杨波 微服务技术专家

by Jake Lumetta

杰克·卢米塔(Jake Lumetta)

专家称，这些是最有效的微服务测试策略 (These are the most effective microservice testing strategies, according to the experts)

Testing microservices is hard. More specifically, end-to-end testing is hard, and that’s something we’ll discuss in greater detail in this article.

测试微服务很难。 更具体地说，端到端测试很困难，这是我们将在本文中详细讨论的内容。

But first, a quick story.

但首先，一个简短的故事。

I learned just how hard microservice testing could be when I first dove into a tech stack with seven separate microservices. Each had its own code base, dependency management, feature branches, and database schema — which also happened to have a unique set of migrations.

当我首次涉足具有七个独立微服务的技术堆栈时，我了解了微服务测试的难度。 每个数据库都有自己的代码库，依赖关系管理，功能分支和数据库架构-碰巧还具有一组独特的迁移。

Talk about hectic.

谈忙。

The approach we took was to run everything locally. So that meant, at any given point in time when I want to run end-to-end tests, I would need to go through the following five steps for each of the seven microservices:

我们采取的方法是在本地运行所有内容。 因此，这意味着，在我要运行端到端测试的任何给定时间点，对于七个微服务中的每个微服务，我都需要经历以下五个步骤：

1. Ensure I was on the correct code branch (either master or feature_xyz)确保我在正确的代码分支上(master或feature_xyz)
2. Pull down the latest code for that branch提取该分支的最新代码
3. Ensure all dependencies were up to date确保所有依赖项都是最新的
4. Run any new database migrations运行任何新的数据库迁移
5. Start the service启动服务

This was just a baseline requirement to enable tests to be run. Often times, I would forget to perform one of these steps for a service and spend 10–15 minutes debugging the issue. Once I finally had all the services happy and running, I could then begin to kick off the test suite. This experience sure made me miss the days of testing one big monolith.

这只是使测试能够运行的基本要求。 通常，我会忘记为服务执行以下步骤之一，而花10到15分钟来调试问题。 一旦我终于满意并运行了所有服务，便可以开始测试套件了。 这种经历肯定使我怀念测试一个大型整体装置的日子。

So yes, I discovered that end-to-end microservice testing is hard — and gets exponentially harder with each new service you introduce. But fear not, because there are ways to make testing microservices easier. I’ve spoken to several CTOs about how they came up with their own creative ways of tackling this complex issue.

因此，是的，我发现端到端的微服务测试非常困难，并且您引入的每一项新服务都变得越来越困难。 但是不要担心，因为有多种方法可以使微服务的测试变得更加容易。 我曾与几位首席技术官谈过他们如何提出自己的创造性方法来解决这一复杂问题。

常见的微服务测试方法 (Common microservice testing methods)

单元测试 (Unit Testing)

A microservice may be smaller by definition, but with unit testing, you can go even more granular. A unit test focuses on the smallest part of a testable software to ascertain whether that component works as it should. Renowned software engineer, author, and international speaker Martin Fowler breaks unit testing down into two categories:

从定义上讲，微服务可能会更小，但是通过单元测试，您可以变得更加细化。 单元测试专注于可测试软件的最小部分，以确定该组件是否可以正常工作。 著名的软件工程师，作家和国际发言人Martin Fowler 将单元测试分为两类：

1. Sociable unit testing: This unit testing method tests the behavior of modules by observing changes in their state.

   社交单元测试：这种单元测试方法通过观察模块状态的变化来测试模块的行为。

2. Solitary unit testing: This method focuses on the interactions and collaborations between an object and its dependencies, which are replaced by test doubles.

   孤立单元测试：此方法着重于对象及其依赖项之间的交互和协作，这些交互和协作被替换为测试双精度。

While these unit testing strategies are distinct, Fowler puts forth that they aren’t competing — they can be used in tandem to solve different testing problems.

尽管这些单元测试策略是截然不同的，但Fowler提出它们并没有竞争-可以串联使用它们来解决不同的测试问题。

During a discussion with David Strauss, CTO of Pantheon, David told me that “the opportunity is that Microservices are very straightforward to actually do unit testing on.”

在与万神殿CTO大卫·斯特劳斯的讨论中，大卫告诉我：“机会是微服务非常容易直接进行单元测试。”

整合测试 (Integration testing)

