写点什么

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

作者:老张
  • 2023-03-10
    上海
  • 本文字数:1375 字

    阅读完需:约 5 分钟

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

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

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

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

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


Mock 是什么?

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

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

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


Mock 能解决什么问题

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

  • 自动化测试,依赖第三方的支付或者物流系统,但第三方没办法提供稳定的环境;

  • 微服务架构,开发经常服务联调,但可能其中某个服务还没开发完,但又是强依赖;

  • 全链路压测,线上支付业务总不能真金白银的测试支付吧,需要一种手段来保障可测性;

如上几种场景只是日常工作中比较常见的,但其实 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 服务化本身也更适合当下的软件研发现状,避免内部重复实现和造轮子。

发布于: 刚刚阅读数: 2
用户头像

老张

关注

读书、思辨、审慎。 2019-12-02 加入

公众号:老张的求知思考世界 博客园:https://www.cnblogs.com/imyalost/ 专注于质量保障建设、DevOps实践、稳定性保障领域

评论

发布
暂无评论
研发提效利器:聊聊mock服务化_Mockito_老张_InfoQ写作社区