AIにAPIテストケースを考えさせてみた

こんにちは。ソリューションSecの増田です。

先日担当した案件で、APIテストの量がこれまでと段違いになりました。エンドポイントは十数本、それぞれに正常系と異常系のケースを立てていくと、テストケースは全体で300件を超える見込み。スケジュールを引いた段階で、これは今までのやり方だと厳しいなというのが正直な感想でした。

そこで、工程のいくつかを生成AIに任せて効率化を試みました。結果として作業時間はかなり圧縮できましたが、逆に「ここは任せてはいけない」とはっきり分かった部分もありました。同じ規模のテストを控えている方に向けて、両方まとめておきます。

ボトルネックは3か所にありました

手を動かす前に、どこに時間が溶けているかを整理しました。

• テストケースの洗い出し：正常系はすぐ書けるのに、異常系と境界値で毎回止まる。「他に漏れている観点はないか」を考える時間が読めない。
• テストスクリプトの作成：Postmanの pm.test() をエンドポイントごとに書く作業。頭は使わないのに、項目数が多いので単純に時間がかかる。
• 実行結果のエビデンス化：提出用に結果を残す作業。件数が増えるほど、ここが効いてくる。

性質が違うので、AIの使い方も工程ごとに分けて考えることにしました。先に全体像を示すと、こういう切り分けになりました。

工程1：テストケースの洗い出し

AIに渡したのは、パラメータの型と必須/任意が書かれた仕様、エラーコードとそれが返る条件の一覧、レスポンスのサンプルを正常時とエラー時で1件ずつ。この3点だけです。

以下のAPI仕様に対するテストケースを洗い出してください。
- 正常系・準正常系・異常系に分類すること
- 境界値のケースは、境界の内側・境界上・外側の3点を明示すること
- 各ケースに「入力」「期待するHTTPステータス」「期待するレスポンス」を書くこと
- 表形式で出力すること

【API仕様】
（ここに仕様を貼る）

最初は「テストケースを考えて」とだけ投げたのですが、これは失敗でした。文章で返ってきて、内容は妥当なのにテスト仕様書へ転記できない。分類と出力形式を先に指定した途端、そのまま表にコピペできる形で出てくるようになりました。大量に処理する前提だと、この差は無視できません。

1エンドポイントあたり30件前後が返ってきます。全件を1件ずつ判定した結果は、次のような比率でした。

特に効いたのが日付パラメータの境界値です。同日指定、開始日と終了日の逆転、期間の上限ちょうど、上限+1日、という4パターンを提示してきたのですが、この「上限+1日」が自分の設計から抜けていました。

境界の内側と境界上は意識していたのに、外側の詰めが甘い。観点の抜けというより自分の癖の問題だったので、これに気づけたのは件数の効率化とは別の価値がありました。

ほかにも、必須パラメータについて「キーごと送らない」と「キーはあるが値が空文字」を別ケースとして立てていたり、ページネーションで総件数が1ページの上限とちょうど一致するケースを押さえていたり。どれも言われれば当然なのに、自分だけで洗い出すと落としやすいところです。

工程2：テストスクリプトの生成

ここは最も素直に効果が出ました。

以下のテストケースに対応するPostmanのテストスクリプトを書いてください。
- ステータスコードの検証
- レスポンスボディの必須項目の存在確認
- 型の検証

定型作業なので精度が高く、ほぼそのまま動きます。レスポンススキーマを渡しておけば、項目が多くても漏れなく書いてくれます。手で書くと面倒なだけで判断を伴わない工程なので、ここは丸ごと任せて問題ないと判断しました。

体感では、1エンドポイントあたり30分かかっていた作業が10分弱になりました。エンドポイントが十数本あるので、ここだけで数時間分の差になります。

工程3：実行結果のエビデンス化

当初はPostmanのCollection Runnerで実行して結果を保存する想定でしたが、件数が増えると1件ずつ保存していくのが現実的でなくなりました。そこでNewmanに切り替えて、htmlextraレポーターでまとめて出力する形に変更しました。

このコマンドと設定もAIに書かせています。使ったことのないツールのオプションを調べる時間が省けるので、こういう「一度書けば以降は使い回すだけ」の部分は相性が良いと感じました。

任せてはいけなかったこと

効率化の話ばかり書きましたが、そのままでは使えない部分もはっきりありました。

まず、仕様書に書いていない業務ルールは当然知らないので、実務では発生しない操作のケースが混ざってきます。ここは人間が落とす必要があります。重複も出ます。表現が違うだけで中身が同じケースが何組かありました。粒度がばらつくこともあり、「認証エラーを確認する」程度のざっくりしたケースと具体的な値まで書かれたケースが同じ表に並んでいることがありました。これは追加で「具体的なリクエスト例まで書いてください」と指示すれば埋まります。

そして、最も注意が必要だと感じたのが期待値です。HTTPステータスの期待値が、こちらの設計と異なる値になっているケースがいくつかありました。一般的な設計としては妥当な提案でも、このAPIの仕様とは違う。気づかずに通すと、テストの正解そのものがずれたまま進むことになります。件数が多い案件ほど、後から気づいたときの手戻りが大きくなる部分です。期待値の確定は必ず仕様書に戻って行いました。

情報の取り扱いについて

仕様書をそのまま貼ることはしていません。顧客名、口座番号やIDのような識別子、認証情報、内部のホスト名は、渡す前にすべてダミーに置き換えました。テストケースの洗い出しに必要なのはデータ構造だけで、実データを含める理由がありません。件数が多いと省略したくなる工程ですが、ここは崩さないほうがよいと考えています。

まとめ

今回の使い方を一言でまとめると、判断を伴わない作業は任せ、判断が必要な部分は必ず自分に戻すという切り分けでした。スクリプトの生成は前者、期待値の確定は後者です。テストケースの洗い出しはその中間で、AIに案を出させて自分が採否を決める形が現実的でした。

そのうえで、順番が結果を大きく左右すると感じました。

まず自分で一通り設計し、そのうえで同じ仕様をAIにも渡して差分だけを確認する。出力を吟味する手間はかかりますが、観点の漏れに気づけるメリットのほうが上回りました。逆に最初から丸投げすると、業務ルールを無視したケースと誤った期待値が混ざった成果物ができあがり、レビューで作り直しになります。効率化のつもりが逆効果になる典型だと思います。

まだ整理しきれていないのが、AIが出したケースをテスト仕様書にどこまで残すかという点です。採用したケースは当然残しますが、検討して落としたケースを判断の履歴として残すべきかどうか。残せばレビューはしやすくなる一方、単に読みづらくなる懸念もあり、ここは次の案件で試したいと考えています。

同じ規模のテストを扱われている方がいれば、プロンプトの工夫でも運用ルールでも、知見を共有いただけると嬉しいです。