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