企业官网建设流程全解析

1. 测试流程为什么需要重构

做过几年测试的人都有一个共同感受：写用例的时间永远不够，定位缺陷的时间永远超出预期。一个中等规模的迭代，测试团队往往要花三到五天写用例，再花两到三天执行和回归，最后还要留出时间做缺陷复现和根因分析。整个链路里，真正"发现有价值问题"的时间占比其实很低，大量精力消耗在重复劳动和信息搬运上。

我所在的团队去年做过一次统计，一个典型的两周迭代里，测试工程师的时间分布大致是这样的：理解需求与拆解测试点占20%，编写与维护用例占30%，执行与记录结果占25%，缺陷复现与定位占15%，沟通与汇报占10%。也就是说，超过一半的时间花在了可以被结构化、可以被辅助加速的环节上。这不是某个人的效率问题，而是流程本身的信息密度太低。

Agent Skills 这个思路进入我的视野，是因为它和传统的"测试工具"有本质区别。传统工具解决的是"执行自动化"，比如接口自动化框架、UI自动化脚本，它们擅长把已经写好的用例跑起来。但用例从哪来、缺陷为什么出现、日志里哪一行才是关键，这些判断依然靠人。Agent Skills 补的正是这一段：它把"理解需求、生成用例、分析失败、定位根因"这些偏认知的工作，拆成一个个可复用的技能单元，让智能体按流程去调用。

这篇文章想聊的，就是我怎么用 Agent Skills 把测试流程从"用例生成"到"缺陷定位"重新串了一遍。适合两类人看：一类是测试负责人，想了解这套东西到底能落地到什么程度；另一类是一线测试和开发，想直接抄一套可复现的方案。我不会讲太多概念，重点放在每个环节具体怎么做、参数怎么定、坑在哪里。

2. Agent Skills 的核心设计思路

2.1 为什么不是"一个大模型包打天下"

最开始我也试过偷懒，直接写一个超长提示词，把需求文档丢进去，让它一次性输出用例、执行建议和缺陷分析。结果很不稳定：用例质量忽高忽低，缺陷定位经常答非所问，而且一旦某个环节出错，整条链路就崩了，根本没法排查是哪里出的问题。

后来我意识到，测试流程本身就是分阶段的，每个阶段的输入输出、判断标准、失败模式都不一样。用一个笼统的智能体去覆盖所有阶段，等于让它同时做五件事，注意力被稀释，效果自然差。Agent Skills 的思路是把每个阶段拆成一个独立技能，每个技能有明确的输入契约、输出格式和校验规则，技能之间通过结构化数据传递。

这样拆的好处有三个。第一是可调试，哪个技能输出不对，单独拿出来测就行。第二是可替换，用例生成技能效果不好，换一个提示词模板或者换一个模型都可以，不影响其他环节。第三是可积累，每个技能跑过的案例、修正过的输出，都能沉淀成这个技能的"经验"，越用越准。

2.2 技能拆分的四个原则

拆分不是随便切，我总结了四条原则，实测下来比较靠谱。

原则一：单一职责。一个技能只做一件事。比如"从需求提取测试点"和"把测试点扩展成用例"就是两个技能，不要合并。合并之后提示词会变长，模型容易漏掉后半段要求。

原则二：输入输出结构化。每个技能的输入是明确的字段，输出是固定格式的 JSON 或表格。比如测试点提取技能，输入是需求段落，输出是{测试点, 优先级, 关联需求ID}的列表。结构化之后，下游技能才能稳定消费。

原则三：可独立验证。每个技能都要有办法判断它输出对不对。用例生成技能可以用"是否覆盖了所有测试点"来验证，缺陷定位技能可以用"给出的根因是否被后续修复证实"来验证。没有验证标准的技能，等于没法迭代。

原则四：失败可降级。某个技能输出质量差时，流程不能直接卡死。比如缺陷定位技能如果置信度低，就退化成"给出可疑范围+建议人工排查方向"，而不是硬给一个错误结论。

2.3 整体链路长什么样

