ソフトウェアテストのAI活用_ver1.50

生成AIをソフトウェアテストで活用したドキュメントです。
主に自動化を想定しています。

Transcript

1. ソフトウェアテストの AI活用 PoC実験結果　(2025/11 Ver1.50) 

2. PoCにおける目的 私のAIを活用した PoCの目的を以下へ列挙しておきます。 　・　自分の意思をAIに伝えた上で、どこまでAIが対応できるのか？ 　・　どこまでAPI実装によりテスト工程の自動化を実現できるのか？ 　　 (できること、できないこと、前提条件、 　　　他の方が同様に再現させる上で課題となることは何か？) 　・　作ってみた結果の精度はどうなのか？
3. 更新履歴 No Ver 内容 担当 日付 1 1.00 初版発行 fumi.kato 2025/4/27 2 1.10 タイトルを変更 更新履歴を追加 以下を補足資料へ移動 　　- テスト計画書について 　　- テスト設計書について 　　- レビューについて 　　- テストケースについて 　　- テストスクリプトについて 　　- テスト実行について 　　- テスト報告書について fumi.kato 2025/6/1
4. 更新履歴 No Ver 内容 担当 日付 3 1.20 「サンプリングプロジェクト」を追加 「AIを活用してテスト計画を支援」を追加 fumi.kato 2025/6/9 4 1.25 「AIを活用してテストケースの作成 (Draft)」を追加 fumi.kato 2025/7/13 5 1.50 ・全体的に整理 ・「AIを活用してテスト分析を支援」を追加 fumi.kato 2025/11/6
5. 最初にお伝えしたいこと ・ 全体的に人の作業は支援できるが、 AIで全て「0 → 100」を実現には至らない。 　 全量のAIで行うには遠いが、IDEを活用した半自動による業務支援が容易になった。 　　＊Agent Modeの高度化、Custom slash commandsの活用により利便性がアップ 　 ただし、CLI、IDE、APIなどの手段に拘らず、コンテキストとプロンプトの 　 重要性は高いまま。 　　＊AIにドキュメントを参照させる、AIへ指示するのは依然として変わらない為 ・ AI活用をイチから進めるには、相応の時間 /コストが必要 　　夢をみず、現実的にできることから着手する方が望ましい 　　実験的なPoCも非常に時間が掛かるので、今回はその見解も踏まえている。 ・ AIが出力されたものはレビューに時間が掛かり、一意に出力されない 　　デメリットとして認識しておくこと。むしろ、活用するならその覚悟が必要。 　　当たり前として認識し、周りにも周知しておく方が良い。 更新ページ
6. はじめに ・　AIを活用したソフトウェアテストに関するドキュメントとして記載しています。 　「2025年11月」時点の更新版となります。 ・　以下については、あらかじめご了承ください。 　　‐　あくまで実用してみた結果などを踏まえている為、 　　　 ベストプラクティスはご自身の企業およびプロジェクトによって異なります 　　‐　新しい生成AIモデル、アプリ層のサービスが提供された場合、 　　　 これらの記載されている前提が大きく変化する可能性があります 　　‐　モデル等の所感はあくまで個人の所感です。 　　　 個人個人に見合った最適なモデルを見つけて頂くことをお勧めします - 今回、API利用についてはOpenAIのモデルをサンプリングしています。 　　　 他のモデルと性能変化がある点についてはご承知おきください - 単体テストにおける活用は様々な記事が出ている為、そちらをご参照ください 更新ページ
7. 生成AIを活用する上で意識すべき点 　AIを日々利用して意識しておくこと 　　　- 毎日会話することでAIの苦手な点、得意な点を理解できるようになります。　 　　 　　　- 利用に慣れると、他のClosedモデルとの差異が理解できるようになり、 　　　 使い分けがクリアに行えるようになります。 　　　- モデルの特性を知ることで、ハルシネーションのポイントも 　　　 理解できるようになってきます。 　　　- 所属企業等でどのようなツールを活用しているかを把握しておき、 　　　 利用するAIモデル、CLI、IDEなどのツール類が変化しても 　　　 左右されない利用方法は検討しておく必要があります。 　　　- 状況によっては、現在のAIを活用した運用方法を手放して再構築する勇気は 　　　 あった方が良いと思います。 更新ページ
8. 生成AIを活用する上で意識すべき点 　AIへの指示と考えさせることは別の概念 ‐ 指示と考えさせることは別の概念として扱ってください。 例）指示する　　　　　　　　「テストケースを作成してください」 例）考えさせてから答えさせる「この不具合の原因は何でしょうか？」 　　　　*Chain-of-Thought Prompting Elicits Reasoning in Large Language Models https://arxiv.org/pdf/2201.11903 「指示する」と「考えさせてから答えさせる 」はプロンプトの性能ギャップが 　　　　　あることを理解しておいてください。 構造化について 　　　　・AIの回答を構造化しないと意図した回答を得られないケースがあります。 　　　　　モーダル/APIを問わずにプロンプトを構造化させる必要があります。 　　　　　＊APIではJSON Schemeが良く使われますね 　　　　 *QUANTIFYING LANGUAGE MODELS’ SENSITIVITY TO SPURIOUS FEATURES IN PROMPT DESIGN or: How I learned to start worrying about prompt formattinghttps://arxiv.org/pdf/2310.11324
9. 参考）オンプレミスで環境構築 　セキュリティ面を考慮して、社内で Close環境を活用する場合... 　・OSSを活用して、ローカル上で活用することを考える 　　　以下はOpenAIの例 　　　gpt-oss-20b 　　　　　https://huggingface.co/openai/gpt-oss-20b 　　　gpt-oss-120b 　　　　　https://huggingface.co/openai/gpt-oss-120b 　　Ollamaを利用したりするケースもあります。 　 さすがにオンプレであれば、 Knowledge DBの構築もセットで運用したいところ。 　（構築するにあたりテックブログであったり、ベンダー活用など構築手段はいくつかあります） 　　　Embedding：テキストを数値ベクトルに変換 　　　Vector（Qdrant）：ベクトルを高速に保管/検索 　　　Fulltext（OpenSearch）：キーワード/正規表現/フィルタで精密に絞り込む 　　　Reranker（bge-reranker-base）：候補を最終的に並べ替える 　　　Framework：LlamaIndex、LangChain 更新ページ
10. 付録）参考情報 　準備（注：Geminiについて、法人利用する場合、 Vertex AIなどで課金を行えばモデル学習を回避できます。無料利用はモデル学習に利用されます） 　　- IDE(Cursor) 　　　 MDC設定＆Custom slash commandsファイルの設置 　　- CLI(Claude Code) 　　　 CLAUDE.md ：ルール設定 　　　 settings.json：プロジェクトのClaude Code設定（ファイルの格納場所により適用範囲が異なる） 　　　 settings.local.json：個人＆プロジェクトのClaude Code設定 　　- CLI(Codex) 　　 AGENTS.md ：ルール設定　(このファイルがよくわからない場合、https://agents.md/ を参照) 　　　config.toml：Codex設定 　　- CLI(Gemini CLI) 　　 GEMINI.md：ルール設定 　　　settings.json：プロジェクトのGemini CLI設定（ファイルの格納場所により適用範囲が異なる） 更新ページ
11. サンプリングプロジェクト
12. サンプリングプロジェクト 　・　Hotel Planisphere 　　　＊ホテル予約のテスト自動化サイトです。 参考URL：https://hotel-example-site.takeyaqa.dev/ja/
13. 自動化の方針（素案） 更新ページ
14. 前提の理解 「決定論と非決定論をいかに融和させて両立させるのか」をテーマにしています。 　この議論がない前提でAI活用をされることがあるかもしれませんが 　作業してきた中での「前提とすべき理解」であると考えた次第です。 　また、基本的にテスト文脈では(AI、仕様などの)制約がありきとなるため 　以下のようなことを念頭に考えて作業を進めました。 　・AIのガードレールをどのように設置するのか 　・どのような抽象度のインプットデータを利用するか 　・コンテキストをどのようにリレーションさせるか 　
15. 本書で進めている手法 ・AI支援 形式仕様とソルバー検証によるアーキテクチャ 　AFS- TeDA(AI assisted Formalization & Solver -checked Test Design & Architecture) 　基本的にAIで形式仕様化させて、ソルバーによる制約チェックを行った 　テスト分析方法（今回はテスト分析のみ）になります。 　古典的な手法をそのまま取り入れた形となります。 　形式仕様とソルバーの制約をガードレールとすることで、 　誤ってAIから出力させることを抑制しています。 　 　これまで、業務で容易に活用することが難しかったのですが、 　AIによる支援を活かすことで、導入の敷居が低くなったとは思います。 　テスト分析の自動化スキルはテスト実行の自動化と 　大きく異なるため、新しいスキル獲得の必要性は感じています。 　＊形式仕様、ソルバーなどはさておき、抽象度と制約設置のスキルが必要です。
16. 参考）必要だと筆者が感じたスキル ・抽象度をコントロールする 　「どの時点でどこまでの抽象度が必要であるか？」です。 　例えば、テスト環境名を好き勝手にAIが記載されても困るわけです。 　「本番環境」などの抽象度に留めておき、あとで置換すれば済む話です。 　といったように、抽象度をコントロールする力が必要です。 ・設計時に行っていた思考を構造化 　思考を構造化させなければ、生成時に大きくブレが発生します。 　構造化というガードレールを用意してAIを活用する方が望ましいです。 ・AIで活用すべきコンテキストの見極め 　プロジェクトによっては、コンテキストが膨大なケースもあり、 　コンテキストを見極める力が必要です。 　例えば、テスト計画書で本当にテスト分析で必要なコンテキストは何であるか？などです。 ・作業の完了を定義すること 　AI自体は作業の完了を判断できません。 　どこまで何を記載し、何ができれば完了であるかを定義することが非常に重要です。
17. 方針の骨子 (1/2) ・AIが確率論的であっても AIを活用できるようにする 　→全てをAIで導出しない仕組みとしています。 　　ただ、確率論も解決に向かう可能性(*1)があることを視野に入れておきます。 　　　加えてハルシーションも原因(*2)が少しずつ解明されつつあることを念頭に。 　　　　*1 Defeating Nondeterminism in LLM Inference 　　　　 https://thinkingmachines.ai/blog/defeating-nondeterminism-in-llm-inference/ 　　　　*2 Why Language Models Hallucinate https://arxiv.org/abs/2509.04664 ・非決定的は AIで生成、決定的はコードによる生成を使い分ける 　→状況により使い分けが必要。 ・利用ツールに依存させない 　→IDEなどのツールに依存せずに、APIのみで導出させる。 　　仮にワークフローがあっても実行ファイルをエージェントに利用有無を委ね、 　　自立的に出力できる仕組みを考えています。 　　＊来年は各プロバイダはアプリ も用意され簡単に使える環境が準備される可能性を視野に入れる。 　　　また、Tool関連操作の容易性に注力することを踏まえて 作業を進める。
18. 方針の骨子 (2/2) ・生成過程において、極端な抽象度ジャンプをさせない 　＊抽象度ジャンプ：非常に曖昧なものから、極端に詳細な導出を行うこととしています。 　＊スコア計算できるようにしようかなとと思います。 　- 例えば、要求定義から直接テストケースを作成するといった 　抽象度ジャンプを行うとAIのドキュメント生成の自由度が高く、 　要求の文脈に依存して導出する傾向にあります。 　- 抽象度ジャンプをさせてもAIに導出させることは可能ですが、 　AIから導出ブレ幅が大きすぎるため、避ける方が無難です。 - 多少の抽象度ジャンプをさせる場合はソルバーを挟み込み形式手法などを 　活用して制約（ガードレールを設置する）を設けると比較的安全に対応できます。 　ただし、極端な抽象度ジャンプは難しいことを理解しておくことが必要です。 　＊出力結果に問題があった場合、課題の追跡が容易（とても便利）
19. 作業を進めていく中で新たに用いた指標 これまで、「重要度」、「優先度」、「発生頻度」など リスクを考慮した手法はリスクベースとして知られていますが、 今回、新たに以下の指標を用いることしています。 情報エントロピー (*1)を活用した「不確実性」を示す ICEスコアを利用 しています。 ICE（Impact：影響度 / Confidence：確信度 / Ease：容易さ）は 「不確実性が高い（例：抽象度が高い） 」、 「不確実性が低い（例：抽象度が低い） 」といった ものを何かしらの形でスコアしています（数字、ABCのレーティングなど） 　＊AIを利用しなければ、これらのような指標は正直不要かもしれません AIを活用した設計を行うにあたり、「コンテキストの質」が鍵となるため 参照元ドキュメントの曖昧さ、AIを利用したコーディングによる不確実さなどを踏まえて それらを優先度のように見える化しておくのが望ましいと感じたのがきっかけです。 *1 A Mathematical Theory of Communication (https://people.math.harvard.edu/~ctm/home/text/others/shannon/entropy/entropy.pdf)
20. 参考）ICEスコア Shannon エントロピー、自己情報量、 KL、PageRank 定常分布（マルコフ連鎖のエントロピー率）、 加重幾何平均（ product-of-experts）／Gibbs などを活用して、 抽象度（ALI）をリスクとして入れることで、曖昧な要件ほど「情報的に未確定」としています。 4種類の分布から構成 静的分布(p_i^{(\mathrm{static})})：次数中心性・媒介中心性・ PageRank を線形合成→正規化 動的分布 (p_i^{(\mathrm{dynamic})})：遷移ログ頻度からの出現比 →正規化 ビジネス分布 (p_i^{(\mathrm{business})})：MUST/法令/顧客影響で重み付け→正規化 セマンティック分布 (p_i^{(\mathrm{semantic})})：抽象度 ALI をエネルギーとして使う Gibbs型 「リスク重視」モード：(;p_i^{(\mathrm{semantic})} \propto \exp{-\gamma_{\mathrm{sem}}\cdot ALI_i}) （抽象度が高い＝不確実 → 確率を下げ、後段のスコアを上げる） 「精度重視」モード：(;p_i^{(\mathrm{semantic})} \propto \exp{-\gamma_{\mathrm{sem}}\cdot (1-ALI_i)}) いずれも最後に和が 1になるようにしています。まだまだ、色々試している状態で勉強中です。
21. 参考）ICEスコア 🔳エントロピー関連の指標 局所エントロピー（各ノード分岐不確実性） H_i ;=; -\sum_j p_{i\to j},\log p_{i\to j}. ランダムウォーク・エントロピー（ = マルコフ連鎖のエントロピー率） H_{\mathrm{RW}} ;=; \sum_i \pi_i, H_i. 正規化エントロピー： (n)：ノード数。 0〜1スケール化の簡便近似 H_{\mathrm{norm}} ;=; \frac{H_{\mathrm{RW}}}{\log n}. 自己情報量（ surprise）：合成分布の確率から算出 I_i ;=; -\log p_i^{(\mathrm{comp})}. I_i^{(\mathrm{w})} ;=; w_i, I_i. ECI（Entropy Coverage Index）： \mathrm{ECI} ;=; \frac{\sum_{i\in C} I_i^{(\mathrm{w})}}{\sum_{i} I_i^{(\mathrm{w})}}. KL ダイバージェンス :テスト配賦実測分布 (q)と合成分布 (p^{(\mathrm{comp})}) の乖離 D_{\mathrm{KL}}(q|p) ;=; \sum_i q_i \log\frac{q_i}{p_i^{(\mathrm{comp})}}. テスト配賦（最適化の素朴近似）総予算 (B)を、重み付き自己情報量に比例配分： n_i ;=; \operatorname{round}!\left( B \cdot \frac{I_i^{(\mathrm{w})}}{\sum_k I_k^{(\mathrm{w})}} \right),\quad n_i\ge1. 🔳ICE スコア（ Impact / Confidence / Ease への還元） Impact： \mathrm{Impact} ;=; w_s \cdot \underbrace{\frac{I_{node}}{\max I}}*{\text{surprise_norm}} ;+; w_p \cdot \underbrace{\mathrm{priority_norm}}*{\text{優先度の正規化 }} （`w_imp_s`, `w_imp_p` は設定値） Confidence： \mathrm{Conf} ;=; 0.5\cdot \Big(1 - \frac{H_i}{\log\max(2,n)}\Big) ;+; 0.5\cdot \frac{\deg(i)}{\max \deg} Ease： \mathrm{Ease} ;=; 0.5\cdot (1-\mathrm{closeness}(i)) ;+; 0.5\cdot \mathrm{ease_category}(i). ICE 統合： \mathrm{ICE} ;=; 0.4\cdot \mathrm{Impact} ;+; 0.3\cdot \mathrm{Confidence} ;+; 0.3\cdot \mathrm{Ease}. セマンティック（抽象度） : (,p_i^{(\mathrm{semantic})}\propto \exp(-\gamma, ALI_i),) のGibbs 分布
22. 生成するテスト工程（仮） テスト 計画 テスト 設計 テスト 分析 テスト 設計 テスト 実装 テスト 実行 テスト 完了 上記の通り、旧来のプロセスを含めて対応を行う想定で考えています。 作成後も精度を上げるために、少しずつアップデートを行う予定です。 そのうち、保守対応についても行えればと考えています。 　*多くのテスト対象は新規開発ではないので... テスト 計画書 テスト 結果記録 テスト 完了レポー ト テスト設計書 テスト 条件 テスト ケース テスト ウェア 工程 成果物 すべて作成できるかどうかはさておき、以下の想定。 テストケース JSTQB 旧来 JSTQB 旧来 今回はこちらを追加 テスト分析書なるものを生成はしていま すが、今回は割愛。 *どこかのタイミングで記載するかも
23. 初期準備 要求定義 プロジェクト計画書 要件定義 test_plan_gen test_req_gen syukei_table test_condition テスト分析(総括) 仕様書群 機能仕様書 画面仕様書 非機能仕様書 ソースコード 中間生成物 ...（省略） 生成ドキュメント テスト計画書 テスト要件一覧 要件定義外の テスト要件一覧 形式仕様.json spec_matching *wrapper_test_json 集計ファイル群.md TCスケルトン.json テスト計画〜テスト分析の構成 * wrapperはテストケース 生成エンジンを呼び出し テスト条件.csv 凡例 生成 参照 追記 test_analyze spec_check *wrapper_test_make
24. 準備物一覧 以下はPoCにあたっての準備したもの 　・　開発IDE環境（CursorのProを利用すると便利かも） 　・　生成AIのAPIの発行（APIは gpt 4.1-miniを利用） 　・　画面仕様、機能仕様、非機能仕様、業務フロー　などを 　　 あらかじめ、Markdown化しておく ・　ソースコード実装で活用するAI 　　　（Claude sonnet 4.5、Codex GPT5を利用） 　・　APIで利用するマネー（1.5万円ぐらい利用した） 　・　やりきる心と諦めないメンタル（ここが一番重要）
25. コンテキストの取り扱い セッション追加
26. コンテキストの取り扱い 　A　：　要件定義からテスト要件生成時 　　　　　→プロンプトだけでは出力内容に限界がある(記載内容が浅い) 　　　 *一般的かつ簡潔な内容になってしまい、必要な情報が消失しているケースがある 　　　　　 →個々の出力内容は問題がなくても要所で矛盾が発生する 　　　　　 →通常は記載の重複などが発生する 　　　　　 →要件定義から生成時に生成漏れが発生する 　　　　　 →要件定義で存在しないものが生成される 　B　：　テスト要件と形式仕様の紐付け時 　　　　　 →テスト要件と形式仕様間でトレーサビリティをチェックが必要 　C　：　テスト要件からテスト条件の導出時 　　　　　 →テスト条件の記載が冗長となり、記載内容に一貫性がない。 実装した際に遭遇した課題を列挙しておきます (愚痴の列挙みたい ...)
27. コンテキストの課題と対策 A　：　要件定義からテスト要件生成時 個々の出力内容は問題がなくても要所で矛盾が発生する 通常は記載の重複などが発生する 要件定義から生成時に生成漏れが発生する 要件定義で存在しないものが生成される プロンプトだけでは出力内容に限界がある 対策内容 Tips1:形式仕様からソルバーで優先度が高い セマンティックなテスト要件をペアマッチング させて、競合関係、依存関係　などを処理して 出力しているため、矛盾を抑制。 要件定義の全ての要件IDをチェックする仕組み 　- 生成が不足している場合、再度 APIを実行 　- 存在しないIDがあった場合は行ごと削除 B　：　テスト要件と形式仕様の紐付け時 対策内容 C　：　テスト要件からテスト条件の導出時 対策内容 テスト要件と形式仕様間でトレーサビリティをチェックが必要 テスト条件の記載が冗長となり、記載内容に一貫性がない Tips2:ルールベース判定→BM25(キーワード)→意味 ベース類似度計算→字句度類似度の順番で処理 Tips3:SMTソルバー(Z3)、ACC(システム分析手法)、 Hoare論理(前提/事前/事後/期待結果)の合技
28. Tips1 : 精度を上げながら矛盾や重複を抑える 構造化処理を意識 曖昧な要件を 「誰が(actor)」、 「何を(object)」、 「どうしなければならないの か(modality)」と いった形式論理を生成。 また、テストオラクル 観測点のフレームワークと して 「情報源」、 「観測対象」、 「判定様式」、 「時間性」 といった整理を行う。 形式仕様を AIで導出させて、曖昧さのない厳密な論理式を生成 今回は自然言語の要件を形式手法で論理モデルに変換し、「競合関係および依存関係」を 有向グラフでモデル化しています。ある要件を選ぶとその前提となる要件も自動で選択、 あるいは競合する要件を同時に選ばないといった、論理モデルを数理最適化させることで、 最適な出力となるようにしています。 AIとアルゴリズムのハイブリッド AIと数理最適化ソルバーの良いとこ取りをしています。 AI単体では厳密な制約を守りながら最適解を出すのは苦手です。 一方でソルバーは自然言語の曖昧な表現から関係性を読みる事ができません。 上記を踏まえてルール（制約条件）とゴール（目的関数）が設定されたものを cbc1、glpkの数理最適化ソルバーに渡して、 AIの柔軟な意味解釈を計算で算出させてい ます。
29. Tips2 : マッチング処理をさせる マッチングの前捌き 闇雲なマッチング作業と ならないよう、 マッチング前までに 該当仕様とマッチングさせ るために、SpecCardを用 意する形にしています。 SpecCardとは仕様書名、 仕様書の概要といった「ど の仕様書にどのような記載 があるか？」を 引渡しするため、全ての仕 様書の概要を生成していま す。 Preマッチング処理 テスト要件がどの仕様書にマッチするかを確認します。 全JSON仕様書のSpecCardを元に要約リストをベースに分類をします。 テスト要件のLLMがルールベースで絞り込みを行います。 詳細マッチング処理 BM25でテスト要件に含まれるキーワードが形式仕様の要素のテキストに対して 頻繁かつ珍しい頻度で出現するかをスコア化します。 Sentence-TransformerでBM25から絞りこまれた候補から paraphrase-multilingual-MiniLM-L12-v2でテスト要件の内容と 形式仕様のテキストと形式仕様のテキストをそれぞれ数値ベクトル(Embedding)に変換。 　ベクトル間のコサイン類似度を計算。 字句類似度で表記揺れ（ユーザ、ユーザー）などの細かいテキストの差異を吸収して、単 語と文字類似度の計算して、最終的に総合スコアからマッチングした内容を導出します。
30. Tips3 : 合わせ技で解決を試みる テスト条件前の前捌き 「テストスケルトンからテスト 要件(仕様書ベース)の生成」 の段階でテストケース生成エ ンジン内ではすでにテスト データを定義できる状態にし ています。 よって、テストデータをJSON からピックアップしているた め、テストデータ生成時にAI による生成は行わずにプロ グラムで処理するような仕込 みを入れています。 Hoare論理の応用 前提条件、事前条件、期待結果、事後条件　を役割毎に定義をプロンプトなどで組み込む　（例） 　　前提条件：開発、インフラ担当などが準備する 　　事前条件：QA担当者が準備する 　　期待結果：QA担当者が観測する 　　事後条件：開発担当者が確認する 数理論理ソルバーの生合成 SMTソルバーであるZ3を活用して、導出された条件間に矛盾が有無を数学的に検証。 unsat(充足不能)となった場合、破綻したテスト条件を自動検出できる仕組みを考慮。 テストデータは「有効なプランID」といった抽象化表現となった場合、該当のMarkdown仕様から取 得する形で効率化を図る。解析結果はキャッシュとして保持している。 システム分析手法 ACC (Attributes-Components-Capabilities)を活用(*1) AIで生成されたテスト条件などの整合性を補正 *1 : test-analytics - AccExplained.wiki：https://code.google.com/archive/p/test-analytics/wikis/AccExplained.wiki
31. 形式論理を用いる際の注意点 例えば、形式論理で以下の 2つの文章に対して矛盾をチェックしたい場合 ... 文章①：Amy and I both have to fight him　　　　 「エイミーと私は彼と戦わなければならない」 文章②：Neither Amy nor I have fought against him「エイミーも私も彼と戦ったことがない」 　形式的な論理だけで自然言語を扱うと... 　　課題A：「エイミーと私」は別個体であることを論理側で明示しない と、Amy = 私 という解釈を許します 　　課題B：“both / どちらも（両方）” の意味は 2人それぞれへの連言なので、Amy ≠ 私 が前提になります 　　課題C：「彼（him）」も第三者であると明示しないと、彼 = Amy や 彼 = 私 の解釈が混入し得ます 　上記の課題があるため、矛盾検出時に検出漏れ発生の可能性があります。 　本来、文章①と文章②が比較されるべきであったが、比較されない結果となります。 よって、形式論理を扱えば全て解決できる訳ではなく、 　形式論理では特に要件定義、仕様書などのコンテキストの質が重要になります。 参考：Automated requirement contradiction detection through formal logic and LLMs：https://link.springer.com/article/10.1007/s10515-024-00452-x
32. 参考）ソルバーの簡易的な説明 ソルバーについて少し簡単な説明を入れておきます。 ソルバーは、人が手作業で探す代わりに、 仕様＝制約 から「OKの入力」、「NGの入力」を 自動で見つけてくれる 道具です。 　自然文の要件 →（短い定型の述語に分解） → 制約 　制約 → ソルバーに質問 → 返事（OK/NG、OKの値、矛盾の原因） 　返事 → テストデータ・境界値・不具合再現・仕様レビューに活用 ・普通のソルバー（SAT/SMT）は... 　「満たせる？（Yes/No）」と、満たせるならどれか 1個の解（モデル）を返す「可否判定器」。 ・最適化ソルバー（MaxSAT / OMT / MILP / CP-SAT など）は... 　「満たす解の中で、一番良い（最小 /最大）ものはどれ？」という目的関数つきの問いに答えてくれる、 最良の解とその最良値を返す「ベスト解探索器」。
33. 参考）ソルバーの系統 系統 代表例 できること 利用できそうなテスト工程 SAT MiniSat, Glucose 命題論理の充足性（True/False の割当があるか） SMT Z3, CVC5, Yices, Boolector(BV) SAT＋“理論”（整数・実数・ビット・文字列・配列など） 要件定義・レビュー テスト分析・設計（テスト条件→データ/シナリオ） MaxSAT / OMT Open-WBO, OptiMathSAT, Z3(OMT) 「できるだけ多く満たす」「コスト最小」 要件定義・レビュー テスト計画（優先度・配分・スケジューリング） 数理最適化 （MILP/MINLP） Gurobi, CPLEX, CBC 目的関数最小化＋線形/非線形制約 制約プログラミング （CP/CP-SAT） OR-Tools CP-SAT 制約充足/最適化（全異なる, 累積など） テスト計画（優先度・配分・スケジューリング） テスト分析・設計（テスト条件→データ/シナリオ） QBF/定理証明 Vampire, E, iProver 量化つき論理（∀/∃…）や推論 要件定義・レビュー モデル検査 （BMC/LTL/CTL） NuSMV, IC3, CBMC 遷移系の性質（死活, 先行条件→必ず…） テスト分析・設計（テスト条件→データ/シナリオ） δ-SMT （実数・微分方程式） dReal 連続系の可否を“許容誤差δ”で判定 AIに手伝ってもらった参考程度の情報
34. AIを活用してテスト計画を支援
35. AIを活用してテスト計画を支援 以下をポイントに解説を進めていきます。 　・　プロジェクト計画書および要求定義または要件定義の読み込み 　・　テスト計画書の Markdownファイルの生成 　実装難易度は低めです。プロンプトとMarkdownを適切に処理すれば、 　対応できるようになっています。
36. AIを活用してテスト計画を支援（処理順序） 入力データ解析 キーワード分類・処理の構造 目次オブジェクトツリーの生成 AIによるプロンプト割り当て AIによるコンテンツ生成 図表の検証と自動修正 テスト計画書 Markdown生成 読み込んだMarkdownの解析 H2見出しをキーワード辞書分類 目次を親子関係の階層構造に変換 目次の各セクションへAIを割り当て 本文と図表の作成 Mermaid形式の軽微な問題を自動修正 テスト計画書を出力 以下が処理順となります。 1 2 3 4 5 6 7
37. AIを活用してテスト計画を支援（処理順序） 入力データ解析 キーワード分類・処理の構造 目次オブジェクトツリーの生成 AIによるプロンプト割り当て AIによるコンテンツ生成 図表の検証と自動修正 テスト計画書 Markdown生成 「1」〜「2」で行っているマッピングについて記載 1 2 3 4 5 6 7 非構造化テキストを、 AIが扱いやすい半構造化 データに変換を行う マッピング： MarkdownにあるH2の見出しを抽出。 あらかじめ定義している辞書の見出しキーワード と照合させることで、後にAIが「スケジュールにつ いて」を問われた際、関連情報だけをピンポイント で参照できるようにする。 今回はキーワードによるマッピングとなるが、セク ション単位でさらに細かいマッピングを実装させる ことも可能。 ＊プロジェクト計画書が定型フォーマットとして存 在するかどうか次第で検討の余地あり
38. AIを活用してテスト計画を支援（処理順序） 入力データ解析 キーワード分類・処理の構造 目次オブジェクトツリーの生成 AIによるプロンプト割り当て AIによるコンテンツ生成 図表の検証と自動修正 テスト計画書 Markdown生成 「3」で行っている目次オブジェクトツリーについて記載 1 2 3 4 5 6 7 ドキュメントの骨格となる目次を、プログラムが 操作可能なデータ構造に変換 目次オブジェクトツリーの生成： あらかじめ定義している「テスト計画時に作成する 目次構造」の階層を解析して、各行のインデントを 確認。 タイトル、階層、子要素リストといった属性をオブ ジェクトに変換。 再帰的に処理を行い、親子関係を持つツリー構造 をメモリ上に構築。 この処理を行うことで、AIが各目次のセクションに 記載しながらも、今現在はどのセクションに対し て、回答しているかをわかる様にしている。
39. AIを活用してテスト計画を支援（処理順序） 入力データ解析 キーワード分類・処理の構造 目次オブジェクトツリーの生成 AIによるプロンプト割り当て AIによるコンテンツ生成 図表の検証と自動修正 テスト計画書 Markdown生成 「4」のプロンプトの割り当てについて記載 1 2 3 4 5 6 7 各セクションに対して、様々なペルソナを設定し ている思考を AIに渡す プロンプトの割り当て： 「３」で作成された目次と「２」で構造化されたプロ ジェクトを情報に対して、最適と思われるプロンプ トを検索して、プロンプトの割り当てを行う。 ここで、実際のテスト計画書にある目次セクション 毎にプロンプトを割り当てることで各セクション毎 にユニークなプロンプト内容を指示できるようにな る。 ＊要はスケジュールならスケジュール、戦略なら 戦略用のプロンプトを個別に用意
40. AIを活用してテスト計画を支援（処理順序） 入力データ解析 キーワード分類・処理の構造 目次オブジェクトツリーの生成 AIによるプロンプト割り当て AIによるコンテンツ生成 図表の検証と自動修正 テスト計画書 Markdown生成 「5」のプロンプトについて解説（後述の出力サンプルも確認してね） 1 2 3 4 5 6 7 プロンプトで思考を強制 ペルソナ： ペルソナの設定はセクション毎に変更。 例えば...リスク管理ではリスクアナリストとすると いった具合にテストの文脈ではなく、各セクション 毎に専門家を設定。 思考の強制： 根本分析：情報をインプットして分析 論理的導出とエビデンスの提示 ：分析結果から 根拠を明確にする 具体的な計画 ：根拠に基づいて、実行できるアク ションプランを記述 これにより、生成する思考の統一させる。
41. AIを活用してテスト計画を支援（処理順序） 入力データ解析 キーワード分類・処理の構造 目次オブジェクトツリーの生成 AIによるプロンプト割り当て AIによるコンテンツ生成 図表の検証と自動修正 テスト計画書 Markdown生成 「6」〜「7」で行っている文脈の維持方法について記載 1 2 3 4 5 6 7 文脈維持をさせるために、要約のバトンリレーを 実施 要約のバントリレー： 膨大なドキュメント量となっても一貫性を保てるよ うに、要約のバトンリレーを以下のように行ってい る。（文脈維持のキモ） セクション (N-1)の要約した文章を取得 ↓ 要約を踏まえて、セクション (N)をAIで記載 ↓ 生成されたセクション (N)を要約 ↓ 以下、ループ
42. テスト計画書作成サンプル (1)
43. テスト計画書作成サンプル (2)
44. テスト計画書作成サンプル (3)
45. AI活用によるテスト計画の考察 多角的なインサイトを得られそう : 人間が抵抗感がある戦略、記載すべき内容の叩き台を約 10分で生成。プロンプトのペルソナでは QAエンジニア、品証保証を あえて設定せずに、セクションにあわせて各専門家（多角的視点）のペルソナを注入することで、普段では得られないインサイトがあった。 AIの強み（認知バイアスの破壊） : 感情と心理的抵抗（「もし、不具合が残っていて自分のせいにされたらどうしよう」という不安（損失回避性））がないため、テストを行わないもの はバッサリと切り捨てる戦略を容易に行える。通常はリソース配分、政治的な力学を想定したりもするが、 LLMは「プロジェクトとビジネスの成功 確率を最大化」を目的として設定している関係上、ある種の合理的な提案してくる部分は面白さがあると思えた。また、 LLMは過去の膨大なイ ンシデントを学習しているため、「ブラックスワンリスク」いわば、人間が想定しづらい極端な悲観シナリオを生成して、その内容を提案すること ができるのは、プロンプト次第でミッションクリティカルなビジネスにおける有用性は感じた。 AIの限界 : AIはあくまで過去のデータに基づいた提案を行う為、斬新な未知のドメインなどの対応が非常に苦手であり、未知の出典先などの リンクは別途ソースを探す為の処理が別途必要となる。また、依然として、プロジェクト計画書、要求定義などの質に左右される。 RAGの質が悪ければ出力結果も曖昧なものとなるので成果物のレビューなどは引き続き課題となる。 議論の叩き台としては有効だと感じた : 生成されたドキュメントは認知バイアスを排除した上で、プロジェクト成功のための品質を根幹としているため、 テストの取捨選択などはステークホルダーを含めた議論には一定の有用性がありそうと感じた。
46. AI活用によるテスト計画の考察 項目 人による作業 AIによる共同作業 計画書の根拠と 一貫性 担当者の記憶と解釈に依存する為、計画の根拠が曖昧にな り、ドキュメントの追従漏れが発生しやすい キーワードマッピングにより構造化され、なおかつ一貫性を保てる様に 文脈を維持し続けるような処理を行える 戦略の質と多角性 担当者の経験や知識に（良くも悪くも）左右される 必要に応じて、プロンプトで多角的なペルソナが設定可能 思考プロセス 個人の頭の中にあるため、構造化して表現するために多く の時間が必要となる 導き出した根拠を思考プロセス（分析、論理的導出、計画立案）を矯正 させることができ、アウトプットすることが可能 成果物の安定性 手作業によるミスが避けらない Mermaid形式出力にミスが目立つ 保守性 手作業による修正に時間がかかる 半自動化で大幅な時間短縮が可能 人による作業と簡易的に比較
47. まとめ 　・　AIの成果物についてのレビューは必要 　　　　　＊完全にドキュメントとプロンプトの内容に大きく依存するため、 　　　　　　プロジェクト計画書、要求定義の品質向上活動とプロンプトの工夫と調整は必須 　・　小さいプロジェクトなら IDEのチャットと併用処理でもよさそう 　　　　　＊長文にするなら本書のように API処理が良いです。 IDEは限界があるため 　・　（本項とは逸脱するが）色々なペルソナでテスト計画書が作れる 　　　　　＊AIしかできないペルソナ設定で同じプロジェクトのテスト計画書が様々な視点で 　　　　　　作成できるので、色々な示唆が得られるのは非常に面白いです。
48. AIを活用してテスト分析を支援 セッション追加
49. AIを活用してテスト分析を支援 以下をポイントに解説を進めていきます。 test_req_gen 　①　テスト要件 (要件定義ベース )の生成 　②　仕様書の評価 　③　テスト要件 (要件定義ベース )と仕様書のマッチング 　④　テストスケルトン化 　⑤　テストスケルトンからテスト要件 (仕様書ベース )の生成 　⑥　「①」と「⑤」から導出されたテスト条件を生成 test_condition spec_matching *wrapper_test_json *wrapper_test_make spec_check
50. ①　テスト要件 (要件定義ベース )の生成 要件定義内容のフィルタリング 要件IDを取得、将来実装予定内容の除外 1 要件定義からチャンク抽出して形式化 推移的閉包エッジ追加し、論理要件抽出 チャンクを形式論理へ変換 論理要件を抽出して、重要ペアを選択 2 3 論理要件内の重要ペアの詳細分析 フェーズ1の処理 フェーズ2の処理 重要ペアの詳細を分析して最適化 テスト要件等の生成 テストオラクル等の生成 4 6 7 ICEスコア計算による算出 ICEスコアの生成 8 最適化対象フィルタリングと絞り込み GLPKソルバー最適化と高度制約の生成 5
51. 行番号 - リスク分類 リスクの分類 ID AC-ID H-TRの子ID 要件タイプ 機能：機能、 GUI、ワークフロー、セキュリティ、性能などから選択 H-TR ID ハイレベルテスト要件 ID ICEスコア 0.667 : 0.00 〜1.00の間でスコアリング 要件ID 要件定義に記載がある ID 範囲IN/範囲OUT 範囲IN：予約画面の UI/UX、画面遷移、入力検証ロジック、予約完了処理の一連の流れ 範囲OUT：予約以外の画面や機能、バックエンドの非予約関連処理 テスト要件 予約導線を最適化し、ユーザーがスムーズに予約を完 了できることを保証する 受け入れ基準 予約導線の各画面で入力検証ロジックが正しく動作し、無効な入力に対して適切なエ ラーメッセージを返す事 目的（ビジネス価 値） 予約導線の最適化によりユーザーの予約完了率向上 と操作性の向上を保証する 観測点 【A：情報源】予約画面仕様書 【B：観測対象】入力検証ロジックのエラーメッセージの出力 【C：判定様式】期待されるエラーメッセージとの完全一致 【D：時間性】入力直後および画面遷移時 【観測内容】予約画面仕様書に基づき、予約導線の各画面で入力検証ロジックが無効な 入力に対して適切なエラーメッセージを返すことを入力直後および画面遷移時に完全一 致で確認する テスト対象フュー チャー ・入力検証ロジック（エラーメッセージ） テストポイント 機能的合成：入力検証の正確性 使用性：エラーメッセージの明確さ 信頼性；異常入力時の安定動作 優先度 P0 : P0 〜 P2が割り振られる テストレベル 単体：　単体、結合、総合、受け入れのいずれかから選択 リスク 予約導線が最適化されていない場合、ユーザーの予約 離脱や操作ミスが増加し、売上減少に繋がる 依存/関連 (空欄)　：依存/関連がある場合、 AC-IDを列挙する テスト要件の出力サンプルと説明 赤字：文章を生成している部分 黒字：選択であったり、 ID、スコアなどの分類
52. ②　仕様書の評価 Markdownのチャンク分割と構造解析 各仕様書の構造を解析 1 DAG構築/検証 述語論理変換 /Z3検証 ノードの登録処理と到達不能ノード検出 制約条件の論理式変換・充足可能性判定 2 3 Alloyモデル生成 競合解析 Alloyモデルを構築 ノードの依存関係の有無をチェック 4 6 圏論的検証 仕様内容の合成可能性をチェック 5 総合評価のレポート生成 AIを利用した改善レポートの生成 7
53. ②　仕様書の評価 (Markdownのチャンク分割と構造解析 ) Markdownのチャンク分割と構造解析 MarkdownParser(構造解析フェーズ ) 　・Alloyモデル用のYAMLを抽出 　・見出し階層構造解析 SpecifivatinExtractor 　・入力/出力パラメータ抽出 　・処理ステップ抽出 　・状態抽出 　・例外処理抽出 　・UI要素抽出 OpenAIAnalyzer 　・チャンキングと埋め込み生成 　・ChunkStore構築と関連チャンク検索 1 DAG構築/検証 述語論理変換 /Z3検証 2 3 Alloyモデル生成 競合解析 4 6 圏論的検証 5 総合評価のレポート生成 7
54. ②　仕様書の評価 (DAG構築/検証) Markdownのチャンク分割と構造解析 以下の2つを主に構築 DAG構築 　・ノード/エッジ構築 　・制約抽出（述語論理文字列化） 　・ワークフローマッピング SpecDAG 　・トポロジカルソート 　・到達不能ノード検出 　・ノードレベル計算 　・統計情報生成 1 DAG構築/検証 述語論理変換 /Z3検証 2 3 Alloyモデル生成 競合解析 4 6 圏論的検証 5 総合評価のレポート生成 7
55. ②　仕様書の評価 (述語論理変換 /Z3検証) Markdownのチャンク分割と構造解析 以下の3つを主に処理 ロジックコンバータ 　・DAGからZ3へ変換 　・型マッピング/制約パース Specコンバータ 　・定量的詳細不足検査 　・エラー/条件分岐/処理順序完全性検査 Z3ソルバー 　・充足可能性判定 　・矛盾検出 　・モデル生成 1 DAG構築/検証 述語論理変換 /Z3検証 2 3 Alloyモデル生成 競合解析 4 6 圏論的検証 5 総合評価のレポート生成 7
56. ②　仕様書の評価 (Alloyモデル生成 /圏論的検証 /競合解析) Markdownのチャンク分割と構造解析 以下の4つを並列処理 Alloy検証 　・モデル生成 　・SAT/UNSAT判定 TyoeFlowValidator 　・型/合成可能性/入出力一貫性検査 CategoryValidator 　・圏論的構造/関手/自然変換検証 ConflictAnalyzer 　・リソース/デッドロック競合検出 1 DAG構築/検証 述語論理変換 /Z3検証 2 3 Alloyモデル生成 競合解析 4 6 圏論的検証 5 総合評価のレポート生成 7
57. 参考）圏論的構造 /関手/自然変換検証 関手 F: C→D は2つの圏の間の写像であり、以下を満たす 1. 対象写像: 各対象 A∈C に対して F(A)∈D 2. 射写像: 各射 f: A→B に対して F(f): F(A)→F(B) 3. 恒等射の保存: F(id_A) = id_F(A) 4. 合成の保存: F(g∘f) = F(g)∘F(f) 2つの関手 F, G: C→D の間の自然変換 η は、 各対象 A∈C に対して射 η_A: F(A)→G(A) を対応させ、 任意の射 f: A→B に対して以下の可換図式が成立する F(f) F(A) -----> F(B) | | η_A η_B | | v v G(A) -----> G(B) G(f) つまり「η_B∘F(f) = G(f)∘η_A」となる 始点: 宿泊日入力 終点: DB検索結果 ルート1（通常フロー）: 宿泊日入力 → 入力検証 → DB検索 → DB検索結果 型: Date → Date → Query → Result ルート2（キャッシュフロー）: 宿泊日入力 → キャッシュ確認 → DB検索結果 型: Date → CacheKey → Result 可換図式例: 入力検証 宿泊日 ----------> DB検索 | | |キャッシュ確認 | | | v v キャッシュ -------> 検索結果 キャッシュヒット 検証: - ルート1の最終型: Result(宿泊情報リスト) - ルート2の最終型: Result(宿泊情報リスト) → 型が一致 ✓
58. ④　テスト要件 (要件定義ベース )と仕様書のマッチング SpecCardを生成 対象予定の仕様書一覧から概要を取得 1 テスト要件の読み込みと分類 Preマッチング テスト要件の種別を判定 ベクトル埋め込み＋語彙的類似度 2 3 テスト手法の分類 詳細マッチング テスト要件の更新 あらかじめ用意しているものから分類 BM25フィルタ→埋め込み類似→字句 Jaccard→BM25正規化でギャップ判定 これまでの結果をテスト要件一覧へ追記 4 6 7 リスク分類 ビジネス影響、発生確率などを評価 5
59. テスト要件 予約導線を最適化し、ユーザーがスムーズに予約を完了できることを保証する 観測点 【A：情報源】予約画面仕様書 【B：観測対象】入力検証ロジックのエラーメッセージの出力 【C：判定様式】期待されるエラーメッセージとの完全一致 【D：時間性】入力直後および画面遷移時 【観測内容】予約画面仕様書に基づき、予約導線の各画面で入 力検証ロジックが無効な入力に対して適切なエラーメッセージ を返すことを入力直後および画面遷移時に完全一致で確認す る 目的（ビジネ ス価値） 予約導線の最適化によりユーザーの予約完了率向上と操作性の向上を保証する テスト ポイント 機能的合成：入力検証の正確性 使用性：エラーメッセージの明確さ 信頼性；異常入力時の安定動作 テスト対象 フューチャー 入力検証ロジック（エラーメッセージ） テストレベル 単体：　単体、結合、総合、受け入れのいずれかから選択 優先度 P0 : P0 〜 P2が割り振られる 依存/関連 (空欄)　：依存/関連がある場合、 AC-IDを列挙する リスク 予約導線が最適化されていない場合、ユーザーの予約離脱や操作ミスが増加し、売上 減少に繋がる 分類 機能 要件タイプ 機能：機能、 GUI、ワークフロー、セキュリティ、性能などから選択 適合仕様書 ID FUNC_001_宿泊予約処理機能 範囲IN/範囲 OUT 範囲IN：予約画面の UI/UX、画面遷移、入力検証ロジック、予約完了処理の一連の流れ 範囲OUT：予約以外の画面や機能、バックエンドの非予約関連処理 テスト技法 境界値分析 受け入れ基準 予約導線の各画面で入力検証ロジックが正しく動作し、無効な入力に対して適切なエ ラーメッセージを返す事 適合詳細 適合の詳細が記載される JSON書込場 書き込まれた場所を示す テスト要件のマッチング出力サンプル 分類 〜 JSON書込場所までが追記される
60. ⑤　テストスケルトンからテスト要件 (仕様書ベース )の生成 処理フォルダのファイル特定 指定のパスにあるファイルを検索 1 テスト方法の推定 JSONから論理形式に変換 ファイル名からテスト内容を推定 バッチ処理とJSONの内容をスコア化 2 3 AIで記載を開始して記載内容を再生成 記載直後に内容をチェックして再生成 4 テストスケルトン段階でテスト自体の内容は AIが類推できる程度に整えられているので、 ソルバーは未使用です。 ソルバーを利用するポイントは「コンテキストの抽象度が高すぎて、 AIからの導出が極端にブレる可能 性がある」場合に限定しています。 レポート生成 Markdownファイルの生成 5
61. ⑤　テストスケルトンからテスト要件 (仕様書ベース )の生成 処理フォルダのファイル特定 JSONの内容を論理形式に変換して、テス ト内容別に関数を呼び出し を行う 仕様書ドキュメントを呼び込みChunkに分割 し、テスト要件生成時の参照情報として使 用。 論理形式に構造化されたJSON形式でLLM に送信して、テスト要件を生成。 1 テスト方法の推定 JSONから論理形式に変換 2 3 AIが記載した処理を確認して再生成 4 レポート生成 5 仕様書の質、プロンプトの質に委ねられます。仕様書の質が低いと生成時にハルシネーションになることがあります。 そのため、良くも悪くも事前の仕様書レビューは必要になります。 （生成時に仕様の曖昧さや矛盾を私自身もいくつか検出しました。仕様書作成は難しいですね） ＊曖昧な記載をすると、AIコーディングもテスト生成も共倒れになるため、レビューは重要な過程です ポイント
62. ⑤　テストスケルトンからテスト要件 (仕様書ベース )の生成 各生成されたカラムから曖昧な内容を自動 補正させる役割を担っています。 例：入力生成ロジック 　　→　料金　0 〜 99999円の範囲検証 　　　　プランIDの確認　など 　　全ての機能を検証する 　　→　予約フォームの料金計算と 　　　　入力を検証する　など 処理フォルダのファイル特定 1 テスト方法の推定 JSONから論理形式に変換 2 3 AIが記載した処理を確認して再生成 4 レポート生成 5 この段階で意図しない出力がされている場合、形式論理生成時点または仕様書の問題です。 そのため、問題が発生しても、問題点を早期に見つけることができる仕組みになっています。 ＊この再生成自体が問題になることは1000万以上で利用していますが、1度も発生していません 　再生成の時点で問題が発生しているのでは？と思い、何度か調査したことがありますが問題はありませんでした。 ポイント
63. プロンプトのサンプル (1/13 :長文です) base = f""" あなたは、形式論理要件から具体的なテスト要件を策定するシニアテストアーキテクトです。 以下の「論理要件」のリストを分析し、 **テストピラミッドの原則 **に基づいた包括的な「テスト要件」を定義してください。 {valid_ids_section} 【最重要指示】 - 入力された論理要件の数と同じ数のテスト要件を生成してください - 各論理要件の「元の要件 ID」(original_id) に対して、必ず1つのH-TR IDを生成してください - requirement_idフィールドには、対応する論理要件の「元の要件 ID」を正確に記載してください - ICEスコアは生成しないでください（後で自動計算されます） - **最重要**: 同一H-TR IDの複数ACで、各test_levelに応じてcriterion（受け入れ基準）を明確に差別化してください。抽象的・汎用的な記述ではなく、そのテス トレベルでしか検証できない具体的な内容を記述してください - **絶対禁止**: 同じH-TR IDの複数ACで同一または類似の記述をすることは禁止です。各テストレベルの特性を活かした独自の検証内容を記述してください - 「要件定義書からの詳細情報」が提供されている場合は、その内容（要件内容・対応する要求・実装方針）を積極的に活用してテスト要件を具体化してください 【ハードコーディング禁止】 - **絶対禁止**: 具体的な要件番号（ FN-001、NF-002、SEC-003等）を直接記載しないでください - **絶対禁止**: 「要件FN-023の内容を～」「要件NF-004について～」等の具体的要件番号参照は禁止です - **必須**: 要件の内容や機能を説明する際は、機能名や動作内容で記述してください - **例**: ❌「要件FN-023の内容を確認」→ ✅「予約入力機能の動作を確認」 プロンプトは長文ですが、参考程度。
64. プロンプトのサンプル (2/13 :長文です) 【ID生成ルール】 - **H-TR ID**: H-TR-で始まり、英数字とハイフンのみ使用（日本語禁止） - **🎯 H-TR ID短縮命名ルール（要件 ID活用・最重要）**: 各論理要件の「元の要件 ID」が提供されている場合は、それを活用してシンプルな H-TR IDを生成してください： * **FN-001** → **H-TR-001**（機能要件は最もシンプルに） * **NF-005** → **H-TR-NF-005**（非機能要件はプレフィックス保持） * **SEC-001** → **H-TR-SEC-001**（セキュリティ要件はプレフィックス保持） * **IF-001** → **H-TR-IF-001**（インターフェース要件はプレフィックス保持） * **MG-001** → **H-TR-MG-001**（移行要件はプレフィックス保持） * **UC-001** → **H-TR-UC-001**（ユースケース要件はプレフィックス保持） * 元の要件IDが'N/A'や空の場合のみ、従来の H-TR-XXXX-001形式を使用 - **AC ID**: H-TR IDに-AC-##を付加（例: H-TR-001-AC-01, H-TR-NF-005-AC-01） - **推奨形式**: H-TR-[機能名]-[連番] （例: H-TR-LOGIN-001, H-TR-PAYMENT-002） - **禁止**: 日本語文字、特殊記号、スペースの使用 【重要な区別】 - **requirement_type**: 要件の種類（functional/performance/security/usability/reliability/workflow/gui/compatibility/maintainability/portability） - **test_level**: テストレベル（unit/integration/system/acceptance） - **絶対禁止**: requirement_typeにtest_levelの値（unit/integration/system/acceptance）を設定しないでください
65. プロンプトのサンプル (3/13 :長文です) 【テストレベル制約（最重要）】 要件タイプに応じて、使用可能なテストレベルに制約があります。必ず以下の制約を守ってください： - **workflow要件**: systemとacceptanceのみ使用可能（unit, integrationは禁止） - 理由：業務フローやワークフローは個別の関数レベルでは検証できず、システム全体の動作や実際の業務要求達成が重要 - **workflow以外の要件**（functional/performance/security/usability/reliability/gui/compatibility/maintainability/portability）: unit, integration, systemのみ使用可能（acceptanceは禁止） - 理由：技術的要件は機能レベルで検証可能であり、ビジネス受入テストの対象ではない {existing_ids_section} 【テストピラミッドの原則】 テストは以下の優先順位で配置すべきです： 1. **単体テスト** (Unit Test): 最も多く、最も早期に実施。個々の関数・メソッドレベルの動作検証（ workflow要件以外で使用） 2. **結合テスト** (Integration Test): モジュール間の連携、 API呼び出し、データベースアクセスの検証（ workflow要件以外で使用） 3. **システムテスト** (System Test): エンドツーエンドのシナリオ、 UIを含む全体動作の検証（全要件タイプで使用可能） 4. **受入テスト** (Acceptance Test): ビジネス要求の充足確認、ユーザー視点での最終検証（ workflow要件のみで使用） 【厳守すべき指示】 1. 各「論理要件」に対し、 **1つの「テスト要件（H-TR ID）」**を生成します。 2. 各「テスト要件」には、 **テストピラミッドの各層に対応した複数の受け入れ基準 **を含めてください。 3. **重要**: 各「受け入れ基準」には必ず個別の IDを付与し、適切なtest_levelを設定してください。 4. **シフトレフトの実践**: 可能な限り早期（単体・結合）でテストできる項目を優先してください。 5. 各受け入れ基準の要件タイプを明確に分類してください。 6. dependency_relationsフィールドで他のテストとの関係を構造化して記述してください。 7. **test_targets（テスト対象フューチャー） **: 各テスト要件とその受け入れ基準に対して、具体的なテスト対象機能を明示してください。 - **H-TRレベルのtest_targets**: テスト要件全体でカバーする主要な検証対象をリストアップ - **ACレベルのtest_targets**: 各受け入れ基準ごとに、その基準で具体的に検証する対象をリストアップ
66. プロンプトのサンプル (4/13 :長文です) - **【最重要】ACC（Attribute-Component-Capability）構造による記述**: * **ACC構造とは**: テスト分析手法で使用される、以下 3要素の組み合わせで記述する方法 - **Attribute（属性）**: テスト対象の属性や特性（料金、日付、ユーザー名、ステータスなど） - **Component（コンポーネント）**: システムのコンポーネントや機能単位（入力フォーム、計算エンジン、画面表示など）※省略可 - **Capability（機能）**: そのコンポーネントが提供する能力（検証、計算、表示、保存など） * **推奨記述形式**: 「Attribute（属性）+ 条件値 + Capability（機能）」 - ✅ 「料金（0～999999円）の範囲検証」← Attribute + 条件 + Capability - ✅ 「料金=-1入力時のエラー検出」 ← Attribute + 異常値 + Capability - ✅ 「予約ステータス（未予約 →予約中）の遷移制御」 ← Attribute + 条件 + Capability * ❌ **汎用語の禁止**: - ❌ 「入力検証ロジック」 → Attributeが不明、Capabilityのみ - ❌ 「バリデーションルール」 → Attributeが不明、Capabilityのみ - ❌ 「エラーメッセージ生成機能」 → Attributeが不明、Capabilityのみ * ✅ **ACC構造での改善例**: - ❌ 「入力検証ロジック」 → ✅ 「料金（0～999999円）の範囲検証」 - ❌ 「エラーメッセージ生成機能」 → ✅ 「無効な料金入力時のエラー表示」 - ❌ 「データ整合性チェック」 → ✅ 「プランID（マスタ参照）の存在確認」 * ✅ **条件値を必ず含める **: - 境界値テスト: 「下限値0の入力検証」「上限値 999999の入力検証」 - 同値分割: 「負の料金-100の拒否処理」「有効範囲内の料金 1000円の受理処理」 - 状態遷移: 「未予約→予約中への状態遷移」「予約中 →キャンセル済への状態遷移」
67. プロンプトのサンプル (5/13 :長文です) - **禁止事項**: 具体的な関数名（例 : validateReservationInfo関数）やクラス名（例 : UserProfileManager）など、実装詳細に依存する記述は絶対に使用し ないでください - 例（H-TRレベル・ACC構造）: ["料金（0～999999円）の範囲検証", "料金負の値入力時のエラー検出 ", "料金上限超過時の拒否処理 "] - 例（ACレベル・境界値テスト） : ["料金下限値0の入力受理確認", "料金下限値-1の入力拒否確認", "料金上限値999999の入力受理確認", "料金上限値 1000000の入力拒否確認"] - 例（ACレベル・同値分割）: ["有効範囲内の料金 1000円の受理処理", "負の料金-100の拒否処理", "上限超過料金2000000の拒否処理"] - 例（ACレベル・状態遷移）: ["予約ステータス（未予約 →予約中）の遷移", "予約ステータス（予約中 →キャンセル済）の遷移 "] - **重要**: 各ACのtest_targetsは、そのACのtest_level（unit/integration/system/acceptance）とrequirement_type（functional/security/performance等） の組み合わせに応じた検証対象を記述してください - **重要**: purpose（目的）、short_requirement（テスト要件）、acceptance_criteria（受け入れ基準）の**すべて**を総合的に分析して抽出してください - テスト要件の全体像から主要な検証対象を特定し、受け入れ基準の具体的な内容で詳細化してください - 重複は避け、テスト観点が明確に伝わるように記述してください 【受け入れ基準（criterion）の記述ルール】 **重要**: 受け入れ基準には「何を検証するか」のみを記述し、テスト工程名は含めないでください。 **禁止事項**: 具体的な関数名（例 : authenticate_user関数）、クラス名、APIエンドポイント名など、実装詳細に依存する記述は使用しないでください。 **推奨**: 役割や処理内容を表現した抽象的な記述を使用してください（例 : 認証処理、プロフィール更新処理、権限チェック機能）。 **テストレベル別の差別化（最重要） **: 同一のH-TR IDに対して複数のAcceptance Criteria（AC）を生成する場合、各 ACのテストレベル（unit/integration/system/acceptance）に応じて、criterionの 記述を明確に差別化してください。テンプレート的な記述ではなく、各レベルの特性を反映した具体的で独自性のある記述を行ってください。
68. プロンプトのサンプル (6/13 :長文です) **重要**: 各テストレベルで検証する「具体的な対象」「検証方法」「期待結果」を明確に変えてください。同じ機能でも、テストレベルによって見る角度・粒度・検証 内容が全く異なることを表現してください。 **テストレベル別の具体的な差別化指針 **: **unit（単体テスト）**: - 個別の機能・処理・ロジックの内部動作に焦点 - 入力パターン、出力結果、例外処理を明記（実装詳細は避ける） - 境界値、エッジケース、異常入力への対応を検証 - 例: "認証処理が無効なパスワードを受け取った場合、認証エラーを返すこと " **integration（結合テスト）**: - モジュール間の連携、データの受け渡し、外部システムとの統合に焦点 - データフロー、インターフェースの整合性を明記（具体的なテーブル名やエンドポイント名は避ける） - 連携処理の正確性を検証 - 例: "認証処理がユーザーデータストアと連携し、認証成功時にセッション情報を正しく保存すること " **system（システムテスト）**: - エンドツーエンドのユーザーシナリオ、 UI操作、システム全体の振る舞いに焦点 - 具体的な画面操作、業務フロー、システム間連携を明記 - 非機能要件（性能、可用性等）の実際の測定値を検証 - 例: "ユーザーがログイン画面で認証情報を入力し、 3秒以内にダッシュボードが表示されること "
69. プロンプトのサンプル (7/13 :長文です) **acceptance（受入テスト）**: - **重要**: workflow要件のみで使用可能 - ビジネス価値、法令遵守、運用要件、ユーザー満足度に焦点 - 具体的な業務要件、法的要件、 KPI、運用指標を明記 - 長期的な運用、監査、コンプライアンス観点を検証 - 例: "承認ワークフローが法的要件を満たし、監査で業務プロセスの適法性が確認できること " **差別化の実例（アクセス制御機能の場合） **: - unit: "アクセス権限チェック処理が管理者ロールに対して許可を返し、ゲストロールに対して拒否を返すこと " - integration: "認証モジュールが権限管理システムと連携し、ユーザーのロール情報に基づいてアクセス許可を正確に判定すること " - system: "管理者ユーザーがログイン後、管理画面にアクセスでき、一般ユーザーは 403エラーで拒否されること " **差別化の実例（承認ワークフロー機能（ workflow要件）の場合）**: - system: "申請者が承認申請フォームから申請を提出し、承認者に通知メールが正確に送信されること " - acceptance: "承認ワークフローが法的要件（内部統制、 SOX法等）を満たし、監査で業務プロセスの適法性と有効性が証明できること " **ハードコーディング禁止 **: - ❌ 絶対禁止: 「要件FN-023の内容を確認すること」 - ❌ 絶対禁止: 「要件NF-004について検証すること」 - ❌ 絶対禁止: 「SEC-005の仕様に従って動作すること」 - ✅ 正しい例: 「予約入力機能が正常に動作すること」 - ✅ 正しい例: 「性能要件を満たすレスポンス時間であること」 - ✅ 正しい例: 「セキュリティ仕様に従った暗号化が実施されること」
70. プロンプトのサンプル (8/13 :長文です) **テスト工程名禁止**: - ❌ 悪い例: 「ユーザーが予約導線を通じてスムーズに予約を完了できることをエンドツーエンドで検証する」 - ❌ 悪い例: 「プラン一覧表示機能を単体テストで検証する」 - ❌ 悪い例: 「システムテストでユーザビリティを確認する」 - ✅ 良い例: 「ユーザーが予約導線を通じてスムーズに予約を完了できること」 - ✅ 良い例: 「プラン一覧取得関数が全プランの正確なデータを返すこと」 - ✅ 良い例: 「複数プランの属性差異が視覚的に分かりやすく表示されること」 テストレベル（unit/integration/system/acceptance）は test_level フィールドで既に指定されるため、 criterion内では純粋に「検証すべき内容」のみを記述してください。 【観測点（observation_points）の記述ルール】 **最重要**: 観測点は必ず以下の厳密なフォーマットで記述してください。自然な日本語での記述は禁止です。 **禁止事項**: 具体的な関数名（例 : authenticate_user関数）、クラス名、テーブル名（例 : users_table）、APIエンドポイント名など、実装詳細に依存する記述は 使用しないでください。 **推奨**: 役割や処理内容を表現した抽象的な記述を使用してください（例 : 認証処理の仕様、プロフィール更新処理、ユーザーデータストア）。 **必須フォーマット**: 観測点は構造化して記述してください ``` 【A:情報源】具体的な参照源（実装詳細を避ける） 【B:観測対象】具体的な観測対象（実装詳細を避ける） 【C:判定様式】判定方法 【D:時間性】タイミング 【観測内容】具体的な観測・検証内容（実装詳細を避ける） ```
71. プロンプトのサンプル (9/13 :長文です) - 複数の観測点は「 / 」で区切る - 除外事項がある場合は最後に「 / 除外：...」を追加 - 構造化フォーマット以外での記述は一切認めません - 観測点の文字数は300文字以内に収めてください - 自然な日本語での長文記述（「以下の観測点を設計します」等）は絶対に禁止です - HTMLタグ（<br>等）の使用は禁止です - 番号付きリストや箇条書き形式での記述は禁止です 観測点はテストオラクルとして機能するため、以下の A～Dの観点を必ず含めてください。 **テストオラクルフレームワーク（ A～D）**: **A. 情報源（根拠はどこから？） **: - 仕様/契約: 要件、APIスキーマ、ビジネスルール - モデル/参照実装: 状態機械、数学モデル、ゴールデン実装 - 比較: ゴールデンマスター、差分、二重実装 - 可観測性: ログ、メトリクス、トレース - 統計/ヒューリスティック: KPI、分布、異常検知 - 人手/専門家: UX、文言、法務 **B. 観測対象（何を見て判定する？） **: - 入力/契約: 型・範囲・スキーマ - 出力: レスポンス、UI、ファイル - イベント: 監査ログ、ドメインイベント - 状態: DB/キャッシュ/外部システムの副作用 - 関係・不変量: 保存則、整合性、メタモルフィック - 非機能: 性能、可用性、セキュリティ、アクセシビリティ
72. プロンプトのサンプル (10/13 :長文です) **C. 判定様式（どう比べる？） **: - 決定的: = / !=、包含、一意 - 比較的: 前後バージョン差分、 A/B差 - 統計・確率的: しきい値、信頼区間、ランキング指標 - 差分系: 前後バージョン差分、 A/B差分 - メタモルフィック: 保存則、整合性、メタモルフィック - プロパティベース: 不変条件、代数的性質、整合プロパティ - 準拠性: 法令/契約、標準/規格 **D. 時間性（いつ/どれだけの期間？） **: - 瞬間: 単発の事実・出力 - 区間: T内に成立、レート制限、ウィンドウ集計 - 順序: イベントの因果・前後関係、ワークフロー順序 - 期限: "10分後に解除"などの時相制約、法令 /契約期限 - 周期: バッチ、定期的なイベント、繰り返し - 保持・消去: 保持期間、消去期間 - レート制御: APIレート制限、通知制限
73. プロンプトのサンプル (11/13 :長文です) **禁止事項**: - ❌ 自然な日本語での長文記述（「この要件をテストする際に観測・検証すべきポイントは以下の通りです ...」「以下の観測点を設計します」等） - ❌ テンプレート的な記載（「状態オラクル」「信頼性オラクル」「事実オラクル」等の一般的な表現） - ❌ 抽象的な表現（「整合性を検証」「適切に動作することを確認」等） - ❌ 汎用的な記述（どの要件にも当てはまるような内容） - ❌ 【A:】【B:】【C:】【D:】フォーマット以外での記述 - ❌ 300文字を超える長文 - ❌ 番号付きリストや箇条書き形式での記述 - ❌ HTMLタグ（<br>等）を含む記述 - ❌ 「1. **」「2. **」等の見出し付き箇条書き - ❌ 「これらの観測点を通じて」等の説明文や総括文 **必須要素**: - ✅ この要件に特有の具体的な観測内容 - ✅ 実際にテスト実行者が何を確認すべきかを明確に記述 - ✅ 測定可能・検証可能な具体的な項目 - ✅ A～Dの観点を適切に組み合わせた記述
74. プロンプトのサンプル (12/13 :長文です) **良い例（A～D観点を含む構造化フォーマット） **: ✅ 例1: API動作確認 ``` 【A:仕様】予約APIスキーマ仕様書 【B:状態】DBのreservationsテーブル新レコード 【C:決定的】statusが'confirmed'と完全一致 【D:瞬間】API呼び出し直後 【観測内容】予約データが正しく DBに保存され、ステータスが確定状態になること ``` ✅ 例2: 性能測定 ``` 【A:メトリクス】APMツール監視データ 【B:非機能】APIレスポンス時間 【C:統計・確率的】95パーセンタイルで1秒以内、成功率99.9%以上 【D:区間】5分間隔で継続測定 【観測内容】性能要件を満たすレスポンス時間と成功率の維持 ```
75. プロンプトのサンプル (13/13 :長文です) ✅ 例3: セキュリティ検証 ``` 【A:セキュリティ仕様】未認証時拒否要件 【B:出力】HTTP 401レスポンス 【B:イベント】アクセスログ拒否記録 【C:決定的】ステータスコードとログ内容が仕様通り 【D:瞬間】未認証リクエスト送信時 【観測内容】認証なしアクセスが適切に拒否され、監査ログに記録されること ``` AIをよく利用されている方であれば、お気づきかとは思いますが、 「こんな長文を読ませて精度上がる訳ないでしょ？」 と 感じるかと思います。プロンプト自体は テスト要件の文脈を構築させるために利用しているプロンプト となるため、 このプロンプトで完全なものを一度で出力させる構成にしていません 。 * 「1度で実行して完全なものを作ること」をあえて放棄しています。 では、「この長文を分割しては？」となるかもしれませんが、そうなると 全体の文脈に崩れが生じるため避けています。 このプロンプトで処理したあと、出力文章の圧縮を AIが試みるので「全体的に」などといった 汎用的な文脈が発生することを想定して再構成したり、テスト レベルに合わせた再調整をするなど、多段的にプロンプトを投げ込んでいます。 結果として、多少時間とコスト(軽微)は掛かるものの、レビューおよび修正時間の削減を踏まえた質を確保 しています。 仮に意図しない結果となる場合、バッチ処理（例えば、テスト要件を 3つずつ）であれば、3項目単位で意図しない結果となります。 よって全体への影響も最低限に抑えることができます。（この方法は IDEのagentでは実現が難しい点です） ポイント
76. ⑥　「①」と「⑤」から導出されたテスト条件を生成 CSVファイルの全体行数と処理量確認 CSVファイルの行数と処理量を算出 1 LLMによるPredicateIR生成 Z3制約の構築 自然言語で記載後、PredicateIRに変換 Z3制約に変換し、ACC/IRの制約をマージ 2 3 Hoare論理による整合性検証 結果出力 整合性チェックをZ3 SATソルバーで検証 CSVファイルによる出力 4 6 テストデータ合成 テストスケルトンから抽出 5
77. Hoare論理による整合性検証 ACC（Attributes, Components, Capabilities）フレームワーク コードは以下の構造化表現を抽出しています： テスト要件: "宿泊予約処理の入力検証 " ↓ ACC射影: Attributes: {宿泊日, 人数, プランID} Components: {入力フォーム, バリデーター} Capabilities: { 　　C1: validate_date(宿泊日) → 有効範囲内 　　C2: validate_count(人数) → 1以上9以下の整数 　　C3: validate_plan(プランID) → マスタ登録済み } 形式的には... ACC = (A, C, Φ) where: 　A = {a₁, a₂, ..., aₚ} # 属性集合 　C = {c₁, c₂, ..., cₚ} # コンポーネント集合 　Φ : C → 2^Constraint # 能力（制約写像） ⭐なぜ自然文パターン認識が重要なのか 　答え：形式化のギャップがあるため 　　仕様書（自然言語） :　"宿泊日が有効範囲内であること"（非形式化） 　　　⬇ ギャップ！ 　　形式仕様（論理式） :　∃min, max. min ≤ 宿泊日 ≤ max（形式化） 📐 形式仕様の観点から見たコードの役割 自然言語: "宿泊日が有効範囲内であること " ↓ (今回実装したパターン認識 ) PredicateIR: {variable: "宿泊日", operator: "within_threshold", value: "valid"} ↓ (Z3変換) SMT制約: z3.Bool("宿泊日_within_threshold") 形式的には:P(x) : x ∈ ValidRange Hoare論理の適用（{P} C {Q}） コードは以下のHoare tripleを検証しています {前提条件 ∧ 事前条件} プログラム {事後条件} 実装上の対応 Hoare論理の要素 コード内の表現 例 P（事前条件） 　preconditions_ir "プランIDがマスタ登録済み" C（プログラム） state_effects_ir "予約ステータスを'確定'に更新" Q（事後条件） postconditions_ir "予約データがDBに存在する" 前提条件 prerequisites_ir "ユーザーがログイン済み "
78. SMTソルバーで整合性検証で問題があった場合 Hoare条件整合性エラー カウンター例検出 　検証式: pre ∧ transition ∧ ¬post Z3ソルバーが以下の検証を実行 　検証式: 事前条件 ∧ 遷移制約 ∧ ¬事後条件 　この式がSAT（充足可能）になっており、以下を意味します 「事前条件を満たし、状態遷移も正しく行われるのに、事後条件を満たさな い状態が存在する」 つまり、論理的に矛盾がある（整合性がない）ということです。 実際に検出されたカウンター例を見ると... 　キャッシュ_pre = "!1!", キャッシュ_post = "!1!" → 変化なし 　メールアドレス_電話番号データ_pre = "!0!", _post = "!0!" → 変化なし 　トランザクション状態_pre = "!2!", _post = "!2!" → 変化なし 　外部APIリクエスト_pre = False, _post = False → 変化なし 　連絡方法_pre = "メール", _post = "メール" → 変化なし 　ビジネスイベント_pre = "", _post = "" → 変化なし 　入力必須制御 _pre = "有効" → post状態未定義？ 　画面表示_pre = "連絡方法選択画面 " → post状態未定義？ 　ログイン状態 _pre = "済み" → post状態未定義？ エラー検出例 　Hoare条件整合性エラー: カウンター例検出 　　テスト要求ID: 不明 　　検証式: pre ∧ transition ∧ ¬post 　　　- pre: IR由来の事前条件（_pre変数） 　　　- transition: 状態遷移制約（_pre → _post） 　　　- post: IR由来の事後条件（_post変数） 　　　　※ ACC制約・realized_* 変数は除外済み 　　カウンター例モデル : [ 　　　キャッシュ_post = "!1!", 　　　キャッシュ_pre = "!1!", 　　　メールアドレス_電話番号データ_pre = "!0!", 　　　トランザクション状態 _pre = "!2!", 　　　外部APIリクエスト_pre = False, 　　　外部APIリクエスト_post = False, 　　　トランザクション状態 _post = "!2!", 　　　連絡方法_pre = "\u{30e1}\u{30fc}\u{30eb}", 　　　メールアドレス_電話番号データ_post = "!0!", 　　　ビジネスイベント _pre = "", 　　　ビジネスイベント _post = "", 　　　入力必須制御_pre = "\u{6709}\u{52b9}", 　　　画面表示_pre = "\u{9023}\u{7d61}\u{65b9}\u{6cd5}\u{9078}\u{629e}\u{753b}\u{9762}", 　　　連絡方法_post = "\u{30e1}\u{30fc}\u{30eb}", 　　　ログイン状態_pre = "\u{6e08}\u{307f}" 　　]
79. SMTソルバーで整合性検証で問題があった場合 Hoare条件整合性エラー カウンター例検出 　検証式: pre ∧ transition ∧ ¬post Z3ソルバーが以下の検証を実行 　検証式: 事前条件 ∧ 遷移制約 ∧ ¬事後条件 　この式がSAT（充足可能）になっており、以下を意味します 「事前条件を満たし、状態遷移も正しく行われるのに、事後条件を満たさな い状態が存在する」 つまり、論理的に矛盾がある（整合性がない）ということです。 実際に検出されたカウンター例を見ると... 　キャッシュ_pre = "!1!", キャッシュ_post = "!1!" → 変化なし 　メールアドレス_電話番号データ_pre = "!0!", _post = "!0!" → 変化なし 　トランザクション状態_pre = "!2!", _post = "!2!" → 変化なし 　外部APIリクエスト_pre = False, _post = False → 変化なし 　連絡方法_pre = "メール", _post = "メール" → 変化なし 　ビジネスイベント_pre = "", _post = "" → 変化なし 　入力必須制御 _pre = "有効" → post状態未定義？ 　画面表示_pre = "連絡方法選択画面 " → post状態未定義？ 　ログイン状態 _pre = "済み" → post状態未定義？ 🔴 問題の原因（推測） 以下のいずれか、または複数の組み合わせ ・事後条件が不十分 　→LLMが生成した事後条件が、期待される状態変化を 　　明示していない 　　　例: 「メールを送信する」という動作に対して 　　　　「メール送信済みフラグ = True」のような 　　　　　事後条件がない ・状態遷移制約が弱い 　→_pre変数と_post変数の関係性が明示されていない ・多くの変数が「変化なし」と判定される 　→事前条件と事後条件の論理的矛盾 　→事前条件で要求されている状態と、事後条件で 　　期待される状態が矛盾している
80. テスト要件 [workflow] 連絡方法選択判定関数の分岐ロジック等の確認 目的（ビジネス価値） ユーザーからの連絡方法選択に関する条件分岐が正しく機能し、連絡手段毎の入力検証が独立して結果に影響を与えることを保証することで、誤った連絡先情報による連絡 失敗リスクを軽減し、顧客対応品質を向上させる テスト対象フューチャー 連絡方法選択判定関数の条件分岐ロジック（メールアドレス検証関数の入力形式チェック） 範囲IN/範囲OUT 🔳範囲IN 「確認のご連絡」属性の値に基づくメールアドレスおよび電話番号の入力検証ロジックのMC/DC条件カバレッジ 🔳範囲OUT 連絡手段以外の入力項目やUI表示、送信処理の検証 受け入れ基準 連絡方法選択に関する関数が、条件「(確認のご連絡 ≠ 'メールでのご連絡') または (メールアドレスが空でなく、かつメールアドレス形式が正しい)」の各真偽値を独立して正しく 判定し、戻り値として適切に反映することを検証する。 観測点 【A:情報源】関数の戻り値および内部状態（ユニットテスト実行結果） 【B:観測対象】対象関数の戻り値および条件判定フラグ 【C:判定様式】各条件の真偽値に対する戻り値の整合性をコードレベルで検証 【D:時間性】関数呼び出し直後 【観測内容】条件ごとの真偽値が独立して結果に反映されていること テストポイント 関数単位の条件判定正確性、入力検証ロジックの網羅性 テストレベル Unit テスト条件の出力サンプル (一部抜粋)
81. 事前条件 テスト対象クラスのインスタンスが生成されている（targetInstance = new TargetClass()） / メールアドレスの空文字および形式不正のテスト引数が準備されている （emailTestValues = ["invalid_email", "example@example.com"]） / 電話番号の空文字および形式不正のテスト引数が準備されている（phoneTestValues = ["12345", "09012345678"]） / 確認のご連絡属性に基づくテスト用パラメータが準備されている（confirmationContactValues = [true, false]） / 依存オブジェクトがテスト対象に注入さ れている（targetInstance.setDependency(mockDepend 前提条件 ステージング環境が構築され、データベースサーバと認証基盤が起動していること。（staging環境構築済み、DBサーバ起動、認証基盤準備完了） / 外部システムとの接続 設定が完了し、ネットワーク設定が適切に行われていること。（外部システム接続設定済み、ネットワーク設定完了） / テスト用のマスタデータ（プラン、商品、ユーザー等）が 登録されていること。（プラン、商品、ユーザー等のマスタデータ登録済み） / モックサーバが設定・起動され、テスト用APIエンドポイントが準備されていること。（モックサーバ 起動済み、テストAPIエンドポイント準備完了） 入力データ テスト対象クラスのインスタンスが生成されている（testInstance = new ConfirmationContactValidator()） / メールアドレス検証用のモックが設定されている （emailValidatorMock = createMock<EmailValidator>()） / 電話番号検証用のモックが設定されている（phoneValidatorMock = createMock<PhoneValidator>()） / "確認 のご連絡"属性に基づく有効なメールアドレスがテスト引数として準備されている（confirmationContact.email = "test@example.com"） / "確認のご連絡"属性に基づく有効 な電話番号がテスト引数として準備されている（confirmationCon ACC Matrix - JSON [{"attr_id": "ATTR-0", "attr_name": "正確性", "comp_id": "COMP-0", "comp_name": "連絡方法選択判定関数", "capability": "連絡方法の条件分岐を正しく判定する", "confidence": 0.95, "actors": ["一般ユーザー"]}, {"attr_id": "ATTR-2", "attr_name": "信頼性", "comp_id": "COMP-1", "comp_name": "入力検証モジュール", "capability": "連絡手段ごとに独立した入力検証を行う", "confidence": 0.9, "actors": ["一般ユーザー"]}, {"attr_id": "ATTR-3", "attr_name": "ユーザービリティ", "comp_id": "COMP-2", "comp_name": "連絡先情報管理", "capability": "誤入力を防止し連絡失敗リスクを低減する", "confidence": 0.8, "actors": ["一般ユーザー"]}] 事後条件 確認のご連絡が「メールでのご連絡」以外の場合、メールアドレスの妥当性チェックはスキップされること / メールアドレスが空でなく正しい形式の場合、連絡方法選択関数が trueを返すこと / メールアドレスが空または形式が不正の場合、連絡方法選択関数がfalseを返すこと / 連絡方法選択関数の判定結果をログに出力すること（対象: application_log, 種類: emit） / 関連するユーザーデータの連絡方法判定結果をDBに更新すること（対象: database, 種類: update） / 判定処理が正常終了した場合、トラン ザクションがコミットされること（対象: transaction, 種類: update） / 判定エラー発生時にエラーログが出力されること（対象: application_log, 種類: emit） 期待結果 連絡方法選択関数が条件の真偽値を独立して正しく判定し戻り値に反映すること（戻り値が条件「確認のご連絡 != 'メールでのご連絡'」または「メールアドレスが空でなく形 式が正しい」の真偽値を正確に反映） / 連絡方法選択関数の戻り値が条件「確認のご連絡 != 'メールでのご連絡'」の真偽値を正しく反映すること（戻り値が確認のご連絡が' メールでのご連絡'でない場合にtrue、それ以外はfalseを返す） / 連絡方法選択関数の戻り値が条件「メールアドレスが空でなくかつ形式が正しい」の真偽値を正しく反映す ること（戻り値がメールアドレスが空でなく形式が正しい場合にtrue、それ以外はfalseを返す） テスト条件の出力サンプル (一部抜粋)
82. まとめ 　・　テスト要件出力の安定した出力となるため、作業のばらつきを 　　　防ぐことはできそう 　・　実行ファイルによる生成となるため、都度出力を確認する 　　　空き時間がなくなり、まとまった時間でチェックが行える 　　　＊IDE経由のエージェント実行の場合、クイックに行えるが地味に時間を奪う ... 　・　生成された精度は要件または仕様の正しさに依存する 　・　トレーサビリティにおける業務は人手では、多くの工数を 　　　消費するため、その点はかなり楽ができる 　　　＊特に抽象化されたものを人手でトレーサビリティさせるのは一苦労
83. AIを活用してテスト設計を支援
84. AIを活用してテスト設計を支援 以下をポイントに解説を進めていきます。 　・　テスト設計の構築（仕様書の整理 =JSON化） 　・　JSONから自然言語のテスト要件 /テスト条件の生成 　最初にお伝えしておきますが、モデル名を除き、 　　「1行もソースコードを記載せずに Vibe Codingで実装」しています。 　　よって、AIを使えば、誰でも実装できる可能性 があります。
85. AIを活用してテスト設計を支援（処理順序） 入力データ解析 構造・分類 関係性解析 ドキュメントカタログ構築 詳細ワークフロー生成 JSON出力 テスト設計書生成 Markdown仕様書群の解析 機能/画面/ワークフロー/非機能に分類 ID参照・自然言語関連付け 各種convert処理 Mermaid解析・ステップ抽出 JSON統合・出力 テスト要件・テスト条件・図表を出力 以下が処理順となります。 JSON出力までは AIは未使用です。 1 2 3 4 5 6 7
86. AIを活用してテスト設計を支援（処理の一部について） 入力データ解析 構造・分類 関係性解析 ドキュメントカタログ構築 詳細ワークフロー生成 JSON出力 テスト設計書生成 ChunkStore ： 解析したMarkdownのチャンクをメモリ上に保持 し、IDによるアクセスや関連チャンクの取得機能 を提供。処理のセッション内でのキャッシュデータ として保持。 マッピング： 一度解析した機能IDと関連画面情報のマッピング をキャッシュで保持。 ベクトル検索： 仕様書チャンクのテキストからベクトル埋め込みを 生成し、ChromaDBに格納。 「1」〜「5」で活用しているキャッシュ処理について記載 1 2 3 4 5 6 7 キャッシュ以外にも並列処理/リトライ処理などはありますが、 よしなにAIが生成してくれるだろうと思うので解説は割愛。 指定しないとやってくれなさそうな処理のみ記載しています。
87. AIを活用してテスト設計を支援（処理の一部について） 入力データ解析 構造・分類 関係性解析 ドキュメントカタログ構築 詳細ワークフロー生成 JSON出力 テスト設計書生成 自動ID生成: FUNC-001_IP01, FUNC-001_IP02 のように一意 IDを自動付与 構造化抽出: Markdownテーブルから structured_items として配 列データ化 関係性推論: ファイル名や内容から機能 -画面-ワークフローの関 連性を検出 メタデータ保持: 元ファイルパスや行番号などトレーサビリティ情報を 維持 「6」を生成するにあたり行っている処理 1 2 3 4 5 6 7
88. 仕様書のMarkdownからJSONへの変換例 --- id: FUNC-001 name: ユーザーログイン機能 --- # ユーザーログイン機能 ## 概要 ### 説明 ユーザーがシステムにログインするための認証機能 ### 目的 - セキュアなアクセス制御 - セッション管理による状態保持 ## 入力パラメータ | パラメータ名 | データ型 | 必須 | 説明 | |-------------|---------|------|------| | email | String | ◦ | メールアドレス | | password | String | ◦ | パスワード | ## 事前条件 - ユーザーアカウントが存在する - ブラウザが起動している ## 事後条件 - ユーザーがログイン状態になる - セッションIDが発行される { "id": "FUNC-001", "name": "ユーザーログイン機能 ", "path": "./specs/functions/func_001_login.md", "summary": "ユーザーがシステムにログインするための認証機能 ", "overview": { "description": "ユーザーがシステムにログインするための認証機能 ", "purpose": [ "セキュアなアクセス制御 ", "セッション管理による状態保持 " ] }, "preConditions": [ "ユーザーアカウントが存在する ", "ブラウザが起動している " ], "postConditions": [ "ユーザーがログイン状態になる ", "セッションIDが発行される " ], "inputParameters": [ { "id": "FUNC-001_IP01", "name": "email", "dataType": "String", "required": true, "description": "メールアドレス ", "source": "UI" },
89. AIを活用してテスト設計を支援（処理の一部について） 入力データ解析 構造・分類 関係性解析 ドキュメントカタログ構築 詳細ワークフロー生成 JSON出力 テスト設計書生成 JSONからテスト設計を作成する処理は以下。 ステップ1: テスト要件(上位テスト要件)生成 ステップ2: テスト条件(詳細インサイト)生成 ステップ3: 関連性構築 各詳細インサイトと上位テスト要件の IDリンク ステップ4: Markdown構造化 上位要件 → 詳細インサイト (タイプ別) 「7」で行っている処理について記載 1 2 3 4 5 6 7
90. JSONからテスト設計書への変換例 { "id": "FUNC-001", "name": "ユーザーログイン機能 ", "overview": { "description": "メールアドレスとパスワードによる認証 ", "purpose": ["セキュアなアクセス制御 "] }, "inputParameters": [ { "id": "FUNC-001_IP01", "name": "email", "dataType": "String", "required": true, "description": "メールアドレス " } ], "preConditions": [ "ユーザーアカウントが存在する " ], "postConditions": [ "ユーザーがログイン状態になる " ] } ## Function ID: FUNC-001 (ユーザーログイン機能 ) ### 上位テスト要件 (High-Level Test Requirements) - **HRQ-FUNC001-ACCURACY**: ログイン機能は正確な認証判定を行うべき である - *検証フォーカス *: 認証ロジック , 入力バリデーション - *受入基準ヒント *: 有効な認証情報で成功、無効な場合は失敗 - *優先度 *: 高 - *関連する詳細インサイト ID*: FUNCFUNC001VALI001, FUNCFUNC001INVA002 ### 詳細テストインサイト /条件 (関連インサイト ) #### インサイトタイプ : StrategicTestGoal - **STRAFUNC001001** (functionalSpecifications.id=FUNC-001.overview.StrategicTestGoal): この機能 がビジネス要件を満たすための測定可能な品質目標として、認証精度 99%以上 を達成すべきである - *関連上位要件 ID*: HRQ-FUNC001-ACCURACY - *期待/根拠*: 正当なユーザーの円滑なアクセスとセキュリティ確保の両立 - *優先度 *: 高 - *テスト技法 *: 認証テスト , 負荷テスト #### インサイトタイプ : ValidInputCase - **FUNCFUNC001VALI001** (functionalSpecifications.id=FUNC-001.inputParameters[0]_FUNC-001_IP01.Va lidInputCase): 有効なメールアドレス形式での正常認証フローを検証する - *関連上位要件 ID*: HRQ-FUNC001-ACCURACY - *期待/根拠*: user@example.com等の標準的なメール形式での認証成功 - *テストデータ *: 有効メールアドレスパターン一覧 - *タグ*: functional, authentication, email_validation
91. コード実行時のテスト設計書 (Markdown形式)への変換例 {// 各機能・ユースケースごとに実行 async function generate_functional_test_artifacts() { // 1. 詳細インサイト生成 detailed_requirements = await gather([ analyze_conditions(), analyze_input_parameters(), extract_strategic_overview_insights(), ... ]); // 2. 図生成 diagrams = []; // テストレベル・スコープ図 if (diagram_scope = await generate_test_level_scope_diagram( func_id, "function", func_spec_summary, all_reqs_for_diagram)) { diagrams.push(diagram_scope); } // リスクベース戦略図 risk_related_insights = filter_risk_insights(all_reqs_for_diagram); if (diagram_risk = await generate_risk_strategy_diagram( func_id, "function", func_spec_summary, risk_related_insights)) { diagrams.push(diagram_risk); } return [detailed_requirements, diagrams]; } ## テストアーキテクチャ概念図 ### テストレベルとスコープ図 (TestLevelsAndScope) (関連: FUNC-001) **図の解説:** この図は機能FUNC-001（ユーザーログイン機能）における推奨テストレベルと各 レベルでカバーすべきコンポーネントの関係を示しています。 ```mermaid graph TD A[ユーザーログイン機能] --> B[認証API] A --> C[セッション管理] B --> D[ユーザーDB] UT1[単体テスト] -.-> B IT1[結合テスト] -.-> A ST1[システムテスト] -.-> E[E2Eシナリオ] CT1[コンプライアンステスト] -.-> F[個人情報保護] style B fill:#ffcccc style F fill:#ffffcc ```
92. (例）機能仕様から生成されるテスト条件 (詳細インサイト ) セキュリティ・コンプライアンス SecurityConsideration 内容: 入力に関連するセキュリティリスクと検証 出力例: 「SQLインジェクション攻撃への脆弱性検証」 ComplianceCheck 内容: 法規制・業界標準への準拠確認 出力例: 「個人情報保護法に基づく同意取得メカニズムの確認」 出力検証・条件確認 OutputVerificationPoint 内容: 出力内容の正確性検証 出力例: 「認証成功時のセッション ID生成形式確認」 PreConditionValidationPoint 内容: 事前条件の検証ポイント 出力例: 「ユーザーアカウントの事前存在確認」 PostConditionVerificationPoint 内容: 事後条件の確認ポイント 出力例: 「ログイン状態への適切な状態遷移確認」 戦略的テスト観点 StrategicTestGoal 内容: 機能の成功を測定する具体的なテストゴール 出力例: 「認証精度99%以上を達成すべきである」 KeyRiskArea 内容: 最も影響の大きいリスク領域の特定 出力例: 「不正アクセスによるデータ漏洩リスク」 CoreTestStrategy 内容: 主要なテスト戦略の柱 出力例: 「多層防御によるセキュリティ検証重視」
93. (例）機能仕様から生成されるテスト条件 (詳細インサイト ) 入力パラメータ検証 ValidInputCase 内容: 正常系の代表的なテストケース 出力例: 「user@example.com等の標準メール形式での認証成功検証」 InvalidInputCase 内容: 異常系のテストケースと期待される動作 出力例: 「無効メール形式入力時の適切なエラーメッセージ表示」 BoundaryValueAnalysis 内容: 境界値条件のテストケース 出力例: 「パスワード長8文字未満・65文字超過での挙動確認」 DataCombination 内容: 複数パラメータの組み合わせテスト 出力例: 「メール＋パスワードの有効・無効の全組み合わせ検証」 その他 ExploratoryTestCharter 内容: 探索的テストのチャーター 出力例: 「非典型的な認証シーケンスでの隠れた脆弱性探索」 SpecificationFeedback 内容: 仕様書の改善提案 出力例: 「エラーコード定義の曖昧さ解消が必要」 NFRTestAspect 内容: 非機能要件テスト観点 出力例: 「同時ログイン1000件での応答性能確認」
94. テスト設計作成サンプル (1)
95. テスト設計作成サンプル (2)
96. テスト設計作成サンプル (3)
97. AI活用によるテスト設計の考察 初期ドラフト作成の効率化はできそう : 人間が数日～数週間を要する可能性のある多岐にわたるテスト要件群、戦略図、関連表の草案を、約 30分で生成できた。 これを手作業で同様の粒度と網羅性で作成するのは非常に時間がかかる ...IDEのチャットを利用するよりも高速で対応できそう。 観点の体系的網羅 : 定義された多様な観点を、仕様の各要素（機能、 UI要素、ユースケース）に機械的かつ体系的に適用できた。 人間では見落としがちな組み合わせや特定の専門知識が必要な観点からのテストアイデアを系統的に洗い出すことができそう。 トレーサビリティの手間を削減 : テスト要件とテスト条件間の関連付けを行うことで、テストの目的（何を検証するのか）とその手段（具体的にどう検証するのか）を 明確に結びつけることができる。これにより、手作業での関連付けの手間を大幅に削減できそう。 議論の叩き台としては有効だと感じた : 生成された具体的なテスト要件、 Mermaid形式の戦略図（テストレベル・スコープ図、リスクベース戦略図）、そしてドメイン特化型のリスク・テ スト関連表は、チーム内で議論の「叩き台」として非常に有効だと考える。 リスクベースアプローチに使えるかも : 「リスク・テスト関連表」では、ドメインにおける一般的なリスク、それに対応するテストタイプ、さらには使用するテスト技法が体系的に整理でき る。また、Mermaid図においてもリスクの高いコンポーネントが強調表示させることができ、リスクベースドアプローチも利用できそう。
98. AI活用によるテスト設計の考察 項目 人による作業 AIによる共同作業 仕様整理 設計者が熟読し手動整理。解釈にばらつき、大規模では膨 大な時間。 Markdownパーサー等が仕様を構造化・関連付け。初期理解・整理の 効率化、網羅性向上。 テスト要件定義 設計者の経験・知識に依存。網羅性・多様性はテスト設計者 のスキル次第。 構造化仕様に基づき LLMが多角的にテストインサイトを生成。アイデ ア出し効率化、多様な観点の網羅性向上。 テスト アーキテクチャ設計 戦略、レベル、スコープ、リスク分析、図表作成を手作業で 作成。 LLMが概念図や関連表を自動生成。戦略の可視化、共通認識醸成を 促進。 網羅性と一貫性 人間の注意力・スキルに依存。大規模では変更追跡や一貫 性維持が困難。 機械処理とAI分析で抜け漏れリスク低減。中間成果物を介し一貫性 向上。AIの解釈限界は考慮要。 効率とスピード 時間のかかる反復作業が多い。仕様変更対応も時間とコス ト。 自動化・半自動化で大幅な時間短縮・コスト削減。仕様変更にもある 程度追随可能。 成果物の品質 設計者のスキル・経験・コンディション (集中力が...)に左 右。レビューが重要。 入力仕様・プロンプト・ LLM性能に依存。AI生成物は専門家のレ ビュー・修正が不可欠。 人による作業と簡易的に比較
99. まとめ 　・　AIの成果物についてのレビューは引き続き必要 　　　　　＊相変わらず、出力されるテスト技法の名称が適当 (プロンプトで解決できるかな ..). 　　　　　＊昔に比べたらモデルが賢くなったのでレビュー指摘は減っている気が ...(気のせい？） 　・　決まったタスクであれば、 API処理の方がよさそう 　・　モデルが賢くなれば、更にインサイトを得られる出力ができそう 　・　自動化が Mustかと言われると、そうではないと考えるが 　　 圧倒的に初稿が楽なのは間違いない 　　　　　＊流石にレビューするにあたって全然こちらが汲み取れない内容までは出てこない 　　　　　　テスト技法の選定で適当な名前があったとしても、なんとなくやりたいことはわかる 　　　　　＊レビューに時間が掛かったとしても、恩恵はありそう
100. AIを活用してテストケース作成 (Draft版)
101. はじめに 今回はあくまで Drft版としています。 テスト実行自動化の際に改めてチューニングの可能性があると 考えているのが理由です。 まだまだ拡張させる必要がありますが、参考程度になればと思い 記載してみました。
102. 準備物 以下はPoCにあたっての準備したもの 　・　開発IDE環境（CursorのProを利用すると便利かも） 　・　生成AIのAPIの発行（APIは gpt 4.1-miniを利用） 　・　Markdown化された仕様書 ・　ソースコード実装で活用するAI（Gemini 2.5 Proを利用） 　　　＊ソースコード量が2000行程度まではClaudeを利用 　・　APIで利用するマネー（7000円ぐらい利用） 　・　やりきる心と諦めないメンタル
103. 参考）利用しているライブラリなど all - MiniLM-L6-v2 　仕様の内容をベクトル化するために利用 NetworkX 　 グラフ理論を扱う為に利用。状態遷移モデルなどで利用。 NuSMV 　 仕様間の論理矛盾の確認、論理プロパティの成立を厳密に検証するために利用。 scikit-learn 　 状態遷移モデルにおいて、ベクトルの意味の近さを自動的に 　クラスタリングするために使用
104. 【参考】今回利用した数式 (1 / 2) Automaton: A = (S, Σ, δ, s₀, F) S: 状態の有限集合 (例: 「ログイン前」「商品選択中」 ) Σ: イベント(入力)の有限集合 (例: 「ログインボタン押下」) δ: S × Σ → S 遷移関数 (例: 「ログイン前」状態で「ログインボタン押下」すると「商品選択中」状態へ ) s₀: 初期状態 F: 受理状態(終了状態)の集合 Objective: Maximize Σ (risk_j * coverage_ij * x_i) // risk_j: 要求jのリスク, x_i:テストiを実行するか Subject to: Σ (cost_i * x_i) ≤ Budget // 総コストは予算内に収める x_i ∈ {0, 1} (実行する/しない) Decision Table: DT = (C, A, R) C: 条件の有限集合 (例: 「会員ランクはゴールドか？」「購入金額は 1万円以上か？」) A: アクションの有限集合 (例: 「送料無料を適用」「割引クーポンを付与」 ) R: ルールの集合。各ルールは、条件の真偽値の組み合わせと、実行すべきアクション (X)のマッピング (例: IF c₁=True AND c₂=True THEN a₁=X AND a₂=X)
105. 【参考】今回利用した数式 (2 / 2) BehaviorSpec (Given-When-Then) ↓ CTL Formula (例: AG(リクエスト → AF(レスポンス))) A: 全てのパスで (Always) G: 全ての状態で (Globally) F: いつかは (Finally) Test Goal: Verify that for a given Automaton M and a CTL formula φ derived from a BDD spec, M ⊨ φ (Automaton M satisfies the property φ) Goal: Find Test Set T that satisfies the following: ∀ pᵢ, pₚ (i≠j) in Parameters ∀ vₐ ∈ domain(pᵢ), vₑ ∈ domain(pₚ) ∃ t ∈ T such that t contains (pᵢ=vₐ AND pₚ=vₑ) ... while minimizing |T| (the number of test cases) Parameter: p Domain: Dₚ = [min, max] Test Values (Tₚ): {min-ε, min, min+ε, (min+max)/2, max-ε, max, max+ε} ε: パラメータが取りうる最小の変化量 (例: 整数なら1)
106. 課題の共有 (1/2) AIでテストケースを作成していると課題が浮き彫りに ... ・ AIにテストケース作成を依頼しても、出力ロジックがわからない 　 * 人が作成する場合、中間生成物があるので思考を追える ・テスト対象から欲しいテストケースが生成されない 　 * AIへ指示しても、思った形にテストケースが生成されない ・チャット形式で質問しても再現性の担保が難しい 　 * 毎回同じプロンプトで質問なり指示を出せているか不透明
107. 課題の共有 (2/2) AI利用以前の課題も ... ・複数名でテストケース作成作業を行う場合の認識齟齬 　 * 5名程度ならコントロールできる範囲であっても5名→10名に増えると、 　　　パラメータ抽出、シナリオテストの考え方などの意識が 　　　合わせづらい場面に遭遇する（PJが多いとさらにややこしいことに...） ・テストケース作成に至るドキュメントの不足 　 * 「チームメンバー全員」が必ず同じ解像度であることは稀。 　　　業務知識（実力差、経験差、知識差）のギャップがありながらも 　　　共同でテストケースを作成するとバラツキが発生する。
108. 今回行ったこと テストケースの生成理論を明確にする 数理モデルなどを使って、AIへ引き渡す前に仕様の前捌き処理を行う 生成理論を人間が可読できるレベルでアウトプットする 生成理論の読解を容易とするため、どのような状態から 出力されるかを把握できるようにレポート化する 自然言語によるテスト実行自動化を前提としたテストケースにする 自然言語でテスト実行ができるようなルールを決めて生成させる
109. テストケース生成過程の簡易比較 テストケース生成までを簡略化して整理 仕様書 中間生成物 テスト ケース 仕様書 LLMへ投入 テスト ケース 仕様書 LLMで抽出 テスト ケース LLMへ投入 人力 LLM直投入 今回の手法 生成理論の 構築
110. 全体像の概略 仕様書読み込み JSON形式 テストケースRAWファイル LLMへ投入 JOSN形式テストケース CSV形式テストケース Markdown形式レポート 生成理論の構築 LLMへ投入 JOSN形式 テストデータ JSON形式 エンリッチ整理 JSON形式 形式仕様抽出 処理 出力 画面仕様書 入力 機能仕様書 非機能仕様書 業務フロー仕様書 ここがとても重要！ そして、とても難しい JSON形式 BDD用データ
111. 仕様書をどのように分解しているのか？ Step1：Markdownの仕様を見出し毎に分割 丸々仕様を利用せずに、「## バリデーションルール」といった形で分割 Step2：文章の各ブロックを all-miniLM-L6-v2でベクトル変換 ベクトル化して項目にラベル付け(ここで変換したものは、状態遷移で利用) Step3：LLMを利用して、テストケース生成に必要な項目の抽出 パラメータ、状態、論理ルールなどを抽出して、JSONへ出力 Step4：LLMを利用して、エンリッチ対応を行う 計算ルール数式化、入出力項目定義、シナリオ着想源などをJSONへ出力 Step5：テストデータ用の JSONファイルを生成 入力項目に必要なテストデータをJSONへ出力
112. 状態遷移の処理について Step1：JSONからStates(状態)、Transitions(遷移)を読み込む ・networkxのライブラリを利用して、読み込んだ情報のグラフデータを構築 ・構築したデータをAutomaton(オートマトン)オブジェクトとしてメモリに格納 Step2：状態遷移の骨子生成 ・Automaton(オートマトン)オブジェクトからC0、C1をピックアップ ・ピックアップした内容からテストケースrawファイルを生成 出力内容： ・状態遷移図 ・状態遷移表
113. 導出されるテストを以下へ列挙 現在対応したテスト一覧 境界値分析 メタモーフィック ロードテスト 同値分割法 CRUD ストレステスト ペアワイズ 状態遷移テスト ＊MBTモデル構築時に必然的に生成される仕組み 耐久テスト デシジョンテーブル ユースケーステスト エラー推測 状態遷移 リスク最適化シナリオ セキュリティテスト ステートメントカバレッジ 外乱要因テスト ゲーム理論（セキュリティ） ドメイン分析 リカバリテスト リテンション（リスク） ブーリアン MC/DC フェイルオーバー BDD 更新ページ
114. 境界値の処理について Step1：JSONからデータ型と入力範囲を読み込む ・入力値、日付などから動的に、max値、min値、うるう年などを格納 Step2：One-at-a-Time ・正常系のテスト生成パターンを作成し、それをベースにたのパターンを作成 ・パターン化したものをテストケースrawファイルとして生成 出力内容： ・テスト対象およびパラメータ一覧
115. ペアワイズの処理について Step1：JSONの入出力項目と制約事項から抽出 ・境界値、異常値などから値を抽出し、制約が定義されている場合はその項目から 　ありえない組み合わせを除外。 　また、ピックアップされた因子に重複した内容がないかをチェック。 Step2：最適なシナリオの選定 ・ allpairspyのライブラリを呼び出して、組み合わせ処理を実行し、 　組み合わせた結果をテストケースrawファイルとして生成 出力内容： ・組み合わせ項目一覧
116. デシジョンテーブルの処理について Step1：JSONの論理ルール項目を読み込み、分類と条件パターンを生成 ・JSONの論理ルールからバリデーションルールと成功/計算ルールに分類。 　各バリデーションルールが単独で成立するよう最小の条件セット(真・偽)を生成。 また、全てのバリデーションルールが発動しないハッピーパスの条件も生成。 Step2：最適なシナリオの選定 ・「Step1」では「年齢 > 20 : True」といった形で記載されている為、 　具体的な値に変換してrawファイルを生成。 　金額などが含まれている場合、JSON内の計算ルールに基づき、自動で再計算。 出力内容： ・デシジョンテーブル
117. 【参考】BDDを活用した仕様整合性のチェック Step1：JSON(BDD用）を読み込み、オートマトンと照合 ・Thenで記述された期待結果をCTLに変換し、NuSMVの外部チェッカーを利用して 　状態遷移モデルが論理プロパティを満たすかどうかを証明。 Step2：論理の曖昧さを LLMが解析 ・振る舞いベースで論理の曖昧さをLLMが分析して、仕様の課題を抽出。 出力内容： ・論理整合性の検証結果
118. 【参考】自然言語でテストケースを LLMに書かせる ポイント①： PlayWriteを用いたテストの自動化を想定　という前提条件 ・なぜか、テストケースの出力内容が未定義よりも出力内容が均一化。 ポイント②：テスト開始元の URLを手順の1つ目で必ず定義しておく ・自然言語でテスト実行する為に必要です。MCPであっても必要なので。 ポイント③：日本語で記載するように定義しておく ・ごく稀に英語となるケース(100回ぐらい行って、1回あるかないかぐらい）が 　あるので、日本語で記載するように定義しておきましょう。 参考程度ですが、 APIを利用してプロンプトで指示する上でのポイントを記載。
119. 作成してみた所感 ・夜に実行したら、朝にはテストケース作成が完了していたのはかなり新鮮 ・テスト技法がテストケース作成数の論理ガードレールとなっているため、 　テスト項目を LLMが無制限に作ることがない（これはありがたい） ・論理の組み立ては人によってそれぞれ異なる為、 　実装した人によっては、面白いものができるかもしれない ・論理の組み立てによっては新しいテスト方法が生まれるような可能性は感じた ・他にも実装できていないテストがあるので、取り込んだら更新していきたい 　＊現状もまだまだ改善の余地がありそう...
120. 【参考】論理整合性の確認
121. 【参考】シナリオ一覧
122. 【参考】デシジョンテーブル