對於軟體測試，我的意思是在產品開發階段之間和之後的某些情況下，我們測試工程師所做的檢查。管理員可以建立新使用者嗎？自動同步可以從連線問題中恢復嗎？這個輸入框接受多位元組的 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 —
相關閱讀
評論(1)