在向開發人員介紹單元測試或TDD等工程實踐時，往往可以聽到這樣的疑問。比如：

自己寫的程序，自己無法從另一個角度測出問題。

寫bug的時間都不夠了，哪有時間來寫測試？

開發來寫測試了，測試干什么？

除了核心代碼，沒有什么值得測試的。

……

本篇想要通過探討這些問題背后的困難，來說明程序員怎樣通過編寫自測代碼更有效率的進行開發。

一個例子

首先我們看一個例子。

全項目唯一的測試

不止一次，我在各種項目中看到這樣的測試，往往這也是整個工程中唯一一個測試。

可以看出，開發者認為編寫是有必要的。所以按照“標準”的做法建立了測試目錄，引入JUnit依賴。并且利用它在開發的初期來驗證某些技術疑問，一般是某些當時還不熟悉的第三方庫，或者數據庫、中間件等外部依賴。

項目初期技術調研階段很快過去后，似乎沒有更多需要驗證的問題。因而也就再沒有需要編寫測試的地方。

簡單而言：“寫測試是應該，但我們的代碼沒什么好測的”

測試，不僅僅關于未知

說起測試，往往與未知相關聯。我們通過測試、調試、檢測來獲取反饋，不斷調整。

以上圖為例，一般想到的測試，都集中在“已知的未知”這個象限。正如前面的示例代碼，使用不熟悉的庫帶來未知。程序員通過在測試中調用和觀察結果來消除未知。

然而，對于自動化測試來說，其實關注點在于已知。

“都已知了，還測試什么呀？”，也許你會有這樣的疑問。

火柴問題

火柴，這種行將消失的物品。也許現在的小朋友只是在《賣火柴的小女孩》中才得知它的存在。在我小時候，還是時常用到的。那時，也許是工藝問題，或者存儲條件有限，往往一盒火柴好多根都不能點著。記的那時聽到的笑話：

小明的媽媽讓他去買盒火柴，不一會功夫買回來了。媽媽問：“你試過沒有，能點著嗎？”

“試過啦”，小明很驕傲的說，“每一根我都試了一遍?！?/p>

我把這種問題稱為“火柴問題”，往往傳統的質量控制面臨的都是這類問題，有如下限制：

?成本，顯然現實中不會有人把所有的火柴拿來測試。不過問題的本質并沒有變，在花費的成本和獲得安全性之間取一個平衡。

?事后，造出火柴后才有能否點著的問題。

?一次性，成本換取的安全是一次性的，每當一個批次到來時，以前的測試的付出都成為了沉沒成本。

另一種測試

讓我們來看另一種關于已知的測試。

Checklist

檢查清單。

比如每天出門的時候，我都會自然而然的檢查一遍，手機、鑰匙、錢包。就是個簡單的清單。

清單是關于已知的，只有十分確定的事項才會列入在清單里。

清單本身很簡單，并不能回答火柴問題這樣的難題。但是不代表它沒有作用。以出門為例子，有時出門是每天都在做的上班通勤，有時是去面臨某個很大的未知，比如去見一個陌生的客戶，進行重要談判。

這時如果有個水晶球，告訴你會成功失敗，甚至告訴你怎樣做才能成功，那就太好了。

然而沒有水晶球。

一個簡單的清單至少保證你不會走在路上才發現忘帶手機。無論未知的挑戰是什么，忘帶手機基本上不會產生任何幫助。

切換回軟件開發的場景，程序員夢想中的好測試也許能告訴我們未知，甚至未知的未知結果。這在目前還不現實。那么寫一個測試確保你在不斷調整中不破壞正確的事情，仍是值得的。

可以看到，這種視角下的驗證，與檢查火柴有所不同：

?預防，這種校驗著眼于未來，是為了避免更大的損失的投入。

?過程中，檢查是做事情步驟中的一個環節。

?反復，越頻繁的行為越有必要進行校驗，校驗的越頻繁潛在收益越大。

假定你是獨自居住，出門前還是鎖門后發現沒帶鑰匙的成本，會有一個巨大的飆升。往往檢查列表都是在這種成本拐點前進行的。

當前標題：程序員自己寫測試，還要測試人員做什么？
網站地址：http://m.newbst.com/news36/102236.html

成都網站建設公司_創新互聯，為您提供網站內鏈、域名注冊、品牌網站設計、Google、小程序開發、靜態網站

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