研发提效利器：聊聊mock服务化

86 2024-02-23

Mock 服务化自动化测试

前两天公众号后台有同学留言问了这样一个问题：

接口测试时依赖调用外部第三方平台，三方平台不稳定经常报错，该如何解决这个问题？

看到这个问题我的第一反应是通过mock的方式来解决。但仔细想了下，这位同学的疑惑其实不是如何解决具体的问题，而是类似的问题有没有很好的分析思路和解决方案。

其实mock除了可以解决上述的问题，它适用于研发过程各阶段，比如：服务联调、性能测试、自动化测试、流量染色和录制回放等场景。这篇文章，我想聊聊我对于mock的理解，它的特点、应用场景以及价值。

Mock是什么？

其实mock还有个称呼，叫做“挡板”。即在某个流程环节起到阻拦、保护的作用。

我们日常的软件研发工作中，整个过程还是比较长的。从需求到线上发布，要经过多个角色多个流程协同配合才能完成。如果按照瀑布模型按部就班的迭代，每个环节经过足够的设计、开发、验证再交付到下个环节，那mock的价值其实不大。但随着业务迭代的不断加快，软件系统架构也越来越复杂，多任务并行的状况越来越多。这个时候为了防止某个中间环节阻塞导致后续任务无法开展，就需要一种方法或者工具，来保证任务的正常开展。

简单理解，mock就是一种降低阻塞风险的方法。

Mock能解决什么问题

举几个常见的工作案例，就能明白mock的作用和应用场景了。

自动化测试，依赖第三方的支付或者物流系统，但第三方没办法提供稳定的环境；
微服务架构，开发经常服务联调，但可能其中某个服务还没开发完，但又是强依赖；
全链路压测，线上支付业务总不能真金白银测试支付，需要一种手段来保障可测性；

如上几种场景只是日常工作中比较常见的，但其实mock应用的场景是很多的。

原则上只要是类似遇到阻塞但又要保证任务进度的事情，都可以采用类似的思路或者方法来进行。

我的理解，mock不仅仅是一种技术手段或工具，而是一种解决问题的思考方式。逆向思考，如果我们在工作开展前能尽可能的考虑到风险并做好冗余措施，就可以更好的提高效率和保障交付质量。

Mock工具选型和推荐

目前市场上商用的、免费开源的mock工具其实挺多的，随便搜搜就有很多。但在实际应用中，技术选型还是要考虑到工具的适配性、落地难度和后期维护成本，以及学习成本。

我个人认为，一个好的mock工具&框架应该满足如下几个特点：

支持多语言多协议（适应不同的技术栈）；
强大的自定义语法，可以灵活配置规则和返回数据；
较好的断言和校验能力，支持条件触发和规则匹配；
开箱即用，较低的学习落地成本以及较低的维护成本；
完善的官方文档和活跃的社区，避免后期无人维护和更新；
一定的数据导入导出和接口/配置管理功能，便于集成到技术体系中；

综合上述几个特点，我个人比较推荐这两个工具：Apifox（商业）和 Mockito（开源）。

当然，具体选型和使用，还是需要结合实际的情况来判断。

Mock服务化的价值体现

近几年很流行这样一句话：XXX即服务。

以前的IaaS、PaaS、SaaS，近几年的BaaS(后端即服务)、FaaS(函数即服务)、NaaS(网络即服务)，其中都有aaS。这里的aas就是 As-a-Service，xxx即为服务的意思。

不是无脑跟风，我个人觉得Mock即服务，或者说Mock服务化，在架构越发复杂和迭代越来越快的情况下，可以很好的体现其价值。

一方面，将Mock服务化，其他调用方或者使用方只需要简单便捷的操作即可快速解决问题，提升研发效率和任务进度，降低风险；另一方面，Mock服务化本身也更适合当下的软件研发现状，避免内部重复实现和造轮子。

原文链接： http://mp.weixin.qq.com/s?__biz=Mzg2NDAwMjM1NQ==&mid=2247486807&idx=1&sn=2761b3f867d464f978f6d24be7e690c4&chksm=ce71450bf906cc1da4d14e5f9c1e77f0d9e39959e4b7419672bfef960a6e016a58dcd46f7525#rd