测试大家谈 - 提Bug与提好Bug

城下秋草

于 2024-10-12 15:30:00 发布

阅读量2.8k

点赞数 76

分类专栏：分享测试流程文章标签： bug 测试功能测试 jira

本文链接：https://blog.csdn.net/danmyw/article/details/142872720

版权

分享同时被 2 个专栏收录

12 篇文章

订阅专栏

测试流程

9 篇文章

订阅专栏

前言

作为测试工程师最重要的工作产出，Bug Report（或者故障单、问题单）是测试工程师工作成果的直接体现，也是最能呈现测试工程师价值和能力的输出物。但项目干系人甚至测试工程师本身对Bug Report的重要性往往认识不足，Bug 单的内容及其提交方式、处理流程对项目推进、运作效率甚至团队士气都有重要影响。

行业针对 Bug Report 的讨论和总结还比较少，本篇我们希望以笔者多年的从业观察出发，对 Bug report 的要素及专业测试工程师的处理方式给出一些总结和建议，意在抛砖引玉，错漏之处还请多多指正。

主要包含以下内容：

Bug 是什么，Bug 报告单是什么
开发或项目团队看到 Bug 实际希望获取的信息是什么
测试小白在提 Bug 时的常见错误做法
提 Bug 与说故事
专业测试工程师如何高质量地提交 Bug

何为Bug？ Bug的历史

Bug 一词在英文中本是虫子，臭虫之意，现在 IT 行业用它来代指软件中存在的缺陷，其实这个历史还比较有意思：

早在 1878 年，大发明家爱迪生就在给朋友的信中就用 bug 一词代指过电子电路中的故障（或可能导致故障的原因），但是真正在计算机行业载入史册还要到 1947 年 9 月 9 日。

这时第一批写程序的程序员们正在哈佛大学研发 markII 计算机，其中 [Grace Murray Hopper][1] 在查找一个问题时，在中继器触点旁发现了一个飞蛾，用日志本拍死了它，并标记它为“第一个找到 bug 的真实案例”。由此 bug 一词便被用来代指计算机中的缺陷或故障。相应地 debug 则被用来指代去除故障的调测行为。

下图即保存在美国管家博物馆的史上第一个 bug 实物：
在这里插入图片描述

史上第一批程序员，其中唯一的女性就是“虫”母：
在这里插入图片描述

总之，现在 Bug 一词可以代指软件或程序中存在的缺陷或者故障。但对于项目团队来说，建议不要简单地将 Bug 定义成故障，因为故障一词定性上有否定的意味，而将 Bug 视作缺陷、或者问题，强调可改进空间对项目团队更加有积极的引导作用。

Bug Report （问题单）是什么?

report 这个词在英文中既可作动词也可作名词。所以 Bug report 既可表示发现问题并报告的这个动作，也可以指问题发现后提交的报告内容。这里我们一般还是将它看作是问题报告(名词)，即 问题单，那么问题单到底是什么呢？

测试大神 Cem Kaner 曾指出:

The purpose of testing is not to find bugs. The purpose is to get bugs fixed.

测试的目的不是发现 Bug, 而是使 Bug 被修复。

这个观点其实指出了很多测试人员认识上的一个误区，就是觉得测试工作就是尽可能多地发现 Bug。其实对团队来说，发现的 Bug 再多，最终还是要解决掉才能体现这些 Bug 被发现的价值。

而从发现到被解决， 问题单 是其中的主要媒介，既是测试人员测试工作的输出，又是开发人员解决问题的输入，重要性不言而喻。

另外，虽然将发现的问题知会给开发人员有各种形式：口头告知、实际演示、电子邮件、IM聊天等等都可以起到知会的作用。但在现代软件研发过程中，一般还会有专门的系统来进行缺陷追踪，如 JIRA、禅道、bugfree、QC（HP quality center）等软件都能进行缺陷的提交和跟踪。通过这些专门的系统，不仅能够起到记录和反馈的作用，还能够通过统计和分析更好地反映出项目整体的质量状况和研发进展。

因此：

问题单 是测试人员测试活动中发现缺陷后的输出
问题单 是开发人员解决缺陷的输入
问题单 是测试人员和开发人员之间针对 Bug 的沟通媒介
问题单 还是项目团队评估当前研发状态和产品成熟度的指示器。

问题单的作用和重要性

相信很多测试工程师在提交问题单后，都有得到如下一些反馈或抱怨的经历：

你这个问题单到底想说明啥？
在我这里运行没有这个问题
为什么你提交的这个算是缺陷？
一般人不会像问题单那样使用软件，脑子有问题的人才会那样用
这个确实是问题，但是修复成本太大，而且也可以换种操作方式来规避
你虽然认为这是个问题，但是实际用户不会觉得不好
你提交的虽然确实是问题，但是影响用户很小。那些影响用户更大的部分为什么看不到多少问题单？

