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

32fe1b1b174c69d06b455799ed1fb285?s=47 h.iseri
December 14, 2019

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

WACATE2019

32fe1b1b174c69d06b455799ed1fb285?s=128

h.iseri

December 14, 2019
Tweet

Transcript

  1. 8.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    ステートマシン図/状態遷移表 ユースケーステスト ユースケース図/ユースケース記述 欠陥分類法 欠陥分類のリストやツリー 原因結果グラフ 原因結果グラフ デシジョンテーブル法 デシジョンテーブル クラシフィケーションツリー法 クラシフィケーションツリー 直交表/オールペア法/nワイズテスト テスト条件と値のリスト ドメイン分析テスト 2次元グラフ 制御フローテスト アクティビティ図
  10. 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 でモデル検査 デッドロックの 有無を確認
  11. 35.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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