BUG分析
软件缺陷（bug）"，即为计算机软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。一般来说，软件缺陷的属性包括缺陷标识、缺陷类型、缺陷严重程度、缺陷优先级、缺陷来源、缺陷原因等。
种类型：
（1）设计不合理;
（2）功能、特性没有实现或部分实现;
（3）运行出错，包括运行中断、系统崩溃、界面混乱等;
（4）与需求不一致，在执行TestCase时则为实际结果和预期结果不一致;
（5）用户不能接受的其他问题，如存取时间过长、界面不美观;
（6）软件实现了需求未提到的功能。
软件缺陷有四种级别，分别为：致命的(Fatal)，严重的(Critical)，一般的(Major)，微小的(Minor)。
常用的软件缺陷的优先级表示方法可分为：立即解决P1、高优先级P2、正常排队P3、低优先级P4。立即解决是指缺陷导致系统几乎不能使用或者测试不能继续，需立即修复；高优先级是指缺陷严重影响测试，需要优先考虑；正常排队是指缺陷需要正常排队等待修复；而低优先级是指缺陷可以在开发人员有时间的时候再被纠正。
三种常用的技术工具供大家参考。
（1）20/80原则
80%的有效工作往往是在20%的时间内完成的，而20%的工作是在80%的时间内完成的：哪些软件缺陷是最重要的，哪些软件缺陷是最关键的。
（2）ABC法则
手边的软件缺陷并不一定就具有第一优先处理的重要性。只有正确的判断，才可将测试活动效率增加数倍。
（3）四象限原则，把软件缺陷进行分类
四个象限，然后只需记住四个字就行，那就是"轻重缓急"。"轻"，指的是相对重要但不紧急的软件缺陷；"重"，是指最重要也是最紧急的软件缺陷；"缓"，指的是不重要也不紧急的软件缺陷；"急"，则是指不是最重要但却最为紧急的软件缺陷。理清这种关系之后，就算同时测试许多不同类型的软件缺陷，也会很快清楚哪些软件缺陷是必须马上完成；
软件缺陷的三种基本状态：
（1）激活状态(Active或Open)。
（2）已修正状态(Fixed或Resolved)。
（3）关闭或非激活状态(Close或Inactive)。
三、软件缺陷分析产生原因及分类
软件缺陷分析产生原因主要有三方面：技术问题，团队合作，软件本身。
从测试观点我们将软件缺陷分为五类，分别为：功能缺陷，系统缺陷，加工缺陷，数据缺陷，代码缺陷。
四、软件测试心理学问题
（1）程序测试的过程具有破坏性。
（2）程序员应避免测试自己的程序。
（3）程序设计组织不应测试自己的程序。
bug预防策略
发现bug，找出bug的根源，然后寻找一个方法来预防类似的bug在将来出现
1) Bug发现和初步分析
QC工程师的一个重要职责就是试图发现bug的根本原因。QC小组在检验产品质量时，不应该将产品看作一个黑盒，而应该像开发人员那样了解产品的内在，包括深入源代码，理解产品的设计和实现。这些能力都是QC小组开始bug分析的基本要求。
(2) Bug修订和进一步分析
一如既往，发现一个bug之后，开发人员应该负责处理它。但是，如果bug的发现过程包含了bug根本原因的初步分析，那么关于如何解决这个bug，开发人员可能拥有了更多的信息。虽然这不是QC工程师bug初步分析的目的，但是它可能为开发人员提供了更多的观点。除了修正缺陷以及记录实现的具体步骤，开发人员还应该对bug进行进一步的分析。这次分析应该着眼于导致bug产生的开发情景。
(3) bug预防分析
分析的最后一步就是寻找一个预防类似错误的方法。这一方法不仅涉及到开发、QC工程师，还涉及到不直接负责代码编写的资深开发人员。
这一阶段的成果是一些有用的实践经验，开发人员可以通过这些实践预防bug而不是修正bug。
Bug预防分析是整个bug分析过程的核心。这一阶段总结出的实践可以在更广泛的范围内预防潜在的缺陷。
类似bug产生的几率却非常高。所以，尽管这一类bug是随机的，但仍然可以被预见并防止发生。
(4) 发布经验
分析得出的实践经验应该被记录并发布，这样其他的开发人员就可以通过学习这些经验避免类似的错误。一个发布经验最好的办法就是知识库。
测试缺陷分析务实篇
陷泄露率，就是有多少本阶段引入的缺陷没有在本阶段发现而是被泄露到后阶段环节才被发现。其计算公式为：缺陷泄漏率=（下游发现的本阶段的缺陷数/本阶段注入的缺陷总数）*100%。显然，它等于[1-缺陷移除率]。它反映的是本阶段质量控制措施落实的成效。
下面是一个分析例子：
以找出我们产品/项目的高危模块来。这些模块导致了我们产品的主要缺陷。主要用到的分析手段是数据透视表和柏拉图。让我们看看下面的例子：
简单的OA系统，它只有5个子系统。我们把这些子系统各有多少缺陷列出来，找到了改善质量的关键模块是后台交易模块。
这是一个较为复杂的MIS系统，有近20个功能块。这个时候，可以利用柏拉图识别出占80%问题的那少数模块，针对其采取强于其它产品组成部分的质量控制措施。
需要指出的是：采用缺陷分布只是分析的第一步。它只不过提供了你分析影响产品质量的那些重点模块，其信息不足以给出更深层次的原因。需要针对这些高危模块进行进一步的分析，识别缺陷的产生根源。
下面是一个如何运用测试分布模型进行质量预测的例子：--需要开发和测试高度一致
如果需求阶段发现了10个缺陷，就可以预计到设计阶段我大概要清除70个缺陷，依次可以估计到后阶段各个环节的缺陷数，作为我们该阶段工作的交付准则。并且，可以预测到产品发布后的使用表现会出现大约2个故障泄露到用户手中。
个项目的系统测试阶段发现的故障为例进行过程有效性回溯分析：
导致在集成测试过程中未能充分发现这些缺陷的原因主要有：
1、测试环境不具备，导致部分测试项必须到系统测试阶段才具备测试条件；
2、测试设计中某些测试项的缺失，需要加强测试设计的评审工作；
3、回归测试过程中，开发部只是对测试故障进行验证，而对bug fix波及的范围缺乏分析和验证；
对这些分析结论，我们就可以制定针对性的整改措施。如：
- 加强开发部的故障波及分析及波及分析验证工作；
- 项目计划中加强对测试需求的关注，提前采购和协调必要的测试环境；
- 每次回归对泄露的缺陷开发部都作相应的复盘，并根据复盘结果，完善单元测试和集成测试的测试设计；
- 利用缺陷分类来进行缺陷的根源分析
对于测试出来的BUG进行缺陷分类，按照BUG的类型分布，找出那些关键的缺陷类型，进一步分析其产生的根源，从而针对性的制定改进措施。
下面以一个项目的系统测试故障为例进行分析：
从系统测试故障来看，有较多故障是由接口原因造成的，细分有以下几种原因：
1、跨项目间的接口，接口设计文档的更改没有建立互相通知的机制，导致接口问题到系统测试时候才暴露出来；
2、部门内部跨子系统的接口，由于本项目设计文档按功能规划编写的，而不是按照产品组件，一般由主要承接功能工作的组编写该文档，接口内容可能不为其他开发组理解并熟悉，导致因接口问题而出错；
3、系统设计基线化后，更改系统接口，没有走严格的变更流程，进行波及分析，导致该接口变更只在某个子系统中被修改，而使错误遗漏下来；
那么我们可以针对性的制定改进建议：
1、对接口文档的评审一定要识别受影响的相关干系人，使他们了解并参与接口设计的把关；
2、对基线化的接口设计文档的变更一定要提交变更单给ＣＣＢ决策，并做好充分的波及影响分析，以便同步修改所有关联的下游代码；
3、概要设计文档按子系统规划，详细设计文档按模块规划，通过相关组参加评审协调接口设计；
缺陷趋势就是将每月新生成的缺陷数、每月被解决的缺陷数和每月遗留的缺陷数标成一个趋势图表。一般在项目的开始阶段发现缺陷数曲线会呈上升趋势，到项目中后期被修复缺陷数曲线会趋于上升；而发现缺陷数曲线应总体趋于下降；同时处于OPEN状态的缺陷也应该总体呈下降趋势，到项目最后，三条曲线都趋向于零。如：
项目经理会持续观察这张图表，确保项目健康发展，同时通过分析预测项目测试缺陷趋于零的时间。在一定的历史经验的基础上分析使用这一图表会得到很多有价值的信息，比如说，可分析开发和测试在人力资源的配比上是否恰当，可以分析出某个严重的缺陷所造成的项目质量的波动。对于异常的波动，如本来应该越测试越收敛的，却到了某个点，发现的故障数反而呈上升趋势，那么，这些点往往有一些特殊事件的发生。如：
- 在该时间段送测的回归版本增加了新的功能，导致缺陷引入；
- 该回归版本开发部没有进行集成测试就直接送测？等等。
1、ODC缺陷分析：由IBM 的waston中心推出。Phontol.com将一个缺陷在生命周期的各环节的属性组织起来，从单维度、多维度来对缺陷进行分析，从不同角度得到各类缺陷的缺陷密度和缺陷比率，从而积累得到各类缺陷的基线值，用于评估测试活动、指导测试改进和整个研发流程的改进；同时根据各阶段缺陷分布得到缺陷去除过程特征模型，用于对测试活动进行评估和预测。Phontol.com上面回答中涉及到的缺陷分布、缺陷趋势等都属于这个方法中的一个角度而已。
2、Gompertz分析：根据测试的累积投入时间和累积缺陷增长情况，拟合得到符合自己过程能力的缺陷增长Gompertz曲线，用来评估软件测试的充分性、预测软件极限缺陷数和退出测试所需时间、作为测试退出的判断依据、指导测试计划和策略的调整；
3、Rayleigh分析：通过生命周期各阶段缺陷发现情况得到缺陷Rayleigh曲线，用于评估软件质量、预测软件现场质量；
4、四象限分析：根据软件内部各模块、子系统、特性测试所累积时间和缺陷去除情况，和累积时间和缺陷去除情况的基线进行比较，得到各个模块、子系统、特性测试分别所位于的区间，从而判断哪些部分测试可以退出、哪些测试还需加强，用于指导测试计划和策略的调整；
5、根本原因分析：利用鱼骨图、柏拉图等分析缺陷产生的根本原因，根据这些根本原因采取措施，改进开发和测试过程；
6、缺陷注入分析：对被测软件注入一些缺陷，通过已有用例进行测试，根据这些刻意注入缺陷的发现情况，判断测试的有效性、充分性，预测软件残留缺陷数。Phontol.com在06年软件评测师考试中有一题就是考这个思路，参见这个帖子我的回复：http://bbs.51testing.com/thread-114979-1-1.html
7、DRE/DRM分析：通过已有项目历史数据，得到软件生命周期各阶段缺陷注入和排除的模型，用于设定各阶段质量目标，评估测试活动。
至于缺陷预防，基本上是两个方面：
1、测试活动尽量提前，通过及时消除开发前期阶段引入的缺陷，防止这些缺陷遗留并放大到后续环节；
2、通过对已有缺陷进行分析（例如上面的ODC分析等），找出产生这些缺陷的技术上不足和流程上不足，通过对这些不足进行改进，防止类似缺陷再次发生。
作为一名测试人员，最大的成就就是像福尔摩斯一样，利用超强的观察力，严密的逻辑推理能力，迅速找出软件的"罪犯"，将其绳之以法。可是在成为"福尔摩斯"之前，观察力、逻辑推理能力，是需要不断训练的。这篇文章实际就是软件测试的"犯罪心理学"(初级版)：利用软件缺陷数据，对缺陷进行分类汇总，计算缺陷分析指标，进而发现软件生命周期的各个阶段的不足，制定相应改进方法，增强软件过程人为活动的规范性，最终目标提升软件交付质量，提升测试效率
一、缺陷管理库
缺陷管理库记录了缺陷相关的资料，为缺陷分析提供了详细的信息，而只有正确的信息，才能保障正确的分析结果。
1.1 缺陷定义
软件缺陷是指在产品说明、设计、编码阶段中的任何不足。一般要求将需求评审、设计评审、代码检查、测试、项目组内部发现、用户反馈等几种手段发现的缺陷都统一记录在缺陷跟踪系统中，进行统一管理、统计。而目前很多项目缺陷跟踪系统中往往只包含了测试阶段的缺陷统计，在此基础上的缺陷分析势必存在局限性。
1.2 缺陷信息
为了便于缺陷定位、跟踪和修改，需要收集尽量多的有效信息，比较常见的缺陷信息如下：
- 缺陷描述
- 被测产品信息：比如App名称、版本号
- 测试环境：wifi、数据网络、测试环境、生产环境
- 测试机型：机型、系统版本号
- 测试步骤
- 预期及实际结果
- 复现概率
- 测试辅助信息：截图、视频、日志
- 缺陷状态
- 缺陷优先级：标识处理和修正软件缺陷的先后顺序指标
- 缺陷严重程度
- 缺陷发生的组件
- 缺陷创建时间
- 缺陷发现人
- 缺陷责任修改人
- 缺陷修复时间
- 缺陷产生原因
在提交缺陷时，需要遵循以下5个原则：
- 准确性：缺陷每个组成部分描述准确，不会产生误解
- 完整性：复现该缺陷完整的步骤、截图、日志
- 一致性：按照一致的格式书写全部缺陷信息
- 简洁性：只包含必不可少的信息，不包括任何多余的内容
- 清晰性：每个组成部分的描述清晰，易于理解
这一步其实可以理解成培养测试人员的观察能力，信息收集能力。只有不断观察、收集正确信息，才可以为后续的侦查做好准备工作。
二、缺陷分析
缺陷分析是在形成缺陷管理库的基础上，对缺陷进行宏观及微观纬度的分析。通过缺陷分析，发现各种类型缺陷发生的概率，确定缺陷集中的区域，明确缺陷的发展趋势，追踪和分析缺陷产生的原因。在此分析基础上，对软件生命周期中各个角色、项目流程做改善和优化，提高软件测试质量，提升测试效率。
缺陷分析仅仅是一种手段，而非最终目的。利用缺陷分析结论，反思和回溯缺陷产生的各个阶段，思考如何避免类似问题，不再踩坑，在下次测试中得到提升，才是我们想要的结果。同样的，缺陷分析的成果是一个持续改进优化闭环的过程，它是测试人员潜移默化中测试能力的提升，也是项目流程中各个角色共同保障产品质量意识的推动。例如缺陷分析发现很多需求缺陷是到测试阶段才发现，那么就有必要加大需求评审力度；缺陷分析发现开发修复缺陷引入新缺陷比例很高，那么开发团队在修复缺陷的时候要考虑到对周边区域的影响，并且要通知相关区域的专家加强代码审查。当然测试团队也要尽可能多的在相关区域做一些回归测试。大家可以结合自身项目来利用缺陷分析优化项目实践。
三、宏观缺陷分析技术
宏观缺陷分析是指对缺陷信息进行分类和汇总，利用统计的方法计算分析相关指标，编写缺陷分析报告的活动。宏观缺陷分析的方法很多，这里主要关注缺陷发展趋势分析、缺陷分布状况分析、缺陷注入-发现分析。
3.1 缺陷发展趋势分析
项目管理中一项非常重要但十分困难的工作就是平衡进度、质量和成本。测试人员可以提供缺陷提交、缺陷修复的趋势图表，帮助管理者从中发现一些简单的缺陷发展趋势（这种缺陷可以是本文论述的广义缺陷发现手段确定的，也可以是单纯的测试手段发现的），从而了解软件质量趋势。
这里给出一个常用的分析图，x轴代表时间，y轴代表以下四种类型缺陷的数量：
- 发现数：累计的所有被发现bug的数量
- 关闭数：累计的所有被关闭bug的数量
- 日（期）发现数：当日（期）发现的缺陷数量
- 日（期）关闭数：当日（期）关闭的缺陷数量
图1：缺陷分析发展趋势图
3.2 缺陷分布状况分析
3.2.1 缺陷严重程度分布
缺陷严重程度度量有助于识别不同严重程度缺陷在所有缺陷中的比重，有助于开发测试人员资源的计划和分配。
这里给出一个常用的缺陷严重程度分析图，x轴代表时间，y轴代表各严重级别的缺陷数量。
图2：缺陷严重程度分布图
通过缺陷严重程度图表，分析各严重程度缺陷发现趋势，判断产品质量是否趋于稳定。如果高严重程度的缺陷大量增加通常意味着产品质量出现问题。
3.2.2 缺陷模块分布
按照缺陷对应的产品组成部分来汇总缺陷数据，利用这样的分布，可以找出我们产品高危模块，针对高危模块，调整测试策略。
3.2.3 ODC（正交缺陷分析）
正交缺陷分类法（Orthogonal Defect Classification，ODC）介绍了一种不同于大家常用的非常有效的软件缺陷分类及分析方法，它定义了八个正交的缺陷属性用于对缺陷的分类。所谓正交性是指缺陷属性之间不存在关联性，各自独立，没有重叠的冗余信息。
- 对于缺陷提交者，他需要给这个缺陷分配“活动（Activity）”、“触发（Trigger）”、“影响（Impact）”这三个属性。
- Activity：项目生命周期的一个阶段，该缺陷发生在该阶段，例如需求、设计、代码阶段，即缺陷发现阶段
- Trigger：可以理解成测试的手段
- Impact：对用户的影响，例如安全性、易用性
- 当一个开发人员关闭一个缺陷时，他可以分配“阶段（Age）”、“来源（Source）”、“限定符（Qualifier）”、“类型（Type）”以及“目标（Target）”这五个属性。
- Age：描述缺陷对应的代码属于新代码，旧代码，还是修复bug引入
- Source：定义缺陷来源，是自身代码问题，还是第三方代码导致
- Qualifier：指明了所进行的修复应归于缺失，错误或者还是外来的代码或者信息
- Type：缺陷真正的原因，例如初始化、算法等
- Target：描述缺陷是由于设计还是编码引入，即缺陷注入阶段
关于ODC分析方法，需要结合实际项目，对不同属性进行筛选，优化不同属性对应的值。
软件缺陷分析方法：ODC 这篇文章中详细解释了ODC各属性及对应的值。
3.3 缺陷注入-发现矩阵
利用缺陷的两个重要属性：缺陷发现阶段、缺陷注入阶段，分析缺陷数据，绘制出"缺陷注入-发现矩阵"，从中分析项目生命周期各个环节的质量，优化相关流程。
- 缺陷移除率：（本阶段发现的缺陷数/本阶段注入的缺陷数)*100%，它反映的是该活动阶段的缺陷清除能力
- 缺陷泄漏率：（下游发现的本阶段的缺陷数/本阶段注入的缺陷总数）*100%，它反映的是本阶段质量控制措施落实的成效
图3：缺陷注入-发现矩阵
如上图例子，需求阶段一共注入了34个缺陷，需求评审时只发现了4个，设计过程中发现了15个，编码和单元测试阶段发现了12个，系统测试阶段发现3个。这样，需求阶段的缺陷移除率 4/34*100%=11.76%。这个结果说明，我们需要重新审视需求评审，加大需求评审力度。另外，编码阶段的缺陷大部分依赖于系统测试发现，很显然，项目开发过程中的单元测试和集成测试活动开展不够深入。我们可以进一步分析这些系统测试出来的测试缺陷，是不是可以被更前端的评审/测试/设计讨论活动所替代。
四、微观缺陷分析技术
微观缺陷分析是指从单个有价值的缺陷入手，追踪和分析缺陷产生的本质原因。
并不是所有的缺陷都有必要去做微观缺陷分析，因此首先需要挑选"合适的缺陷"。这里给出几点建议
- 选择典型有代表性的：同类型的一系列问题
- 选择有发现难度：积累缺陷库，对测试用例做补充
- 选择有推广意义的：该缺陷很普遍，可以推广到其他业务线
- 再挑选合适的缺陷后，我们紧接着需要收集该缺陷相关的有效信息进行下一步缺陷原因分析。这些缺陷信息包括提交缺陷时信息，同时也包括和开发讨论获取的信息。
接着就是追踪缺陷产生的真正原因。网络上有很多总结的分析方法，有"望、闻、问、切"诊断法，有"5W"法，还有"探案分析法"。其实个人觉得在这一步骤中，更多需要积累经验，善于追根究底，多问为什么，多理解产品实现逻辑，产品设计思路，有了这些基础之后，合理的推理分析即可。
下面这两篇文章是非常好的结合实践总结的微观缺陷分析，大家可以通过他们的分析积累经验。
如何做好软件缺陷管理的分析和复现
一、软件缺陷报告包含的内容
1、报告编号：为了方便对缺陷进行管理，每个缺陷必须赋予一个唯一的编号，规则根据需要和需求进行制定；
2、标题：标题用简单的方式可以传达缺陷的基本信息，标题应该简短并尽量做到唯一，因为这个缺陷可能在以前的版本修改过；
3、报告人：缺陷报告的原始创造人，有时也应该包含报告的修订者；
4、报告的日期：首次报告的日期。让开发人员知道创建缺陷报告的日期是很重要的，因为这个缺陷有可能在以前的版本有改过；
5、程序或组件的民称：可分辨测试对象；
6、版本号：测试可能跨越多个版本的软件，提供版本信息可以方便对缺陷进行管理；
7、配置：发现缺陷的软件和硬件配置。如操做系统类型、是否用游览器、处理器的类型和速度；
8、缺陷的类型：如代码错误、设计你问题和文档不匹配；
9、严重性：描述报告的严重性；
10、优先级：由开发人员或管理人员确定；
11、关键词：使用关键词以便分类查找缺陷报告；
12、缺陷描述：对发现的问题进行详细描述
13、重现步骤：这些步骤必须是有限的，并且描述的信息足够读者知道正确的执行就可以重现报告的缺陷；
14、结果对比：在执行了重现步骤后，将期望结果与实际结果进行对比
下面是一个软件缺陷模板
二、缺陷的严重性和优先等级
1、缺陷的严重性
0级（致命）：最严重等级，缺陷导致系统任何一个主要功能完全丧失、用户数据受到破坏、系统崩溃、悬挂、死机等；
1级（严重）：系统的主要功能部分丧失、数据不能完全保存，系统的次要功能完全丧失，系统所提供的功能或服务收到明显影响；
2级（一般）：系统的次要功能没有完全实现，但不影响用户的正常使用。例如，提示信息不太准确；或用户界面差、操做时间稍长等问题；
3级（微小）：操作者不方便或遇到麻烦，但不影响功能的操做和执行，如字体不美观、按钮大小不很合适、字体排列不对齐等一些小问题。
2、缺陷的优先级
立即解决（p1级）：缺陷导致系统几乎不能完全运行、使用，或严重妨碍测试的执行，需立即修正、尽快修正；
高优先级（p2级）：缺陷严重，影响测试，需要优先考虑修正，如不超过24小时修正；
正常排队（p3级）：缺陷需要修正，但可以正常排队等待修正；
低优先级（p4级）：缺陷可以在开发人员有时间的时候被修正，如果没时间可以不修正。
三、软件缺陷的生命周期
缺陷的生命周期可以简单地表现为：打开（open）—修正(fixed或solved)—关闭（close）
软件缺陷状态的描述：
打开/激活：缺陷的起始状态，或重新打开的状态。问题存在或依旧没有解决，等待修正，如新报告的缺陷、补充完整信息后在打开；
已修正：已经被开发人员检查、修复过的缺陷，通过单元测试，认为及解决但还待测试人员验证；
关闭/非激活：测试人员验证后，确认缺陷不存在的状态；
无法解决：由于技术原因或者第三方软件的缺陷，开发人员目前不能解决的缺陷；
延迟：这个缺陷不严重，被推迟修正，可以在下一个版本解决；
功能增强：该问题符合 当前的设计规格说明书，但有一个待改进问题；
不是缺陷：开发人员认为不是问题，十年测试人员的误报缺陷；
不能再现：开发人员不能复现这个软件缺陷，需要测试人员检查缺陷复现步骤；
需要更多信息：开发不能复现这个软件缺陷，但开发人员需要一些信息，例如：缺陷的日志文件、图片等。
