AI原生实践：测试用例创作探索

百度Geek说2024年05月06日约 8 分钟

基于需求生成脑图用例：输入需求，一键生成测试用例，2个月生成并被采纳用例达2.6w 条

移动生态事业群组大部分业务都通过思维导图（脑图）来编辑测试用例，但是不同经验水平同学编写的测试用例参差不齐。业务和测试经验越丰富的 QA 同学可以写出更好的测试用例，反之则有可能会出现遗漏或者冗余，带来质量问题或者降低测试效率，但遇到研发人员流动则会加剧这个问题。但好在，生成式 AI 的快速发展，使得其已经具备了处理这一复杂任务的能力，其不仅能有效持久化业务及测试经验，辅助 QA 快速编写完备的测试用例，还可以通过标准化的生成输出，使得用例更易于理解及传承。

QAMate 项目组基于文心大模型，通过构建针对测试用例智能生成的标准化开放共建的 Prompt 层，基于成熟的脑图用例产品构建同测试人员直接闭环的数据飞轮，及测试&业务经验外挂知识库，实现了基于需求生成脑图用例的能力。

Prompt 层开源共建：采用开放 Prompt 层同各业务同学协同共建的模式，使得分业务可以规范输入输出、规则明确、针对特定场景优化 Prompt，从而最大程度激发大模型效果

数据飞轮构建：完成了「用例生成 -> 生成用例采纳/删除；人工修正/添加用例 -> 业务个性化模型训练」数据飞轮的构建，经业务线评估，启用个性化模型的生成效果会优于92%通用模型的输出效果

建构外挂知识库：持久化测试经验&业务知识，进一步增强了生成效果

当前 QAMate 已经支持了基于需求文本、表格及整份需求文档生成测试用例，并支持用户构建专属 Prompt、业务经验知识库来定向提升生成效果。

APP UI 用例录制回放：点点手机，搞定 UI 自动化用例，累计支撑1.5w 条 UI 用例编写，平均稳定性90%+

众所周知，移动端 APP 的 UI 测试耗时耗力，尤其是集成回归阶段，需要把 UI 测试用例做一遍遍地回归，甚至还需要在多种不同机型上重复这个过程。为了解决这个噩梦，过去数年，不管是业界还是百度内部，都尝试了各种方案，其中最有代表性、影响最广的便是 Appium 自动化测试框架，但是落到实处，Appium 也只是解决了 UI 用例能不能自动化跑起来的问题，基于它构建的各类方案远没有真正达成为业务提效的最终目标。

如下图所示，为文心一言输出的，用 Appium 来编写百度 APP 首页搜索框 UI 自动化用例要做的事情，包括不限于：

安装和配置 Appium 环境、连接设备到 Appium 服务器等

启动 XPath 元素定位功能，查找搜索框的 XPath（类似 com.baidu.Baidu:id/search_button 这类不易理解的代号）

接着编写一大段 Python 脚本等等

其实不难看出，UI 自动化用例的撰写成本很高，而且不仅撰写成本高，稳定性也是影响提效的一大难题。据此前构建的 Fast UI 自动化平台数据统计，UI 用例执行的稳定性仅70%不到，其核心问题在于 XPath 控件定位容易随 APP 版本不同、机型不同而变得不同，导致用例执行不稳定。而 APP 业务迭代频繁，也让 UI 用例维护、撰写和执行成本直线上升。

QAMate 项目组以 AI 原生为第一视角，直接抛弃了业界惯用的 XPath 的控件定位技术，基于 YOLOv5对象模型构建底层图标&组件模型、整合 OCR 能力、多控件布局算法及多真机云控技术，实现了 APP UI 用例录制回放能力，让用户只需要点点手机就能完成 UI 自动化用例的编写，直接将单 UI 自动化用例步骤编写的成本由40s/步骤降低至了 5s/步骤，用例整体执行的平均稳定性达到了 90%。

以视觉 AI 技术为基底，使得我们可以以人的视角自动化操控 APP，从而无视 APP 跨版本、跨机型兼容等问题，使得用例编写成本直线下降同时用例执行稳定性直线上升。

80%以上的自动化测试场景，都是非常简单直接的单控件检测和点击操作。建设以视觉建模、识别能力为核心的通用控件定位算法解决。

视觉元素建模

视觉特征匹配寻址

对于剩余的20%场景，往往存在大量复杂的多控件协同检测和复杂操作方式。建设综合使用视觉、dom 处理能力的多控件协同控件定位算法进行解决。

基于多种元素重组页面结构建模

多控件布局&特征协同寻址

进一步，通过用例产品闭环用户反馈、自动化执行结果，基于控件准召等指标实现底层视觉模型的自动迭代升级，形成数据飞轮，进而得以持续支撑快速迭代的 APP 业务。

