本文講的是[譯] 單元測試，精益創(chuàng)業(yè)，以及兩者之間的關(guān)系，

• 原文地址：Unit testing, Lean Startup, and everything in-between
• 原文作者：Itamar Turner-Trauring
• 譯文出自：掘金翻譯計劃
• 譯者：gy134340
• 校對者：zhaochuanxing，yifili09

為什么軟件需要測試？

我曾經(jīng)以為是為了產(chǎn)出高質(zhì)量的代碼：你總是需要測試因為你總是需要寫出高質(zhì)量的代碼。
但是這個觀點有幾點問題。

有時候質(zhì)量不是主要問題。
在“精益創(chuàng)業(yè)” 這本書中，作者 Rric Ries 說過有時候發(fā)布一個軟件最終發(fā)現(xiàn)沒人真的想用它。
這也是他創(chuàng)作的動機之一: 為創(chuàng)業(yè)初期建立一套更好的方法論，在真正投入時間去構(gòu)建一個高質(zhì)量的產(chǎn)品時，就能夠發(fā)現(xiàn)這款產(chǎn)品是否能夠成功的方法論。
如果沒人用你的軟件的話那么確保高質(zhì)量純屬浪費時間。

即使高質(zhì)量很有必要，但高質(zhì)量與測試之間的關(guān)系卻很模糊的。
一個 QA 的團隊跟自動化的單元測試又什么不同？
他們的確不一樣，但他們又分別給出什么樣的質(zhì)量？
什么時候需要特別的測試？

另外，測試是有成本的：你怎樣辨別成本的花費是否超出回報？
比如說，有一家做稅務(wù)申報軟件的公司（我稍微改了一下細節(jié)）。
他們使用 Selenium 來對他們網(wǎng)站的 UI 來測試... 但是他們的應(yīng)用依然很爛，而且每次改變 UI 測試都會崩潰。
這個測試并沒有改變產(chǎn)品的質(zhì)量，相反浪費了程序員的時間來維護測試。
他們做錯了什么？

說我們都需要寫出高質(zhì)量的軟件并不能幫助解決這些問題。
那我們回頭來更加深入的討論一下。

測試的意義是什么？

康熙字典 :)?)里告訴我們測試是為了 “舉證，通過一定原則或標準或?qū)嶒瀬?#xff0c;證明真理，真實性。“
軟件質(zhì)量就在那里，是的，但事實卻又不僅如此。

準確的說，這只是英語定義，可以肯定，有很多不說英語的開發(fā)者。
我不想被字典來束縛我們的行為。
人類語言是數(shù)世紀以來對世界的觀察和理解，也是我們可以拿來借鑒的寶庫。

那我們來以這個為出發(fā)點來看看能學(xué)到點什么。

測試的第一個方面

下面這個是測試吧？

def test_add():assert add(2, 2) == 5

沒錯，他還真是，沒毛病。
看函數(shù)名，一點都沒錯。
測試說明?add()?做了他該做的：將兩個數(shù)相加得到結(jié)果。

你注意到這個測試是錯的。
幸運的是我們的開發(fā)流程進入到了另一步：代碼審查。
親愛的讀者們，代碼審查告訴我我的代碼是錯的，2 + 2 = 4，不是 5。

代碼審查是不是測試的一種？

根據(jù)字典定義來說是的：代碼審查就是根據(jù)標準來驗證代碼的 “正確，真實性和質(zhì)量”，這個從小我們就知道。

那我們假設(shè)代碼審查跟單元測試一樣都是測試的一種。
他們都是測試，卻又相當不同。
那主要的區(qū)別在哪里？

一種是自動化的，一種是人來做的。

自動化測試具有一致性和可重復(fù)性。
你可以這樣寫：

def test_add_twice():for i in range(10000000):assert add(i, i) == 2 * i

電腦每次都跑一遍一摸一樣的代碼。
代碼可以保證根據(jù)輸入每次調(diào)用add()返回他們的結(jié)果。
人在手動驗證一千萬種不同的計算時會遇到一些困難，比如無聊、分心、失誤、緩慢啦等等。

另一方面，任何人都可以很快的告訴你下面的代碼是錯的：

def add(a, b):return a + b + 1

計算機只按照指令執(zhí)行操作，孰對孰錯，人類能賦予它意義。
只有人才知道軟件是為何而生。

現(xiàn)在我們知道每種測試的不同，以及如何組織它：人類來發(fā)現(xiàn)意義，自動化測試確保一致性。

測試的第二個方面

我們來看一下測試的另一個方面。
“A／B 測試”是一種嘗試不同分類來看哪種結(jié)果更好的測試。
比如你為了測試網(wǎng)站新的設(shè)計：給 90% 的訪問者原有的設(shè)計，同時給 10% 的訪問者新的設(shè)計，看看哪種注冊人數(shù)多一點。

這是測試嗎？
這就叫 “A/B 測試”，跟它的名字一樣。

