微服务测试

自动化测试的世界日新月异，并且几乎每个月都会出现新的工具和技术，不断推动这个世界向前发展。如何高效且有效地测试分布式系统仍然是一个挑战。使用微服务架构之后，测试的复杂度进一步增加。

了解测试有哪些不同的类型，可以帮助我们实现尽早交付软件与保持软件高质量之间的平衡。如果当前你正在使用大量的手工测试，建议在深入微服务的道路之前，先解决这个问题。

单元测试通常只测试一个函数和方法调用。服务测试是绕开用户界面、直接针对服务的测试。只测试一个单独的服务可以提高测试的隔离性，可以更快地定位并解决问题。为了提高这种隔离性，我们需要给所有的外部合作者打桩，以便只把服务本身保留在测试范围内。一些服务测试可能会像单元测试一样快，但如果你在测试里使用了真实的数据库，或者通过网络跟打桩的外部合作者交互，那么测试时间会增加。端到端测试会覆盖整个系统。越靠近Mike Cohn测试金字塔的顶端，测试覆盖的范围越大，但测试时间和反馈周期长。测试失败时，难以定位哪个功能被破坏。越靠近金字塔的底部，测试会越快，反馈周期短，测试失败后容易定位问题，持续集成的构建时间也短。顺着金字塔向下，下面一层的测试数量要比上面一层多一个数量级。

运行端到端测试需要部署多个服务。随着测试范围的扩大，纳入测试的服务数量也会相应地增加。这些服务有可能会使测试失败，而这些失败是由其他一些原因引起的，网络故障也可能导致测试失败。包含在测试中的服务数量越多，测试就会越脆弱，不确定性也越强。脆弱的测试是我们的敌人，这种测试无法告诉我们有用的信息。当发现脆弱的测试时，我们应该竭力解决这个问题。否则，人们会开始对测试套件失去信心，因为它们总是这样失败。随着时间的推移，我们对事情出错习以为常，并开始接受它们是正常的，这叫异常正常化。所以要尽快找出脆弱的测试并消除它们，避免破窗效应。当不能立即修复时，需要把它们从测试套件中移出，然后就可以不受打扰地安心修复它们。最好的平衡是共享端到端测试套件的代码权，但同时对测试套件联合负责。团队可以随时提交测试到这个套件，但实现服务的团队负责维护套件的健康。

运行缓慢和脆弱性是很大的问题，需要精细化管理端到端测试套件，减少重复覆盖的测试或花足够的时间让他们变快。

有一种不需要使用真正的消费者也能达到同样目的的方式，就是消费者驱动的契约测试。

在敏捷中，故事通常被认为是一种促进沟通的方式。契约也起到类似的作用。他可以推动关于如何编写一组API的讨论，当其被破坏时也可以触发API该如何演进的讨论。消费者和生产者之间要有良好的沟通和信任。

微服务测试要点:

1、优化快速反馈，并相应地使用不同类型的测试。

2、尽可能使用消费者驱动的契约测试，来替换端到端测试。

3、使用消费者驱动的契约测试，提供团队之间的对话要点。

4、尝试理解投入更多的努力测试与更快地在生产环境解决问题之间的权衡(MTBF与MTTR之间的平衡)。

​