一、说在前面
基于微服务或者SOA的自动化测试系统每个公司都有自己的特有的，我今天就主要介绍一下，我们研发的一套mock测试系统。
二、目前面临的问题
1、测试人员面临的测试问题
我公司目前用的是基于Dubbo的微服务改造，服务之间的调用链路冗长，每个服务又是单独的团队在维护，每个团队又在不断的演进和维护各个服务，那么对测试人员将是非常大的挑战。
测试人员每次进行功能测试的时候，测试用例每次都需要重新写一遍，无法将测试用例的数据沉淀，尤其是做自动化测试的时候，测试人员准备测试数据就需要很长时间，效率非常低。
目前接口自动化测试框架也多种多样，testng，junit，Fitnesse等，但都需要测试人员具备测试代码编写能力，如果要做好和手工接口测试一样效果的自动化测试更是需要大量的代码堆积，后期维护代码成本非常大。因此做成简单配置用例流，无需编写测试代码的系统是更贴合实际工作要求。
举个例子：拿互联网支付系统来说，某个团队新增了支付交易的需求，这时候要进行测试，测试人员除了要测试支付交易需求本身是否正确，同时也要结合上下游的服务整体进行回归测试，这时候开发人员往往在支付交易系统中采用“硬编码”的方式对上下游的系统进行“挡板”，如果测试人员对测试数据有所调整那么“挡板”也要跟着调整，同时在项目正式上线的时候，如果开发人员没有将“挡板”程序去除干净，将面临严重的线上问题。
2、测试人员如何验证数据
-
接口返回值
通过肉眼分析比对接口返回值的内容，判断业务逻辑正确性。 -
数据库验证
测试接口的输入值需要通过手工编写数据库SQL查询获取，接口调用完成后，需要通过大量的SQL验证数据库值的正确性。 -
日志验证
通过返回值和数据库不能确保代码走到了预期的逻辑，只能通过肉眼观察日志确认代码的实际运行逻辑 -
测试报告
人工记录用例结果，人工编写报告，耗时耗力，难以准确定位代码问题
三、Mock模拟系统的产生
业务系统调用众多其他系统完成功能逻辑，而想要得到其他系统接口的特定输出，需要做相应的运营配置，增加很多的沟通成本；甚至偶发性bug只能在特定的环境状况下复现，只能作为不可测的逻辑。
以风控系统为例，如果业务系统需要测试某个商编某个商品类别下的累积限额，需要风控的同事配合不断修改限额阈值，目前的情况是多个业务系统都在接入风控，配合测试的人力成本和时间成本是很高的。为此设计了挡板模拟系统，其功能结构如下：
针对测试人员测试用例数据无法沉淀和复用的问题，我们将采用“用例与日志锚点库”方案：
用例库的建立可以实现对以往测试规则的记录与复用，改变每次回归测试都要重复编写用例与准备数据的现状。
日志锚点库是对代码执行流程的有效验证，除了可以应用在测试环境中，还可基于大数据日志中心对生产代码的运行做日常监控。
交易与支付系统业务逻辑复杂，靠人脑和文档记忆功能关系难免疏漏，而用例库和日志锚点库会随着业务的变更测试而随即维护，是一部活文档。
四、Mock系统的技术方案
1、系统的功能点
说明： 上图罗列了整个Mock测试系统的功能点有哪些，共分为：配置接口数据、创建测试用例、创建测试集、创建测试计划、执行测试计划以及生成测试报告等大功能。
- 配置接口数据界面图
- 创建测试用例配置图
- 挡板请求路由配置图
- 测试执行结果
2、系统的功能流程图
说明：
依据上下文环境，利用工厂类动态注入spring对远程接口的依赖，保持线上与测试的代码一致。在测试环境中，通过mock系统管理端，可以随时调整请求的流向，“指哪打哪”
说明：
执行某项测试用例， 利用mock将被测试接口与底层依赖接口隔离开来，可以方便的模拟数据，并监控输入输出。用例执行完毕后，使用返回断言、SQL查询、日志标记等多种手段验证。
五、感谢与后续
在整个mock测试系统的设计和开发过程中，要特别感谢我的同事刘洋洋，给与的大力支持，目前系统正在部门内推广使用中。自动测试的目的是模拟人的行为，用机器代替人工，高效而且便捷，节省人工成本并且有效的解决目前业务系统频繁升级导致的大量回归测试。
目前的系统处在1.0的版本中，后续我们会继续推出升级版本，待系统的稳定性和性能完善后我们可以开源出来，供大家使用和参考。
