初创公司需要自动化测试吗_5种针对初创企业的微服务测试策略

初创公司需要自动化测试吗

测试微服务很难。 当我第一次进入具有七个独立微服务的技术堆栈时，我会感到有多难，每个微服务都有自己的代码库，依赖关系管理，功能分支和数据库架构-碰巧也有一组独特的迁移。

谈忙。

我采取的方法是在本地运行所有内容。 这意味着，每当我想运行端到端测试时，我都需要针对七个微服务中的每个执行以下五个步骤：

1. 确保我在正确的代码分支上（ master或feature_xyz ）

2. 提取该分支的最新代码

3. 确保所有依赖项都是最新的

4. 运行任何新的数据库迁移

5. 启动服务

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

测试微服务与测试整体

在讨论测试微服务的通用方法和应对这些方法所面临挑战的策略之前，让我们深入研究一下为什么测试微服务与测试整体不是一回事。

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

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

• 可用性 ：由于不同的团队可能管理着自己的微服务，因此很难确保微服务的可用性（或更糟糕的是，试图找到所有微服务都可用的时间）。

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

• 知识鸿沟 ：尤其是对于集成测试（我们将在本文后面介绍），进行测试的人员将需要对每种服务都有深刻的了解，以便有效地编写测试用例。

尽管存在这些挑战，但由于测试挑战，微服务的优势实在太大了，无法放弃。 可以使用多种方法来应对测试微服务的挑战。

常见的微服务测试方法

单元测试

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

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

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

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

万神殿的首席技术官戴维·斯特劳斯（David Strauss）告诉我：“机会是，微服务非常容易直接进行单元测试。”

Armory的首席技术官Isaac Mosquera表示同意，并补充说Armory“指示客户专注于单元测试。”

整合测试

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

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

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

Sumo Logic的首席架构师Stefan Zier还透露，他们“在集成测试上投入了相当大的资金”。

但是，与我交谈的并不是每个人都喜欢这个过程。 例如，Mosquera关于集成测试的观点非常值得注意：“就工时而言，集成测试非常容易出错且成本很高。 投资回报率不存在。 每个单独的集成测试都会带来用例的少量边际覆盖。

“如果考虑到应用程序的所有代码路径组合，再加上另一个应用程序的代码路径，则需要编写的测试数量很容易爆炸成无法实现的数量。 相反，我们指示客户关注单元测试范围，这是少数几个集成测试，它们将证明应用程序关键区域完全失败。

端到端测试

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

Fowler写道 ：“端到端测试可能还必须考虑系统中的异步性，无论是在GUI中还是由于服务之间的异步后端进程。” 他继续解释了这些因素如何导致“松懈，测试运行时间过多以及测试套件的维护成本增加”。

关于端到端测试，我能提供的最佳建议是限制每种服务尝试该测试的次数。 提及的其他微服务测试策略（例如单元测试和集成测试）之间的健康平衡将有助于您清除较小的问题。 根据定义，端到端测试更大，花费更多时间并且容易出错。 为了降低成本并避免浪费时间，请在所有其他测试手段都用尽后坚持进行端到端测试，并以此作为最终的质量保证。

创业公司的五种微服务测试策略

测试微服务很困难，但并非不可能。 为了应对这些挑战，我从几位CTO那里获得了见识，并提炼了他们成功用于测试微服务的五种策略。

1.以文件为先的策略

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

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

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

2.完整的即插即用策略

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

“在我以前工作过的一家公司中，我曾对这种谬论有第一手的经验，当时我们试图在[本地]无家可归的盒子里旋转整个堆栈。 就像您可能想像的那样，想法很简单，那就是让公司中的任何工程师（甚至前端和移动开发人员）都能够在笔记本电脑上旋转整个堆栈。”

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

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

尽管她尽了最大的努力来记录遇到的障碍以及克服障碍的方式，但Sridharan透露，她公司雇用的下一位工程师遇到了自己的问题，这些问题无法在另一台笔记本电脑上复制。 （我确实说这很棘手！）

Sumo Logic的首席架构师Stefan Zier向我解释说，除了难以实施之外，这种本地化的测试策略根本无法扩展：“ [通过]本地部署，我们在那里运行了大多数服务，因此您可以得到一个完全运行的系统，而现在这甚至很难扩展16GB RAM机器。 因此，这并没有真正扩大规模。”

3. AWS测试策略

第三种策略涉及为每个工程师扩展Amazon Web Services（AWS）基础架构，以部署和运行测试。 这是一种用于上面讨论的完整的即插即用策略的可扩展性更高的方法。

Zier将此称为“个人部署[策略]，这里的每个人都拥有自己的AWS帐户。” 他补充说：“您可以在大约十分钟的时间内将笔记本电脑上的代码推送到AWS中，然后像在真实系统中一样运行它。”

4.共享测试实例策略

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

史蒂芬Czerwinski，工程负责人， Scaylr ，解释如何在实践中工作：

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

Czerwinski继续说道：“类似地，我们一直在谈论为前端开发人员这样做。 将数据库层隐藏在服务之间，以便人们在测试UI功能时不必运行自己的整体服务器即数据库服务器。 他们希望能够依靠可以很频繁地更新并且没有生产或暂存数据或类似数据的外部数据。”

5.存根服务策略

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

Zier提出了Sumo Logic进行存根服务测试的方法：“存根使您可以编写微服务的这些标记或“存根”，这些微服务的行为就像是正确的服务，并在我们的服务发现中做广告，就好像它们是真实的服务，但它们只是一个虚拟的模仿。”

例如，测试服务可能会要求服务意识到用户执行了一组任务。 使用存根服务，您可以假设用户（及其任务）已经发生，而没有随之而来的通常的复杂性。 显然，这种方法比总体上运行服务要轻得多。

帮助您测试微服务的工具

除了这些策略外，CTO还建议使用以下工具来使微服务测试更加容易：

• Hoverfly ：模拟API延迟和失败

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

• VCR ：单元测试工具

• 协议 ：以消费者为导向的合同测试框架

• API蓝图 ：设计和原型API

• Swagger ：设计和原型API

微服务测试：困难但可行

测试您的微服务并不是在公园里散步，但是额外的工作值得拥有微服务架构的好处。 回顾一下，五种策略是：

1. 以文档为先的策略

2. 完整的即插即用策略

3. AWS测试策略

4. 共享测试实例策略

5. 存根策略

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

[请参阅我们的相关故事， 在设计微服务之前应了解的5条指导原则 ]

翻译自: https://opensource.com/article/18/6/five-microservice-testing-strategies-startups

初创公司需要自动化测试吗