k6-script-creation は何をしますか？

このスキルは、k6 に詳しくなくてもチームの誰もが実行、理解、修正できる k6 パフォーマンステストを生成します。そのために、すべてのスクリプトは同じ構造を持ち、役割がわかる名前が付けられ、認証情報はコードの外部に置かれ、各部分を説明する .md ファイルが添付されます。

チームの優先事項: ロードテスト と ストレステスト。HTTP と k6 browser の両方に対応します。スモークテストは常に事前のステップとして実施します。

信頼できる情報源: 公式ドキュメント

記述する内容はすべて https://grafana.com/docs/k6/latest/ (k6 v2.x) と一致している必要があります。このスキルのリファレンスはそのドキュメントを要約したものです。ここでカバーされていない事項や、API、オプション、メトリクスについて少しでも疑問がある場合は、公式ページを参照してください (references/official-docs.md にマップがあります)。インターネット上の多くのサンプルは v2 では動作しなくなった古い API (k6/experimental/browser、同期ブラウザ、browser_web_vital_fid) を使用しています。

リファレンスファイル (必要なものだけ読んでください)

ファイル	読むタイミング
`references/test-types.md`	常に: テストタイプ、ステージプロファイル、executor を選択するとき
`references/thresholds-checks.md`	常に: 標準のしきい値とチェックの書き方
`references/http-patterns.md`	API テスト: ライフサイクル、認証、シークレット、相関、データ
`references/browser-patterns.md`	k6 browser またはハイブリッドテスト
`references/doc-template.md`	説明用 `.md` を書くとき
`references/official-docs.md`	特定のトピックに関する公式ページを検索するとき
`assets/lib/config.js`	`k6/lib/config.js` にそのままコピー
`assets/templates/*`	フロー、テスト、README、`.secrets.example` のベース

プロジェクト構造の標準

k6/
├── tests/
│   ├── api/        <タイプ>-<フロー>.js            例. load-checkout.js, stress-search-products.js
│   └── browser/    <タイプ>-<フロー>-browser.js    例. load-login-browser.js
├── lib/
│   ├── config.js   (assets/lib/config.js からコピー)
│   ├── flows/      <フロー>.js — ユーザーの一連の操作手順。すべてのタイプで再利用
│   └── pages/      <ページ名>-page.js — ページオブジェクト (ブラウザのみ。フローに複数ページがある場合)
├── data/           テストデータ JSON/CSV (認証情報は絶対に含めない)
├── docs/           <スクリプトと同じ名前>.md
├── .secrets.example
└── README.md       (assets/templates/k6-README.md から。スクリプトのインデックス付き)

命名規則: ケバブケース。タイプのプレフィックス (smoke-, load-, stress-, spike-, soak-, breakpoint-) + 説明的なビジネスフロー (checkout, search-products。test1 や api は不可)。ブラウザテストにはサフィックス -browser を付けます。.md ファイル名はスクリプト名と完全に同一にします。

言語: コメントとドキュメントは日本語。コード内の識別子は英語。

プロジェクトに既に k6/ ディレクトリがある場合は、config.js、フロー、既存のページオブジェクトを複製せずに再利用し、既存の内容を尊重してください。

ワークフロー

1. リクエストを理解する

ユーザーの発言から以下を抽出します:

テストタイプ: ロード、ストレス、またはその他。「どのくらい耐えられるか」や「限界まで」と言ったら、ストレス（正確な限界点を知りたいならブレークポイント）。「通常の負荷」や「典型的な1日」ならロード。
API、ブラウザ、またはハイブリッド。
エンドポイントまたは画面、およびフローの順序、認証方法、各ステップで検証する内容。
負荷 (同時ユーザー数またはリクエスト/秒)、期間、および SLA (例: p95 < 500 ms)。
対象環境。

合理的に推測できず、かつブロックとなる項目のみ質問してください。具体的には、ユーザーが指定しなかった URL やエンドポイント、および目的が本番環境かどうかが不明瞭な場合、必ず確認します。それ以外の項目は、リファレンスのデフォルト値 (SLA 500 ms、シンクタイム 1–3 秒、ストレスはロードの 2 倍の負荷) を想定し、各想定は .md の「想定」セクションに記載します。ユーザーが負荷数値を知らない場合は、その旨を伝えてください。数値なしでは、テストはユーザーの意図とは異なる質問に答えることになります。

2. 構造を準備する

k6/ に不足しているものを作成します: lib/config.js (assets/lib/config.js の正確なコピー)、スクリプトが使用するキーを含む .secrets.example、テンプレートからの README.md。さらに、プロジェクトの .gitignore に以下を追加します:

