以速度和规模进行创新的举动让软件质量变得紧张，暴露了测试的局限性。

不要误解我——所有形式的测试都与软件交付供应链密不可分。测试和静态分析对于软件开发流水线是必不可少的，这对于传统和云原生应用程序都是如此。

但问题是，它们是不够的。

我们正处在一个前所未有的时代，一个颠覆性的时代，历史悠久的金融机构正面临着来自7年之久的初创企业的竞争。企业面临着快速行动以保持生存的压力，即便是那些已经存在了 100 多年的企业，它们也需要以两倍的速度行动，以捍卫自己的地位并保持竞争力。

十多年前，当引入测试驱动开发（Test-Driven Development）（TDD）时，它承诺提高生产力和质量。即使是那些不太关注它的团队，也会注意它。从那以后，发布周期缩短了，CI/CD 不再是一个时髦的词，而开发流水线自动化产品的新公司， GitLab ，已经足够成熟，可以上市了。

重申这一点，测试可能比以往任何时候都更相关，但是当快速移动是表利害关系时，仅仅依靠传统测试来防止错误是不够的。尽管测试是不可替代的，但关键的错误仍然会出现在生产中，而客户正在等待他们承诺的无缝体验（就在他们的应用程序中断之前）。

底线？测试已经不够了。在这篇文章中，我们将概述我们是如何到这一点，以及专家们对此有什么看法。

红皇后假说（以及它对测试的意义）

在数字商业的背景下，停滞不前等同于失败。Lewis Carroll 在《爱丽丝梦游仙境》（Alice in Wonderland）中说得最好，这成为“红皇后假说”（Red Queen Hypothesis）的基础：

《红皇后假说》不仅是一本伟大著作中的奇闻轶事，它还源于一个进化的概念，即生物必须不断适应才能生存，同时还要在不断变化的环境中与其他生物竞争。

同样的思想也可以应用到业务环境中，这说明了为什么每个公司都急于将自己的 CI/CD 工作流自动化。这里的二阶效应是它如何应用于测试的。当你越来越快地发布代码，提高开发速度时，如何防止错误升级？如果它们真的发生了，你怎样才能快速修复它们？

时速 70 英里的公路汽车的安全措施与时速 200 英里以上的 F1 汽车的安全措施非常不同，因此当你将 CI/CD 工作流程自动化时，测试也需要改进。

专家们对此有什么看法？

根据谷歌云的 DevOps Research & Analysis（DORA）《DevOps 状态报告》，更改故障率（即导致服务降级并需要修复的生产更改的百分比）可以达到所有新代码发布的 60%。对于优秀的执行者，失败率可以保持在 15% 以下，但是由于这只针对已知的错误，并且是基于工程师（而不是客户）的自我报告，实际的失败率甚至可能更高。

低绩效者和优秀绩效者之间的差距相当大，这使得精英在创新和快速行动的能力上拥有“不公平的优势”。这解释了我们从Facebook、苹果、Netflix、微软和谷歌等大型科技公司那里看到的结果，尽管它们也不是没有错误。

这背后的一个关键驱动力是能够以更高的频率发布更小的变化——但这并不是唯一的区别。虽然所有的公司都在以这样或那样的形式进行测试，但是它们如何进行测试以及它们寻找的是什么却有很大的不同。

在最近的一次现场讨论会上，我们与 DevOps Paradox 的共同主持 Darin Pope 讨论了这个问题，他是 DevOps 的顾问，以使复杂变得简单而闻名，还有 Viktor Fracic，他是总软件交付战略家、开发人员倡导者和出版作者。与 OverOps 解决方案工程副总裁 Eric Mizell 一起。

按需录制的对话回放，包括通过持续可靠性（Continuous Reliability）平衡速度和质量的要点，可在这里获得。

下面是对话中的三个要点，说明了为什么传统测试是不够的：

1. 100%的代码覆盖率 ≠100% 的错误识别

Viktor Fracic：“代码覆盖毫无意义。我不明白为什么人们仍然痴迷于代码覆盖。问题不在于你有多少测试，而在于这些测试的质量。我见过一些公司，他们的代码覆盖率接近 100%，但是他们的测试毫无意义，什么也证明不了。”

“在我看来，这些指标非常具有误导性。拥有 95% 的测试代码覆盖率很容易，但是拥有真正重要的测试，让它们驱动你的设计，并检测那些难以检测的东西，这才是真正困难的。如果测试本身做得不是很好，那么代码覆盖就没有多大用处。”

2. 高质量的测试需要时间，但不能保证成功

Darin Pope：“这是大多数人的日常生活，我宁愿在生产中发生错误并迅速进入市场，也不愿在失去所有市场机会的情况下花5年时间来开发产品。我宁愿看到人们快速行动，坦然面对失败。”

Viktor Fracic：“如果你开发了五年，然后投入生产，它仍然会失败。在将其投入生产之前，你并不真正知道它在实际用户中的表现。我们只是想在投入生产前尽可能地保持稳定，但一旦稳定了，我们就能知道发生了什么，并迅速做出反应来解决问题。但是你会测试，测试，测试然后你说，是的，现在它会 100% 工作，这从来没有发生过。如果你能帮我找到一个有这样才能的人，我很高兴能见到他们。”

Eric Mizell：“我不想生产力下降，然后惨败。但是我确实希望能够有合适的人员和流程来修复它，因为你希望采用快速行动/快速修复的心态。我想要更快地实现它，因为在当今世界，我需要更快地行动。在云计算的世界里，一家新公司可以花一天的时间，与我竞争我已经工作了五年的东西。我需要弄清楚如何快速前进，如何在不摔倒的情况下继续前进。”

3. GA 实际上是一个测试版，而用户是新的 QA

Viktor Fracic：“我想说，这在很久以前是真的。只是现在我们承认了。每个人都知道，我们从来没有在生产中部署稳定的代码，从来没有失败或没有任何问题。20 年前，世界上的每一家公司都收到用户的通知，这个或那个不工作，然后你需要修复它。我们知道这一切，现在我们只是承认现实。”

Eric Mizell：“我曾听一家公司说，他们试图对失去客户和收入与推出软件的风险程度进行风险评估。他们需要新的特性。这是一个平衡。我不认为任何人有完美的平衡，但你看到它发生了很多，它回到我想要能够快速移动/快速修复的概念。如何从失败中走出来才是真正的挑战。”

总结

作为开发人员，我们非常擅长编写代码，但在预测代码将在何处崩溃方面存在固有的能力限制。如果我们想要实现快速移动/修复快速视图，那么检测软件问题的任务，无论是在测试的早期还是在生产的后期，以及收集有关软件问题的信息都应该是自动化的。