メニュー
Write and run Artillery load tests with YAML phases and scenarios, CSV data payloads, the expect plugin for functional checks, and ensure thresholds that fail CI when latency or error budgets are breached.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/PramodDutta/qaskills --skill load-testコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
SOC 職業分類に基づく
SKILL.md を表示中
| name | Artillery Load Testing |
| description | Write and run Artillery load tests with YAML phases and scenarios, CSV data payloads, the expect plugin for functional checks, and ensure thresholds that fail CI when latency or error budgets are breached. |
| version | 1.0.0 |
| author | thetestingacademy |
| license | MIT |
| tags | ["artillery","load-testing","performance","stress-testing","yaml","thresholds","ci","api","latency"] |
| testingTypes | ["load","performance"] |
| frameworks | ["k6"] |
| languages | ["javascript"] |
| domains | ["api","web"] |
| agents | ["claude-code","cursor","github-copilot","windsurf","codex","aider","continue","cline","zed","bolt","gemini-cli","amp"] |
This skill makes an AI agent author Artillery 2.x load tests as declarative YAML: realistic traffic phases, multi-step scenarios with captured variables, CSV-driven virtual user data, functional expect checks inside load flows, and ensure thresholds that turn latency regressions into red CI builds. Trigger it when a project contains artillery.yml, artillery in package.json, or when the user asks for load, stress, soak, or spike testing of an HTTP API or website in a Node.js stack.
arrivalRate hides cold-start effects and autoscaling lag. Always define at least warm-up, ramp, and sustain phases.arrivalRate is new virtual users per second, not concurrency. Each arriving VU runs the whole scenario. If your scenario takes 10 seconds and you arrive 50/sec, you have roughly 500 concurrent users. Calculate this before picking numbers.ensure plugin so artillery run exits non-zero when p95/p99 or error rate budgets are blown. A load test that cannot fail is a demo, not a test.expect. A server returning 200 with an empty body at p99 latency is still broken. Check statusCode, contentType, and hasProperty inside the flow.payload with hundreds of distinct credentials and SKUs to defeat caches realistically.npm install --save-dev artillery@latest
npx artillery version
# Run a test locally
npx artillery run load/checkout.yml
# Save raw metrics for trend analysis
npx artillery run load/checkout.yml --output artillery-report.json
# load/checkout.yml
{}
{}
email,password
loadtest-001@example.com,Str0ngPass!001
loadtest-002@example.com,Str0ngPass!002
loadtest-003@example.com,Str0ngPass!003
loadtest-004@example.com,Str0ngPass!004
Generate hundreds of rows with a one-liner instead of writing them by hand:
seq -w 1 500 | awk -F, 'BEGIN{print "email,password"} {printf "loadtest-%s@example.com,Str0ngPass!%s\n", $1, $1}' > users.csv
# In config:
config:
target: https://staging-api.example.com
processor: ./processor.js
scenarios:
- name: create-order-with-dynamic-payload
flow:
- function: generateOrderPayload
- post:
url: /orders
json:
sku: '{{ sku }}'
quantity: '{{ quantity }}'
afterResponse: logSlowResponse
// processor.js
module.exports = { generateOrderPayload, logSlowResponse };
function generateOrderPayload(context, events, done) {
// Runs before the request; sets template variables on the VU context
context.vars.sku = `SKU-${1000 + Math.floor(Math.random() * 9000)}`;
context.vars.quantity = 1 + Math.floor(Math.random() * 4);
return done();
}
function logSlowResponse(requestParams, response, context, events, done) {
const tookMs = response.timings ? response.timings.phases.total : 0;
if (tookMs > 1000) {
console.warn(`SLOW ${requestParams.url} -> ${response.statusCode} in ${tookMs}ms`);
events.emit('counter', 'custom.slow_responses', 1);
}
return done();
}
The ensure plugin makes Artillery exit with code 1 on any threshold breach, so the job fails without extra scripting.
# .github/workflows/load-test.yml
name: load-test
on:
workflow_dispatch:
schedule:
- cron: '0 2 * * 1'
jobs:
artillery:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 20
cache: npm
- run: npm ci
- name: Run load test against staging
run: npx artillery run load/checkout.yml --output artillery-report.json
env:
ARTILLERY_DISABLE_TELEMETRY: 'true'
- name: Upload raw metrics
if: always()
uses: actions/upload-artifact@v4
with:
name: artillery-report
path: artillery-report.json
think steps (1-3 seconds) between requests so VUs pace like humans instead of a retry storm.weight: to mirror real traffic mix (for example 70 percent browse, 25 percent search, 5 percent checkout).--overrides '{"config":{"phases":[{"duration":10,"arrivalRate":1}]}}') before any big run to catch broken auth and 4xx noise cheaply.--output JSON artifacts from every CI run so you can diff p95 across releases.http.timeout explicitly; the 120-second default hides hangs as slow successes.arrivalRate and no ramp: you are testing the load balancer's SYN queue, not your application.expect or ensure block exists.arrivalRate past what one generator machine can produce: watch for Artillery's own CPU warnings, and split load across workers (or Fargate via artillery run-fargate) instead.artillery.yml, files under load/ or perf/ with Artillery config, or artillery in package.json devDependencies.