テスト設計をより良くするモデリングと観点分析/ Improve Test Design with Modeling

Transcript

1. テスト設計をより良くする モデリングと観点分析 井芹 洋輝 WACATE 2019 招待講演 2019/12/15 1

2. 自己紹介 ⚫井芹 洋輝（オリンパス/ASTER） ⚫組込み製品の開発・テスト・コンサルタント 現在：SET/SETIチームを率いる ⚫社外活動： • JSTQB技術委員、U30テスト設計コンテスト審査委員長 • 講演、著作複数

   • システムテスト自動化標準ガイド、Androidアプリテスト技法、 ソフトウェアテストPRESS、 Proposal for Enhancing UTP2 with Test Aspectsなど 2

3. 自己紹介：WACATE歴 ⚫WACATE2009夏～2010夏： 参加者 • BFP賞1回 ⚫2010冬～2015夏： 実行委員 • 手がけたもの： 組み合わせテスト、リスクベースドテスト、

   TPI NEXT、レビュー、 テストのリバースエンジニアリング、クラシフィケーションツリー法 3

4. このセッションの目的 ⚫テスト設計でのモデリングの活用所を知る • 活用例 • 状態遷移テストでの具体例 ⚫前提知識 • 状態遷移テスト・Nスイッチカバレッジを知っている •

   UMLを知っている 4

5. この資料について ⚫内容のSNS展開可 ⚫資料は公開 • https://speakerdeck.com/goyoki/improve-test-design-with-modeling 5

6. アウトライン 1. モデリングとは 2. 目的・制約とモデリング 3. 目的・課題・観点とモデリング 4. テスト設計を支えるモデリング 5.

   テストケース導出でのモデリングの活用 6. まとめ 6 前提知識 動機付け 本題

7. モデリングとは 7

8. モデル、モデリング（モデル化）とは ⚫「モデル化とは、認知したいと考えている構造、振る舞い、 現象などについて、別の効率的な形式や方法による表現を 用いることである」 • (「The Nature of Modeling」。訳はSQuBOK V2)

   ⚫「モデルとは『ある人によっての、ある状況、あるいはある状 況についての概念の明示的な解釈』です」 • (「UMLモデリングの本質」にて、システム仕様の分析学の引用を用いた解 説) 8

9. モデル、モデリング（モデル化）とは ⚫「目的を達成するために、対象の特定の特質を、特定の形 式で表現する」のがモデリング ⚫目的達成にフォーカスするため、以下を活用する • 抽象化する • 削る • 構造化する

   • 形式化する • 分割する 9

10. モデリングの目的 1. 理解を助ける • 例）大規模な実装をクラス図で抽象化し俯瞰 2. 思考を深める • 例）マインドマップでアイデアを掘り下げ 3.

    共有を助ける • 例）ロジックツリーで第三者に問題を明示化 4. 協力を支える • 例）構造モデルを使って分担決め 5. モデル対応ツール・手法の恩恵を得る • 例）モデル駆動テストで仕様を検証 10

11. モデリングの目的 1. 理解を助ける • 例）大規模な実装をクラス図で抽象化し俯瞰 2. 思考を深める • 例）マインドマップでアイデアを掘り下げ 3.

    共有を助ける • 例）ロジックツリーで第三者に問題を明示化 4. 協力を支える • 例）構造モデルを使って分担決め 5. モデル対応ツール・手法の恩恵を得る • 例）モデル駆動テストで仕様を検証 11 モデリングで より効率的に物事をこなす より難しい物事をこなす 仲間とシナジーを発揮する モデリング＝ 表現の工夫で人間の 能力を拡張する

12. モデルの記法の例：多種多様に存在する ⚫モデリング記法の例 • UML ：オブジェクト指向開発のための記法 • SysML ：システムエンジニアリングのための記法 • PFD

    ：開発プロセスのための記法 • その他多種多様。アドホックな図解もモデリング ⚫モデリングを活用する手法の例 • QC7つ道具/新QC7つ道具：品質管理のためにモデルを活用 • RUP/UP ：ソフトウェア開発のためにUMLを活用 • SaPID ：問題解決のためにモデルを活用 • VSTeP ：テスト分析・設計のためにモデルを活用 12

