软件测试之软件缺陷管理

什么是软件缺陷

标准的定义：从产品内部看，缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题；从产品外部看，缺陷是系统所需要实现的某种功能的失效或违背

软件缺陷的生命周期

一个缺陷的正常生命周期是 新建（提交）--打开（确认）--修复--测试验证，通过就关闭，没有通过就重新打开，继续修复和验证。

缺陷状态

软件缺陷的常用指标

部分常用指标	描述
缺陷率（缺陷数量/规模）	一方面作为对开发人员的考核，另一方面用于分析开发过程的bug原因分析及预防
缺陷密度（发布缺陷数/总缺陷数）	主要用于分析产品发布的过程改进，如果这个数据过大，说明我们的放行标准过低，如果这个数很低，说明我们的放行标准过高，事实发布后是允许存在bug的，那么如何改进发布放行，就必须用这个数据来度量
缺陷修复时效	对于不能等级的缺陷修复的时效要求不同，一般用于考察开发是否及时反馈问题
缺陷验证时效	考察测试人员是否及时验证缺陷的解决情况
拒绝率	考察测试人员提交的BUG质量
重复打开率（重复打开的BUG数量/BUG数量）	考核开发人员的对于BUG的自测情况
缺陷类型分布报告	缺陷类型分布报告主要描述缺陷类型的分布情况，看缺陷属于哪些类型的错误。这些信息有助于引起开发人员的注意，并分析缺陷为什么会集中在这种类型
缺陷区域分布报告	缺陷区域分布报告主要描述缺陷在不同功能模块出现的情况，这些信息有助于开发人员分析为什么缺陷会集中出现在某个功能模块。例如，如果缺陷主要集中在单据的审批过程中，那么就要分析是否是审批流程调用的工作流接口设计不合理
缺陷状态分布报告	缺陷状态分布报告主要描述缺陷各种状态的比例情况，例如Open、Fixed、Closed、Reopen、Rejected、Delay的Bug分别占了百分之多少。这些信息有助于评估测试和产品的现状
缺陷趋势报告	缺陷趋势报告主要描述一段时间内的缺陷情况。如果项目管理比较规范，缺陷管理和测试流程比较正常的话，缺陷趋势报告还可以用来估算软件可发布的日期

软件缺陷怎么管理

bug管理的目的

1.保证每个缺陷都被修改

2.保证每个缺陷都被回归

3.缺陷的完整性和一致性

4.避免纠纷，降低沟通成本

缺陷管理的意义

1.提高工作效率（BUG分类，状态负责人）

2.记录唯一的缺陷信息，保证BUG完整一致（通过设置权限实现）

3.记录中间环节，是BUG可追溯

4.为测试报告提供数据

软件缺陷管理流程

  BUG跟踪流程：1.测试人员拿到最新软件版本，执行测试；2.发现BUG并记录到BUG管理平台；提交BUG报告或测试报告，邮件抄送开发人员；3.开发人员得到最新BUG并修复BUG（如复杂问题，进行专家评审如何处理）4.修复BUG后把新代码Check in到源代码服务器；5.Buider人员会进行版本编译并提交到发布版本服务器；6.测试人员开始执行新的一轮测试任务。

  缺陷跟踪目的：1.保证BUG得到有效的跟踪和解决，使每一环节都有相对应责任人负责。2.进行缺陷分析和产品度量。

  软件缺陷分析

  •缺陷分析就是分析缺陷在与缺陷关联关系的一个或多个参数值上的分布。缺陷分析提供了一个软件可靠性指标

  •主要参数•状态：缺陷的当前状态（打开的、正在修复或关闭的等）。•优先级：必须处理和解决缺陷的相对重要性。•严重性：缺陷的相关影响。对最终用户、组织或第三方的影响等等。•起源：导致缺陷的起源故障及其位置，或排除该缺陷需要修复的构件

常见的Bug跟踪管理软件：禅道、Jira、企业内部管理软件

BUG描述的注意事项