With integration tests, you’re doing what it sounds like you’re doing: testing the communication paths and interactions between components to detect issues. According to Fowler, an integration test “exercises communication paths through the subsystem to check for any incorrect assumptions each module has about how to interact with its peers.”

使用集成测试，您可以按听起来的方式做：测试组件之间的通信路径和交互以检测问题。 根据Fowler的说法 ，集成测试“通过子系统执行通信路径，以检查每个模块有关如何与对等方进行交互的任何不正确的假设。”

An integration test usually tests the interactions between the microservice and external services, like another microservice or datastore.

集成测试通常测试微服务和外部服务(例如另一个微服务或数据存储)之间的交互。

Pawel ​Ledwoń, Platform Lead at Pusher, informed me that his team “lean[s] towards integration testing. Unit tests are still useful for some abstractions, but for user-facing features they are difficult to mock or skip important parts of the system.”

Pusher平台负责人Pawel``Ledwon''告诉我，他的团队``倾向于集成测试''。 单元测试对于某些抽象仍然有用，但是对于面向用户的功能，它们很难模拟或跳过系统的重要部分。”

Not everybody I spoke to was a fan of the process. Mosquera’s take on the subject of integration testing, for example, is well worth noting:

与我交谈的并不是每个人都喜欢这个过程。 例如，Mosquera对集成测试的看法很值得一提：

Integration testing is very error prone and costly, in terms of man-hours. The ROI just isn’t there. Each individual integration test brings small marginal coverage of use cases.

就工时而言，集成测试非常容易出错且成本很高。 投资回报率不存在。 每个单独的集成测试都会带来用例的少量边际覆盖。

端到端测试 (End-to-end testing)

Last but not least is end-to-end testing, which — as previously mentioned — can be a difficult task. That’s because it involves testing every moving part of the microservice, ensuring that it can achieve the goals you built it for.

最后但并非最不重要的一点是端到端测试，如前所述，这可能是一项艰巨的任务。 这是因为它涉及测试微服务的每个移动部分，以确保其可以实现为其构建的目标。

Fowler wrote the following:

福勒写道 ：

end-to-end tests may also have to account for asynchrony in the system, whether in the GUI or due to asynchronous backend processes between the services.

不管是在GUI中还是由于服务之间的异步后端进程，端对端测试都可能不得不考虑系统中的异步性。

He goes on to explain how these factors can result in “flakiness, excessive test runtime and additional cost of maintenance of the test suite.”

他继续解释了这些因素如何导致“松散，测试时间过多和测试套件的维护成本增加”。

The best advice I can give when it comes to end-to-end testing is to limit the amount of times you attempt it per service. A healthy balance between the other microservice testing strategies mentioned — like unit testing and integration testing — will help you weed out smaller issues.

关于端到端测试，我能提供的最佳建议是限制每次服务尝试尝试的次数。 在上述其他微服务测试策略(例如单元测试和集成测试)之间保持良好的平衡，将有助于您清除较小的问题。

An end-to-end test is larger by definition, takes more time, and can be far easier to get wrong. To keep your costs low and avoid time-sink, stick to end-to-end testing when all other means of testing have been exhausted, and as a final stamp of quality assurance.

根据定义，端到端测试更大，花费更多时间并且容易出错。 为了降低成本并避免浪费时间，请在所有其他测试手段都用尽后坚持进行端到端测试，并以此作为最终的质量保证。

测试微服务的挑战 (The challenges of testing microservices)

Microservices (compared to a monolith) require extra steps, like managing multiple repositories and branches, each with their own database schemas. But the challenges can run deeper than that.

微服务(相对于整体服务)需要额外的步骤，例如管理多个存储库和分支，每个存储库和分支都有自己的数据库架构。 但是挑战可能比这更深。

Here are a few key challenges associated with testing microservices:

以下是与测试微服务相关的一些关键挑战：

• Availability: Since different teams may be managing their own microservices, securing the availability of a microservice (or, worse yet, trying to find a time when all microservices are available at once), is tough.

  可用性：由于不同的团队可能管理着自己的微服务，因此确保微服务的可用性(或者更糟糕的是，试图找到同时提供所有微服务的时间)非常困难。

• Fragmented and holistic testing: Microservices are built to work alone, and together with other loosely coupled services. That means developers need to test every component in isolation, as well as testing everything together.

  零散的整体测试：微服务被构建为可以单独工作，并与其他松散耦合的服务一起工作。 这意味着开发人员需要单独测试每个组件，以及一起测试所有组件。

