如何测试微服务？

Question

我负责领导一个QA团队，我们的任务之一是开发自动微服务测试。

我们已经成功地测试了这些微服务一年了。总之，我们的测试过程是：

1. 审查文件
2. 通常，Microservice输出将相应地变化到6个输入组合。我们为那些~6测试场景编写了规范
3. 使用我们的测试数据使用REST生成消息到源主题
4. Microservices将使用和处理这些输入消息，映射字段，聚合/转换数据，执行计算并生成输出消息。
5. 使用REST使用输出主题中的消息并执行断言

附加信息:开发人员负责单元测试。QA团队负责功能测试、集成测试、性能测试和探索性测试。我们的自动化测试已经集成到CI/CD工作流中。

然而，公司正在从Docker迁移到Kubernetes，我们将使用不同的REST API，因此测试将被重构。因此，在重构DevOps团队之前，如果我们改变了测试范式，而不是开发自动微服务测试，QA团队将开发“测试微服务”，那该怎么办？这些“测试微服务”将在生产环境中运行，并验证所有生成的消息。在我看来，这违背了所有好的测试实践，但我想听听您的意见。

1. 开发微服务是一项发展任务，而不是QA任务
2. 我们在生产中会有两倍多的微服务(在阶段中运行这些“测试微服务”会更有意义，但他们说生产)？这将大大降低服务器的性能。
3. 这有什么意义呢？我看不出这样做有什么好处，只有缺点

此外，我们的自动微服务测试也可以做到这一点，我们不需要开发“测试微服务”。但同样，也只有缺点。每个Microservice每天生成数万条消息。为什么我们要执行成千上万的请求来测试每个Microservice，而测试场景已经确定，并且输出将相应地变化到六个输入组合？我们可以执行相同的任务，只执行6个请求，从而避免服务器性能的下降。

Answer 1

对于团队目前的工作方式以及他们期望的工作方式，我们需要更加清楚的说明。

通过阅读这个问题，看起来当前的测试策略如下所示：

这个实现的巨大缺点：

1. 这就去掉了微服务体系结构的基本支柱，这个测试创建了微服务之间的依赖关系。
2. 您将无法测试微服务实现。在这里，即使体系结构遵循微服务规则，测试策略仍然遵循整体测试产品的单一方法。
3. 即使一个模块失败，测试也无法测试其他模块。

DevOps团队推荐的是：

的优点：

1. 您将测试单个微服务。
2. 您不必开发微服务，而是创建模拟响应的模拟服务器，测试目标微服务需要其他组件。
3. 此策略确保每个模块按预期工作，并在集成时工作。
4. 移除不必要的依赖项，并将其作为微服务测试策略进行调整。

Recommendations:

如果您正在使用Java，则可以使用wiremock。但是我建议迁移到postman，因为它支持内置的模拟服务器，而且非常容易使用。

https://blog.postman.com/postman-engineering-microservices-example/

Answer 2

使用Unit、Integrated测试，您测试微服务的方式与测试所有软件的方式相同。正如PDHide很好地描述的那样，微服务的一个关键部分是它们使您能够执行单元测试和集成测试，而不需要传统测试所需的所有依赖项。这取决于高质量的软件工程师承认和实现这一点。这将不仅仅是‘发生’，传统业务往往不会认识到这种技术上的区别和需要。

你想问的问题也许更多

我们应该在生产中进行测试吗？

这是一个非常重要和非常相关的问题。

每天发布数百次的公司显然不能花费传统的时间来运行和验证每个用例场景的缓慢和脆弱的端到端用户界面测试。

其实很多人都这么做，但这是一个噩梦，它的价值大大降低了阻塞效应和缓慢得到反馈给开发人员。这可能伴随着不健康的工作环境，其特点是指责和指责分配。墙上的海报可能会说我们都是一个大团队，但每天的互动可能并不能充分反映出这一点。

最初，自动化而不是手动测试似乎解决了这一问题(正如供应商大声宣称的那样)，但是随着具有数千个测试的自动化套件的实现，瓶颈又回来了，尽管现在出于不同的原因，这些原因都与自动化本身有关。一段时间后，测试套件需要一天或更长时间才能运行。不太好。令人吃惊的是，发现这一点的公司并不是小型的一次性创业公司，而是我们时代的行业巨头--雅虎、Facebook、Netflix、亚马逊等等。

为了做到这一点，这是两个主要做法：

• 在到达UI层之前进行大多数测试，使用敏捷测试金字塔作为您的指南。
• 使用AB、Canary和Feature测试，监视和测量生产，以了解实际用户做什么

在重新阅读你的问题时，脑海中浮现出一个想法--也许测试微服务如果被特别看作敏捷测试金字塔中的集成测试层，就会起作用。在编写代码(TDD)或选择UI测试(理想情况下通过BDD过程)时，既不替换也不重复伴随代码的广泛单元测试。不过，这确实引发了一个有趣的两难处境--如果您严格要求编写功能测试，那么除非不断地在测试级别重构，否则测试时间可能会不断增长，例如将UI测试迁移到Unit测试、模拟更多的依赖项、删除从未失败或被其他测试覆盖的测试。这可以导致方法，如固定的测试运行时，但这是一个更先进的热带。