当 AI 编码助手能更快生成软件和测试时，更值得追问的是：它是否知道系统为什么这样运行、哪些风险已经验证过、过去又发生过什么？

在 Ministry of Testing 的分享《From Test Cases to AI-Ready Quality Data: Why Structure Matters》中，Sembi 旗下 TestRail 与 Ranorex 的解决方案架构负责人 Chris Faraglia 提出，团队应从向 AI 塞入互不相连的记录，转向提供有结构、有关系、保留历史的质量上下文。

本文先整理分享内容，再提出工程落地建议。数据治理、AI 原生 QA 应用与试点计划属于本文延伸，不代表演讲者已实施或验证。

原始分享：From Test Cases to AI-Ready Quality Data: Why Structure Matters: https://www.ministryoftesting.com/media-sessions/from-test-cases-to-ai-ready-quality-data-why-structure-matters

AI 需要连得起来的历史，而不是更多零散记录

需求可能在 Jira，用例在测试管理平台或 Markdown，自动化结果在持续集成系统，缺陷在问题跟踪器，发布历史在 GitHub，而关键决策可能只留在 Slack、Teams 或某个人的记忆里。

单条记录可以完全准确，但“测试失败”本身仍无法说明需求是否刚变过、运行的是哪个构建和环境、这是不是重复出现的故障，还是用例本身不稳定。

**数据量不等于上下文质量。**演讲者介绍，Sembi 每年会开展软件质量调查，覆盖数千名用户；首份综合《Software Quality Pulse》报告中，受访者报告称其代码有 53% 由 AI 生成或辅助完成。Sembi 于 2026 年发布的公开报告称，受访者接近 4,000 人，来自 QA、安全、开发和工程管理等岗位；报告还显示，61% 的受访者称 AI 生成代码带来了中等到显著的 QA 需求增长，17% 则认为 AI 驱动的测试产生了显著影响。这些是厂商发布的调查中由受访者报告的数据，不是对全球代码的普查，也不能证明变化完全由 AI 单独造成。代码产出加快，也让 QA 更需要可供机器使用的质量知识。

什么样的测试结果以后仍然有用？

演讲者把质量数据比作医疗记录。电子病历会记录结构化的诊断、化验结果和用药信息；临床记录则补充当时的情况、观察与判断理由。

测试也需要两类信息：

信息类型测试中的例子价值
结构化事实测试标识、需求标识、环境、构建版本、结果、缺陷标识便于检索、关联和汇总
非结构化叙述为什么修改断言、复现说明、风险判断、失败分析保留解释与细节

只有结构化字段，工程判断容易丢失；只有自由文本，又很难可靠关联。让数据适用于 AI，并不意味着要淘汰 Markdown，而是要让重要事实有稳定、明确的含义，同时保留解释它们的文字。

把结果关联到需求和变更。

“500 个测试通过了”——它们覆盖了哪些需求、流程和风险？“构建失败了”——这是新问题还是反复出现的模式？“测试改过了”——是需求变化、缺陷修复，还是日常维护？“发现一个缺陷”——它出现在哪个环境和构建里，又属于哪个发布版本？

一条可追溯的证据关系可以表述为：需求或风险，关联到测试义务与用例；用例关联到测试执行、环境和构建版本；失败关联到缺陷、修复与代码变更；最后再关联到发布、回归证据和发布决策。

这些记录不必全部放在同一个产品里，但需要稳定标识、明确关系和可检查的证据。也要区分相关性与因果关系：代码合并先于测试失败，只能形成调查假设，不能直接证明根因。

留下足以解释重复问题的历史。

分享用结账流程举例：需求发生变化，代码合并并部署，原本通过的测试开始反复失败，随后团队提交了相关缺陷。

单次红灯只说明出现了症状；把执行历史、环境、构建、代码变更和修复连起来，才更有机会判断这是重复缺陷、配置影响，还是不稳定测试。

历史并不意味着所有原始日志都要永久保存。团队应制定保留期限、去重规则、时间戳和版本归属。追踪文件、截图等大型材料可以放在外部存储，只在上下文中保留稳定链接和摘要，不必整批塞进模型窗口。

建立一套质量数据生命周期

分享提出五步：Structure（结构化）→ Connect（连接）→ Preserve（保留）→ Enrich（补充）→ Expose（受控开放）。

统一字段含义（Structure）。