…

测试人员当然不希望得到这样的反馈。但这些问题也从侧面反映出在对待 Bug 这件事上，开发人员或项目团队更加注重的其实是 Bug 如何解决（包括是否需要解决的判断），他们更希望从问题单中获知的是如下的一些信息：

所发现的什么问题？
- 问题现象是什么？
- 总是会出现吗？
- 发现这个问题时的背景、上下文是什么？
- 除了看到的现象，系统同时还发生了什么？
- 有没有截图、日志、录屏？
为什么它是个问题？
- 这个问题有什么影响？
- 不解决它会怎么样？
- 发生概率怎么样？
- 有没有和其他问题重复？
是做了什么操作，暴露出的这个问题？
- 输入是什么？
- 用了什么测试路径？测试数据？
- 所在测试环境、软件版本如何？

所以，作为测试，不应把问题单看作是一个简单的问题记录，它是测试和开发之间的重要沟通媒介，好的问题单可以极大减少双方的沟通成本，既极大减轻开发人员解决问题的工作量，同时也减少测试人员澄清、重复验证等的工作量。对项目来说，问题单的提交质量，影响的就是团队的生产力以及交付速度，不容小觑。

问题单的要素

了解了问题单的作用，那么问题单中应该包含的要素也就比较清楚了，一般有以下方面：

方便初步判断的标题

标题应该能够比较清楚地概要说明问题，以及这个问题所处的模块。便于开发人员作一个初步的判断
上下文及必要的关联信息

发生问题时的上下文背景，关联的信息如软件版本、测试环境、配置情况、资源状态等
准确合理的详细描述信息

详细描述问题发现的步骤，操作预期，实际发生的状况。问题发生频率，所使用的测试输入、数据、文件等
帮助问题解决的补充信息

能够帮助开发人员加快解决问题进度的补充信息，比如截图、录屏、操作日志、系统日志等
帮助项目决策的辅助信息

测试人员作为 Bug 的第一判断者，应给出问题的严重程度、解决优先级建议。初步指派解决问题的开发人员，以及便于统计、追踪的关联信息标识。

测试小白的错误做法

那么结合问题单的要素，我们可以初步总结一些测试小白或者不专业测试在提交 Bug 时常见的一些错误做法：

标题不够明确

标题非常简单，不便于初步判断问题。比如简单地写 “系统 crash”，太过笼统，而且过于简单的标题很容易产生雷同，对问题的集中回顾、评审都带来很多不便。

或者过于复杂。太长的标题，容易导致阅读疲劳，没有重点。比如标题中详细描写操作步骤就没什么必要
脱离实际，偏离需求场景。

有时候测试小白会从个人偏好角度出发，想当然地提出一些问题。“我觉得”、“感觉上不好” 是这类小白问题中出现的高频词汇。
不是问题

测试小白，往往因为对系统实现原理理解上的错误或技能水平上的不足，提交出不是 bug 的问题单。

还有因为测试小白的测试方法或者环境配置本身就是不正确的，由此导致的问题
描述信息不足

典型的，通过问题单的描述信息，开发人员不足以确认问题现象或自行复现。测试小白往往觉得发现问题就完成工作，没有把充分的信息提供给开发人员，比如截图、日志等。
无关信息过多、格式杂乱

有时小白的问题单中会包含太多冗余的嘈杂信息，很难看到重点。比如不分青红皂白把几万行的 log 贴到问题单中

或者完全不进行排版，一大堆信息杂乱地混杂在一起，阅读难度极高
问题过多

问题单应该聚焦，有时测试小白会在同一个问题单中包含很多个不同的问题。这对于问题追踪和聚焦都非常不利
只看现象不考虑本质

有时候简单的问题现象，往往是一些严重问题的体现或线索。小白往往会忽视重要的风险，对一些看似蛛丝马迹的问题视而不见，将潜藏在现象之下的 Bug 轻易漏过。比如有些预期外的提示信息，往往是后台计算、统计准确性等 Bug 的体现。

提 Bug 与说故事

再回到 提交 Bug 这件事，本质上，这其实是一个沟通的过程，问题单 承载了这个沟通媒介的作用，通过问题单，测试人员将自己在测试过程中看到的、发现到的问题描述出来，开发人员通过阅读问题单，掌握到对应信息并相应地去解决问题。

所以提 Bug 其实和写一个小短文，说一个小故事一样，测试人员是作者，而开发人员是读者。

我们在提问题单时，其实也是写作的一种。写作的 5W 要求也一样适用：

