SQC是研发管理基础测试组开发的服务级功能和性能测试平台，本篇主要介绍大家在功能测试或性能测试过程中，经常出现依赖的第三方服务不可控/不可用的情况，提供方便易用的mock方式来模拟外部服务，达到测试各种场景的目的。SCF 服务通信框架（Service Communication Framework）是58自主研发的微服务框架。致力于在分布式环境下提供高性能、高可靠、多语言和透明化的解决方案。具有服务注册与发现、负载均衡、动态路由、服务鉴权、服务限流、全方位监控、完善的告警等特点。目前在集团内稳定、可靠地支撑了上万个服务实例，每天支持公司业务2400+亿级调用。
公司的后端服务都是基于SCF框架开发，在日常协作中，经常遇到服务不稳定，不满足需求等情况，开发同学在需要借助mock单测工具，验证方法模块的正确性，另外一些复杂的业务数据，业务之间的交互、联调等场景测试成本较高。经过调研和业务反馈，期望在使用时框架能提供统一的mock功能，帮助大家节省mock成本，提高测试联调效率。对比业界开源的RPC框架，例如dubbo也有自己的mock功能，SCF框架也可以有一个统一的MOCK解决方案！我们是否可以提供统一的mock服务，来减少mock的成本，甚至不用额外的代码编写就可以mock，基于以上想法，我们梳理了各种解决方案，下面是有代表性的三种。1、无关业务代码，通过字节码方式根据接口生成伪的SCF服务程序2、mock服务较多，维护量大，并且会占用大量机器资源1、通过拦截请求的方式，将请求转发到mock服务。2、接入成本：需要针对接口进行插桩开发，并部署插桩模块。1、依赖框架内部细节，实现scf返回协议或对象，成本高。2、mock功能需要在部署时进行注入插桩，有可能影响到框架逻辑。3、服务多版本时，mock服务端需要兼容支持不同的版本接口。方案一的缺点：测试人员都需要部署自己的mock服务，测试数据需要隔离，维护成本高。方案二的缺点：必须了解框架细节，框架升级或者方法变更需要升级拦截器，存在兼容性问题。以上两个mock方案都不够完美，有没有更合理的方案？如果框架调用链上能提供扩展点进行请求前处理或请求后处理，既对框架没有侵入又可以随时插拔。同时又不涉及到业务代码，并且没有额外的部署维护成本，在开发阶段和测试阶段都可以无差别使用mock功能。跟框架部门沟通后，我们有了一个更合适的方案，解决依赖和部署成本，并且有更好的扩展性，例如可以做cdc(契约验证）、扩展协议的mock等方面的能力。1、成本较低：无需额外部署，引入包即可使用mock功能。2、易使用：无需额外的资源支持，通过平台实现mock数据管理。3、易维护：框架层面扩展，对业务代码没有侵入，不影响业务调用关系。5、适用性：单测／联调／测试都适用，并且规则透明，支持scf绑定/解绑。
目前，通过scf框架自身扩展
1、无需修改业务代码，mock功能即插即用，单测或调试都很快捷。3、支持到方法级别的mock，例如：同一个类只mock一个方法，其他方法正常访问真实的scf服务。4、web层与scf联调或部署回归测试更便捷，支持多层scf调用之间的mock。mock平台创建相应的业务名称，自动生成对应的mockKey，scfKey可绑定不同的mockKey，每个mockKey管理一组mock规则。
•支持规则匹配，设置默认规则
mock平台提供服务维度的mock策略，同一个方法可以mock多条规则，例如：1返回a;2返回b;3返回c;default返回d；同一个服务下方法mock规则不可重复。
•支持多版本
mock平台提供同一个服务通过不同mockKey模拟多个版本，一个mockKey对应一个服务版本。
•mock规则开关
•支持多环境
scfmock支持办公环境/测试环境/沙箱环境，暂不支持线上环境使用。
•提供对应的Api方式
sqc提供mockApi方便在自动化测试过程中，通过API创建和管理mock规则，目前已接入商业测试团队和安居客测试团队。
•Filters配置支持客户端是否开启mock功能
后记
例如：1返回a;2返回b;3返回c;default返回d；同一个服务下方法mock规则不可重复；支持部分参数创建规则，规则之间支持权重配置
mock平台通过scf扩展能力，进行SCF访问数据录制
以上是我们的针对公司内部框架的mock方案的初步实现，欢迎大家使用交流。
作者简介
侯会斌，技术平台测试架构师，负责框架/存储/搜索/账户等相关业务测试与平台构建，对服务端测试技术有丰富的项目经验。