最小测试记录可以包含稳定标识、测试目的、前置条件、步骤、预期结果、需求和风险关联、生命周期状态。自动化测试还需要对应的代码位置、用例标识和清晰的断言意图。

使用 BDD 的团队还可以保留场景描述、步骤说明和评审评论，让业务语境与判断理由留在记录中。但这些文字仍应关联稳定的需求和风险标识，不能只靠自然语言描述关系。

id: TEST-CHECKOUT-017
requirement_ids: [REQ-CHECKOUT-004]
risk_ids: [RISK-PAYMENT-DUPLICATE]
level: api
preconditions: "A valid cart exists; payment gateway uses a controlled test double"
expected: "A repeated submission must not create a second payment"
owner: checkout-team
status: active

这只是说明字段设计的示例，不是演讲者规定的格式。重点是字段含义要一致：不能在一个系统里让 status 表示用例生命周期，在另一个系统里却表示本次执行结果。

关联质量记录（Connect）。

用系统原生标识或稳定链接，连接需求、测试、执行、缺陷、代码变更和发布版本，不要只靠相似标题猜测关系。关系也可能是多对多：一个业务风险需要多个测试层级共同验证。

留存变更与决策（Preserve）。

保留有意义的执行记录、失败分类、用例变更原因、需求变更和发布决策。淘汰用例时，也应记录淘汰原因与影响，而不是直接让它从历史中消失。

补足领域背景（Enrich）。

视实际用途补充环境、浏览器、地区、功能开关、测试数据版本、依赖版本、框架和业务重要性。每个字段都应支持具体判断；没有用途地收集元数据，只会增加维护负担。

按权限提供上下文（Expose）。

可以用 REST API、系统集成或 MCP，让 AI 助手查询质量上下文。MCP 是访问与集成协议，不会自动清洗错误数据，也不会替团队推断出正确关系。必须同时设计最小权限、敏感信息脱敏、访问审计、查询范围和来源标注。

让关联数据进入工作流，而不是先假定某个平台

分享将这种做法称为“以测试为上下文”（Tests as Context）。测试资产不应只在代码写完后负责验收，也可以参与需求分析、设计、实现和代码审查。

例如，团队准备修改结账 API 时，助手可以先读取相关需求、现有测试、过去的回归缺陷和高风险断言。QA 随后据此识别新增的验证义务，而不用每次都从头人工拼接背景。

仍有两个明显风险：把过期测试误当成当前需求；或者把 AI 生成的测试建议未经执行就写成“已验证证据”。上下文是待核查的证据，不会自动变成真相。

质量数据应该放在哪里？

演讲者把测试管理平台定位为质量编排层，用来连接持续集成、需求、缺陷、发布，以及手工和自动化测试。这与 TestRail 的产品视角一致，应明确视作厂商立场，而不是唯一解。

小型仓库可能用 Markdown、测试代码、持续集成产物和轻量索引就足够；跨团队、长期积累的数据则可能更适合专门的管理平台或关系数据层。比起争论“平台还是 Markdown”，更值得评估的是：

  • 质量实体能否使用一致的标识？
  • 关系与版本历史是否可以持续维护？
  • 更新能否同步，避免重复手工录入？
  • 有权限的查询能否返回可追溯来源？
  • 维护成本和厂商锁定风险是否可控？

问答与效果数据能说明什么

分享后的问答补足了实施中的几个关键判断。

模型是否比上下文更重要？

演讲者提到，在他的实验中，是否提供相关上下文，比单独换一个具体模型更能影响结果。没有上下文的强模型仍可能表现不佳；通过 MCP 提供恰当资料能改善任务表现。不过模型能力、上下文质量、令牌消耗和任务本身都有关，不能据此断言任何任务都无需关注模型选择。

能否接入多个上下文来源？

演讲者提到可以连接测试管理平台、GitHub 或 GitLab、持续集成等来源。重点不是接入数量，而是确保数据之间关系清楚、内容质量可信。本文的实践建议是：不要只因数据来源不同就一概排除，也不要把能接入误当成值得全部检索。

团队怎样把它放进日常工作？

演讲者描述了手工与自动化测试并行、尽早且频繁验证的工作方式，并提到通过 MCP 把测试数据带入开发者工作流。问答环节中，他说 TestRail 的正式版本几乎按月发布，部分客户还会收到更早的版本。这是 TestRail 的产品发布节奏，不是所有团队都应照搬的交付建议。

