为什么测试对今天的软件交付管道不再足够

在速度和规模上进行创新的举动强调了软件质量，并暴露了测试的局限性。

不要误会我的意思-所有形式的测试都离不开软件交付供应链。测试和静态分析对于软件开发管道至关重要，对于传统应用程序和云本地应用程序都是如此。

我们正处于史无前例的时代，处于一个颠覆的时代，历史悠久的金融机构正面临着来自成立7年的初创公司的竞争。公司面临着快速行动以保持生存的压力，即使是那些已经存在超过100年的公司，他们也需要以两倍的速度来捍卫自己的地位并保持竞争力。

十多年前，当引入测试驱动开发(Test-Driven Development，TDD)时，它承诺提高生产力和质量。即使对于那些不虔诚地追随它，但更多地将其视为北极星的团队来说也是如此。从那时起，发布周期缩短了，CI/CD不再是一个时髦的词，开发管道自动化产品的新公司-我在看你的GitLab-已经足够成熟，可以IPO了。

重申这一点，测试可能比以往任何时候都更相关，但是当快速移动是桌上的赌注时，仅仅依靠传统的测试来防止错误已经不够了。即使测试是不可替代的，关键错误仍然会影响生产，而客户正在等待承诺的无缝体验(就在他们的应用程序中断之前)。

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

在数字商业的背景下，原地踏步就相当于输了。刘易斯·卡罗尔(Lewis Carroll)在“爱丽丝梦游仙境”(Alice In Wonderland)中说得最好，这成为了所谓的“红皇后假说”的基础：

除了是一本伟大的书中的一则精彩轶事外，红皇后假说源于一种进化论概念，即生物体必须不断适应才能生存，同时在不断变化的环境中与其他生物体竞争。

同样的想法也可以应用于业务设置，这说明了为什么每家公司都在争先恐后地自动化其CI/CD工作流。这里的二阶效应是它如何应用于测试。当您越来越快地发布代码、提高开发速度时，如何防止错误被提升呢？如果它们真的发生了，您如何快速修复它们？

时速70英里的公路车辆的安全措施与时速超过200英里的F1赛车的安全措施非常不同，因此，当您自动执行CI/CD工作流时，测试也需要发展。

根据Google Cloud的DevOps Research&；Analysis(DORA)的DevOps状态报告，更改故障率(即生产中导致服务降级并需要补救的更改的百分比)可能高达所有新代码发布的60%。对于表现优秀的人员，故障率可以保持在15%以下，但由于这只解决了已知的错误，并且是基于工程师(而不是客户)的自我报告，因此实际的故障率可能会更高。

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

这背后的一个关键驱动因素是能够以更高的频率发布较小的更改-但这不是唯一的区别。虽然所有的公司都以这样或那样的形式进行测试，但它们如何进行测试，以及它们寻找的是什么，差异很大。

在最近的一次现场小组讨论中，我们与DevOps Paradox的联合主持人Darin Pope和Viktor Fracic讨论了这个问题，Darin Pope是一位以将复杂变得简单而闻名的DevOps顾问，Viktor Fracic是首席软件交付策略师、开发人员倡导者和出版作家。以及Over Ops解决方案工程副总裁Eric Mizell。

这里提供了该对话的点播录音，其中包括如何在速度和质量与持续可靠性之间取得平衡的要点。

下面是从那次谈话中得出的三个关键结论，它们说明了为什么传统测试是不够的：

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

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

达林·波普：“对于大多数人来说，这是日常生活，我宁愿在生产过程中出现错误。