《软件测试策略》——测试相关技术（项目预测和推动变革）（五）

京东购买链接：https://item.jd.com/10205955087769.html

 

6.6 项目预测

上一节提供了两个预测的示例：随时间变化的缺陷数量和随时间变化的测试用例通过数量。我们对这两个指标并不特别热衷。在敏捷开发背景下，目标是快速解决值得修复的 bug，bug 的唯一记录可能只是版本控制系统中的一个变更。

“预测（Projections）”一词源自“project”，在此并不严格限定其意义。在处理软件质量时，我们可能希望做出几种预测，这些预测可能包括以下几个方面：

● 受影响人数：这个变更或缺陷将影响多少用户或客户？

● 每日经济损失：问题持续存在的每一天，造成的收入损失是多少？这被称为“延期成本”（cost of delay）。

● 间接成本：除了用户无法使用功能的直接成本外，我们在用户采纳、客户流失、销售和品牌声誉方面是否有间接成本？

● 修复工作量评估：查找问题、修复及重新测试所需的工作量预计是多少？

● 投资回报率比较：相比于其他潜在的工作，该需求或变更的投资回报率是多少？

Amazon曾声称，网页加载时间延迟1秒会导致每年损失16亿美元的销售额，这一说法已经有 10 多年的历史了。时至今日，这类问题导致的损失可能会变得更大。有人曾经做过这样的分析。

现在确实有一些工具可以用来分析日志以获取这些信息。对于 Web API 而言，这些工具能分析出响应时间的平均值（均值）、中位数（中值）和最常见的响应时间（众数）。同时，查看处理请求的最慢时间也很有帮助，比如最慢的25% 请求的统计指标（例如平均值、中位数和众数）。另外，我们也可以直接导出整个数据集来直接查看原始数据。

在传统项目中，你可能会发现一些方法来衡量已完成的工作量，以及错误出现的频率，从而预测完成整个项目需要多少个周期以及每个周期应该有多长。随着每个周期推进，待测试的内容量可能会逐渐减少。在最后一次运行中，如果回归测试频繁失败，并且我们无法一次只发布一部分内容，那么我们倾向于回到早期的完整用户旅程中，重新执行这些测试。关键在于利用 bug 报告、度量指标和分析手段来平衡各方面因素，并预测结果。

首先，我们要弄清楚当前的状况；接着，确定需要做出哪些改变，识别哪些方面需要改进或调整；之后，思考如何有效地传达这些信息，确保团队成员或利益相关者能够理解并采纳建议。在第 8 章和第 9 章中，我们将详细探讨如何具体实施这一系列步骤。

6.7 推动变革

我们可以认为，测试“仅仅”是一种技术性调查，旨在揭示与质量相关的信息。就这一定义而言，没有什么问题，因为其涵盖的范围并不大。如果测试工作发现了问题，并且这些问题被详细记录下来，但却从未有人阅读……那么实际上不会有任何改变，测试工作的商业价值也就等于零。或许公司很幸运，没有出现“致命性 bug”，用户也不在意。在这种情况下，理智的管理层可能会削减测试预算，或者公司也可能会因此而倒闭。

我们大多数人可能并没有遇到那种完全忽视测试发现的问题的情况，但我们可能面临另一种困境：测试确实发现了 bug，但只有一部分得到了修复，且不够彻底。更糟糕的是，开发人员没有从错误中吸取教训，反复犯同样的错误，不断产生相似的 bug，这种情况会拖累整个团队的效率。有些测试人员觉得这样很好，因为有工作可做，就不会失业。曾经有一位测试人员对我们说，每次发布都会包含大量用户界面的 bug 或更改，使用录制回放自动化脚本时，这些变更都会导致脚本失效。通过手工重新创建脚本（实质上是手工测试），他可以发现这些bug，然后等待修复，并再次验证修复情况。整个“自动化”过程实际上与人工测试是重复的，并没有增加额外价值。但只要他愿意，他就能保住工作。

对于拒绝变革的测试人员，最好的结果可能就是获得一份长久但使人变得思维惰化、只是机械执行脚本的工作，我们认为这并不是一件好事。从第 12 章开始，我们将着手讨论实践策略，但在此之前，先来讨论一个与测试真正相关的优秀技能—总结信息的能力。

6.8 总结信息

测试人员身处信息洪流之中，我们需要从中汲取关键信息。因为高层领导者很少有时间和精力去深入了解这些细节，即便他们有时间，也无法获得他们所需的高层次信息来做决策。这些决策包括：

● 软件今天能否上线？

● 我们何时能启动广告宣传活动？

● 为了让软件“足够好”，现在需要修复哪些内容？

● 新功能是否足够好，可以在 ×× 会议上进行演示吗？

● 我们能发布（新功能）了吗？

过去常用的模式是给团队施加压力，促使团队宣称产品已经准备好发布。而当产品并未达到发布标准时，就会去批评那些承受了巨大压力的团队成员。对此，我们想寻求一种更好的方式解决这种问题。

语境驱动测试（一种测试思维的体现，通常是指测试人员首先查看特定迭代的细节，如产品特性、业务需求、相关人员等，来选择他们的测试目标，即强调人的作用，寻找利益相关方关注的 bug）将测试人员定位为调查员和信息传递者，而非决策者。这意味着测试人员不会说“测试已完成”，而是会说“我针对这六个风险进行了测试，发现了这些问题，并认为继续测试没有更多价值”。这样的对话可以在需求开发 / 测试层面、回归测试层面（例如 API、某个 sprint 冲刺），甚至季度全量测试或项目测试层面进行。当我们看到某些“大规模”方法中的额外负担（如 Large-Scale Scrum 在实施过程中确实可能存在一些额外的负担，这些负担主要源于跨团队协调、产品积压工作的管理、角色和职责的扩展、工具和技术的适应性以及组织变革的挑战）时，我们试图通过“架构师”或“发布列车工程师”等角色来实现这一目标。接下来，让我们通过一个简单的文本示例来看看如何为一个虚构产品“POWERTRAIN”制作这样的总结。