k6/.secrets
k6/screenshots/

3. フローとテストを書く

フロー: k6/lib/flows/<フロー>.js に作成します (ベース: assets/templates/flow-api.js)。リクエスト、チェック、番号付きグループ、name タグ、シンクタイムを含みます。フローにログインが必要な場合、setup() から呼び出される login() 関数をエクスポートします。
テスト: k6/tests/api/<タイプ>-<フロー>.js に作成します (ベース: assets/templates/test-api.js)。options (シナリオ + しきい値)、setup()、default() (フローを呼び出す) のみを定義します。ステージとしきい値はファイル内に明示的に、各行にコメントを付けて記述します。
ブラウザ: k6/tests/browser/<タイプ>-<フロー>-browser.js に作成します (ベース: assets/templates/test-browser.js)。デフォルトはハイブリッド: HTTP 負荷に少数のブラウザ VU を追加します。references/browser-patterns.md を参照してください。
smoke-<フロー>.js も常に生成します (存在しない場合)。コストが低く (フローを再利用)、ロードやストレスの前の必須の最初のステップです。
同じフローのロードテストが存在しない状態でストレステストが要求された場合は、両方を生成します。公式ドキュメントでは、ストレステストはロードテストの後に実行し、そのスクリプトを再利用することを推奨しています。

以下は絶対に妥協しないルールです。これらはチームとシステムを保護します:

認証情報、トークン、API キーは、必ず k6/secrets (await secrets.get('NOMBRE')) と --secret-source=file=k6/.secrets を使用します。コード、data/、__ENV のデフォルト値、console.log には絶対に記述しません。
URL と環境は、-e BASE_URL / -e TARGET_ENV 経由で lib/config.js から読み取ります。ハードコードは禁止です。
config.js の本番環境保護を削除したり弱めたりしないでください。
jslib のインポートは正確なバージョンで行います (official-docs.md を参照)。
ブラウザ: k6/browser、async 関数、シナリオ内の options.browser.type: 'chromium'、finally 内の page.close()、非同期チェック用の k6-utils の check、sleep() の代わりに page.waitForTimeout()。
各リクエストには安定した name タグ ('GET /items/:id') を付け、ID を含む URL でメトリクスが爆発的に増えないようにします。

4. 説明用 `.md` を書く

スクリプトごとに k6/docs/<名前>.md に 1 つ作成し、references/doc-template.md のすべてのセクションに従います。読者は専門家ではありません。用語 (VU、イテレーション、p95、しきい値) は最初に出現したときに説明し、各数値の理由を説明し、スクリプトの実際の値を使用します。負荷プロファイルの ASCII 図、チェックとしきい値の「平易な言葉での」表、正確な実行コマンド (最初にスモーク)、一般的なエラーを含めます。その後、スクリプトを k6/README.md のインデックスに追加します。

5. 検証する

新しいスクリプトごとに k6 inspect -e BASE_URL=https://example.test -e TARGET_ENV=staging <script> を実行します。負荷をかけずに、構文エラー、壊れたインポート、無効なオプションを検出します。k6 がインストールされていない場合は、その旨を伝え、ユーザーが実行できるコマンドを残します。
実際の実行は、ユーザーの明示的な許可がある場合のみ、かつスモークテスト (少数の VU、短時間) として、本番環境以外の環境に対して行います。決して自身でロード、ストレス、スパイク、ソーク、ブレークポイントを起動しないでください。これらは共有システムに実際の負荷を生成します。

6. 応答する

簡潔な応答:

作成または変更したファイルのリスト。
スモークテストを実行するコマンドと、その後要求されたテストを実行するコマンド。
主要な想定 (.md と同じもの)。
検証した内容としていない内容 (例: 「k6 inspect はパスしました。API に対する実行は行っていません」)。

既存のスクリプトをレビューまたは修正する

リクエストがスクリプトの理解、修正、改善である場合:

完全に読み、標準および公式ドキュメントと照合します (古い API、await なしのブラウザ、page.close の欠如、コード内の認証情報、しきい値なし、name タグなし、シンクタイムなし、「ジェットコースター」タイプのプロファイルなど)。
問題を重要度順に簡潔な言葉で説明し、変更を提案します。
修正する際には、.md を更新 (または作成) し、ドキュメントがコードと一致するようにします。
名前が標準に従っていない場合は、名前の変更を提案しますが、確認なしには実行しないでください。スクリプトを呼び出すパイプラインを壊す可能性があります。

k6-script-creation