微服务的测试策略

在之前的文章中，我们聊了关于单体微服务的测试策略，有读者反馈想知道从宏观上微服务的测试策略要如何进行，本文就来探讨一下这方面的思考。

一、微服务指的是技术层面的服务细化，并不是业务层面的变革。

所以，测试微服务应用程序与测试使用任何其他体系结构构建的应用程序没有什么不同，原来的那套测试理论，还是适用的。

我们暂时把微服务看成是一个较大体系的“黑盒”，因为业务上没有变化，所以我们原来熟悉的等价类、场景法、探索性测试等测试策略还是可以照样执行，没有太多需要做出改变的，因为业务没有太大的变化。需要注意的是，基于风险的测试策略可能会发生一些变化，因为风险因素变多了，需要考虑的影响因子变多，风险分析、评估需要考量更多的内容而已。

02

好了，我们现在再把“黑盒”打开，看看微服务的技术架构给测试带来了哪些新的风险。我们需要针对这些新的挑战做出一些不一样的策略。

微服务的稳定性：在单体架构中，业务的封装调用是基于函数来进行的，几乎不存在调用失败的情况。也不会存在版本不致的情况（都在一套代码内）。但是拆成微服务后，就会面临两个问题。

第一，服务依赖得不可控：因为微服务都是可以被独立部署的，那么部署的版本就会变得不可控，那就意味着可能你调用的接口版本会发生变化，导致调用失败（这类问题会在下次的文章中重点介