综合监控测试是一组针对生产环境的实时系统进行的功能测试。这些测试有时被称为“看门狗”、“主动监控”或“综合事务验证”，其重点是持续验证运营系统的健康状况和恢复能力。

为什么需要监控测试

传统上，软件提供商一般习惯依赖于通过众所周知的测试金字塔（单元测试、集成测试、端到端测试）中的CI/CD阶段进行软件测试，以验证产品的健康状况，并回归检查是否存在新的问题。这些测试活动都是发生在部署到生产环境并产生实时用户流量之前，在构建的测试环境或预发布环境中来运行的。在服务处于生产环境运行期间，为了不影响对真实用户业务数据的监控和报警，系统往往是受到保护而不让随意请求的。

然而，随着如今越来越多的公司组织提供更多高可用性（99.9+%服务级别协议）的产品，人们逐渐发现长期运行的分布式应用程序（通常依赖于多个硬件和软件组件）不可避免地会出现系统异常。系统各组件的频繁发布（有时每天多次）可能会进一步加剧生产环境的不稳定性。生产环境快速变化的这种趋势往往使得CI/CD阶段的测试活动并不完善，并且实际上也无法代表最终用户的使用体验和生产环境的实际能力。

对于这样的系统，项目研发团队的目标是尽量减少修复缺陷或故障所需的时间，即平均修复时间（MTTR）。这是一项在实时系统/生产环境上持续进行的工作。可以使用系统监控来检测以下问题：

• 可用性 - 整个系统或其特定功能是否可用。
• 系统事务和客户场景 - 已知的用户常用请求应该能够正常工作，而已知的无效请求则应该报错。
• 性能 - 操作的执行速度如何，以及在高负载和版本发布期间性能是否保持稳定。
• 第三方组件 - 系统所使用的云组件或其他软件组件是否发生故障。

测试右移

监控测试（Synthetic Monitoring Tests）是在生产环境中运行的一类测试活动的子集，有时也被称为生产测试（Test-in-Production）或右移测试（Shift-Right Tests）。在非常流行的测试左移中，方法是在应用程序开发生命周期中尽早进行测试（即在项目研发时间线上向左移动）。而右移测试是对左移测试的补充，并在其基础上进行了内容增加。它指的是在产品部署、发布以及发布后（即产品正在运行生产流量时）在项目周期的后期运行的测试工作。这些测试活动为现代研发团队提供了更广泛的工具集，以确保随着时间的推移，系统仍能够维持高水平的服务级别。

监控测试的设计

系统监控测试是一种使用合成数据和真实测试账户向系统注入用户行为，并验证这些行为效果的一种测试，通常是通过被动地依赖现有的监控与警报功能来实现。监控测试的组成部分包括探针（Probes）、生成数据的测试代码/账户，以及部署的监控工具，这些工具可以用于验证被测系统的工作行为以及探针本身的健康状况。

探针

探针（Probes）是用户操作行为的来源，是用以驱动测试活动的。它们针对产品的前端页面或对外开放的API接口，并在它们自己的生产环境中运行。实际上，系统监控测试与黑盒测试非常类似，并且通常会从用户的角度关注端到端的业务场景。使用与端到端（e2e）或集成测试相同的代码来实现探针是很常见的做法。

监控

由于系统监控测试在生产环境中是连续且间隔性地运行的，因此通过分析来断言系统行为需要依赖于在实时系统中使用的现有监控要素（比如日志记录、指标、分布式跟踪等）。通常，会有一组有限的测试活动以及关键指标，这些用于构建监控和警报，以断言是否符合已知的服务等级目标（SLO），并验证该系统的关键结果领域（OKR）是否得到了维护。而监控工具有效地捕获了由探针生成的真实用户监控（RUM）数据，并能分析出这些数据背后系统功能的健康状况。

系统监控测试的应用

断言被测系统