13. 目的・制約とモデリング 13

14. 目的と制約は何をモデリングするかのインプット ⚫モデリングには無数の選択肢がある ⚫モデリングは目的を達成するために制約内で実施する • 目的：モデリングで達成を助けたいもの • 制約：モデリングの自由度を制限するもの 14

15. 目的に合わせたモデリング 「机のモデリングをしたい」 ⚫目的：「机が入口を通り抜けられるか知りたい」 • モデリングするもの：机の幅・高さ・奥行 ⚫目的：「机を提供部品で組み立てたい」 • モデリングするもの：机の組み立て手順、完成図 15

16. 制約に合わせたモデリング ⚫技術制約 ：プロジェクトでの技術的な実現性の制約 • 例）技術的に実現不可能な設計モデルは許容されない ⚫ビジネス制約 ：ビジネスの成否にかかわる制約 • 例）コストがかかりすぎる設計モデルは許容されない •

    例）チームの開発リソースを超える設計モデルは許容されない ⚫モデリング制約 ：モデリング作業やその成果物管理の制約 • 例）モデル作成者が管理できないほど膨大なモデルは作れない 16

17. 【補足】モデリングは不確定性を持つ ⚫同じ目的・制約下でもモデリングにバリエーションが生まれる • モデラーの能力・指向 • 不確定要素の多さ • 複数の解決策の両立 ⚫一般的にモデリングは探索的 •

    システマティックに決まらない • 様々な観点で分析し、揺さぶりをかけ、フィードバックで洗練させていく 17 プロセス手順や方法論の指定に従ってモデリングすればOKではない 制約に合わせながら目的達成を目指して探索していく

18. 目的・課題・観点とモデリング 18

19. 何をモデリングするかは観点に紐づく 目的・制約とモデリングを紐づけるのが観点 ⚫目的・制約や課題へ対応する際の観点が、何をモデリングす るかを方向づける ⚫観点とは • 「観点： 物事を見たり考えたりする立場。見地。」（大辞林 第三版） 19

20. 観点とは 20 上からの姿は？ 正面からの姿は？ 重さは？ ••の安全性規格を満たしてる？ ・どれも観点 ・着目したい特質・側面の 方向性が観点

21. 観点とモデリング 21 課題 課題解決のアクション結果 観点 観点に基づいて得られた成果物 課題解決を考えるときの切り口 目的・制約 目的達成にあたっての課題 1..*

    1..* • 目的達成や課題解決の手段を 考える切り口が観点

22. 観点とモデリング 22 課題 課題解決のアクション結果 観点 観点に基づいて得られた成果物 課題解決を考えるときの切り口 モデルの種類 モデリング結果 目的・制約

    目的達成にあたっての課題 1..* 1..* • 目的達成や課題解決の手段を考える 切り口が観点 • 観点の一部はモデルの種類と紐づい ている その観点に基づく分析＝モデリング

23. 課題解決における観点とモデリング 23 課題 課題解決のため のアクション結果 観点 机が入口を通り抜けられるか確認する 机の幅と高さと奥行きは？ 入口の高さと幅は？ 高さ・幅の

    モデリング結果 高さ・幅・奥行の モデリング結果 目的・制約 大きな机を部屋に入れたい 3次元モデル 2次元モデル

24. 観点とモデリングの関係性を扱う参考文献： ISO/IEC/IEEE 42010:2011 24

25. 【補足】観点とモデリングの相互フィードバック 25 課題 課題解決のアクション結果 観点 モデルの種類 モデリング結果 目的・制約 • 観点に応じてモデリングを行う

    • モデリングのやりにくさを感じたら、観点・課題 に立ち戻る • モデリング結果から観点を派生させる

26. アウトライン 1. モデリングとは 2. 目的・制約とモデリング 3. 目的・課題・観点とモデリング 4. テスト設計を支えるモデリング 5.

    テストケース導出でのモデリングの活用 6. まとめ 26 前提知識 動機付け 本題

27. テスト設計を支えるモデリング 27