我把整条链路设计成五个技能串联，中间用一份共享的"测试上下文"对象传递数据。这个上下文对象贯穿始终，每个技能读它需要的字段，写它产出的字段。

这五个技能不是必须全用。小团队可以只用 S1+S2 解决用例生成，大团队可以全上。关键是每个技能都能独立跑，也能串起来跑。

3. 从需求到用例：前两个技能怎么落地

3.1 需求解析技能：把模糊描述变成可测点

需求文档最大的问题是"看起来说了很多，实际能测的没几条"。比如一句"用户可以快速完成下单"，里面藏着至少五个可测点：下单入口在哪、快速的定义是什么（几步内）、异常情况怎么处理、并发下单怎么办、下单后状态怎么变。人工拆解靠经验，Agent 拆解靠结构化提示。

我的需求解析技能提示词大致是这样的结构：先让模型识别需求里的"动作主体、动作、对象、约束条件"，再针对每个动作生成正向、反向、边界三类测试点。这里有个关键技巧，就是要求模型对每个测试点标注"可测性"，如果它自己都觉得这个点没法验证，就标出来让人复核。

{ "skill": "requirement_parser", "input": { "requirement_text": "用户可以快速完成下单", "context": "电商下单模块，已有购物车" }, "output_schema": { "test_points": [ { "id": "TP-001", "description": "从购物车进入下单页的入口可见", "type": "正向", "priority": "P0", "testable": true, "related_requirement": "下单入口" } ] } }

实测下来，一个两百字的需求，这个技能能稳定产出 15 到 25 个测试点，其中约 70% 是人工会想到的，剩下 30% 里有一部分是人工容易漏的边界情况，比如"购物车为空时下单入口是否还显示"。这 30% 就是价值所在。

注意：需求解析技能一定要喂足够的上下文。只给一句话需求，模型只能瞎猜；把相关的模块说明、历史缺陷、接口文档一起给它，测试点的质量会明显提升。

3.2 用例生成技能：从测试点到可执行用例

测试点只是"要测什么"，用例是"怎么测"。这一步的难点在于，模型很容易生成"正确但没用"的用例，比如"输入合法数据，点击提交，验证成功"，这种用例写了等于没写。

我的做法是给用例生成技能加三个约束。第一，每条用例必须包含具体的数据值，不能写"合法数据"，要写"手机号13800000000、金额0.01"。第二，必须包含预期结果的精确描述，不能写"下单成功"，要写"订单状态变为待支付，且库存扣减1"。第三，必须标注这条用例覆盖了哪个测试点，方便后续查覆盖度。

用例生成技能的提示词里，我会放一个"反面示例"清单，明确告诉模型哪些写法是不合格的。这个技巧很管用，模型对反面示例的敏感度比正面要求高。

# 用例生成技能的核心校验逻辑（伪代码） def validate_case(case): errors = [] if not case.get("concrete_data"): errors.append("缺少具体数据值") if "成功" in case["expected"] and len(case["expected"]) < 10: errors.append("预期结果过于笼统") if not case.get("covers_test_point"): errors.append("未标注覆盖的测试点") return errors

这个校验逻辑跑在技能输出之后，不合格的用例打回去让模型重写，最多重试两次。实测下来，加了校验之后，用例的可用率从大概 50% 提升到 80% 以上。

3.3 覆盖度检查：别让技能自己说了算

用例生成完，不能直接信。我会跑一个独立的覆盖度检查，把测试点列表和用例列表做交叉比对，看哪些测试点没有被任何用例覆盖。这个检查逻辑很简单，就是集合运算，但效果很好。

有一次跑下来发现，一个"并发下单"的测试点没有任何用例覆盖，因为模型觉得这个场景"太复杂"就跳过了。这种遗漏人工复核时很容易漏，但机器一比对就出来了。覆盖度检查的结果会反馈给用例生成技能，让它针对未覆盖的点补用例。

4. 执行与失败分析：中间两个技能

4.1 执行编排技能：让结果可复现

