{"id":"abf54526-8fe7-4694-835a-32683c386496","slug":"performance-test-design","kind":"skill","name":"performance-test-design","summary":"Agent skill that designs performance test cases from system documentation — tool-agnostic, ISTQB CT-PT aligned, from Operational Profile discovery to implementer-ready Test Case Specifications","owner":"phatnguyen975","repoUrl":"https://github.com/phatnguyen975/performance-test-design","license":"MIT","licenseTier":"permissive","trust":"community","stars":0,"match":null,"fewStars":true,"format":"skill","createdAt":"2026-07-10T13:26:10.000Z","addedAt":"2026-10-21T10:17:57.865Z","logoUrl":"https://avatars.githubusercontent.com/u/234490267?u=55c5d92471cab63f430d172dfb76504921be0f49&v=4","linkOnly":false,"collection":null,"skillPath":null,"categories":["developer-tools","design-media","writing"],"tags":["antigravity-skills","opencode-skills","performace-testing","test-design"],"runtime":"binary","local":true,"cloudCapable":false,"cloudCapability":"unknown","cloudReadyOnPlatform":false,"needsApiKey":false,"reviewed":false,"syncedAt":"2026-10-23T06:04:11.438Z","sample":false,"url":"https://conduits.dev/tools/performance-test-design","language":"","transports":["stdio"],"install":{},"requirements":{"env":[],"upstreamMayCharge":false},"tools":null,"readme":"
\n

Performance Test Design Skill

\n \n Author: Nguyễn Tấn Phát\n
\n July 12, 2026\n
\n\nAn Agent skill that takes a system's requirements documentation and turns it into a complete set of **implementer-ready Performance Test Case Specifications** — one per Operational Profile the system needs tested.\n\nThe skill covers the full design process: discovering which profiles exist, analyzing each profile's transactions and load behavior, calculating virtual users and throughput with documented reasoning, and specifying test data requirements. It stops at the specification. It never writes JMeter, k6, Gatling, or LoadRunner code — that remains a separate implementation step.\n\n## What it does\n\nGiven system documentation (BRD, FRD, use cases, NFR/SLA docs, architecture docs, and optionally production APM data), the skill runs a two-phase process:\n\n**Phase 1 — Operational Profile Discovery:** Reads all available system documents once, identifies user roles and business flows, and produces a prioritized list of Operational Profiles the system needs performance-tested. Pauses for human review before any design begins.\n\n**Phase 2 — Per-Profile Test Case Design:** For each approved profile, in priority order, runs four dependent steps and pauses for human review after each profile completes before moving to the next:\n\n| Step | Output file | What it produces |\n| ------------------------ | ----------------------------------------------------- | --------------------------------------------------------------------------------------------------------- |\n| Profile Analysis | `p1-profile-analysis.md` | Transaction boundaries, protocols, persona behavior, frequency data, transaction mix |\n| Load Profile Design | `p2-load-profile.md` | Test type selection (Load/Stress/Spike/Soak/Scalability/Volume/Baseline), load shape, acceptance criteria |\n| Throughput & Concurrency | `p3-workload-numbers.md` | Open/closed model choice, think time, Little's Law VU calculation, throughput reconciliation |\n| Test Case Specification | `p4-test-data-specification.md` + `test-case-spec.md` | Data parameterization, correlation mapping, data diversity rules, script blueprint, final condensed spec |\n\nEvery number in every output is either sourced (with a citation) or explicitly labeled `[ASSUMPTION]` — the skill never invents a figure without flagging it.\n\n## What it is not\n\n- It does not write test scripts. Output is tool-agnostic design documentation.\n- It does not execute tests or analyze post-execution results.\n- It does not do functional test design (equivalence partitioning, BVA, etc.).\n- It does not do infrastructure sizing or capacity procurement planning.\n\n## Setup\n\n1. Clone or download this repository.\n2. Copy the entire `performance-test-design/` into your AI's `skills/` directory.\n\n## Usage\n\n### Default mode — output to conversation\n\nType the invoke command and attach (or paste) your system documentation:\n\n```\n/performance-test-design\n```\n\nThe skill will:\n\n1. Run Phase 1 — print `operational-profiles.md` content to the conversation, then **pause and ask you to confirm the profile list**.\n2. On your approval, begin Phase 2 for Profile #1 — print each step's output as it's completed, running an AI self-review gate between steps.\n3. After all four steps for Profile #1 complete, **pause and ask you to confirm** that profile's design. You can request corrections at this point; the skill will fix the specific step(s) that need it and re-run only the steps downstream of the fix.\n4. On your approval, move to Profile #2 and repeat until all profiles are done.\n\n### File mode — write output to disk\n\n```\n/performance-test-design --file=docs/perf-test-profiles/\n```\n\nThe path after `--file=` is a **directory**. The skill writes all outputs there:\n\n```\ndocs/perf-test-profiles/\n├── operational-profiles.md ← Phase 1: approved profile list\n├── PROF-01-{short-name}/\n│ ├── p1-profile-analysis.md\n│ ├── p2-load-profile.md\n│ ├── p3-workload-numbers.md\n│ ├── p4-test-data-specification.md\n│ └── test-case-spec.md ← final condensed spec (implementer-facing)\n├── PROF-02-{short-name}/\n│ └── [same 5 files]\n└── ...\n```\n\nIn file mode, a short progress summary is still printed to the conversation after each step so you can follow along without opening files. Review gates work the same way — the skill still pauses and asks for your approval at Phase 1 and after each completed profile.\n\n## Inputs\n\nProvide any combination of the following — the more that's available, the fewer assumptions the skill needs to make:\n\n| Document | Used for |\n| -------------------------------------------- | ------------------------------------------------------------------------------------------ |\n| Business Requirements (BRD) | Identifying business-critical flows and their relative priority |\n| Functional Requirements (FRD) / User Stories | Enumerating transactions and user roles |\n| Use Case documents | Mapping actors to business goals (feeds directly into Operational Profile discovery) |\n| NFR / SLA documents | Response time targets, throughput/concurrency targets, error rate limits |\n| System architecture / design docs | Protocols, tiers, sync/async boundaries, known constraints |\n| Production logs / APM data | Real transaction frequencies and session behavior (strongest source for workload modeling) |\n\nMissing document types don't block the skill — they result in `[ASSUMPTION]` labels on the affected figures, which are consolidated in each Test Case Specification's \"Open Questions\" section for stakeholder follow-up.\n\n## Outputs explained\n\nEach profile produces five files:\n\n- **`p1-profile-analysis.md`** — the full reasoning trail for the profile's transaction list, frequency data, and transaction mix. Verbose by design so a reviewer can catch a wrong assumption at its source.\n- **`p2-load-profile.md`** — which test types were selected and why (each traces to a specific NFR or risk flag), the load shape for each type, and per-transaction acceptance criteria.\n- **`p3-workload-numbers.md`** — the workload model choice (open vs. closed), think time per step, Little's Law calculation showing all inputs and arithmetic, and a throughput reconciliation cross-check.\n- **`p4-test-data-specification.md`** — data parameterization requirements (fields, volumes, sources, reuse policy), correlation mapping (dynamic values extracted from one step and injected into later steps), data diversity rules (pool sizing, distribution shape), and a tool-agnostic script blueprint.\n- **`test-case-spec.md`** — the condensed, implementer-facing document. Contains only what's needed to configure a script and its data. References the four files above for anyone who wants the full reasoning trail. Includes a consolidated list of all assumptions requiring confirmation before execution.\n\n## Techniques covered\n\n### Phase 1\n\n- System Document Analysis (actor identification, business-event decomposition, NFR extraction)\n- Profile Boundary Definition (coherence testing, actor/task partitioning)\n- Profile Prioritization (business criticality, risk exposure, volume, dependency ordering)\n\n### Phase 2 — Step 1\n\n- Protocol & System Analysis\n- Transaction Identification (including nested sub-transactions and async completion boundaries)\n- Persona Behavioral Detailing\n- Task Frequency Mapping (APM data, HAR captures, session-replay tooling, growth factor application)\n- Transaction Mix Design (User Business Profile weighting for low-volume, high-importance transactions)\n\n### Phase 2 — Step 2\n\n- Test Type Selection (Load, Stress, Spike, Soak/Endurance, Scalability, Volume, Baseline, Capacity)\n- Load Shape Design (ramp-up pacing, steady-state duration, spike patterns, stress stop conditions)\n- NFR to Acceptance Criteria Mapping (percentile-based targets, hard constraint cross-referencing)\n\n### Phase 2 — Step 3\n\n- Open vs. Closed Workload Model Selection (coordinated omission risk explanation)\n- Think Time & Pacing (randomized ranges, HAR/session-replay derivation, zero-think-time prohibition)\n- Little's Law Application (dual-method derivation: historical data vs. stated NFR target, reconciliation)\n- Throughput Reconciliation (cross-check against source frequency data)\n\n### Phase 2 — Step 4\n\n- Data Parameterization Specification (pool sizing, reuse policy, uniqueness constraints)\n- Correlation Mapping Specification (dynamic value extraction, lifetime, single-use flags)\n- Data Diversity Rules (Zipfian/power-law distribution, two-tier weighted pool approximation, cache-skew prevention)\n- Script Blueprint Specification (initialization, main flow, verification points, error handling, cleanup — no tool syntax)\n\n## Example walkthrough\n\nThe `examples/` directory contains a complete worked example of the skill applied to **GreenCart**, a fictional online grocery delivery platform. It was generated by actually running the skill against the system documentation — not hand-authored to illustrate the skill.\n\n```\nexamples/\n├── README.md ← GreenCart system documentation (BRD + FRD + NFR + Architecture)\n├── operational-profiles.md ← Phase 1 output: 4 discovered profiles\n├── PROF-01-registered-customer-browse-checkout/\n├── PROF-02-guest-customer-quick-checkout/\n├── PROF-03-warehouse-staff-order-fulfillment/\n└── PROF-04-system-regional-inventory-reconciliation/\n```\n\nThe four profiles were selected to illustrate distinct scenarios:\n\n- **PROF-01 / PROF-02** — customer-facing, open workload model, checkout flow with a recently-reworked code path and a third-party payment gateway constraint\n- **PROF-03** — internal staff tooling, **closed workload model** (staffing-bounded, not arrival-driven), two concurrent actor tracks (Pickers/Packers + Dispatchers)\n- **PROF-04** — scheduled batch job, no human actor, **Volume and Stress testing** instead of Load/Spike, regional scheduling overlap as the key risk factor rather than concurrent user traffic\n\nReading the `examples/` directory alongside the `phases/` guidance shows how each technique decision was made — including cases where a technique was explicitly _not_ applied and the reason is stated, assumptions that were flagged rather than invented, and cross-step inconsistencies that were caught during the process.\n\n## Repository structure\n\n```\nperformance-test-design/\n├── SKILL.md ← skill entry point\n├── phases/\n│ ├── phase-1-operational-profile-discovery/\n│ │ ├── README.md\n│ │ ├── techniques/\n│ │ │ ├── system-document-analysis.md\n│ │ │ ├── profile-boundary-definition.md\n│ │ │ └── profile-prioritization.md\n│ │ ├── resources/\n│ │ │ └── profile-types-reference.md\n│ │ ├── output-template.md\n│ │ ├── output-quality-checklist.md\n│ │ ├── best-practices.md\n│ │ └── anti-patterns.md\n│ │\n│ └── phase-2-per-profile-test-design/\n│ ├── README.md\n│ ├── step-1-profile-analysis/\n│ │ ├── techniques/ (5 files)\n│ │ ├── resources/ (2 files)\n│ │ ├── output-template.md\n│ │ ├── output-quality-checklist.md\n│ │ ├── best-practices.md\n│ │ └── anti-patterns.md\n│ ├── step-2-load-profile-design/\n│ │ └── [same structure, 3 techniques]\n│ ├── step-3-throughput-concurrency/\n│ │ └── [same structure, 4 techniques]\n│ └── step-4-test-case-specification/\n│ └── [same structure, 4 techniques, 2 output templates]\n│\n└── examples/\n ├── README.md ← GreenCart system documentation\n ├── operational-profiles.md\n └── PROF-0{1-4}-*/ ← 4 profile folders, 5 files each\n```\n\n## Standards alignment\n\nThe skill's process and terminology follow the **ISTQB Certified Tester — Performance Testing (CT-PT) syllabus** (2018), specifically:\n\n- ISTQB CT-PT 4.2.1 — Typical Communication Protocols → Step 1 Protocol & System Analysis\n- ISTQB CT-PT 4.2.2 — Transactions → Step 1 Transaction Identification\n- ISTQB CT-PT 4.2.3 — Identifying Operational Profiles → Phase 1 + Step 1\n- ISTQB CT-PT 4.2.4 — Creating Load Profiles → Step 2\n- ISTQB CT-PT 4.2.5 — Analyzing Throughput and Concurrency → Step 3\n- ISTQB CT-PT 4.2.6 — Basic Structure of a Performance Test Script → Step 4 Script Blueprint (specification scope only)\n- ISTQB CT-PT 4.2.7 — Implementing Performance Test Scripts → Step 4 Parameterization & Correlation (specification scope only)\n\nSeveral techniques extend beyond the syllabus's summary level with real-world practice: HAR-based think-time derivation, dual-method Little's Law reconciliation, Zipfian distribution for data diversity, growth factor application, and the User Business Profile concept for transaction-mix weighting.\n"}