智能API测试的探索与实践

简介：API自动化测试在服务器端分层测试体系中占有重要地位。 在不断追求提升研发交付效率的背景下，传统的自动化测试工具在质量和效率上面临着更高的挑战。 智能测试的本质是一种利用数据与算法相结合赋能质量活动的测试方法。 借助智能测试思维，在整个API测试生命周期中进行多环节针对性优化，形成提升测试质量和效率的合力。 。

全文5736字，预计阅读时间16分钟。

1. API测试面临的质量和效率问题

1.1API自动化测试特点

由于API具有良好的可测试性，自然成为服务器端应用程序自动化测试的首选解决方案：

1. API的结构化帮助程序实现请求和解析接口。 目前主要采用Json数据结构作为输入参数和返回结构，可读性强，方便编程处理。

2、API业务逻辑集成度高，测试性价比高。 接口的参数组合具有直接的业务意义。 通过不同的参数组合可以覆盖主要业务场景。

3. API测试执行和维护成本低。 考虑到需要编写的案例的规模、调试和维护的成本，它在测试分层的金字塔概念中起到了腰部支撑的作用。

1.2API自动化测试面临新挑战

随着自动化测试的建设和积累，一站式平台已成为测试服务的主要形式。 几乎整个CASE循环都是在平台内进行的。 平台的建设集成了丰富的测试能力，减少了重复建设。 ，提高了测试服务的可靠性，从完全手动测试到自动化平台的跨越对于提高质量和效率具有重大意义，但同时也面临着需要回答的新问题：

1、整个测试周期人力投入能否得到充分释放：

2、自动化CASE水平急剧扩大，测试效率开始下降，可维护性恶化：

3.自动化CASE测试的质量可信吗？

2.智能测试的基本思路

如何理解智能测试：用数据和算法相结合的方式为质量活动赋能的测试方法，让每一次测试活动都能以较低的成本准确判断质量风险。

（1）智能测试并不是一种新型测试；

（2）智能测试存在于传统测试的一个或多个环节；

（3）传统测试是智能测试发挥作用的最重要载体。

基于自动化测试的整个生命周期，输入、执行、分析、定位、评估都有其对应的数据特征和模式，以及对应的瓶颈。 智能测试旨在提高测试过程各阶段的质量和效率，将数据与策略相结合，形成整体合力。

3. API测试全周期智能测试实践

在智能测试思维的指导下，以API自动化测试平台为载体，结合API测试各个阶段面临的问题进行分而治之。

1.准备CASE：通过自动化生成快速生成CASE，并利用智能策略解决参数组合爆炸和断言缺失的问题。

2、执行CASE：通过任务编排的动态并发策略提高测试效率，通过代码覆盖率的映射关系精准筛选CASE，提高测试效率。

3、结果分析判断：采用Diff去噪策略，保证接口对比测试的调试效率和效果。

4、故障排查和定位原因：通过日志追踪系统和异常错误规则库的构建相结合，提高自动排查和定位的效率。

5.评估测试质量：使用适当的自动化CASE评估方法来评估CASE的有效性，指导CASE优化治理和披露风险。

3.1“自动化+智能化”生成自动化CASE

API CASE主要由三部分组成：接口定义结构、参数数据、断言。 前两部分更容易实现自动化，而断言部分则需要更多考虑智能策略，因为它包含了业务逻辑的验证。

1、接口定义+参数数据自动导入生成：拓展多种对接渠道，建立快速自动生成CASE机制。

自动生成的API CASE主要用于两类场景：

2.自动生成接口断言：尽可能多做一步，为新的CASE和现有的CASE主动生成和推荐断言。 由于JSON是当前API的主要数据交换格式，因此断言生成部分主要关注JSON处理机制。

对于新生成的CASE，结合导入的上游通道中描述的接口定义（包括接口返回结构），可以将json数据直接转换为JSON-schema。

对于现有的因书写不规范而存在断言间隙的CASE，它们无法解决任何拦截问题。 因此，应该从成本角度补充 JSON 模式断言。 根据CASE执行的历史结果数据，提取N条没有异常错误的记录，将其转换为JSON-schema集并计算期间的差异。 将它们的性能与 CASE 参数和执行时间进行比较，并通过不同的规则确定合适的 JSON 模式。 该版本会自动回填到 CASE 中。

经过上述能力建设，目前增量CASE中，自动化手段生成的CASE比例已提升至60%以上，全年为30%。

3.2 自动化CASE执行更加高效有效

1、自动化CASE的“效率”问题：当CASE级别达到千级以上时，执行效率问题就变得更加突出。 基于CASE的历史性能、可执行资源以及规模较大、耗时较长的CASE集合，实现动态预估分组并发执行。 与固定分组相比，充分利用执行资源，有效减少长尾分组。

优化执行模型后，长尾任务数量减少了40%，有利于资源的快速释放，可以消化更多的任务。 整体测试任务平均耗时降低了30%。

2、自动化CASE的“效益”问题：CASE积累到一定阶段后就变得庞大、冗余。 另一个棘手问题是由于维护不及时导致CASE质量无法筛选，全量执行失败率高影响测试效果。 。 因此，推荐使用高度相关的CASE集进行代码变更筛选，可以减少冗余执行，提高效率，实现对代码变更影响范围的“精益”测试。

CASE筛选策略可广泛应用于CI管道的准入测试（冒烟），自动筛选相关CASE，替代人工维护。 筛选后的执行效率相比完全执行可优化70%。

3.3 分析测试结果的智能手段

API测试中有一个场景，API的数据结构比较复杂，数据量很大。 无论是手动设置断言还是自动生成断言，都很难实现更好更准确的覆盖。 对于此类接口，衍生出Diff测试方法来进行测试覆盖率。

