api-testing について
API テストの計画、ケース作成、リスク分析を支援するスキルです。複数のインターフェースプロトコルを扱い、前提、優先順位、証拠を明確にします。
主な機能
- 01API テスト計画とケースの作成
- 02インターフェースリスクの分析と優先付け
- 03プロトコルに応じた確認項目の選択
- 04確認済みの事実と前提の分離
- 05リクエスト間の業務結果の確認
活用シーン
- 01REST または GraphQL API のテスト設計
- 02gRPC、WebSocket、SOAP のシナリオ確認
- 03前提を明記した初版の作成
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ naodeng/ awesome-qa-skills --skill api-testingインストール後、Claude Code で/api-testingを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
output-formats.mdquick-start.mdREADME.mdagents/openai.yamlevals/eval.yamlevals/cases/basic-success.yamldomain-method-regression.yamledge-incomplete-input.yamledge-risk-priority.yamlevals/fixtures/check_domain_decisions.pycheck-domain-decisions.shdomain-oracle.jsonexamples/postman-rest-api/API-Environment.postman_environment.jsonnewman-run.shREADME.mdUser-API-Tests.postman_collection.jsonexamples/rest-assured-java/pom.xmlREADME.mdexamples/rest-assured-java/src/test/java/com/example/UserApiTest.javaexamples/supertest-nodejs/package.jsonREADME.mdexamples/supertest-nodejs/tests/users.test.jsoutput-templates/template-csv.csvtemplate-excel.tsvtemplate-json.jsontemplate-markdown.mdtemplate-word.mdtemplate-xmind.mdprompts/api-testing.mdreferences/domain-decision-example.md詳細
翻訳後に原文が更新されています。最新の内容は原文をご確認ください。
API テスト(英語)
中国語版: 対応する中国語のスキルを参照してください。
使用する場面
- API テスト計画、API テストケース、または API リスク分析が必要な場合。
- リクエストに REST、GraphQL、SOAP、gRPC、WebSocket、または複数の API にまたがる動作が含まれる場合。
ワークフロー
- Progressive disclosure に記載されているメインプロンプト(カバレッジ、構成、品質基準)を読み、それに従います。
- 結果に影響するプロジェクトのコンテキストのみを追加します。対象範囲、環境、制約、リスク、依存関係、期待する成果物などです。
- 入力が不完全な場合は、実用的な初稿を提示し、前提と不足事項を明示します。
- 既定では Markdown を使用します。ユーザーから要望があった場合にのみ、形式を切り替えます。
ドメイン実行の要点
- 確認済みのプロトコルにのみ分岐します。REST ではメソッド/ステータス/スキーマ/冪等性、GraphQL ではデータとエラー/null/フィールド権限、gRPC ではステータス/メタデータ/期限/ストリームの終了、WebSocket ではハンドシェイク/メッセージ ID/順序/再接続、SOAP では WSDL/名前空間/Fault を確認します。使用しないプロトコルを必須にしないでください。
- コントラクトの検証と、リクエストをまたぐビジネス上の事後条件を分けます。作成/更新→読み戻し→権限に応じた表示→再実行/後続への影響を確認します。リクエスト ID、ビジネスキー、バージョン、証跡を保持してください。
- ステータスが正しくても、永続化された残高/状態/関連付けが誤っていれば、ビジネス上の失敗です。非同期の影響にはプロジェクトの整合性ウィンドウを適用し、遅延を勝手に設定しないでください。
- 分離された名前空間/一意のビジネスキーを用意し、依存関係を逆順にたどってクリーンアップし、残存物を記録します。権限が不足している場合や、実際の影響を伴う制約がある場合は、ブロックされた状態のままにします。
主な制約
- リスク/ビジネスへの影響に基づいて優先順位を付け、すべてを同等に扱わないでください。
- 確認済みの事実と、現時点での前提を分けてください。
- ユーザーが提示していないエンドポイント、フィールド、環境、根本原因を作り出さないでください。
- 実行可能な出力にします。具体的なシナリオ、明確な優先順位、明確な次のステップを示してください。
段階的な開示
-
ドメインの結果、妥当な制御、または証跡の不足を判断する場合は、サニタイズ済みの入力、項目ごとのオラクル、再現可能な計算について、references/domain-decision-example.md を参照してください。
-
出力を作成する前に、
prompts/api-testing.mdを読み、従ってください(最低限のカバレッジ、出力構成、品質基準)。 -
Excel/CSV/JSON/Word が指定された場合は、
output-formats.mdを読み、その形式に従ってください。 -
既成のテンプレートが適している場合は、
output-templates/内の該当ファイルを使用してください。 -
フレームワーク/トラブルシューティング/スキーマについて詳しく調べる場合は、
references/内の関連ファイルのみを読み、ディレクトリ全体を読み込まないでください。 -
形式変換や補助的なチェックには、一から作り直すのではなく、既存の
scripts/を優先してください。 -
このスキルの評価/回帰テストには、skill-up と併せて
evals/を使用してください。
提出前チェックリスト
- メインプロンプトの出力構成に従っている
- 最低限のカバレッジに注力している:対象範囲内のエンドポイントまたはビジネスフロー、優先順位とリスクレベル、正常系シナリオ、異常系シナリオ、境界値シナリオ、認証と権限のチェック、リクエストとレスポンスの検証、エラー処理、……(詳細はメインプロンプトを参照)
- 最低限のチェックリストを網羅しているか、省略した項目について説明している
- 高リスク項目に明示的な優先順位を付けている
- ユーザーが提示していない詳細を作り出していない
- 前提と不足事項を明示している
よくある落とし穴
- 対象範囲やコンテキストが不足しているのに、網羅しているかのように見せないでください。
- すべての項目を同等に重要なものとして扱わないでください。
- 前提や情報の不足を省略しないでください。
- 現在のツールチェーンに関係のない一般論を並べないでください。
コメント
Markdown 対応