Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à ゆもつよ博士論文説明資料公開
Similaire à ゆもつよ博士論文説明資料公開 (20)
Plus de Tsuyoshi Yumoto
Plus de Tsuyoshi Yumoto (9)
ゆもつよ博士論文説明資料公開
- 1. 入出力データの順序情報に基づく ブラックボックステスト手法に関する研究 A study on the method of black-box testing based on I/O data sequence システム情報工学研究科 リスク工学専攻 湯本剛
- 2. 発表内容 1. 緒論 2. システムテストにおけるブラックボックステスト の課題 3. テスト分析結果のばらつき傾向とその影響 4. I/O テストデータパターンによるテストケース 抽出手法 5. データ共有タスク間の順序組合せテストケース 抽出手法 6. 結論 2014/10/31 学籍番号 201230165 1
- 3. 問題意識 2018/2/5 1. 緒論 学籍番号 201430172 2 ソフトウェアの規模と複雑度合いは増加の一途 必要とされるテストケースの数はJonesの研究からみて増大する． 多くの人員がテストケースを作る仕事にかかわるようになる． Testing increaseinsize increasecomplexity Testing Development ・Requirement ・Specification ・Design ・CodeDevelopment ・Requirement ・Specification ・Design ・Code FP規模は 30年間で 10倍に増加 Longstreet Quantity FP Test cases Quantity FP Test cases テストケース数はFP(function point) 総計の1.3乗～1.5乗 Jones
- 4. 問題意識 • 多数の人員がテストケースを作成する工程に 必要とされているにもかかわらず，テスト ケースを作成するためにテスト対象を詳細化 していく際の明確に定義されたルールがない． – 投入された人員は個々の考え方に基づいてテスト 対象を詳細化してテストケースを開発する． – テストケース数の増加，漏れの原因となる． • テストの活動がソフトウェアの品質を確保す る役割を果たせない． – コスト増や納期遅延の原因となる． 2018/2/5 1. 緒論 学籍番号 201430172 3
- 5. 研究テーマ • 目的 – ブラックボックステストのテストケース抽出にお いて，テストケースを作成する工程に投入される 人員が、必要なテストケースの抽出において抜け 漏れを防止し，適正な数量にすること． • 研究内容 – テスト対象に対する入出力データの順序情報に基 づいてテストケースを抽出する手法を提案． – その適用評価を行い，合理的にテストケースを抽 出できることを確認． 2018/2/5 1. 緒論 学籍番号 201430172 4
- 6. 論文構成 • 本論文の構成は以下のとおり 2018/2/5 1. 緒論 学籍番号 201430172 5 第1章 緒論 – 問題意識と研究テーマ 第2章 システムテストにおけるブラックボックステストの課題 第3章 テスト分析結果の ばらつき傾向とその影響 第4章 I/O テストデータパター ンを使ったテストケース 抽出手法 第5章 データ共有タスク間の順 序組合せテストケース 抽出手法 第6章 結論 – まとめ 参 考 論 文 IEEE ICSTW 2015 (Conference) IEEE ICSTW 2016 (Conference) 電気学会論文誌 C 2017 (Journal)
- 7. 入力In タスク群Ta ｛Ta1,Ta2,Tai,Tat｝ 出力Out アプリケーションソフトウェアAS 状態St保持データDs ｛ Ds1,Ds2,Dsij,Dst｛ 源泉So 処理で利用するデータ のうち，データベースや 内部メモリに保存されて いるもの 研究対象のソフトウェアの構成 • アプリケーションソフトウェアASは，入力Inに対して，何らかの出力Out を返す． • ASの機能はInをOutに変換する処理（本論文ではタスクTaと呼ぶ）により 実現する． 2018/2/5 2.システムテストにおけるブラックボックステストの課題 学籍番号 201430172 6 タスクは該当のテストレ ベルから見た入力を出 力に変換する処理 広範囲でタスクの有効 性を決めているもの（保 持データとして実装する 場合もある）
- 8. 研究の対象 • テストレベル – システムテストレベル • 開発した単体の「タスク」が がすべて統合されるため， 規模の増大と複雑性の増加の 影響が大きい． • テスト開発プロセス – テスト分析とテスト設計 • テスト分析にてテスト対象を 詳細化 • テスト設計にてテストケースを 抽出 • テスト設計の種類 – ブラックボックステスト 2018/2/5 2.システムテストにおけるブラックボックステストの課題 学籍番号 201430172 7 V model (Forsberg,1995 et.al) Develop system Performance Specification and System VerificationPlan Integrate System andPerform System Verificationto Performance Specification テスト計画 テストプロセス テスト分析 テスト設計 テスト実装 テスト実行 終了基準の評価 テスト開発プロセス
- 9. テスト対象詳細化の問題 • 分類に対する一貫性の欠如 – 課題：テスト対象をテスト設計できるサイズまで詳細化し ていく方法が経験則や個人の考え方に基づいているため， 複数人で分析作業をした時の分類にばらつきが発生する． これは，テストケースの抜け漏れ，重複の原因となりうる． 2018/2/5 2.システムテストにおけるブラックボックステストの課題 学籍番号 201430172 8 同一組織の複数人を対象にテストケースを作成する実験を行った時のばらつきの結果
- 10. 機能間の統合に対するテスト抽出の問題 • 機能間の統合に対するテストへの既存の網羅基準適用 によるテストケース数増大 – 課題：機能間の統合でのテストケース数は, 単一の機能や 制御構造の和ではなく積となる. それに加え, システムテス トでは, 状態遷移に伴う時系列の組合せのテストも求めら れることから, テストケース数の爆発問題が生じる. 時系列 の組合せとして, 状態遷移テスト設計によるS1 網羅基準 (1 スイッチカバレージ )があるが．これは2 つの状態遷移 間における遷移数の積となり, 膨大なテスト工数を必要と する課題になる． 2018/2/5 2.システムテストにおけるブラックボックステストの課題 学籍番号 201430172 9 St’’ Data’’ Ds In1 Ta1 St’St Ouｔ1 副作用 In2 Ta2 Out2 Ds’
- 11. テストカテゴリベースドテスト • テスト分析での分類の一貫性欠如に対する先行研究 – 前述したテスト分析の課題を解決するために著者本人が提案し， ソフトウェア開発の現場にて適用している手法である. – 検証実験のための題材となる仕様書，模範解答が揃っており， それらの題材を使って実験を行った実績を論文にしている. • テスト分析の課題の更なる実験 の必要性 – 実験データが少ない． （1つのサンプルのみ） – 分析手法の効果が述べられている のみである. • 研究のベース – ３章での予備実験で利用 – ４章で提案する手法の前提 2018/2/5 2.システムテストにおけるブラックボックステストの課題 学籍番号 201430172 10 ⼊⼒調整 出⼒調整 貯蔵 サポート AUT外部 フィーチャ フィーチャ テスト実⾏ 変換 フィーチャ 機能 組合 せ 外部 観察 でき る 仕様 内部 に関 わる 仕様 相互作⽤ AU T外 部 ⼊⼒ 出⼒ 論理的機能構造（分類の参照モデル）
- 12. 予備実験の概要 • 目的 – テスト分析手法を適用する前のテスト分析での結果のばらつき傾向，及び その傾向と手法適用後の結果との相関を調べること. • 実験の概要 – ワークショップを通じてグループ単位，個人単位の実験を実施． • グループ単位の実験（2回実施） – ①1企業の同一製品開発チームのメンバーを４〜5人にグルーピングして実施（6サンプル） – ②オープンな研修にて，別々の企業の参加者を４〜5人にグルーピングして実施（２サンプル） • 個人単位の実験（1回実施） – テスト技術者コミュニティ主催のワークショップを通じて実施（57サンプル） – 前述した「テストカテゴリベースドテスト」を利用した． 2018/2/5 3.テスト分析結果のばらつき傾向とその影響 学籍番号 201430172 11 各自のこれま での経験 テスト分析手法の 知識 各自のこれまでの経 験をベースにした グループワーク 最初のグループワー ク＋知識 テスト 分析結果 参加者間の 意見交換 テスト 分析結果 テスト ベース 参加者間の 意見交換 各自のこれま での経験 テスト分析手法の 知識① (単一機能) 各自の経験をベース にした個人ワーク 各自の経験 ＋知識①での 個人ワーク 各自の経験 ＋知識①＋知識② での個人ワーク テスト 分析結果 テスト 分析結果 参加者間の意見 交換 テスト分析手法の 知識② (統合機能) テスト 分析結果 テスト ベース 個人単位では57人分のサンプルを収集グループ単位では８つのサンプルを収集
- 13. 実験の題材１ 2018/2/5 3.テスト分析結果のばらつき傾向とその影響 学籍番号 201430172 12 組み込みソフトウェア開発の仕様書 Bluetoothヘッドセット機能仕様書 • 「ボリュームコントロール」を題材として選択 – ボリュームコントロールの機能テストの テスト条件(仕様項⽬)／テストケースを 洗い出す演習を実施 • 仕様書の量 パワーポイントで12枚 • 演習時間 40分（演習題材の説明時間含む） • ⾒つけるべきテスト条件の数 ９ 例：音量調節／ボタン押下でボリュームが上下すること フィーチャ分類 テスト対象フィーチャ 起動/終了 起動/終了 ペアリング BlueTooth接続 再生 ワイヤレス再生 スイッチリモコン 通話 ハンズフリー通話 音声調節 ボリュームコントロール 初期化/リセット 初期化/リセット 機能⼀覧 グループ単位の実験①、個人単位の実験で利用
- 14. 実験の題材2 2018/2/5 3.テスト分析結果のばらつき傾向とその影響 学籍番号 201430172 13 エンタープライズシステム開発の仕様書 フライト予約システム機能仕様書 • 「新規フライト予約」を題材として選択 – 新規フライト予約の機能テストの テスト条件(仕様項⽬)／テストケースを 洗い出す演習を実施 • 仕様書の量 パワーポイントで12枚 • 演習時間 40分（演習題材の説明時間含む） • ⾒つけるべきテスト条件の数 23 例：うるう年判定、末日判定 ／うるう年、末日判定のチェックをすること 機能⼀覧 フィーチャ分類 テスト対象フィーチャ ログイン ログイン メニュー メニュー フライト予約 新規フライト予約 フライト予約更新 フライト削除 分析 注文グラフ 注文一覧 グループ単位の実験②で利用
- 15. 予備実験の結果（グループ単位） • テスト分析手法を適用する前のテスト分析での結果の ばらつき傾向 – 同一企業内での実験では各グループの記載方法や結果がば らつくことを確認した． • テスト分析手法適用後の結果 – 4/6(同一組織)，2/2（オープンセミナー）グループにて効 果を確認した． • 効果に対する相関を見いだすに到っていないので，傾向を分 析するためのサンプルを増やすため個人単位の実験を実施． 2018/2/5 3.テスト分析結果のばらつき傾向とその影響 学籍番号 201430172 14 B :手法適用後に変化がなく，期待結果に満たない - :手法適用後に変化がなく，期待結果に達している A :手法適用後に結果が増えているが，期待結果に満たない A+：手法適用後に結果が増えているが，期待結果に達している
- 16. 予備実験の結果（個人単位） • テスト分析手法を適用する前のテスト分析での結果のばら つき傾向 – 表に示す４パターンに整理できることを確認した． • テスト分析手法適用後の結果 – 論理的機能構造の要素毎に 分類し効果が出ている要素を 整理し，出力，貯蔵にて ルール適用の効果を確認した． 2018/2/5 3.テスト分析結果のばらつき傾向とその影響 学籍番号 201430172 15 書き方の分類 例 人数 仕様項目 ○○なときに☓☓となること 18 分析的 テストケース 事前条件、アクション、結果 19 実装的 P-V（パラーメータ/値） 例： 日付 3月8日 17 分析的 シナリオ １ なにをする ２ このあとなにをする ３ そうしてどうなる 3 実装的
- 17. 提案手法の概要 • 目的 – テストカテゴリベースドテストの課題である，テストベースを網羅的に 分析できる方法として，テスト実行時のデータの入出力（以降I/O と呼 ぶ）に着目し，テストベースを分析する際にテスト実行時のI/O の要素 で分解し網羅性を確認する方法を提案する． • I/Oテストデータパターン – テストを実行するためには，データをASに入力し，ASの出力を期待結 果と実際の結果で比較する. – この組み合わせは全体で9パターンとなりテスト実行時の単一の入出力 からみた全体集合となる． – ３章での検証実験 の結果を基にして， 各I/Oテストデータ パターンのデータフロー で全てのテスト条件が 特定可能であることを 確認した． 2018/2/5 4. I/O テストデータパターンを使ったテストケース抽出手法 学籍番号 201430172 16
- 18. 適用評価 • 実験の目的 – I/O テストデータパターンを使う分析手法が，現実のテス ト設計と比較して網羅的であることの確認を目的とする． • 評価方法 – 実験対象は，実在するオンラインのモバイル写真共有アプ リケーションを使った．モバイル写真共有アプリケーショ ンの実際の開発にて使われたテストケースと、提案する手 法で分析した結果を比較する． – テスト対象フィーチャのテストベースを分析し，画像デー タ，画像の情報、設定データ，外部コマンドを入力データ， 出力データとして扱うこととした. そして，テスト実行時 の追記したデータの流れをシミュレーションし，該当する I/O テストデータパターンを明らかにした．その後，I/O テ ストデータパターンと既存の分析手法であるテストカテゴ リベースドテストを併用してテスト分析を行った． 2018/2/5 4. I/O テストデータパターンを使ったテストケース抽出手法 学籍番号 201430172 17
- 19. 適用評価の題材3 2018/2/5 4. I/O テストデータパターンを使ったテストケース抽出手法 学籍番号 201430172 18 写真を扱うアプリです。 サーバー群 端末の画像 アップロード ダウンロード 画像参照 ・・・ ログイン/ログアウト アップロード ダウンロード 画像参照 ・・・ テスト対象： アプリが中⼼。 サーバーとのやり取 りにも着⽬するが、 APIのテストは別途 サーバー側で⾏う。 モバイル写真共有 アプリケーション Feature アカウント新規登録 ログイン ホーム 設定 マイフォト グリッドビュー フロービュー マップビュー ピクチャービュー 再生 スライドショー 写真詳細情報/画像一枚編集 画像移動・削除 アップロード ダウンロード 共有 静的画面
- 20. 適用評価の結果 • 網羅度合いの向上 – 実プロジェクトの結果と適用評価結果の両者を比較すると，I/O テストデータ パターンを利用したテスト分析の結果が実プロジェクトより多くの項目を特 定できたことが確認できている． • 考察 – P1 が特にテストカテゴリと実プロジェクトの差異が大きいことがわかる．P1 は外部からの入力を行い，外部に出力する最も単純なパターンであり，I/O テ ストデータパターンから見て，単純なことを確認する仕様項目が漏れている． 2018/2/5 4. I/O テストデータパターンを使ったテストケース抽出手法 学籍番号 201430172 19 0 10 20 30 40 50 60 70 80 90 Test Category Real Project Upload Grid View 0 5 10 15 20 25 30 35 40 P1 P2 P3 P4 P6 P7 P9 sum Upload Grid View I/Oテストデータパターン 実プロジェクト
- 21. 提案手法の概要 • 目的 – I/Oテストデータパターンだけでは対応できない，単一の 入出力だけではなく，統合して確認すべきテスト条件に着 目する. – 単一のタスクへのデータ入出力による副作用を他タスクの データ入出力で確認するテストケースを抽出する「順序組 み合わせテスト」を提案する． • 順序組合せテスト – 既出の順序組み合わせの手法である状態遷移テスト設計に おけるS1網羅基準ではテストケース数が爆発するが，S0 網羅基準では漏れが生じるという課題を解決する手法． – このテストは，ASの一部に変更を加えた際の波及を確認 する必要がある際に有用となる． 2018/2/5 5.データ共有タスク間の順序組合せテストケース抽出手法 学籍番号 201430172 20
- 22. Ini 変更タスクTai （R+1） Outi AS StlDsj So k (最初の実行と入出力) 変更Q Ini’ 波及タスクTai’ (R) Outi’ U：更新 U：更新 So k’ （二番目の実行と入出力） 提案手法の概要 • 変更が入りテストが必要なTaを「変更タスク」とよび，順序組み合わせ のテストが必要な後続のTaを「波及タスク」と呼ぶ．この2タスク間の制 御を行うのがStとなる． • テスト対象となる機能セットに対して，DFD，ERダイアグラム，CRUD ダイアグラムをテストベースとして利用して，テストケースを抽出する． 2018/2/5 5.データ共有タスク間の順序組合せテストケース抽出手法 学籍番号 201430172 21 変更波及は，タスク間の参照が状 態と保持データを介した範囲に限 られると考える この考えから波及を受ける タスクを特定する CRUD ダイアグラム ER ダイアグラム DFD 提案手法で利用するテストベース 機能セット タス ク タス ク タス ク タス ク 上位の制御フローは状態遷移が制御条件となる
- 23. 提案手法の概要 • テストケース抽出ルール – 提案する手法は，2 タスク間の順序組合せを対象 とする．2 タスク間の順序組合せの抽出は以下の ルールを適用する． • ルール1: 変更タスクの特定 • ルール2: 波及タスクの特定 • ルール3: 順序組合せのテスト ケース抽出 2018/2/5 5.データ共有タスク間の順序組合せテストケース抽出手法 学籍番号 201430172 22 変更タスク 波及タスク 上位の制御フローは状態遷移が制御条件となる
- 24. 中間の拡張CRUDダイアグラム ルール1: 変更タスクの特定 • 源泉からの入力エッジを持つ 変更タスクの特定 – DFDから見つける • データストアへの出力エッジ を持つタスク特定 – ER ダイアグラムからデータを 見つける – データ操作はCRUDダイアグラ ムから見つける • 中間の拡張CRUDダイアグラ ム作成 – この時点拡張CRUD図は作成途 中のものとなる 2018/2/5 5.データ共有タスク間の順序組合せテストケース抽出手法 学籍番号 201430172 23
- 25. ルール2：波及タスクの特定 • データストアを介した波及タスク 特定 – P{Ds}にエッジを持ちSoへ出力す るタスク – タスク間のデータ共有の組合せパ ターンに合致するタスク • 拡張CRUDダイアグラムの完成 2018/2/5 5.データ共有タスク間の順序組合せテストケース抽出手法 学籍番号 201430172 24 タスク間のデータ共有組合せパターン 変更タスク群 波及タスク群 拡張CRUDダイアグラム
- 26. ルール3: 順序組合せのテストケース抽出 • 変更タスクと波及タスクの組合せを 抽出 • データストアに対する操作の組合せ • テストケース表の完成 2018/2/5 5.データ共有タスク間の順序組合せテストケース抽出手法 学籍番号 201430172 25 論理的テストケース一覧 拡張CRUDダイアグラム
- 29. 結論 2018/2/5 6. 結論 学籍番号 201430172 28 研究の目的 テストケースを作成する工程に投入される人員が、必要なテストケースを網羅的に抽出し，抜 け漏れを防止できるようにすることを目的とし，適切な数のテストケースを開発するための手 法を提案し，その適用評価を行った． テストケースの抜け漏れ テストケースの増加 課題 テスト対象をテスト設計できるサイズまで 詳細化していく過程が経験則や個人の考え 方に基づいているため，分類にばらつきが 発生し，抜け漏れにつながる． システムテストでは, 状態遷移に伴う時系列 の組合せのテストも求められることから, テス トケース数の爆発問題が生じる. テーマ I/Oテストデータパターンを使った分析 順序組合せテスト技法 テスト実行時のデータI/O の要素で分類し網 羅的に分析する方法を提案 状態遷移を持つソフトウェアにおいて，保持 データを介して影響が生ずる場合のテストに 関して，順序組合せテストケースを抽出する 手法を提案 結果 提案した方法で特定した仕様項目と実プロ ジェクトで作られるテストケースと比較して，不 足している仕様項目の発見が可能であること が確認 従来手法である画面遷移図からS1 網羅基準 にて抽出した状態遷移パスと提案手法を比 較して，テストケース数の削減ができる効果と， S1 レベルの画面遷移の網羅では抽出できな いテストケースが抽出できる 効果を確認 IEEE ICSTW 2015 (Conference) 電気学会論文誌 C 2017 (Journal)
Notes de l'éditeur
- 本審査 60分のプレゼン（40分以上は行う） リスク工学専攻の湯本剛です. 本日は,現在,博士論文の執筆を進めております「入出力データの順序情報に基づくブラックボックステスト手法に関する研究」について発表いたします. どうぞよろしくお願いいたします. -------- タイトル 入出力データの順序情報に基づくブラックボックステスト手法に関する研究 概要 本研究はブラックボックステストのテストケース抽出に抜け漏れやケース数が増 大する課題に対して，テスト対象に対する入出力データの順序情報に基づいてテストケースを抽出する 手法を提案し，合理的に テストケースを抽出することを成果とするものである 予備審査のコメント 徳島大学 泓田先生 筑波大学 片岸先生 説明に文字が多すぎる．モデルなどでわかりやすく説明をしてほしい．どう素晴らしかったか？を説明してほしい 筑波大学 吉田先生 これだけで全てのことがテストできるとは思えない．他の既存のやり方とどうマッチングさせているのかとかを説明してほしい 筑波大学 倉橋先生 I/OパターンのP1が見つかって何が良いのか？ 参考文献の on IEEE は書き方が違う 公式には，発表は60～90分，質疑30分です． よって，湯本さんの場合は，公式には10:00-12:00の内訳は，下記の通りです． ・発表 60分 ・質疑 30分 ・最終試験 30分 場所： つくばキャンパス内総B811 セミナー室２ 池袋亀戸32分 ．
- 発表の内容ですが,論文の章構成に従い,ご覧の順に進めてまいります.
- まず,最初に本研究の背景です. ソフトウェア開発の中の品質を確保する主要な技術として, ソフトウェアテストがあります．求められるテストケースの数は ソフトウェアの複雑性と規模の急激な増加に伴い増加の一途を たどっています． ブラックボックステストの場合テストケースの数量は規模に対して1．３乗から1.５乗という研究結果があります． また，ソフトウェアの規模は30年間の間に10倍に増大しているという調査結果もあります．
- 必要とされるテストケースの増加に伴い，多くの技術者がテストケースの開発に携わるようになっています． それにもかかわらず開発の現場では，テストケースを作成するためにテスト対象を詳細化する際のルールが明確になっていないことが多いのが実情です． 投入された人員は個々の考え方に基づいてテストケースを開発し，それらがマージされていくことが，テストケースの増加，漏れの原因になっていると考えられます．
- そこで,本研究では,私自身の実務であるソフトウェアテストのテストケース作成方法に焦点を当て,，システムテストにおけるブラックボックステストでのテストケース作成工程に投入される人員が、必要なテストケースの抽出において抜け漏れを防止し，適正な数量にすることをテーマとしました． テスト実行時のテスト対象に対する入出力データの順序情報に基づいてテストケースを抽出する方法を２種類提案し，その適用評価から合理的にテストケースを抽出できることを確認しました．
- 本論文の構成ですが,ご覧の6章からなります. 2章でまずシステムテストにおけるブラックボックステストにおける課題と，関連する先行研究について述べる．また，本研究で使用するテスト分析手法について解説します 3章では前章で述べた課題を更に分析するために，実験を行い実験結果で確認を行いました． 4章ではテスト実行時のデータの入出力に着目し、テスト対象の分析を網羅的に行う手法の提案と適用評価を行いました． 5章ではテスト実行時のデータの入出力を順番に組み合わせる必要がある際に，重要な順序組み合わせを抽出してテストケースにする方法の提案と適用評価を行いました． 最終の6章は結論を述べます.
- 2章では,研究対象の範囲を明確にするために定義を説明し，そこで起きている課題を述べます． 本研究では，図に示す状態と保持データを持つアプリケーションソフトウェアに対するソフトウェアテストを研究対象にします． アプリケーションソフトウェアは，入力に対して，何らかの出力を返します． ソフトウェアの機能は，何らかの入力を出力に変換する処理により実現されていると考えられます． この処理を本研究ではタスクと呼びます． タスクは，該当のテストレベルからみた入力を出力に変換している1処理でです． そのため，タスクのサイズは，テストレベルによって決まります．
- ソフトウェアテストといっても非常に広い活動の総称であるため，研究対象を明確に定義したいと思います． テストには多くの段階があり，それはVモデルにて表現されることが一般的です． 本研究はVモデルでいうところのシステムテストを対象にします． 開発した単体のソフトウェアがすべて統合されるため，規模の増大と複雑性の増加の影響が大きく，私自身の問題意識と一致するためです． テストの活動は計画からテストケースの作成，実行，結果の評価までありますが，テスト開発プロセスと呼ばれる部分のテスト分析と設計を対象にします． 分析にてテスト対象を詳細化してテストケースが作れる粒度にしていきます．設計にて，テストケースとして完成させていきます． テストケースの種類はブラックボックステストを対象にします．
- テスト分析，設計の活動での問題点のひとつとして，テスト対象を詳細化する際の分類に対する一貫性の欠如があげられます． テスト対象をテスト設計できるサイズまで詳細化していく方法が経験則や個人の考え方に基づいているため，複数人で分析作業をした時の分類にばらつきが発生します． ４つの表は，予備実験の中で，ある企業にて実験をさせてもらった際に，仕様書からテストケースを各自がいつも行うやり方で作ってもらった時の結果になります． これらは個人の結果ではなく，４−５名でグルーピングして一つの回答を作ってもらった際の結果です． 同じ企業の同じプロダクトに携わる人たちでもこのように結果が変わります． これは，テストケースの抜け漏れ，重複の原因となりうると考えています．
- もう一つの問題として機能間の統合のテストケースの問題があります． 機能間の統合でのテストケース数は, 単一の機能や制御構造の和ではなく積となります それに加え, システムテストでは, 状態遷移に伴う時系列の組合せのテストも求められることから, テストケース数の爆発問題が生じます. 時系列の組合せとして, 状態遷移テスト設計によるS1 網羅基準 (1 スイッチカバレージ )があります．これは，図のようにある状態から処理を実行し 次の状態に遷移したあとにさらにもう一度処理を実行してその後の状態までを確認する網羅基準です． これは2 つの状態遷移間における遷移数の積となり, 膨大なテスト工数を必要とする課題があります．
- この2つの課題に対する研究を進めるための前提となる先行研究であるテストカテゴリベースドテストを簡単に説明します． 私自身がテストコンサルタントをしていた中で提案し現場に適用している手法であり，検証実験を行い論文にした実績があります． 一言で言うと，問題の一つであるテスト分析の際の分類に対する一貫性の欠如の問題を解決することが目的の手法です． 論理的機能構造という分類の参照モデルを使い，一貫性のある分類を定義することで，テスト対象の詳細化を行う際にばらつきが出ることを抑えるのが狙いです． この手法を３章の予備実験で使い現状調査を行いました． また，４章で提案するI/Oテストデータパターンはテストカテゴリベースドテストでは不十分であった網羅性の確保の考え方を捕捉する提案となります．
- 3章では,前章で説明した問題に対する実証データを得るための実験を行った結果について述べます． 実験のためのワークショップを数多く行いましたが，本論文ではデータ収集が想定通り行えた３つの実験の結果を利用しました． 最初はグループ単位の実験結果の収集を2回おこない，8つのサンプルを収集しました．その後個人単位の実験結果の収集を行い，57人分のサンプルを収集しました． ワークショップでは，最初に演習に使うテストベースを示し，参加者が各自の考えに基づいたテスト分析を実行してもらいます． その後，テスト分析手法と実施手順を説明して手順に沿って再度テスト分析を実行してもらい，テスト分析手法の知識を与える前と後の回答を検証実験のデータとして利用しました. 正解は演習の模範回答を利用しました．
- 題材は2つ用意していました．いずれもサイズは同じ程度で作ってあります． 一つは組み込みソフトウエア開発をイメージした仕様書です． ヘッドセットの１機能を対象にしています．
- もう一つはエンタープライズ向けソフトウエア開発をイメージした仕様書です． 飛行機予約システムの１機能を対象にしています．
- グループ単位での予備実験の結果です． 各自の考え方に基づいてテストケースを作成すると結果がばらつくことがわかりました． 先ほどの分類の一貫性の欠如のスライドにて示した通りになります． テスト分析手法適用後の結果では，８グループ中６グループにて，分類に一貫性を持たせるだけでテストケースの不足が解消されることを確認しました． ただし，解消されるにあたり何かしらの相関関係を見出すにはいたりませんでした．サンプル数が８つと少ないことも原因の一つだと考え，個人単位での データ収集を行うことにしました．
- 個人単位の予備実験の結果になります．
- そのために現実のテスト設計の結果と， I/O テストデータパターンを使った分析結果を比較する． 491 151ケースあり 59，22項目
- 変更タスクで保持データを追加/更新し，波及タスクがその保持データを使う場合が該当する 変更タスクから波及タスクへのデータフローを決定するのは，2階層の制御フローである 状態は順序組合せの制御フローを決定する上で影響を及ぼす
- 最後に全体を総括します.