• Mock服务化能给我们带来什么价值提升?
  • 发布于 2个月前
  • 246 热度
    0 评论
前两天有同学留言问了这样一个问题:接口测试时依赖调用外部第三方平台,三方平台不稳定经常报错,该如何解决这个问题?
看到这个问题我的第一反应是通过mock的方式来解决。但仔细想了下,这位同学的疑惑其实不是如何解决具体的问题,而是类似的问题有没有很好的分析思路和解决方案。其实mock除了可以解决上述的问题,它适用于研发过程各阶段,比如:服务联调、性能测试、自动化测试、流量染色和录制回放等场景。这篇文章,我想聊聊我对于mock的理解,它的特点、应用场景以及价值。

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

Mock能解决什么问题
举几个常见的工作案例,就能明白mock的作用和应用场景了:
1.自动化测试,依赖第三方的支付或者物流系统,但第三方没办法提供稳定的环境;
2.微服务架构,开发经常服务联调,但可能其中某个服务还没开发完,但又是强依赖;
3.全链路压测,线上支付业务总不能真金白银测试支付,需要一种手段来保障可测性;
如上几种场景只是日常工作中比较常见的,但其实mock应用的场景是很多的。原则上只要是类似遇到阻塞但又要保证任务进度的事情,都可以采用类似的思路或者方法来进行。我的理解,mock不仅仅是一种技术手段或工具,而是一种解决问题的思考方式。逆向思考,如果我们在工作开展前能尽可能的考虑到风险并做好冗余措施,就可以更好的提高效率和保障交付质量。

Mock工具选型和推荐
目前市场上商用的、免费开源的mock工具其实挺多的,随便搜搜就有很多。但在实际应用中,技术选型还是要考虑到工具的适配性、落地难度和后期维护成本,以及学习成本。我个人认为,一个好的mock工具&框架应该满足如下几个特点:
1.支持多语言多协议(适应不同的技术栈);
2.强大的自定义语法,可以灵活配置规则和返回数据;
3.较好的断言和校验能力,支持条件触发和规则匹配;
4.开箱即用,较低的学习落地成本以及较低的维护成本;
5.完善的官方文档和活跃的社区,避免后期无人维护和更新;
6.一定的数据导入导出和接口/配置管理功能,便于集成到技术体系中;
综合上述几个特点,我个人比较推荐这两个工具:Apifox(商业)和 Mockito(开源)。
当然,具体选型和使用,还是需要结合实际的情况来判断。

Mock服务化的价值体现

近几年很流行这样一句话:XXX即服务。以前的IaaS、PaaS、SaaS,近几年的BaaS(后端即服务)、FaaS(函数即服务)、NaaS(网络即服务),其中都有aaS。这里的aas就是 As-a-Service,xxx即为服务的意思。不是无脑跟风,我个人觉得Mock即服务,或者说Mock服务化,在架构越发复杂和迭代越来越快的情况下,可以很好的体现其价值。


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