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

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.


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.


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.


74.

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

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

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

Want more?

Transcript