Source · govern documents
NexSpec Hub
Specification and document master data hub
NexTest accesses specification master data through fixed-version references, while versions and source files are governed by Hub.
Home Products NexTest Studio
Product 03 · Test
NexTest Studio
AI test closed-loop platform for automotive software
From specification to test case, along one traceable, reusable and reviewable automation chain.
10
Collaborating Agents
≥95%
Traceability coverage target
5
Measurable quality metrics
Problem → Approach
Where testing hours go needs to be made clear
Much of the time goes not into designing tests but into reading documents, matching requirements, finding old test cases and chasing changes. These steps can be handed to the system.
| The old way | The NexTest Studio approach |
|---|---|
| Hunting for requirement points by hand in Word, Excel, PDF and PPT specifications | Multiple Agents parse the document structure, extract testable atomic requirements and assign confidence |
| Test cases are written by engineers on experience, so quality depends on the individual | Generated from the test viewpoint library, test factor library and defect knowledge base, covering normal, abnormal and boundary-value cases |
| When a version changes, the regression scope gets decided in a meeting | Version diffs automatically list affected test cases and the recommended regression scope |
| The link from requirement to test case sits in one person's memory | Builds full-chain traceability for Document → Requirement → AtomicRequirement → TestCase → Defect |
| No one dares sign off on whether the AI's conclusion is right | Every output is traceable to the document version, section, page, paragraph and knowledge source, and must pass human confirmation |
Capabilities
Ten Agents, each owning a stage
AGENT 01 — 02
Document parsing & requirement understanding
Identifies sections, tables, paragraphs and function descriptions while preserving their source position, then reconstructs "function, condition, action, result, constraint, interface, exception" from natural language. Target document structure parsing accuracy ≥80%.
AGENT 03 — 04
Requirement decomposition & rule checking
Breaks requirements into the smallest testable atomic requirements, tagging confidence for each; the rule-checking Agent flags ambiguous wording, conflicting items, untestable items and missing conditions. Target human acceptance rate for atomic requirements ≥70%.
AGENT 05
Knowledge retrieval
For each requirement, retrieves applicable test viewpoints (normal, abnormal, boundary values, state transitions, communication faults, diagnostics, HMI, power modes, etc.) and test factors (vehicle speed, gear, power, door state, signal validity, environmental conditions, etc.).
AGENT 06
Test design
Combines retrieved viewpoints and factors into test scenarios, combination conditions and boundary points — rather than mechanically filling in fields. The historical defect knowledge base is consulted too, to avoid repeating past test escapes.
AGENT 07
Test specification generation
Outputs the test purpose, preconditions, test steps, expected results and pass criteria from the corporate template, along with automation suitability, priority, risk level and related historical defects.
AGENT 08 — 10
Change analysis, traceability modeling & review
Version diffs identify additions, deletions, modifications, and threshold and signal changes, then compute the affected test cases and recommended regression scope; the results are written into graph relationships and the coverage matrix; finally, a quality issue list is compiled and manual confirmation tasks are generated.
Interface
When a version changes, which test cases are affected
Change impact analysis lists added / modified / deleted items one by one, and directly gives the number of affected test cases and the regression scope for each. Before you meet, there is a table.
N
Current module · Change & Regression
Search modules, Cases, tasks…⌘K
Chinese
千工
Change ImpactNX-BCM-0141 Body control module · v2.4 → v2.5
Export impact list
Add to plan as a formal revision
11Affected test cases
8Recommended regression
6Auto-generatable
2Needs manual confirmation
Modified
Anti-pinch force threshold 120 N → 100 N, with the pass criteria updated accordingly"Window anti-pinch function detailed specification" Clause 3.2
6 test cases
Added
Pass criterion for a return travel of at least 50 mm"Window anti-pinch function detailed specification" Clause 3.3
4 test cases
Added
Degraded-mode alert conditions under sensor obstruction"Window anti-pinch function detailed specification" Clause 4.1
3 test cases
Modified
Validity range for the BCM_WindowPos signal"Forward collision warning interface specification" signal table row 12
2 test cases
Deleted
Compatibility note for the legacy 120 N threshold"Window anti-pinch function detailed specification" Clause 6.4
0 test cases
Every change traces back to its source passageAffected test cases 11Recommended regression 8
The change is not the problem — not knowing what it touches is
A threshold adjustment looks like changing a single number, but it actually ripples into pass criteria, boundary test cases, signal validity checks and regression items for historical defects. If those relationships live only in people's memory, something will be missed.
- Every change lands at the test case level. Not a conclusion like "the impact scope is fairly large".
- Recommended regressions can be executed directly. It hands you individual test cases, not a paragraph of description.
- Analysis results leave a version record. Who confirmed this impact list and when is on record.
Workflow
Five steps to complete one closed loop
01
Import specification
Upload Word, Excel, PDF and PPT documents, retaining version, source, owner and release date.
02
Extract atomic requirements
Identify function, condition, action, result, constraint, interface and exception descriptions, break them into testable atomic requirements, and tag confidence and review status.
03
Match test viewpoints and factors
Match each requirement with applicable test viewpoints (normal, abnormal, boundary values, state transitions, communication faults, diagnostics, HMI, power modes, etc.) and test factors (vehicle speed, gear, power, door state, signal validity, environmental conditions, etc.).
04
Generate test specification
Produce complete test specification content from templates, which can be manually edited, confirmed or rejected when saved to the repository.
05
Traceability & change impact
Write to the traceability graph and coverage matrix; after a version update, output the affected test cases and recommended regression scope.
Controllability
AI-generated content must be something you can sign off on
In automotive R&D, "the AI says so" is not evidence. So three bottom lines are built into the product, not left as toggles.
Traceable to the source
Every AI output is bound to the document version, section, page, paragraph and knowledge source, and clicks back to the original text.
Human-controllable
All automatically generated content supports human confirmation, editing and rejection, and leaves a version record.
Measurable quality
Parsing accuracy, requirement acceptance rate, test case reuse rate, traceability coverage and change recall are all measurable.
A knowledge base is something you operate continuously, not load once and forget. Test viewpoints, test factors and the defect knowledge base support import, review, disabling, versioning and effectiveness evaluation — quality comes from operations, not luck.
Targets
We accept on these numbers
The following are quantitative targets for the MVP stage, verifiable on your own data.
| Metric | Target | Notes |
|---|---|---|
| Document structure parsing accuracy | ≥ 80% | Accuracy in identifying sections, tables, paragraphs and function descriptions |
| Human acceptance rate for atomic requirement extraction | ≥ 70% | Share accepted as-is or with only minor edits after human review |
| Share of test cases directly reusable | ≥ 50% | Can enter the test case library with no or only minor edits |
| Requirement-to-test traceability coverage | ≥ 95% | Every core functional requirement traces to its corresponding test case |
| Version change impact analysis recall | ≥ 80% | Recall rate for affected test cases |
Who It's For
Five roles, five concerns
OEM test leads
Focused on project test coverage, change impact, quality risk and delivery efficiency.
Tier1 system test engineers
Focused on specification parsing, test requirement extraction and test specification generation.
Requirements analysts
Focused on requirement consistency, testability, version diffs and source traceability.
Test automation engineers
Focused on test case structuring, signal mapping and automation script drafts.
Quality and project managers
Focused on defect tracing, risk heat maps, closed review loops and audit records.
Continue
The first two links in the chain
Know · make knowledge usable
Nex Knowledge Base
On-premises Knowledge search and Q&A
Turns historical documents and standards into searchable, queryable intranet knowledge that feeds test design.
All · the full picture
Back to home
How the product line connects into one chain
Document master data → internal knowledge → test closed loop, with one single fact carried all the way through.
Request a Demo
Bring a Japanese specification and watch it break down the requirements
Live demo of parsing, atomic requirement extraction, test specification generation and traceability graph writing.