AI Coding 后半程：6 类 QA Skills 如何接住测试与发布？

本文来自花椒技术部真实工程实践。如果你也研究 AI 工程化、Agent 落地，没同行交流、没人拆解实战？可以关注公众号「花椒技术」，回复「AI」加入交流群。，群内每日精选研发向 AI 行业日报，欢迎一起交流～

AI 写代码越来越快之后，研发流程里的压力并没有消失，只是开始往验证和交付环节移动。

一段代码生成出来，距离真正交付还有很长一段路：需求有没有理解偏，测试点有没有遗漏，核心链路能不能跑通，接口结果是否符合预期，测试数据和环境是否正确，真机回归是否稳定，发布前的安装包和检查项是否齐全。

我们更关心的是：这些测试工作里，哪些必须依赖 QA 的业务判断，哪些高度重复、规则相对明确的步骤，可以先沉淀成可复用的 Skill。

我们目前沿着真实测试流程，把已经反复出现、输入输出相对明确的环节，逐步沉淀成可以调用、可以检查、关键操作需要确认的 QA Skills 和平台能力。

一、QA 为什么要沿测试流程分层落地 Skills

测试流程里的重复劳动，不只发生在写测试用例时。

开发自测和提测后快速校验，需要根据需求和代码变更重新整理冒烟重点；正式测试时，需要反复调用接口、准备数据、核对缓存和观察运行结果；真机回归需要准备设备、脚本和运行环境；版本发布前，还要整理安装包、完成真机验证和准备发布材料。

单独看，每一步都不是一个全新的技术问题。但当同样的操作不断重复，质量就很容易依赖个人经验、临时沟通和手工检查。

因此，我们没有先做一个笼统的"测试 Agent"，而是沿着真实 QA 流程，把适合标准化的环节分层落地。先让每一类能力可以独立使用、独立验证；等这些单点能力逐步稳定后，再考虑上下文传递、执行结果交接和流程串联。

这张图展示的是 QA Skills 的能力分层和流程位置。

二、自动化负责重复执行，QA 负责判断

把测试流程拆成 Skills，并不意味着把质量责任交给 AI。Skill 可以承担生成、查询、执行和整理结果，QA 仍然负责业务规则、测试范围、风险操作、异常处理和最终发布结论。

这条边界贯穿后面的六类能力：自动化只接住重复、规则明确且结果可复核的步骤；涉及业务判断、数据安全和发布责任的节点，必须回到人。六类能力讲完后，我们再把这些人工判断统一归纳。

三、六类 QA Skills 如何进入质量交付流程

1. 测试用例设计

能力说明

测试用例设计依赖现有测试用例生成平台。平台先根据需求完成模块划分和测试点分析，再根据测试点生成测试用例，最后由 QA 结合业务经验补充和校正测试场景。

平台能力

• 测试用例生成平台：接收需求背景、功能点、约束条件和期望覆盖范围，生成测试点和测试用例。

适用场景

• 需求评审后，生成测试点和完整测试用例；
• 需要对需求进行模块化拆分和场景补充时；
• 需要快速形成测试用例初稿，再由 QA 进行校正时。

使用说明

需求背景、功能点、约束条件和覆盖范围
→ 按模块生成测试点
→ 根据测试点生成测试用例
→ QA 结合业务经验补充和校正测试场景

此前测试用例文章采用的阶段统计口径里，简单需求的 AI 节点采纳率约为 80%---90%，复杂或带有历史包袱的需求约为 50%。这组数字反映的是当时不同复杂度需求的使用效果，不代表当前所有项目的整体覆盖率。

延伸阅读：《我们自研了一个AI辅助生成测试用例平台》

2. 冒烟质量测试

能力说明

qa-smoke-skills 结合测试平台生成的用例，围绕冒烟测试和代码评审沉淀，用于开发自测阶段和提测后快速校验核心链路、关键功能和代码变更风险。

包含 Skill

• qa-smoke-skills：根据测试用例、需求文档、代码路径和变更范围，整理检查重点，执行冒烟验证或输出结构化评审报告。