用例有了，接下来是执行。这一步 Agent Skills 能做的不是替代自动化框架，而是做"执行编排"：根据用例的优先级、依赖关系、环境要求，生成一个合理的执行顺序，并记录每条用例的执行上下文。

为什么执行顺序重要？因为很多用例之间有状态依赖。比如"下单"用例必须在"加入购物车"用例之后跑，否则数据不对。人工排顺序容易出错，尤其是用例上百条的时候。执行编排技能会分析用例之间的数据依赖，自动排出拓扑顺序。

执行结果我要求记录三样东西：实际结果、执行时的环境快照（版本号、配置项）、原始日志片段。这三样是后续失败分析的基础。很多团队执行完只记个"通过/失败"，失败分析时两眼一抹黑，就是因为上下文丢了。

4.2 失败分析技能：先分类，再定位

失败分析是最容易被低估的环节。一条用例失败，可能是产品缺陷，可能是用例本身写错了，可能是环境问题，可能是数据问题。如果不先分类，直接去定位根因，方向就错了。

我的失败分析技能第一步做分类，把失败归到四类：产品缺陷、用例问题、环境问题、数据问题。分类的依据是日志特征和失败模式。比如日志里出现"连接超时"，大概率是环境问题；出现"断言失败但接口返回200"，可能是用例预期写错了。

分类之后，只有"产品缺陷"这一类才进入下一步的缺陷定位。其他三类分别走不同的处理路径：用例问题打回用例生成技能修正，环境问题触发环境检查，数据问题触发数据重置。这样整个流程就不会在非缺陷问题上浪费定位精力。

这个分类表是我跑了大概两千条失败用例之后统计出来的。可以看到，真正需要定位的产品缺陷只占三分之一，剩下三分之二如果都按缺陷去查，就是纯浪费。分类这一步省下的时间，比定位本身省下的还多。

提示：分类技能的准确率依赖日志质量。如果日志里只有一句"执行失败"，分类基本靠猜。所以执行编排技能里记录原始日志片段这一步，是整条链路的地基。

5. 缺陷定位技能：最难也最有价值的一环

5.1 定位不是猜，是缩小范围

缺陷定位技能最容易做成"算命"：给个失败信息，让模型猜哪里出了问题。这种猜法偶尔对，但不可靠。我的做法是把定位拆成"缩小范围"和"提出假设"两步。

缩小范围靠的是证据关联。一条用例失败，相关的证据有：失败的断言、接口返回、服务端日志、最近的代码变更、相关的历史缺陷。定位技能把这些证据收集起来，先做关联分析，把可疑范围从"整个系统"缩小到"某几个模块或某几次提交"。

具体怎么缩？我用的是"变更关联法"：把失败用例涉及的接口、页面、数据表，和最近的代码提交做匹配，找出改动过这些地方的提交。如果失败用例在改动前是通过的，改动后才失败，那这些提交就是高可疑对象。这个方法不依赖模型，纯靠数据比对，但能把范围缩得很准。

5.2 根因假设与证据链

范围缩小之后，定位技能才让模型提出根因假设。关键是每个假设必须附带证据链，不能光给结论。比如假设是"库存扣减逻辑在并发下出现超卖"，证据链就要包含：失败用例的并发场景、日志里库存变化的时序、相关代码片段。

我要求定位技能输出这样的结构：

{ "root_cause_hypothesis": "库存扣减未加锁导致并发超卖", "confidence": 0.75, "evidence_chain": [ {"type": "log", "content": "两次扣减日志时间戳相差2ms"}, {"type": "code", "content": "扣减方法未见锁或原子操作"}, {"type": "history", "content": "同类问题在三个月前出现过一次"} ], "verification_steps": [ "构造10并发下单，观察库存最终值", "检查扣减方法的数据库隔离级别" ] }

置信度这个字段很重要。低于 0.5 的假设，我要求技能直接标注"建议人工排查"，不要硬给结论。高于 0.8 的假设，可以直接进入验证步骤。中间地带的，人工看一眼证据链再决定。

5.3 验证闭环：让定位结果可被证实