28. テスト設計ではモデリングは重要スキル 活動全体で活用できる 1. テスト設計のコミュニケーションを効率化する • ステークホルダとの連携を支える • 仲間との協業を支える 2. テストケースの導出を効率化する

    • より複雑・曖昧・大規模な対象に対応する • ミスが少なく的確なテストケース導出を支える • テスト分析・設計成果の管理を効率化する 3. 有益なテストツールやテスト手法を適用可能にする 28

29. 用途1：テスト設計のコミュニケーションを効率化する ステークホルダとの連携を支える ⚫多様なロール・視点を横断した、情報共有、同意形成の 効率化にモデリングを活かす • ファシリテーションのサポート ⚫例）アクティビティ図でテスト活動の責務分担を話し合う 29

30. 用途1：テスト設計のコミュニケーションを効率化する テストの仲間との協業を支える ⚫テスト活動についての作業分担、役割分担を支えるために モデリングを活用する • 分担をサポート/レビューなどの連携をサポート/協業によるシナジー発揮 ⚫例）ツリーモデルで仲間とアイデアを出し合う 30

31. 用途2：テストケースの導出を効率化する ⚫モデリングで構造整理、抽象化を行い、複雑な対象でもテスト設計 可能にする • 例）対象をクラシフィケーションツリーで整理しオールペア法を適用する 31

32. 【補足】用途2：テストケースの導出を効率化する ⚫主要なテスト設計技法がモデリングに依存している 32 テスト技法 活用するモデル 同値分割法 同値パーティションのリスト 境界値分析 一次元グラフ 状態遷移テスト

    ステートマシン図/状態遷移表 ユースケーステスト ユースケース図/ユースケース記述 欠陥分類法 欠陥分類のリストやツリー 原因結果グラフ 原因結果グラフ デシジョンテーブル法 デシジョンテーブル クラシフィケーションツリー法 クラシフィケーションツリー 直交表/オールペア法/nワイズテスト テスト条件と値のリスト ドメイン分析テスト 2次元グラフ 制御フローテスト アクティビティ図

33. 用途3：有益なテストツールやテスト手法を適用可能にする ⚫例）モデル化し、モデル検査で仕様不具合を検査する 33 int thread0inside = 0; int thread1inside =

    0; void threadZero() { while (true) { while (thread1inside) {} ...OtherTask... thread0inside = 1; ...CriticalRegionOfThreadZero... thread0inside = 0; ...OtherTask... } } void threadOne() { while (true) { while (thread0inside) {} ...OtherTask... thread1inside = 1; ...CriticalRegionOfThreadOne... thread1inside = 0; ...OtherTask... } } MODULE main VAR thread0inside : boolean; thread1inside : boolean; th0pc : 1..5; th1pc : 1..5; ASSIGN init(thread0inside) := FALSE; init(thread1inside) := FALSE; init(th0pc) := 1; init(th1pc) := 1; next(thread0inside) := case th0pc = 2 : TRUE; th0pc = 4 : FALSE; TRUE : thread0inside; esac; next(thread1inside) := case th1pc = 2 : TRUE; th1pc = 4 : FALSE; TRUE : thread1inside; esac; next(th0pc) := case th0pc = 1 & thread1inside = FALSE : {1, 2}; th0pc > 1 & th0pc < 5 : th0pc + 1; th0pc = 5 : {5, 1}; TRUE : th0pc; esac; スピンロックのコード 状態遷移モデル化しSMVで記述 Cadence SMV でモデル検査 デッドロックの 有無を確認

34. モデリングはテスト設計の 活動全体で活用できる 重要スキル 34

35. 【補足】テスト設計でモデリングを活用できるようになるためには どうすればよいか？ モデル記法の知識 モデルの活用手法 の知識 モデルで課題 解決する能力 35 【勉強する】テスト対象：UML テスト：テスト技法で使われているモデル

    例えばJSTQB FL、UMTP L2をとる 【勉強・実践する】テスト対象：モデリングを活用 する開発手法（RDRA、UP等） テスト：テスト設計技法、テスト手法（VSTeP）等 例えばJSTQBテストアナリストをとる 【実践して磨く】 日頃の業務で、モデルを使って •課題の全体構造を明快に整理する •課題の要点を的確に表現する •課題解決の要点を的確に表現する の経験を重ね、継続的に磨く 必要スキル

