mcpField
A
api-testing

api-testing

github.com/naodengテスト・品質292131 回インストール1 日前に更新
リポジトリ

api-testing について

API テストの計画、ケース作成、リスク分析を支援するスキルです。複数のインターフェースプロトコルを扱い、前提、優先順位、証拠を明確にします。

主な機能

  1. 01API テスト計画とケースの作成
  2. 02インターフェースリスクの分析と優先付け
  3. 03プロトコルに応じた確認項目の選択
  4. 04確認済みの事実と前提の分離
  5. 05リクエスト間の業務結果の確認

活用シーン

  1. 01REST または GraphQL API のテスト設計
  2. 02gRPC、WebSocket、SOAP のシナリオ確認
  3. 03前提を明記した初版の作成

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/naodeng/awesome-qa-skills --skill api-testing

インストール後、Claude Code で/api-testingを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

output-formats.md
quick-start.md
README.md
agents/
openai.yaml
evals/
eval.yaml
evals/cases/
basic-success.yaml
domain-method-regression.yaml
edge-incomplete-input.yaml
edge-risk-priority.yaml
evals/fixtures/
check_domain_decisions.py
check-domain-decisions.sh
domain-oracle.json
examples/postman-rest-api/
API-Environment.postman_environment.json
newman-run.sh
README.md
User-API-Tests.postman_collection.json
examples/rest-assured-java/
pom.xml
README.md
examples/rest-assured-java/src/test/java/com/example/
UserApiTest.java
examples/supertest-nodejs/
package.json
README.md
examples/supertest-nodejs/tests/
users.test.js
output-templates/
template-csv.csv
template-excel.tsv
template-json.json
template-markdown.md
template-word.md
template-xmind.md
prompts/
api-testing.md
references/
domain-decision-example.md

詳細

翻訳後に原文が更新されています。最新の内容は原文をご確認ください。

API テスト(英語)

中国語版: 対応する中国語のスキルを参照してください。

使用する場面

  • API テスト計画、API テストケース、または API リスク分析が必要な場合。
  • リクエストに REST、GraphQL、SOAP、gRPC、WebSocket、または複数の API にまたがる動作が含まれる場合。

ワークフロー

  1. Progressive disclosure に記載されているメインプロンプト(カバレッジ、構成、品質基準)を読み、それに従います。
  2. 結果に影響するプロジェクトのコンテキストのみを追加します。対象範囲、環境、制約、リスク、依存関係、期待する成果物などです。
  3. 入力が不完全な場合は、実用的な初稿を提示し、前提と不足事項を明示します。
  4. 既定では Markdown を使用します。ユーザーから要望があった場合にのみ、形式を切り替えます。

ドメイン実行の要点

  1. 確認済みのプロトコルにのみ分岐します。REST ではメソッド/ステータス/スキーマ/冪等性、GraphQL ではデータとエラー/null/フィールド権限、gRPC ではステータス/メタデータ/期限/ストリームの終了、WebSocket ではハンドシェイク/メッセージ ID/順序/再接続、SOAP では WSDL/名前空間/Fault を確認します。使用しないプロトコルを必須にしないでください。
  2. コントラクトの検証と、リクエストをまたぐビジネス上の事後条件を分けます。作成/更新→読み戻し→権限に応じた表示→再実行/後続への影響を確認します。リクエスト ID、ビジネスキー、バージョン、証跡を保持してください。
  3. ステータスが正しくても、永続化された残高/状態/関連付けが誤っていれば、ビジネス上の失敗です。非同期の影響にはプロジェクトの整合性ウィンドウを適用し、遅延を勝手に設定しないでください。
  4. 分離された名前空間/一意のビジネスキーを用意し、依存関係を逆順にたどってクリーンアップし、残存物を記録します。権限が不足している場合や、実際の影響を伴う制約がある場合は、ブロックされた状態のままにします。

主な制約

  • リスク/ビジネスへの影響に基づいて優先順位を付け、すべてを同等に扱わないでください。
  • 確認済みの事実と、現時点での前提を分けてください。
  • ユーザーが提示していないエンドポイント、フィールド、環境、根本原因を作り出さないでください。
  • 実行可能な出力にします。具体的なシナリオ、明確な優先順位、明確な次のステップを示してください。

段階的な開示

  • ドメインの結果、妥当な制御、または証跡の不足を判断する場合は、サニタイズ済みの入力、項目ごとのオラクル、再現可能な計算について、references/domain-decision-example.md を参照してください。

  • 出力を作成する前に、prompts/api-testing.md を読み、従ってください(最低限のカバレッジ、出力構成、品質基準)。

  • Excel/CSV/JSON/Word が指定された場合は、output-formats.md を読み、その形式に従ってください。

  • 既成のテンプレートが適している場合は、output-templates/ 内の該当ファイルを使用してください。

  • フレームワーク/トラブルシューティング/スキーマについて詳しく調べる場合は、references/ 内の関連ファイルのみを読み、ディレクトリ全体を読み込まないでください。

  • 形式変換や補助的なチェックには、一から作り直すのではなく、既存の scripts/ を優先してください。

  • このスキルの評価/回帰テストには、skill-up と併せて evals/ を使用してください。

提出前チェックリスト

  • メインプロンプトの出力構成に従っている
  • 最低限のカバレッジに注力している:対象範囲内のエンドポイントまたはビジネスフロー、優先順位とリスクレベル、正常系シナリオ、異常系シナリオ、境界値シナリオ、認証と権限のチェック、リクエストとレスポンスの検証、エラー処理、……(詳細はメインプロンプトを参照)
  • 最低限のチェックリストを網羅しているか、省略した項目について説明している
  • 高リスク項目に明示的な優先順位を付けている
  • ユーザーが提示していない詳細を作り出していない
  • 前提と不足事項を明示している

よくある落とし穴

  • 対象範囲やコンテキストが不足しているのに、網羅しているかのように見せないでください。
  • すべての項目を同等に重要なものとして扱わないでください。
  • 前提や情報の不足を省略しないでください。
  • 現在のツールチェーンに関係のない一般論を並べないでください。

コメント