在最近的一次连续讨论（c9d9）视频播客中，专家小组成员讨论了连续测试。我们的专家小组包括：Splunk的首席技术倡导者Andi Mann，Dynatrace的技术策略师Andreas Grabbner；Parasoft的布道者Arthur Hicken；自动化狂热者Javier Delgado；顾问、作家和演讲者Jeff Sussna；以及我们自己的Sam Fell和Anders Wallgren。在这一集中，小组成员讨论了持续测试的好处和挑战以及成功的先决条件。继续阅读他们的全部见解！»持续测试：它是什么？为什么？ 持续的测试并不是描述它的最佳方式-持续的实验/创新才是我们想要的@grabenerandi c9d9pic.twitter.com/izMC6Y3wBl-CloudBees（@electricloud）2017年5月23日如果你继续尽可能多的测试，你会得到更高的反馈，并对@witokondoria'c9d9'devops更有信心pic.twitter.com/0ee35jJglC-CloudBees（@electricloud）2017年5月23日持续测试是一种策略-最终目标是降低@anders_wallgren c9d9版本的业务风险pic.twitter.com/eBkdasmfHe-CloudBees（@electricloud）2017年5月23日Mann说："持续测试能够快速交付软件质量，我们说DevOps是关于交付更快、质量更好的产品。我认为这就是持续测试带给聚会的核心，更好的软件更快的理念，是速度和质量。如果软件是垃圾软件，很容易很快就出来。如果你有一整年的时间放弃一个功能，那么你很容易得到好的软件。但我认为，持续地高质量地做这件事是件大事。当你进入一个虚拟的连续测试周期时，不仅仅是为了功能质量，不仅仅是为了遵从性和代码覆盖率，还有一件事，我认为非常重要的是要进行影响分析。当你谈到连续测试时，能够在发布后进行测试，事实上，我认为这也是很重要的一部分。""这不是持续的测试，而是持续的实验，"格拉伯纳解释道："我喜欢持续的实验，因为我认为这就是事实。如果你有一篇论文，你就要做实验，弄清楚这是人们真正喜欢的东西。事实上，我不喜欢"持续测试"这个词，因为我认为测试太多了，至少在我看来，是在我们真正给客户提供一些东西之前，我们在早期就做的事情。更多的是这种持续的实验，一种持续的创新，你想出一个想法，然后有不同的方法来测试这个想法，它可能涉及原型，可能涉及复制测试，然后通过a/B测试，通过蓝绿部署，基本上可以获得关于您所做工作是否实际良好的反馈。"Hicken解释说，持续测试实际上更像是持续评估："持续评估的想法其实就是我们所说的。我们在看代码，然后说‘准备好了吗？’？更糟吗？更好吗？"我认为这是关键，因为如果我们考虑持续交付，持续部署，这对很多组织来说都是一个圣杯。有些人已经做到了。对大多数人来说，这是我们努力追求的东西。所以如果我们看看，我们有这些测试，我们有正在进行的编码，我们有正在进行的集成，但在某个时候，我们必须能够说，"我可以部署这个吗？"？我让事情变得更糟了吗？我做得更好了吗？"这就是持续测试、持续评估的地方。这就是简单的自动化与持续评估之间的巨大区别，因为自动化只是执行测试。"持续测试有助于建立信任度perdelgado："我相信持续测试是一种渐进式测试杀手。如果你继续尽可能多的测试，你会得到更高的反馈，你不能保证你有传统的缺陷，但至少你可以有一些信心。与持续交付相关，这种信心是我们唯一可以宣扬的东西。只有当我们至少有一个自信的时候，我们才能快乐。我会简化一切，继续测试我们现有的整个套件，我们必须控制没有人会做坏事，但这是您的主要反馈，除了产品处于同一级别之外。"Wallgren说："持续测试使我们能够将业务风险降至最低，我认为持续测试的方式是将其视为一种策略。该策略的最终目标之一是确保在发布过程中降低业务风险，这样当代码暴露给客户，或者客户接触到代码时，这将最小化风险，这就是策略。测试自动化是我们用来尽可能多地实现连续测试的一种策略。但我认为，持续测试的重点不在于基本的单元测试，或者代码的格式是否正确，我们是否运行并发现了错误，以及所有这些类型的东西，这当然是整个管道的一部分。但是，我们最关心的是业务风险，而不一定是技术风险。我们准备好释放了吗？我们现在可以开始生产了吗？"SUS建议，在进行连续测试时，应考虑连续两个级别。一个是开发和部署技术IT管道的一部分。但我认为它实际上是在那之前开始的。鉴于我们现在所处的世界，我们必须将持续测试视为我们处理整个业务的方法。如果你看看像设计思维和精益用户体验，它们实际上是关于持续测试的，你有这个好主意，你认为你是同情心，然后你必须做一些用户测试，或者你做一个MVP。关于MVP到底是什么，我已经进行了很多有趣的讨论，但实际上，它所要做的是测试你的假设，然后这种流到技术管道中。我喜欢思考DevOps之类的事情的方式是，它实际上使我们能够更好地测试我们的假设，因为我们可以在真实世界中发现真实客户使用真实系统，这实际上是唯一一种你能够真正知道你所做的是否有效的方法，就是看看人们是如何实际使用它的。"»持续测试：挑战 在右侧发现问题的成本异常昂贵@samueldfell#c9d9pic.twitter.com/VE3FrrW0ud-CloudBees（@electricloud）2017年5月23日我们不能只做更多的测试，我们做的测试越多，我们的变体和噪音就越多-测试更智能！@编解码器c9d9pic.twitter.com/ZOf3kexLE9-CloudBees（@electricloud）2017年5月23日我看到的最大的反对意见是"我们如何跟上我们的测试？"@杰夫斯纳c9d9软件测试devopspic.twitter.com/NV6PVwCeEz-CloudBees（@electricloud）2017年5月23日分析连续的、自动化的测试是Mann认为的一个主要挑战："我看到我的客户面临的一个重大挑战是，他们正在运行所有这些自动化测试，而且其速度和输出量都非常难以分析和说‘完成了。’作为一个人，从多个测试工具中吸收所有这些输出，从白盒中吸收黑盒，静态分析，动态分析，代码覆盖率，相对于功能测试，相对于回归，所有这些东西都很难。因此，自动化测试分析，我认为，是一件我看到了很多精力投入。当然，我已经实现了自动化测试，但现在我必须坐下来三个小时，试着弄清楚它是否有效。因此，进行能够反馈到自动化工具中的分析，以使持续的流程保持同步，我认为这是我目前面临的挑战的一部分。"确保开发人员和操作团队都能看到连续测试分析是一项挑战，但很重要，格拉伯纳解释说："重要的是将其向左移动，使开发人员尽可能容易地获得即时反馈，但也要向右移动。右移不仅意味着我应该对这个特性在我的开发和测试环境中的表现感兴趣，而且还应该对它的使用方式感兴趣，因为如果我知道我的特性实际使用的频率以及它的行为，这实际上会让我更深入地了解我所产生的潜在影响。因为如果我正在开发一个几乎无人使用的特性，那么进行更改就更容易了。如果这是我的80个用户使用的功能，而且是业务关键，那么我甚至需要做更多的测试，我需要更加小心。因此，我们要确保左倾，尽早发现问题，使之变得非常容易，并将其纳入生产线，同时还要从生产中提取数据，以便我们知道如果我犯了错误，潜在的影响是什么。"希肯建议说："我认为人们缺少的是，我们确实需要更聪明地进行测试。这意味着，当我查看覆盖率时，我必须问，‘我需要更多的测试来覆盖这个吗？’？当我在看嘈杂的测试时，如果我有一个测试套件需要我花三个小时来分析，那就意味着我忽略了大部分测试。应关闭忽略的测试。我会关掉它，因为至少你会注意到其他的变化，这是非常重要的。向左移动是理解何时进行更改的关键，如果我有大量需要花费时间的好测试，那么我必须运行的最小数量是多少？什么能告诉我它是安全的？我不想测试所有的东西，但我不只是想测试我更改的代码行。我想测试依赖于代码t行的东西