• Knowledge gaps: Particularly with integration testing (which we will address later in this article), whoever conducts the tests will need to have a strong understanding of each service in order to write test cases effectively.

  知识差距：尤其是对于集成测试(我们将在本文后面介绍)，进行测试的人员必须对每种服务都有深刻的了解，才能有效地编写测试用例。

According to Oleksiy Kovyrin, Head of Swiftype SRE at Elastic,

Elastic的Swiftype SRE负责人Oleksiy Kovyrin表示，

One important issue we have to keep in mind while working with microservices is API stability and API versioning. To avoid breaking applications depending on a service, we need to make sure we have a solid set of integration tests for microservice APIs and, in case of a breaking change, we have to provide a backwards-compatible way for clients to migrate to a new version at their own pace to avoid large cross-service API change rollouts.

使用微服务时，我们必须牢记的一个重要问题是API稳定性和API版本控制。 为了避免根据服务中断应用程序，我们需要确保我们有一套针对微服务API的可靠的集成测试，并且在发生重大更改的情况下，我们必须为客户提供向后兼容的方式来迁移到新的自行调整版本，以免大规模推出跨服务API更改。

Stefan Zier, Chief Architect at Sumo Logic, also reiterated to me that microservice testing is indeed “very, very difficult.”

Sumo Logic的首席架构师Stefan Zier也向我重申，微服务测试确实“非常非常困难”。

“Especially once you go towards more continuous deployment. We’ve invested and continue to invest fairly heavily into integration testing, unit testing, and would do a lot more if we had the people to do it,” Zier told me.

“特别是一旦您要进行更连续的部署。 Zier告诉我，我们已经投资并且继续在集成测试，单元测试上投入相当大的资金，如果让我们的人来做，它将做得更多。

With that being said, he admitted that, at certain stages, when Sumo Logic wants to test their services holistically, “more or less [the] entire company [becomes] a quality assurance team in a sense.”

话虽如此，他承认，在某些阶段，当Sumo Logic想要整体测试他们的服务时，“整个公司或多或少都在某种意义上成为了质量保证团队。”

解决方案：针对初创企业的五种微服务测试策略 (Solution: Five microservice testing strategies for startups)

Yes, testing microservices can be difficult, but given all the benefits of microservices, foregoing them because of testing challenges isn’t the right path. To tackle these challenges, I got insight from several CTOs and distilled five strategies they used to successfully approach testing microservices.

是的，测试微服务可能很困难，但是鉴于微服务的所有好处，由于测试挑战而放弃它们并不是正确的方法。 为了应对这些挑战，我从几个CTO那里获得了见识，并提炼了他们成功用于测试微服务的五种策略。

1.以文件为先的策略 (1. The documentation-first strategy)

Chris McFadden, VP of Engineering Sparkpost, summarized the documentation-first strategy quite nicely during our discussion:

在我们的讨论中，Sparkpost工程副总裁Chris McFadden很好地总结了文档优先的策略：

We follow a documentation first approach so all of our documentation is in markdown in GitHub. Our API documents are open source, so it’s all public. Then, what we’ll do is before anybody writes any API changes or either a new API or changes to an API, they will update the documentation first, have that change reviewed to make sure that it conforms with our API conventions and standards which are all documented, and make sure that there’s no breaking change introduced here. Make sure it conforms with our naming conventions and so forth as well.

我们遵循文档优先的方法，因此我们所有的文档都在GitHub的markdown中。 我们的API文档是开源的，因此都是公开的。 然后，我们要做的是在任何人编写任何API更改或新API或对API进行更改之前，他们将首先更新文档，对更改进行审核以确保其符合我们的API约定和标准。所有文件均已记录在案，并确保此处没有引入重大更改。 确保它也符合我们的命名约定等。

If you’re willing to go one step further, you could dabble in API contract testing, which — as previously mentioned — involves writing and running tests that ensure the explicit and implicit contract of a microservice works as it should.

如果您愿意更进一步，则可以涉足API合约测试，如前所述，API合约测试涉及编写和运行测试，以确保微服务的显式和隐式契约能够正常工作。

2.全栈即装即用策略 (2. The full stack in-a-box strategy)

