云化背景下的接口测试覆盖率自动化检查

一、问题来源

在云化场景下，API的测试覆盖是一项重要评估与考察指标。除了开发者自测试外（UT），还可以利用云化测试平台、流水线等方法进行相关指标的检查与考核。利用这种方法既可以减轻开发者测试工作量，不必在本地做大量的、降低人为指标灰度空间，又可以自动识别重要接口，实现测试数字化与自动化、复用测试用例资产。
这里，我们简单对接口测试覆盖率自动化检查办法的相关实践进行说明。

二、基本思路

首先，在目前的常见DevOps云化平台中，基本都有各自对应的测试平台，用于方便、快捷地在线编写用例、执行相关测试任务。
其次，在服务部署时，云化背景中都是通过DevOps流水线来进行的，而为了保证发布版本的合规与可信，我们通常会在流水线中添加相关检查与卡点门禁。
最后，在服务上线后的运维阶段，APM（应用性能管理）平台会对服务线上接口调用情况做各个维度的统计分析，其中就包括了最基础的接口调用环境与具体内容。
基于以上三点思考，我们提出利用实际调用链用户侧使用数据聚合统计API实例，并利用门禁插件与云化测试相结合的方法，来实现对服务接口测试覆盖率的自动检查功能。

三、实践办法

1、API基线统计方法

对于哪些API需要看护统计，这其中是需要我们做自动化的识别与统计的。正如第二部分所提到的，我们可以直接利用调用链数据来做聚合统计分析，找到哪些接口调用次数最多、哪些接口是在生产环境中被实际使用到的。对于这类接口，自然是重要等级的接口，因此在测试覆盖上我们就需要有强制要求。
通过这种接口分层分级的方法，我们便能够快速识别重要接口，在保证测试覆盖核心接口的同时，减少服务自身用例编写与维护的工作量。

2、云化测试用例

在云化测试平台中，接口测试本质上就是利用可视化的AW（ActionWord，可以理解为一个接口单元）进行用例撰写，并通过在线的执行机发起测试请求、通过对比检查点来判断用例是否执行通过。
因此，服务方面只需要在平台中导入对应的接口设计文档yaml文件，编辑维护好对应的测试用例，并将对应的测试用例统一编排在同一个测试任务中，就能够一次全量执行、作为一个统一的视角对外提供，用以表达当前服务接口功能的可用性与正确性。

3、流水线插件检查方法

在目前的DevOps流水线体系中，服务只需要点击按钮、跑一下流水线，就能够自动的将代码仓中的内容部署到现网的机器中。这种方式虽然方便，但为了保证整体上线功能的可靠性，我们会在流水线的各个环节中添加门禁与卡点，包括安全问题、病毒扫描、开源风险等等。
基于这种门禁卡点与检查的逻辑，我们便能够直接在流水线中强制添加一个接口覆盖率检查的环节，通过获取服务对应云化测试任务中所有接口的测试结果，并根据我们API基线的统计数据分析，以此对比得出对应服务的重要接口是否有测试用例覆盖。

四、发散与扩展

在上述所说的接口检查中，本质上只做了API是否有用例覆盖的相关检查，并没有更详尽的检测，而在接口测试维度，依旧存在着很多痛点与问题。
用例，代表了服务对用户调用接口行为的模仿与预测，并制定出的执行测试样例。虽然在一定程度上可以检验接口功能的可用性，但是会存在一些问题：对于一个接口而言，不同的参数调用组合，实际代表的其实是用户不同的行为逻辑，而这种不同的参数组合在代码层面可能会代表截然不同的行径与分支，从而带来各种各样的结果。测试人员在编写用例时，只能在局限的范围内尽可能模仿用户的使用行为逻辑，但很难将用户的全部行为都囊括在其中。
因此，基于调用链大数据分析手段，我们对海量的用户接口调用与参数情况做聚类分析，并提出了一种名为“用户场景覆盖率”的看护维度。

1、用户场景覆盖情况

该场景原始数据来源为鲁班调用链，经过我们大数据聚合分析之后可以得到具体结果：在生产环境中，用户调用的相关实际接口、调用参数组合以及各参数组合的调用次数情况。
同时，针对大数据的分析手段，我们可以对具体参数组合调用次数做分析统计，并针对性地引入“高频”的概念以定级：对于调用次数较少的的级别的场景，我们倾向于是不重要的或异常的调用，找出调用次数多的高频场景。

2、用例场景覆盖情况

基于微服务所配置的功能测试套，解析对应的用例接口以及相应的参数选择情况，就可以找到服务侧所定义的接口场景覆盖情况。
最后，上述两种的参数组合覆盖情况的差集，就可以得到了接口对应用户场景未覆盖的情况。
加之结合用例自动化的生成手段，就可以较为方便快捷的为服务提供接口调用场景的缺失与待补充情况，作为用例设计的指导。