“反”探索性软件测试， 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.ltesting.net