The full stack in-a-box strategy entails replicating a cloud environment locally and testing everything all in one vagrant instance (“$ vagrant up”). The problem? It’s extremely tricky, as software engineer Cindy Sridharan of Imgix explained in a blog post:

完整堆栈即装即用策略需要在本地复制云环境，并在一个无所事事的实例中测试所有内容(“ $ vagrant up”)。 问题？ 正如Imgix的软件工程师Cindy Sridharan在博客文章中所述，这非常棘手：

I’ve had first hand experience with this fallacy at a previous company I worked at where we tried to spin up our entire stack in a [local] vagrant box. The idea, as you might imagine, was that a simple vagrant up should enable any engineer in the company (even frontend and mobile developers) to be able to spin up the stack in its entirety on their laptops.

我曾在一家以前的公司工作过，曾有过这种谬论的第一手经验，在那家公司，我们试图在[本地]无家可归的盒子中旋转整个堆栈。 就像您可能想像的那样，想法是，只需进行一次简单的游荡，即可使公司中的任何工程师(甚至是前端和移动开发人员)都能够在笔记本电脑上旋转整个堆栈。

Sridharan goes on to detail how the company only had two microservices, a gevent based API server and some asynchronous Python background workers. A relatively simple setup, by all means.

Sridharan继续详细介绍了该公司如何只有两个微服务，一个基于gevent的API服务器和一些异步Python后台工作者。 绝对是一个相对简单的设置。

“I remember spending my entire first week at this company trying to successfully spin up the VM locally only to run into a plethora of errors. Finally, at around 4:00pm on the Friday of my first week, I’d successfully managed to get the Vagrant setup working and had all the tests passing locally. I remember feeling incredibly exhausted,” she narrated.

“我记得整个第一周都在这家公司工作，试图在本地成功启动虚拟机，但是却遇到了很多错误。 终于，在我第一周的星期五下午4:00左右，我成功地使Vagrant设置正常工作，并使所有测试都在本地通过。 我记得我感到非常疲惫，”她说。

In addition, Stefan Zier, Chief Architect at Sumo Logic, explained to me that — on top of being difficult to pull off — this localized testing strategy simply doesn’t scale:

此外，Sumo Logic的首席架构师Stefan Zier向我解释说，除了难以实现之外，这种本地化的测试策略根本无法扩展：

“[With] a local deployment, we run most of the services there so you get a fully running system and that’s now stretching even the 16GB RAM machines quite hard. So that doesn’t really scale,” he said.

“在本地部署中，我们在那里运行大多数服务，因此您将获得一个完全运行的系统，而现在即使16GB RAM机器也很难扩展。 因此，这并没有真正扩大规模，”他说。

3. AWS测试策略 (3. The AWS testing strategy)

This third strategy involves spinning up an Amazon Web Services (AWS) infrastructure for each engineer to deploy and run tests on. This is a more scalable approach to the full stack in-a-box strategy discussed above.

第三种策略涉及为每个工程师扩展Amazon Web Services(AWS)基础架构，以部署和运行测试。 这是对上面讨论的全栈即用策略的一种更具可扩展性的方法。

Zier called this a “personal deployment [strategy], where everyone here has their own AWS account.”

Zier将此称为“个人部署[策略]，这里的每个人都拥有自己的AWS账户。”

“You can push the code that’s on your laptop up into AWS in about ten minutes and just run it in like a real system,” he said.

他说：“您可以在大约十分钟的时间内将笔记本电脑上的代码推送到AWS中，然后像实际系统一样运行它。”

4.共享测试实例策略 (4. The shared testing instances strategy)

I like to think of this fourth strategy as a hybrid between full stack in-a-box and AWS testing. That’s because it involves developers working from their own, local station, while leveraging a separate, shared instance of a microservice to point their local environment at during testing.

我喜欢将第四种策略视为完整堆栈即装式测试与AWS测试之间的混合体。 这是因为它涉及开发人员在自己的本地工作站上工作，同时利用单独的共享微服务实例在测试期间将其本地环境指向。

Steven Czerwinski, Head of Engineering, Scaylr, explained how this can work in practice:

Scaylr工程主管Steven Czerwinski解释了这在实践中如何工作：

Some of [our] developers run a separate instance of a microservice just to be used for testing local builds. So imagine you’re a developer, you’re developing on your local workstation, and you don’t have easy way of launching the image parser. However, your local builder would just point to a test image parser that’s running in the Google infrastructure.

