如何编写好的软件测试

我们都经历过混乱和熵的影响。你把线材整齐的耳机放进口袋，拿出来时却发现它们乱糟糟的，简直是难以想象。一根耳机线怎么会在三分钟内扭成25个结，这真是难以解释，对吧？

软件开发中也经常发生同样的情况。你更新了几行简单的代码，运行测试套件，某个随机测试就抛出了一个毫无意义的错误。（“PC 加载字母？这他妈什么意思？！”）你调查后才发现，错误来自一段十年来无人敢碰的关键代码。

通过测试套件来了解代码变更的影响非常困难，尤其是在将代码推送到复杂且高度集成的存储库时。您可以建议重构测试套件，但这会给您的团队带来巨大的技术负担，目前您无法承担。您肯定已经听到项目经理说：“我会把它和其他所有东西一起放到待办事项里。”

全球各地的组织都面临着类似的问题。为什么？因为我们很容易在不知不觉中构建出一个极其复杂的系统。而到那时，就为时已晚了。

摆脱这种情况的唯一方法是进行更好的测试。

为什么软件测试很重要

有效的软件测试使开发人员能够专注于复杂的问题。复杂度越高，建模就越具挑战性。因此，编写分离、可重复的测试，并提供重要且有意义的信号至关重要。这句话包含的内容很丰富，我们将在本文中进行详细解读。

让我们从简单的事情开始。软件测试有两个主要好处：

1. 在将代码投入生产时增强信心
2. 增加该动作的速度

代码越接近生产环境，就越需要反复测试。测试代码越多，就越能确保其在生产环境中的可行性。而信心源于精心编写的测试，它们能够提供问题所在。

但仅有信心是不够的；生产速度同样重要。现代企业无法容忍对每一项变更都进行细致入微的测试。在过于专注于细节和编写一次性覆盖所有细节的测试之间，存在一个折衷方案。这才是最有价值的测试进行的地方。

那么开发人员应该如何确定哪些测试是有价值的？

什么是好的软件测试？

好的软件测试具有明确的特征和目标：

• 证明你的软件有效
• 证明你的软件能够实现预期的功能
• 证明你对软件的假设成立
• 证明相对复杂的东西可以在各种场景下工作，并按预期与其他组件协同工作
• 发出强烈、有意义、信息丰富且明确的信号
• 奔驰
• 可重复
• 无副作用

其中一些显而易见，但也有一些并非如此。我们喜欢将失败的测试比作汽车上的“发动机故障灯”。发动机故障灯本身并不能提供任何有价值的信息。但汽车修理工拥有设备，可以从车辆的诊断系统中获取更有意义的数据。如果故障灯亮起，且诊断结果为“2号发动机气门松动”，则是一个有意义的信号，修理工可以直接进行维修。否则，修理工必须进行一系列广泛的测试才能确定问题所在。

软件测试结果需要提供对开发人员或质量工程师有价值的诊断信息。仅仅说“数据库错误”是不够的。一个好的测试应该说“无法连接数据库”，并显示来自数据库连接器本身的确切错误消息。像这样清晰的错误消息信息丰富、明确，可以引导开发人员找到需要更正的确切代码行。

好的测试是可重复的，并且可以按任意顺序运行，且没有依赖关系。换句话说，它们是幂等的。好的测试能够模拟各种各样的用例。例如，你可能不想将发送电子邮件作为系统的一部分，但你应该对其进行建模，以便处理所有可能失败的情况。

什么是好的测试套件？

测试套件是一系列优秀的测试的集合，它们能够模拟各种用例并尽可能快速地运行。优秀的测试能够确保对个别变更实例的可靠性，而优秀的测试套件则能够确保在正常情况下，整个环境都能成功运行。优秀的测试套件能够清晰地显示依赖项变更，帮助开发人员快速行动，增强提交和批准拉取请求的信心，并发现不良测试。

另一方面，糟糕的测试套件会随着时间的推移越来越少地被执行，因为它无法建立或提升对整个系统的信心。人们停止运行糟糕的测试套件的原因是：

• 难以管理
• 速度慢
• 只为少数人服务
• 让开发人员耸耸肩
• 容易受到依赖性变化的影响
• 过于全面
• 伪造或模仿过多的环境/背景

你可能听过这样一句话：“如果森林里有一棵树倒下，却没有人听到，那它会发出声音吗？” 我们的推论是：“如果你编写了测试，但直到最后一刻才有人运行它们，这是否证明你的软件已经可以投入生产了？”

过于全面的测试套件测试范围太广。如果你测试了2+2=4个组件，并且在过去25年里从未失败过，那么即使它通过了，也没有任何意义。如果你的测试覆盖了系统中的所有内容，那么你基本上就只能看到“发动机故障灯”了。如果一个测试执行了25分钟，最后却失败了，那么这25分钟很可能就浪费了。（此外，我们认为等待一个测试套件完成执行，即使10分钟也太长了。）

编写提供价值、信心和提高速度的测试

在过于专注于细枝末节和一次性编写覆盖所有细节的测试之间，很​​难找到一个“中间地带”。通过消除那些耗时过长、提供无意义信息、从不失败、仅服务于少数人、易受依赖项变化影响以及缺乏幂等性的测试，可以取得显著的进步。

专注于复杂代码的测试对开发人员最有利。如果测试涵盖各种故障场景，并能提供关于这些故障的有力且有意义的信号，开发人员的信心就会增强。此类测试的编写应确保快速运行且无副作用。

代码越接近生产环境，就越需要反复测试。充满快速、有效测试的测试套件将增强信心。当代码部署到生产环境时，几乎不会出现关于其生产可行性的疑问。

要了解有关 YourBase Test Acceleration 如何加快测试套件运行时间的更多信息，请查看yourbase.io！