狠狠撸

狠狠撸Share a Scribd company logo

テスト设计技法の适用???その前に

?Download as PPTX, PDF?
?
K
kauji0522

WACATE 2017 Summer

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

More Related Content

テスト设计技法の适用???その前に

Editor's Notes

  1. IEEE Standard Classification for Software Anomalies Defect An imperfection or deficiency in a work product where that work product does not meet its requirements or specifications and needs to be either repaired or replaced. 作業成果物がその要件または仕様を満たさず、修理または交換する必要がある作業成果物の不完全または不足。 Fault A manifestation of an error in software. ソフトウェアにおけるエラーの現れ。 Failure Termination of the ability of a product to perform a required function or its inability to perform within previously specified limits. 製品が要求された機能を果たす能力、または以前に特定された限度内で実行する能力の欠如。 An event in which a system or system component does not perform a required function within specified limits. システムまたはシステムコンポーネントが指定された制限内で必要な機能を実行しないイベント。 Problem Difficulty or uncertainty experienced by one or more persons, resulting from an unsatisfactory encounter with a system in use. 使用中のシステムとの不満足な遭遇の結果、1人または複数の人が経験する困難または不確実性。 A negative situation to overcome. 克服すべき否定的な状況。
  2. 無限に存在する値の中からたった数個しかテストしなくて大丈夫なの？ テストケースがスッカスカで、絶対バグを見逃してそうなんですが??? 会社で「同値分割だとこれが正しいんです！」って言ったら上司に怒られそう???