26软工实践 智测领航 TestPilot 团队展示 选题报告 需求分析
26软工实践 智测领航 TestPilot 团队展示 选题报告 需求分析
一、作业信息
| 项目 | 内容 |
|---|---|
| 作业所属课程 | H202601 软件工程与软件工程实践 |
| 作业要求 | 2026秋软工实践团队作业-第一次（团队展示+选题报告+需求分析） |
| 作业目标 | 围绕真实需求选择一个具体领域，构建领域 Agent，并在此基础上开发一条可运行、可检查的软件流程；说明目标用户、使用场景、领域知识、Agent 任务、软件范围、团队分工和验收方法。 |
| 团队名称 | 智测领航 TestPilot 团队（队名可在发布前确认） |
| 项目名称 | 智测领航 TestPilot：面向 Vibe Coding 者和基础开发者的智能软件测试平台 |
| 团队成员 | 见下方“团队展示” |
| 博客标题 | 26软工实践 智测领航 TestPilot 团队展示与选题报告 |
二、团队展示
2.1 队名与项目一句话介绍
我们是智测领航 TestPilot 团队。我们计划开发一个面向 Vibe Coding 者、基础开发者和课程项目团队的智能软件测试平台，把“需求澄清、测试规划、用例设计、人工确认、不同测试类型的执行或检查、结果分析和报告留档”串成一条可追踪的流程。
TestPilot 的领域 Agent 主要完成两项任务：
- 根据需求、功能描述、接口资料和测试知识，识别需要覆盖的功能、异常、边界、鉴权、数据流和接口集成场景，生成带有需求关联、覆盖类型、测试步骤、断言候选和缺项清单的测试草稿。
- 根据已经发生的失败证据，引用实际请求、响应、断言差异和错误阶段，给出可能原因与下一步建议，并区分接口、功能、环境、数据和用例问题。
AI 只提供测试候选和分析建议。用户确认测试版本，后端执行器或人工检查流程负责记录确定性结果。
2.2 团队成员
下表中的角色来自答辩材料，成员的性格、兴趣和个人简介请在发布前由本人补充。
| 学号 | 姓名 | 主要角色 | 主要工作 | 性格 / 兴趣 |
|---|---|---|---|---|
| 102402141 | 叶思铖 | 项目协调 / Agent | 需求组织、范围评审、Agent 方案 | 打游戏 运动 睡觉 |
| 102302152 | 戴锴斌 | 项目协调 / Agent | 进度协调、Agent 协作 | 打游戏 |
| 052404147 | 刘怀正 | Agent / 汇报 | Agent 设计、答辩汇报 | 打羽毛球、看小说 |
| 052401324 | 刘昭杉 | 测试与部署 | 测试环境、异常分支、部署检查 | 打游戏 |
| 102401323 | 陈勇昊 | 测试与部署 | 演示服务、验收记录、部署支持 | 打羽毛球、cs |
| 102402123 | 丁维彤 | 测试与部署 | 测试用例、验收和回归检查 | 打羽毛球、打游戏 |
| 052404129 | 林彦羽 | 前端 | 页面结构、用例编辑和结果交互 | 打游戏，睡觉 |
| 102402120 | 陈睿涛 | 前端 | 执行进度、报告展示和前端联调 | 听歌、看球 |
| 102401314 | 曾炜毅 | 后端 | 数据模型、接口和业务服务 | 三角洲，王者 |
| 072308214 | 周兴宇 | 后端 | 执行引擎、状态和结果持久化 | 打游戏 |
| 032401339 | 沈冠宇 | 后端 | 校验、报告和后端联调 | 打王者 |
| 052402234 | 郭泽强 | 后端 | 环境配置、安全约束和接口实现 | 打乒乓球，刷算法题 |
2.3 团队首次合照
2.4 团队愿景
我们希望把软件测试从交付前的临时检查，变成有依据、可追踪、能复核的日常实践。通过分工协作完成真正可用的智能测试平台，让学生更容易发现问题，也在项目中学会对需求、代码和测试结论负责。
2.5 团队分工与协作方式
- 需求与项目协调：负责真实调研、需求追踪、范围控制、迭代记录和进度沟通。
- Agent 设计：负责测试知识整理、提示词模板、结构化输出、需求澄清和定制效果评估。
- 前端：负责项目页、需求页、接口与环境页、用例编辑页、执行页、结果页和报告页。
- 后端：负责数据模型、版本管理、静态校验、HTTP 执行、状态管理和 HTML 报告。
- 测试与部署：负责演示服务、异常场景、验收证据、公网部署和操作说明。
- 汇报：负责答辩材料、现场演示和问答组织。
团队允许成员兼任角色。每周进行一次范围评审，范围变更记录功能编号、变更原因、工作量影响和对应验收项。
三、选题背景与真实需求
3.1 为什么选择智能软件测试
Vibe Coding 和基础开发工具可以帮助用户快速生成页面、接口和业务代码，但“能生成代码”不等于“项目已经被验证”。对于缺少系统测试经验的开发者，测试往往集中在最后的手工点击或一次接口调试，容易遗漏异常输入、边界条件、鉴权、数据流和需求变更后的回归检查。
团队需要回答的问题不只是一条接口能不能返回 200，还包括：
- 需求中的功能、异常和边界条件是否都被覆盖？
- 测试用例能不能对应回具体需求和实现模块？
- 接口、页面或业务规则变化后，哪些测试需要复核？
- 失败来自功能缺陷、接口问题、环境、测试数据还是用例本身？
- 能不能把自动执行结果和人工检查证据整理成一份可复核的报告？
因此，TestPilot 的定位是面向基础开发者的软件测试辅助平台。平台可以生成多种测试类型的方案和用例，首版以 HTTP JSON 接口及其集成场景作为最完整的可执行链路；功能场景、鉴权、边界、数据流和回归检查纳入统一的需求追踪。UI 自动化和性能压测先以测试计划、检查清单或后续适配为边界，不把未实现的自动化能力写成现成果。
3.2 调研
问卷中呈现出的主要信号如下：
| 观察项 | 调查结果.xlsx 中的结果 | 对产品的启发 |
|---|---|---|
| 独立负责过接口测试 | 25.0% | 需要让基础开发者从需求出发获得可理解、可修改的用例 |
| 完全没有接触过接口测试 | 37.5% | 需要给出测试依据、缺项说明和操作提示 |
| 凭经验列举常见测试场景 | 37.5%（多选） | Agent 可以把经验补充为结构化的覆盖清单 |
| 使用 AI 工具辅助生成 | 33.3%（多选） | 平台需要让 AI 输出可核对、可追踪的结果 |
| 最容易遗漏：异常输入 | 29.2% | 检查空值、错误格式和无效参数 |
| 最容易遗漏：鉴权 / 权限 | 20.8% | 检查登录、缺失凭证和无效凭证 |
| 最容易遗漏：接口间的数据传递 | 20.8% | 支持前一步结果向后续测试传递变量 |
| 变更后需要少量或较多重复修改 | 62.5% | 需要版本、影响分析和待复核状态 |
| 通过“实际运行一遍”判断 AI 用例 | 45.8% | 需要明确的预期依据和执行证据 |
| 整理测试报告至少需要半小时 | 50.0%（其中 45.8% 为半小时至两小时） | 需要保留批次统计和可导出的报告 |
| 只能保留一个辅助功能：生成测试草稿 | 41.7% | 优先实现需求到测试草稿 |
| 只能保留一个辅助功能：人工确认后一键执行 | 29.2% | 执行前必须保留人的确认 |
| 更接受批量预览后修改 | 50.0% | 用例需要支持批量预览和明显问题筛选 |
| 更接受逐条检查并修改 | 25.0% | 保留逐条编辑和人工确认入口 |
3.3 目标用户
| 用户 | 使用场景 | 主要需要 |
|---|---|---|
| Vibe Coding 者和基础开发者 | 快速完成一个项目后，补充系统测试、回归检查和问题定位 | 从需求和功能描述生成测试方案，覆盖功能、异常、边界、鉴权、数据流和接口集成 |
| 课程项目学生 | 在有限时间内验证项目功能并整理交付材料 | 可理解、可修改、能追踪需求的测试用例；失败时能看到证据 |
| 小组组长 | 查看测试进度、失败分布和交付材料 | 测试类型覆盖、批次统计、历史记录和可导出的报告 |
| 教师与助教 | 按公网地址和演示步骤检查项目 | 可复现的操作路径、明确的范围和逐项验收证据 |
3.4 项目价值
TestPilot 关注的是从“这条需求应该测什么”到“这次失败到底说明什么”的完整记录。平台希望做到：
- 每条用例都能追踪到需求点、接口版本和预期依据；
- AI 生成的内容必须经过字段校验和人工确认；
- 执行结果区分 PASS、FAIL、ERROR 和 BLOCKED；
- 失败分析必须引用已发生的证据，证据不足时明确说明无法确定；
- 历史报告引用执行快照，不因当前用例修改而漂移。
通过率只表示本批测试的统计结果，不等同于被测软件的整体质量。AI 分析也只是辅助意见，不直接构成缺陷结论。
3.5 主要测试类型
| 测试类型 | Agent / 平台提供的帮助 | 首版边界 |
|---|---|---|
| 功能测试 | 从需求生成正常、异常和边界场景，关联验收条件 | P0 纳入测试规划、用例管理和可执行样例 |
| 接口测试 | 维护方法、路径、参数、状态码、JSON 字段和耗时断言 | P0 提供最完整的 HTTP JSON 执行链路 |
| 集成与数据流测试 | 组织 setup、test、teardown，传递 token 或其他前置结果 | P0 通过演示服务验证跨接口流程 |
| 鉴权与权限测试 | 检查有效、缺失、过期和无效凭证场景 | 纳入需求澄清、用例生成和接口执行 |
| UI 功能检查 | 根据功能需求生成页面操作步骤、检查项和验收证据清单 | 首版先支持计划和人工检查，自动化执行留作后续适配 |
| 回归测试 | 根据需求或测试对象版本变化标记受影响用例并要求复核 | P0 支持版本追踪和 NEEDS_REVIEW，完整 CI 回归留作后续扩展 |
| 性能与专项测试 | 帮助整理测试目标、指标和准备条件 | 首版不承诺压测执行，避免超出课程项目范围 |
四、需求不明确时，Agent 如何帮助用户把需求说清楚
老师在答辩中强调，真实用户给出的需求文档经常不完整。TestPilot 因此补充一个位于“生成测试用例”之前的需求澄清与完善环节。它不是让模型替用户猜答案，而是让系统把不清楚的地方显式列出来，帮助用户补充成可验证的需求。
4.1 需求澄清的处理原则
- 先识别缺项：检查需求是否缺少对象、触发条件、输入范围、成功条件、异常行为、返回字段、鉴权要求或验收依据。
- 引用原文位置：每个问题都链接到需求文档中的段落或需求编号，用户能看见 Agent 为什么提出这个问题。
- 提出具体问题：问题应能由用户直接回答，例如“成功登录时 HTTP 状态码是多少？”“token 位于响应 JSON 的哪个字段？”“空密码应返回 400 还是 401？”
- 不替用户编造：没有资料时标为 NEEDS_INFO，不自动填入端点、状态码、字段值或业务规则。
- 用户确认后版本化：用户补充内容后，系统保存新的需求版本和变更记录，显示哪些测试草稿受到了影响。
- 澄清结果进入后续链路：只有满足最低可验证条件的需求点，才进入用例生成、静态校验和执行。
4.2 典型例子
用户上传的原始需求只有一句：
“系统支持用户登录，并返回用户信息。”
Agent 不会直接生成一个“登录成功返回 200”的确定结论，而是列出待补充项：
| 缺少的信息 | Agent 提问 | 影响 |
|---|---|---|
| 登录接口 | 登录接口的 HTTP 方法和相对路径是什么？ | 无法绑定接口 |
| 输入字段 | 用户名、密码字段的名称、类型和必填规则是什么？ | 无法构造请求 |
| 成功预期 | 成功时的状态码、响应字段和 token 位置是什么？ | 无法形成可靠断言 |
| 失败预期 | 错误密码、空密码和缺少凭证分别如何响应？ | 无法设计异常用例 |
| 用户信息 | “返回用户信息”需要检查哪些字段？ | 无法确定字段断言 |
| 性能约定 | 是否有单次请求耗时上限？ | 无法确定耗时断言 |
用户补充“POST /auth/login 成功返回 200，token 在 token 字段且必须为非空字符串；错误密码返回 401 和 INVALID_CREDENTIALS；登录后使用 Bearer token 调用 GET /me，要求 user.id 等于演示用户编号”后，系统才把需求点升级为可验证版本，并生成对应的 setup 与 test 步骤。
4.3 这项能力怎样体现在软件中
- 需求页：显示原文、需求编号、缺项列表、问题状态和用户补充内容。
- 用例编辑页：显示每条用例引用了哪些需求点，以及是否仍有待补充字段。
- 执行前预检：存在未解决的需求缺项、接口绑定、变量或断言问题时，整批不启动，并逐项返回原因。
- 版本追踪：需求或接口发生变化时，关联用例进入 NEEDS_REVIEW，旧报告仍保留原来的快照。
- 人工责任边界：用户确认业务含义和可执行版本，Agent 不能代替用户拍板。
因此，Agent 的作用不仅是“把明确的需求变成测试用例”，还包括“帮助用户把模糊的需求补成可讨论、可验证、可执行的需求”。
五、领域 Agent 的任务与定制方法
5.1 Agent 的两项核心任务与一个前置环节
| 环节 | 输入 | 输出 | 边界 |
|---|---|---|---|
| 需求澄清与测试规划（T1 前置） | 需求原文、功能描述、已有接口或测试资料 | 缺项清单、澄清问题、测试类型建议、覆盖检查项、原文引用 | 不猜测业务规则；问题未解决时进入 NEEDS_INFO |
| 多类型测试用例生成（T1） | 已确认需求点、测试对象资料、领域测试知识 | 功能、异常、边界、鉴权、数据流和接口集成等测试草稿 | 没有执行依据时只生成测试意图或检查清单，不能直接执行 |
| 失败分析（T2） | 脱敏请求、响应、检查结果、断言差异、错误阶段、已确认预期 | 五类归因、证据引用、可能原因、建议和待补证据 | 证据不足时可以“无法确定”；不修改原断言 |
T2 的五类归因包括：疑似接口缺陷、环境问题、用例问题、数据问题和证据不足。
5.2 领域知识来源
| 知识来源 | 使用方式 | 状态 |
|---|---|---|
| ISTQB CTFL v4.0.1 第 4 章等测试设计资料 | 整理等价类、边界值等方法，转成生成检查项 | 条目需要在开发阶段编写并评审 |
| 团队软件测试检查清单 | 整理功能、接口、鉴权、参数、数据流、错误处理、超时和清理规则 | 需要团队评审 |
| 用户确认的需求和接口资料 | 提供业务状态码、错误码、字段约束和取值范围 | 随项目录入，优先级高于模型常识 |
| 真实执行记录 | 为失败分析提供脱敏报文、断言差异和错误阶段 | 只使用已经发生的证据 |
每个知识条目保留来源标识、标题、版本或日期、章节或链接和团队摘要。提示词、知识条目和输出结构分别版本化，平台不把“使用提示词和知识注入”表述为已经完成模型训练或微调。
5.3 四层定制与两道人把关
- 领域提示词：固定角色、测试判定口径和输出纪律，要求先覆盖正常、异常和边界。
- 少量知识注入：只注入与当前需求有关的检查项，避免把无关资料塞进上下文。
- 固定输出结构：以 JSON Schema 约束需求引用、测试意图、步骤、断言和缺项清单。
- 后端静态校验：检查接口归属、路径模板、变量可获得性、JSONPath、断言类型和版本一致性。
- 人工确认：用户确认“测试意图、请求内容和预期依据”后，才形成可执行版本。
- 执行前预检：整批重新检查，缺接口、缺断言、变量未定义或版本过期时整批不启动。
首版不依赖独立向量数据库、模型微调或完整多智能体编排。先保证“需求澄清—用例生成—确认—执行—证据—报告”这条链路可验证。
5.4 Agent 的三条红线
- 不决定是否发请求，是否执行必须由用户点击确认；
- 不修改断言来把失败变成通过；
- 不使用实际响应反向推断“正确答案”。
这三条约束由权限、状态机、确定性执行器和版本快照共同保证。
六、软件整体流程
6.1 从需求到报告
- 用户创建项目并上传 UTF-8 编码的 Markdown 或 TXT 需求、功能描述和测试相关资料。
- 系统解析文本、生成需求编号并保留原文位置。
- Agent 检查需求完整性，建议需要覆盖的测试类型和检查项；用户补充并确认需求版本。
- 用户补充测试对象资料。对于 API 或集成场景，维护方法、相对路径、参数、鉴权方式、响应约定和允许目标；对于页面或其他功能，维护操作步骤和验收条件。
- 用户选择需求点生成多类型测试草稿。信息不足的草稿进入 NEEDS_INFO，不能直接执行。
- 用户补齐测试步骤、变量、断言或人工检查项，系统静态校验后进入 READY。
- 用户确认版本，状态变为 CONFIRMED。
- 用户选择可执行用例或人工检查清单。API 和集成用例单批不超过 20 条，查看请求与数据修改提示后点击执行；人工检查项按清单记录证据。
- 后端对可执行用例再次预检，通过后冻结需求、测试对象、用例和版本快照，创建 run_id 并顺序执行。
- 系统记录脱敏后的请求、响应、检查结果、耗时、断言和错误阶段。
- 先展示确定性结果，再按用户操作生成 AI 失败分析；模型不可用时仍可以查看结果并导出 HTML 报告。
- 用户修改用例或系统后重新运行，创建新的批次，历史批次保持不变。
6.2 测试状态与结果
用例状态：
- DRAFT：草稿或编辑中；
- NEEDS_INFO：缺项或校验失败；
- READY：校验通过，等待确认；
- CONFIRMED：已确认，可执行；
- NEEDS_REVIEW：关联需求或接口版本发生变化，等待复核。
单条用例结果：
- PASS：必要步骤与断言均通过，清理成功或无需清理；
- FAIL：收到响应，但至少一项业务断言不满足；
- ERROR：超时、执行器异常、提取失败或清理失败；
- BLOCKED：准备步骤失败导致主测试未开始，或批次中断导致未开始。
批次状态：
- QUEUED：已创建，等待执行；
- RUNNING：正在执行；
- COMPLETED：处理结束，不表示全部用例通过；
- INTERRUPTED：进程重启或中断后保留已知结果。
分母包含 FAIL、ERROR 和 BLOCKED。四类终态数量之和必须等于选中用例数。
七、代表性场景：接口与集成测试
接口和集成测试是平台首版最完整的自动执行示例。其他测试类型先通过测试规划、用例管理、人工确认和证据清单接入，后续再增加对应执行适配器。以下以 TC-DEMO-01 为例：
| 顺序 | 阶段与接口 | 参数或变量 | 断言 / 提取 |
|---|---|---|---|
| 1 | setup：POST /auth/login | 用户名和密码来自秘密环境变量 | 状态码 200；token 字段为非空字符串；提取为 steps.login.token |
| 2 | test：GET /me | Authorization: Bearer steps.login.token | 状态码 200；user.id 等于演示用户编号；耗时不超过 3000ms |
如果登录准备步骤没有返回 token，系统将该用例标记为 BLOCKED，并继续执行其他独立用例；不会把“没有成功测到 /me”误判为“用户信息接口有缺陷”。
对于 GET /items?page_size=n，系统还要覆盖范围内、边界上和范围外的输入，例如 0、1、100、101。对于错误密码、空密码、缺少 Bearer token 和无效 Bearer token，负向用例保存明确的 negative_intent 和预期错误响应。
八、首版功能范围
8.1 P0 功能
| 编号 | 功能 | 对应验收 |
|---|---|---|
| FR-01 | 项目创建、编辑、数据归属和跨项目访问校验 | AC-01 |
| FR-02 | 需求上传、解析、条目编辑和来源追踪 | AC-02 |
| FR-03 | 测试对象与环境配置，首版优先支持接口和集成场景 | AC-03 |
| FR-04 | 需求澄清、测试类型规划、AI 测试草稿和可执行字段候选 | AC-04 |
| FR-05 | 多类型用例编辑、测试对象绑定、静态校验、确认和失效复核 | AC-05 |
| FR-06 | 测试准备、变量提取、请求构造、人工检查和清理 | AC-06 |
| FR-07 | 执行批次、顺序执行、进度和中断处理 | AC-07 |
| FR-08 | 确定性断言、检查结果状态和执行证据 | AC-08 |
| FR-09 | 带证据的 AI 失败分析和人工反馈 | AC-09 |
| FR-10 | 批次统计、历史记录和 HTML 报告导出 | AC-10 |
8.2 首版暂不承诺
以下内容暂列为 P1 或明确不做：
- Excel 用例导出；
- OpenAPI 自动导入；
- Word 和 PDF 导入；
- 自动增量用例；
- 历史趋势图和 PDF 报告；
- 扫描件 OCR；
- UI 自动化执行；
- 性能压测和长时间稳定性测试；
- 移动端专项测试；
- 任意 Python / JavaScript 脚本执行；
- 任意流程编排；
- 多用户权限体系；
- 多智能体编排；
- 硬件联动。
首版先实现跨类型的测试规划、需求追踪、用例管理和人工确认，并把 HTTP JSON 接口及集成场景做成可执行链路。UI、性能等类型先支持测试计划、检查清单和证据记录，后续再增加自动化适配。API 和集成用例单批最多 20 条，每条最多 5 个 HTTP 步骤。
九、前后端设计与技术可行性
Vue 3 + Element Plus 前端
│ REST API / JSON
FastAPI 后端
├─ 项目与需求服务
├─ Agent 适配层
├─ 用例版本与静态校验
├─ HTTP / 集成执行器（httpx）
└─ 统计与 HTML 报告
│
SQLite 数据库
└─ 项目、需求、接口、用例版本、批次、步骤结果、分析和报告
十、典型功能验收
| 编号 | 验收重点 | 通过标准 |
|---|---|---|
| AC-01 | 项目归属 | 两个项目可以分别编辑，跨项目绑定需求或接口时后端拒绝 |
| AC-02 | 需求解析 | Markdown 和 TXT 样例均可解析、编号、人工修改和定位原文；不支持格式或超限输入有明确错误 |
| AC-03 | 测试对象与环境 | 可保存带版本的接口、集成对象或人工检查清单；秘密变量回读遮蔽；未允许目标被拒绝 |
| AC-04 | 需求澄清、测试规划与生成 | 对固定样例识别功能、异常、边界、鉴权和数据流检查项；缺少资料时列出问题并保持 NEEDS_INFO，不编造测试对象或预期 |
| AC-05 | 确认与复核 | 缺接口、缺断言、变量未定义或未确认时不能启动；编辑或关联版本变化会触发复核 |
| AC-06 | 测试准备、数据流与清理 | 登录提取 token 后能构造受保护请求；准备失败阻塞主测试；其他测试类型可记录前置条件和检查证据；临时资源在主测试失败后仍按条件清理 |
| AC-07 | 批次执行 | 返回 run_id 后可轮询和刷新；同一时间第二批被拒绝；中断后不重复发请求 |
| AC-08 | 判定与证据 | 状态码、JSON 字段和耗时断言均有满足与不满足样例；人工检查项有明确通过条件和证据；负向预期的 401 可以判为 PASS |
| AC-09 | 失败分析 | 分析引用真实证据；证据不足时可以“无法确定”；采纳和驳回有记录；模型不可用不影响结果和报告 |
| AC-10 | 报告 | 各测试类型、结果状态和证据均可追踪；可执行批次的四类结果数量之和等于用例数；历史报告不因当前用例修改而变化 |
10.1 需求澄清专项验收
为落实老师强调的内容，增加一组可直接检查的需求澄清场景：
- 给系统一段缺少接口路径、成功状态码和错误行为的需求。
- 检查 Agent 是否指出缺项，并引用对应原文位置。
- 检查系统是否把需求点标记为 NEEDS_INFO，阻止生成可执行确认版本。
- 用户补充信息后，检查系统是否生成新版本、记录变更，并允许重新生成草稿。
- 检查生成的用例是否能回指补充后的需求和预期依据。
判定依据是“问题被指出、依据可回溯、补充后可继续、补充前不能假装可执行”，而不是问题数量越多越好。
十一、领域定制效果验证（以接口与集成场景为第一组样例）
11.1 对照设计
- 对照组：普通任务提示，只提供需求和接口资料。
- 实验组：加入领域提示、相关测试知识、固定输出结构和校验反馈。
- 控制变量：同一模型版本、同一采样参数、同一输入资料、同样的输出结构和最多 20 条用例。
- 重复方式：两组各独立生成 3 轮，保留失败轮次、调用次数、耗时和人工改动。
- 评审方式：两组最终都经过同一套预检和人工核对，由未参与该模块实现的成员或评审者检查。
固定样例先使用第七节的登录、/me 和分页参数需求，后续再增加页面功能和其他测试类型的样例。评审不根据结果删掉失败轮次，也不把人工修订后的结果当作首次输出结果。
11.2 指标与目标
| 指标 | 计算方式 | 首版拟定目标 |
|---|---|---|
| 有效需求覆盖率 | 至少有一条预期正确且可追踪用例的需求点数 / 需求点总数 | 三轮平均不低于 90% |
| 直接可执行率 | 无需修改业务参数或断言即可通过共同预检、发出请求且断言可求值的用例数 / 生成用例总数 | 三轮平均不低于 80% |
| 结构规范率 | 结构和字段合法的用例数 / 生成用例总数 | 最终接受入库的草稿 100% 通过结构校验，同时报告首次输出规范率 |
| 方法覆盖率 | 正确覆盖的检查项数 / 冻结检查项总数 | 三轮平均不低于 80%，包含正常、异常和边界 |
实验组除达到绝对目标外，四项指标中至少两项比对照组高 5 个百分点，其他指标不能下降超过 5 个百分点。如果没有达到，应如实记录“未验证提升”，再调整知识、提示词或校验规则。
浙公网安备 33010602011771号