点击蓝字
关注我们
Skill写出来只是起点。一个需求到用例的四Skill流水线搭建完成，能跑通、能出结果，大概也就刚到60分的水平。
真正决定这套东西能不能长期用下去、能不能在不同项目上复用的，是后续一轮一轮的迭代优化。
不少团队的做法是：Skill搭完就上线，跑几轮发现效果不理想，结论是"AI生成的用例不靠谱"，然后弃用。
问题往往不在Skill本身的能力上限，而在于缺少一套科学的迭代方法——不知道拿什么指标衡量好坏，不知道改了哪里起了作用，不知道什么时候算调好了。
本文聚焦在"Skill写出来之后怎么科学地迭代优化，从60分调到90分"，覆盖迭代方法论、质量度量体系、版本基线管理、控制变量法实操，以及一个完整的六阶段演进模型。
一、需求到用例Skill的编排回顾
在讨论迭代之前，有必要快速回顾一下四Skill流水线的编排架构。这里不重复每Skill的具体写法，而是从一个特定角度切入——编排设计如何影响后续迭代的便利性。
四Skill流水线的职责划分
需求文档 → [Skill 1: 需求分析] → 结构化需求摘要→ [Skill 2: 测试点提取] → 分层测试点列表→ [Skill 3: 用例生成] → 格式化测试用例→ [Skill 4: 用例评审] → 评审意见 + 最终用例集
四个Skill各自独立，通过Agent调度串联。每个Skill的输入来自上游Skill的输出，输出作为下游Skill的输入。
职责边界决定了迭代的独立性
编排设计对迭代效率的影响，在实际操作中体现得非常直接：
一个典型反例：需求分析Skill的输出里直接带了"建议的测试重点"，这相当于越界到测试点提取Skill的领域。后续想单独优化测试点提取策略时，发现需求分析Skill也在做一部分测试点的工作，改还是不改？改了怕影响需求分析的质量，不改又没法独立优化测试点提取。
为迭代而设计的第一原则：每个Skill只做一件事，输出结构精确到字段级别，下游Skill不依赖上游的"意图"只依赖上游的"数据"。
接口契约的稳定性
Skill之间的输入输出接口，类似于微服务之间的API契约。一旦确定并通过验证，就不应该频繁变动。如果每次迭代都在改接口格式，说明一开始的职责划分有问题。
稳定的接口契约带来一个直接好处：可以单独对某个Skill做A/B测试。比如只升级Skill 3的用例生成策略，Skill 1和Skill 2的输出保持不变，那么Skill 3的改进效果可以被精确度量，不会被上游的变动干扰。
二、质量度量维度
用什么标准衡量Skill好不好
迭代的前提是知道当前在什么位置、每次调整往哪个方向走。这就需要一套可量化的度量体系。
2.1 有效率（Efficiency Rate）
定义：AI生成的用例中，经人工审核后不需要修改或只需微调（如文字措辞调整、步骤编号修正）即可直接纳入用例集的比例。
计算方式：
有效率 = 有效用例数 / 总生成用例数 × 100%其中"有效用例"的判定标准需要事先明确：
A级和B级计入有效用例数。C级和D级不计入。
度量方式：以存量手工用例为参照基准。选取已经通过评审的手工用例集，让Skill对同样的需求文档生成用例，然后对比两者的差异。对比维度包括：
●手工用例中有哪些测试点，AI生成的用例是否覆盖
●AI生成的用例中有哪些是手工用例没有的（增量价值）
●AI生成的用例中有哪些是手工用例没覆盖到的边界/异常场景
2.2 覆盖度（Coverage Rate）
定义：AI生成的用例对需求点的覆盖程度。
覆盖度不是一个单一数字，需要从多个子维度分别度量：
计算方式：将需求文档拆解为最小的可验证单元（需求点），逐条检查AI输出是否覆盖。
覆盖度 = 已覆盖的需求点数 / 需求点总数 × 100%这个计算需要人工参与：先把需求拆成需求点列表，再逐条标记AI用例是否覆盖。工作量不小，但对于建立基线和阶段性评估很有价值。
2.3 对比方法论：AI+Skill vs 纯人工
建立评估对比的核心思路是：以同一份需求文档为输入，分别由资深测试工程师手工编写用例和Skill生成用例，在有效率和覆盖度两个维度做量化对比。
对比表格模板：
这张表在每次迭代时都要填写，用来追踪各项指标的变化趋势。
2.4 度量中的常见陷阱
●陷阱一：用例数量多≠质量好。 一个需求点生成了10条用例，看起来覆盖度很高，但其中8条是等价类重复。有效用例数应该以"独立验证点"为计数单位，而非简单计数。
●陷阱二：覆盖度数字好看但用例质量差。 某条用例的步骤写的是"验证登录功能正常"，这算覆盖了"登录"功能点吗？严格来说不算——步骤不可执行、期望结果不明确。覆盖度统计需要配合用例质量检查，不能只看是否"提到"了某个功能点。
●陷阱三：评估集太小导致统计失真。 只拿一两个简单需求做评估，有效率达到90%就以为Skill很好了，换个复杂需求可能直接掉到50%。评估集至少需要包含5-10个不同复杂度的需求文档。
三、AI辅助生成与手动微调的边界
Skill的调优过程中，一个绕不开的问题是：哪些环节可以借助AI来辅助调优，哪些环节必须手动操作。
3.1 AI辅助的适用阶段
在Skill迭代的早期阶段，AI辅助可以显著加速调优过程：
●提示词初始版本的生成：给定Skill的目标和约束，让AI生成一版system prompt的初稿，在此基础上修改远比从零开始高效
●输出模板的格式化调整：输出格式不规范、字段缺失、JSON结构错误这类问题，可以通过调整提示词中的格式约束让AI自动修正
●批量规则提取：从历史用例库中提炼通用的测试设计规则，AI可以帮忙做初步的分类和归纳
●few-shot示例的扩写：给定一个示例的风格和结构，让AI批量生成类似但场景不同的示例
3.2 AI辅助的边际效益递减
Skill调到一定程度后，AI辅助调优的效果会明显下降。一个直观的感受是：让AI帮忙改提示词，改来改去都是表面措辞的变化，对用例质量的提升越来越小。
这个"临界点"的判断标准，可以按问题类型来划分：
3.3 什么时候批量调优 vs 逐条分析
适合AI批量调优的场景：
●同一类问题在多条用例中重复出现（如"所有接口类用例都缺少响应码校验"）
●格式性问题（如"所有用例的步骤编号不连续"）
●某类需求场景的整体覆盖不足（如"所有异常场景用例都只覆盖了一种异常"）
这类问题有明确的规律，可以通过添加规则或调整提示词来批量解决。
必须逐条人工分析的场景：
●用例的业务逻辑错误（每条错误的原因可能不同）
●评估集中表现差异大的用例（A需求效果好B需求效果差，原因需要个案分析）
●涉及领域知识的判断（如金融类需求的合规性校验规则，不同业务线的理解可能不同）
逐条分析虽然耗时，但产出的洞察往往能直接转化为Skill的规则沉淀。每一条"为什么AI在这里犯错了"的分析，都可能对应一条需要补充到references中的规则。
未完待续
后续我们将继续深入了解Skill版本基线建立、控制变量优化迭代、六阶段迭代演进模型与提效指标衡量。
声明：本文为51Testing软件测试网 旦莫 用户投稿内容，该用户投稿时已经承诺独立承担涉及知识产权的相关法律责任，并且已经向51Testing承诺此文并无抄袭内容。发布本文的用途仅仅为学习交流，不做任何商用，未经授权请勿转载，否则作者和51Testing有权追究责任。如果您发现本公众号中有涉嫌抄袭的内容，欢迎发送邮件至:editor@51testing.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