1一定可以重现的BUG可以不写“重复几次操作，出现几次，我认为，标题里不能写步骤，不能用主观的话描述，我在。。。。的，不确定语句：某些好像，禁止使用”之后”，然后之类的语句”之类的话

2需求规格说明书以外的错误可以当建议报告，不当BUG报告，开发可以改，也可以不改

3若是随机出现的BUG，要写出操作几次，出现几次

4若被测软件是跨平台软件，要写上在其他平台下无误

5禁止写冗余的操作的步骤。常识性的步骤不用写进缺陷操作步骤

6写明环境数据，如何选择数据，数据如何被破坏

缺陷难以复现怎么办

问题1： 复现不了的问题
a. 昨天必现的问题、今天复现不了；
b. 生产环境必现的问题、测试环境复现不了；
c. 测试人员必现的问题、开发人员复现不了；
d. 一套环境必现的问题、另一套环境复现不了；

问题2： 自己的问题复现不了
A：发现的问题很多，也很严重，最终复现不了需要攻关解决、降级处理的也不少
B : 提交问题比A可能稍少也可能多，大部分问题在提交之前就分析的很透彻，甚至点出了问题的原因、出现的条件和场景，最终问题全部高效、及时的得到了解决。

出现以上问题的原因是什么？如何解决？下面一步一步说。

一、出现上述问题的原因
经过这些年工作的积累，以及与各领域测试同行的交流，问题复现不了的原因不外乎下面几个：

绩效导向，提单量影响绩效考核
问题是伴随出现的，不知道何时出现、如何出现的
你觉得你知道了根本原因，实际上你不知道
系统日志记录不完善、或者根本没有打开
测试过程全程无记录
问题单缺乏关键信息
高并发、多线程、异步调用复现概率低的问题
黑天鹅问题

二、解决问题的思路

1. 绩效导向问题
很多公司，问题单提单量是绩效考核的很大一部分，甚至占到了90%或更高，这就导致了比较奇葩的现象：问题单提单量高，解决率却很低。这么说有点诛心的味道，实际工作中怀揣这种想法的人其实非常少，这种结果是特定的考核机制下自然形成的，很多身处其中的人可能并没有意识到。

跟我们平常说的上有政策、下有对策是一致的，比如二套房，大家排队离婚。
姿势： 高大上的价值观引导，绩效考核方式是落实测试价值观的手段
a. 提交问题的目的，是为了解决问题，提升用户的使用体验。这样测试人员不仅会从技术角度分析产品的实现，还会从易用性等各个角度去衡量产品。
b. 测试的乐趣在于发现问题、定位问题的过程。一般喜欢打探小道消息、对问题刨根究底的人，测试都做的特别好。
 

 现在很多公司已经调整了绩效考核的指标，比如阿里同学，重点考核的是上线发布后产品的质量、测试的效率、个人的成长。虽然最后一点有点虚，但是从现在阿里系出版的技术作品看，价值观引导确实做得好。

问题数量可以作为产品质量评价的一个数据，去衡量产品的质量，但前提是有代码缺陷密度等基线数据作为支撑，而不能拍脑袋。

2. 伴随出现的问题
执行测试时都有明确的目的性，这个用例测试的目的是什么，怀疑会出现什么样的现象。出现计划内的问题，是很容易复现和定位的。但伴随出现的问题，你一般不能第一时间抓住它，直到它产生了破坏作用，才能感知到问题的存在。它是在何时因为什么操作出现、什么事件触发的，不知道。这类问题就比较容易演化为难复现问题。

姿势：
保持冷静，不要激动，保持现状
思考一下：你对它做了什么？为什么这样？ 他们两个什么关系（可能没关系）？ 可能在什么地方、什么操作、什么事件触发的？
想明白了吗？想不明白叫别人一起想。
不管是否想明白，把操作记录、组网、数据、配置、状态全部记录下来
在不破坏环境的情况下，尝试验证想法；如果问题比较严重，考虑另搭环境验证；
想法得到验证后，简化环境验证问题，找到问题触发条件