适用场景

• 开发自测阶段和提测后，快速验证主流程是否可用；
• 发布前检查核心功能、关键接口和高风险路径；
• 结合需求文档或变更 diff 做结构化代码评审。

使用说明

根据当前任务选择冒烟或评审方向，提供测试用例、需求文档、代码路径、变更范围或需要验证的核心链路，由 Skill 生成检查重点，执行冒烟或输出评审报告。

输入：测试用例、需求文档、代码路径、变更范围或核心链路
→ 过程：生成检查重点，执行冒烟或结构化评审
→ 输出：冒烟结果或评审报告

注意事项

• 调用前要明确需求文档、代码路径和变更范围，避免检查范围失焦；
• 冒烟结果或评审报告是复核证据，不代替 QA 对风险和提测结果的最终判断；
• 开发自测和提测后都可以触发，不能把它误解成只属于某一个固定节点。

3. 接口自动化

能力说明

qa-interface-skills 把自然语言请求映射到规则化的接口自动化场景，重点服务高频、标准化，而且已经具备现有接口能力的测试请求。

包含 Skill

• qa-interface-skills：发现支持场景、解析请求参数、生成执行计划，并在确认后执行接口验证。

适用场景

• 登录、房间状态、互动状态和榜单等标准化接口验证；
• 需要用自然语言描述测试目标，再转换成规则化请求时；
• 需要在正式请求前检查支持场景和参数完整性时。

使用说明

推荐按照下面的顺序使用：

scenes
→ help-scene
→ parse
→ plan
→ run

先确认是否存在可用场景和场景说明，再解析参数、生成计划，最后执行真实接口请求。

注意事项

• 真实请求执行前必须检查场景、参数和执行计划；
• 不支持的场景不能跳过解析和计划阶段直接执行；
• 具体接口、账号和敏感参数不写入对外文章或公开截图。

4. 测试数据、环境与结果验证

能力说明

测试工具类 Skills 主要用于日常数据排查、缓存定位和测试环境消息观察，帮助 QA 快速验证状态、定位问题和辅助故障排查。

包含 Skill

• qa-db-skills：中文自然语言数据库交互工具，支持查询、元数据查看和受控写操作；
• qa-redis-tools-skills：Redis 查询、扫描、修改、删除和多实例 key 定位工具；
• qa-message-printer-skill：测试环境消息监听工具，支持按直播间、用户和消息类型过滤。

适用场景

• 查询测试数据、核对数据库状态；
• 查询 Redis key，排查缓存状态或校验缓存变更；
• 监听测试环境消息，观察指定消息类型或协议字段。

使用说明

• 数据库操作建议按 sources → parse → plan → run 流程执行；
• Redis 查询可以直接使用自然语言，修改和删除建议显式指定实例；
• 测试环境消息监听需要说明目标对象、消息类型和输出方式。

注意事项

• DB / Redis 写操作、删除操作必须谨慎，建议先查询或预览，再确认执行；
• Redis 自动多实例定位主要用于只读查询，不建议在未确认实例时执行写删；
• qa-message-printer-skill 仅连接测试环境，不用于生产环境消息监听。

5. 真机 UI 自动化

能力说明

UI 自动化相关 Skills 用于准备 Midscene 自动化环境，并在 Android / iOS 真机上运行 checklist YAML，支持多设备队列、状态页、暂停和重跑。

包含 Skill

• qa-midscene-env-config：检查和配置 Windows + Android + Midscene.js 自动化环境；
• qa-run-android-checklist-yamls：在 Android 真机上并发运行 checklist YAML；
• qa-run-ios-checklist-yamls：在 Mac + iPhone 环境运行 iOS checklist YAML。

适用场景

• 新机器配置 Node、ADB、Midscene CLI 和模型环境变量；
• Android 多台设备并发运行 checklist；
• iOS 双机运行 Midscene YAML，并自动生成 .ios.yaml 执行文件。

使用说明

