测试团队在项目或版本测试完成后，需要对本次项目或版本所发现的缺陷做统计分析，在分析的过程中，总结项目或版本在哪些方面可以进行改进，为下个项目或版本的管理，做更好的管理和风险预防。
分析缺陷一般从以下角度来进行：
以某个项目为例，此项目共涉及6个关联系统，整个项目周期，发现的缺陷数共508个（缺陷数已按等级进行换算）。下面从各方面分析缺陷的分布情况。
从缺陷的根本原因上分析
上表中，根本原因中，各项内容的含义如下：
文档问题
指的是在静态测试（包括文档的正式及非正式评审）时，测试人员发现的各类文档的问题，投产手册的问题。
程序代码问题
程序存在各种的代码问题，程序未按需求功能实现等。
需求分析不全
需求分析不全面导致的部分场景或功能未实现。
需求变更
由于出现缺陷，导致需求需要变更。
环境问题
部署操作不正确；
参数设置没按投产手册要求执行；
控版出错（含：未与生产同步、未与上一个版本同步等）。
数据质量问题
不符合需求的测试数据，测试中产生的脏数据。
项目组的问题由程序代码问题、需求分析不全和文档问题组成。
其中，程序代码问题的占比是最高的，程序代码问题表现在：一是程序员在编码时只考虑正常场景的情况，一些异常和特殊的场景的情况都没考虑到；二是修改一个缺陷后，引出另外的缺陷。
需求分析不全、和文档问题，加起来占比6.7%，从另一方面说明项目组不重视文档及文档质量，对功能分析不透彻。
从以上可以看出，项目组需要加强文档编写质量、需求的充分评审和代码评审及走查。测试交付团队方面的问题，数据质量问题和环境的问题共占比9.8%，数据质量问题单项占到6.3%，这个比例偏高，测试团队应该管理好测试数据的质量，以免由于不合规的数据浪费大家的时间和精力。
环境问题，交付团队应该在项目或是版本开始时，测试环境的配置与生产环境的配置一致，以保证测试版本的有效性，在部署时，需要与测试团队先做沟通，避免一些没有必要的环境问题。
从缺陷发现的阶段分析
测试分析阶段处于测试人员对需求文档、概要设计文档的评审（评审包括文档的测试和评审会），这个阶段的缺陷数，主要由文档问题、评审问题组成。
测试执行阶段包括冒烟测试、第一轮、第二轮和回归测试。在这个阶段，测试团队对整个项目或是版本做全面的测试，用各种测试方法来验证项目或版本是否符合上线标准。
冒烟测试：只对项目或是版本做主流程的验证。
回归测试是对项目或是版本做全面的回归测试，包括第一或第二轮测试过程中，本来测试通过的用例，再加上此次未改造的功能。
补丁测试，指的是在项目或版本已经定版后，仍存在非改不可的，影响流程性的缺陷。
各个阶段出现的缺陷数量，也可以分析项目组或是测试团队在哪个阶段是否有问题。
从缺陷的引入系统上分析
缺陷数已按等级进行换算：
系统2和系统3的改造量排名第一和第二，难道就证明了改造量大的，出的缺陷就多吗？
也不是，像系统4的改造量只是比系统3少了10%，但缺陷数却少了3分之一。
虽然系统与系统之间的缺陷没有什么可比性，但如果加上各个系统的开发工作量，计算出各个系统的缺陷密度，虽然可比性的不大，但是以整体来看项目组的程序质量来说，这样子有一定的可比性了。
缺陷密度以1为基准，缺陷密度高于1的系统，可能需要分析一下程序的质量，看问题出在哪里。
从测试漏检上分析
此次项目上线运行一个月内，生产上出现的故障数量如上表所示。从上面可以看出，测试团队在漏检的问题上占了3个，是总故障数量的一半，且测试分析遗漏一个，用例遗漏一个，而执行还遗漏了一个，这说明测试团队的内部存在流程或沟通的问题。需要测试团队进行分析具体的原因。
总结
以上从各个方面来分析项目或版本的缺陷，都是希望从各种渠道来了解项目组和测试团队的情况，分析是否他们存在内部规范或是流程上的问题，需在哪一方面做进一步改进措施。
除此之外，还能收集各团队的项目指标，与公司的基准数据做对比，看是否与之相匹配，是否存在改进的方面，能以更好的姿态去迎接下一次挑战。
版权声明：本文出自51Testing会员投稿，51Testing软件测试网及相关内容提供者拥有内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
