测试不止是测试Bug,还有更重要的是分析缺陷！

lsekfe

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

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

上表中，根本原因中，各项内容的含义如下：
　　文档问题
　　指的是在静态测试（包括文档的正式及非正式评审）时，测试人员发现的各类文档的问题，投产手册的问题。
　　程序代码问题
　　程序存在各种的代码问题，程序未按需求功能实现等。
　　需求分析不全
　　需求分析不全面导致的部分场景或功能未实现。
　　需求变更
　　由于出现缺陷，导致需求需要变更。
　　环境问题
　　部署操作不正确；
　　参数设置没按投产手册要求执行；
　　控版出错（含：未与生产同步、未与上一个版本同步等）。
　　数据质量问题
　　不符合需求的测试数据，测试中产生的脏数据。
　　项目组的问题由程序代码问题、需求分析不全和文档问题组成。
　　其中，程序代码问题的占比是最高的，程序代码问题表现在：一是程序员在编码时只考虑正常场景的情况，一些异常和特殊的场景的情况都没考虑到；二是修改一个缺陷后，引出另外的缺陷。
　　需求分析不全、和文档问题，加起来占比6.7%，从另一方面说明项目组不重视文档及文档质量，对功能分析不透彻。
　　从以上可以看出，项目组需要加强文档编写质量、需求的充分评审和代码评审及走查。测试交付团队方面的问题，数据质量问题和环境的问题共占比9.8%，数据质量问题单项占到6.3%，这个比例偏高，测试团队应该管理好测试数据的质量，以免由于不合规的数据浪费大家的时间和精力。
　　环境问题，交付团队应该在项目或是版本开始时，测试环境的配置与生产环境的配置一致，以保证测试版本的有效性，在部署时，需要与测试团队先做沟通，避免一些没有必要的环境问题。
　　从缺陷发现的阶段分析


测试分析阶段处于测试人员对需求文档、概要设计文档的评审（评审包括文档的测试和评审会），这个阶段的缺陷数，主要由文档问题、评审问题组成。
　　测试执行阶段包括冒烟测试、第一轮、第二轮和回归测试。在这个阶段，测试团队对整个项目或是版本做全面的测试，用各种测试方法来验证项目或版本是否符合上线标准。
　　冒烟测试：只对项目或是版本做主流程的验证。
　　第一轮、第二轮测试，是执行所有的测试用例，对所有的功能做全面的验证，测试类型包括了功能测试、性能测试、可靠性测试、安全性测试、接口测试等等。
　　回归测试是对项目或是版本做全面的回归测试，包括第一或第二轮测试过程中，本来测试通过的用例，再加上此次未改造的功能。
　　补丁测试，指的是在项目或版本已经定版后，仍存在非改不可的，影响流程性的缺陷。
　　各个阶段出现的缺陷数量，也可以分析项目组或是测试团队在哪个阶段是否有问题。
　　从缺陷的引入系统上分析
　　缺陷数已按等级进行换算：


系统2和系统3的改造量排名第一和第二，难道就证明了改造量大的，出的缺陷就多吗？
　　也不是，像系统4的改造量只是比系统3少了10%，但缺陷数却少了3分之一。
　　虽然系统与系统之间的缺陷没有什么可比性，但如果加上各个系统的开发工作量，计算出各个系统的缺陷密度，虽然可比性的不大，但是以整体来看项目组的程序质量来说，这样子有一定的可比性了。
　　缺陷密度以1为基准，缺陷密度高于1的系统，可能需要分析一下程序的质量，看问题出在哪里。


从测试漏检上分析

此次项目上线运行一个月内，生产上出现的故障数量如上表所示。从上面可以看出，测试团队在漏检的问题上占了3个，是总故障数量的一半，且测试分析遗漏一个，用例遗漏一个，而执行还遗漏了一个，这说明测试团队的内部存在流程或沟通的问题。需要测试团队进行分析具体的原因。
　　总结
　　以上从各个方面来分析项目或版本的缺陷，都是希望从各种渠道来了解项目组和测试团队的情况，分析是否他们存在内部规范或是流程上的问题，需在哪一方面做进一步改进措施。
　　除此之外，还能收集各团队的项目指标，与公司的基准数据做对比，看是否与之相匹配，是否存在改进的方面，能以更好的姿态去迎接下一次挑战。