Skills × 缺陷管理：AI写了两页Bug报告，研发只回“无法复现”

关注 霍格沃兹软件测试开发 公众号，回复「资料」, 领取人工智能测试开发技术合集

标题很专业，影响分析很完整，原因猜了三条，修复建议甚至带上了代码。

研发看完，回复一句：“具体怎么复现？”

这句话容易让人上火。但把那两页报告重新翻一遍，可能真的没有写清：用什么账号、进入哪一页、修改了哪个字段、期待发生什么、实际上看到了什么。

AI可以把几句描述扩写成一份很像样的报告，也可能把信息缺口藏进流畅的段落里。

缺陷报告的价值，是让接手的人更快获得同一个可检查的事实。 字数、术语和语气，都不能替代这件事。

先看一个虚构示例：它缺的不是“根因分析”
假设后台允许修改联系人资料。用户只编辑地址，手机号没动，保存后手机号却变成空值。

一份低效报告可能这样写：“客户资料保存存在数据一致性问题，疑似前端状态同步异常，可能影响用户体验，建议优化数据绑定。”

这些句子不一定错，但接手的人仍然不知道从哪里开始。

把同一个教学场景改成下面的结构，信息会直接落地：

标题：编辑联系人地址后，未修改的手机号被保存为空

环境：测试环境，构建号build-demo-09
前置：测试联系人C-17已有地址与手机号
步骤：

1. 打开C-17编辑页
2. 仅修改地址字段
3. 保存并重新打开详情

预期：地址更新，手机号与保存前一致
实际：地址更新，手机号为空
证据：保存前后字段快照、请求载荷、响应、重新查询结果
复现情况：记录实际尝试次数和发生次数，不预填“必现”
影响范围：当前只验证了这个测试联系人与这个入口
原因推测：可能与未编辑字段的提交语义有关，尚未确认
这里故意把“原因推测”和“已经观察到的事实”分开。前端可能传了null，服务端可能把缺失字段当成清空，序列化过程也可能改了值。没有证据前，不必抢着给责任方下结论。

人工智能技术学习交流群
伙伴们，对AI测试、大模型评测、质量保障感兴趣吗？我们建了一个 「人工智能测试开发交流群」，专门用来探讨相关技术、分享资料、互通有无。无论你是正在实践还是好奇探索，都欢迎扫码加入，一起抱团成长！期待与你交流！👇

让AI先检查缺口，再帮助整理
如果输入只有“地址改完手机号没了”，更合理的Skill输出不是补出一套虚构环境，而是列出还缺什么。

可以把缺陷整理Skill的规则写成这样：

只使用输入中已有的事实。
缺少环境、步骤、预期或实际结果时，列为待补充。
不得编造复现次数、影响用户量、版本号和请求内容。
“疑似原因”单列，不能改写成“根因已确认”。
保留原始证据标识，摘要不能替代原始记录。
将报告整理为最短可复现步骤，再补充影响与线索。
这类约束对AI测试开发特别有用。模型擅长组织语言，但测试报告不能容忍它为了完整而补齐不存在的事实。

对于涉及模型输出的缺陷，额外记录提示词版本、模型配置、关键输入和必要上下文。没复现不一定说明没有问题，也可能是这几项发生了变化。真实数据应按团队规则脱敏，同时保留与复现相关的结构和边界。

“无法复现”以后，别只把录像再发一遍
先把差异拆成三组：

差异类型
可以直接比较的内容
输入不同
账号权限、字段原值、请求内容、历史数据
执行不同
版本、入口、操作顺序、并发与等待条件
观察不同
看页面提示、重新查询、还是查到了另一个数据源
如果问题只在保留旧数据的账号上出现，新建账号当然可能复现不了。如果只看保存成功提示，不重新读取字段，双方观察的也不是同一件事。

接下来缩小步骤：能否删除与问题无关的操作？能否把大文件缩成三行？能否用一组脱敏字段代替整份客户资料？每删一步，都重新确认问题仍然存在。

这不是为了把报告写得好看，而是降低他人重现问题的成本。最小复现样本也更适合后续变成回归测试。

别让“复现次数”变成另一个漂亮数字
如果尝试十次出现三次，就记录3/10，以及每次的关键条件。不要为了让缺陷显得重要写成“稳定复现”，也不要因为概率低就自动降低影响评级。

发生概率与后果严重程度是两个维度。一个偶发的数据清空问题，可能比稳定出现的轻微样式问题更需要优先处理。

反过来，测试环境验证了一个账号，不代表可以推断“影响全量用户”。可以列出疑似相关范围和下一步验证方法，但要让接手的人看得出哪些已经验证，哪些仍是待查。

测试负责人可以改一条验收规则
不要按“AI生成了多少条Bug报告”衡量价值。更接近交付的观察是：首次接手是否能执行复现步骤、补充信息往返多少次、重复缺陷如何合并，以及修复后是否有回归样本。

这些指标也需要结合复杂度，不能用来惩罚提出疑难问题的人。目的应是改善信息流动，而不是逼大家只提交容易复现的小问题。

技术能力和沟通能力，在这里其实连在一起：你越能区分输入、状态、观察和推测，报告越清楚；报告越清楚，问题也越容易进入有效排查。

对想进阶AI测试开发的人来说，可以从一个简单练习开始：选一份自己已经处理过、允许使用的缺陷，把它整理成一个脱敏最小样本，再写出修复前失败、修复后通过的回归验证。

AI可以帮你把报告写长。测试工程师真正要做的，是让下一位接手的人少猜一点。

推荐学习
智能化测试-测试用例生成公益训练营，从行业大模型特性讲起，带你搞懂AI测试的全链路：大模型能力评测、智能体Harness工程、Skill技能体系、CLI与MCP工具体系、RAG知识图谱——最后直接上手打造一个能自动生成测试用例的智能体。

关于我们
霍格沃兹测试开发学社，隶属于 测吧（北京）科技有限公司，是一个面向软件测试爱好者的技术交流社区。

学社围绕现代软件测试工程体系展开，内容涵盖软件测试入门、自动化测试、性能测试、接口测试、测试开发、全栈测试，以及人工智能测试与 AI 在测试工程中的应用实践。

我们关注测试工程能力的系统化建设，包括 Python 自动化测试、Java 自动化测试、Web 与 App 自动化、持续集成与质量体系建设，同时探索 AI 驱动的测试设计、用例生成、自动化执行与质量分析方法，沉淀可复用、可落地的测试开发工程经验。

在技术社区与工程实践之外，学社还参与测试工程人才培养体系建设，面向高校提供测试实训平台与实践支持，组织开展 “火焰杯” 软件测试相关技术赛事，并探索以能力为导向的人才培养模式，包括高校学员先学习、就业后付款的实践路径。

同时，学社结合真实行业需求，为在职测试工程师与高潜学员提供名企大厂 1v1 私教服务，用于个性化能力提升与工程实践指导。