微服务架构的测试自动化

#1 楼

希望开发团队知道他们的职责，即在单元和集成级别（测试金字塔）具有较高的测试覆盖率。假设您可以集中精力进行高级测试，即端到端测试和合同测试。
合同测试：微服务架构师的一种很好的实践，它有一些解决方案。最合适的一种方法是由消费者驱动的合同测试，称为“契约”。同样，留在相同的存储库中可能会对您的CI / CD管道有所帮助。
看看M.Fowler进行的微服务测试。它为微服务测试的不同层次提供了很好的思路。​​

#2 楼

测试什么以及如何测试


您肯定需要测试系统的完整流程，以查看服务是否相互理解，特别是当服务之一响应错误消息时。这是我通常会发现问题的地方。嘲弄肯定会在这里有所帮助。
此外，如果您正在使用队列，那么许多异步事件和超时可能会发挥作用。您可以尝试分别模拟每种情况，但是当许多并发线程正在以意外数量的消息加载队列之一时的性能测试可能会发现有趣的错误。
在单元测试级别上，许多场景更易于自动化，在这种情况下，您无需启动HTTP服务器即可托管服务或服务模拟。对于负面情况尤其如此。我通常会与此类服务的开发人员紧密合作，每当我发现自动化方案在系统级别上的成本很高时，我都会要求开发人员在其单元测试套件中添加测试。
Martin Fowler确定微服务的多重测试级别：单元测试，集成测试，合同测试和端到端测试。但是，请确保您那里确实有微服务架构。我已经看到许多微服务以分布式整体，共享代码甚至共享数据库而结束。此问题已在InfoQ中进行了描述。

如何组织存储库

这不仅取决于测试策略，而且还取决于团队的工作方式。 >

微服务是否由不同的团队拥有？这些微服务的代码是否在同一存储库中？
谁将维护和更新这些测试？通常只有您，其他测试人员或微服务开发人员吗？

我通常更喜欢在他们所测试的代码附近进行测试，因此，如果有新项目出现，她可以使用一两个代码开始自动化结帐。


您将如何在开发管道中启动这些测试？是否要使所有测试通过还是失败都具有一种状态，还是仅当它们通过启动端到端测试时才希望对单个服务启动第一个测试？

您不需要每组测试使用单独的存储库。软件包可以按照您希望的方式组织测试的结构，因此很容易了解软件包名称和结构，从而掌握测试范围。然后有一些测试组可用于注释您的测试。它们将简化启动单独的测试组的工作，特别是如果您希望在CI服务器中拥有单独的工作（例如Jenkins）。其他帮助工具是另一个问题。您是否还将在其他测试项目中使用这些工具？其他人还会在您的项目之外使用这些工具吗？

我通常更喜欢从一个单一的，结构合理的仓库开始。从一开始就创建许多存储库会使维护变得不必要的复杂。当存储库开始增长时，您将需要不时重构它，更新结构。如果重构还不够，那么您可以考虑是否要移动一些工具或测试来分离存储库。

#3 楼

您提到了“兔子队列”，即RabbitMQ。配置RabbitMQ的方法有很多，涉及性能，容错能力和资源需求之间的权衡。我建议您先阅读RabbitMQ可靠性指南，然后再阅读Aphyr在RabbitMQ上的帖子，然后考虑一下它可能如何应用于您的系统。 br />
如果发布者由于RabbitMQ服务器太忙或暂时不可用而无法发布消息，会发生什么？
如果网络分区导致RabbitMQ进入裂脑模式会怎样？分区修复后，可能会有两个主节点，其中一个将决定截断其数据，从而导致消息丢失。您不能对RabbitMQ的行为做任何事情，但是您可以尝试确定对系统的灾难性影响。如果您无法发送一些电子邮件，那是一回事。如果您无法将钱存入某人的银行帐户，那就别无所求了。

#4 楼

使用微服务是一个不断发展的趋势。

我将在全局图中查看如何在何处进行测试的指南

您可以使用4象限方法，它们是：


单元测试。这将涵盖针对api和每个服务的基本测试。使用其他服务的代码应模拟并存根。
集成测试。在这里，您可以专门测试从一个应用程序到另一个应用程序的服务。您需要创建给定请求将使用的服务的测试版本。
性能。您应该考虑创建一个反映生产系统的测试系统。这意味着创建所有测试服务的测试版本以及反映实际使用情况的数量。
探索性测试。从实际用户的角度来看，您可以在这里查看所有服务是否正确结合在一起。

#5 楼

老实说，我会用与被测产品相同的语言来编写自动化程序。我发现这减少了开发人员和质量保证之间的障碍（在角色分开的环境中）。此外，您可以轻松提取受测的代码。话虽如此，我建议尽可能将代码保留在相同的存储库中，以减轻版本控制的痛苦。理想情况下，您应该将这些测试作为实际项目的一部分。

如果您确实使用Java，则我建议使用Rest-Assured和Restito库。在针对API进行测试时，我喜欢这些库。