做好發散測試，提高軟件測試效率

　　朋友，你是否了解發散測試?你嘗試過發散測試么?你的發散測試的效果如何呢?

　　發散測試，顧名思義就是不以某個標準或者框框作為約束的一種測試，對于我們測試人員來說，給我們最大的約束的就是測試方案和測試用例，有時候別人寫好的東西我們直接執行就行了，就像我們根本就不需要思考一樣，那個時候，就覺得自己馬上就成為一個隨時被淘汰的角色，因為只是執行，我比自動化工具差多了。(具體差多少，自己可以比較時間，金錢，效率，成功率，犯錯率等等，保證讓你無地自容。)

　　還好，現代的軟件測試還沒有發展到那么強大--完全可以依靠工具。但是不管怎么樣，作為測試人員，我們的首要目標就是在產品上市前多找出缺陷，保證不會因為我們的漏測將缺陷遺留到現場去。我們每輪迭代按部就班，兢兢業業的將我們的用例跑一遍，卻時常感到有點不靠譜，總感覺有地方沒覆蓋到，測過的地方好像還是有點問題，但是用例確實是執行通過了。這時候，你有什么辦法?

　　此時，你需要拋開用例了。

　　發散測試幫你的忙，你完全可以不用盯著用例一遍遍執行步驟，你完全可以依靠此時你對系統的理解和分析得出你自己的結論，哪些地方好像不足，哪些地方需要再覆蓋一下。筆者總結點自己日常使用的方法，雖然是班門弄斧，但是還是覺得有一點用，畢竟，它們都曾經發現過我漏測的問題。

　　(1)2-8原則：測試的同學都知道有2-8原則，80%的缺陷發生在20%的代碼區，這一塊基本上是缺陷的高發區，不光主流程有問題，各種小毛病層出不窮?？墒?，你提了多少張問題單了?你的覆蓋是否全面了呢?越是這個時候越要小心，有可能你自己測試的時候就放過了不同的問題，而自己卻覺得是已知問題而一帶而過。這種問題不止一次發生在自己身上，深有體會，發散測試需要重點關注這樣的場景，你會收到意想不到的收獲。

　　(2)對比需求，參照設計：我們的用例寫好之后還有多少同學會回過頭去看但是給我我們啟發的設計方案?我們還是否能夠一直跟著需求文檔對需求文檔了如指掌，甚至比需求人員還要熟悉?測試人員憑什么說自己能夠代表用戶在進行測試?不就靠這個么?如果你對需求的理解，對設計的了解不如開發人員，人家要你干什么呢，你測試完成后現場用戶提了一堆問題你測試一點責任都沒有?怎么可能，最先追溯的就是你測試。如果出現設計和需求重大偏離的還會遭到投訴。我們作為質量的把關人員，整天和開發混在一起，很容易按照他們的思維走，認為這個東西就是這樣。我們測試完成之后還是要認認真真的過下需求和設計，確保理解的一致。

　　(3)用戶場景：試問一句，有多少同學確切的知道現場客戶如何使用咱們賣出去的東西?長期在研發體系混的大部分不知道?？偸怯X得應該是這樣用的吧!例如一個最大容量是500個同時請求的系統，一般情況下有多少人在使用?我們需要使用500個線程一直連接測試系統的抗壓能力么?完全不用。老同學們都知道其實這個系統長久的運行一般都是300號人同時，一年能夠有幾次500人的機會。就像移動的系統，他的設計規格可能是容納春節期間的用戶量的，但是我們測試人員就不用一直測試，畢竟春節也就那幾天電話、短信暴漲，平時也就正常值的6成到7成。我們測試結束后可以讓幾個同學一起登陸系統操作，模擬用戶的真實場景，并發情況等操作，系統是否采用了保護措施，雖然開發可能跟你說，這種觸發的概率低，但不能因為低就忽略它，如果不測試，它就是個隱患，不知道什么時候就迸出來。

　　(4)異常場景：我們有時候就過分的迷信了自己。我們的系統是強大的，健壯的。但是一次下電、一次主備倒換、一次異常重啟，一次網絡故障，我們的系統就Down掉了。這叫健壯么?我們要考慮到一切場景，例如用戶操作到一半突然系統故障了，就像取錢，萬一正在吐錢的時候ATM掛掉了?怎么辦?用戶升級后需要重啟系統我們是否還能保留原來的數據和狀態讓最終的用戶毫無察覺系統在主備倒換?災難過后的數據能否正?；謴?，不懷好意的用戶進行的非主流操作你是否能夠給予他警告并讓其無法執行?我們都覆蓋了么?

　　(5)我們要根據規范，測試，不是無原則的發散，我們的規范、結論也是大家集體討論的結果，是產生效率的保證，我們根據規范就能發現一些不規范的地方，常見的規范包含UCD規范、online、inline規范，設計規范，接口規范。我們根據規范，讓我們的系統不至于那么難看，不至于讓人一看，這些個頁面、功能就是一群江湖郎中做出來的。

　　給自己總結，給大家分享，測試之路，越走越寬!

原文轉自：http://www.kjueaiud.com