系统监控测试通常是具有统计性的。测试结果指标会与时间维度的某些历史或运行平均值进行比较（例如：在过去30天内，每天的这个时间段内，将商品添加到购物车的平均响应时间为250毫秒，标准差为平均值的正负32毫秒）。因此，如果在任何时间观察到的测量结果都在正常偏差范围内，那么系统服务很可能是健康的。

构建系统监控测试解决方案

从更高层面来看，构建系统监控测试能力通常包括以下步骤：

• 确定要验证的数据指标（比如功能结果、延迟时间等）。
• 构建一段自动化程序，该程序针对系统测量该指标，并将遥测数据收集到系统的现有监控基础架构中（比如现有监控系统中）。
• 设置监控的警报/操作/响应规则，以检测系统是否达到指标的预期目标。
• 在适当的间隔周期内连续运行自动化测试用例。

监控测试的健康状况

探针运行时（Probes runtime）自己本身就是一个生产环境，而其测试的健康状况是至关重要的。许多供应商提供基于云服务的系统来托管此类运行时环境，而一些组织则使用现有的生产环境来运行这些测试任务。无论采用哪种方式，监控监控器（monitor-the-monitor）策略都应该是生产环境预警系统的重要组成部分。

测试监控与真实用户监控

测试监控并不能取代真实用户监控（Real User Monitoring, RUM）的需求。探针是可预测的代码，用于验证特定场景，但它们并不能100%完全真实地代表用户会话的处理方式。另一方面，建议不要使用RUM来测试网站的可靠性，因为：

• 顾名思义，RUM需要用户流量。如果网站可能已经宕机，但由于没有用户访问被监控的路径，因此就不会触发任何警报。
• 测试监控和真实用户监控两者不一致的流量和使用模式使得难以进行基准测试。

风险

一般来说，在生产环境中进行测试工作会伴随着一定的风险因素，这些风险在CI/CD阶段进行的测试中并不存在。具体来说，在生产环境系统监控测试中，以下因素可能会影响生产环境正常运行：

• 损坏或无效的数据：测试注入的测试数据可能以某种方式损坏系统，请考虑使用测试架构。
• 受保护数据被泄露：在生产环境中运行的测试会生成日志或跟踪信息，而这些信息可能包含受保护的配置数据或业务数据。
• 系统过载：系统监控测试可能会导致系统出现错误或过载。
• 对其他关联的生产系统产生意外的副作用或影响。
• 非正常的技术分析结果（如流量漏斗、A/B测试结果等）。
• 认证/授权：测试需要在生产环境中运行，但访问令牌和机密信息可能会受到限制或难以获取。

系统监控测试的框架和工具

大多数重要的监控或应用性能管理（APM）供应商都拥有一款内置系统监控功能的企业级产品（见下文列表）。这些产品使得上述提到的某些风险变得无关紧要，因为解决方案的集成和运行方面都是开箱即用的（OOTB）。然而，这类解决方案通常价格不菲。

一些组织倾向于在现有基础设施上运行探针，使用已知的工具如Postman、Wrk、JMeter、Selenium，甚至自定义代码来生成监控数据。这些解决方案必须考虑将探针的生产环境与核心产品的环境隔离开来，并进行解耦，同时提供监控、地理分布和测试健康维护。

以下是几种测试监控工具或服务的示例：

• Application Insights 可用性测试 - 简单的可用性测试，允许使用多步骤Web测试进行一些自定义
• DataDog Synthetics
• Dynatrace Synthetic Monitoring
• New Relic Synthetics
• Checkly

结论

生产环境测试监控的价值仅体现在特定的系统类型中，并且它们也伴随着相关的风险和成本。然而，在适用的情况下，它们能够持续确保从用户的角度来看，系统不会出现故障。在开发PaaS/SaaS等解决方案时，系统测试监控是服务可靠性团队成功的关键，并且它们正成为高可用产品质量保证体系中不可或缺的一部分。