36. 【補足】テスト設計のためのモデリングについての参考図書 ⚫テスト設計技法で使用するモデリング • ソフトウェアテスト技法ドリル（秋山浩一, 日科技連出版） • はじめて学ぶソフトウェアのテスト技法（リー・コープランド, 日経BP） ⚫テスト対象のモデリング（UML） •

    UMLモデリングのエッセンス（マーチン・ファウラー, 翔泳社） • 実践UML（グレーグ・ラーマン, ピアソンエデュケーション） 36

37. アウトライン 1. モデリングとは 2. 目的・制約とモデリング 3. 目的・課題・観点とモデリング 4. テスト設計を支えるモデリング 5.

    テストケース導出でのモデリングの活用 6. まとめ 37 前提知識 動機付け 本題

38. テストケースの導出での モデリングの活用 ～状態遷移テストを事例として～ 38

39. 本章で扱うこと ⚫実際の状態遷移テストの設計でモデリングをどう活用するか を示します • モデリングの活用所を解説します • モデリングでの対象分析で、テスト設計が容易になることを解説します 39

40. 解説のフェーズ（JSTQBの定義） 40 テスト分析 テスト設計 テスト実装 対象機能の特定～抽象テストケース導出まで

41. 解説で用いる題材 ⚫テスト対象 • 簡易ファイル共有システム（Google DriveやDropboxと同種） • 1台のサーバと2台のクライアントで構成 • クライアント間のファイル状態を共有する ⚫テスト目的

    • ファイル共有のクライアントの状態遷移が仕様と合致することを確認する ※通信の状態遷移テストは本来かなり複雑ですが、アプローチとテク ニックの説明に集中するため仕様を簡略化します 41 サーバー

42. 【補足】複雑・曖昧・高度なテスト目的に対応するための ３つのモデリング方針 1. 全体を俯瞰できるようにする • 全体像を示す/重要な要点がどこに位置するか示す 2. 扱えるように整理・分割する • 関心事を分離する

    3. 重要な課題に注力する 42

43. 関心事を分離し、分けて課題に対応する 43 ファイル同期システムの状態遷移仕様との合致性確認 対象を分析し、必要な 情報を明らかにする テストすべきものを 識別する テストケースを作成 する 相互にフィードバック

    しながら分析する 方針1：全体を俯瞰できるようにする 方針2：扱えるように整理・分割する 目的 課題 ※「テストすべきもの」＝JSTQBでの「テスト条件」。JSTQBを知らない方向けにこの表記で記載

44. 対象を分析し、必要な情報を明らかにする 44 ファイル同期システムの状態遷移仕様との合致性確認 対象を分析し、必要な 情報を明らかにする テストすべきものを 識別する テストケースを作成 する 目的

    課題

45. 対象を分析し、必要な情報を明らかにする： 構造モデルで状態を識別する 45 ファイル同期システムの状態遷移仕様との合致性確認 状態遷移を識別する どのような状態があるか？ 対象の クラス図 目的 課題

    観点 成果物 対象を分析し、必要な情報を明らかにする 複雑な状態遷移テストでは、第一に構造モデル で、どこにどのような状態があるか分析する ・・・

46. 対象を分析し、必要な情報を明らかにする： 構造モデルを明示化し、状態を識別する 46 最初のスケッチ

47. 【補足】複雑な状態遷移テストではいきなり状態遷移図を 描かない ⚫状態やイベントの見落とし、複数の状態の混同、状態間の 制約を見逃しがち ⚫第一歩として、構造モデルの中で、だれがどのような状態を 持つか明確化するアプローチが有効 47

48. 対象を分析し、必要な情報を明らかにする： 機能モデル・ふるまいモデルで構造モデルを洗練させる 48 ファイル同期システムの状態遷移仕様との合致性確認 状態遷移を識別する どのような状態があるか？ クラス図 目的 課題 観点

    成果物 対象を分析し、必要な情報を明らかにする 構造モデルを描いたら、機能モデル/ふるまいモデルを描いて分 析を深め、状態の識別を洗練させる シーケンス図 基本シナリオ ・・・

