微服务架构测试策略
微服务架构的测试思考和实践（一）里我们强调了测试的重要性，这一部分我们来聊聊微服务架构的测试策略。说到微服务架构下的测试策略，就不得不提起Martin Fowler和Toby Clemson的《Testing Strategies in a Microservice Architecture》和测试金字塔模型（图1）。
测试金字塔由底向上分别是单元测试、集成测试、组件测试、端到端测试和探索性测试。单元测试是类级别的测试，是对类或者类群的逻辑实现的验证；集成测试是接口级别的测试，是对接口的逻辑实现和数据存储等的验证；组件测试是微服务级别的测试，是对微服务之间的协同功能的验证。通过组合单元测试、集成测试、组件测试的策略可以确保微服务的业务逻辑被正确实现。在此之上，再通过端到端测试和探索性测试，来验证整个系统是否实现了业务需求。
对于测试金字塔，越底层效率越高、成本越低，也越容易自动化实现，因此在测试金字塔模型的落地实施时往往会结合自动化测试的策略，这也就有了目前业界应用最广泛的自动化测试金字塔模型（图2）。
自动化测试金字塔模型来源于图1的测试金字塔和图3的自动化金字塔两个模型，图3的自动化金字塔由Lisa Grispin在《Agile Testing》一书中提出，基于此模型又衍生出很多有意思的自动化测试模式，有兴趣的同学可以网上找资料学习，这里不再展开。
在车险承保系统微服务架构改造的项目测试过程中，我们基于图2的自动化测试金字塔模型做了进一步的优化，在契约自动化测试层和界面自动化测试层之间，增加了接口串联自动化测试层，形成了图4的新型自动化测试金字塔模型。
接口串联自动化测试是接口层面的端到端测试，之所以增加这一层，主要是从以下两方面考虑：
一方面是将其作为中台微服务提测的准入标准。微服务架构的前台和中台是分离的，有时候分属于不同的项目组负责，当中台的某个微服务发生了改造，不能仅仅只针对此微服务进行接口测试和契约测试，还要考虑此微服务的改造是否会影响整个中台业务流程的完整性和正确性，这就需要通过接口的串联测试来保证。
另一方面是为了覆盖更多的业务场景。在我们对业务需求进行测试时，往往希望尽可能多的覆盖页面不同字段的排列组合场景。如果依赖于前台界面的端到端自动化测试，不仅开发维护成本高，而且执行起来又慢又不稳定。但是，如果下沉到中台通过接口串联自动化测试的方式来执行，不仅开发成本很低（可复用第二层的单接口测试脚本），而且执行的速度和效率会呈几何倍数的提升。一个前台页面需要执行10分钟的自动化测试场景，用中台接口串联自动化测试执行可能仅仅需要30秒钟甚至更短的时间。
因此，在制定微服务架构的整体测试策略时，建议采用图4的新型自动化测试金字塔模型。至于每一层应该投入的成本占比，目前业界并没有统一的定论，还需要团队根据自身的实际情况来具体考量。我这边随着项目的推进，也会定期收集并分析每一层测试的投入产出数据，希望有一天能够得到些许有价值的结论可供诸位参考。