我們來重新看一下字典定義：“舉證，通過一定原則或標準或實驗，來證明真理，真實性。”

字典上說這也是測試，因為通過實驗。
我們通過實驗來看看哪個版本更受歡迎。

單于測試和代碼審查，對比來說，就是通過一定原則或標準來測試。
我們對軟件有一些特定規(guī)格，一些我們希望軟件的行為，同時我們確保它符合規(guī)格。

現(xiàn)在我們有了第二種理解與組織測試的方法：通過實驗測試?vs?針對規(guī)格測試

測試的象限圖

將它們放在一起我們得到下面這張關(guān)于測試的圖表：

用戶行為

• 有人買你的產(chǎn)品嗎？
• 設(shè)計的改變會影響注冊人數(shù)嗎？
• 用戶知道軟件是如何工作的嗎？

這些都是無法通過軟件是否符合規(guī)格來回答。
相反需要你的經(jīng)驗知識：你需要觀察人對軟件的真實反映。

軟件表現(xiàn)

• 你的軟件在負載下表現(xiàn)如何？
• 你的產(chǎn)品拋出異常嗎？

這些問題不能通過對比規(guī)范來解答，
你需要把軟件跑起來看看到底會發(fā)生什么。

功能正確性

• 你的軟件符合規(guī)范嗎？
• 它做了它該做的嗎？

很容易說自動化的測試可以證明這一點，但有沒有想過單元測試在檢查 2 + 2 = 5。
在基本的層面上，軟件可以在技術(shù)上符合規(guī)范卻完全無法達成規(guī)范的初衷。
但只有人明白規(guī)范的含義，和辨別是否匹配這個規(guī)范。

功能的穩(wěn)定性

• 你的公有 API 對于相同輸入返回相同的值嗎？
• 你的代碼是否提供了它該提供的？

人不是測試這個問題的好辦法。
所有人都會忽略小問題：如果一個按鈕從 “Send Now” 變成 “Send now”，很多人都不會注意到。
對比來說，如果你的 API 從?sendNow()?變成?send_now()，或者返回一個不同類型的值，你的軟件就會崩潰。

這就是說公有的 API，或者其他軟件依賴的 API，需要穩(wěn)定性來確保正確性。
為私有的接口寫自動化測試，或者對于迭代較快的代碼，更新測試將導(dǎo)致極高的維護成本。

應(yīng)用上述模型

如何應(yīng)用模型？

選擇如何測試

首先，模型可以幫助你根據(jù)你的目標選擇合適的測試。

如果一家初創(chuàng)公司做一個沒人用的軟件。
寫自動化測試純屬浪費時間，因為他連用戶想要什么都不知道就開始專心實施了。

這里需要用精益創(chuàng)業(yè)的方法論，一個專注于用實驗找到什么產(chǎn)品將滿足客戶的需求的方法來解決。
這意味著專注于用戶行為象限。
只有證明他值得花費時間來進行下去，才值得對這個產(chǎn)品來做一些為了功能性和穩(wěn)定性的測試。

了解你是否選擇了錯誤的測試類型

第二，這個模型可以幫助你改變錯誤的行進路線。
比如說那家初創(chuàng)的稅務(wù)公司，如果他們對于 UI 進行自動化測試但是并沒有發(fā)現(xiàn)問題，然后每改變一次 UI，整個系統(tǒng)都要重新來進行一遍測試。
他們的問題在于系統(tǒng)的兩個方面：

稅務(wù)機制是相當穩(wěn)定的：稅率每年只變一次。
這就需要他們對核心的稅務(wù)計算部分進行穩(wěn)定性或者單元測試。
正確性可以通過代碼審查和稅務(wù)會計來反饋。

基于 web 的用戶界面
UI 一直在變，說明不需要穩(wěn)定性測試。
正確性測試可以通過人工測試來解決（比如說寫代碼的開發(fā)者）。

討論測試的根據(jù)

最后，這個模型提供了一個公有的術(shù)語，來討論的測試的意義及其不同的目標。

• 對于人工測試還是單元測試的優(yōu)異性選擇，你可以從一個很清楚地表明它們之間的差異的模型開始。
• 你也可以從一個完全不同的角度對公司的其他方面（比如市場）來討論測試。

總結(jié)

• 無論是選擇人還是自動化測試來保持持續(xù)性，都是有意義的，自動化測試提供準確性，人手工測試提供意義性。
• 即需要通過實驗，也需要對比規(guī)范來進行測試。
• 每個組合提供了不同的測試形式：用戶行為、軟件行為、正確性、穩(wěn)定性。
• 確保根據(jù)你的目標和情況來選擇合適的測試方式。

原文發(fā)布時間為：2017年3月27日
本文來自云棲社區(qū)合作伙伴掘金，了解相關(guān)信息可以關(guān)注掘金網(wǎng)站。

總結(jié)

以上是生活随笔為你收集整理的[译] 单元测试，精益创业，以及两者之间的关系的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。