不同于单体应用服务，微服务是根据业务功能划分几个单一的服务，并由这些服务共同协作组成整体的应用架构。每个服务都有自身的功能和设计，可以独立进行开发、部署、升级等。服务之间通过接口或者消息进行通信。
单体应用测试时，通常是对整个流程分模块分场景进行测试，那么对微服务需要进行哪些测试呢？
对单体应用服务来说，如果该服务可用性为99%，那么这个应用的可用性就是99%；但是对于由10个微服务组成的应用来说，如果一个服务的可用性为99%，那么总体的可用性只有90%左右，并且随着链路服务的增加而降低。
所以，最重要的是确保各微服务的可用性，以及服务之间交互的连通性、准确性、容错性。
在测试阶段，首先要进行单一微服务的测试，包括功能测试、性能测试、安全测试等。功能上主要是接口测试，包括单接口测试和场景类测试(因为同一个微服务中的接口都有上下游关系，有进就有出，有增就有减，这部分接口需要串成一些场景来测试)，测试时尽量将用例统一维护好(不管是用jmeter还是用python/java语言的接口框架编写)，能够方便后面的回归和维护工作，同时通过持续集成监控接口的稳定性。
还有可用性测试，在系统负荷达到一定程度或者某个服务出现故障的时候，微服务架构有两种技术来确保系统的可用性：服务的熔断和降级。服务的熔断是指当某个服务出现故障时，为了保证系统整体的可用性，会关闭掉出现故障的服务；服务的降级则是当系统整体负荷过载的时候，考虑关闭某些外围服务来保证系统的整体可用性。所以要对微服务的熔断和降级处理进行测试。
单服务完成后，就是全流程的测试，包括正常场景和异常场景。只验证各种业务场景下服务间的交互、消息处理和数据处理正确是不够的，异常情况下的处理也很重要，服务间消息消费失败或者请求超时都要做重试机制。整个应用的链路很长，不确定因素很多，要探索更多场景，确保整个应用服务是健壮的，数据是一致的。业务时序图可以帮我们理清这中间需要测试和关注的重点。
最后是服务之间的容灾测试(破坏性测试)。在不能确保其他服务可用性是100%的情况下，要保证其中某个服务出现异常的时候，业务能够正常处理，服务恢复时，用户流程可以继续进行。微服务大都用docker部署，可以通过将容器打开/关闭，来测试在某个服务异常关闭时业务的流转情况，十分便利。
上线后，监控和预警仍然是不可或缺的。需要监控单服务的可用性(如CPU、内存、数据库、响应时间等)，当服务调用失败和业务出现异常的时候也需要预警并让相关人员及时处理。特别是作为公共服务的微服务，更需要出现异常时第一时间跟进解决。测试同学可以帮忙梳理监控点和指标，以及当项目未实现线上监控时监督开发增加监控预警功能。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
