AIは変更差分からユニットテスト_結合テスト_システムテストでテストすべきことが出せるのか？

2025/8/19, AI時代におけるユニットテストの現在地 ( https://findy.connpass.com/event/363174/ )での発表です。
AIは適切なテストレベルで適切なテスト観点が出せるのか。
システムテストだけではなく、テストレベルを通したテストのアプローチの最適化ができるのかどうかという実験の話です。

Transcript

1. AIは変更差分から ユニットテスト 結合テスト システムテストで テストすべきことが 出せるのか？ 松谷峰生
2. 2 名前 : 松⾕峰⽣（まつ） 仕事 : ハードウェアの⼈    & QAエンジニア 社外活動 • マンガ家 ◦ ベリサーブ様HQWにて⽉刊マンガ連載 ◦ テスターちゃん (最近はお休み中) • ソフトウェアテストシンポジウム九州の共同実⾏委員⻑ • ソフトウェアテスト技術振興協会の教育事業領域担当 ⾃⼰紹介 出典 : C&R研究所 マンガでわか るソフトウェアテスト入門 テスター ちゃん Vol.2 https://www.veriserve.co.jp/helloqualityworld/media/20250808001/
3. テーマ AIは 適切なテストすべき場所(テストレベル)で 適切なテストすべきこと(テスト観点)を 出せるのか？ ※今日の発表は私が個人で行っている活動の話です
4. 発表を聞くための 認識合わせ
5. 5 開発時はフワっとしたものをギュッと固めていくイメージ 要求 要件 仕様 設計 実装 フワッとしたもの 色々決まって固まっていく ※画面は開発中のものです
6. 6   バグの多くは「忘れもの」 要求 要件 仕様 設計 実装 テスト ・実装漏れ ・実装の間違い ・設計の間違い ・影響箇所の把握漏れ ・認識の齟齬 実装通り動くかの確 認だけでいい？ ・仕様漏れ ・書き間違え ・仕様の更新忘れ ・要件定義漏れ ・認識の齟齬
7. 7   テストの時は「忘れものない？」と発想を広げる 要求 要件 仕様 設計 実装 テストの時は発想を広げていく活動も必要 忘れもの ないかな？ 考慮漏れで65536秒後にバグる じゃん！ 管理ツールも変更必要じゃん！
8. 8 テストで⾏うこと3選 確認活動 「決めたものが決めた通り動く」 →　ユニットテストが典型例 バグの探索 忘れもの（考慮漏れ、決めていない）や「何かおかしいぞ …？」を探して発見する活動 　→コードに直接現れにくい問題 妥当性確認 「顧客が本当に必要だったもの」ができているか　 →　A/Bテストやユーザーテスト 　　現実の問題 　　　確認活動に終始してしまい、バグの探索が不十分になりがち
9. 9   テストの⽬的を達成するために最適な場所がある ダメージ計算が正しいか確認 したいのですが、武器が出る確率が低すぎるのでデバッグメ ニューを作ってください。 ダメージ計算のロジックの正しさ ならユニットテストで確認 したほう がいいのでは？
10. 10 テストレベル3選 (テスト活動をグループ分けしたもの) ユニットテスト (コンポーネントテスト) メソッド単体などテストできる最小単位での確認 　→　主にロジックの確認 インテグレーションテスト (結合テスト/コンポーネント統合テスト) メソッド間のやりとり、コンポーネント間のやり取り 　→　主にインターフェイス（接点の部分）に着目して相互処理の確認 システムテスト システムを通してのテスト　 →　システム全体にしたときに要件を満たしているか確認 　　現実の問題 　　　なんでもユニットテスト、なんでもシステムテストでやろうとして非効率になりがち
11. テーマ AIは 適切なテストレベルで 適切なテスト観点を 出せるのか？
12. 実験 Cursor x Claude-4-Sonnet で試してみた
13. 13 個⼈開発の横シューティングゲームで実験 実験環境 • エディター : Cursor • AIモデル : Claude-4-Sonnet • プロジェクト : Unity ◦ 個人開発の横シューティングゲーム • テスト対象 : 新武器「クラスター爆弾」実装 仕様 • 大きい親弾が重力に従って少し下に落 ちる • そこからゴゴゴーと前に加速しながら前 進 • パカっと外装が外れて、子弾が下にば らまかれる • (細かくはもっとあるが略 ) 実装
14. 14   各テストレベルでテストすべきことを出せるのか？ 変更差分から、ユニットテストでテストすべきこと、インテグレーション テストでテストすべきこと、システムテストでテストすべきことを出せる のか？ Cursorではdiffをコンテキストとして与えることができる diffには載らないがテストすべきこ とも出したい
15. 15   “ないもの”を⾒つけられるのか？ バグを2つ仕込み、 AIがそれを見つけるテスト観点を出せるのか？ ダメージ値をコードにベタ書き → インテグレーションテストで見つけたい 他の武器では必ず呼んでいる SetDamage()の呼び忘れ。これにより ItemDataからダメージ値を取ってこ ない。よって後々ItemDataをいじってもダメージが反映されないことになる。 親弾のtagの設定忘れ → システムテストで見つけたい 何のオブジェクトにぶつかったかは tagで判定している。親弾に設定を忘れたため、親弾にぶつかっても ダメージ処理が走らない 　コードに現れないものを見つけられるのか？
16. 16 ⽐較⽤に⼈間もテスト観点を出しておく AIが出したテスト観点と比較するため、事前に人間もテスト観点を出して おく ユニットテスト ・ダメージ計算 ・子弾の発射ロジック etc… インテグレーションテスト ・設定呼び出し ・キャラによるダメージ倍率変化 etc… システムテスト ・カッコ良さ！ ・ゲーム内特有のルールの適用 etc…
17. 実験結果
18. 18   仕込んだバグを⾒つけられるテスト観点を出せた 仕込んだバグを 2つとも見つけられるテスト観点を出せた ! PASS ダメージ値をコードにベタ書き → インテグレーションテストで出している 「弾丸設定読み込みテスト」のテスト観点を出している。このテストを詳細化 (AIでも人でも)するとおのずと ItemDataからのダメージ値呼び出しは通る 親弾のtagの設定忘れ → インテグレーションテストで出している 「敵ダメージ適用テスト」のテスト観点を出している。出て当然のテスト観点だが、詳細化すればダメージ が適用されるかされないかはおのずと通る 私が仕込んだ 2つのバグを拾える観点を出せたということは、本当の「忘れもの」も見つけられる 可能性が高い
19. 19   各テストレベルでテストすべきことを出せていそう 各テストレベルでテストすべきことを出せているが、インテグレーションテ ストが曖昧 (私の指示が曖昧 ) おおよそ OK ユニットテスト 各種パラメーターのテストやロジックのテスト、メモリリークのテストなど、ユニットテストの項目はさすが。 私が考えるよりも詳細であった インテグレーションテスト 相互作用があるテスト観点は全てここに含まれている。コードで見るべきテストもあれば、音響テストのよ うな実プレイで見たほうが良いテストもある。 システムテスト 通常プレイでの武器の実用性、ボス戦に有効か、パフォーマンステストなど、全体を通して見るべき妥当 な項目が出せている
20. 20   AIの出したテスト観点を取捨選択、補完して使うべし AIが出せて人間が出せなかったテスト観点もあれば、逆もある このゲーム特有の仕様のテスト観点は出せない このゲームはプレイヤーが左右を向けるといった特有の実装があるが、特有部分のテスト観点が出せて いない。一般的なシューティングゲームの内容からテスト観点を出している パフォーマンスやメモリリークなど非機能のテスト観点が含まれている 私はどうしても機能に着目してしまいパフォーマンスなど非機能要件の考慮が抜けることが多々あるが、 AIが出したテスト観点に含まれる (今回の武器は子弾をばら撒くので重要 ) 　現状での根本的な問題 　　AIはコードベースの実際の状況を把握しているわけではない 　　　→　一般的なゲーム開発の知識で推測 している 最近mdc(ルール)ファイルに仕様を 書いて読み込ませることを試してい る
21. 21   AIの問題点 ハルシネーションが多発 先にお伝えした通り一般的なゲーム開発知識での推測が入った。よって、オブジェクトプールや武器の切 り替えなど実装していない機能のテスト観点が入っている 過剰なテスト 物理演算の確認など、求めていないレベルでの過剰なテスト観点を出している より良い結果を得るために ・コンテキスト情報を充実　 →　diffだけでなく仕様なども渡す（コードベース全体を渡せたら …） ・プロンプトを具体化　 →　「変更内容に絞って」だと手が加わったコード全体を読んでいるように見える。 tag忘れは拾えていなかった。ハルシネーションはおさえられているが発生している
22. 22 実⽤的な活⽤⽅法 基本戦略 「AIでテスト観点を出し、人間が観点を追加/取捨選択する」 「AIでどのテストレベルで何のテストをするか出し、テストの最適化をする」 ・初期のテストアプローチ生成 　　ゼロから考える手間の削減 ・大まかなテスト観点の洗い出し 　　人間が見落としがちな観点導出 ・テストレベルの分類 　　どのテストをどこで行うかの提案 AIの役割 ・プロダクト固有のテスト観点追加 　　プロダクト特有の仕様など ・ハルシネーションの除去 　　存在しない機能・観点の除去 ・テストの詳細さの調整 　　自プロダクトの品質目標に合わせる ・優先度の判断 　　優先すべきテストの判断 人間の役割
23. 23 まとめ 結論 各テストレベルに適したテスト観点をかなりよく出せるようになっている。 だが人間がサポートをしないと無駄なテスト・出来ないテストが発生する。 「全部」を求める 0か100かの思考ではなく 「ある程度の手間の削減・補完」として活用しよう 期待できること ・テストすべきことの洗い出しの支援 ・見落としがちなテスト観点の発見 ・テストアプローチのたたき台作成 ・ある程度の手間の削減 期待できないこと ・完璧なテスト観点の生成 ・プロダクト固有の仕様の把握 ・100%正確な情報 ・ちょうどよい粒度のテスト
24. 24 おまけ : GPT5で実験 HPが0になったら一定時間点滅して周囲を巻 き込んで爆発する敵キャラ追加 https://github.com/jam0824/AIWritesTestPlan/blob/main/bomberFly_test_plan.md 結論 「実装の確認作業」としてのテストであれば GPT5で行うとよい。 90FPSという全体設定は変更していないファ イルに記載。よって変更していないファイルも 参照している。 (GPT5というより今のCursorの性能か) ハルシネーションがなく 素晴らしい。 ただし良くも悪くも発想もない。 よって「忘れもの」発見は難しい かもしれな い。
25. 25 詳細は以下の記事 変更差分からユニットテスト /結合テスト/システムテストのテスト観点を出せるのか？【 cursor】 https://zenn.dev/jam0824/articles/877546e6d059fb
26. ご清聴 ありがとうございました！ ※画面は開発中のものです