Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

テスト設計技法の適用・・・その前に

4 659 vues

Publié le

WACATE 2017 Summer

Publié dans : Ingénierie
  • Identifiez-vous pour voir les commentaires

テスト設計技法の適用・・・その前に

  1. 1. テスト設計技法の適用 その前に・・・ WACATE2017 夏
  2. 2. 自己紹介 • 氏名:なかむら こうじ • あなたとテストの関わり:1~2年に1案件くらいやる • 組織の主な業務:SIです • 業務担当している主な分野:なんでも。今は要件定義。 • テストに関連する資格:JSTQB AL TM/TA, JCSQE 中級 • あなたの派閥:猫派 2017/6/17 WACATE 2017 Summer 2
  3. 3. WACATEとテスト設計技法の歴史 2010 冬 デシジョンテーブルを使いこなそう!(加瀬正樹) https://www.slideshare.net/softest/wacate2010w デシジョンテーブル 2012 夏 入門!組合せテスト(井芹洋輝) https://www.slideshare.net/goyoki/ss-34571626 基本用語等の基礎知識 組合せテスト技法はじめの一歩(近江久美子) https://www.slideshare.net/omn/wacate2012s-main-techniquepublic デシジョンテーブル、 ペアワイズ、直行表 実践!組合せテスト設計(井芹洋輝) https://www.slideshare.net/goyoki/wacate2012s 有則、無則、禁則における組合 せ技法の選定 冬 かいてみようCFD(近江久美子) http://www.slideshare.net/omn/wacate2012w-letsdrawcfdpublic CFD技法、同値分割、 デシジョンテーブル 2013 夏 分けてみよう悩んでみよう同値分割・境界値分析(近江久美子) https://www.slideshare.net/omn/wacate2013s-technical-sessionpublic 同値分割 境界値分析 冬 状態遷移テスト(朱峰錦司) http://www.slideshare.net/kjstylepp/wacate2013-29199595 状態遷移テスト 2014 冬 クラシフィケーション・ツリー法入門(井芹洋輝) http://www.slideshare.net/goyoki/ss-42412647 クラシフィケーション・ツリー法 2015 冬 わりとディープ?同値分割↔境界値分析(山口寛子) https://www.slideshare.net/scarletplover/ss-56911349 同値分割、境界値分析、 ドメイン分析 2016 夏 テスト設計技法の説明(越中谷郁美、山口寛子、近江久美子) http://wacate.jp/2016/summer/テスト設計技法についての説明_20160619版.pdf 同値分割、境界値分析、 デシジョンテーブル、状態遷移 ユースケーステスト 冬 組み合わせテスト(藤原洋平) https://www.slideshare.net/mirer/wacate2016 デシジョンテーブル、 ペアワイズ、直行表 2017/6/17 WACATE 2017 Summer 3 過去 11 セッション
  4. 4. なぜテスト設計技法を使うのか • テストに利用できる要員、機材、時間は有限 • 全ての入出力をテストするのは非現実的 2017/6/17 WACATE 2017 Summer 4 現実的な手数で効率的に バグを検出していく必要がある
  5. 5. なぜテスト設計技法を使うのか • テスト設計技法を使わない場合のあるある –たくさんテストをしてもなかなかバグが見つからない –同じところを何度もテストしている 2017/6/17 WACATE 2017 Summer 5
  6. 6. なぜテスト設計技法を使うのか • 現実的な手数で・・・ • 効率的に・・・ 2017/6/17 WACATE 2017 Summer 6 現実的な手数で効率的に バグを検出していく必要がある テストケースを減らして バグがあるところを狙って ダブらず広い範囲を
  7. 7. テスト設計技法のリスク • テストケースを減らすということは、 減らした分だけ確認しない箇所があるということ • 適切にテスト設計技法を適用しないと 必要なテストが漏れたり、 無駄な箇所ばかりテストすることに・・・ 2017/6/17 WACATE 2017 Summer 7
  8. 8. さまざまなテスト設計技法 2017/6/17 WACATE 2017 Summer 8 ■仕様ベースの技法 同値分割法 境界値分析 デシジョンテーブル 原因結果グラフ法 状態遷移テスト 組み合わせテスト技法 ユースケーステスト ユーザストーリーテスト ドメイン分析 ■欠陥ベースの技法 欠陥分類法 ■経験ベースの技法 エラー推測 チェックリストベースドテスト 探索的テスト ■Structure-Based Testing Introduction Condition Testing Decision Condition Testing Modified Condition/Decision Coverage (MC/DC) Testing Multiple Condition Testing Path Testing API Testing ■Quality Characteristics for Technical Testing Security Testing Reliability Testing Performance Testing Resource Utilization Maintainability Testing Portability Testing ■Specification-Based Test Design Techniques Equivalence Partitioning Classification Tree Method Boundary Value Analysis Syntax Testing Combinatorial Test Design Techniques Decision Table Testing Cause-Effect Graphing State Transition Testing Scenario Testing Random Testing ■経験および直観に基づいた技法 アドホックテスト 探索的テスト ■仕様に基づいた技法 ブラックボックステスト 同値分割 境界値分析/境界値テスト デシジョンテーブルによるテスト 原因結果グラフによるテスト 状態遷移テスト ランダムテスト モデルベースドテスト 要因分析技法【富士通】 CFD技法 ■コードに基づいた技法 ホワイトボックステスト 制御フローテスト データフローテスト トランザクションフローテスト フォールトに基づいた技法 エラー推測テスト ミューテーションテスト ■利用に基づいた技法 運用プロファイルによるテスト ローカライゼーションテスト ユーザー環境シミュレーションテスト 整合性確認テスト ■ソフトウェアの形態に基づいた技法 オブジェクト指向テスト Webシステムのテスト GUIテスト サーバーサイドのテスト データベーステスト 並行プログラムのテスト プロトコル適格性テスト 実時間のテスト モバイルアプリケーションのテスト ■組合せの技法 直行配列表(実験計画法)を用いたテスト All-pair法を用いたテスト ■リスクに基づいた技法 テストマネジメントにおけるリスクベースドテスト テスト設計におけるリスクベースドテスト EQUIVALENCE PARTITIONING BOUNDARY VALUE ANALYSIS STATE TRANSITION TESTING CAUSE-EFFECT GRAPHING SYNTAX TESTING STATEMENT TESTING BRANCH/DECISION TESTING DATA FLOW TESTING BRANCH CONDITION TESTING BRANCH CONDITION COMBINATION TESTING MODIFIED CONDITION DECISION TESTING LCSAJ TESTING RANDOM TESTING JSTQB/ISTQB BS7925 ■Structure-Based Test Design Techniques Statement Testing Branch Testing Decision Testing Branch Condition Testing Branch Condition Combination Testing Modified Condition Decision Coverage (MCDC) Testing Data Flow Testing ■Experience-Based Test Design Techniques Error Guessing SQuBOK Guide ISO/IEC/IEEE 29119
  9. 9. 今回とりあげるテスト設計技法 • 仕様ベースの技法から以下をご紹介 –同値分割 –境界値分析 –デシジョンテーブル –状態遷移テスト –ユースケーステスト –組み合わせテスト技法 2017/6/17 WACATE 2017 Summer 9
  10. 10. Attention! • 仕様ベースの技法では基本的に「Failure」や「Problem」を 見つけますが、本セッション中は「バグ」という表現を使用してい ます。 2017/6/17 WACATE 2017 Summer 10 Defect Fault Failure コード等に記述された誤り 既定された処理の 実行能力の欠如 Failureによって生じる 困難や不確実性 IEEE1044-2009 Problem 不正な文字コードの指定 文字化けした表示 読めない
  11. 11. Attention! • これから各技法の説明で例を提示します。 • 例には架空のテーマパーク 【東京ネズミーランド】【東京ネズミーシー】の オンラインチケット購入サイトを想定しています。 • 実在する施設・団体・商品等とは一切関係ございません。 2017/6/17 WACATE 2017 Summer 11
  12. 12. 2017/6/17 WACATE 2017 Summer 12 同値分割
  13. 13. 同値分割 • 同値分割とは –たくさんある入力値や出力値を【同値クラス】に分けること • 同値クラスとは –システムによって同じように扱われる(と思われる)値のセットや範囲 • 同値クラス内の値は、全て同じように扱われるはずなので、 テストケースを減らすことができる –同値クラス毎に1つの値を確認すればOK 2017/6/17 WACATE 2017 Summer 13
  14. 14. 同値分割 • 配送チケットを代金引換で購入する場合、 購入金額に応じて代引き手数料がかかります。 –購入金額に対して代引き手数料が正しく 判断されるか確認するテストを考えてみましょう 2017/6/17 WACATE 2017 Summer 14 購入金額 代引き手数料 ~ 29,999 324円 30,000 ~100,000 540円 100,001 ~200,000 864円 200,001 ~ 1080円
  15. 15. 同値分割 ① 有効同値クラスと無効同値クラスを見つける 2017/6/17 WACATE 2017 Summer 15 購入金額 代引き手数料 ~ 29,999 324円 30,000 ~100,000 540円 100,001 ~200,000 864円 200,001 ~ 1080円 ~ 29,999 30,000~ 100,000 100,001~ 200,000 200,001 ~ 999,999 ~ 0 1,000,000 ~ 有効同値クラス 無効同値クラス 無効同値クラスは 仕様に明示されないことも あるので要注意!
  16. 16. 同値分割 ② 最もそのクラスの特性を表す代表値を選ぶ – 平均値、中央値、最頻値など ③ 期待結果を決定して テストケースにする 2017/6/17 WACATE 2017 Summer 16 ~ 29,999 30,000~ 100,000 100,001~ 200,000 200,001 ~~ 0 ~999,999 -10,000 15,000 70,000 150,000 600,000 2,000,000 No 購入金額(入力値) 代引き手数料(期待結果) 1 -10,000 N/A 2 15,000 324円 3 70,000 540円 4 150,000 864円 5 600,000 1080円 6 2,000,000 N/A
  17. 17. 同値分割 • なんとなく分かったところで別の例題 • 1デーチケットは利用者に応じて以下の料金設定です • チケット購入時の料金判定について同値分割で考えてみよう 2017/6/17 WACATE 2017 Summer 17 利用者 料金 大人(18歳以上) 7,400円 中人(中学生/高校生) 6,400円 小人(4歳以上/小学生)4,800円
  18. 18. 同値分割 • 同値クラスは何個になりましたか? 2017/6/17 WACATE 2017 Summer 18 利用者 料金 大人(18歳以上) 7,400円 中人(中学生/高校生) 6,400円 小人(4歳以上/小学生)4,800円
  19. 19. 同値分割 • 解答例 –こんな入力フォームを想定しています –どんな方法で何が入力できるかはとても重要 • 場合によっては「選択なし」などの無効同値クラスが必要になることもある 2017/6/17 WACATE 2017 Summer 19 小人 中人 大人 利用者を選択して「購入」をクリックしてください。 選択 利用者 料金 ● 大人(18歳以上) 7,400円 〇 中人(中学生/高校生) 6,400円 〇 小人(4歳以上/小学生) 4,800円 購 入
  20. 20. 同値分割 • 自分がどの料金のチケットを買うべきなのかを教えてくれる ヘルプ機能を考えてみましょう。 • 年齢と在学状況から、どれを買うべきかの判定します • 同値分割すると同値クラスはどうなりますか? 2017/6/17 WACATE 2017 Summer 20 利用者 料金 大人(18歳以上) 7,400円 中人(中学生/高校生) 6,400円 小人(4歳以上/小学生) 4,800円
  21. 21. 同値分割 • 年齢と在学状況からどれを買うべきかの判定 –これであってますか? 2017/6/17 WACATE 2017 Summer 21 3歳以下 4歳以上 小学生 中学生 高校生 18歳以上 小人 中人 大人 利用者 料金 大人(18歳以上) 7,400円 中人(中学生/高校生) 6,400円 小人(4歳以上/小学生)4,800円
  22. 22. 同値分割 • 分割なので同値クラス間で重複はNGです • 仕様に明示された条件を並べただけでは同値分割にならない (そもそも仕様がイケてない) 2017/6/17 WACATE 2017 Summer 22 3歳以下 4歳以上 小学生 中学生 高校生 18歳以上
  23. 23. 同値分割 • じっさいのところこうでした –基本は年齢で区分 • (小人)4~11歳、(中人)12~17歳、(大人)18歳~ –12歳と18歳だけ特別対応(同学年のグループ内で差がでないように) • 12歳・・・小学生は小人、中学生は中人 • 18歳・・・高校生は中人、高校生以外は大人 2017/6/17 WACATE 2017 Summer 23 0~3歳 4~11歳 12歳 小学生 13~17歳 18歳 高校生 19歳以上 小人 中人 大人 12歳 中学生 18歳非 高校生
  24. 24. 同値分割 • 同値分割の使いどころ –基本的な動作を確認したいとき • 細かいテストの前にそもそもそれなりに動くのか(有効値と無効値を1個ずつとか) –異常系の細かいテストを全てパスした後で 普通の正常系でエラーになったらショック大きいですよね! • ユーザー受入テストなど通常の使い方で問題がないか • ビルド後に想定外の影響がないかスモークテストとか –他のテスト設計技法を適用する準備や合わせ技 2017/6/17 WACATE 2017 Summer 24
  25. 25. 2017/6/17 WACATE 2017 Summer 25 境界値分析
  26. 26. 境界値分析 • 境界値とは –システムの振る舞いを分けるギリギリのポイント –条件分岐とか繰り返し処理の最後とか –同値クラス内の最小値と最大値とか • なぜ境界値なのか –バグが多そうだから • 「未満」と「以下」とか、「〇〇区分≠{xxしない}」(二重否定)とか –バグがありそうなところを狙うための設計技法です 2017/6/17 WACATE 2017 Summer 26
  27. 27. 境界値分析 • 先ほどの代引き手数料の例ですが・・・ • テストしようと思うと気になりますよね 2017/6/17 WACATE 2017 Summer 27 購入金額 代引き手数料 ~ 29,999 324円 30,000 ~100,000 540円 100,001 ~200,000 864円 200,001 ~ 1080円 ~ 29,999 30,000~ 100,000 100,001~ 200,000 200,001 ~ 999,999 ~ 0 1,000,000 ~
  28. 28. 境界値分析 • 気になるポイント ① 仕様に明示されていない境界 ② 「xx0~」と「xx1~」の違いとか 2017/6/17 WACATE 2017 Summer 28 ① ①② ② ② ~ 29,999 30,000~ 100,000 100,001~ 200,000 200,001 ~ 999,999 ~ 0 1,000,000 ~
  29. 29. 境界値分析 • テストケース 2017/6/17 WACATE 2017 Summer 29 # 購入金額 (入力値) 代引き手数料 (期待結果) 1 0 N/A 2 1 324円 3 29,999 324円 4 30,000 540円 5 100,000 540円 ~ 29,999 30,000~ 100,000 100,001~ 200,000 200,001 ~ 999,999 ~ 0 1,000,000 ~ # 購入金額 (入力値) 代引き手数料 (期待結果) 6 100,001 864円 7 200,000 864円 8 200,001 1080円 9 999,999 1080円 10 1,000,000 N/A
  30. 30. 境界値分析 • チケット購入時に来園日は2か月先までの日付を指定できる –2か月先の同日が存在しない場合、当該月の末日まで指定可能 • 例)7/31の2か月先9/31は存在しないので9/30 • 指定できる上限日の判断が正しいかテストしてください –1年365日、365ケースをテストしますか? ※うるう年のことは一旦忘れてください 2017/6/17 WACATE 2017 Summer 30
  31. 31. 境界値分析 • 時間軸で境界を探す –これが境界値!・・・でいいですか? 2017/6/17 WACATE 2017 Summer 31 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月 1月 2月 1 1 1 1 1 1 1 1 1 1 1 1 1 1 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ 28日 ~ 28日 ~ ~ ~ ~ ~ ~ ~ ~ ~ 28日 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ 29日 ~ × ~ ~ 30日 ~ 30日 ~ 30日 30日 ~ 30日 30日 30日 × 31日 31日 31日 31日 31日 × 31日 31日 31日 × 1/1 7/30 7/31 8/1 12/28 12/29 12/31 2か月先の同日がある ない 2か月先の同日がある ない
  32. 32. 境界値分析 • こんなふうに実装してたら境界値分析は正しい 2017/6/17 WACATE 2017 Summer 32 1/1 7/30 7/31 8/1 12/28 12/29 12/31 2か月先の同日がある ない 2か月先の同日がある ない 今日が1/1~7/30の場合 ⇒ 上限日は2か月先の同日 今日が7/31の場合 ⇒ 上限日は2か月先の月末日 今日が8/1~12/28の場合 ⇒ 上限日は2か月先の同日 今日が12/29~12/31の場合 ⇒ 上限日は2か月先の月末日
  33. 33. 境界値分析 • もし実装がこんなだったら? • 実装と乖離するとバグを見落とすことに・・・ –上記の実装、12/30を11/30と間違えています –先ほどの境界値分析のテストだと見落とすよね 2017/6/17 WACATE 2017 Summer 33 今日が7/31,12/29,11/30,12/31のいずれかの場合 上限日は2か月先の月末日 それ以外の場合 上限日は2か月先の同日 7/31 12/29 12/30 12/31 その他の日 当日資料には 掲載なし
  34. 34. 境界値分析 • 境界値分析の弱点 –「1≦x≦5」を「x=1 or x=5」と実装されるとバグを検出できない –境界値は極端な値。境界値ばかり攻めてると 普通のケースでバグを見逃すことに・・・ • 対策 –同値分割と組み合わせる –3点の境界値をテストする 2017/6/17 WACATE 2017 Summer 34 0 1 5 63 0 1 5 62 4
  35. 35. 境界値分析 • 境界値分析の使いどころ –そこに未確認の境界が存在するとき –境界にバグが多いことはわかっているので、 可能な限りどこかで1回はテストすべき –境界だけをテストすればいいわけではない • 境界を見誤っても気づけるように同値分割を併用したり、 3点の境界値などを使って保険をかけましょう 2017/6/17 WACATE 2017 Summer 35
  36. 36. 2017/6/17 WACATE 2017 Summer 36 デシジョンテーブル
  37. 37. デシジョンテーブル • デシジョンテーブルとは –複数の条件によって決まる動作を表形式で整理する • カタカナで書くと格好良いけど日本語(JIS X0125)だと『決定表』です。 –複数の条件の組み合わせの不整合や考慮もれなど バグがありそうなところを狙う設計技法です。 –複雑な論理(ロジック)を網羅的に確認します。 2017/6/17 WACATE 2017 Summer 37
  38. 38. デシジョンテーブル • デシジョンテーブルの書式 2017/6/17 WACATE 2017 Summer 38 #1 #2 #3 #4 #5 #6 #7 #8 条 件 条件1 Y Y Y Y N N N N 条件2 Y Y N N Y Y N N 条件3 Y N Y N Y N Y N 動 作 動作1 X X X X 動作2 X X X X 動作3 X X X X X Y:条件が満たされなければならない N:条件が満たされてはならない 組み合わせる条件を列挙 条件に応じて発生する動作を列挙 条件1が真 かつ 条件2が偽 かつ 条件3が真 の時 動作が動作3になる
  39. 39. デシジョンテーブル • ところで先ほどの同値分割の例、モヤモヤした方もいたのでは? –基本は年齢で区分 • (小人)4~11歳、(中人)12~17歳、(大人)18歳~ –12歳と18歳だけ特別対応(同学年のグループ内で差がでないように) • 12歳・・・小学生は小人、中学生は中人 • 18歳・・・高校生は中人、高校生以外は大人 2017/6/17 WACATE 2017 Summer 39 0~3歳 4~11歳 12歳 小学生 13~17歳 18歳 高校生 19歳以上 小人 中人 大人 12歳 中学生 18歳非 高校生
  40. 40. デシジョンテーブル • 2つの条件の組合せを1次元的に扱ってた –年齢の同値クラス –在学状況の同値クラス 2017/6/17 WACATE 2017 Summer 40 0~3歳 4~11歳 12歳 13~17歳 18歳 19歳以上 小学生 中学生 高校生 それ以外
  41. 41. デシジョンテーブル 2017/6/17 WACATE 2017 Summer 41 #1 #2 #3 #4 #5 #6 #7 #8 #9 … … … … 条 件 0~3歳 4~11歳 12歳 13~17歳 18歳 19歳以上 小学生 中学生 高校生 その他 動 作 小人 中人 大人 不要 まず条件と動作を列挙して ・・・ ・・・見にくい
  42. 42. デシジョンテーブル 2017/6/17 WACATE 2017 Summer 42 #1 #2 #3 #4 #5 #6 #7 #8 #9 条 件 年齢 0~3歳 4~11歳 12歳 13~17歳 18歳 19歳以上 在学状況 小学生 中学生 高校生 その他 動 作 購入すべき 券種 小人 中人 大人 不要 間違えないためには 見やすさ・美しさも 大事ですよね
  43. 43. デシジョンテーブル 2017/6/17 WACATE 2017 Summer 43 #1 #2 #3 #4 #5 #6 #7 #8 #9 条 件 年齢 0~3歳 Y 4~11歳 Y 12歳 13~17歳 18歳 19歳以上 在学状況 小学生 Y 中学生 高校生 その他 Y 動 作 購入すべき 券種 小人 X 中人 大人 不要 X まず「0~3歳」は、 在学状況「その他」で、 動作は「不要」でしょ 次、「4~11歳」は、 在学状況「小学生」で、 動作は「小人」でしょ ちょっと待って、 そうじゃないんだ!
  44. 44. #1 #2 #3 #4 #5 #6 #7 #8 #9 条 件 年齢 0~3歳 Y 4~11歳 Y 12歳 13~17歳 18歳 19歳以上 在学状況 小学生 Y 中学生 高校生 その他 Y 動 作 購入すべき 券種 小人 X 中人 大人 不要 X デシジョンテーブル 2017/6/17 WACATE 2017 Summer 44 思いついた組み合わせで 列を足していく 「足し算」の考え方だと、 思いつかなかった組み合わせ は漏れる
  45. 45. デシジョンテーブル 2017/6/17 WACATE 2017 Summer 45 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 条 件 年 齢 0~3歳 Y Y Y Y 4~11歳 Y Y Y Y 12歳 Y Y Y Y 13~17歳 Y Y Y Y 18歳 Y Y Y Y 19歳以上 Y Y Y Y 在 学 状 況 小学生 Y Y Y Y Y Y 中学生 Y Y Y Y Y Y 高校生 Y Y Y Y Y Y その他 Y Y Y Y Y Y 動 作 購 入 券 種 小人 中人 大人 不要 最初に全ての条件の組み合わせを用意して、 テストできないものを削る「引き算」の考え方 の方が考慮もれを阻止できる
  46. 46. デシジョンテーブル 2017/6/17 WACATE 2017 Summer 46 4 5 8 9 10 14 15 16 19 20 23 24 条 件 年 齢 0~3歳 Y 4~11歳 Y Y 12歳 Y Y 13~17歳 Y Y Y 18歳 Y Y 19歳以上 Y Y 在 学 状 況 小学生 Y Y 中学生 Y Y 高校生 Y Y Y その他 Y Y Y Y Y 動 作 購 入 券 種 小人 X X X 中人 X X X X X 大人 X X X 不要 X ところで「在学状況」は12歳、18歳以外の 場合は購入券種の判定に無関係です
  47. 47. デシジョンテーブル 2017/6/17 WACATE 2017 Summer 47 4 5 9 10 14 19 20 23 条 件 年 齢 0~3歳 Y 4~11歳 Y 12歳 Y Y 13~17歳 Y 18歳 Y Y 19歳以上 Y 在 学 状 況 小学生 ー ー Y ー ー 中学生 ー ー Y ー ー 高校生 ー ー ー Y ー その他 ー ー ー Y ー 動 作 購 入 券 種 小人 X X 中人 X X X 大人 X X 不要 X 無関係「-」を明示して 1列にまとめること ができます
  48. 48. デシジョンテーブル • デシジョンテーブルの使い方 ① 同値分割で条件を洗い出す ② 最初に全ての組み合わせを用意する ③ テストできない組み合わせを削る ④ 動作の決定に無関係な条件をまとめる • 「削る」「まとめる」は慎重に! • 本当はテストできるのでは?無関係と言える根拠は? • ケースを減らしたい気持ちが先行すると失敗するかも 2017/6/17 WACATE 2017 Summer 48
  49. 49. 2017/6/17 WACATE 2017 Summer 49 状態遷移テスト
  50. 50. 状態遷移テスト • ある状態がイベントに応じて別の状態に遷移する仕様のテスト –こんなのなら別に使う必要ないかな –こんなだったら? 2017/6/17 WACATE 2017 Summer 50 未承認 承認済 承認 未承認 一次 承認 承認 否認差戻し 否認 差戻し再申請 最終 承認 上位承認 否認 承認 S E S E
  51. 51. 状態遷移テスト • 何かが起こりそう –仕様通りに遷移しない、不正な遷移ができる 遷移する経路によって状態が不正になる といったバグがありそうなところを狙う技法 2017/6/17 WACATE 2017 Summer 51 未承認 一次 承認 承認 否認差戻し 否認 差戻し再申請 最終 承認 上位承認 否認 承認 S E 行って、戻って 同じ状態? ある状態を スキップ どの経路から来ても 同じ状態?
  52. 52. 状態遷移テスト • 全ての経路を最低1回はテスト 2017/6/17 WACATE 2017 Summer 52 未承認 一次 承認 承認 否認差戻し 否認差戻し 再申請 最終 承認 上位承認 否認 承認 S E
  53. 53. 状態遷移テスト • StartからEndまで一筆書きでたどるシナリオ 2017/6/17 WACATE 2017 Summer 53 未承認 一次 承認 承認 否認差戻し 否認 差戻し再申請 最終 承認 上位承認 否認 承認 S E 1 2 3 4 差戻し
  54. 54. 状態遷移テスト • 複数の連続した遷移のパターン(Nスイッチ) • 未承認から一次承認で1スイッチするパターン 2017/6/17 WACATE 2017 Summer 54 未承認 一次 承認 承認 否認差戻し 否認 差戻し再申請 最終 承認 上位承認 否認 承認 S E 差戻し
  55. 55. 状態遷移テスト • 基本的に状態遷移図があれば実施できる –正しく遷移できるか –遷移後の状態が正しいか • 状態遷移図に漏れや誤りがあれば・・・ –状態遷移表を書いて確認しよう • 状態遷移図からケースを全部抜き出せるか –機械的な作業なので人力だと面倒だし間違う 2017/6/17 WACATE 2017 Summer 55
  56. 56. 状態遷移テスト • 状態遷移表 2017/6/17 WACATE 2017 Summer 56 ID イベント s0 未承認 s1一次承認 s2最終承認 s3差戻し s4否認 e1 承認 s1 一次承認 s2最終承認 N/A N/A N/A e2 上位承認 s2 最終承認 N/A N/A N/A N/A e3 差戻し s3 差戻し s3差戻し N/A N/A N/A e4 否認 s4 否認 s4否認 N/A N/A N/A e5 再申請 N/A N/A N/A s0未承認 N/A 未承認 一次 承認 承認 否認差戻し 否認 差戻し再申請 最終 承認 上位承認 否認 承認 S E 「差戻し」の状態で[再申請]を行うと「未承認」状態になる N/Aはその状態でそのイベントは 適用できないという意味 本当にN/Aで良いのかしっかり吟味!
  57. 57. 状態遷移テスト • 機械的な作業を助けてくれるツール ① astah*(有償版) • 状態遷移図から状態遷移表を自動で作成 • 状態遷移図・表からパスを抽出 ② stateMatrix (無償) • Nスイッチの遷移パターンを生成するExcelマクロ • 遷移前状態と遷移後状態の表をもとに自動作成 • ①は高いし②は遷移図をサポートしない –考え方はシンプル、無いなら作ればいいじゃない 2017/6/17 WACATE 2017 Summer 57
  58. 58. 2017/6/17 WACATE 2017 Summer 58 ユースケーステスト
  59. 59. ユースケーステスト • ユースケース(Use Case:使用事例) –アクターがシステムを利用する一連の手続き –目的達成に必要なアクターとシステムのやりとり • アクター –対象システムの利用者や連携する外部システム • ユースケーステスト –アクターがユースケースに沿って目的達成できるか 2017/6/17 WACATE 2017 Summer 59
  60. 60. ユースケーステスト • ユースケース図 –チケット予約 2017/6/17 WACATE 2017 Summer 60 購入者 チケットを 購入する チケットを 変更する
  61. 61. ユースケーステスト • ユースケース記述 2017/6/17 WACATE 2017 Summer 61 ユースケース ケットを購入する 目的 オンラインでチケットを購入したい 事前条件 会員登録し、ログインしていること 基本 フロー 1 購入者は購入情報を入力する 2 システムはお客様情報の入力フォームを表示する 3 購入者はお客様情報を入力する 4 システムはお支払方法の入力フォームを表示する 5 購入者はお支払方法を入力する 6 システムは入力内容の確認画面を表示する 7 購入者は入力内容を確認する 8 システムは購入完了を表示する 事後条件 チケットの購入が完了すること アクターとシステムによる 一連の対話によって 目的が達成できることを確認
  62. 62. ユースケーステスト • 使い方は常にひとつ・・・とは限らない 2017/6/17 WACATE 2017 Summer 62 ユースケース チケットを購入する 代替 基本 フロー 1 購入者は購入情報を入力する ① 2 システムはお客様情報の入力フォームを表示する ・・・・・・ 代替 フロー ① 入力した購入情報にエラーがある場合 1. システムは購入情報の入力フォームを再表示する 2. システムはエラーの内容を表示する →基本フローの1へ進む 使用方法によって基本フローから 分岐するフローは代替フローとして記載する 基本フローのどこから分岐して、どこに合流するのかは大事
  63. 63. ユースケーステスト • システムが実際に利用される場面を想定し、きちんとゴールまで たどりつけるかをシミュレーションするのでリアリティーが大事 • 機械的にすべてのパスを出すわけではない • 連続50回入力間違える、とかは別で確認すべき • 使いどころ –システムテストやユーザー受入テストなど –細かい網羅的な検証が済んでから使うことが多い 2017/6/17 WACATE 2017 Summer 63
  64. 64. 2017/6/17 WACATE 2017 Summer 64 組合せテスト技法
  65. 65. 組合せテスト技法 • たくさんの条件がある場合、全ての組合せをテストするのは 現実的に不可能な場合がある • 組合せに依存関係はないはずだけど想定外がこわい・・・・ –組合せテスト技法を活用して組合せの数を減らす • どうやって組合せの数を減らすか –適当に間引くのではなく偏りなく広い範囲をテストする技法です 2017/6/17 WACATE 2017 Summer 65
  66. 66. 組合せテスト技法 • ペアワイズ(All-pair法)の考え方 –全組合せだと3×3×2=18ケース –各2項目間の全組合せをマージする • ①券種×料金区分(3×3) • ②料金区分×支払方法(3×2) • ③券種×支払方法(2×3) 2017/6/17 WACATE 2017 Summer 66 券種 1デーチケット スターライトチケット アフター6チケット 料金区分 大人 中人 小人 支払方法 クレジット 代金引換 1 2 3
  67. 67. 組合せテスト技法 • 全組合せ18に対して、ペアワイズなら9 2017/6/17 WACATE 2017 Summer 67 # 券種 料金区分 支払方法 1 1デーチケット 小人 代金引換 2 アフター6チケット 小人 クレジット 3 1デーチケット 大人 クレジット 4 アフター6チケット 中人 代金引換 5 スターライトチケット 中人 クレジット 6 1デーチケット 中人 クレジット 7 スターライトチケット 小人 代金引換 8 アフター6チケット 大人 代金引換 9 スターライトチケット 大人 代金引換
  68. 68. 組合せテスト技法 • 禁則 –「シニアチケット」は65歳以上の人が利用可能 • 機械的に組み合わせるとテストできないケースが発生 • 禁則を意識して無駄なく組合わせる必要がある • PICT,PictMasterなどのツールでは禁則の設定が可能 2017/6/17 WACATE 2017 Summer 68 券種 1デーチケット スターライトチケット アフター6チケット シニアチケット 料金区分 大人 中人 小人 65歳以上の場合、 料金区分の選択はないので 組合わせられない
  69. 69. 組合せテスト技法 • ちなみに量が多いからと言って無暗に組合わせを減らすのはNG –先ほどの例、「支払い金額が正しいか」を検証したいのなら? • 「アフター6チケット×小人×代金引換」は登場しない • 代引き手数料は大丈夫? • 依存関係の整合性をテストするなら・・・ –テスト可能なボリュームにして全部テストする • 同値分割などを使って条件の内訳を減らす • 組合わせる条件を論理に関係するものに絞る –それも無理なら設計から見直した方がいいかも 2017/6/17 WACATE 2017 Summer 69
  70. 70. 組合せテスト技法 • その他の組合せテスト技法 –直交表(実験計画法) • 2項目間の全組合せが同一回数存在する • ペアワイズ(All-pair法)より偏りが少ない –クラシフィケーション・ツリー法 • 組合わせる項目をツリー状に展開 • グラフィカルに組合せを表現 2017/6/17 WACATE 2017 Summer 70 購入 区分 大人 中人 支払 クレカ 代引小人 #1 #2 #3
  71. 71. 組合せテスト技法 • 使いどころ –出荷後のバグ修正が困難だったり影響が非常に大きい製品の場合 • “想定外”が許されない場合は、可能な限り事前に 想定外を狙ってテストすべき –先ほどのチケット購入のユースケーステストのように 詳細な入力値が任意の場合 • 同じ種類のチケットばかりでなく、どうせならいろんな組合せでテストした方が 有意義 2017/6/17 WACATE 2017 Summer 71
  72. 72. 2017/6/17 WACATE 2017 Summer 72 ドメイン分析 当日資料には 掲載なし
  73. 73. ドメイン分析 • 「x≦5の場合True」という仕様の場合、 境界値分析ならx=5,6をテストしますね • 「x≦5かつy<8の場合True」なら? • ドメイン分析では、複数の条件が掛け合わさった場合の境界値 をテストします • 境界値というバグがありそうな箇所を狙うテスト設計技法です 2017/6/17 WACATE 2017 Summer 73 当日資料には 掲載なし
  74. 74. ドメイン分析 • 「x≦5かつy<8の場合True」 • x、yともに0以上の整数とします • ドメインの赤枠線(境界)をテストしていきます 2017/6/17 WACATE 2017 Summer 74 x y 5 6 x 7 8 0-1 0 -1 xの境界値 yの境界値 x 8 6 7 50-1 -1 xとyのドメイン 当日資料には 掲載なし
  75. 75. ドメイン分析 • 手順 –条件毎に同値分割してIN/OUTを見つける –条件毎に境界値分析してon/offを見つける –ドメイン分析テストマトリクスで組み合わせる 2017/6/17 WACATE 2017 Summer 75 当日資料には 掲載なし
  76. 76. ドメイン分析 • 条件毎に同値分割してIN/OUTを見つける –「x≦5かつy<8の場合True」 • x、yともに0以上の整数とします 2017/6/17 WACATE 2017 Summer 76 x<0 OUT 0≦x≦5 IN 5<x OUT y<0 OUT 0≦y<8 IN 8≦y OUT 有効同値クラス 無効同値クラス 当日資料には 掲載なし
  77. 77. ドメイン分析 • 条件毎に境界値分析してon/offを見つける –「x≦5かつy<8の場合True」 • x、yともに0以上の整数とします 2017/6/17 WACATE 2017 Summer 77 5 60-1 x on off 7 80-1 y on off 仕様上に表れた 境界値が on 境界を挟んだ 反対側が off 当日資料には 掲載なし
  78. 78. ドメイン分析 • ドメイン分析テストマトリクスで組み合わせる 2017/6/17 WACATE 2017 Summer 78 条件 #1 #2 #3 #4 #5 #6 #7 #8 0≦x On 0 Off -1 IN x≦5 On 5 Off 6 IN 0≦y On 0 Off -1 IN y<8 On 8 Off 7 IN 期待結果 境界値分析でみつけた4つの条件を並べる 条件毎にon/off、INの3行を配置 1列(ケース)に1つの境界値(on/off)を 含むように値を設定する 【条件4つ × on/off2通り =8列必要】 当日資料には 掲載なし
  79. 79. ドメイン分析 • ドメイン分析テストマトリクスで組み合わせる 2017/6/17 WACATE 2017 Summer 79 条件 #1 #2 #3 #4 #5 #6 #7 #8 0≦x On 0 Off -1 IN - - 1 2 3 4 x≦5 On 5 Off 6 IN - - 1 2 3 4 0≦y On 0 Off -1 IN 6 5 4 3 - - y<8 On 8 Off 7 IN 6 5 4 3 - - 期待結果 True False True False True False False True xの境界値をテストする時 yの値はIN値を設定 yの境界値をテストする時 xの値はIN値を設定 当日資料には 掲載なし
  80. 80. ドメイン分析 • 1回のチケット購入で以下を全て満たす場合送料、代引き手 数料は無料です –大人2枚以上 –大人以外(中人・小人)1枚以上 –1回で購入できるチケットは合計8枚まで 2017/6/17 WACATE 2017 Summer 80 当日資料には 掲載なし
  81. 81. ドメイン分析 • 2枚≦大人 • 1枚≦大人以外 • 大人+大人以外≦8枚 2017/6/17 WACATE 2017 Summer 81 大人 9 9 8 8210 1 IN 大 人 以 外 条件 値 大人 On 2 Off 1 IN 2~8 大人以外 On 1 Off 0 IN 1~8 大人+以外 On 8 Off 9 IN 1~8 当日資料には 掲載なし
  82. 82. ドメイン分析 • 3つの境界線のon/offで6ケース 2017/6/17 WACATE 2017 Summer 82 条件 値 #1 #2 #3 #4 #5 #6 大人 On 2 2 Off 1 1 IN 2~8 6 4 3 6 大人以外 On 1 1 Off 0 0 IN 1~8 3 5 5 3 大人+以 外 On 8 8 Off 9 9 IN 1~8 5 6 7 4 期待結果 無料 有料 無料 有料 無料 エラー 当日資料には 掲載なし
  83. 83. ドメイン分析 • ドメイン分析の使いどころ –複数のAND条件で境界値が決まる場合 – OR条件の場合は分割して個別に確認できる場合が多い • ポイント –各境界についてon/offを1つずつ確認 – 複数のoffを一度に確認するとバグが隠ぺいされる – 複数のonを一度に確認するとどの境界が問題か判別不能 –グラフは必須ではありません – x,yの二次元なら容易だが、三次元以上になると大変 2017/6/17 WACATE 2017 Summer 83 当日資料には 掲載なし

×