前言

在軟件測試中有很多重要的指導原則，這些原則看上去大多是顯而易見的，但是總是被我們忽略，作為蟲師，我們當然應該把這些原則牢記于心，作為專業測試人員的基本素養。

測試用例中一個必需部分是對預期輸出或結果的定義 這條原則是軟件測試中常犯錯誤之一，但是如果不按照這條原則進行，由于“所見即所想”這樣的一個心里現象的存在，某個似是而非的錯誤結果可能會被當成是正確的結論。解決問題的辦法就是事先在設計用例的時候就精確地定義程序的預期輸出，鼓勵人們對輸出的結果仔細檢查。

因此一個測試用例必須包括兩個部分：

對程序輸入數據的描述；

對程序在上述輸入數據下的正確輸出結果的精確描述。

程序員應當避免測試自己編寫的程序

這個大家都能夠理解，因為親自編輯或者校對自己的作品作品確實是有失公允的。當程序員“建設性”地設計和編寫完程序之后，很難讓他改變視角“破壞性”的來審視程序。但是我們要注意一點，這一條原則并不適用于“調試”，相反的，“調試”由程序員自己完成會更有效。

編寫軟件的組織不應當測試自己編寫的軟件

這一條原則的論據與上一條想死。雖然很多組織在某種程度上面成功地做到了這一點，但是更經濟的方法是由客觀、獨立的第三方來進行測試。

應當徹底檢查每個測試的執行結果

這條原則很多人覺得簡直是廢話，但是卻還是常常的被忽略。我們見過很多大量的例子，即便錯誤的癥狀在輸出清單中可以清楚地看到，但是還沒是沒有找到那些錯誤出來。

5.測試用例的編寫不僅應當根據有效和預期的輸入情況，而且也應當根據無效和未預料到的輸入結果

在軟件測試的時候，有一個自然的傾向，就是將重點集中在有效和預期的輸入情況上，而忽略了無效和未預料的情況。但是用戶真正使用軟件的時候，就有了很大的隨機性，因此軟件產品會突然暴露出很多問題在測試的時候未被預料到。因此，針對未預料的和無效輸入情況的測試用例，似乎比針對有效輸入情況的那些用例更能發現問題。

檢查程序是否“未做其應該做的”僅是測試的一半，測試的另一半是檢查程序是否“做了其不應該做的”

這一條原則是上一條原則的必然結果，必須檢查程序是否有我們不希望的副作用。雖然程序員會覺得委屈：我做了更多的功能難道還錯了嗎？測試人員只能含淚點頭：親，確實錯了。不論IT世界是如何的倡導自由開放，基本的規則還是要遵守的，給用戶想要的，做到最好足矣。

應避免測試用例用后即棄，除非軟件本身就是一個一次性的軟件

飽含蟲師們寶貴投入的測試用例，在測試結束之后就消失了，一旦軟件需要重新測試，比如改正了某個錯誤或者作了某種改進，又必須重新設計這些測試用例。保留測試用例，當程序其他部分發生更動后重新執行，這就是我們所謂的“回歸測試”。

計劃測試工作時不應默許假定不會發現錯誤

測試，就是為了發現錯誤而執行程序的過程。

程序某部分存在更多錯誤的可能性，與該部分已發現錯誤的數量成正比

這個原則也叫缺陷的二八定理，指的是一般情況下，軟件80%的缺陷集中在20%的模塊中。我們測試的時候要抓住主要矛盾，如果發現某一個程序模塊比其他模塊有更多的缺陷，就要投入主要的人力和精力重點測試這20%的模塊，以提高測試的效率。缺陷的二八定理成為缺陷的集群現象或者是蟲子窩現象。

如果對軟件測試、接口測試、自動化測試、技術同行、持續集成、面試經驗交流。感興趣可以進到902061117，群內會有不定期的分享測試資料。

如果文章對你有幫助，麻煩伸出發財小手點個贊，感謝您的支持，你的點贊是我持續更新的動力。

總結

以上是生活随笔為你收集整理的为什么软件测试容易被小看,做软件测试容易忽视的问题的全部內容，希望文章能夠幫你解決所遇到的問題。

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