为什么测试对云原生流水线不再足够

2020-05-08 17:30


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

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

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

我们正处在一个前所未有的时代,一个颠覆性的时代,历史悠久的金融机构正面临着来自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:“我曾听一家公司说,他们试图对失去客户和收入与推出软件的风险程度进行风险评估。他们需要新的特性。这是一个平衡。我不认为任何人有完美的平衡,但你看到它发生了很多,它回到我想要能够快速移动/快速修复的概念。如何从失败中走出来才是真正的挑战。”

总结

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