第三：版本测试发现的缺陷情况如何。

　　缺陷记录是测试人员的宝库，但是很多测试人员甚至包括测试leader对缺陷记录的利用一直停留在很初级的水平上，没有进入深入的挖掘，没有能够总结出一套属于自己组内的缺陷模式，导致每个版本发布时总是出现相同的缺陷，而且不同人接手不同项目的测试总是会犯一些以前犯过的错误。针对这种情况，测试人员是否要思考下有没有什么方法来改善，来充分的利用缺陷？

　　1、缺陷产生的原因分析。缺陷找到后，需要弄清楚为什么这里会出现问题，其它地方没有问题。缺陷产生的根本原因是开发人员的经验欠缺呢？还是系统比较复杂，涉及到的交互和协议很多，单个开发人员不可能完全掌握？还是产品的需求定义不明确？甚者是开发人员的懒惰找出代码对异常情况的考虑不周？

　　2、缺陷是否能够归为一类，是否可以抽象出共性的问题，比如缺陷生成的功能点、场景、业务，测试业界是否有类似的缺陷模式来定义，如果没有的话，我们自己是否可以明确定义这类问题，并且分享给业界。这类缺陷是否在不同项目下出现过，且出现的频率很高。测试人员对这类缺陷应该进行抽象和总结并且分享给开发人员和管理层，减少他们再次产生同类缺陷的成本。

　　3、对于比较难重现的缺陷测试人员是否可以通过编写自动化工具来复现，创造特定的环境来使bug现身。

　　4、bug严重等级分布。致命、严重、一般、建议类的bug分别如何，是否符合正态分布。

　　5、缺陷密度如何。那些模块比较容易产生bug；那些开发人员的bug数比较多，且bug严重等级高；那位产品提的需求不够严谨，经常出现需求变动导致bug，需求定义不准确导致bug；那类环境下出现的bug多（比如web的兼容性测试，是ie6环境下bug多呢？还是firefox下等）。

　　第四：版本漏测原因分析。

　　随着计算机软件的复杂度增加，系统内部各模块之间的交互通信、系统与系统之间的交互越来越复杂，但是开发人员的能力提升水平却是比较缓慢的，而且优秀的开发人员更加少，合格的开发人员也不多，导致编写的代码存在很多缺陷。我们测试过的一个web系统，开发周期大概1多月，但是测试时间才2周，发现了300多个bug。即使这样发出去后还是会出现一些漏测的情况。针对这种情况，我们有什么办法来分析并且减少漏测呢？

　　1、测试用例覆盖度如何？有没有覆盖到用户常用的场景、操作习惯、用户数据真实度模拟。

　　2、代码覆盖率有没有至少做到行覆盖，对于未覆盖到的代码有没有进行风险评估。千万不能认为用户的环境不会这么特殊而放弃测试。我们有一个版本特性是测试软件给用户开辟一块硬盘缓存的特性，开发想当然的直接划分了1G的空间给到程序，没有考虑到如果用户的虚拟内存是分配在系统盘，且如果系统盘的剩余空间小于1G时程序会不会出现crash。测试人员在做代码差异覆盖时已经发现这个问题，但是在和开发确认后就轻易的放过去了。

　　3、测试人员的测试思维是否狭窄，对被测系统的各个底层理解不够深入，所检查的测试点都是比较简单，导致系统会出现漏洞。比如在测试文件上传功能时，程序不允许上传exe等可执行文件。如果只是简单的检查是否文件名后缀，并且只是前端javascript来做检查，后台不做二次检查的话，就很容易被用户使用fiddler等抓包调试工具轻松构造条件绕过。

　　4、测试人员的经验是否不足，测试leader在人员安排方面是否有疏忽，没有进行新老同事搭配，没有对重要且风险高的功能安排资深的测试工程师辅助进行把关。

　　5、测试时间不够，导致计划测试的内容结果没有测试到。针对这种情况测试人员在版本发布前是否有进行风险分析并且知会到相关的owner。

　　以上是perry在日常的测试工作中不断总结的一些经验，肯定会存在很多偏差的地方，随着经验的积累，阅读和反思，以后肯定会有更多不同的想法。以后如果有新的想法会不断的补充进去。如果有什么建议很欢迎各位发表留言。