背景：接口自动化测试一直是服务端的有效质量保证手段之一。而对于接口自动化通常会有代码覆盖率指标来作为度量指标。在自动化工作开展初期，代码覆盖率指标还能够明确地引导自动化建设，自动化测试效果提升明显。但是随着自动化建设工作的开展，代码覆盖率逐渐达到瓶颈难以继续提升，难以再引导自动化建设方向。

因此探索新的指标逐渐提上日程。

作者｜玄龄&之初
来源｜酷家乐技术质量

一、分析

对于接口测试的代码覆盖率瓶颈主要有几个原因：

1.极端场景下的特殊逻辑：对于一些极端场景可能存在一些防御性编程，这部分代码难以被测试。

2.接口测试本身可覆盖场景有限：受限于接口测试，难以控制所有输入端（依赖服务、数据等），因此无法控制所有场景覆盖。

3.测试人员认识不到位：接口测试作为一种主动测试，完全依赖于测试人员对系统的了解以及用例设计水平，因此会存在用例遗漏。

对于原因 1、2，在接口自动化测试中难以有效解决，这边不做探究。

因此我们的探索方向主要集中在原因 3：如何提高测试人员对系统的了解。

或者更近一步，是否可以直接告诉测试人员应该写哪些用例？

二、方案

基于以上思路，我们进行了流量分析方案的探索：

对系统的业务流量以及测试流量（接口测试）进行分别收集、分析，提取出其中的场景特征进行匹配，从而得到接口场景的覆盖情况。同时可以基于业务流量进行用例的辅助生成，降低用例编写成本。

场景特征提取

可以看到上述方案中最为关键的就是场景特征提取。那么这里要回答一个问题：什么信息能代表一个业务场景？

public boolean 出价(价格){  
  if(价格<5):      
  return false;  
else:    
  return true; 
}

这里以伪代码作为示例: 假设我们有一个'出价'接口,那么来分析下这个接口的业务场景有哪些:

业务层面: 两种场景 1.出价大于等于 5,出价成功；2. 出价小于 5,出价失败

数据层面: 两种逻辑 (代码) 分支: 1. 分支 1,返回 false；2.分支 2,返回 true

场景特征提取就是从数据层面向业务层面反推的过程, 我们需要根据数据来分析出业务层面可能存在的场景。

那么数据层面有哪些信息呢? 再来一个例子

public void A(){    
     if(condition):        
        B(1)    
    else:        
       B(2)
}
public void B(){    
...
     }

假设我们有一个'A'接口,那么他的数据信息是什么呢?

第一种: 两个分支，分支 1 调用 B(1),分支 2 调用 B(2)

第二种: 抽象一点，先调用 A 函数, A 函数中调用 B() 函数

第三种: 具象一点，可能 CPU 的多次计算

以上几种都是这端逻辑的数据信息，可以看出数据信息没有明确定义，其本质是对程序执行过程的抽象，其内容的差异取决于抽象的层次。

那么在哪个层次抽象更合适呢? 这并没有准确答案。目前我们是在微服务子调用堆栈层面进行尝试，将不同场景下的微服务子调用差异作为场景特征进行区分。

示例:

场景 1: 接口存在顺序调用 A/B/C 三个子服务

场景 2: 接口存在顺序调用 A/C 两个自服务

三、效果展示

接口场景分析结果展示

在接口自动化平台中，会以接口维度进行场景覆盖的展示，存在 3 种覆盖情况：

未采集：测试用例的场景，在业务流量中没有被采集到 (业务流量可能采集不全)

已覆盖：测试用例的场景，在业务流量中也存在，所以为已覆盖场景

未覆盖：存在测试用例未覆盖的场景特征

接口场景分析具体信息

在接口详情增加了场景覆盖分析页，可以看到分析得到的场景特征 (子调用堆栈)

比如：account@AccountAp/getUserIdByNode~G 代表了该接口调用了调用了 account 服务的 AccountAp 类中的 getUserIdByNode 方法

接口场景流量详情

点击流量数量来查看采集到的流量详情

生成用例

点击用例生成，自动跳转到接口自动化平台的新增 case 界面，根据采集到的流量自动填充 header、入参等

测试同学可以直接修改 cookie/header/域名等参数来进行调试，调试完成后将生成的用例关联到测试计划中进行执行。

四、最佳实践—定制订单服务

定制订单服务是酷家乐后端核心服务之一，也是很多大客户生产链路核心环节之一。但服务历史悠久代码量巨大，复杂场景的数据构造又需要多个业务线的配合，使得接口自动化覆盖率提升成本较高。

如 search 接口查询条件涉及众多其他服务，入参排列组合多，手工新增费时费力。使用流量分析可以快速地自动生成，避免大量的重复工作。

对于核心接口，可以借助流量分析来研究这些场景之前没有覆盖到的原因，并将数据复制到测试账号后作为长期入参使用。

借助流量分析，覆盖率提升又快又稳。

实践总结

而流量分析可以帮助测试同学更深入的了解到接口的完整调用链路和真实的覆盖情况。

对于复杂场景数据的构造，可以通过分析或拷贝的方式添加到自己的自动化测试账号，节省大量的沟通协作成本。

对于入参组合繁琐的接口，我们可以利用自动生成用例功能快速生成，提升用例编写效率。

当自动生成用例后，还需要对这些用例进行分析，搞清楚为什么这种场景之前没有覆盖到、为什么这种入参会触发不一样的链路，从而加强对业务的理解深度和广度。

五、总结

当自动化测试工作开展一定程度之后，代码覆盖率指标逐渐达到瓶颈难以提升。此时想进一步提升，则对测试同学对被测服务的理解提出更高的要求。

而流量分析可以通过对被测服务的链路信息收集，提供测试同学一种更加白盒化的信息，从而提升测试同学对被测服务的理解，赋予测试同学查漏补缺的一种新视角。

更多分享！

今年 7 月 15 日，MTSC 中国互联网测试开发大会（上海站），来自酷家乐的行业专家们，针对接口自动化、线下环境稳定性建设、稳定性保障、大客户质量保障、渲染质量保障等话题，将进行专场分享。

感兴趣的朋友们，快来看！