我们合作的一些团队已经停止编写 bug 报告，也不再追踪 bug。取而代之的是，开发人员和测试人员在协同工作时发现并解决问题。在某些情况下，团队成员可能会在某个框架中创建一个失败的自动化检查，此时，修复的目标是让检查通过，同时不引起其他任何部分失败。有时，开发人员也会自测，发现问题后直接“修复并继续前进”。另外一些情况下，团队成员位于同一空间中，发现问题的人可以直接走到责任人（结对编程、三人一组或群体编程）面前，解释问题，然后立即解决。许多人认为这是现代软件开发的方式—即将测试融入开发过程中。这种做法非常棒，我们也很支持。
但我们仍然认为你应该学习如何编写一份有效的 bug 报告。
从根本上讲，bug 报告是一种不理想的沟通方式。它指出的问题会给相关人士带来困扰，这种沟通既可以是口头告知他人问题所在，也可以通过书面形式进练习如何有效地书写 bug 报告、学习如何具体描述 bug，并养成截屏和录屏的习惯—在 bug 传递过程中，这些技能都非常有价值。口头交流的风险会根据对话的笼统程度而略有不同，但提供了更好的即时反馈机会。相比之下，bug 报告则为修改代码提供了更便利的机会。如果公司有跟踪记录 bug 报告，不妨利用午休时间回顾过去一百份左右的报告，看看哪些得到了修复。在多数情况下，报告的书写方式就能预示着 bug 的未来走向。那些表述模糊且将原因排查推给修复者的报告，很可能会被以“无法复现”“符合预期”为由关闭，或是导致开发团队与报告人之间无休止地来回沟通。
再次强调，我们将 bug 定义为“令重要人物感到烦恼或困扰的事物”。初级测试人员经常会发现一些困扰自己的问题，但他们并不是决定问题是否需要修复的人。正如我们的同事弗里·纳德曼正确地指出的那样，这可能会让人感到沮丧。我们希望通过这项工作帮助你理解决策者关心什么，并以一种对他们有意义的方式表达。更高级别的员工可能会“站在决策者角度思考”，在某种程度上成为一个小型的产品负责人。
对于进行用户验收测试（User Acceptance Testing,UAT）的公司来说，bug 报告尤为重要。UAT 是指软件为特定类型的客户（用户）定制，且公司在测试过程中会邀请代表这些用户角色的人员参与。然而，如果现场没有人协助这些用户有效地编写 bug 报告，最终收集到的信息往往会很模糊，无法提供实质性的帮助。我们认为 bug 报告是提升软件质量的一种机制，若缺乏有效的报告机制，整个测试过程将徒劳无功。这也是许多人对 UAT 持保留态度的原因—因为他们的 bug 报告质量非常糟糕。
在某些情况下，缺陷会逃逸到生产环境。即使团队在问题进入生产环境之前能发现所有问题，新的浏览器版本或操作系统也可能导致新的 bug。在这种情况下，如果收到的 bug 报告不足以说明问题，那么 bug 可能要被反复报告多次后才会得到修复。
可见，我们有必要写好 bug 报告。
下面是一个 bug 报告模板：
● 前置条件：包括环境变量、数据库中的内容以及任何必要的配置。如果是特定浏览器或环境下发现的问题，也应该在此说明。
● 操作步骤：复现 bug 的具体操作步骤，最好是以编号列表的形式呈现。
● 预期结果：软件预期产生的行为或输出结果。
● 实际结果：软件实际的结果或表现。
● 更多信息：如果实际结果并不清楚明了，可以考虑添加附件，例如屏幕截图、录制视频。本书推荐使用 Windows 自带的截图工具或 Techsmith 的Snagit。另一种选择是使用手机直接拍摄问题界面并附加到报告中。如果复现bug 存在困难，但你能使其在 70% 或更多的情况下出现，那么可以在此列出复现问题的提示和技巧。弗里 · 纳德曼建议每次测试控制在 30 分钟左右，并录制整个过程。这样做会从一开始就确保问题的可复现性。
● 摘要 / 标题：对问题进行一行简单的概括说明。
在实践中，人们常常会跳过报告中的详细内容。因此，我们需要努力将摘要写得足够完整，以使读者即使跳过主体内容也能了解问题概况。为了达到这个目的，我们将摘要放在最后并建议最后书写。
为了说明这点，我们提供了一张某网站的真实（稍作模糊处理）截图（图 6-3）。你会给这个 bug 起什么标题呢？
图 6-3 一个移动应用中的文本处理错误
下面，我们来看一些可能的标题，以及测试人员如何看待它们：
● 会议网站中“关于我们”页面在移动版本上数字混乱。检查人员可能会在平板电脑上复现这个问题，但没有发现问题，然后将其标记为无法重现。
● 在特定型号的 iPhone 上使用 Safari 浏览器访问“关于我们”页面时出现数字重叠 / 错乱。这可能引发关于 iPhone 用户数量、支持哪些 iPhone 版本以及公司是否支持 Safari 浏览器的争论。实际上，公司往往会为设备设定一个最低支持版本（通常支持过去两到三个版本的设备），以及支持的浏览器类型。在进行测试时，我们一般至少会在两种不同的浏览器上进行，并且尽量选择与开发人员所用不同的浏览器。然而，随着浏览器市场的不断成熟，我们发现所谓的“浏览器兼容性问题”正逐渐减少。因此，摘要可能这样会更好些：
● 移动设备上“关于我们”页面出现数字重叠 / 混乱（以 iPhone 16 Pro 为例的屏幕截图）。这样的摘要既告知读者他们可以在一个特定设备上复现该问题，同时也表明问题并不局限于这一特定设备。
当我们将此截图发布在 X（原 Twitter）上并征求一个好的摘要时，有人回复说“列标题互相重叠”，我们可以将其完善为“移动设备：‘关于我们’页面的列标题 / 数据重叠（来自 iPhone 16 Pro 的截图）”。
想象一下阅读 bug 报告的人很懒，他们不想按照步骤去重现问题，他们希望所有信息都能从标题中直接获取，而且是立刻就要得到。
所以为什么不直接提供给他们呢？
假设你正在测试一个在线账单应用程序。点击服务日期（service date）后查看“月份”的弹出窗口，如图 6-4 所示，其中日期以数字显示，而 23 号却错误地显示为 2.3。
下面提供两种方式来描述这个问题。
方式一：
● 摘要：在服务日期（新建账单）日历中，部分数字以文字形式显示。
● 复现步骤：使用 Chrome 浏览器最新版本，创建一个新的账单，点击服务日期旁的日期选择器图标，展开的日历中会看到某些数字以文字形式出现。
方式二：
● 摘要：新建账单问题：笔记本电脑上，服务日期的日历下拉菜单中月份的某些数字以文字形式显示。
图 6-4 日历功能中的文本转换错误
● 复现步骤：
Ⅰ. 以测试用户身份登录，即使用 testuser@testaccount.com 邮箱进行登录。
Ⅱ. 等待页面加载完成。
Ⅲ . 点击“Sales”（销售）。
Ⅳ . 点击“Invoice”（发票）。
Ⅴ . 点击“New”（新建）。
Ⅵ . 等待页面加载完成。
Ⅶ . 找到第一张发票第一行中的“service date”字段。
Ⅷ . 点击“service date”。
Ⅸ . 进入“月份”下拉菜单。
Ⅹ . 选择月份“August”。
● 预期结果：日期选择器中的月份弹出窗口，所有日期均以数字形式展现。
● 实际结果：日历中的 1 号、2 号、11 号、15 号、20 号和 21 号等日期以英文单词形式显示（如“one”“two”等），而 23 号却异常显示为 2.3（此处错误地在数字 2 和 3 之间加入了小数点）。
第二个表达方式虽然具体且准确，但确实显得较为冗长和乏味。因此在编写bug 报告时，需要找到一个平衡点，既要提供足够的信息以准确地识别和修复问题，也要避免过多的细节导致信息混乱。
在“正确性”与“易读性”之间的最佳平衡点，会因团队需求的不同及 bug的具体情况有所变化。根据我们的经验，对于那些明显错误的问题，通常只需一个简单的说明配合截图就足够了。为了提升团队在这方面的意识和能力，我们建议开展一项练习：选取一个真实的 bug，让每个团队成员独立编写 bug 报告。随后打印这些报告，带上记号笔，让团队成员选出他们认为最优质的 bug 报告。然后，对你们认为优质的 bug 报告的构成要素进行分类和讨论。这项练习的理念在罗伯特 · M · 波西格（Robert Maynard Persig）的著作《禅与摩托车维修艺术》中有较为详细的描述，该书副标题是“对价值的探究”。
目前，我们建议将 bug 报告视为一种目标导向的冲突。无论 bug 报告以何种形式呈现，阅读报告的人都可能有一个潜在目标—那就是忽视这份报告。他们面临着截止日期的压力和其他诸多重要事务，而修复 bug 只会拖慢他们的进度。鉴于此，他们会寻找各种理由不去处理这些问题。这些理由可能包括以下几点：
● bug 报告太模糊，我无法理解或复现。
● bug 报告太具体，冗长且乏味，所以不重要。
● 这个 bug 仅在特定环境下出现，因此没那么重要。
● 没有提到环境，我在 ×× 环境测试了，无法复现。
● 这份 bug 报告错别字太多，我无法认真对待。
● 这份 bug 报告太长了，更像是抱怨而非报告。
这使得报告 bug 的过程类似于奥德修斯（Odysseus）驾驶他的船在双怪之间航行的情景—一边是栖息于悬崖岩石上的怪物斯库拉（Scylla），另一边则是制造漩涡的卡律布迪斯（Charybdis）。完美的 bug 报告应当如航行于这两者之间那般精准而不过于枯燥，既要防止被误解，又要恰当地表达问题的范围和重要性。
如果你所在的环境经常出现仅在某个平台上出现的 bug，那么花上大约 10 分钟时间去检查该 bug 是否也存在于其他设备、外形规格、操作系统和浏览器。如果确实存在，你仍然应该列出最初发现该bug的环境，同时注明该bug似乎普遍存在。
在本节将结束之际，我们想跳出当前的视角，审视一下那些效果不佳的 bug报告。从第 12 章开始的“职场实践”部分，将包含一些测试工作效果不佳且未能产生有效改变的故事。在大多数情况下，bug 报告的标题未能充分证明该问题必须得到解决，即报告 bug 的人未能让管理层意识到这些问题的重要性。然后，一周、一个月，甚至一年之后，当出现严重的问题时，管理层又会将责任归咎于那些本应该关注产品风险的人—特别是与产品质量相关的风险。
编写不佳的 bug 报告还具有时间衰减效应。在报告刚被创建时，由于团队正全身心地投入到工作中，报告中所指的问题可能还算明确。但到了下一个冲刺阶段，可能需要花费一些功夫才能理解编写不佳的报告。而到了明年，随着团队成员的变动，由于缺乏共同的工作经验和上下文理解，原先的报告对新团队成员而言可能就变得毫无意义。新团队可能看不到旧报告的价值，因为这些报告对他们来说没有直接的帮助，不具有实际效用。
所有这些因素加在一起，可能会边缘化甚至消除测试工作的作用。这种因素并不新鲜，也不是独一无二的，而且不会消失。我们希望，即使测试角色的关注度可能会降低，软件开发流程中的每个人都应意识到，随着测试人员的减少或测试角色的消失，团队中的每个人都需要更加深入地学习测试。那些采用敏捷方法和高信任度、选择“发现问题就立即修复”而不记录 bug 的团队，将陷入无法理解测试过程中发生的情况、没有数据来验证假设、做出调整或进行实验的风险中。缺乏这些数据，测试的其他要素，如度量、预测和规划，就变得更加重要，接下来我们将转向这些方面。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。