什么是持续负载测试？
当我们规划负载测试时，不应该考虑“左移”或“右移”负载测试，而是应该把这种测试活动集成在软件开发生命周期的所有阶段。负载测试可以定义为对系统提出一个需求并对性能进行度量。“continue”这个词的意思是持续进行或者中断后继续。作为整个交付管道的一部分，持续测试是执行自动化测试的过程。持续负载测试是一项风险管理活动。软件应用的风险通常会转化为更重要的商业风险，无论是财务风险还是公司的市值风险。与性能相关的风险尤其如此，影响范围往往很大。
持续负载测试的核心思想很简单——随着开发人员不断开发新功能并对应用程序进行更改，如果能立即准确地知道每个更改会对性能产生什么样的影响，难道不是很令人惊叹吗?
必须在压力下测试新应用程序的性能——在构建过程完成之后，但发布到生产环境之前。由于大多数开发团队都引入了有效的持续集成（CI），性能测试就变成了CI流水线中的一个阶段——主要是在回归测试之后，但在生产部署之前执行。
持续负载测试的目标
持续负载测试的目标包括以下几点：
1、证明应用程序满足性能目标。负载测试的目标必须与业务需求相关联，并代表与真实客户相关的真实业务场景。每个公司都有不同的关键性能约束。
2、规划应用的容量并应对增长。即使现阶段应用程序的性能很出色，如果客户、请求或数据集的数量突然增加，也不一定能避免崩溃。为增长做准备是一项危险的挑战。性能测试有助于构建容量规划模型。
3、跟踪有价值的性能指标。使用该应用的用户应该可以收到性能报告，也许是通报性能良好的“绿色”报告，也许是报告性能问题的警告。设计良好的性能测试策略可以提供许多关键指标，以便业务用户可以看到性能趋势并做好应对。这些指标可以通过用户体验、极限值和业务领域(例如，响应时间、最大吞吐量、资源使用等)来确定。
4、识别与负载有关的弱点。关于风险以及如何暴露风险的知识是制定风险管理策略的基础。性能压力测试在于如何发现这些风险点，并提前提供所有必要的信息，帮助我们做出合理的风险管理决策。
真正的挑战在于上述思想的实际应用。开发一个完全自动化的性能回归和压力测试系统非常重要，然而，对于一些开发团队来说这属于“火箭科学”的难度级别。
为什么要进行持续负载测试？
性能
性能是整个可测量应用程序度量范围的术语。这些指标可以从页面加载时间开始，然后跨度到并发用户数、页面组件的来源、浏览器缓存、每分钟的页面浏览量等。
可用性
可用性表现为“臭名昭著”的HTTP 503页面。这类问题属于客户的不良体验，在负载测试中具有很高的优先级。
可靠性
可靠性度量本质上是询问应用程序是否返回预期的结果。可靠性问题涉及的领域非常广，在脚本化测试的情况下很难发现，因此探索式负载测试是发现可靠性问题的一种很好的方法。
可伸缩性
可伸缩性涵盖了各种观点，从由于意外增加的工作负载而向上或向下扩展基础设施，到仅仅知道基础设施是否正确地扩展到日常操作。响应延时、服务降级、交易不完整等问题都会增加用户的焦虑。
何时进行持续负载测试?
应用程序中的性能问题被视为是一个“系统问题”。把负载测试留到生产阶段就和把功能测试留到创建阶段一样危险。通过预先进行负载测试，我们可以了解组件级别的性能，这是一种更轻松、高度可重复的测试方法。这与单元测试和API测试的概念类似。越早发现问题，越容易调试。
在产品的DevOps周期中进行产品发布后的线上负载测试也同样重要，适合解决可用性、可伸缩性和可靠性方面和生产规模相关的问题，提供了对生产行为的关键洞察，并有助于验证在开发期间针对风险缓解方案进行的负载测试。
持续负载试验的特点
灵活性。
性能测试几乎总是自动化的，因为使用手工测试方法来加载大量的负载是非常困难的。我们不可能手工点击“提交”按钮一万次。由于性能测试中固有的高水平自动化，可以根据需要在任何时候执行，包括休息日和周末。
覆盖率。
性能测试能够迅速覆盖产品功能的广泛领域。
性能测试提供了对重要功能的“足够好的”覆盖，而不需要深入功能。如果一个功能缺陷存在于一个重要的特性中，那么它经常会在性能测试的网络中被捕获。性能测试本质上强化了产品的功能验证。
需要注意的是，不要让性能测试变成公认的功能测试，因为这样做会使团队失去对性能问题的关注。然而，如果将功能测试和性能测试结合起来使用，它们就会成为发现重大缺陷的得力合作伙伴。
有效性。
性能测试有助于立即捕获难以确定的缺陷。
大多数与性能相关的错误发生在“弱代码”中。当代码行执行一次时，有缺陷的代码更改对性能的影响很小。但当执行数千次或更多次数时，它们会产生显著的性能消减效果。小小的性能延迟导致系统每秒可以处理的事务数量大幅减少。
关键是产品功能的更改通常体现为规定性的内容，功能代码的更改会影响系统在设计和预期方面表现出不同的行为。然而，在任何情况下，引起性能变化的代码更改，特别是带来负面影响的更改，都不太愿意成为规定性的，并且必然是本意良好的更改带来的负面影响。
快速获得性能问题的类型是开发人员查找缺陷根因并修复的关键，开发人员和测试人员就可以把更多的时间集中准备发布高质量的产品上面。
如何提高连续负载测试
选择合适的工具
选择一个支持CI的工具，可以快速比较版本并检测与Git repository manager的差异。我是Apache JMeter的支持者，它很适合做负载测试，但测试是以XML的形式被保存的。对于CI来说，使用依赖于代码或简单文本的东西是更明智的，会让对比结果和发现差异变得更简单。因此，开源工具Gatling和Taurus非常适合这种测试。
考虑测试级别
加载模拟是端到端的，影响浏览器执行的操作(用户交互)。这些测试并不容易维护，因为它们对这些HTTP合作(针对Web系统时)中的更改很敏感。对于CI来说，更好的策略是进行API层的自动化测试，从而影响REST接口调用。
这些测试在计划和维护上更简单、成本更低，但与进行负载模拟相比，可以更快地获得有价值的信息。
构建正确的测试基础架构
在任何类型的负载测试中，都应该充分利用测试基础设施，否则，结果将无法重现，发现误报将更具挑战性。测试基础架构越接近生产环境，测试结果就越准确。
但是，如果您没有这样一个用于连续负载测试的测试基础设施，也不要担心。在规模缩小的基础设施上运行测试可能会更好。通过这样做，将不需要那么多机器来生成接近崩溃点的负载，并且更容易了解在极限状态下运行的系统。
把频率和时间调下来
首先更频繁地测试最重要的东西。压力测试不能穷尽所有场景，因为创建和维护成本很高。关键是组织和保持较少的测试数量。在所有的测试中选择最重要的，将它们放在不同的阶段，即持续交付管道中的早期阶段，并为每次构建都运行这些测试。然后每天运行一次完整的回归测试套件。
创建负载场景和断言
哪些性能测试需要持续运行?在谈论负载模拟时，必须考虑到用户会如何使用系统并试图进行匹配。在这种情况下，通过考虑如何根据用户交互来利用API来做类似的事情。在开发人员的帮助下，测试人员可以通过检测日志来获取相关数据。
另一种方法是尝试触及接近基础设施临界点的固定负载。然后根据从底层执行中获得的结果定义断言。使用这种方法，可以确保在持续集成中立即发现哪些代码变更导致了性能降级。
持续负载测试技术
首先，应该建立基本的DevOps标准。如果QA和性能团队是独立的，他们应该被重新安排。运营团队成员应该与开发团队进行协调。这些运维工程师在隔离、复制和描述导致问题的环境变量方面成为自动化专家，并确保测试工具不断改进。持续交付流水线更加高效，让开发人员、QA工程师和经理直接了解应用程序上线前的每个阶段发生了什么。
第二，如果测试范围很广，就需要分解它们。我们的目标是将测试组件化，并在半小时到一小时内运行尽可能多的测试。测试是在API层完成的，这样其他服务就可以同时测试，但彼此独立。每个测试都有一个基础目标，并且应该为一个特定的假设场景提供答案。
第三，尽可能用模拟服务来替换下游服务，可以更快地测试相关服务的假设场景，而不需要等到下游服务稳定之后才能进行测试。
持续负载测试的工具或平台
有很多工具/平台可以用于持续负载测试，例如：Neoload、Load Impact、Apache JMeter、LoadNinja、Web load
英文原版链接：https://www.xenonstack.com/blog/continuous-load-testing/