Files
gps-denied-onboard/.cursor/skills/plan/templates/performance-tests.md
T
Oleksandr Bezdieniezhnykh 1f634c2604
ci/woodpecker/push/02-build-push Pipeline failed
Update demo replay validation and testing documentation
- Modified the autodev state to reflect the current testing phase and details of the new `jetson-e2e` tests.
- Enhanced the "How to Test" documentation to provide clearer instructions on the demo replay validation process, including video and tlog alignment steps.
- Updated architectural documentation to include the new demo replay operator flow and its dependencies.
- Documented the removal of deprecated auto-sync features and clarified the operator-facing UI for replay validation.
- Added new entries in the dependencies table for upcoming tasks related to the demo replay flow.

These changes improve clarity and usability for operators and developers working with the demo replay system.
2026-06-20 11:24:43 +03:00

944 B

Performance Tests Template

Save as DOCUMENT_DIR/tests/performance-tests.md.


# Performance Tests

### NFT-PERF-01: [Test Name]

**Summary**: [What performance characteristic this validates]
**Traces to**: AC-[ID]
**Metric**: [what is measured — latency, throughput, frame rate, etc.]

**Preconditions**:
- [System state, load profile, data volume]

**Steps**:

| Step | Consumer Action | Measurement |
|------|----------------|-------------|
| 1 | [action] | [what to measure and how] |

**Pass criteria**: [specific threshold — e.g., p95 latency < 400ms]
**Duration**: [how long the test runs]

Guidance Notes

  • Performance tests should run long enough to capture steady-state behavior, not just cold-start.
  • Define clear pass/fail thresholds with specific metrics (p50, p95, p99 latency, throughput, etc.).
  • Include warm-up preconditions to separate initialization cost from steady-state performance.