“反”探索性軟件測試， anti exploratory testing

　　首先申明一下， 這篇文章不是要說探索性軟件測試這種方法不好，而是想說明，不能過度去追尋探索性軟件測試的方法，或者是說想提供一個簡單的探索性軟件測試的簡化方法(情景測試， scenario 測試 or 主要情景測試)。

　　scope： 個人軟件， 一般的辦公軟件。。。

　　大部分用戶(80%)使用的是軟件20%的功能(80/20理論)， 所以你要認真的測試這個20%的功能，如果這20%的功能是完善的，用戶會給你80分;

　　80%的test case，需要cover這20%的功能， 其他20%的test case需要cover其他80%的功能; 20%的test case可以發現80%的bug; 也就是你設計的其余80%的test case能發現20%的bug(大部分都是探索性軟件測試的方法來設計的)

　　20%的代碼貢獻80%的bug; 80%的代碼貢獻20%的bug，而這80%的代碼往往比較底層，或者說比較難以發現;

　　另外一個是關于新功能的測試，還有回歸測試的：

　　80%的bug源自新功能，20%(或者更少)是來自回歸的， 而所有的test case 80%是針對舊功能的，20%針對新功能，所以多花點時間在新功能上;

　　建議： 新功能可以多采用探索性軟件測試的辦法;舊功能只要跑正常情景下的測試即可

　　所以怎么辦呢? 建議是用情景測試來替代探索性軟件測試， 所謂情景測試就是把用戶在大部分情景下使用軟件的情況都想到。

　　Scenario testing is a software testing activity that uses scenarios: hypothetical stories to help the tester work through a complex problem or test system. The ideal scenario test is a credible, complex, compelling or motivating story the outcome of which is easy to evaluate.[1] These tests are usually different from test cases in that test cases are single steps whereas scenarios cover a number of steps.[2][3]

　　Use-case and role-based scenarios

　　In this method the focus is on how a user uses the system with different roles and environment.[4][Need quotation to verify]

　　可以參考： http://en.wikipedia.org/wiki/Scenario_testing

　　以上分析，80，20只是一個比喻，不是精確的數據;

原文轉自：http://www.anti-gravitydesign.com