传统测试与微服务测试的区别传统测试模型抽象上图中的服务端包括n个功能，传统服务都是将功能部署在一个上机，通过增加服务器数量来扩容！参考下图（每种颜色代表一个功能，部署了四套相同的服务）。微服务测试模型抽象微服务不同于传统的测试。它通常没有UI页面。我们需要通过构建请求（通过编码或工具模拟）来调用各个服务接口。微服务部署在业务单元中。上图中的每个服务代表一个功能。不同的业务部署在不同的服务器上。经常使用的服务可以使用更多的资源来部署（下图中橙色（黄色部署5个，玫红只部署1个）），这样可以更合理地使用资源。微服务的主要测试内容单元测试：从服务中最小可测试单元的角度，验证代码行为是否符合预期，从而测试方法和类级别的缺陷。集成测试：验证当前服务与外部模块的通信方式或交互是否符合预期，从而测试出接口缺陷。组件测试：将测试范围限制在被测系统的一部分（通常是单个服务），并使用测试替身（模拟）将其与其他组件隔离，以测试被测代码中的缺陷。契约测试：验证当前服务与外部服务的交互是否符合消费者服务所期望的契约，本质上是验证接口规范UI测试：传统的一点一点的页面测试。其中，集成测试、组件测试和契约测试是我们的测试重点，以上三种测试可以理解为接口测试（这里不详细介绍什么是接口测试）。即每个服务提供一个对外的接口，然后我们通过这个接口调用服务，最后验证返回值是否符合预期！我们可以使用编码或者工具来构建接口并向接口发起请求，然后根据接口文档验证响应是否符合预期。微服务测试注意事项微服务可以分为非依赖服务和依赖服务。免依赖服务：无需其他服务提供功能，即可提供完整的服务功能，满足调用者的需求。我们可以直接测试服务提供的接口。依赖服务：自身不能满足调用者的需求，需要其他服务提供一项或多项功能，共同向调用者提供完整的服务功能。这时候我们就需要隔离单个微服务所依赖的其他微服务，避免在测试过程中受到依赖服务的影响（如服务不可用、服务缺陷等），导致测试过程阻塞和无效测试。mock技术通常用于将被测服务与依赖服务隔离，使服务链路稳定，环境可控，有利于测试流程的开发。Mock的概念起源于单元测试。在单元测试中，我们只关注被测单元，不关心其他依赖的内容。Mock让我们有一个模拟的环境，我们在单元内部流程检查时不用担心因为环境导致验证过程失败。由于外部环境的多样性，单元测试应该设计一些异常场景，让代码能够捕捉到异常。比如下图a，如果我们要测试A，首先要构建整个依赖树，它是BCDE的一个实例，这种方案的成本是非常高的。另一种方法是使用mock，如图b所示，我们只需要指定MockB和MockC在收到A的请求后给出相应的响应即可（不需要在MockB和MockC操作中执行复杂的逻辑）。在代码实现层面，我们可以通过mockito(forjava)来实现mock操作。图a图b微服务测试中mock的服务是什么？比如我们把支付功能做成一个微服务，负责处理支付逻辑，在最后的支付中，我们需要调用支付宝完成支付。那么如何处理这种情况呢？简单的方法，我们花一分钱实际购买服务。那么假设我们要验证10000元的购买服务呢？或者当支付宝出错的时候我们的程序应该怎么办？这里我们可以使用支付宝作为模拟服务。核心实现思路如下：分析应用请求，并返回一个预定义的响应值，如下：1.支付请求验证无误，返回支付成功；2.付款请求验证失败，退回付款失败；3.关闭支付宝mock服务，可以模拟支付宝异常我们可以使用wiremock搭建自己的mockserver。简单的原理如下图所示：我们需要在配置文件中设置一个预定义的请求，如果应用程序的请求满足预定义的请求，则返回一个预定义的响应。然后启动wiremock实现请求处理，wiremock是一个web服务器！详细可以参考：https://github.com/tomakehurst/wiremock微服务测试总结1.如果只做UI功能测试，那么微服务测试和传统测试没有区别，因为你感受不到架构的变化。2、各个微服务提供的接口测试，本质上等同于接口测试。需要根据微服务的接口描述文档，对接口功能、性能和安全进行测试。3、如果需要，需要使用mock方法模拟微服务所依赖的服务，提高被测服务的可测试性。4、注意负载均衡，测试请求是否分布到多点应用。参考文章：微服务性能测试的关键-IP欺骗技术5.通过工具SpringCloudSleuth、Turbine、Prometheus监控各个服务消耗的资源（包括：cpu、内存、磁盘、网络）；6、通过ELK（ElasticStack）集中管理日志。参考文章：微服务测试的关键——通过ELK查询日志7.理解微服务的核心概念。参考文章：一文搞定微服务测试精髓