定位技能给出的假设，必须能被验证。验证方式有两种：一是构造针对性用例复现，二是检查代码或配置确认。我要求定位技能同时给出验证步骤，这样测试人员拿到结果就能直接动手，不用再想"怎么证明这个假设"。

验证结果会回写到技能的经验库里。假设被证实，这个案例就成为正样本；假设被推翻，就成为负样本。跑得越多，定位技能的准确率越高。我这边跑了大概三个月，定位准确率从最初的 40% 左右提升到 70% 上下，主要靠的就是这个反馈闭环。

6. 实操中的坑与排查技巧

6.1 技能之间的数据契约最容易出问题

整条链路跑起来之后，最常见的故障不是某个技能输出质量差，而是技能之间的数据对不上。比如用例生成技能输出的字段叫case_id，失败分析技能读的字段叫id，结果就是读不到数据，流程静默失败。

我的解决办法是维护一份"上下文 schema"，所有技能都按这份 schema 读写。schema 用 JSON Schema 定义，每个技能启动时先校验自己的输入输出是否符合 schema，不符合直接报错，不要往下传。这个校验加在流程入口和每个技能出口，虽然多写点代码，但省下了大量排查数据问题的时间。

6.2 模型输出不稳定，要用重试和兜底

大模型输出有随机性，同一个输入跑两次结果可能不一样。对于测试流程这种要求稳定的场景，必须加控制。我的做法是：关键技能设置温度参数为 0 或接近 0，减少随机性；输出加格式校验，不合格就重试；重试两次还不行，走兜底逻辑，比如返回"需要人工处理"而不是硬输出。

温度参数这里有个经验值：需求解析和用例生成可以用 0.2 到 0.3，保留一点多样性，避免用例千篇一律；失败分析和缺陷定位必须用 0，要的是稳定和可复现。

6.3 常见问题速查表

这张表是我踩坑踩出来的，基本覆盖了八成以上的日常问题。遇到新问题，先对照这张表看是不是已知类型，不是再深入排查。

6.4 几个反直觉的经验

第一个经验：技能不是越多越好。我一开始拆了十几个技能，结果维护成本极高，技能之间的依赖关系复杂到没人能理清。后来合并到五个，反而更稳。拆分的粒度以"能独立验证"为准，不要为了拆而拆。

第二个经验：人工复核不能省。Agent Skills 再准，也有盲区。我的流程里，用例生成后有人工抽检，缺陷定位后有人工确认。抽检比例不用高，10% 到 20% 就够，但必须有。完全放手不管，迟早出问题。

第三个经验：先跑通一个技能，再串链路。很多人一上来就想把整条链路搭起来，结果每个环节都不稳，根本不知道问题在哪。正确做法是先挑一个技能，比如用例生成，单独跑顺、跑准，再往上接需求解析，往下接执行编排。一个一个来，稳得多。

7. 这套流程适合什么样的团队

Agent Skills 重构测试流程，不是所有团队都适合立刻上。我的判断标准是看两点：一是测试用例量是否大到人工维护吃力，二是缺陷定位是否经常靠"猜"和"问"。如果这两点都中，那这套东西值得投入。

小团队可以从用例生成这一个技能开始，投入不大，见效快。中等团队可以把需求解析到用例生成这一段跑通，解决用例质量和覆盖度问题。大团队再考虑全链路，把失败分析和缺陷定位也接进来，这时候收益才明显。

需要提醒的是，这套流程对工程能力有要求。技能之间的数据契约、schema 校验、重试兜底、反馈闭环，这些都需要写代码。纯靠提示词拼凑，跑不长。所以落地之前，先确认团队里有人能维护这套基础设施。

我在实际推进的时候，最大的阻力不是技术，是习惯。测试同学习惯了手工写用例、手工定位，对机器输出天然不信任。我的做法是先让技能做"辅助"，输出结果给人参考，人做最终判断。跑一段时间，大家发现机器给的测试点确实有遗漏的、定位确实有方向，信任就慢慢建立起来了。这个过程急不得，但一旦建立，整个团队的测试效率会有质的变化。