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

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 系列后续更新，以及文章评论区里大家最关心的实践问题。