问微服务体系结构的测试自动化

EN

• 希望开发人员团队知道他们的职责，即在单元和集成级别(测试金字塔)拥有较高的测试覆盖率。假设这一点，您可以专注于高级别测试，即end2end测试和合同测试。
• 合同测试:微服务architect.There中的一个很好的实践是一些解决方案。最合适的测试之一是一种名为"协约“的消费者驱动的合同测试。
• 如果可能的话，将您的测试自动化保持在相同的回购中，因为您可能需要模拟/研究，加上版本控制是很棘手的。同时，在相同的回购可能是一个帮助您的CI/CD管道。
• 看看M.Fowler的微服务测试。它给出了不同层次的微服务测试的良好思路。

要测试什么以及

如何测试

• 您肯定需要测试系统的完整流程，以查看服务是否相互理解，特别是当其中一个服务使用错误消息进行响应时。这是我经常发现问题的地方。在这里模拟肯定会有帮助的。
• 另外，如果您正在处理队列，那么可能会有很多异步事件和超时出现。您可以试着单独模拟每个这样的场景，但是当许多并发线程加载一个队列时，会发现一些有趣的错误。
• 许多场景在单元测试级别上更容易自动化，在那里您不需要启动HTTP服务器来承载服务或服务模拟。消极情况尤其如此。我通常与这类服务的开发人员密切合作，每当我发现自动化场景在系统级别上太昂贵时，我就要求开发人员向他们的单元测试套件添加一个测试。
• Martin识别了微服务的多个测试级别：单元测试、集成测试、契约测试和端到端测试.但是，请确保您确实拥有微服务体系结构。我看到许多微服务以分布式monolith、共享代码甚至共享数据库而告终。这个问题已经在InfoQ中描述过了。

如何组织存储库

这不仅是你的测试策略的问题，也是你作为一个团队如何工作的问题。

• 微观服务是否属于不同的团队？这些微服务的代码是否在同一个回购程序中？
• 谁来维护和更新这些测试？只有您，其他测试人员或微服务开发人员？

我通常更喜欢在他们测试的代码附近进行测试，所以如果有新的人加入到这个项目中，她可以通过一两个代码签出来启动自动化。

• 您将如何在开发管道中启动这些测试？您希望拥有一个单一状态-是否所有测试都通过或失败，还是您更愿意为单个服务启动第一次测试，并且只在它们通过启动端到端测试时？

对于每组测试，不需要单独的repos。包以您希望的方式支持测试的组织结构，因此很容易掌握查看包名称和结构的测试覆盖率。还有一些测试组可以用来注释您的测试。它们可以轻松地启动不同的测试组，特别是如果您希望在您的CI服务器中有单独的作业(例如Jenkins)。

• 是否为服务存根、模拟和其他帮助工具建立单独的存储库是另一个问题。您也打算在其他测试项目中使用这些工具吗？其他人会在你的项目之外使用这些工具吗？

我通常喜欢从小开始，有一个回购，结构良好。从一开始就创建了许多存储库，使得维护变得非常复杂。当存储库开始增长时，您将需要不时地重构它，更新结构。如果重构还不够，那么您可以考虑是否将一些工具或测试移到单独的repos中。

您提到了“兔子队列”，即RabbitMQ。有许多方法可以配置RabbitMQ，包括性能、容错和资源需求之间的权衡。我建议您阅读兔南可靠性指南，然后阅读Aphyr在兔文上的文章，然后考虑如何将其应用于您的系统。

下面是一些需要测试的内容：

• 如果发布服务器由于RabbitMQ服务器太忙或其他临时不可用而无法发布消息，会发生什么情况？
• 如果发布者写消息的速度远远快于使用者读取消息的速度，会发生什么情况？
• 如果网络分区导致RabbitMQ进入分裂大脑模式，会发生什么情况？当分区恢复时，可能有两个主节点，其中一个将决定截断其数据，从而导致消息丢失。您不能对RabbitMQ的行为做任何事情，但是您可以尝试确定这将对您的系统造成多大的灾难。如果你没有发一些电子邮件，那是一回事；如果你没有把钱存入别人的银行账户，那就是另外一回事了。