测试人员基本功：缺陷报告

什么是Bug？

一只虫子爬进主机引起短路的这个事件（不知道的可以咨询百度），让我们知道了软件缺陷被称为“Bug”的原因，而我也一直以为缺陷就是bug。

那缺陷又是什么呢？
还是看上面的这个例子，真正的缺陷是计算机维护工程师提出来的那个问题：在主机的散热孔那里可以加装一层更加细密的金属网，既不影响散热，又可以防止虫子爬到主机里。这是计算机设计人员疏忽的地方，是产品真正的缺陷。而虫子引发的那个故障只是这个缺陷导致的故障的其中一种表现形式。也就是说，Bug是缺陷的一种表现形式，而一个缺陷是可以引起多种Bug的。
所以缺陷和bug是一对多的关系，弄清楚这层关系了接下来我们就来看看缺陷报告。

缺陷报告是测试人员日常工作中的一部分，每天都要进行，有时可能一天要报上三四十个，因此缺陷报告的质量就显得特别重要，直接关系到缺陷修正的速度、开发人员的效率。

缺陷报告本身的质量将直接关系到缺陷被修复的速度以及开发工程师的效率，同时还会影响测试工程师的信用、测试与开发人员协作的有效性。

好的缺陷报告绝对不是大量信息的堆叠，而是以高效的方式提供准确有效的信息

缺陷报告的描述

一份有效的缺陷报告要素通常包括：标题、前提、测试环境、操作步骤、实际结果、期望结果、出现的频率、优先级、严重等级、附件（一般是图片形式）。
另外还会有一些附加信息，如测试人员、开发负责人等。

结合我司的报告内容说明下

1.png

• 标题：简明扼要，无歧义
  通常采用“在什么情况下发生了什么问题”的模式”
  比如 “用户不能正常登录”、“搜索功能有问题”、“用户信息页面的地址栏位置不正确”等，这样的描述会给人“说了等于没说”的感觉。很容易引发开发工程师的反感和抵触情绪，从而造成缺陷被拒绝修改（reject）。同时，还会造成缺陷管理上的困难以及过程的低效。

• 优先级 Priority（4个等级）：软件被修复的紧急程度
  1--立即解决：缺陷导致系统几乎不能运行使用 或 严重妨碍测试的执行（需立即修改）
  2--高优先级：缺陷严重，影响到测试了（当天或第二天要及时解决的）
  3--正常：一般错误
  4--低优先级：可以在开发有时间的时候处理，如页面文本框对齐显示

• 严重等级 Severity（4个等级）：缺陷引起的故障对用户使用系统的影响
  1--致命的：主流程不通，导致系统功能缺失、用户数据被破坏、系统崩溃、死机
  2--严重的：影响流程的 比较严重的，比如系统主要功能部分未实现
  3--一般：系统的次要功能没有完全实现，但不影响用户的正常使用
  4--较小：操作不方便或遇到麻烦，但不影响功能的使用，如字体不美观、按钮大小不合适、文字排列对齐等（属于建议性或者美观方面的）

一般来说，缺陷越严重，优先级越高，但也有例外：
1）从用户角度看，缺陷不是很严重，但可能影响到测试执行了（优先级高严重等级低）
2） 有些缺陷比较严重，但由于技术的限制，暂时没法修改。这时优先级就降低了

• 附件
  有时候，用文字很难清楚描述缺陷，此时用图片（画笔指明问题）就很直观了
  常见的有见的附件有界面截图、测试用例日志、服务器端日志、GUI 测试的执行视频等。

如何有效的报告缺陷？

• 单一准确：每个报告只针对一个缺陷，如果有多个缺陷，可能开发只修正了其中一个，其他的没有得到修改，加长了缺陷的生命周期

• 可以再现：不能忽视或省略任何一项操作步骤，特别是关键性的操作，如描述的不够清楚，RD就会过来沟通怎么操作的，浪费了大家的时间

• 完整统一：完整的描述信息

• 短小简练：使用关键词

• 特定条件：有些问题只在特定环境下存在
  1）win7使用某个功能时提交审批时失败，而win8、win10都正常的
  2）IE 文本框搜索有问题，其余浏览器正常
  特定环境报错举例如下图所示：

特定环境报错举例.png

缺陷的生命周期

状态：Active（激活） ——> Resolved（已修改） ——> Closed（关闭）

软件缺陷生命周期.png

而我们在实际工作中会遇到各种各样的情况，过程有时比较复杂，如：

• 不是每个bug 都能及时得到修改，可能由于时间关系或者技术问题，需要延到下一版本中去修改
• 有些描述不清楚，RD看不懂或不能再现，将bug打回
• 有些RD修改了（状态变为Resolved），测试人员验证后，发现bug依旧存在，没有得到彻底的处理，又将bug状态标注为Active

并不是所有的bug都能被及时修复，所以很多bug会被关闭，一般原因有：

• Cannot Reproduce（不能再现）
• As Designed（设计如此）
• Deferred（推迟）
• Duplicate（重复提交）
• Fixed（已处理）
• Obsolete（现在已经不存在的bug）
• Not a bug（RD认为不是问题）

常见Bug类型

代码错误、界面优化、设计缺陷、配置相关、安装部署、安全相关、性能问题、需求问题、测试脚本、其他。

一般以下地方为bug多发区：浏览器兼容性及按钮操作、字符编码、页面跳转、跨域、性能

如何重现在线Bug？

• 充分利用各种测试手段复现
  尽最大努力来还原当时的场景：环境，数据，前置条件及测试步骤等
• 服务器端问题，看log
• 前端问题，督促开发加上报警机制
• 时间允许情况下，寻求开发协助

具体可以阅读老徐公众号文章
https://mp.weixin.qq.com/s/GoUXk8gih_M78A3q2EK-OQ

对于线上发现的Bug，如果没有分析流程，测试人员需要制定线上Bug的分析流程，先重点分析这个线上Bug产生的原因、线上Bug的影响范围，然后与PM、RD一起决定可以有哪些改进措施可以避免同类线上Bug再犯。

bug很严重，影响了版本的发布时，测试人员要再次确认用例设计的覆盖度及周密性
对于测试而言，用例设计的覆盖不够，不够严谨就会导致bug
有两种情况：
1）原本用例就没有好好设计过，未经评审过，测试时就很随意
补救措施：赶紧把用例好好琢磨琢磨，再叫上项目相关人员进行评审，这么做的目的也是为了保证测试用例得到了项目相关人员的认可，各种情况大家都讨论过，保证在需求上大家的一致性，保证软件覆盖度能满足本次项目需求的要求，做到需求100%覆盖，开发人员若再提出更多建议，那也可以弥补一些黑盒测试时可能遗漏的情况
2）该项目已经经过严格的需求评审及用例评审了，当然，即便如此也不能避免测试过程中漏测以及对特殊情况的考虑。

当我们绞尽脑汁，bug仍然不能复现时，需保持关注，若通过项目组决定不影响版本发布，那么在发布后验证时也需要重点关注。而且该bug不能关闭，依次往以后版本中顺延，并且每轮测试时都要尝试再次复现。
那何时可以关闭呢？也许3，5个版本发布后，没有出问题就可以决定关闭它了。

缺陷分析

测试完成之后，我们需要对缺陷进行一次分析，可以更好的了解整体的测试效率、RD修复的效率等，图表形式有很多种，如下是我公司目前在用的

bug trends1.png

bug trends2.png