测试管理与质量管理有什么区别？

演讲者认为，行业正在从存放用例的测试管理，走向连接需求、构建、执行、缺陷、发布和决策的“质量编排”。重点是让质量活动及数据彼此衔接，而不只是维护一个用例库。

如何处理不同版本的上下文？

可以把测试、需求、缺陷和变更历史关联到发布里程碑，例如用 Jira 的固定版本，或 Git 的发布标签。不必为每个分支各自维护一套孤立资料；更重要的是保留可跨发布查询、可追溯的历史。

AI 是增强还是替代？

演讲者强调 AI 应成为能力放大器，支持现有工作，而不是只为了把工作外包出去。本文进一步延伸这一观点：如果代码产出更快，却没有相应的验证和治理，生产质量仍可能下降；聚焦且可信的上下文能减少返工，但不能取代人的责任。

Markdown 与专用平台如何选择？

问答中，有听众提到一家大型国防机构曾考虑用版本化 Markdown 管理需求和质量记录。演讲者的回答强调系统集成、结构化数据实体和规模化能力；他也承认自己可能偏向 TestRail。小型团队可以从 Markdown、测试代码、持续集成产物和轻量索引开始。演讲者还提到一位客户拥有 5 TB 测试数据，这是个案，不是“达到某容量就必须买平台”的门槛。这些都是厂商视角下的案例，并不能证明所有团队都需要专用平台。团队应根据规模、关系管理、治理、集成、维护成本和锁定风险评估。

把分享中的效果数据当作案例看。

演讲者报告了 Sembi 的内部结果：每个功能的模型令牌用量减少 36%；使用 Tests as Context 的首轮通过率为 100%，未使用时为 40%。他还提到缺陷减少、代码质量提高、每个功能预防的缺陷增多，但没有给出这些结果的具体数值。这些都是演讲者报告的内部案例结果，不是独立验证的行业基准。分享未提供足够的样本规模、任务分布、模型设置和统计方法，外部团队无法据此直接复现。

团队可在自己的任务上做对照，观察首轮有效通过率、人工返工时间、逃逸缺陷、上下文检索准确率、引用可追溯性，以及令牌和费用。还应记录任务难度，不能把生成更快直接等同于质量更好。

从一个 AI 原生 QA 工作流开始

开发 QA 技能、智能体和测试质量工具的团队，可以把质量上下文视为共享能力，而不是在每个智能体里重复硬编码：

  1. 定义共同实体：需求、风险、验证义务、测试、执行、证据、缺陷、变更、发布。
  2. 建立关系索引：能从代码变更找到验证义务，也能从失败回溯到需求和历史证据。
  3. 标记证据类型：区分用户提供的信息、工具观测结果、AI 推断和人工确认结论。
  4. 提供受控检索：先按发布、模块和环境筛选，再读取所需叙述材料。
  5. 评估上下文质量：测量检索准确性、关系正确率、过期命中、虚构引用和决策影响。

先挑一个业务流程，把需求变更、影响分析、测试建议、执行结果、缺陷和发布串起来，不要一上来就建大平台。

四周试点安排。

周次工作验收证据
第 1 周选一个高风险流程，盘点需求、测试、缺陷、运行记录和发布来源清单、缺口、标识约定
第 2 周定义最小字段与关系，导入近期执行历史能从需求查到测试，也能从失败查到构建和缺陷
第 3 周通过只读 API 或 MCP 提供带来源的查询AI 输出包含可核实的标识和版本
第 4 周对照使用与不使用结构化上下文的任务留存样本、失败案例、成本和质量指标

测试用例不应在执行后变成无人维护的静态清单。当它们能与需求、风险、变更、结果和决策建立联系，就能成为 AI 可使用、工程师可审计的质量资产。

适用于 AI 的质量数据，不是让 AI 读得更多，而是让人和模型都能看清：每条记录代表什么、关联到哪里、适用于哪个版本，以及为什么值得信任。

参考资料

来源说明：本文依据 Chris Faraglia 于 2026-10-15 的 Ministry of Testing 分享、用户提供的笔记和转录整理。AI 原生 QA 应用、试点计划与示例数据结构是额外的实践建议；调查与内部效果数字均保留演讲者归属。

测试管理安全测试白盒测试背靠背测试本地化测试
分享