What it does
Exercises the system while running, captures baseline and timed resource snapshots, trends each metric against an explicit leak rule, and isolates a suspected root cause.
When to use it
When hunting faults that only surface at runtime under sustained load, not statically.
Prerequisites
qa.config.yml; paths.*; tooling.* (a stack-appropriate profiler); gates.performance/risk_areas for the load profile; a production-like environment for valid results.
Output
ISO/IEC/IEEE 29119-3 Test Execution Log extended with profiling/leak evidence -> paths.docs_dir/DYNAMIC-ANALYSIS-<scope>.md.
Mechanics
How it works
- Guard config, resolve the target flow/endpoint, and validate a profiler exists for the detected stack
- Define the scenario: load profile (config-sourced), duration (>=8h or >=500 iterations), baseline metrics
- Instrument the profiler and capture/validate the t=0 baseline snapshot
- Run the duration, capturing snapshots at 25/50/75/100% (5 datapoints per metric)
- Trend each resource and apply the >5%-growth-without-release leak rule with severity
- Pass the 9-point quality gate, then write the report; route confirmed leaks to /qa:triage
Why it works
The theory behind it
Dynamic analysis (CTAL-TTA) — finds faults invisible to static analysis because they only manifest during execution. Complements static-analysis (no execution) and perf-test (workload-driven). A specialist/Advanced-track topic, not CTFL Foundation.
CTAL-TTA (dynamic analysis)
Example
See it in use
> /qa:dynamic-analysis "cart session handling"✓ Correct when It targets runtime leaks/handle-exhaustion/degradation over time, not static defects.
Related commands
Used by