关注 霍格沃兹软件测试开发 公众号回复「资料」, 领取人工智能测试开发技术合集很多测试从业者不是不努力而是每天都卡在同几个问题上用例写了很多线上还是漏问题缺陷提上去了研发一句“无法复现”就打回来上线前时间不够面试官问“你怎么排优先级”只能回答“先测核心流程”项目做完了复盘只会写“沟通不足、时间紧张、后续优化”。这些问题背后其实不是单点能力不够而是缺一套可以反复调用的测试工作流。以前我们靠经验、模板、Checklist 来兜底。现在有了 Claude Code 的 Skills就可以把这些测试经验沉淀成一个个可复用的“测试助手”。你可以简单理解为Skill 不是普通提示词而是把一套固定工作方法、检查清单、输出模板和操作步骤封装成 Claude 可以随时调用的能力。比如你要写用例它按“主流程、异常、边界、兼容、权限、数据状态”帮你拆。你要提 Bug它按“标题、环境、步骤、预期、实际、日志、严重程度”帮你补齐。你要做复盘它按“缺陷分布、漏测原因、流程问题、改进动作”帮你沉淀。这才是测试从业者真正该关注的 AI 用法不是让 AI 随便生成一堆内容而是把测试方法论变成可复用的工作流。一、先搞懂测试从业者为什么要用 Skills很多人现在用 AI 做测试还是停留在“复制一段需求让它帮我生成用例”。这当然能用但问题也很明显生成结果不稳定每次都要重新描述规则不同人问出来的结果差异很大新人容易把 AI 的输出当标准答案团队无法沉淀统一规范。Skills 解决的就是这个问题。它更像是你给 AI 配了一套“测试工作手册”。比如团队里规定缺陷标题必须包含模块、动作、异常现象用例必须覆盖正常、异常、边界、权限、兼容上线前必须按风险、业务价值、历史缺陷、测试成本排序复盘必须包含数据、原因、动作和责任人。这些规则如果每次都靠人工提醒很容易漏。 但如果写进 SkillClaude 每次执行对应任务时就会按这套规则来输出。这对测试团队特别有价值。因为测试工作本身就高度依赖流程、规范、经验和检查清单而这些东西非常适合沉淀成 Skills。根据 Anthropic 官方说明Skills 本质上是由说明文档、元数据以及可选脚本、模板等资源组成的模块化能力官方也提供了公开 Skills 示例仓库方便开发者学习结构和写法。二、测试工作流可以拆成 8 个高频 Skills测试从业者真正高频使用的 Skills不应该是花里胡哨的工具而应该围绕真实工作链路来设计。一条完整的测试链路大致可以拆成所以这篇文章直接按测试从业者日常工作场景整理 8 个最值得沉淀的 Skills。Skill解决的问题适合人群需求澄清 Skill需求看不懂、测点抓不准初中级测试、测试开发用例分层 Skill用例覆盖不全、重复冗余所有测试工程师场景模拟 Skill不会从用户路径设计场景业务测试、功能测试优先级排序 Skill时间不够不知道先测什么面试、项目上线前缺陷报告 SkillBug 被研发打回初级测试、团队规范建设根因分析 Skill只会复现不会分析原因中高级测试工程师回归验证 Skill修复后不知道怎么回归测试负责人、测试开发测试复盘 Skill项目做完无法沉淀经验测试组长、测试经理下面逐个展开。一、需求澄清 Skill别一上来就写用例很多测试同学拿到需求后第一反应就是写测试用例。但真正有经验的测试工程师会先问三个问题这个需求到底解决什么业务问题哪些规则是明确的哪些规则是模糊的哪些地方一旦理解错后面测试一定会漏所以第一个 Skill不是用例生成而是需求澄清。适用场景产品文档写得很粗需求评审时没人说清楚异常规则研发已经开始做了测试才发现规则缺失面试被问“你如何参与需求评审”。推荐触发词使用需求澄清 Skill帮我分析下面这个需求找出测试前必须确认的问题。输入示例需求用户下单时可以使用优惠券。优惠券分为满减券、折扣券和新人券。每个订单最多使用一张优惠券支付成功后优惠券状态变为已使用。输出应该包含什么一个合格的需求澄清 Skill不应该只总结需求而应该输出这些内容模块需要输出的内容业务目标这个功能解决什么问题核心规则已明确的业务规则模糊点需求里没说清楚的地方冲突点可能和已有功能冲突的地方测试关注点后续用例设计重点评审问题清单需要产品确认的问题示例输出针对优惠券需求它应该能帮你问出这些问题满减券和折扣券是否互斥新人券是否只能使用一次优惠券过期后已锁定但未支付的订单如何处理支付失败后优惠券是否释放订单取消后优惠券是否退回部分退款时优惠券是否退回多端同时提交订单时优惠券是否会被重复使用这些问题如果不提前问后面很容易变成缺陷。踩坑提醒很多测试同学用 AI 分析需求只让它“总结需求”。这没什么价值。测试从业者真正需要的是把模糊需求提前暴露出来。所以这个 Skill 的核心不是“总结”而是“质疑”。二、用例分层 Skill把“测全”拆成可执行结构很多测试工程师说自己会写用例但一看用例表就知道经验深浅。常见问题有三个只覆盖正常流程异常场景靠临场发挥边界值想起来一个写一个。这种用例不是不能用而是不稳定。真正可复用的用例设计应该先分层。推荐分层方式适用场景新功能测试用例设计面试现场设计测试用例新人写用例前的辅助检查测试负责人 Review 用例覆盖度。推荐触发词使用用例分层 Skill基于下面需求按核心流程、异常流程、边界场景、组合场景输出测试用例。示例登录功能如果输入“登录功能”不要只输出账号正确、密码正确登录成功 账号错误登录失败 密码错误登录失败。这种太浅了。更好的输出应该是分层测试点核心流程正确账号密码登录成功参数异常账号为空、密码为空、账号格式错误认证异常密码错误、账号不存在、账号被冻结安全限制连续输错密码是否锁定验证码验证码错误、验证码过期、验证码刷新多端场景同账号多设备登录策略会话状态登录后 Token 过期、退出后访问页面兼容场景Web、App、小程序登录一致性面试可以怎么说面试官问“你怎么保证用例覆盖全面”可以这样回答我一般不会直接开始写用例而是先做用例分层。第一层覆盖核心业务流程保证主链路可用第二层覆盖异常输入、异常状态和异常环境第三层覆盖边界值、权限、兼容和数据状态最后再结合历史缺陷和线上高频问题做补充。这样能避免只测主流程也能避免用例堆得很多但没有重点。这比一句“我会覆盖正常、异常、边界”更有说服力。三、场景模拟 Skill从“功能点测试”升级到“用户路径测试”很多漏测不是因为功能点没测而是因为没有按真实用户路径测。比如购物车功能单测“添加商品”是没问题的。但真实用户路径可能是搜索商品 → 加入购物车 → 修改数量 → 使用优惠券 → 提交订单 → 支付失败 → 返回购物车 → 再次支付。问题往往就出在这种连续状态变化里。场景模拟 Skill 要解决什么它解决的是测试同学不会把功能点串成业务场景。尤其适合电商、金融、教育、SaaS、ERP、后台管理系统这类业务系统。推荐触发词使用测试场景模拟 Skill围绕【购物车结算】设计真实用户路径、异常路径和边界路径。场景设计结构一个好的场景模拟 Skill至少应该输出四类内容类型示例主路径选品 → 加购物车 → 下单 → 支付成功分支路径修改数量、删除商品、切换地址异常路径库存不足、优惠券失效、支付失败状态路径未登录、已登录、会员、黑名单用户示例购物车结算场景类型测试场景正常场景多个商品加入购物车后正常结算库存场景提交订单前库存充足支付前库存不足价格场景商品加入购物车后发生改价优惠场景使用优惠券后订单金额是否正确地址场景默认地址失效或删除后能否提交支付场景支付失败后订单状态是否正确并发场景多端同时修改购物车数量数据场景购物车商品数量达到上限踩坑提醒很多测试同学写场景用例时只是把多个功能点罗列在一起。但真正的场景测试重点是状态会不会变数据会不会错链路中断后能不能恢复跨模块之间有没有一致性问题。所以这个 Skill 的关键不是生成更多用例而是帮你补齐“业务链路”。四、测试优先级 Skill时间不够时先测什么这是面试高频题也是项目里经常会遇到的问题。上线前只剩半天需求还没测完怎么办很多人会说先测核心功能。这句话没错但太空。面试官真正想听的是你怎么判断核心你依据什么排序你怎么取舍你怎么跟产品和研发同步风险推荐排序模型测试优先级可以按四个维度来排维度说明业务价值是否影响收入、转化、核心链路用户影响影响多少用户、是否高频使用缺陷风险是否新模块、复杂模块、历史问题多测试成本剩余时间内能否快速验证可以简单理解为优先测“影响大、风险高、成本可控”的场景。推荐触发词使用测试优先级 Skill基于下面功能清单和剩余测试时间帮我输出测试优先级排序和取舍理由。输入示例项目电商 App 大版本上线 剩余测试时间1 天 功能清单 1. 登录注册 2. 商品搜索 3. 购物车 4. 下单支付 5. 优惠券 6. 订单列表 7. 个人资料修改 8. 消息通知输出示例优先级功能理由P0登录、下单、支付核心链路失败会直接阻断交易P1购物车、优惠券、订单列表影响转化和订单数据一致性P2商品搜索、消息通知影响体验但不一定阻断交易P3个人资料修改低频功能可做基础验证面试可以怎么说如果上线前时间不足我会先按业务影响和质量风险做排序。第一优先级是核心交易链路比如登录、下单、支付、订单状态第二优先级是高风险模块比如优惠券、库存、金额计算、权限控制第三优先级才是低频配置和展示类功能。同时我会把未覆盖风险同步给产品和研发明确哪些是已验证范围哪些是带风险上线。这个回答的重点是有框架有排序有风险同步有取舍逻辑。五、缺陷报告 Skill别再让研发说“无法复现”很多 Bug 不是研发不想修而是测试报告写得不够清楚。常见问题包括标题太泛步骤缺失环境没写预期结果和实际结果混在一起没有截图、日志、接口返回严重程度和优先级乱标。最后研发只能回复一句无法复现。缺陷报告 Skill 要标准化什么一份高质量缺陷报告至少要包含字段要求标题模块 操作 异常现象环境测试环境、版本、设备、浏览器、账号、数据前置条件复现前需要满足什么复现步骤1、2、3 分步写清楚预期结果按需求应该发生什么实际结果实际发生了什么证据截图、录屏、日志、接口返回严重程度是否阻断、是否影响核心链路优先级是否需要当前版本修复回归建议修复后重点回归哪些点推荐触发词使用缺陷报告 Skill把下面这个 Bug 整理成研发可直接复现的缺陷报告。输入示例用户连续输错 5 次密码后系统没有锁定账号还能继续尝试登录。输出示例缺陷标题登录模块连续输错 5 次密码后未触发账号锁定测试环境测试环境 / Android 14 / App 版本 3.2.1 / 账号test001前置条件账号 test001 状态正常未被冻结。复现步骤打开 App 登录页输入账号 test001连续 5 次输入错误密码观察系统提示和账号状态第 6 次继续输入错误密码预期结果连续输错 5 次密码后账号应被临时锁定并提示用户稍后再试或进行安全验证。实际结果连续输错 5 次后账号未锁定仍可继续尝试登录。严重程度严重。涉及账号安全策略失效可能导致暴力破解风险。优先级P1建议当前版本修复。回归建议锁定阈值是否生效锁定时间是否正确正确密码是否仍被限制多端登录是否共享锁定状态接口层是否也有防刷限制。踩坑提醒缺陷报告最忌讳三件事不要写“有问题”不要把多个问题塞进一个 Bug不要只写现象不写复现路径。好的缺陷报告不是为了证明测试发现了问题而是为了让研发快速定位和修复问题。六、根因分析 Skill从“发现 Bug”到“避免同类 Bug”初级测试关注这个 Bug 怎么复现。中级测试关注这个 Bug 怎么修。高级测试关注为什么会出现以及怎么避免同类问题再次出现。这就是根因分析 Skill 的价值。推荐分析框架可以用“现象 → 触发条件 → 影响范围 → 根因假设 → 验证证据 → 改进动作”这条链路。推荐触发词使用缺陷根因分析 Skill基于下面 Bug帮我分析可能根因、影响范围和预防措施。示例订单支付后库存未扣减一个普通测试同学可能只会写支付成功后库存没有减少。但根因分析 Skill 应该继续追问是支付回调没收到是库存服务扣减失败是消息队列消费失败是事务没有兜底是测试用例没覆盖支付成功但库存扣减失败的异常分支是需求里没明确库存扣减时机输出示例分析项内容缺陷现象用户支付成功后商品库存未扣减直接影响可能导致超卖关联模块支付、订单、库存、消息队列可能根因支付成功回调后库存扣减逻辑未执行或执行失败未重试测试遗漏只验证支付成功和订单状态未验证库存状态同步研发改进增加库存扣减失败重试和告警测试改进补充支付成功后库存一致性校验流程改进需求评审增加跨模块状态一致性检查面试可以怎么说遇到线上缺陷后我不会只停留在复现和回归。我会先确认触发条件和影响范围再从需求、研发、测试、环境四个角度分析根因。如果是测试遗漏我会补充对应场景如果是研发缺少兜底我会推动增加日志、告警和异常处理如果是需求不清我会把规则补进后续评审 Checklist。这类回答能明显体现你不是单纯执行测试而是有质量闭环意识。七、回归验证 Skill修复了不代表问题真的结束了很多团队有个误区研发说修复了测试重新点一下原步骤通过了就算回归完成。这其实很危险。因为一个 Bug 的修复可能影响的不只是原场景。比如优惠券金额计算问题修了可能影响满减券折扣券新人券退款金额订单实付金额财务对账营销活动报表。所以回归测试不能只测“原 Bug 是否消失”还要测“修复有没有引入新问题”。回归验证 Skill 要做什么它要根据 Bug 类型自动帮你生成原路径回归关联功能回归数据一致性回归异常路径回归自动化补充建议上线后观察指标。推荐触发词使用回归验证 Skill基于下面缺陷修复说明帮我设计回归范围和回归用例。输入示例缺陷优惠券抵扣金额计算错误。 修复说明后端调整了优惠券计算逻辑。输出示例回归范围验证点原缺陷路径原 Bug 场景是否已修复同类优惠券满减券、折扣券、新人券是否正确订单金额商品金额、优惠金额、实付金额是否一致退款场景使用优惠券后退款金额是否正确边界场景优惠金额等于订单金额、订单金额低于门槛数据一致性订单、支付、营销、财务字段是否一致自动化建议将金额计算场景加入接口自动化回归集踩坑提醒回归测试不能只做“点验证”。测试工程师要多问一句这个修复改了哪段逻辑这段逻辑被哪些功能复用有没有可能影响历史数据有没有必要加入自动化回归这才是回归测试的专业性。八、测试复盘 Skill项目结束后别只写流水账很多测试复盘写得像日报本次完成测试用例 100 条发现 Bug 30 个严重 Bug 5 个后续继续优化测试流程。这类复盘看起来完整但没有价值。真正有价值的复盘要回答四个问题问题集中在哪里为什么会集中在那里哪些问题本可以提前发现下一次具体怎么避免推荐触发词使用测试复盘 Skill基于下面项目数据生成一份测试复盘报告要求包含缺陷分析、漏测原因和改进动作。输入示例项目电商优惠券改版 测试周期5 天 执行用例180 条 发现缺陷32 个 严重缺陷6 个 线上遗留2 个 缺陷集中模块优惠券计算、订单金额、退款输出结构模块内容测试概况测试范围、周期、人员、用例数量缺陷数据缺陷数量、严重程度、模块分布质量问题缺陷集中区域和典型问题漏测分析为什么没有提前发现改进措施需求、开发、测试、自动化四层动作后续计划下个版本如何落地示例复盘结论本次缺陷主要集中在优惠券计算、订单金额和退款链路说明金额类规则在需求评审和用例设计阶段没有拆透。测试过程中虽然覆盖了正常下单和优惠抵扣但对退款、优惠券过期、订单取消、部分支付失败等状态流转覆盖不足。后续需要将金额计算类场景沉淀为专项 Checklist并补充接口自动化回归用例避免每次依赖人工经验重新覆盖。这才叫复盘。不是写“这次测试辛苦了”而是把问题沉淀成下一次的能力。三、这 8 个 Skills 怎么安装如果你用的是 Claude Code可以按下面方式创建。Claude Code 官方文档中提到可以通过 Skills 扩展 Claude 的能力Skills 可以用于创建、管理和共享可复用能力。([Claude Code][2])常见放置方式可以按个人级和项目级来区分类型路径适合场景个人级~/.claude/skills/skill-name/SKILL.md所有项目都能用项目级.claude/skills/skill-name/SKILL.md当前项目团队共用比如你要创建一个“缺陷报告 Skill”可以这样做mkdir -p ~/.claude/skills/bug-report-standard然后新建文件touch ~/.claude/skills/bug-report-standard/SKILL.md写入下面内容--- description: 用于将简单缺陷描述整理成标准缺陷报告。适用于 Bug Report、缺陷单、研发无法复现、缺陷补充信息等场景。 --- # 缺陷报告标准化 Skill 当用户提供一个缺陷现象时请按以下结构整理 ## 一、缺陷标题 格式模块 操作 异常现象 ## 二、测试环境 包括系统、版本、设备、浏览器、账号、测试环境、数据条件。 ## 三、前置条件 说明复现前需要满足什么状态。 ## 四、复现步骤 用 1、2、3 分步写清楚不要省略关键操作。 ## 五、预期结果 说明按需求或正常逻辑应该发生什么。 ## 六、实际结果 说明实际出现了什么异常。 ## 七、证据材料 提醒用户补充截图、录屏、日志、接口返回、数据库记录等。 ## 八、严重程度和优先级 区分严重程度和修复优先级并说明理由。 ## 九、回归建议 给出修复后需要回归的相关场景。保存后在 Claude Code 里输入/bug-report-standard或者直接说帮我把下面这个 Bug 整理成标准缺陷报告。Claude 就会自动按这个 Skill 的规则输出。四、8 个测试 Skills 的目录建议如果你想一次性搭好测试从业者的 Skills 工作台可以按下面目录建.claude/ skills/ requirement-clarifier/ SKILL.md test-case-layering/ SKILL.md test-scenario-simulation/ SKILL.md test-prioritization/ SKILL.md bug-report-standard/ SKILL.md defect-root-cause-analysis/ SKILL.md regression-verification/ SKILL.md test-retrospective/ SKILL.md对应中文名称如下目录名中文名称requirement-clarifier需求澄清 Skilltest-case-layering用例分层 Skilltest-scenario-simulation测试场景模拟 Skilltest-prioritization测试优先级 Skillbug-report-standard缺陷报告标准化 Skilldefect-root-cause-analysis缺陷根因分析 Skillregression-verification回归验证 Skilltest-retrospective测试复盘 Skill这样做的好处是新人可以直接按规范输出老人可以减少重复沟通团队可以形成统一测试方法面试时也能把方法论讲清楚后续还能把公司内部规范继续沉淀进去。五、下载地址和获取方式这里要提醒一句网上很多文章会直接列一堆 Skills 仓库但测试从业者不要只看名字就下载使用。因为 Skills 本质上是可执行的工作流文件里面可能包含脚本、命令、工具调用建议优先选择官方仓库、可信作者仓库或者自己按团队规范创建。目前可以参考三类来源1. 官方 Skills 示例库GitHub 搜索anthropics/skills这是 Anthropic 官方公开的 Skills 示例库适合学习 Skills 的目录结构、SKILL.md写法和组织方式。([GitHub][3])2. 产品方法论 Skills 仓库GitHub 搜索deanpeters/Product-Manager-Skills这类仓库偏产品管理方法论不是专门给测试从业者用的但其中需求分析、优先级、复盘类方法可以作为测试 Skills 的参考。注意不要直接把它包装成“测试专属仓库”更适合写成“可参考的方法论来源”。3. 自建测试 Skills最推荐测试团队自己建。原因很简单每家公司缺陷规范不同每个团队用例模板不同每个业务的风险点不同每个项目上线标准不同。与其下载一堆不一定适配的 Skill不如把自己的测试经验沉淀成团队版 Skills。比如电商团队沉淀订单、支付、库存、优惠券 Skills金融团队沉淀风控、授信、还款、账务 SkillsSaaS 团队沉淀权限、审批、组织架构、数据隔离 SkillsApp 团队沉淀安装、升级、兼容、弱网、权限 Skills。这才是真正能提升效率的地方。六、测试从业者用 Skills最容易踩的 5 个坑1. 把 Skill 当提示词提示词是一次性的。 Skill 是可复用的流程。如果只是写一句“帮我生成测试用例”那不叫 Skill。 真正的 Skill 应该包含流程、规则、检查点、输出格式和反例提醒。2. 只追求生成数量不检查质量AI 很容易一口气生成 100 条用例。但质量工程师要关心的不是数量而是核心链路有没有覆盖异常状态有没有覆盖边界值是否合理是否有重复用例是否能真正执行。用例多不等于质量高。3. 不结合业务背景通用 Skill 只能解决通用问题。 真正有价值的是业务 Skill。比如“支付测试 Skill”就应该包含金额计算优惠抵扣支付回调订单状态退款对账重复支付超时关闭幂等处理。这比泛泛地写“生成支付测试用例”有用得多。4. 不做人审AI 输出不能直接当最终结果。尤其是测试用例、缺陷分析、上线风险评估这类内容必须由测试工程师二次确认。测试从业者要把 AI 当助理不要把 AI 当负责人。5. 不沉淀团队规范个人用 Skills只是提效。 团队用 Skills才是能力沉淀。如果团队能把缺陷模板、用例规范、上线检查、复盘模板都沉淀进去新人培养和团队协作都会明显变顺。七、真正该掌握的不是“会不会用 AI”而是“能不能把经验流程化”很多人理解 AI 测试容易走偏。以为 AI 测试就是让 AI 生成用例让 AI 写自动化脚本让 AI 帮忙提 Bug让 AI 替代测试执行。但从实际落地看AI 更适合先做一件事把优秀测试工程师脑子里的经验变成团队可复用的流程。一个高级测试工程师为什么值钱不是因为他会点页面。 而是因为他知道哪里容易出问题知道怎么设计用例知道怎么判断风险知道怎么推动修复知道怎么复盘沉淀。这些经验以前只能靠带人、评审、踩坑慢慢传。 现在可以通过 Skills 变成团队资产。这对测试从业者来说是一个很重要的变化。未来测试岗位不会只看你会不会写用例、会不会点功能、会不会跑自动化。更重要的是你能不能把测试方法论沉淀成工具你能不能把业务风险转成检查清单你能不能把缺陷经验变成回归资产你能不能用 AI 提升整个测试流程的效率。这才是测试从业者真正应该跟进 Skills 的原因。八、写在最后不要一上来就追求“搭一个完整 AI 测试平台”。先从最小的 3 个 Skills 开始缺陷报告 Skill用例分层 Skill测试优先级 Skill。这三个最容易落地也最容易看到效果。因为它们分别解决了测试工作里最常见的三个问题写不全说不清排不准。等这三个跑顺了再继续扩展到需求澄清、根因分析、回归验证和测试复盘。AI 对测试从业者的价值不是替你干掉所有工作而是把那些重复但又不能乱来的流程变成稳定、标准、可复用的能力。这也是为什么测试从业者现在必须关注 Skills。不是因为它是新概念而是因为它刚好击中了测试工作的核心流程、规范、经验、复用。关于我们霍格沃兹测试开发学社隶属于测吧北京科技有限公司是一个面向软件测试爱好者的技术交流社区。学社围绕现代软件测试工程体系展开内容涵盖软件测试入门、自动化测试、性能测试、接口测试、测试开发、全栈测试以及人工智能测试与 AI 在测试工程中的应用实践。我们关注测试工程能力的系统化建设包括 Python 自动化测试、Java 自动化测试、Web 与 App 自动化、持续集成与质量体系建设同时探索 AI 驱动的测试设计、用例生成、自动化执行与质量分析方法沉淀可复用、可落地的测试开发工程经验。在技术社区与工程实践之外学社还参与测试工程人才培养体系建设面向高校提供测试实训平台与实践支持组织开展“火焰杯” 软件测试相关技术赛事并探索以能力为导向的人才培养模式包括高校学员先学习、就业后付款的实践路径。同时学社结合真实行业需求为在职测试工程师与高潜学员提供名企大厂 1v1 私教服务用于个性化能力提升与工程实践指导。本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容侧重测试实践、工具应用与工程经验整理。​