在經歷了多年的痛苦之后，我感覺已經找到了一條通往軟件測試事業的道路。盡管如此，我還是忍不住感到沮喪，因為我花了這么長時間才找到一個有意義的答案。作為一名軟件測試人員，我覺得我應該能夠更快地找到答案，回顧我之前的工作，有幾條紀律需要額外注意。

　　第一，覆蓋范圍廣的正式測試比隨機測試更好。當我們第一次接觸一個系統是，總是想根據經驗來解決它。也許應該控制參數長度?也許該改變參數類型?這些想法雖然都很正確，但更多的是基于猜測而非證據。

　　一次檢查需要很多時間，結果卻是不可控的。正式的測試用例設計也需要花費時間，但是它能得到明確的結果，之后還可以復用。

　　當一切正常時，隨機測試是可以接受的，但當系統性問題出現時，隨機測試毫無幫助，此時必須建立覆蓋范圍廣的正式測試用例，確鑿的證據勝過胡亂猜測。

　　運行一組已建立的測試，即使它們看起來很小，也可以在短時間內提供巨大的價值。

　　第二，當測試產生結果時，知道什么是“好”和知道什么是“壞”一樣重要。通常，軟件工程師只關注失敗的測試，如果測試通過了，誰在乎呢?

　　當你試圖考慮哪些參數格式可能引發異常時，也要看一看，用戶常見的一些輸入格式是否會引發異常。

　　第三，沒有任何測試具有“完整”的覆蓋范圍。作為一名軟件測試人員，永遠應該有的擔憂是測試無法完全涵蓋產品行為。這就是為什么我們試圖用擁有的資源最大限度地覆蓋風險最大的因素，我們也會盡可能多地了解測試中的行為，以盡量減少未知因素。

　　第四，測試成本雖然貴，但值得一試。 軟件測試的成本是非常高的，但是相比上線后可能產生的損失，測試行為是非常劃算的。 許多軟件團隊回避常規的正式測試工作，因為他們不想花時間做這件事，也不想花錢請第三方的機構，這會為產品上線后的用戶使用埋下巨大隱患，甚至決定產品的發展和增長，不重視測試的軟件團隊是不值得呆的，因為他的未來有很大的產品風險。

　　第五，測試結果只有得到糾正才具備意義。如果測試團隊測試出的 bug 遲遲得不到修復，測試人員提出的建議總是被搪塞和延遲執行，軟件的總體質量也會被侵蝕。

　　測試并不能提高質量，它只是指出質量問題。作為工程師，我們必須根據測試反饋改進軟件行為，無論這意味著修復 bug、改善用戶體驗，還是針對已知問題發出警告。