软件可测试性（简称可测性），是指在给定环境中，软件对测试工作的支援程度。从测试角度来看，软件的可测试性越高，测试覆盖率和测试效率就越高。如果软件的可测性低，会造成测试任务难以进展、工作量增多、不可测导致的漏测和线上问题等情况发生。如何从提升可测性来提升测试效率、测试覆盖率将是研发质量团队面临的严峻问题。

本文将主要介绍在微保车险类保险产品测试中，是怎样解决可测性问题的。

微保作为互联网保险平台，和保险公司深度合作，共同研发产品。在投保类功能测试中，对保险公司测试环境有强依赖性，这种依赖性在车险产品中显得更加重要。

以车险续保功能为例，保险公司的核心系统中需要有车辆的相关信息数据，才能针对该车辆进行新一年的车险投保，如车辆信息、投保限制、投保信息、交强险信息等。测试阶段进行功能验证时，需要保险公司支持提供虚拟车辆信息，在对数据需求和数据构造问题的沟通交流上，需要我方和保司侧提供专人持续跟进数据问题，提供一批测试数据往往需要5天时间。

而拿到数据只是测试的第一步，在测试过程中还会遇到各种阻塞性的问题，如：

• 对保险公司测试环境强依赖，遇到服务更新或重启情况时阻塞测试

• 构建测试账号流程繁琐，测试等待时间长

• 保险公司调试服务、解决问题沟通成本高

• 特定场景返回值触发困难，异常场景不可控

对于互联网公司敏捷研发流程来说，这样的测试流程加大了测试成本，严重影响了测试进度和项目进度，并且对于各种异常场景无法覆盖完全。在功能测试已经无法完全保证的情况下，也无法进行进一步的接口测试、性能测试、自动化测试、和上线发布验证。

因此，我们决定和保险公司进行解耦，使用Mock 方式来模拟一家车险保险公司，便于我方自己构造测试数据，解决产品的可测性问题

在决定使用Mock模拟保险公司投保服务后，对行业内的开源Mock工具进行调研，发现已有的Mock工具存在局限性如：针对固定请求报文特性进行文本匹配，模拟所有请求情况需要穷举工作量较大，无法提供异步回调模式等问题。

所以我们决定自己开发一套Mock Server系统，来满足以下需求：

• 不影响真实保险公司测试流程

• 不污染真实测试数据、保险公司联调数据，mock数据有标识区分

• 支持投保方案查询、报价、投保、出单接口

• 自定义模拟车辆信息如：车牌号、车架号、品牌、价格、年限信息

• 自定义模拟去年投保方案信息如：交强险起保终保时间、商业险起保终保时间、商业险投保方案

• 根据用户车辆和投保方案，按照基本费率表进行保费计算，针对不同价格、不同方案返回不同的续保价格

研发的Mock Server系统框架主要包括两项内容

1）Mock Server提供数据处理和接口响应

2）Web端可视化测试工具平台

      第一步，针对业务流程开发响应接口，主要模拟方案查询、报价、投保、出单四个接口，按照对接保险公司的协议文档返回响应，与C端接口交互时序图如下图所示。

接口功能详细说明：

1）方案查询

在用户进入车辆续保详情页面时，前端请求方案查询接口，获取用户去年的投保方案信息，Mock Server使用车牌号查询预先写入的车辆信息和去年投保方案，按照接口协议返回投保险种信息

2）报价

       小程序显示车辆信息和去年投保方案后，用户可以操作修改投保信息（如：三者责任险100万调整为200万），用户确认投保方案后请求报价接口对新方案报价。Mock Server将真实报价逻辑进行简化，按照车辆价格、投保险种计算投保费用（如：车损险=车价×0.9%+基础保费(342元)），按照接口协议返回报价信息。

3）投保

用户确认投保方案并进行支付后，调用投保接口进行投保操作，Mock Server接受前端投保请求，记录请求信息，默认返回请求接受成功

4）出单

由于出单接口使用异步处理，Mock Server在投保请求延时3秒后，按照合理算法生成并记录符合规则的保单号，将投保信息回调后端服务，即出单成功

    第二步，在不影响小程序真实保险公司数据测试的情况下，将Mock保险公司的数据路由到Mock Server服务中：

1）数据隔离

将Mock Server命名为微保Mock保险公司，代码MOCK，与真实保险公司代码区分。在模拟的用户数据时，车牌号码使用不属于任意省份的“莫MCXXXX”格式，来区分真实保险公司提供数据和Mock车辆数据

2）流量分配