49. 対象を分析し、必要な情報を明らかにする： 機能モデル・ふるまいモデルで構造モデルを洗練させる 49 【基本シナリオ】 ・ファイル変更を共有する（プッシュ） ・ファイル変更を共有する（プル） ・ファイル競合を解消する ・ファイル競合をマージする ・・・ •基本シナリオを抽出し、シナ

    リオごとにシーケンス図でふる まいを分析する

50. 対象を分析し、必要な情報を明らかにする： 機能モデル・ふるまいモデルで構造モデルを洗練させる 50 【基本シナリオ】 ・ファイル変更を共有する（プッシュ） ・ファイル変更を共有する（プル） ・ファイル競合を解消する ・ファイル競合をマージする ・・・ •基本シナリオを抽出し、シナ

    リオごとにシーケンス図でふる まいを分析する 重要：テスト設計のモデリングでは、テスト設計視点での気がかり・リスク要因・課題を出し て明示化する

51. 対象を分析し、必要な情報を明らかにする： 構造モデルを洗練させ、テストすべき状態を適切に識別する 51 テストすべき状態を識別 ※今回は赤枠に絞って解説

52. 【補足】テスト設計には正しい仕様や設計のモデルが有益 ではテスト設計に必要な対象モデルをどう確保するか？ ⚫テスト用に全再モデリングするのは非効率 • 「必要なテストベース確保の早期からの働きかけ」が重要 ⚫モデルが不十分なときはどうするか？ • 仲間の集合知で対応すると効率的にモデルを確保できる • 【状況】モデルがない

    • →リスクベースで重要なモデルに注力する • 【状況】モデルがテスト設計の視点でみると不十分 • →テスト設計の視点で補強する 52 ありふれている

53. 【補足】テスト設計の対象モデリングは本質的な品質リスクを 見つけ出す作業 53 設計のための対象モデリング INPUT INPUT INPUT INPUT INPUT INPUT

    INPUT INPUT テスト設計のための対象モデリング 設計の誤り 実装の誤り 外から見た 妥当性 本質的な設計・実装を見定める 視野を広げて本質的な品質リスク を見定める 最初から全対応のモデリングを行うのが理想。 ただし一般的に制約によって差が生まれがち 具体化 具体化 発散

54. 【補足】対象モデルを補強するテスト設計の視点： テスト目的の達成を視点に補強する（事例でのミクロ視点） 54 モデリングでの視点 状態遷移テストでのアクション例 全体のスコープの明確化 （テストすべき状態・状態遷 移の明確化。設計の抜け漏 れ・冗長性の検出） ・クラス図でテストすべき状態を洗い出す

    ・ステートマシン図でテストすべき状態遷 移を明確化する 目的とする品質リスクの識 別（広い視点で対象の分析 を加えてリスクを識別する） ・シーケンス図で順序についての欠陥可 能性を考える ・タイミングチャートで遷移タイミングにつ いての欠陥可能性を考える ・・・・ 【目的例】 •特定のスコープ で品質が十分であ ることを確認する

55. 【補足】対象モデルを補強するテスト設計の視点： より広い視点でテストを補強する（テスト活動全般の視点） 55 視点を広げる方向性 視点 ビジネス指向 ビジネスについての専門性を発揮する 例）競合製品との比較テスト拡充、ROIに基づいたテストの選別 ユーザ指向 ユーザビリティなど利用時の品質について専門性を発揮する

    例）ユーザビリティテストの充実、ユーザ要求に基づいたテスト補強 プロジェクト指向 プロジェクトの状態や仲間とのつながりや理解を活かす 例）プログラマとのコミュニケーションによるリスクの識別 ホワイトボックス指向 設計、実装から品質リスクを分析しテストを導く 例）採用技術のセキュリティホールについてのテスト補強 内部品質特性指向 特定の内部品質特性の専門性を発揮する 例）性能テストの充実、移植性についてのテスト補強

56. 対象を分析し、必要な情報を明らかにする： ステートマシン図で状態遷移を分析する 56 状態を識別したらステートマシン図で状態遷移を 分析する ファイル同期システムの状態遷移仕様との合致性確認 状態遷移を識別する 状態 クラス図 状態遷移

    目的 課題 観点 成果物 対象を分析し、必要な情報を明らかにする シーケンス図 基本シナリオ ステートマシン図 ・・・