在对 POWERTRAIN 进行了 4 小时的测试后，我们面临着三种选择：在当天解决以下问题后发布、直接以当前状态发布，或是明天继续测试。我们倾向先解决问题再部署。以下是我们发现的四个最严重的问题，预期如果发现更多错误，它们的严重性也不会超出以下情况：

● 在旧版本的 iPad 和 Safari 浏览器（特别是运行 2019 年以前操作系统版本的型号）上进行回归测试时，发现了一系列问题。这些版本虽得到支持并可以使用，但存在一些用户体验问题（缺陷 #2220），尽管有直观的临时解决方案，但用户体验仍然不佳。Safari/iPad 用户占总体用户的 0.25%，占销售额的 0.05%。我们同时也测试了其他浏览器。

● 新鲜蔬菜图标显示为“损坏图标”（缺陷 #2120）。

● 同时应用五个或以上属性过滤，再加上高级搜索条件（包含多个 AND或 OR）时，无法返回任何结果（缺陷 #2229）。

● 评论字段限制在 2048 个字符（缺陷 #225），而需求是不限制字符数。值得注意的是，数据库中 95% 的评论长度都小于这个限制，并且错误提示信息清晰明了。

我们预计开发人员能在今天下午解决上述问题，并于明天上午 9 点部署产品。我们的测试工作主要集中在搜索功能、产品展示及购物车部分，因为这些是变动最大的模块。我们还快速检查了报告和控制面板功能，并创建了自定义目录功能。目前，我们面临三个选项：继续在这几个关键领域进行 4 小时的深度测试，对变化最大的区域进行更深入的测试，或是根据当前情况规划产品发布。

上述示例提供了一个文本总结，可能显得有些“繁琐”。在后续章节中，我们将探讨如何利用仪表板、思维导图、热力图和其他可视化工具，直观展示已测试内容与未测试内容的对比情况。

上面的总结信息中含有一些隐含的信息点，本节我们就来讨论它们。

首先，它向管理层提供了多项选择：“我们可以这样做，也可以那样做，或者采取第三种方案。”当只有一个选择时，人们会感到没有自由。当有两种选择时，他们可能会陷入两难境地。而给出三个或更多的选择后，人们开始感觉到自己掌握了控制权，能够根据情况做出更适合的决定。

其次，总结中表明，这些只是我们目前发现的 bug。如果有更多时间，我们很可能会发现更细微的 bug。

最后，它解释了哪些内容没有被测试。这为决策者提供了基于质量因素做出判断所需的信息，同时也提供了一种策略上的灵活性。也就是说，如果列出的bug 看起来并不严重，那么即使不修复也可以相对安心地上线。毕竟，进一步的测试可能会发现更多此类 bug。

而如果存在更多 bug，但它们存在于我们选择不测试（或仅简略测试）的区域中，那么我们就不会面临“为什么没发现这三个问题？”之类的质疑。相反，我们让管理层参与到了决策过程中来，他们甚至不会提出这个问题，因为批评这个决定就是在批评他们自己。

向人们提供信息，让他们参与到决策过程中，这样他们之后就不会对你所做的决策进行批评。

有时候，组织可能不会听从理智的声音。他们会忽略你的警告，即使产品状况一团糟，即使是字斟句酌的警示可也能会被置若罔闻，你发现自己无力改变最终的结果。

即便在这样的困境中，你仍然可以找到积极的意义。当下次类似情况发生时，组织就有了学习和改进的机会。当他们说“这个项目感觉很像之前的POWERTRAIN 项目”时，你可以回应道：“还有谁经历过 POWERTRAIN 项目？我们还想重蹈覆辙吗？”

如果你希望从事涉及测试的职业，并期望在这个领域有所作为，那么培养能够影响变革的能力是至关重要的。其中一部分涉及策略和政治手腕—你需要意识到大多数决策实际上在会议之前就已经初步形成，如果在会议中试图改变决策方向，可能会无意中让其他人显得不够称职或决策不当。

简洁有力的总结是一个好的起点。无论是口头表达还是书面文字，都需要练习这项技能。了解你的听众需要的信息量，学会根据他们的接受能力调整信息的多寡。首先陈述现状，接着给出原因，与受众熟悉的案例类比，最后提供多种可选的解决方案。

通常情况下，从事测试工作的人员往往没有决策权，却在承受压力，甚至常因团队中有人做出了仓促发布产品的不良决策而受到批评。我们也许无法完全避免这种情况的发生，但可以通过一些方式帮助领导者认同决策过程，有时甚至是促进整个组织从中学习和成长。

6.9 本章回顾

本章讨论了进行高效测试所需的测试相关技术，包括识别可能困扰用户的问题、准确报告问题、运用数据讲述一个有说服力的故事，以及做出预测。然而，“变革”这一测试环节经常被忽视。如果没有这一环节，测试就仅仅是“我们为了将软件投入生产环境而必须做的例行公事”。另一个常被忽视的测试元素则是测试数据。在下一章中，我们将阐述为何测试数据如此重要，并为读者提供一些策略来收集和管理测试数据。以适应变化，消除错误警报并缩短调试时间。