在后台服务中，按照正常流程配置Mock保险公司，配置信息如：保险公司名称，公司代码，机构代码，请求地址即Mock Server接口地址。为用户添加的车辆信息中包括保险公司代码MOCK，后台服务根据保险公司代码将请求发送到对应保司服务地址，Mock Server按照对应接口协议返回接口响应

    第三步，在Mock Server服务已完成的基础上，开发Mock平台web页面，通过页面将车辆信息、续保信息写入到Mock数据库中：

1）数据写入

页面信息内容包括车辆信息和投保信息（去年投保方案），车辆信息中包括车主个人信息、车辆品牌型号，购买年限，以及“莫MC”开头的车牌号码。投保方案信息中，可以设置任意险种是否投保、部分险种可选择是否投保不计免赔。

2）规则限制

根据车险险别投保规则，在平台页面中进行相应规则处理，如：在投保主险后允许添加附加险，按照车辆品牌型号判断玻璃破碎险投保国产或进口，险别未选中时不能选择改险别的不计免赔选项。

    完成以上功能后，Mock Server系统已经可以满足大部分的测试场景需求。在使用一段时间后，我们对系统进行功能扩展和进一步的优化。具体功能如：

1.数据批量构造

针对车险的测试场景中，经常需要大量数据进行场景覆盖，我们将常用的测试场景分为了5类：单独交强险、单独商业险、交强险过期商业险未过期、交强险未过期商业险过期、交强险商业险均未过期，并且设定了各个场景的不同险种方案。在平台中添加“批量创建”功能，只需要输入个人信息，平台自动生产车辆信息和投保方案进行数据写入。

2.报价接口延时

由于车险产品对接了多家保司，每家保司针对报价接口响应时长不一样，可能存在响应时间过长或超时情况，在测试过程中需要验证不同响应时间下小程序前端的用户提示情况。在车辆信息功能中，添加【平均延时】字段，Mock Server在接到延时信息后，针对该车辆的每个请求进行响应延时。按照真实保司请求接口的响应时间情况（平台端默认设置3秒的平均延时），来模拟真实测试场景。

 3.指定出单结果

测试中除了覆盖正常的测试场景外，验证异常情况下小程序对用户是如何进行提示和响应也是一种重要的测试场景。在第一个Mock Server版本中，对于任何的接口请求都默认为请求成功，没有考虑到异常情况。在总结了几类常见出单失败情况后，对Mock Server的出单功能进行了扩展。在写入数据时新增【出单状态】字段，通过请求的车牌号判断请求的响应结果，覆盖场景如：

  a) 出单成功：单险或者双险投保，均出单成功

  b) 出单失败：单险或者双险投保，均出单失败

  c) 交强无返回：双险投保，只有单商业出单成功返回

  d) 商业无返回：双险投保，只有单交强出单成功返回

  e)  交强失败商业成功：双险投保，单交强出单失败，单商业出单成功

 4.生产验证

由于车险的特性，功能发布后的生产验证需要测试人员有真实的续保车辆信息，并且已在指定的保险公司进行投保，导致发布的新功能基本无法验证。

    我们搭建的Mock Server不影响正常保险公司投保流程，对测试数据进行染色标注，所以可以在生产环境部署Mock Server服务，来解决生产无法验证问题。在保证不影响生产正常功能的前提下，大幅度提升了生产环境的产品可测性。

    综上，我们完成了车险Mock Server工具，实现了对保险公司服务解耦，在测试过程中不需要等待保险公司提供测试数据，而是使用测试工具平台中的车险测试数据构造功能，自定义构造需要的测试数据和测试场景，避免了由于数据问题导致的测试阻塞、场景不可测、沟通人力浪费等问题，数据构造时间由之前的5天缩短到1分钟。

    将测试流程简化后，具体测试步骤如下：

1. 在测试门户平台使用Mock工具对指定用户添加续保车辆自定义信息：

 a) 车辆信息：Mock保险公司、个人信息、车牌号、型号、车辆价格

 b) 投保信息：交强险、商业险投保信息

 2. Mock平台添加数据后，在小程序中可以看到添加的车辆信息，进行报价、修改方案、投保等测试操作。

 3. 测试完成后，使用数据清理工具，将测试车辆相关数据移除，初始化账号数据，进行下一轮验证。

    本文从可测性概念出发，阐述了我们在互联网车险产品测试中遇到的可测性问题，以及Mock Server解决方案。工具经过几个迭代的逐步开发完善，解决了车险保险业务的可测性，提升了测试覆盖率和测试效率。测试平台工具页面也进行了用户体验和视觉优化，让测试变得更高效更便捷。

    未来我们也会根据业务需求逐步添加和完善工具功能，使Mock Server能够覆盖更多的测试场景。进一步覆盖接口测试和性能测试，搭建互联网车险的自动化测试框架，多方面提升测试效率，保证产品质量。

搜索公众号关注：微保技术

or

长按扫码可关注

▼请长按二维码，可加入我们哦！▼