随着互联网的不断发展,微服务编程开发可以说得到了众多程序员的追捧,而今天我们就通过案例分析来了解一下,微服务测试又有哪些实践作用。

1.使用另一个微服务的测试实例来测试您的微服务。

团队成熟度的影响很小,因为团队不需要了解测试替身的类型以及如何使用它们。如果你是软件开发和测试的新手,那么用这种方式进行测试比较容易。

这种技术适合任何变更速度。如果速度很快,团队就会得到关于API之间兼容性问题的快速反馈。当节奏变慢时,也没什么关系。

随着复杂性的增加,大多数项目投入市场的时间会变慢。这是软件团队的典型陷阱,也是许多大型企业的技术债务来源。这项技术很容易就能开始用起来,因为它几乎不需要额外的基础设施或测试替身的知识。

2.使用另一个微服务的生产实例来测试您的微服务。

在使用产品实例进行测试时,团队需要格外小心,相比于使用测试替身的团队,必须要更加信任这个团队。

投入市场的成本和时间与一种技术没有区别。你的团队与产品发布周期维系在一起,这可能会延迟他们的测试。

团队需要格外小心,因为这种技术的风险比测试替身要高得多。连接到生产系统的测试可以更改生产系统的状态。仅针对无状态API或团队精心选择的在生产中可以使用的测试数据使用此方法。

3.桩(进程内或通过网络/远程)。

模拟使用特定于测试的对象替代微服务依赖的对象,该对象验证微服务是否正确地使用了它,而桩使用特定于测试的对象替代它,该对象为微服务提供测试数据。两者的取舍很是相似。

内部开发复杂依赖项的桩可能非常耗时和昂贵。建议选择现成的模拟、模拟器(simulators)或服务虚拟化工具,而不是桩。

4.使用遗留的非微服务内部依赖项来测试微服务。

这种技术就微服务的新领域和旧遗留系统之间的契约问题提供快速反馈周期,从而降低风险。

除了技术1的所有缺点之外,你还需要记住,遗留系统常常存在测试环境可用性和测试数据设置方面的问题。

5.使用非软件(硬件)依赖项测试微服务。

团队需要知道如何在硬件依赖项中设置测试数据。

一般来说,硬件的变化速度比较慢,但是价格可能会比较贵。即使仅要得到一个用于测试目的的硬件实例,成本也会很高。当你需要更多的硬件来由不同的团队或构建\流水线并行运行测试时,成本可能会显著增加。

与前一项技术类似,微服务和硬件之间有一个快速的反馈周期,这可以降低风险——但是硬件可能存在测试环境可用性和测试数据设置方面的问题。

6.模拟(进程内或通过网络/远程)。

团队必须知道如何使用进程内的模拟。

模拟有助于降低测试用例的复杂性,减少调查和重现问题的时间,但是会带来API之间存在差异的高风险。它们通过对其他系统的行为进行假设来降低复杂性,但是可能会对API的工作方式做出不正确或过时的假设。项目需求的变更速度越快,保持模型新就越重要。请参阅契约测试以了解减少这种风险的策略。