最后，通过将录制回放能力集成于同一工具，使得编写及执行环境高度一致，再基于此构建稳定可靠的云真机控制系统，保障自动化用例高效稳定执行。

基于流量生成接口自动化用例：接口有流量，就有用例，用例生成占比达 76%

服务端接口自动化测试是服务端质量保障非常重要的一个手段，但是服务端接口众多，用例编辑和维护的成本非常的高，虽然自动化手段对于质量保障行之有效，但是也带来了很大的人力成本。

依托生成式 AI，QAMate 实现了基于线上流量的接口自动化用例生成能力，让服务端 QA 同学不用再花费大量人力去补充接口自动化回归用例，只要有线上流量进来，自动生成接口自动化用例。

▎关键实践

■ 基于多种引流方式构建流量接入->分析->用例生成的端到端全流程自动化解决方案,用例编写维护成本节省70%

低成本：eBPF 实时引流方式，用户仅需知道 BNS 就可以配置生成任务，一键完成总引流到生成case的工作，无需任何开发工作

多渠道：提供 eBPF 流量实时录制、XSTP GoReplay 引流、用户流量文件上传等流量接入方式，覆盖不同业务形态的模块

能力强：突破长连接、SSE、chunked 等接口引流能力，支持点到点、inbound 录制模式，提供单接口录制上限等接口录制丰富度相关配置

■ 提供配置化的流量采样和用例生成策略能力，生成用例的覆盖率超过人维护用例

流量采样策略：提供精简采样、优先采样、普通采样、高覆盖采样4种标准采样模式

case 生成策略：提供枚举值遍历、边界值异常、必填项异常、枚举值异常、字段类型异常等多种异常策略

相对原人工维护 case，自动生成的 case 函数覆盖率从14.8%->46.7%，行覆盖率从9.9%->34.7%。单 API 行覆盖率从66%->74.3%

■ 基于文心大模型和业务外挂知识库实现个性化的测试诉求识别和用例转化能力，生成的用例直接满足业务诉求，无需再人工调整

简单的 LUI 支持复杂的用例修改能力：通过 LUI 和 LLM 技术识别用户对于流量用例请求参数、响应断言以及特定场景的复杂修改诉求，保证用例在其他环境的可运行性和问题拦截能力

业务知识库：构建业务知识库存储不同业务的 case 特征，在生成过程中通过检索业务知识，转化为生成诉求的方式，实现生成出满足业务诉求的用例

LUI 使用案例

基于接口/代码生成接口用例：

有了接口文档/代码，就能生成用例

以上基于流量的用例生成只能解决回归测试用例编写和维护的问题，在全新功能的场景下需要寻找其他的解决方案。我们针对这一场景实现了基于代码分析和接口文档变更筛选&生成待测试用例的方案，在研发自测、服务端新功能迭代测试等阶段应用，辅助 RD 和 QA 高效完成新功能自测和测试，提升用例规范性、和测试质量。

▎关键实践

接口文档生成：基于调用链、大模型、业务变更代码影响的接口分析能力，支持直接从变更代码挖掘出影响的接口文档，使得没有标准化、平台化的接口文档管理能力的业务也可接入

业务知识库：通过离线的历史 case 分析和手动录入的方式构件字段字典信息、断言和参数特征等业务知识，解决新接口难以生成正确参数值的问题

端到端方案：生成推荐过程融入业务 RD 和 QA 的日常工作流程中，业务无需调整或增加流程，在原有工作流程中就能直接使用到生成好的用例结果

总结

回顾既有的工作，我们认为，一个 AI 原生的产品，一定要找到自己的数据飞轮，通过数据让自己的能力不断迭代升级，而不是纯靠人工迭代；一定要抛弃方向上的惯性思维，用 AI 手段从人的视角上找解法；此外，还需要想方设法打磨好产品体验，降低用户使用成本，这样才有机会让能力落地，让用户用起来，从而让飞轮转起来。

展望测试用例智能创作方向，能用 AI 技术重构的，远远不止于测试用例的智能生成。测试用例落到研发测试环节，存在一个自有的生命周期：测试用例新引入阶段（新功能或者回归用例的撰写/生成）->执行阶段（新功能/回归用例的签章执行）-> 入库阶段（用例正式入到回归用例集合）-> 回归用例集合（通过筛选进入到当次正式的回归用例集合）->消亡阶段（随着项目的下线或者更改，用例从回归用例集合中删除），这样形成了用例的生命周期。

AI 技术不仅能重塑用例撰写过程，我们相信，未来 AI 还能辅助用例的执行、转化、更新和消亡等过程，进而为研发测试保质提效。