差异测试通常用于回归测试。 主要方法是使用相同的接口请求参数，分别发送给A、B两个版本的接口服务。 一种版本是已交付且被认为值得信赖的在线版本。 Diff测试的优点是可以全程自动生成，无需编写断言。 但diff结果比较复杂，一般包含很多随机值，变化的值不是验证的重点，导致案例调试成本较高。

为了解决Diff结果中的“噪声”问题，设置去噪算法，消除Diff结果的不确定性，降低手动案例调试成本，自适应提高案例稳定性。 目前，接口CASE应用于diff测试场景时，大部分断言不需要关注，自适应修正可以100%自动完成，无需人工干预。

3.4 CASE FAIL原因智能分析定位

自动 CASE FAIL 相对常见。 在建设初期或者维护案例比较大的业务中，70%~80%以上的FAIL问题基本上都是由非代码Bug引起的。 这部分调查涉及的人力成本也比较高。 通过自动化平台建立自己的+业务逻辑故障排除服务，采用自动定位和故障排除的方法，可以有效减少这部分人力投入。

1、一级定位：首先，排除自动化测试工具平台、环境、CASE规范等非常明显、容易出现的问题。 这部分工作依赖于自动化测试工具本身的日志构建，建立完整的异常错误码机制，对各个环境中容易出现的异常进行仔细的分类。 例如接口请求失败，需要分类为被测服务异常无法访问还是CASE中的URL填写错误。该工具需要解决的一个策略机制问题是，当异常过多时测试中发生的问题，如何选择一个根本原因作为主要根本原因并将其反馈到测试结果中。 这里的过滤策略首先将CASEID+ERROR作为Key存入缓存中，过滤掉同一个CASE的重复错误； 根据执行测试流程建立ERROR发生时机的优先顺序，当同一个CASE有不同ERROR错误信息时，按顺序推荐第一个错误原因； 当批量CASE中存在多个ERROR错误信息时，区分ERROR计数，选择​​占比最高的错误原因。 这样，20%的CASE FAIL问题就可以自动消除，无需干预。

2.二级定位​​：与一级定位相比，其他FAIL原因与测试环境和测试数据的关系更加密切。 比如被测系统调用第三方API超时不返回，体现在CASE结果断言失败，我们希望能够定位到这个原因，并且定位的路径能够大大提高缩短了。 要实现这个层面的自动定位分析，需要解决两个问题。 第一个是将自动化的CASE与业务系统的日志连接起来。 业务系统首先建立日志追踪机制，可以通过唯一的ID连接一个API请求的流程。 二是针对业务日志中常见的逻辑异常错误建立错误消息规则库。 当FAIL的CASE关联ID发送到日志时，根据已有的错误消息规则库检测日志范围内的匹配结果。 这样可以继续自动消除大约60~70%的FAIL问题。

3.5 自动化CASE的有效性评估

在测试工作中，我们经常对测试交付的质量存在以下顾虑：自动化CASE的测试拦截效果如何？ 通过每项测试我可以高枕无忧吗？ 需要证明自动化 CASE 可以有效地发现 bug，以便对测试行为充满信心。 这就是测试有效性的意义。

上面是一个典型的有效性不足的CASE，即验证点覆盖不够，会漏掉业务逻辑的验证。 业界用于有效性评估的方法大多是突变测试。 学术界还对语句覆盖率、分支覆盖率和突变测试评估的效果进行了对比分析。

结合实际测试工作经验，可分为四个评估方向：

1、静态分析与评估：最基本的方法之一是根据自动化案例本身的写作特点来检查和评估设计的合理性。

2、动态分析评估：根据案例运行后的结果评估执行效果。

3、突变试验评价：是一种研究较多、有一定难度的评价方法。 通过源代码生成变体后，进行测试，看看案例是否能找到变异。 它主要用于白盒测试。

4、错误检测能力评估：在实际工作中，案例存在特殊问题，即有很多同质案例带来额外的执行开销，也有脆弱、不稳定的案例干扰测试结果，需要评估和治理。

对于API测试来说，测试覆盖过程较长，不方便做代码级的变异和检测。 不过，我们可以先从体现CASE本质的基本因素来评价，即上述静态+动态分析方法的结合：

1、CASE规范性：基本因素是断言，体现了测试验证的覆盖范围。 否则，将只有代码覆盖率数据而没有检查点覆盖率。

2、代码覆盖率：代码覆盖率虽然不能作为检验测试质量的唯一标准，但它是基础。 低代码覆盖率必然意味着弱CASE覆盖率。

3、CASE稳定性：CASE设计不充分导致错误频繁，性能波动较大，意味着不可靠。 稳定性差会严重影响测试结果的可信度。

4. CASE活动：运行的频率、暂停和搁置的周期、更新和编辑的次数等，表明CASE是否不再活动并成为空闲CASE。

5、CASE复杂度：当CASE内容过于复杂时，维护成本和运行稳定性风险会比较高。

根据以上数据特征，对每个项目按照不同的权重进行评分，汇总后给出CASE评分。 它用于两个方面。 一是对CASE数据进行评估，为CASE后期维护提供参考。 二是利用检测报告实时披露CASE的质量风险。

4. 总结

回顾API自动化测试智能化改造的实践过程：从痛点出发，由点到线，全面覆盖，全方位优化API测试流程的效率和质量，形成API测试作为自动化测试的有力保障。主流功能回归测试能力。

经过智能化测试改造后，整个API测试流程变得更加精细化，各个环节形成合​​理，全面提升测试过程的效率和质量。

参考链接：