前言

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

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

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

對程序輸入數(shù)據(jù)的描述；

對程序在上述輸入數(shù)據(jù)下的正確輸出結(jié)果的精確描述。

程序員應(yīng)當(dāng)避免測試自己編寫的程序

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

編寫軟件的組織不應(yīng)當(dāng)測試自己編寫的軟件

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

應(yīng)當(dāng)徹底檢查每個測試的執(zhí)行結(jié)果

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

5.測試用例的編寫不僅應(yīng)當(dāng)根據(jù)有效和預(yù)期的輸入情況，而且也應(yīng)當(dāng)根據(jù)無效和未預(yù)料到的輸入結(jié)果

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

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

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

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

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

計劃測試工作時不應(yīng)默許假定不會發(fā)現(xiàn)錯誤

測試，就是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程。

程序某部分存在更多錯誤的可能性，與該部分已發(fā)現(xiàn)錯誤的數(shù)量成正比

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

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

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。