本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

部署前活动

环境设计

您测试和评估应用程序的环境会影响您对其进行测试的彻底程度，以及您对这些结果是否能准确反映生产环境实际情况的信心。您可以使用 Amazon DynamoDB 等服务，在开发者计算机上本地执行一些集成测试（请参阅 DynamoDB 文档中的设置 DynamoDB local）。但是，在某些时候，您需要在复制生产环境的环境中进行测试，以获得最高可信度的测试结果。这种环境会产生费用，因此我们建议您对环境采取分阶段或管线化方法，将类似生产环境的测试环境放在管线的后期阶段。

集成测试

集成测试是测试应用程序中明确定义的组件在使用外部依赖关系运行时能否正确执行其功能的过程。这些外部依赖关系可能是其他自定义开发的组件、应用程序使用的 AWS 服务、第三方依赖关系和本地依赖关系。  本指南重点介绍验证应用程序韧性的集成测试。其假设已经存在可以验证软件功能准确性的单元测试和集成测试。

我们建议您设计专门测试已实施韧性模式的集成测试，例如断路器模式或卸除负载（请参阅第二阶段：设计与实施）。面向韧性的集成测试通常涉及向应用程序施加特定的负载，或者使用 AWS Fault Injection Service（AWS FIS）等功能故意向环境中引入中断。理想情况下，应将所有集成测试作为 CI/CD 管线的一部分运行，并确保每次提交代码时都运行测试。这可以帮助您快速检测导致违反韧性目标的任何代码或配置变更并作出反应。大规模分布式应用程序非常复杂，即使是微小的变更也可能会严重影响应用程序中看似无关部分的韧性。尝试在每次提交时运行测试。AWS 为运行 CI/CD 管线和其他 DevOps 工具提供了一套出色的工具。有关更多信息，请参阅 AWS 网站上的 Introduction to DevOps on AWS。

自动化部署管线

部署到预生产环境并在其中进行测试是一项重复且复杂的任务，最好留给自动化处理。该过程的自动化可以腾出人力资源，并减少出错的机会。自动化此过程的机制通常称为管线。在创建管线时，我们建议您设置一系列越来越接近生产配置的测试环境。您可以使用这一系列的环境来反复测试应用程序。第一个环境提供的功能集比生产环境更为有限，但成本要低得多。后续环境应添加服务并扩展，以更接近地反映生产环境。

首先在第一个环境中进行测试。在您的部署通过第一个测试环境中的所有测试后，让应用程序在一定负载下运行一段时间，以观察是否会随着时间的推移出现任何问题。确认您已正确配置可观测性（请参阅本指南后面的告警精度），以便能够检测到出现的任何问题。此观测期成功完成后，将您的应用程序部署到下一个测试环境并重复该过程，在环境支持的范围内添加其他测试或负载。以这种方式对应用程序进行充分的测试后，您可以使用之前设置的部署方法将应用程序部署到生产环境中（请参阅本指南前面的定义 CI/CD 策略）。Amazon Builders Library 中的 Automating safe, hands-off deployments 一文是一个优秀的资源，其中介绍了 Amazon 如何自动化代码部署。生产部署之前的环境数量会有所不同，具体视应用程序的复杂性及其依赖关系的类型而定。

负载测试

从表面上看，负载测试与集成测试类似。您可以测试应用程序的某项独立功能及其外部依赖关系，以验证其是否按预期运行。负载测试不仅仅是集成测试，其侧重于应用程序在明确定义的负载下如何运行。负载测试需要验证功能是否正确，因此必须在成功完成集成测试之后进行。重要的是要了解应用程序在预期负载下的响应情况，以及负载超出预期时应用程序的行为。这可以帮助您验证是否已经实施了必要的机制，以确保您的应用程序在极端负载下仍能保持韧性。有关 AWS 上负载测试的全面指南，请参阅 AWS Solutions Library 中的 Distributed Load Testing on AWS。