57. 対象を分析し、必要な情報を明らかにする： ステートマシン図で状態遷移を分析する 57

58. 対象を分析し、必要な情報を明らかにする： テスト設計の視点でゆさぶりをかけ、モデルを補強・洗練させていく 58 アクティビティ図で変更情報キューの 上限、判定を詳細化する ・失敗のパターンを詳細化する ・通信失敗時のシーケンスを描き状 態遷移を補強する 懸念が実現した時のシナリオについ てシーケンス図で分析する

    状態遷移表を作成し無則のイ ベント組み合わせを分析する

59. 対象を分析し、必要な情報を明らかにする： 懸念点・品質リスクに対応する 【変更共有失敗】 ⚫通信エラー • タイムアウト • ビジー • データ異常

    • チェックサム不一致 • パリティエラー • フレーミングエラー ⚫通信シーケンスエラー • 通信のブロッキング ⚫ファイル同期エラー • ハッシュ不一致 • フォーマット破損 ・・・ 59 「共有失敗」の遷移パスとし て認識 【課題】 失敗のパターンを詳 細化する

60. 対象を分析し、必要な情報を明らかにする： モデリングで見つけたリスク要因に基づいてリスクを分析する 60 リスク要因 リスク事象 リスク レベル 上限を超えるサーバからの変更通知の キューイング サーバからの変更通知を処理できない

    中 複数の変更通知のキューイング サーバからの変更通知を処理できない 中 サーバからの変更通知受信エラー サーバへの変更共有エラー 特定のエラー時にエラー処理が行われない 中 複数ファイル変更時の一部の競合発生 非競合ファイルが競合と判定される 競合ファイルが非競合ファイルと判定される 中 サーバからの変更通知受信中に変更通 知を受信（再入） 変更情報がキューイングされない 高 サーバへ変更共有中にサーバから通知 受信（割込み） 変更情報がキューイングされない サーバへの変更が共有されない 高 サーバへ変更共有中状態/競合状態/ 変更あり状態中に他処理をブロック ブロックされた状態遷移が動く ブロックされていない状態遷移が動かない 中 モデリングで見つけた リスク要因 上限あるキュー処理 通信エラー・競合 のパターン多数 受信の再入可能 受信の割込みあり 状態遷移をブロック 論理関係をもつ集合 方針３：重要な課題に注力する

61. 成果物の全体像 61 ファイル同期システムの状態遷移仕様との合致性確認 状態遷移の識別 状態 クラス図 状態遷移 目的 課題 観点

    成果物 対象を分析し、必要な情報を明らかにする シーケンス図 基本シナリオ ステートマシン図 状態遷移表 状態間の制約 や連携の識別 キュー処理の識別 イベント・状態の 組み合わせ制約 品質リスクの 分析 品質リスク リスク管理表 アクティビティフロー キュー処理の アクティビティ図 通信エラー/競合仕様一覧

62. 【補足】テスト設計の対象モデリングは本質的な品質リスクを 探索していく作業 ⚫様々な観点でモデリングして、 気がかりやリスク要因・課題を抽出して、洗練させ、学習し、 さらにモデルを洗練させる学習ループを回すことで、 テストすべき本質的な状態遷移が見えてくる 62

63. テストすべきものを識別する 63 ファイル同期システムの状態遷移仕様との合致性確認 対象を分析し、必要な 情報を明らかにする テストすべきものを 識別する テストケースを作成 する 目的

    課題 ※テストすべきもの＝JSTQBのテスト条件

64. 【補足】テストすべきものを識別する ⚫適切にモデリングを活用して対象やリスクを分析しておくと、 テストすべきものは容易に抽出できる ⚫方針 • 分析した状態遷移を一通り網羅する • リスクベースドテストで品質リスクに対してピンポイントでテストを補強する 64

65. テストすべきものを識別する 65 ファイル同期システムの状態遷移仕様との合致性確認 目的 テストすべきものを識別する 0スイッチカバレッジ 100%網羅テスト 基本シナリオテスト リスクベースドテスト 状態遷移をテストする

    通信エラーテスト 対象の品質リスクをコントロールする 状態遷移 リスク 競合テスト 課題 観点 テストすべきもの

