43 lines
2.2 KiB
Markdown
43 lines
2.2 KiB
Markdown
# Test Plan & Strategy
|
|
|
|
## Goals and Visibility Metrics
|
|
|
|
- Correctness: 100\% Pass Rate for Unit and Component Tests.
|
|
- Performance: Go backend event processing (with `oha`)
|
|
- Latency: average latency < 500ms
|
|
- Reliability: success rate > 99\%.
|
|
- Coverage: Minimum 80\% branch coverage.
|
|
|
|
## Integration Strategy: "Sandwich" Approach
|
|
|
|
Given the polyglot architecture, a "sandwich" integration strategy was adopted:
|
|
|
|
- **Bottom-Up:** Rigorous Unit Testing of the Go computation engine and Java Service logic using `go test` and `JUnit`.
|
|
- **Top-Down:** End-to-End (E2E) validation using **Bruno** and Manual UI testing.
|
|
- **Meeting Point:** Integration testing at the REST API layer using Spring Slice Tests.
|
|
|
|
## Critical Path & Dependencies
|
|
|
|
The **Critical Path** for testing was identified as:
|
|
|
|
1. **Core Algo (Go):** Must be verified first as all upstream services depend on it.
|
|
2. **API Contract:** Java-Go interoperability must be stable before UI development.
|
|
3. **UI Logic:** Svelte validation is dependent on stable backend APIs.
|
|
|
|
|
|
## Risk Management (ODC-Based Analysis)
|
|
|
|
Risks are categorized using **ODC (Orthogonal Defect Classification)** principles to predict potential defect impacts and assign targeted mitigations.
|
|
|
|
| Risk ID | Risk Description | ODC Impact Category | Mitigation Strategy |
|
|
| :--- | :--- | :--- | :--- |
|
|
| **R-DATA** | Java/Go data models diverge, causing serialization failures. | **Reliability** | Implement strict JSON Schema validation (Shift-Left) in CI. |
|
|
| **R-EXT** | Drone Info API downtime or latency. | **Capability** / **Stability** | Invest in **Mockito Stubs** to simulate outages and verify fallback logic. |
|
|
| **R-PERF** | Latency: Go backend exceeds 500ms processing budget. | **Performance** | Run `oha` benchmarks on every commit to detect regression. |
|
|
| **R-SEC** | Unauthenticated Access: API endpoints exposed without tokens. | **Security** | Negative Testing: Automated security suites in Bruno to verify 401/403 responses. |
|
|
|
|
## Instrumentation Plan
|
|
|
|
* **Scaffolding:** Use Test Doubles (Stubs/Mocks) for all external HTTP calls.
|
|
* **Observability:** Implement Spring Actuator (`/actuator/health`) for black-box liveness checks.
|
|
* **Logging:** Use structured logging for traceability across services.
|