转载

开发和测试微服务

在 Agile Testing Days 2015 会议上，来自Redgate软件的 Jose Lima分享了自己有关开发与测试微服务的经验。InfoQ有幸对他进行了采访，主要关于用微服务开发产品的优点和缺点、如何应用微服务提高产品质量、测试微服务和测试人员需要的技能、以及他从开发与测试微服务中学到的经验和教训。

InfoQ：您能详细说明采用微服务开发产品的优点和缺点吗？

Lima ：首先要指出的是我有关微服务框架的经验大部分来自为内部客户开发服务时获得的。我们唯一可以接触“顾客”（我在一个内部开发团队内工作，因此我们的客户大多数是 Redgate软件的员工）的地方是在我们网站内，比如通过订单查询。跟优点一样，也有很多的缺点，但是我们的情况是，在我们大量的成功中有一件事情是每个服务都有的，松散耦合。我们需要集成相当数量的外部服务和应用程序，以便有能力做到这一点，将其看成一个设计原则是一件很棒的事情。

我想说的是其中一个缺点可能会影响其性能，比如那些需要接通通道的系统，如果通信时间过长可能会影响其性能。这里我说“可能”是因为它对我们不适用。我曾在 Agile Testing Days的演讲中提过，我们不在乎信息经过一段时间达到目的地，但是如果你在一个不同的环境里（比如银行），那么你可能需要注意这一点。

InfoQ：您有案例说明如何应用微服务提高产品质量？

Lima ：最好的案例是我们自己订单查询时的结账处理。它不仅仅需要收钱，还需要处理发票、连接授权系统、记录顾客详细信息等等。尽管我们还在分离他们的过程中，但是我们已经构建了一个微服务，用于负责订单完成后标记付款，并且只有付款完成后它才会做另外一件事情。

InfoQ：您能描述一下您的团队如何测试微服务？

Lima ：这么多年我们的测试方法已经改变了很多，因为我没有在其他团队工作过，因此我只能给你提供我看到的现在的测试跟过去测试不同的地方。在我们测试之前我们会花大量的时间跟开发人员、产品拥有者等等进行沟通，有时我们扮演的几乎就是顾问角色。在我的团队里，我不是负责写单元测试和集成测试的人，尽管有时我会被派去审查这些代码（或者审查任何因此发生改变的代码）。

但是当时为了达到目的我们调整了一些开发原则，我认为与其称他们为测试改变我觉得开发/工程改变更合适。其中一个案例是我们的一位负责部署产品到生产环境的主管，你最好不要将任何与产品质量无关的事情推给他。在实际技术工作方面，我发现我比以前执行了更多的测试（探索），因为我不会发现更多愚蠢的错误（在我看来多亏了测试改变），并且可以花更多的时间通过测试学习和研究系统。

InfoQ：哪些技能是测试人员为了测试微服务所必须的？

Lima ：在我的演讲中我提到了三种不同的类别。第一是熟练的技术技能，比如自动化环境构建或者学习优秀的持续部署实践。有些人可能会说自动化测试也是一个必须的技能，尽管我不认同。首先我不信任自动化测试，其次检查自动化也可以由团队的其他人完成，而不只是测试人员。根本就没有自动化测试，但是确实存在自动化检查——对我而言，测试不仅仅是检查，并且检查过程可以实现自动化，但是必须在你研究或者学习了你要检查的内容和它想要实现什么，你才能正确检查（自动化或者不是），检查执行情况是否跟设计一样。

这么多年来，我的业务分析能力也得到了提高，我发现自己跟利益相关者和产品负责人的沟通越来越多，并能找出更多的信息（尽管我们有专门的 BA可以完成这些工作），因此我可以更有效率地执行探索性测试。最后，社交技能也是你最应该具备的，并且我的社交技能这些年也得到了提高，因为我每天都将不同的事情进行对比。

InfoQ：您能分享一下您在开发和测试微服务中学到的东西吗？

Lima ：我想更多的是技术技能的变化，还有态度的变化，因为你可能最终拥有比团队其他成员更多的服务。每个人都应该承认所有的服务是一个集合而不是个人拥有部分。这允许知识在团队内均匀传播，因此让维修变得更加容易，这样新服务的构建将来源不同人的丰富经验。

InfoQ：如果人们正在考虑采用微服务，您对他们有什么建议吗？

Lima ：我建议人们认真考虑一下这种架构方法的利弊，寻找已经完成这些转型的公司或者个人，不仅仅是成功转型的，还包括失败的。当然，你应该关注实施这种架构方法积极的一面，但是确实有缺点，因此你必须考虑你的环境和这种方法是否比你目前的方法更好，或者其它一些因素。如果你决定实施这种方法，一定要小心，并确保拥有技术熟练的人（正如我前面说的）和愿意忍受这种改变的人。

查看英文原文： Developing and Testing Microservices

正文到此结束