缺陷预估方法

目前存在的问题

1、 用例设计完成后测试人员基本按照用例执行，测试人员主观发挥空间比较少，不利于测试人员的测试分析能力的提高

2、 目前基本上在集成测试阶段整个用例导入后90%以上的用例都能够正常pass掉，实际这部分的用例是能够减少测试的。执行发现不了bug的用例（特别是在测试人员在执行该用例的时候就能够分析到该用例不能够发现bug）基本上做的就是无用功，也浪费了我们很多的测试时间，对应的增加了整个版本的测试周期

缺陷预估方法：在集成测试开始前（全面测试），首先分析该模块可能存在缺陷的地方（可以按照研发的千行代码bug率来进行分析），然后根据分析导入能够测试到这些缺陷的用例（如果分析可能有5个地方存在10个缺陷），那么第一天只导入大概20个用例左右（差不多一天就能够测试完成），这样如果我们分析的比较全面的话，第1天应该就能够发现该模块所有的bug（当然，现在可能还没有达到这样的程度，但是70-80%以上应该还是有可能的，后面通过我们分析技术的不断完善，基本上是能够达到90%以上的），然后我们再根据自己的测试结果进行进一步的分析，然后再导入部分可能存在风险的用例（大概20个也差不多够了，通过这20个用例发现剩余20%左右的bug），这样我们实际上该模块就测试了40个用例，比起以前测试100个用例能够节省60%的工作量，也能够让bug在前期就暴露出来（以前按照顺序执行用例发现bug的效率确实是比较低的）！而且随着测试质量分析技术越来越完善，我们实际上需要话费的测试时间就更少了！

下面，提供一些分析的方法和过程：

1、 评估该模块的代码行数，结合千行bug率来评估下该模块的的bug数（这个要走悲观策略，比平均值要稍微高点）

2、 子模块划分法，根据该模块的逻辑划分出具体的子模块（具体方法可以查看测试分析技术1），然后将每个子模块的bug数分析出来（可以跟研发和该模块专家一起讨论）

3、分析出可能存在bug的逻辑（根据该逻辑的复杂程度和自己的经验），然后导入能够测试到这些逻辑的用例（可能发现有些逻辑没有用例覆盖到，需要补充测试用例），可以重点考虑研发的一些异常情况处理（这部分研发实际上已经有很大改进了）

4、分析每个逻辑是否会和其他哪些模块关联（可以参考模块的关联表），由于研发一般只关注自己的模块，这块是比较容易出现问题的地方，然后也针对性的导入用例和预分析出bug

5、内部头脑风暴，可以召集2-3个人一起分析下是否还有其他存在其他的风险，或者这个时候就可以引入ET测试技术，然后再导入对应的用例安排测试

 6、经过上面方式后看下发现的bug情况，是否和预期差不多，然后再根据发现的bug做一些补充和发散测试，这点可以作为上面提到的第2部分补充测试方案（也可以结合起来），如果分析技术比较全面的话应该是能够达到目的的