What 内容–具体的问题是什么？
Why 目的–为什么要提出这个问题？为什么它是个问题？
Who 主体-问题主体是谁？关联方有谁？？
Where 地点–问题发生在哪？
When 时间–在什么时间和频率下发生？

提 Bug 时思考这 5W，再结合上文提到问题单要素，一般就不会犯很多测试新手在提问题单时常犯的错误了。

提 Bug 的艺术

上文阐述问题单的要素以及提Bug 时应注意的一些细节，但是为什么我们还要说提 Bug 其实是一件艺术性的工作？

我们来举几个问题单的例子：

假设有一个商品管理系统，用户在某个特定商品分类下（水果）新增商品时会发生crash

问题单例一：

用户新增商品，发生Crash

如图所示（crash界面截图）

这个问题单通过提供截图其实基本描述了问题现象。但是对开发人员来说，信息量太少，而且很有可能并不能第一时间复现问题（水果分类）。问题单中包含的信息太过于简单，可以说是非常糟糕的问题单案例。

问题单例二：

用户在新增商品时，会发生Crash

操作步骤：
1. 打开App
2. 用户登录系统，输入正确的用户名、密码并登录
3. 进入商品管理页面
4. 选择分类：水果
5. 点击新建商品按钮
6. 输入商品信息：*********
7. 点击提交按钮
预期结果：商品创建成功App
实际结果：发生 crash
使用的设备机型：xiaomi 8
操作系统版本：android 8.0
软件版本 V1.1
附件：crash截图

这个问题单，是很多测试小白常见的提单形式，包含了非常详细的操作步骤和相关辅助信息。但是这也是一个非常糟糕的问题单。
首先，这样的步骤描述毫无必要，开发人员不会连打开app、登录、提交这样的操作也不了解需要在问题单中交代
其次，辅助信息虽多，但是基本和问题原因无关，并不利于开发人员定位，反而引入了一些干扰信息。
这样的问题单，无法体现测试人员的专业价值，对问题的快速解决也没有好处

问题单例三：

用户在水果分类下进行新增商品操作时，会发生Crash

操作步骤：
1. 选择水果分类，创建商品，发生crash
2. 选择非水果分类，创建商品，商品创建成功

已验证机型：xiaomi 8，huawei mate 7 等现象一致，应和机型、操作系统、版本无关
附件：错误截图、系统 crash 时的 logcat 日志
影响：用户无法新增水果分类商品，直接影戏用户使用。需高优先级解决

此问题单已经可以算比较合格的问题单了，比较明确地指明了问题发生的场景，并将一些无关信息进行了初步排除。开发人员可以聚焦在水果这个类别下的商品创建进行问题分析。
同时指出了问题对软件的影响和解决优先级建议，使项目团队明确知道这个问题的影响所在

问题单例四：

用户在水果分类下进行新增商品操作时，会发生空指针Crash

操作步骤：
1. 选择水果分类，创建商品，发生crash
2. 选择非水果分类，创建商品，商品创建成功
3. 对已有水果分类下的商品进行编辑操作，可以编辑成功

后台数据库对水果分类因字段缺失insert操作出错，update操作正常。

已验证机型：xiaomi 8，huawei mate 7 等现象一致，应和机型、操作系统、版本无关
附件：错误截图、系统 crash 时的 logcat 日志
影响：用户无法新增水果分类商品，直接影戏用户使用。需高优先级解决

这个问题单，则在上一个问题单基础上更进一步，初步分析出了问题原因，新增操作时，有一个关键字段信息未包含，所以导致的crash。开发人员已经可以很明确地对问题进行修复了

问题单例五：

用户在水果分类下进行新增商品操作时，会发生空指针Crash。导入商品操作旧模板也同样存在问题。

操作步骤：
1. 选择水果分类，创建商品，发生crash
2. 选择非水果分类，创建商品，商品创建成功
3. 对已有水果分类下的商品进行编辑操作，可以编辑成功

后台数据库对水果分类因字段缺失insert操作出错，update操作正常。

在商品管理导入商品功能中，新模板水果商品导入成功，使用旧模板（未包含新增字段）导入水果数据，也会发生失败。需一并修复。

已验证机型：xiaomi 8，huawei mate 7 等现象一致，应和机型、操作系统、版本无关
附件：错误截图、系统 crash 时的 logcat 日志、新旧模板导入日志
影响：用户无法新增水果分类商品，直接影戏用户使用。需高优先级解决

这个问题单，则在上一个例子的基础上，根据测试人员的经验，推理出有类似逻辑的导入功能，可能存在同样问题并进行了验证。很好体现了测试人员专业能力。

通过以上这个简单的案例，我们可以看到，不同的问题单提法，对问题解决效果却有很大差距。