灵感
我第一次接触到“合成测试”这个词是在一两年前。当时，我的任务是实现一个简单的定期测试，以验证一个关键端点的健康状况，这是我们团队生产准备检查表的一部分。我使用了Datadog的合成监控功能来完成这个任务。这个过程非常简单且实用，但当时我并没有意识到它的更大意义。
后来，当我在获得AWS解决方案架构师专业认证的过程中再次遇到这个术语时，我受到了启发，决定写下关于这个话题的文章。这次我看到了它在分布式系统中为实现和达成运营目标所带来的重要价值。本文旨在深入探讨这一主题，并分享关于它应用的“3W”（是什么，为什么，何时）的合理默认建议。
什么是合成测试？
合成测试也被称为语义测试、合成监控测试以及主动/预主动监控测试。像RUM（真实用户监控）和APM（应用性能管理）这样的流行监控方法是被动的，因为只有在用户遇到问题后才会被发现。合成测试旨在缓解这一缺点。合成测试的主要目的是在用户体验到问题之前捕捉到这些问题。这是通过在实时环境中主动探测您的应用程序来实现的。
合成监控测试设计模块。摘自微软工程手册——[https://microsoft.github.io/code-with-engineering-playbook/automated-testing/synthetic-monitoring-tests/](https://microsoft.github.io/code-with-engineering-playbook/automated-testing/synthetic-monitoring-tests/)
** 根据DataDog的定义**——“合成测试是一种通过在生产或类似生产环境中模拟真实用户流量，来识别关键用户路径中性能问题的方法。”
** 根据微软的定义**——“合成测试是一组功能性测试，针对生产环境中的实时系统，持续验证其健康状况和弹性。”
** 根据MartinFowler.com的定义**——“合成测试是应用程序自动化测试的一个子集，定期针对生产系统运
综合所有这些定义，有效的合成测试可以分为四个部分：
关注领域 — 绝对关键路径（关键用户流程和业务功能）
输入数据 — 模拟真实用户数据
测试环境（实时） — 生产环境和/或类似生产的环境
结果 —
- 发现失败的业务需求
- 识别运营问题（功能性、性能等）
- 持续验证产品的健康状况和弹性
合成测试的类别
合成测试可以根据以下两个不同的标准分为不同的类型：
基于测试的应用层：
- 浏览器测试
- API测试 — 根据应用程序使用的数据交换协议分为不同的类型，例如HTTP、SSL、TCP、DNS等。
基于测试的应用方面：
- 可用性测试 — 例如，健康检查
- 性能测试 — 例如，负载测试、压力测试等
- 事务流测试 — 确保功能流程的可靠性，这可能涉及多个组件。
- 用户路径测试 — 确保特定用户路径的可靠性，这可能涉及单个组件或多个组件。
- 冒烟测试 — 稳定性回归测试或向后兼容性测试。
合理的默认设置：3个W——“哪里”、“什么”及“哪种”
-
生产环境 — 仅限读取操作
-
简单的健康检查
- 监控关键功能的运行时间
-
类似生产的环境 — 读取和写入操作
-
与上面相同，但具有更多灵活性
- 模拟进入新市场 — 例如，向新的业务线开放功能
- 监控第三方API
- 集成到部署管道中，以便更快且一致的反馈
-
如何操作
以下工具可以用于设置合成测试，难易程度各不相同：
API测试：
- Datadog合成API测试
- Postman（用于安全集成到部署管道的SDK）
- AWS CloudWatch Synthetics Canary Blueprints
- Spring Boot Actuators（需与其他工具配合使用）
- JMeter
- Wrk
UI测试：
- AWS CloudWatch Synthetics Canary Blueprints
- Cypress
- Selenium
优势
- 从MTBF（平均故障间隔时间）转向MTTR（平均恢复时间） — 在分布式系统中，由于涉及多个服务，并且这些服务可能由全球不同的团队负责，因此很难将MTBF保持在最小值。通过在开发生命周期和生产中进行测试，转变心态是缓解这一问题的一种方式。John Allspaw曾说过：“对于大多数类型的故障，MTTR比MTBF更重要。”
- 减少MTTR — 通过主动的测试和监控方法，能够更早地发现问题。根据问题的类型，可以在用户体验到问题之前解决它或回滚。
- 自信地扩展到新市场和地区 — 有效的合成监控测试可以让您确信，即使偶然有bug进入生产环境，也会被迅速发现。这使得扩展用户群到新市场和地区变得更加容易。
- 实现性能目标 — 更容易遵守和维护系统的OKR、SLO和SLA。
- 通知性能目标 — 牢记AWS可观察性的格言：“记住要构建、测量、学习、重复！”合成测试可以帮助您为应用的当前状态设定合理的基准预期。好的基准指标并不是一成不变的。合成测试与被动监控结合使用，可以为这些指标的演变提供信息。
- 更频繁的发布 — 这是实现每日部署的必备条件。
缺点
- 成本/投入 vs 价值 — UI/浏览器测试可能非常脆弱。如果UI经常更改，设置测试的前期投入可能不会带来长期收益。
结论
从AWS无服务器徽章来看：“当你在规模化运营无服务器应用时，你无法承担盲目操作的代价。你需要能够回答重要的运营和业务问题。”
将合成测试与被动监控结合使用，不仅可以更深入地了解这些问题，还能提出更好的问题。这也重申了为应用程序设定的运营目标。
在不同的层面上，大多数开发团队都有简单的合成测试，如健康检查。可以更进一步，充分利用合成测试。服务“健康”并不一定意味着它是“功能正常”的。为什么要等用户发现问题呢？主动出击！
参考文献
