源 · 管住文档
NexSpec Hub
式样书与文档主数据中心
NexTest 通过固定版本引用访问式样书主数据，版本与源文件都归 Hub 管。
首页 产品 NexTest Studio
Product 03 · 测
NexTest Studio
车载软件 AI 测试闭环平台
从式样书到测试用例，走一条可追溯、可复用、可评审的自动化链路。
10
协同 Agent
≥95%
追溯覆盖率目标
5
可度量质量指标
Problem → Approach
测试工时花在哪，得说清楚
大量时间不在设计测试本身，而在读文档、对需求、找旧用例、追变更。这些环节可以交给系统。
| 过去的做法 | NexTest Studio 的做法 |
|---|---|
| 对着 Word、Excel、PDF、PPT 式样书人工找需求点 | 多 Agent 解析文档结构，抽出可测试的原子要件并给出置信度 |
| 测试用例靠工程师凭经验写，质量取决于个人 | 结合测试观点库、测试因子库与不具合知识库生成，覆盖正常系、异常系与边界值 |
| 版本一改，回归范围靠开会讨论 | 版本差分自动列出受影响用例与建议回归范围 |
| 需求到用例的对应，存在某个人的记忆里 | 建立 Document → Requirement → AtomicRequirement → TestCase → Defect 全链路追溯 |
| AI 结论对不对，没人敢签字 | 每条输出可追溯到文档版本、章节、页码、段落与知识来源，且必须经过人工确认 |
Capabilities
十个 Agent，各管一段
AGENT 01 — 02
文档解析与需求理解
识别章节、表格、段落与功能描述，保留原文位置；再把"功能、条件、动作、结果、约束、接口、异常"从自然语言里还原出来。文档结构解析准确率目标 ≥80%。
AGENT 03 — 04
要件分解与规范校验
把需求拆成最小可测试的原子要件，逐条标注置信度；规范校验 Agent 标出模糊表达、冲突条目、不可测试项与缺失条件。原子要件人工可接受率目标 ≥70%。
AGENT 05
知识检索
为每个要件检索适用的测试观点（正常系、异常系、边界值、状态迁移、通信异常、诊断、HMI、电源模式等）与测试因子（车速、档位、电源、门状态、信号有效性、环境条件等）。
AGENT 06
测试设计
用检索到的观点与因子组合出测试场景、组合条件与边界点 —— 而不是按字段机械填空。历史不具合知识库同时参与，规避已发生过的漏测。
AGENT 07
测试式样书生成
按企业模板输出测试目的、前置条件、测试步骤、期待结果与判定标准，并附自动化适配性、优先级、风险等级与关联历史缺陷。
AGENT 08 — 10
变更分析、追溯建模与评审
版本差分识别新增、删除、修改、阈值与信号变化，算出受影响用例和建议回归范围；写入图谱关系与覆盖矩阵；最后汇总质量问题清单，生成人工确认任务。
Interface
版本一改，要动哪些用例
变更影响分析把"新增 / 修改 / 删除"逐条列出来，并直接给出每一条波及的测试用例数与回归范围。开会讨论之前，先有张表。
N
当前模块 · 变更与回归
搜索模块、Case、任务…⌘K
中文
千工
变更影响分析NX-BCM-0141 车身控制模块 · v2.4 → v2.5
导出影响清单
通过正式修订加入计划
11受影响用例
8建议回归
6可自动生成
2需人工确认
修改
防夹力门限 120 N → 100 N，判定标准同步变更《车窗防夹功能 详细式样》第 3.2 条
6 条用例
新增
回退行程不小于 50 mm 的判定项《车窗防夹功能 详细式样》第 3.3 条
4 条用例
新增
传感器遮挡场景下的降级提示条件《车窗防夹功能 详细式样》第 4.1 条
3 条用例
修改
信号 BCM_WindowPos 的有效性判定范围《前向碰撞预警 接口式样》信号表第 12 行
2 条用例
删除
旧版对 120 N 门限的兼容性备注《车窗防夹功能 详细式样》第 6.4 条
0 条用例
每条变更可追回原文段落受影响用例 11建议回归 8
变更不是问题，不知道波及哪里才是
一次门限调整看上去只改了一个数字，实际会牵动判定标准、边界用例、信号有效性判定和历史缺陷的回归项。这些关系如果只存在人的记忆里，就会漏。
- 每条变更都落到用例级别。不是"受影响范围较大"这种结论。
- 建议回归可以直接执行。给出的是一条条用例，不是一段描述。
- 分析结果留下版本记录。谁在什么时候确认了这份影响清单，可查。
Workflow
五步跑完一个闭环
01
导入式样书
上传 Word、Excel、PDF、PPT 文档，保留版本、来源、负责人与发布日期。
02
抽出原子要件
识别功能、条件、动作、结果、约束、接口与异常描述，拆成可测试的原子要件，标注置信度与评审状态。
03
匹配测试观点与因子
为每个要件匹配适用的测试观点（正常系、异常系、边界值、状态迁移、通信异常、诊断、HMI、电源模式等）与测试因子（车速、档位、电源、门状态、信号有效性、环境条件等）。
04
生成测试式样书
按模板产出完整测试式样书内容，落库时可人工编辑、确认或驳回。
05
追溯与变更影响
写入追溯图谱与覆盖矩阵；版本更新后输出受影响用例与建议回归范围。
Controllability
AI 生成的内容，必须能签得下字
在汽车研发里，"AI 说是这样"不能作为依据。所以三条底线写进产品，不做开关。
可追溯到原文
每条 AI 输出都绑定文档版本、章节、页码、段落与知识来源，点得回原文。
可人工处置
自动生成的内容一律支持人工确认、编辑、驳回，并留下版本记录。
可度量质量
解析准确率、要件可接受率、用例复用率、追溯覆盖率、变更召回率，全部可测。
知识库是可运营的，不是一次性灌进去的。
测试观点、测试因子与不具合知识库支持导入、审核、禁用、版本化与效果评估 —— 质量靠运营，不靠玄学。
Targets
我们按这几个数字验收
以下为 MVP 阶段的量化目标，可以在你的数据上复核。
| 指标 | 目标 | 说明 |
|---|---|---|
| 文档结构解析准确率 | ≥ 80% | 章节、表格、段落、功能描述的识别准确度 |
| 原子要件抽取人工可接受率 | ≥ 70% | 人工评审后直接接受或轻修改的占比 |
| 测试用例可直接复用比例 | ≥ 50% | 无需修改或仅需轻修改即可进用例库 |
| 需求到测试追溯覆盖率 | ≥ 95% | 核心功能需求均可追到对应测试用例 |
| 版本变更影响分析召回率 | ≥ 80% | 受影响用例的召回比例 |
Who It's For
五类人，五个关心的点
车企测试负责人
关心项目测试覆盖率、变更影响、质量风险与交付效率。
Tier1 系统测试工程师
关心式样书解析、测试要件抽出与测试式样书生成。
需求分析工程师
关心需求一致性、可测试性、版本差分与原文追溯。
测试自动化工程师
关心测试用例结构化、信号映射与自动化脚本草案。
质量与项目管理人员
关心缺陷回溯、风险热力图、评审闭环与审计记录。
Request a Demo
带一份日文式样书来，看它拆要件
现场演示解析、原子要件抽取、测试式样书生成与追溯图谱写入。