軟件測試是失敗者的賭注

    英文原文： Software testing is a loser's bet

在看本文時，切記測試不是為了提高質量。提高質量的唯一方式是修改產品，測試不會改變產品。

測試的目標是收集產品信息，當然，這種信息在改善產品時可以被用到。

對于軟件測試，我的意思是在產品開發階段之間和之后的某些情況下，我們測試工程師所做的檢查。管理員可以創建新用戶嗎？自動同步可以從連接問題中恢復嗎？這個輸入框接受多字節的 UTF-8 字符？等等類似的問題。

或許軟件測試最重要的不是單元測試、可用性測試、性能測試、驗收測試或任何其它非功能性的測試。

檢查與 90 年代的相關性

關于測試工程師在開發階段做了大量檢查而沒有在其它地方做太多的當前模式，是來自于早期的人為現象，在互聯網之前的日子贏了每一場戰斗。

在一切都是網頁以及我們所有設備都能不間斷地訪問互聯網之前，收集產品信息的唯一方式就是測試。沒有可查的服務器日志、崩潰報告和 UI 標準。

在過去，如果你一周能夠得到一個版本就是幸運的。第一個可行的單元測試框架誕生于 1998 年（SUnit，xUnit 家族第一成員【注1】），因此，“如果它編譯了，那么它就沒問題”成了標準。

收集關于產品任何信息的唯一方式是做大量測試。

回到現在

今天狀況完全不同了。

很快我們所有設備都可以始終訪問互聯網了。如果我們避開操作系統和 web 瀏覽器，那么我猜想，我們消費的大部分軟件實際上正運行在軟件所有者的機器上。我這里討論的是網頁。

因此大部分軟件正運行在這樣的機器上，以致于開發者能夠得到真正詳實的使用數據、錯誤報告以及所有細致的日志信息。所有這些信息在 20 年前都是獲取不到的。

當然，我們用來得到這些日志和報告的同樣渠道，也可用于發布、更新軟件。

20 年前，當你發布一款軟件產品時，你將其刻在 CD 上，放入紙板盒，逐個將產品發往某個地方。你不知道誰在真正地使用產品，因為它是被實體店買走的，你沒有去賣它。一些零售商在處理這些事務。

因此你根本不知道軟件在客戶機器上是否真正運行。即使你知道某些功能不好用或在某些條件下不能運行，你也沒有辦法更新軟件。因為你不知道誰在用你的產品。

當周圍環境發生變化時，我們需要重新思考該如何使用我們的資源。過去唯一理智的做法就是盡可能保證沒有 bug，因為如果有任何種類的問題，修復它們幾乎是不可能的，你的軟件也無法報告給你。

現在推論就有了，在發布前盡最大人力做大量測試的行為，還算是最聰明的策略嗎？據我看，不是。

在我看來，我們應當把精力放在盡可能確保原始代碼的質量上，產品版本是我們實際想要的東西，我們也在真正地關注著版本。我們應該盡可能多地監控產品使用情況。為了對產品反饋給我們的數據做出反應，我們必須確保產品易于修改和維護。

接下來呢？

我們應該幫助開發者寫出更好的代碼，而不是整天放在檢查工作上。我們應該提倡更好的開發實踐，我們應該教他們使用持續集成系統，更好的版本控制系統，單元測試、代碼審查、靜態分析和其它最佳實踐。

我們應該通過建立紙面原型（paper prototype）以及做一些走廊可用性測試【注2】來幫助產品所有者。我們應該確保這個版本被真正實現了。

我們應該編寫小程序，以自動地驗證產品核心組件的功能。這里，我故意避免測試自動化，因為我想強調這種技能是必需的。

我們應該測試產品的初始版本盡可能沒問題，這實際上是有要求的。產品接下來的開發應該盡可能容易。

為什么？

初始代碼質量越好，產品后續工作就越容易。當有驗證核心組件功能的自動化測試用例時，產品后續工作就更有保障了。當開發過程和版本控制都處于良 好態勢時，產品后續工作就更加容易。同樣還有經過同行評審【注3】和單元測試的代碼等。當我們確保代碼質量處于這種狀態時，修改和修復產品就更容易了，我 們能夠更加容易地對變化做出反應。較好的代碼質量意味著 bug 更容易修復、新的開發人員能夠在較短時間內接手產品等。

我們應該拋棄發布重度測試過的產品的懶惰思維，而要關注發布一個盡可能容易修改的產品。

通過幫助產品所有者驗證他們的想法，我們可以更容易地找到失敗之處。當我們確保這些想法真正被實現時，我們才真正地得到了符合要求的產品。

長話短說

這里用摘自 GTAC 2014 的一張不錯的幻燈片做為總結：

• 注1：SUnit 是面向編程語言 Smalltalk 的一個單元測試框架，它起源于 XUnit 設計，原作者是極限編程的創始人 Kent Beck。http://en.wikipedia.org/wiki/SUnit
• 注2：走廊測試是一種通常的可用性測試，這個技術上的命名意指測試這應該是隨機穿過走廊的人。http://en.wikipedia.org/wiki/Usability_testing
• 注3：同行評審（Peer review，在某些學術領域亦稱 Refereeing），或譯為同儕審查，是一種學術成果審查程序，即一位作者的學術著作或計劃被同一領域的其他專家學者評審。一般學術出版單位主要以同 行評審的方法來選擇與篩選所投送的稿件錄取與否，而學術研究資金提供機構，也廣泛以同行評審的方式來決定研究是否授予資金、獎金等。http://zh.wikipedia.org/wiki/%E5%90%8C%E8%A1%8C%E8%A9%95%E5%AF%A9

— END —

譯文： 《軟件測試是失敗者的賭注 》 臘八粥