51Testing软件测试网正在收集测试行业问卷结果，如果你也想为测试行业的前景助力，就点击下方的链接提交答案吧，还有精美礼品等你拿（测试课程五选二）。链接：http://vote.51testing.com/

　　测试团队在项目或版本测试完成后，需要对本次项目或版本所发现的缺陷做统计分析，在分析的过程中，总结项目或版本在哪些方面可以进行改进，为下个项目或版本的管理，做更好的管理和风险预防。

　　分析缺陷一般从以下角度来进行：

　　以某个项目为例，此项目共涉及6个关联系统，整个项目周期，发现的缺陷数共508个（缺陷数已按等级进行换算）。下面从各方面分析缺陷的分布情况。

　　从缺陷的根本原因上分析

　　上表中，根本原因中，各项内容的含义如下：

　　文档问题

　　指的是在静态测试（包括文档的正式及非正式评审）时，测试人员发现的各类文档的问题，投产手册的问题。

　　程序代码问题

　　程序存在各种的代码问题，程序未按需求功能实现等。

　　需求分析不全

　　需求分析不全面导致的部分场景或功能未实现。

　　需求变更

　　由于出现缺陷，导致需求需要变更。

　　环境问题

　　部署操作不正确；

　　参数设置没按投产手册要求执行；

　　控版出错（含：未与生产同步、未与上一个版本同步等）。

　　数据质量问题

　　不符合需求的测试数据，测试中产生的脏数据。

　　项目组的问题由程序代码问题、需求分析不全和文档问题组成。

　　其中，程序代码问题的占比是最高的，程序代码问题表现在：一是程序员在编码时只考虑正常场景的情况，一些异常和特殊的场景的情况都没考虑到；二是修改一个缺陷后，引出另外的缺陷。

　　需求分析不全、和文档问题，加起来占比6.7%，从另一方面说明项目组不重视文档及文档质量，对功能分析不透彻。

　　从以上可以看出，项目组需要加强文档编写质量、需求的充分评审和代码评审及走查。测试交付团队方面的问题，数据质量问题和环境的问题共占比9.8%，数据质量问题单项占到6.3%，这个比例偏高，测试团队应该管理好测试数据的质量，以免由于不合规的数据浪费大家的时间和精力。

　　环境问题，交付团队应该在项目或是版本开始时，测试环境的配置与生产环境的配置一致，以保证测试版本的有效性，在部署时，需要与测试团队先做沟通，避免一些没有必要的环境问题。

　　从缺陷发现的阶段分析

　　测试分析阶段处于测试人员对需求文档、概要设计文档的评审（评审包括文档的测试和评审会），这个阶段的缺陷数，主要由文档问题、评审问题组成。

　　测试执行阶段包括冒烟测试、第一轮、第二轮和回归测试。在这个阶段，测试团队对整个项目或是版本做全面的测试，用各种测试方法来验证项目或版本是否符合上线标准。

　　冒烟测试：只对项目或是版本做主流程的验证。

　　第一轮、第二轮测试，是执行所有的测试用例，对所有的功能做全面的验证，测试类型包括了功能测试、性能测试、可靠性测试、安全性测试、接口测试等等。

　　回归测试是对项目或是版本做全面的回归测试，包括第一或第二轮测试过程中，本来测试通过的用例，再加上此次未改造的功能。

　　补丁测试，指的是在项目或版本已经定版后，仍存在非改不可的，影响流程性的缺陷。

　　各个阶段出现的缺陷数量，也可以分析项目组或是测试团队在哪个阶段是否有问题。

　　从缺陷的引入系统上分析

　　缺陷数已按等级进行换算：

　　系统2和系统3的改造量排名第一和第二，难道就证明了改造量大的，出的缺陷就多吗？

　　也不是，像系统4的改造量只是比系统3少了10%，但缺陷数却少了3分之一。

　　虽然系统与系统之间的缺陷没有什么可比性，但如果加上各个系统的开发工作量，计算出各个系统的缺陷密度，虽然可比性的不大，但是以整体来看项目组的程序质量来说，这样子有一定的可比性了。

　　缺陷密度以1为基准，缺陷密度高于1的系统，可能需要分析一下程序的质量，看问题出在哪里。

　　从测试漏检上分析

　　此次项目上线运行一个月内，生产上出现的故障数量如上表所示。从上面可以看出，测试团队在漏检的问题上占了3个，是总故障数量的一半，且测试分析遗漏一个，用例遗漏一个，而执行还遗漏了一个，这说明测试团队的内部存在流程或沟通的问题。需要测试团队进行分析具体的原因。

　　总结

　　以上从各个方面来分析项目或版本的缺陷，都是希望从各种渠道来了解项目组和测试团队的情况，分析是否他们存在内部规范或是流程上的问题，需在哪一方面做进一步改进措施。

　　除此之外，还能收集各团队的项目指标，与公司的基准数据做对比，看是否与之相匹配，是否存在改进的方面，能以更好的姿态去迎接下一次挑战。

作者：陆空    

来源：http://www.51testing.com/html/76/n-7793376.html