Threat Stack 为何使用容器实现微服务测试自动化

即使设计正确，微服务仍然很难测试。 但是，当系统架构发展到由数十或数百个连接服务组成不断变化的基础设施中的软件平台时，测试您和您的团队负责的产品就会成为一项极其复杂的任务。 为这些环境编写测试自动化非常困难，因此您需要确保从编写的测试中获得最大的价值。

在 Threat Stack，我们编写系统集成测试（一种灰盒功能测试），并且我们选择 Docker 来运行容器化测试环境。

其他类型的测试有什么问题？

一些组织仍然依赖传统的测试模型，其中白盒测试和黑盒测试被视为足够的补充测试策略。 虽然它们在认证软件方面仍然发挥着重要作用，但它们已不足以为您提供自信发布软件所需的反馈。

在这种环境中，黑盒用户验收测试的关注点过于广泛，依赖它可能会对上市时间策略产生严重影响：

• 它没有提供足够的覆盖范围，因为在运行测试所分配的时间内需要测试的可能场景太多了。
• 它运行很长时间，并且经常由于应用程序无法控制的因素而超时。
• 它必须在服务部署后运行，而不是在构建时运行，这意味着反馈与产品开发进一步分离。 在主导测试工程的左移哲学中，依赖这种测试会降低您的组织的竞争力。
• 因为它们是黑盒测试，所以确定故障原因可能是一项极其困难的任务。
• 开发人员不容易编写或维护它们。

另一方面，白盒单元测试的关注点过于狭窄，并且经常被错误地用于限定软件系统功能：

• 它没有考虑服务与组件或其他服务交互的实际行为。
• 它可以测试那些没有足够价值去维护的毫无意义的场景。
• 对于那些必须针对代码的细微改动不断更新大量测试的开发人员来说，这可能会变得十分繁重。
• 测试工程师不容易编写或维护它。

为什么要关注系统集成测试？

Threat Stack 测试工程师越来越依赖系统集成测试来测试所有这些服务，以最大化测试覆盖率，同时提供我们所需的速度和特异性，以确保应用在许多操作条件下正常运行。

集成测试是一种灰盒测试，重点关注被测软件或系统与外部组件交互时的行为。 例如：

• 数据存储，例如 PostgreSQL、Cassandra、ElasticSearch
• 消息代理，例如 Kafka
• HTTP 服务器

换句话说，您可以与之交互以验证行为的软件。 在 Threat Stack，我们主要执行复制真实情况的功能测试，但测试中的行为将在容器化环境的边界处停止，从而避免不必要的外部交互。

由于这些测试与微服务紧密耦合，您可以在自动化测试中检查和集成被测服务的代码，从而一致地识别需要执行的代码区域。 此外，这些测试可以写为用户验收测试，以便非开发人员（例如产品经理和 QA 工程师）可以更轻松地理解测试中的行为。

换句话说：

给定一组条件

当服务收到此输入时（或此条件影响服务）

然后，服务将以预期的方式运行并产生预期的副作用

这些功能测试不仅易于理解和编写，而且还与微服务的代码紧密耦合，因此开发人员可以在整个开发过程中或之后由专门的测试工程师轻松运行和更新它们。

为什么要使用容器？

容器对于测试系统非常有用，因为它们允许您在测试期间以最少的资源快速重现测试环境，然后在测试完成后轻松清理。 与许多黑盒测试自动化不同，您不需要昂贵的、始终在线的测试环境来进行集成测试。 运行测试时，微服务的行为可以在测试环境中重现。 

一旦您定义了一个镜像生产中的微服务环境的容器化环境，那么您的测试框架就会成为与被测试的组件或微服务交互的外部客户端或模拟服务。 这确保测试代码驱动测试的各个方面，从而使您能够控制测试的更多方面。

在开始时， Docker是一个快速启动容器化环境的良好平台。 使用Docker Compose ，您可以轻松定义和运行被测应用的各个部分，无论是在本地还是在 CI 中使用相同的代码。 如果您的组织支持使用其他容器基础设施工具和服务（例如Kubernetes 、 AWS EKS或AWS Fargate ），也可以用于部署测试环境。

结论

最终，将测试工作重点放在集成测试上而不是其他类型的自动化上，会给您带来两大好处：

• 您的微服务测试被左移，因此它们在部署之前执行，这为您提供了更快的迭代开发反馈。
• 您仍然针对真实服务和组件运行测试，这意味着您正在减少测试覆盖率差距，但仍在运行功能测试。