[我们的]一些开发人员运行一个微服务的单独实例，仅用于测试本地构建。 因此，假设您是一名开发人员，正在本地工作站上进行开发，并且没有启动图像解析器的简便方法。 但是，您的本地构建器只会指向在Google基础架构中运行的测试图像解析器。

5.存根策略 (5. The stubbed services strategy)

And finally, we have the stubbed services testing strategy.

最后，我们有存根服务测试策略。

Zier laid out SumoLogic’s approach to stubbed service testing by telling me how, “stubbing let’s you write these marks or ‘stubs’ of microservices that behave as if they were the right service and they advertise themselves in our service discovery as if they were real service, but they’re just a dummy imitation,” he explained.

Zier告诉我如何，SuerLogic展示了SumoLogic进行存根服务测试的方法，“存根让您写下这些标记或微服务的“存根”，它们的行为就像是正确的服务，并且在我们的服务发现中做广告，就好像它们是真实的服务一样。 ，但它们只是一个虚拟的模仿，”他解释说。

For example, testing a service may necessitate that the service becomes aware that a user carries out a set of tasks. With stubbed services, you can pretend that user (and his tasks) have taken place without the usual complexities that come with that. This approach is a lot more lightweight compared to running services in their totality.

例如，测试服务可能需要使服务意识到用户执行了一组任务。 使用存根服务，您可以假设用户(及其任务)已经发生，而没有随之而来的通常的复杂性。 与整体上运行服务相比，此方法轻巧得多。

帮助您测试微服务的工具 (Tools to help you test microservices)

Here’s a list of tools that have benefited me during my own microservice testing experiences, bolstered by some recommendations from the pool of CTOs and senior developers:

以下是在我自己的微服务测试经验中受益的工具列表，并得到了CTO和高级开发人员的建议 ：

• Hoverfly: simulate API latency and failures.

  Hoverfly ：模拟API延迟和失败。

• Vagrant: build and maintain portable virtual software development environments

  Vagrant ：构建和维护便携式虚拟软件开发环境

• VCR: a unit testing tool

  VCR ：单元测试工具

• Pact: frameworks consumer-driven contracts testing.

  契约 ：构架消费者驱动的合同测试。

• Apiary: API documentation tool

  养蜂场 ：API文档工具

• API Blueprint: design and prototype APIs

  API蓝图 ：设计和原型API

• Swagger: design and prototype APIs

  Swagger ：设计和原型API

微服务测试：困难，但值得 (Microservices testing: difficult, but worth it)

Testing your microservices won’t be a walk in the park, but the additional work is worth the benefits of having a microservice architecture.

测试您的微服务并不是在公园里散步，但是额外的工作值得拥有微服务架构的好处。

Plus, the microservice testing strategies adopted by the likes of SumoLogic and Scaylr should help smooth the process out. Here’s a quick recap of those strategies:

另外，SumoLogic和Scaylr等公司采用的微服务测试策略应有助于简化流程。 以下是这些策略的简要介绍：

1. The documentation-first strategy以文档为先的策略
2. The full stack in-a-box strategy全栈即装即用策略
3. The AWS testing strategyAWS测试策略
4. The shared testing instances strategy共享测试实例策略
5. The stubbed service strategy存根策略

Naturally, you may need to tweak each strategy to match your unique circumstances, but with some good old fashioned trial and error, your microservice testing strategy should come into its own.

自然地，您可能需要调整每种策略以适应您的独特情况，但是通过一些良好的老式尝试和错误，您的微服务测试策略应该成为自己的策略。

If you’ve enjoyed this article, please help it spread by clapping below! For more content like this, follow us on Twitter and subscribe to our blog.

如果您喜欢这篇文章，请通过下面的鼓掌帮助传播！ 有关此类的更多内容，请在Twitter上关注我们并订阅我们的博客。

Jake Lumetta is the CEO of ButterCMS, and is publishing Microservices for Startups.

杰克Lumetta是首席执行官ButterCMS ，并发布了创业微服务 。

And if you want to add a blog or CMS to your website without messing around with Wordpress, you should try Butter CMS.

而且，如果您想在您的网站上添加博客或CMS而不用弄乱Wordpress，则应该尝试Butter CMS 。

翻译自: https://www.freecodecamp.org/news/these-are-the-most-effective-microservice-testing-strategies-according-to-the-experts-6fb584f2edde/

杨波 微服务技术专家