shift-left testing

What is shift-left testing?
您越早发现代码中的问题，它们的影响就越小。处理它们的成本也更低。本文，我们将探讨向左移动的方法以及如何在你的组织中实现向左移动。
The Shift Left Testing Methodology
“向左移动”是关于将关键测试实践移到开发生命周期的早期。这个术语在敏捷、连续和DevOps计划中尤其常见。那么，为什么需要执行早期的软件测试呢?许多测试活动发生在周期的后期，此时需要花费更长的时间来找出哪里出了问题，并且需要花费更多的成本来修复。向左转移就是将缺陷的识别和预防转移到更早的时候。当你在开发周期的后期等待执行测试实践时，你的非功能性业务需求(比如安全和性能测试)会从根本上根植于你的代码中，你所能做的就是修补它们而不是正确地修复它们。
When do bugs enter the code?
bug什么时候出现在代码中?
左移测试策略在Capers Jones的著名图表中得到了很好的说明，该图表显示了在软件开发的每个阶段，引入到软件中的错误/缺陷的成本不断增加。图的第一部分显示了在编码阶段出现的绝大多数错误，这是意料之中的。

不管他们是否犯了实际的错误，或者误解了需求，或者没有考虑到特定代码片段的后果，开发人员都会在代码生成时引入缺陷。
当需要将各个部分组合在一起时，缺陷也会引入到应用程序中，特别是在涉及多个团队的情况下(并且随着像微服务这样的现代体系结构变得更加复杂)。
When are those bugs found?
这些bug是什么时候发现的?
当我们将显示缺陷所在的那条线覆盖在正在引入的缺陷图上时，它就开始变得有趣了。
注意，它基本上是第一行的倒数:

当然，这并不奇怪，因为通常在开始测试时就会发现bug，而且在一切准备就绪之前，如果没有合适的基础设施来开始测试可能会很困难(稍后将详细介绍)。我们在这里看到的是，bug大多是在编码过程中引入的，但几乎从来没有在那个阶段发现过。
What does it cost to fix bugs?
修复错误的成本是多少?
因为大多数错误都是在编码期间引入的，但直到后期才被发现，所以了解在开发的每个阶段修复缺陷的成本差异就变得很重要。如下所示:

现在它开始变得非常有趣了，因为我们看到缺陷发现的越晚成本就会急剧增加。让一个bug潜入到系统测试中是在编码期间找到它的成本的40倍，或者是在单元测试期间找到相同bug的成本的10倍。当你看到让bug溜进实际部署的数量时，你就会发现它的代价非常昂贵。
成本上升的原因包括:
 跟踪问题所花费的时间和精力。测试用例越复杂(越大)，就越难找出哪一部分才是真正的麻烦制造者。
 当数据库或第三方api等依赖系统被引入时，在开发人员的桌面上再现缺陷的挑战。(在这些情况下，组织通常会经历缺陷检测和缺陷补救之间的多周延迟。)
 修复缺陷所需的变更的影响。如果只是一个简单的bug，那也没什么大不了的。但是，如果你在很多地方都这样做过，或者你使用了错误的框架，或者你构建的代码在预期的负载下没有足够的可伸缩性，或者不能保证安全……
Test early, test often (the shift left approach)
现在观察添加到下图的橙色线，它说明了一个基于早期测试的缺陷检测周期(向左移动):

你可以看到橙色的检测曲线在便宜的那一边变得更大而在昂贵的那一边变得更小，给我们带来了相当显著的成本降低。左移位依赖于一个更成熟的发展实践中,例如一个基于软件测试金字塔(开发人员创建的一组单元测试覆盖的代码相当不错,API和功能测试人员和测试人员做尽可能多和尽可能减少依赖上升周期较迟的测试有足够的手动/ UI测试来证明一切都是工作)。通过这种方式，后期循环测试是为了证明功能，而不是寻找bug。尽早测试，经常测试是左撇子的口头禅。
Shifting even farther left
进一步向左移动
一些组织向左移动在这一点上停止。但你会得到更多的价值，当你进一步向左，进入编码本身。毕竟，这是引入bug的地方——所以让我们在开发还在进行的时候开始寻找它们。这就是我们从静态代码分析中获益的地方——通过发现更靠左的缺陷，缺陷是最便宜的修复:

使用静态分析，您可以在实际编码阶段开始查找错误，此时查找错误的成本是最低的。
您可以清楚地看到，在“测试”开始之前找到东西是最划算的。它也是最省时的，因为它不会给开发人员在试图重现错误或理解失败时留下任何问题。能够将缺陷补救周期从几天或几周缩短到几小时或几分钟是非常有用的。
Beware of just shifting the burden to the developer
注意不要将负担给开发人员
但是在这个步骤中有一个危险，那就是无意中给软件开发人员增加了太多的测试负担。重要的是记住你看看图,是,虽然缺陷修复的成本会大幅提高,左边的资源可能在软件生命周期中最高的成本——更不用说,你带他们远离关注发展的功能。所以你必须做正确的事情，把所有这些带到下一个层次。您不只是想更早地发现缺陷，您实际上是想在一开始就减少您放入应用程序中的缺陷的数量。请看下面的图表，左边是可爱的缩小了的泡泡。

但是，等等，这里有一个陷阱!如果你奖励那些发现和修复bug的人，现在他们发现的bug会更少，这正是你真正想要的，但前提是你一开始就真正减少了引入的bug的数量。度量进入该领域的缺陷的数量可能是一个更有用的度量。
So how do you shift-left
这是我们在开发时做的所有事情的核心。但是为了简洁起见，左移测试方法分为两个主要活动。
Apply development testing best practices
应用开发测试最佳实践
做早期的开发实践，例如静态代码分析和单元测试，可以帮助识别和防止过程早期的缺陷。
重要的是要记住，我们的目标不是找到bug，而是减少bug的数量(特别是那些出现在发行版中的bug)。最终，在一开始就创建更少的bug要比发现更多的bug更有价值——而且成本更低。这就是为什么通过标记可能“工作”但仍然不安全的代码，以一种积极的、预防性的方式制定安全关键编码标准。
Leverage service virtualization to enable continuous testing
利用服务虚拟化来支持持续测试
接下来，您必须接受在开发过程的所有阶段(包括后面的阶段)创建的测试，并继续向前执行它们。对于采用敏捷开发实践的团队来说，在整个开发过程中提供持续的反馈是至关重要的。单元测试可以轻松地连续执行，但是由于外部系统依赖关系，将后期功能测试的执行保留下来通常比较困难，而这正是您可以利用服务虚拟化来支持连续测试的地方。服务虚拟化使您能够模拟可用性有限的依赖系统，例如大型机、访问费用、第三方服务，或者可能还没有准备好的系统。通过模拟它们，您可以在没有整个系统可用的情况下执行功能测试，并且您可以将测试执行一直移到开发桌面。在性能测试方面，服务虚拟化使您能够在一切准备就绪之前进行测试，而无需在系统中拥有所有东西的完整实验室。您甚至可以运行各种假设场景，比如appserver快而数据库慢(这在现实世界中很难实现)。或者，如果我的服务器开始抛出一些奇怪的错误，比如500错误——这会如何影响系统性能?你可以随心所欲地推行这个系统，而且越早越好。(了解更多关于如何切换到左移的性能测试。)类似地，您可以更早地开始进行安全性测试。与物理系统的解耦允许您做一些更有趣的事情，即使模拟系统以一种邪恶的方式运行。现在您可以真正进入安全性测试……您可以让系统向您大量发送数据包，或者发送格式不正确的数据，或者攻击者通常使用的许多其他exploit中的任何一个，而不只是检查系统中的受污染数据和DDoS。因此，您不仅可以更早地进行测试(左侧)，而且还可以比在测试实验室或生产系统中进行更深层次的测试。
Summary
经过几十年证明有效的质量保证过程可以用来大幅度提高质量，同时节省时间和金钱。通过利用现代软件测试技术，您可以实现安全、可靠和安全的软件。通过将测试移到左侧，您可以通过更早地发现bug来降低测试成本，同时还可以减少您在第一时间放入代码中的bug数量。

最后

以上就是洁净火为你收集整理的shift-left testing的全部内容，希望文章能够帮你解决shift-left testing所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。