3. 几个自作孽的问题
下面这几个问题，只要做事严谨是可以避免的：
你觉得你知道了问题原因，实际上你不知道
系统日志没开
系统日志记录不完善
测试环境、配置文件、环境数据无保留
操作过程无记录
问题单缺乏关键信息

偶发的缺陷怎么处理

在软件测试中经常会出现很多偶尔出现的缺陷，也就是说不是100%的能复现，对于这样的缺陷，该怎么处理呢？

（1） 考虑各方面的因素来判断缺陷的严重级别和优先级别。

首先判断严重级别：严重级别比较容易判断，和其他能复现的缺陷一样处理。然后判断优先级别，就需要看对用户的影响，即需要知道这个缺陷能被复现的概率，这就需要去复现这个缺陷。

怎么搜集复现概率呢，有很多种方法，可以暂缓处理这个缺陷，看后来这个缺陷是否能出现，如果从项目初期到项目结束，这个缺陷就出现一次，那完全可以忽略这个缺陷；可以刻意的安排测试员复现这个缺陷，不断重复的去复现这个缺陷，这个时候如果有开发人员来分析哪些操作容易导致这个缺陷出现，测试人员通常更容易成功复现，测试人员最好把软件连着trace来试图复现缺陷，这样如果成功复现了，就拿到有效的信息来给开发人员分析；也可以在终端用户测试的时候，让终端用户测试人员注意有没有碰到这样的缺陷，终端用户测试能最真实的模仿实际用户的行为，如果几个月的终端用户测试都没有发现这个缺陷，那大可以放心的忽略这个缺陷；相反，如果终端用户测试里频繁碰到这个缺陷，那这个缺陷对用户的影响就很大，就需要被重视。

（2）根据缺陷的优先级别决定什么时候fix这个缺陷。

这一步和常规的缺陷处理流程一样，就是开发人员去分析得到的有效信息，然后找相应的解决方案。不过需要提醒的是，通常偶尔出现的缺陷不是一个一个分析处理的，而是一批同类型的缺陷一块处理。通常会等到不可重现的缺陷积累到一定的量的时候再成批的处理。只所以这样处理，是因为如果不可重现的缺陷没有积累到一定的量，很难找出根本原因，因为每个偶尔出现的缺陷只能提供很少的一部分信息，信息量没有累积到一定的程度，就找不出根本的原因。

（3）集成fix的代码。

这一步和常规的缺陷处理流程是一样的，但是管理者需要注意，很多时候同一段fix代码解决的可能是一批偶尔出现的缺陷，这些fix代码改动通常比较大，或者改变的是底层的数据，或者是内存管理的优化等，反正都是些疑难杂症，所以不适合在重要的软件，比如，Sales candidate，上集成这些fix。

（4）验证fix是否成功，并试图验证这个fix是否有负面影响。

Fix是成功的，没有负面影响或者负面影响在可接受范围内，那这个缺陷就可以close了；如果fix不成功，或者有严重的负面影响，需要考虑是否rollback。

对于能复现的缺陷，验证fix是否成功是件很容易的事情，但是对于偶尔出现的缺陷，验证fix是否成功是件相当难的事情，因为本身缺陷就是偶尔出现的，不能复现了也不能说明fix是成功的。这依然需要长期观察、安排测试人员集中测试、或者让终端用户测试人员多注意。有时候不可复现的缺陷并不能完全fix，可能一个fix只能降低复现的概率，将到能接受的范围也是可以的，比如对于一个通话过程中经常掉话的缺陷，把复现率从百分之一降到万分之一，也是可以接受的。

通常偶尔出现的缺陷不是一个一个处理的，一般是一批一批处理的，偶然的现象联系起来，让开发人员分析，通常能发现根本原因是什么，这样对于试图复现偶尔出现的缺陷、对于开发人员分析这些缺陷、对于测试人员验证这样的缺陷的效率提高，是有很大帮助的。处理这样的问题很重要的一点是，不能因为这个问题出现的概率低，就随意的的忽略这样的问题。