mirror of
https://github.com/azaion/detections-semantic.git
synced 2026-04-23 02:06:37 +00:00
Oleksandr Bezdieniezhnykh
98 lines
2.5 KiB
Markdown
98 lines
2.5 KiB
Markdown
# E2E Non-Functional Tests Template
|
|
|
|
Save as `PLANS_DIR/integration_tests/non_functional_tests.md`.
|
|
|
|
---
|
|
|
|
```markdown
|
|
# E2E Non-Functional Tests
|
|
|
|
## 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]
|
|
|
|
---
|
|
|
|
## Resilience Tests
|
|
|
|
### NFT-RES-01: [Test Name]
|
|
|
|
**Summary**: [What failure/recovery scenario this validates]
|
|
**Traces to**: AC-[ID]
|
|
|
|
**Preconditions**:
|
|
- [System state before fault injection]
|
|
|
|
**Fault injection**:
|
|
- [What fault is introduced — process kill, network partition, invalid input sequence, etc.]
|
|
|
|
**Steps**:
|
|
|
|
| Step | Action | Expected Behavior |
|
|
|------|--------|------------------|
|
|
| 1 | [inject fault] | [system behavior during fault] |
|
|
| 2 | [observe recovery] | [system behavior after recovery] |
|
|
|
|
**Pass criteria**: [recovery time, data integrity, continued operation]
|
|
|
|
---
|
|
|
|
## Security Tests
|
|
|
|
### NFT-SEC-01: [Test Name]
|
|
|
|
**Summary**: [What security property this validates]
|
|
**Traces to**: AC-[ID], RESTRICT-[ID]
|
|
|
|
**Steps**:
|
|
|
|
| Step | Consumer Action | Expected Response |
|
|
|------|----------------|------------------|
|
|
| 1 | [attempt unauthorized access / injection / etc.] | [rejection / no data leak / etc.] |
|
|
|
|
**Pass criteria**: [specific security outcome]
|
|
|
|
---
|
|
|
|
## Resource Limit Tests
|
|
|
|
### NFT-RES-LIM-01: [Test Name]
|
|
|
|
**Summary**: [What resource constraint this validates]
|
|
**Traces to**: AC-[ID], RESTRICT-[ID]
|
|
|
|
**Preconditions**:
|
|
- [System running under specified constraints]
|
|
|
|
**Monitoring**:
|
|
- [What resources to monitor — memory, CPU, GPU, disk, temperature]
|
|
|
|
**Duration**: [how long to run]
|
|
**Pass criteria**: [resource stays within limit — e.g., memory < 8GB throughout]
|
|
```
|
|
|
|
---
|
|
|
|
## Guidance Notes
|
|
|
|
- Performance tests should run long enough to capture steady-state behavior, not just cold-start.
|
|
- Resilience tests must define both the fault and the expected recovery — not just "system should recover."
|
|
- Security tests at E2E level focus on black-box attacks (unauthorized API calls, malformed input), not code-level vulnerabilities.
|
|
- Resource limit tests must specify monitoring duration — short bursts don't prove sustained compliance.
|