• 环境未准备好时，先使用 qa-midscene-env-config 检查或修复依赖；
• Android 执行时，先列出设备和 YAML，再确认 lane 与设备映射；
• iOS 执行前确认 iPhone 已连接并信任 Mac，同时检查 Xcode、WDA 和 Midscene 依赖。

进入执行后，可以通过状态页查看多设备队列，并根据实际情况暂停或重跑。

下图是一份真机 UI 自动化运行报告：左侧记录执行步骤和耗时，顶部保留运行时间线，中间可以回看执行画面，右侧展示本次操作的参数、定位结果和状态。现有截图保留的是一次任务如何被执行、记录和复核的证据结构。

6. 版本发布验证

能力说明

版本发布流程相关 Skills 覆盖 APK 下载归档、Android 发版真机验证和发布邮件准备，减少手工复制链接、安装验证和整理邮件模板的重复工作。

包含 Skill

• qa-apk-download-skill：从发版邮件或本地文本提取 APK 链接，下载并归档 Android 全量包；
• qa-apk-release-skill：在下载归档基础上连接 Android 真机，完成安装和发版关键验证；
• qa-release-mail-skills：根据版本号、平台和阶段生成发布相关邮件草稿。

适用场景

• 只需要下载并归档 Android APK 包；
• 需要安装目标 APK，并验证版本号和发版关键检查项；
• 需要生成运营体验邮件、测试报告邮件、灰度 / 全量发布邮件或 checklist 确认邮件。

使用说明

• 仅下载归档时使用 qa-apk-download-skill，建议先 DryRun 确认解析结果，再正式下载；
• 需要真机安装验证时使用 qa-apk-release-skill，提前连接 Android 设备并确认 ADB 可用；
• 需要准备发布邮件时使用 qa-release-mail-skills，输入版本号、平台、小版本号和发布阶段。

注意事项

• qa-apk-download-skill 只负责 APK 下载和归档，不负责真机安装或 UI 验证；
• qa-apk-release-skill 会卸载旧版 App，可能清除手机本地数据；
• qa-release-mail-skills 只生成或更新邮件草稿，不自动发送，发送前需要人工检查。

四、六类能力背后，哪些判断不能交给自动化

把六类能力放回完整流程，至少有五类判断必须由 QA 负责：

• 需求和业务规则是否理解正确；
• 测试范围、优先级和风险是否合理；
• 数据写入、删除和 Redis 实例选择是否安全；
• 真机安装、失败重跑和异常结果怎样处理；
• 当前版本是否达到可以发布的标准。

这些判断决定的是测试范围、执行风险和版本能否发布。QA Skills 要减少的是重复查找、重复输入和重复操作，把测试人员的时间留给真正需要经验和责任的判断。

五、接下来，我们会沿真实流程逐章拆解

这一篇先把 QA Skills 的真实测试流程、整体分层、能力位置和人工边界交代清楚。

接下来，我们会沿着这张全景图，逐步拆解每一个测试环节：它解决什么问题、包含哪些 Skills、怎样调用、实际输出什么，以及哪些步骤仍然需要 QA 判断。

系列顺序是：

1. 系列全景：本文；
2. 测试用例设计 ：已发布《我们自研了一个AI辅助生成测试用例平台》，本系列直接引用；
3. 冒烟质量测试：拆解开发自测、提测后快速校验、代码评审和结果报告；
4. 接口自动化：拆解场景发现、参数解析、执行计划和真实请求；
5. 测试数据、环境与结果验证：拆解数据库、Redis 和测试环境消息如何协同；
6. 真机 UI 自动化：拆解环境准备、设备映射、执行、暂停与重跑；
7. 版本发布验证：拆解安装包归档、真机检查和发布邮件准备。

这一篇不把每一类能力的实现细节一次讲完。后续专题会继续补充真实文档、调用过程、结果报告和实际页面截图，把每一步单独讲清楚。

如果你也在做 AI 测试、Agent 或研发流程自动化，想继续交流落地问题，可以关注公众号「花椒技术」，回复「AI」加入交流群。

群内会同步每日精选 AI 行业日报、QA Skills 系列后续更新，以及文章评论区里大家最关心的实践问题。