AI 辅助测试 Skill:从可追溯证据走向可靠提效

AI 能快速生成测试想法,却也会把不存在的接口、遗漏的边界和看似合理的断言带进仓库。采用它的前提是让人能验证每一条建议。

AI 辅助测试 Skill 将模型输出视为可审查草稿,并以产品上下文、证据和人的责任约束它。

本文通过一个贴近协作现场的案例,说明如何把不同信号转化为可沟通、可追踪的行动。

Awesome QA Skills 按语言和测试阶段组织 Skill。项目结构和通用安装方式见系列总览,本文只讲 AI 辅助测试。

先看源 Skill

主 Prompt 把工作拆成“质量要求、执行流程、核心约束、按需加载、交付前自检”几个部分。这些标题只是导航,真正使用时还要回到项目材料。

源目录现有 1 份示例、1 份参考、17 个脚本入口。可以先看 AI 辅助测试 示例与使用说明、AI 辅助测试 补充参考资料、模板批量转换脚本。

用一个具体任务跑通思路

本例让 AI 根据需求与历史缺陷提出回归范围,并逐条保留引用和人工复核状态。

可以先把下面这组材料交给 Skill。

事实源:当前需求版本、相关页面或接口、已知缺陷
范围:只覆盖本次变更影响的链路
未知项:环境、账号、数据准备方式
期望输出:风险排序、覆盖清单、待确认问题

下面的片段只展示格式,不代表执行结果。

优先级测试点依据状态
P0需求明确要求覆盖的关键路径验收标准或业务规则待设计
P1AI 建议新增的边界场景影响分析或历史缺陷待人工复核
P1找不到事实源的接口或断言未提供依据删除或补材料

状态列不能提前写成“通过”。静态设计到这里结束,后面还需要真实执行。

从覆盖清单走到决策

先按风险拆任务,再决定写多少用例,并保留每条判断的依据和人工复核状态。

风险问题测试设计需要的证据
建议是否能回到真实需求逐条回链需求、接口或缺陷source 链接、版本和人工备注
生成用例能否实际执行检查数据、命令、环境和断言执行日志、退出码和报告路径
人工改动是否有理由对照原建议与最终用例review 记录、取舍原因和 Owner

这张表会继续长,但别一开始就追求面面俱到。先确认“质量要求”和“执行流程”是否命中本次改动,再补边界和兼容性。

评审输出时怎么判断够不够

对每条测试点都问三个问题:它依据哪条需求或风险?执行需要什么环境和数据?失败后会留下什么?回答不出来的条目仍是想法,还不能交给执行者。

一段可以直接改的调用词

把方括号中的占位内容替换成项目实际信息。材料越具体,Skill 越少猜。

请使用 ai-assisted-testing Skill。

任务:让 AI 根据需求与历史缺陷提出回归范围,并逐条保留引用和人工复核状态
版本与环境:[需求版本 / 构建号 / 环境]
输入材料:[文件路径或链接]
范围:[本次包含与排除的业务链路]
限制:[账号、数据、时间、合规要求]

按业务风险排序覆盖,区分设计状态与执行状态。每条测试点注明依据、数据和预期证据。
最后列出待确认问题,不要补写材料里没有的事实。

第一次调用先看结构和缺口,补齐材料后再生成正式产物,可以少一些来回修改。

进阶使用,从一次调用走到持续流程

把这次输出保存成基线。需求或代码变化后先做影响分析,只重跑受影响链路和固定门禁集,完整回归留给合适的阶段。

三段式 Skill 链

requirements-analysis → ai-assisted-testing → test-reporting

交接传递内容接收方检查
上游到 ai-assisted-testing来源版本、范围、风险和未决问题输入是否过期,冲突是否标记
ai-assisted-testing 到下游主产物、证据索引、未完成项产物能否继续执行,Owner 是否明确
下游回写 ai-assisted-testing运行结果、缺陷和新风险是否更新 AI 辅助测试基线与回归范围

不要把三次输出复制进一个大 Prompt。AI 辅助测试只接收结构化摘要和可访问的原始材料,能减少上下文浪费,也方便追错。

放进团队流程的门禁

门禁建议检查失败动作
ai-assisted-testing 输入门禁版本、环境、Owner、来源可访问停止流程并列出缺口
ai-assisted-testing 产物门禁关键结论带依据和状态退回补证据
ai-assisted-testing 执行门禁命令、退出码、报告可复现标记基础设施或测试问题
ai-assisted-testing 决策门禁残余风险有接受人和日期不进入下一阶段

团队可以每个 Sprint 统计 AI 辅助测试的采用率、人工修改率、无依据结论数和失败定位时间。目标由团队自己定,先连续记录几轮再谈阈值。

使用时我会特别检查什么

  • 范围是否落到具体业务链路,避免把范围写成百科全书。
  • 质量要求是否引用了真实需求、页面、接口或缺陷。
  • 正常、异常、边界和恢复路径有没有按风险排序。
  • 输出状态是否诚实区分待设计、待执行、通过和失败。

相关 Skill

AI 辅助测试要把效率判断接回测试设计和结果复核:

交付前复核:把判断落到证据

拿到 Skill 输出后,先核对四件事:输入版本是否明确,范围是否完整,每条结论能否回到证据,下一步由谁执行。少一项,报告就容易变成漂亮的猜测。

项目需要留下缺失时
输入边界版本、环境、时间窗口和本次范围标记假设,不写成事实
证据索引日志、报告、Trace、截图或命令输出标记 evidence_pending
结论状态verified、assumption、blocked 或 pending停止扩大结论
后续动作最小验证命令、负责人和截止时间交付为待办,不进入门禁
source_version: [版本或提交]
scope: [本次包含和排除的对象]
evidence: [日志、报告、Trace 或命令输出]
status: pending
owner: [负责人]
next_action: [最小验证动作]

分析类 Skill 要保留查询条件和时间窗口;执行类 Skill 要保留命令、退出码和失败产物。人工修改也要记录,否则下一次复核时无法解释结论为何变化。

安装与调用

安装单个 Skill 就够了。项目总览里的安装说明不再在每篇重复。

npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh/testing-types/ai-assisted-testing -g

调用时直接写“请使用 ai-assisted-testing Skill”,然后附上真实材料。

常见问题

材料不完整时还能使用 AI 辅助测试 吗?

可以,但输出应降级为已知事实、假设和待确认问题。缺失环境或数据时,不能写执行结论。

怎么判断 执行流程 做得够不够?

拿需求和风险逐项回查。能说明覆盖依据、遗漏原因和下一步动作,才算可交接。

什么时候需要人工复核?

涉及范围取舍、风险接受、发布决定或材料冲突时必须由负责人确认。

输出怎么留档?

保存输入版本、Skill 输出、人工修改和最终证据。只留最后一份文档,很难解释结论怎么来的。

先拿一份真实材料跑 AI 辅助测试,保留输入、输出和复核意见。文中的片段只能帮你搭起结构,真正的项目证据仍要在项目中产生。

参考

分享