本文講的是[譯] 單元測試，精益創業，以及兩者之間的關系，

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

為什么軟件需要測試？

我曾經以為是為了產出高質量的代碼：你總是需要測試因為你總是需要寫出高質量的代碼。
但是這個觀點有幾點問題。

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

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

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

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

測試的意義是什么？

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

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

那我們來以這個為出發點來看看能學到點什么。

測試的第一個方面

下面這個是測試吧？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

測試的第二個方面

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

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

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

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

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

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

測試的象限圖

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

用戶行為

• 有人買你的產品嗎？
• 設計的改變會影響注冊人數嗎？
• 用戶知道軟件是如何工作的嗎？

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

軟件表現

• 你的軟件在負載下表現如何？
• 你的產品拋出異常嗎？

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

功能正確性

• 你的軟件符合規范嗎？
• 它做了它該做的嗎？

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

功能的穩定性

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

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

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

應用上述模型

如何應用模型？

選擇如何測試

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

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

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

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

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

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

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

討論測試的根據

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

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

總結

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

原文發布時間為：2017年3月27日
本文來自云棲社區合作伙伴掘金，了解相關信息可以關注掘金網站。

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。