66. テストすべきものを識別する 0スイッチカバレッジ100%網羅テスト 66 テスト テスト網羅基準 基本シナリオテスト ファイル共有の基本シナリオをテスト。通信エラー/競合発生 以外の遷移を0スイッチカバレッジ100%網羅する 通信エラーテスト 共有失敗、サーバからの変更通知受信失敗のパターンを網

    羅する 競合テスト 競合要因パターンを網羅する

67. テストすべきものを識別する リスクベースドテスト 67 リスク要因 リスク事象 リスク レベル テスト 上限を超えるサーバからの変更通 知のキューイング

    サーバからの変更通知を処理できない 中 キューに対する3値の境界値テスト 複数の変更通知のキューイング サーバからの変更通知を処理できない 中 複数の変更通知をキューイングするテスト サーバからの変更通知受信エラー サーバへの変更共有エラー 特定のエラー時にエラー処理が行われ ない 中 全エラーパターンについてテスト 典型的なエラーの組み合わせをテスト ※通信エラーテストで実施 複数ファイル変更時の一部の競合 発生 非競合ファイルが競合と判定 競合ファイルが非競合ファイルと判定 中 全競合パターンについてテスト ※競合テストで実施 サーバからの変更通知受信中に 変更通知を受信（再入） 変更情報がキューイングされない 高 受信の再入発生時についてテスト サーバへ変更共有中にサーバから 通知受信（割込み） 変更情報がキューイングされない サーバへの変更が共有されない 高 サーバへ変更共有中の受信割込みをテス ト サーバへ共有中/競合/変更あり 状態中に他処理をブロック ブロックされた状態遷移が動く ブロック対象外の状態遷移が動かない 中 サーバへ共有中/競合/変更あり状態中 の無則のテストを実施

68. 【補足】モデリングでリスク要因や課題を把握する恩恵： 有効なテストをコンパクトに作成することができる ⚫今回は、モデリングでリスクを識別し、リスクベースドテストの ピンポイントのテストで補うことで、NスイッチカバレッジのN値 を0に抑えることができた • テスト設計の手間、テストケースの数を減らすことができた 68

69. 【補足】テストすべきもののモデリング ⚫テストすべきものが複雑化・大規模化すると、そのモデリング が必要になる • 方針：全体を俯瞰できるようにする/扱えるように整理・分割する • 形式：全体をツリーかマトリクスで整理し、詳細を参照する構造が多い • 本講演ではツリー構造で整理している 69

70. テストケースを作成する 70 ファイル同期システムの状態遷移仕様との合致性確認 対象を分析し、必要な 情報を明らかにする テストすべきものを 識別する テストケースを作成 する 目的

    課題

71. クライアント リスクベースドテスト クライアント状態遷移テスト テストケースを作成する ⚫テストすべきものをパッケージングしてテストスイートにする • 他のテストとの整合性も加味する • テストスイートをテストケースに詳細化する 71

    基本シナリオテスト 競合テスト サーバ・クライアント通信エラーテスト リスクベースドテスト 通信エラーテスト サーバ通信エラーテスト 他のテスト分析結果 と統合

72. テストケースの導出でのモデリングの活用 まとめ ⚫モデリングで全体像と要点（リスク要因・リスク）を分析するこ とで、有効なテストをコンパクトに作成することができる • テストすべき状態を的確に識別できた • リスク要因を識別できた。そこからリスク分析を支援することで、的確なリス クベースドテストを設計できた。それによりNスイッチカバレッジのN値を小さ し、テストケースを減らせた

    72

73. アウトライン 1. モデリングとは 2. 目的・制約とモデリング 3. 目的・課題・観点とモデリング 4. テスト設計を支えるモデリング 5.

    テストケース導出でのモデリングの活用 6. まとめ 73 前提知識 動機付け 本題

74. 最後のまとめ ⚫モデリングはテスト設計の活動全域をよりよくできます • 例えば有効なテストをコンパクトに作れるようになります ⚫モデリングについて、知識をつけ、現場で活用する能力を高 めて、仕事をよりよくしていきましょう！ 74