《软件测试策略》中，有哪些技术可以用于识别bug？

京东购买链接：https://item.jd.com/10205955087769.html 到目前为止，本书主要讲述了测试设计和执行。这两方面固然重要，但忽略了一些重要内容，比如如何识别问题。当我们意识到存在问题时，就需要以一种经得起推敲的方式，向其他人传达这一问题的严重性。你可能会认为，发现错误并解释为什么需要修复，是一件简单甚至显而易见的事情……但如果真是如此，那为什么还有那么多软件存在非常多的 bug 呢？ 为了提高效率，测试活动不仅需要发现对项目构成风险的问题，还需要以能促成改变的方式进行沟通。这些方式会因许多因素而有所不同，比如公司文化、接收信息的人、他们所承受的压力程度等，因此并不存在“唯一正确”的沟通方式。相反，沟通是一种技能，需要你在自己的工具箱里储备多种技巧，然后不断尝试行之有效的方法。本章的目标就是充实你的工具箱，并通过一些实例展示如何实施这些沟通技巧。 为了促成这一目标，本章将从以下方面进行介绍： ● 识别 bug—如何找到 bug ； ● 向利益相关者传达问题； ● 规划并记录工作； ● 衡量工作、进度和工作效果—度量指标； ● 推动变革。 6.1 技术要求 本章将探讨跟踪工作进度和收集工作信息的相关内容。至于如何具体实现，我们并不限定特定的方式。一个高效运作且高度互信的团队，可能只需在看板上贴上便利贴或用马克笔标记，并将测试中、测试完成的功能作为进度的主要衡量标准。然而在撰写本书时，采用了如Jira、Trello或Microsoft Teams等工具来跟踪工作进度，之后将数据导出到电子表格中进行度量统计，这种做法更为普遍。本书将为这两种极端情况及中间的大多数人群提供适用的解决方案。使用这些工具自行收集数据，将有助于你深入理解本章的要点，并且也可能为决策者提供关键信息。另一方面，如果缺乏这些工具，可能会让你感觉到工作中缺失了什么重要的元素。 几年前，Matthew 为一个团队培训时，该团队报告了一些 bug，但没有人关心。测试人员和开发人员在不同地点办公，因此 bug 被记录在一个没有人查看的数据库中。在这个软件系统中，用户可以在注册后通过输入无效的信用卡号获得访问权限。测试人员猜测，也许该服务正处于小范围试运营阶段，信用卡处理功能还未“接入”—这只是他们的推测。这个故事听起来可能有些不可思议，但类似问题在软件开发中却极为常见。 这个团队只做对了一半—他们发现了 bug。这是本章的起点。另一半是设定预期、沟通交流以及创建能激发行动的反馈，而这些正是他们所缺失的。 本章的目标是为你提供一套工具，避免陷入这样的困境。 6.2 识别 bug 从 20 世纪遗留下来的关于测试的普遍思维模式，或者说最响亮的观点，就是“制订计划并按照计划工作”。进行测试的人会依照一系列步骤操作，最后与“预期结果”对比。如果实际结果与预期不符，就提交一个 bug 报告。听起来很简单，对吧？ 但实际情况“似乎”并非如此。实际情况是，测试人员遵循既定步骤操作，当发现这些步骤无法顺利进行时，他们就会报告 bug，等待新版本构建，然后再尝试从之前的某个环节重新开始测试。之前使用了“似乎”这个词，因为那已是过去式。如今许多客户在软件首次运行时，大体上都能取得较好的效果，关键在于“预期结果”。正如第 1 章中提到的，每一个带有预期结果的文档化测试用例都隐藏着一个第二断言—不会发生其他异常情况。如果你手头有一些这样的分步检查并对照预期结果的文档化测试，同时配合 bug 追踪系统，你可以比较一下，看看有多少 bug 来源于这些文档化测试用例。根据我们的经验，此类 bug 数量很少。 那么，bug 从哪里来？我们想问的是，它们是如何进入我们的认知范畴的？ 通常是有人注意到了某些在他们看来不正常或不对劲的情况。 大多数人并不会刻意研究 bug 是如何被发现的。比如某个单词拼写错误，人们往往基于自己对正确拼写的认知模型来判断，他们会说：“我们知道它是错的”。但当我们深入探讨更复杂的用户界面问题，比如如何处理没有空格的换行、调整窗口大小，或是类似推荐书籍或电影的复杂算法结果时，确定什么是“错误的”就变得更为重要。在这种情况下，我们不再单纯依赖绝对的对与错，而是倾向于寻找一系列虽不完美但能帮助识别问题的方法。我们用“先知（oracle）”一词来描述这个过程。oracle 在此不是指数据库，而是更类似于古希腊的占卜者，他们能提供智慧。“先知”并非需求规范，也不一定完美无缺。例如，将这本书的内容粘贴到拼写检查器中，可能会因为包含像 DevSecOps 这类词汇而触发拼写检查警告，但实际上这些词汇是正确的。即便如此，拼写检查仍然是一个帮助发现问题的有效途径。