20241214_WACATE2024冬_テスト設計技法をチョット俯瞰してみよう

2024年12月14～15日に開催されたWACATE冬2024の招待講演資料です。

Transcript

1. 1 / 91 WACATE2024冬 招待講演 テスト設計技法をチョット俯瞰してみよう Dec. 15th, 2024 鈴木 一裕 Image: Generated by GPT4o
2. 2 / 91 Kazuhiro SUZUKI @ WACATE2024冬 自己紹介 鈴木 一裕 Kazuhiro SUZUKI 株式会社 日立製作所 サービスプラットフォーム品質保証本部 担当部長 ※今日は、会社の立場でのお話ではありません。 ⚫ ソフトウェアのQA業を22年ほど。 ⚫ テストを中心としたソフトウェア品質保証について考えることを趣味とし、 マイナーなブログ『ソフトウェアの品質を学びまくる』を細々運営。 ときどき社外イベントで発表などしてます。 ⚫ ISO/IEC JTC1/SC7/WG26（ソフトウェアテスト）に所属、テストの国際規格化にチョット貢献。 ⚫ ソフトウェア関連書籍の翻訳や執筆にチョット関与。 ⚫ 『システムテスト自動化 標準ガイド』（翻訳・監訳）、『ソフトウェア品質知識体系ガイド(第3版)』（ごく一部執筆）、 『実践ソフトウェアエンジニアリング 第9版』（2021年、一部翻訳） ⚫ 2011年WACATE冬参加者です！
3. 3 / 91 Kazuhiro SUZUKI @ WACATE2024冬 本日の発表について ◼ JaSST’24 北海道(*1)でお話したこと ⚫ 「QA、品質保証」というテーマを見渡すことを目指した。 - テスト実行、バグ管理、テスト計画・管理、テスト実装、テスト設計・分析、 レビュー、品質評価、改善と失敗、品質・価値、QAの仕事、‥ ⚫ どうしても、「広く浅く」となった。 ◼ WACATE2024冬でお話すること ⚫ JaSSTの焼き直しではツマラナイので、「狭く、チョット深く」。 WACATEセッションでも扱った、テスト設計技法の話をします。 ⚫ 個々の技法の深掘りではなく、テスト設計技法の全体像を考えていく内容になります。 ◼ 注意点 ⚫ 「教える」というものではなく、「こんな風に考えてみた」の共有です。 眉に唾をつけながらお聴きください。 ⚫ Twitter投稿は歓迎します！ (*1) JaSST’24 Hokkaidoはコチラ。
4. 4 / 91 Kazuhiro SUZUKI @ WACATE2024冬 本日の発表について ◼ 字が小さい！って方は、お手元でもどうぞ。
5. 5 / 91 Kazuhiro SUZUKI @ WACATE2024冬 本日の発表について ◼ 今日お話すること、もうちょい具体に ⚫ 個々のテスト設計技法を理解したら、次にそれらの関係を考えてみることで、 見えてくることがあるかもしれない。 ないかもしれない。 ⚫ テスト設計には、「モデルの作成」と「カバレッジアイテムの識別」が含まれる。 ここで使用されるモデリング技法はテストの専有物ではなく、 むしろ設計時点で使っていく方が有効だろう。 いわゆる「シフトレフト」にもつながるかもしれない。 ⚫ ふだん技法と意識せず使っているナレッジも、テスト設計技法の一種と考えられる。 知識を散逸させず、ツールボックスに納めていくことが大切。 ⚫ テスト設計技法は「技術としてすべて出そろい、自然に使われている」わけではない。 未発掘の技法や、十分に使われてない技法がある。 テスト設計技法を自分で作り出すこともできるのではないか？
6. 6 / 91 Kazuhiro SUZUKI @ WACATE2024冬 それでは、始めましょう。
7. 7 / 91 Kazuhiro SUZUKI @ WACATE2024冬 今日のキーワード: 網羅 もう‐ら〔マウ‐〕 ［名］(スル) １ （魚をとる網と、鳥をとる羅 (あみ) から） 人を束縛するものや法律の制裁など。 ２ 残らず取り入れること。 (*1) goo国語辞典より引用。
8. 8 / 91 Kazuhiro SUZUKI @ WACATE2024冬 テストしているとめっちゃ言われる。 網羅。
9. 9 / 91 Kazuhiro SUZUKI @ WACATE2024冬 網羅してないとどうなる？ 漏れる。 漏れて欠陥になる、欠陥が流出する。
10. 10 / 91 Kazuhiro SUZUKI @ WACATE2024冬 どこで漏れる？ ◼ 要件が漏れる。 ◼ 仕様が漏れる。 ◼ 設計が漏れる。 ◼ 実装が漏れる。 ◼ マージが漏れる。 ◼ テストが漏れる。 ◼ デプロイが漏れる。 ◼ リリースが漏れる。 ◼ ‥ 今日は、「テスト設計で漏らさない」ための テスト設計技法に注目します。 ◼ テスト分析で漏れる。 ◼ テスト設計で漏れる。 ◼ テスト実装で漏れる。 ◼ テスト実行で漏れる。 ◼ ‥ ◼ 実行してない。 ◼ 実行したけど結果を 見てない。 ◼ 結果を見たけど 記録してない。 ◼ 記録したけど 改修してない。 ◼ ‥
11. 11 / 91 テスト設計とは何か
12. 12 / 91 Kazuhiro SUZUKI @ WACATE2024冬 ‥と始めるのもアリなのですが、 話が抽象的になってしまうので、 個別のテスト設計技法を見ていきます。
13. 13 / 91 値のテスト 想定経過時間 7:00
14. 14 / 91 Kazuhiro SUZUKI @ WACATE2024冬 テストケース5大要素(*1)の1つ「入力値」。 何はなくともまず、 「値」を漏らさないことを考えましょう。 (*1) JSTQBの用語集によると、「実行事前条件、入力値、アクション（適用可能な場合）、期待結果、および実行事後条件」とある。
15. 15 / 91 Kazuhiro SUZUKI @ WACATE2024冬 まずは単一のパラメタから。
16. 16 / 91 Kazuhiro SUZUKI @ WACATE2024冬 同値分割法 ◼ 動物園の入園料の仕様(1) ⚫ この仕様のテストを考える時、多くの人は条件反射的に、 「じゃあ、2パターンのテストやればよさそうね」と考えるかも。 ⚫ 来園者のもつ多くの属性と、その属性が持つ多くの値のテストだってできる。 - 性別は？ 本籍は？ 割引券は？ 来園頻度は？ 職業は？ ⚫ 同値分割法は、注目すべき属性に絞って、必要な値だけをテストすることで、 無数のパターンを2つに絞るという離れ業。 - 「全数テストは不可能」って話は、セッションでも出てきましたね！ てことで、同値分割法の解像度をちょっと高めてみましょう。 (*1) 「そもそも“乳幼児”の定義は？」から問うのは悪いQA仕草ではないが、ここでは割愛する。 ▶ 乳幼児(*1): 無料 ▶ それ以外: 500円
17. 17 / 91 Kazuhiro SUZUKI @ WACATE2024冬 同値分割法 ◼ 同値分割法の手続き ⚫ 注目している情報について、ベン図を描く - ここでは「乳幼児かどうか」というパラメタ(*1)に注目する。 ⚫ 同値パーティションを洗い出す - 「乳幼児である」「乳幼児でない」という2つがあるとわかる。 ⚫ 同値パーティションを網羅するためのテストケースを作る - たとえば「3歳のこども」と「高校3年生」という入力で網羅できる。 - 期待結果、テスト実行のための前提条件、実行手順などを決める。 無駄に細かい分割に思えるかも。国際規格を見てみましょう。 (*1) 前のスライドで「属性」と呼んでいたもの。「条件」「軸」と呼ぶこともある。 1 2 パラメタ 値の集合 同値パーティション 乳幼児でない 乳幼児である 乳幼児かどうか 3
18. 18 / 91 Kazuhiro SUZUKI @ WACATE2024冬 同値分割法 ◼ ISO/IEC/IEEE 29119 Part2におけるテスト設計プロセス ⚫ 29119はソフトウェアテストの国際規格。Part2はテストプロセスを規定したもの。 ⚫ 右図(*1)は、テスト設計/実装におけるアクティビティを示す。 ◼ 出てくる用語(*2) ⚫ テストアイテム: テストを行う作業成果物。 - 要は「テストする部分」。今回の例でいうと、入園料の判定機能。 ⚫ テストモデル: 特定の属性や品質にフォーカスしてテストできる ように、テストアイテムを表現したもの。 - テストアイテムで注目したい何かを図なり表なりで、表現したもの。 今回の例でいうと、「乳幼児かどうか」のベン図。 ⚫ カバレッジアイテム: テストアイテムの測定可能な属性。 - モデルから導出する「これを確認すれば網羅できる」というリスト。 - 今回の例でいうと、ベン図で表現された2つの同値パーティション。 (*1) ISO/IEC/IEEE 29119 Part2の図10「Test Design and Implementation Process」を発表者が翻訳・再構成したもの。 (*2) 同、Terms and Definitionを発表者が意訳したもの。 TD1: テストモデルの 作成 TD2: テストカバレッジ アイテムの識別 TD3: テストケースの 導出 TD4: テスト手順の作成 テストモデル テストカバレッジアイテム テストケース テスト手順
19. 19 / 91 Kazuhiro SUZUKI @ WACATE2024冬 同値分割法 ◼ テストモデル ⚫ 同値分割法は、同値パーティションの分割というモデリング方法を提示している。 たとえばISTQBシラバス(*1)では以下の通り。 - ある特定のパーティションのすべての要素がテスト対象によって同等に処理されることを 想定して、データをパーティションに分割する。 - パーティションは重複してはならず、空でない集合でなければならない。 ⚫ ただしかなり抽象的で、これだけで機械的に手続きすることは難しい。 ◼ カバレッジアイテム ⚫ 同値分割法は、同値パーティションの選択方法を提示している。 たとえばISTQBシラバス(*1)では以下の通り。 - カバレッジ100％を達成するために、識別されたすべてのパーティションを、 少なくとも1回はカバーするように通過しなければならない。 (*1) 前のスライドと一貫性がないが、有償国際規格よりもISTQBシラバスの方がアクセスしやすいため、こちらの定義や説明を引用（一部編集）している。
20. 20 / 91 Kazuhiro SUZUKI @ WACATE2024冬 ◼ テスト設計技法 整理テーブル この表を作りながら、テスト設計技法を概観しましょう。 ◼ 伏線: 同値分割法のカバレッジアイテムは、「値」ではない 同値分割法は、以下を前提に、同値パーティションを通じて値を網羅する。 ⚫ 入力値の範囲が広大であっても、少数の領域に分割して代表値をテストすることで、 すべての入力値をカバーできる。 ⚫ 分割する方法は、明示的あるいは暗黙的な仕様に含まれている。 同値分割法 1 2 カテゴリー テスト設計技法 カバレッジ対象 = 網羅したいもの 代表的なモデル 代表的なカバレッジ 基準 値のテスト 同値分割法 パラメタの範囲（＝同値パーティ ション） ベン図など 同値パーティション から最低1つ値を選択
21. 21 / 91 Kazuhiro SUZUKI @ WACATE2024冬 値が「連続する」性質を持つなら、 話がもう少し具体的になります。 想定経過時間 18:00
22. 22 / 91 Kazuhiro SUZUKI @ WACATE2024冬 境界値分析 ◼ 同値分割法が対象とするパラメタ(*1) ◼ 境界値分析が対象とするパラメタ(*1) 対象とする値の性質を絞っているのがポイント。 (*1) JSTQB Foundation Levelシラバスより引用。 同値パーティションは、入力、出力、構成アイテム、内部値、時間関連の値、 インターフェースパラメーターなど、テスト対象に関連するあらゆるデータ要素に ついて識別できる。パーティションは、連続または離散、順序性ありまたは 順序性なし、有限または無限のいずれでもよい。 同値パーティションの境界を確認することに基づいた技法である。 したがって、BVAは順序性のあるパーティションにのみ使用できる。
23. 23 / 91 Kazuhiro SUZUKI @ WACATE2024冬 境界値分析 ◼ 動物園の入園料の仕様(2) ◼ テストモデル ⚫ ベン図でも表現できるが、連続値の特徴を 活かし、より具体的にモデリングできる。 - 逆に言えば、同値分割法は対象となるパラメタの 種類が広いため、モデル作成が抽象的である。 ◼ カバレッジアイテム ⚫ モデルからカバレッジアイテムを導出する手続きが明確である。 ⚫ 境界値分析は、同値分割対象を「順序性のあるパラメタ」(*1)に制限する代わりに、 カバレッジアイテムの識別手順を具体的にした技法といえる。（制約と誓約） (*1) 順序性のあるパラメタとは、数値とは限らない。たとえば成績がA～Eで表現される場合、A～Eは順序性のあるパラメタと言える。 ▶ 65歳以上: 無料 ▶ それ以外: 500円 65 63 64 年齢 66 65歳未満である 65歳以上で ある 年齢 2値の選択では on として65、off として64を選ぶ。 3値の選択ではこれに加え、66を選ぶ。
24. 24 / 91 Kazuhiro SUZUKI @ WACATE2024冬 境界値分析 ◼ 雑談: 入力テキストボックスの「最大」 ⚫ テキストボックスへの値入力で「最大」と言われて思いつくのは‥ ➊ 最大文字数 ➋ 最大値（連続値の場合） ⚫ 鈴木は若かりし頃、 「最大文字数を入れるテストでは、連続の全角 Ｗ を使え」 と教えられた。そのココロは‥・？ ⚫ その頃のアプリケーションで、「表示が見切れる」問題がよくあった。 全角 Ｗ はプロポーショナルフォントで表示幅がもっとも広く、 全角 Ｗ 最大文字数 というデータが正しく表示されるなら、 それ以外の文字列の幅も問題ないだろうという理屈。 - 今比べてみると、Ｍ もなかなか強い‥ が、実は ＿ が最強らしい (*1)。 「最大」にもいろいろある、という小ネタでした。 (*1) 気になって軽くググったら、Excelのセルで検証しているサイトがあった。 一番文字幅が大きい文字は何か調べてみました。
25. 25 / 91 Kazuhiro SUZUKI @ WACATE2024冬 境界値分析 ◼ なんだろう、出題者よりしっかりした答えを出すの、 やめてもらっていいですか‥？
26. 26 / 91 Kazuhiro SUZUKI @ WACATE2024冬 ◼ テスト設計技法 整理テーブル こういう表を見ると、埋めたくなるのがQA屋さん。 縦軸、つまり「網羅したいもの」は他に何があるでしょう？ ‥「単一パラメタ」？ 境界値分析 カテゴリー テスト設計技法 カバレッジ対象 = 網羅したいもの 代表的なモデル 代表的なカバレッジ 基準 値のテスト 同値分割法 パラメタの範囲（＝同値パーティ ション） ベン図など 同値パーティション から最低1つ値を選択 境界値分析 順序性のある単一パラメタの範囲 の境界 数直線など 境界値の周り2値、3 値
27. 27 / 91 Kazuhiro SUZUKI @ WACATE2024冬 「単一パラメタ」があるなら、 「複数パラメタ」も考えてみよう。 想定経過時間 25:00
28. 28 / 91 Kazuhiro SUZUKI @ WACATE2024冬 ドメイン分析テスト(*1) ◼ 動物園の入園特典の仕様 ◼ ドメイン分析テスト ⚫ 仕様に関係するパラメタは複数ありうる。 複数のパラメタの境界をテストすべき時に適用する。 ⚫ パラメタ同士が関連し合う場合、2次元平面上に描くことで、境界もクリアになる。 ⚫ ドメイン分析テストが境界値分析のn次元以上の拡張と言ってもいいし、 境界値分析がドメイン分析のn=1特殊版と言えるかもしれない。 (*1)ドメイン（domain）とは、数学用語でいう「定義域」のこと。つまりは「入力の範囲」を意味する。 以下の条件を満たす入園者には、 オリジナルグッズをプレゼントする。 ▶ 入園料が300円以上 ▶ かつ 園内での買い物が200円以上 ▶ かつ 合わせて600円以上 買い物 200 400 対象外 対象外 600 200 400 入園料 800 対象外 対象 0 対象外
29. 29 / 91 Kazuhiro SUZUKI @ WACATE2024冬 ドメイン分析テスト ◼ テストモデル ⚫ 前スライドのように、パラメタが2個であれば、2次元平面上で表現可能。 ⚫ Binderの「ドメイン分析テストマトリクス」で、表形式での表現もできる（下図）。 ◼ カバレッジアイテム ⚫ 注目するパラメタの境界値と、それ以外のパラメタの代表値を組み合わせて網羅する。 パラメタ 1 2 3 4 5 6 入園料が 300円以上 On 300 Off 299 In 500 450 350 320 買い物が 200円以上 On 200 Off 199 In 500 400 250 279 合計が 600円以上 On 600 Off 599 In 800 699 700 549
30. 30 / 91 Kazuhiro SUZUKI @ WACATE2024冬 ◼ テスト設計技法 整理テーブル さて、このまま各技法を表に埋めていってもいいのですが、 飽きてきましたね？ 境界値分析 カテゴリー テスト設計技法 カバレッジ対象 = 網羅したいもの 代表的なモデル 代表的なカバレッジ 基準 値のテスト 同値分割法 パラメタの範囲（＝同値パーティ ション） ベン図など 同値パーティション から最低1つ値を選択 境界値分析 順序性のある単一パラメタの範囲 の境界 数直線など 境界値の周り2値、3 値 ドメイン分析テスト 順序性のある複数パラメタの範囲 の境界 直交座標など 境界値分析と同様
31. 31 / 91 テスト設計技法の分類 想定経過時間 29:00
32. 32 / 91 Kazuhiro SUZUKI @ WACATE2024冬 テスト設計技法の分類 今日はテスト設計技法を整理していっているわけですが、 テスト設計技法の分類の方法は、他にもあります。 ◼ テスト設計技法の目的に基づく分類 ◼ テスト技法ポジショニングマップ 1 2
33. 33 / 91 Kazuhiro SUZUKI @ WACATE2024冬 テスト設計技法の分類 ◼ テスト設計技法の目的に基づく分類(*1) ⚫ 技法の主たる3つの目的で分ける。 - 3つの目的は、必ずしもMECEとは言えないかもしれない‥。 (*1) 『ASTERセミナー標準テキスト』を参考に発表者が作成。 (*2) ブラックボックステストは、「コードを意識しない」というより、「コードよりも仕様をベースに設計したテスト」と考えられる。「グレーボックステスト」 という言葉もある。なお、ブラック・ホワイト両方で使う技法もある。 ブラックボックステスト(*2) • 同値分割 • 組み合わせテスト • 境界値分析 • 探索的テスト • デシジョンテーブル • 状態遷移テスト • シナリオテスト ホワイトボックステスト • 制御フローテスト • データフローテスト テストケースを合理的に 少なくする 多くの欠陥が 見つかるようにする テスト対象を漏れなく テストする 1
34. 34 / 91 Kazuhiro SUZUKI @ WACATE2024冬 テスト設計技法の分類 ◼ 効果: 多くのバグを検出できること ⚫ どれだけバグを見逃さずに済むかが大事。左上の例だと、 - バグ検出効果 = 4/6 = 67% - バグ検出効率 = 4/36 = 11% ⚫ 理論的には、「全数テスト」は効果が最高。が、効率は低い。 ⚫ 同値分割法は、同値パーティションで全体を網羅するので効果的。 ◼ 効率: かけた時間に対して、検出できるバグが多いこと ⚫ 重要なバグが出そうな場所を集中的に確認する。左下の例だと、 - バグ検出効果 = 3/6 = 50% - バグ検出効率 = 3/13 = 23% ⚫ テスト開始直後に欠陥を1つ見つければ効率は最高。が、効果は低い。 ⚫ 境界値分析は、バグりやすい値を叩くので効率的(*1)。 技法単品ではなく、技法同士の違いを 考えてみると面白い。（と思う人もいる） (*1)境界値分析は、同値分割の特性を併せ持つので、効果的でもある。 テストすべき範囲 テストすべき範囲 見つかるバグ 見つからないバグ 補 完 テスト実行
35. 35 / 91 Kazuhiro SUZUKI @ WACATE2024冬 テスト設計技法の分類 ◼ テスト技法ポジショニングマップ(*1)での分類 ⚫ 網羅的 – ピンポイント の軸と、ブラックボックス – ホワイトボックスの軸で分類。 - 今日の発表は「網羅」が1つのキーワードなので、右側の技法がたくさん出てくる。 では、この辺に進んでいきましょう。 (*1) 作成者である秋山浩一さんのnoteから引用。 2
36. 36 / 91 値の組み合わせのテスト （論理関係あり） 想定経過時間 35:00
37. 37 / 91 Kazuhiro SUZUKI @ WACATE2024冬 「値」がわかったところで、 「値の組み合わせ」を見ていきます。
38. 38 / 91 Kazuhiro SUZUKI @ WACATE2024冬 ◼ 動物園の入園料の仕様(3) ⚫ 複数パラメタの組み合わせルールによって 結果が決まる。これを「有則」という。 ◼ どのように表現するか ⚫ 3つのパラメタ「中学生かどうか」「都内在住かどうか」「都内在学かどうか」の ベン図を組み合わせると、23で8つのエリアをもつベン図になる。 ⚫ 直感的にはわかりやすいけれど、パラメタが4つ以上になったり、パラメタの 取り得る値が3つ以上になると、途端に表現が困難になる。 デシジョンテーブルテスト ▶ 中学生: 200円 ▶ 都内在住または在学の中学生: 無料 ▶ それ以外: 500円 都内在住でも都内在学でも中学生でもない 都内在住 である 都内在学 である 中学生である 中学生でない 中学生で ある 都内在住である 都内在住 である 都内在学である 都内在学 でない
39. 39 / 91 Kazuhiro SUZUKI @ WACATE2024冬 デシジョンテーブルテスト ◼ 雑談: 「生きがい」を表すベン図 ⚫ 右のような図(*1)で、海外でも知られるように なったらしい日本語「生きがい」。 ⚫ 内容に納得するかどうかはともかく、4つの要素 「あなたが好きなこと」 「あなたが得意なこと」 「あなたが稼げること」 「世の中が必要としていること」 をシンメトリックに美しくまとめている。が‥ ⚫ 4つの要素がそれぞれT/Fの2値を取るのに、 パーティションは14個しかない！(*1) そこで表形式ですよ！ (*1) Twitterより引用。 (*2) 向かい合う2つの要素のみを含む領域がない。たとえば「LOVE」と「PAID FOR」が重なる領域にはすべて、「GOOD AT」か「NEEDS」がかかっている。
40. 40 / 91 Kazuhiro SUZUKI @ WACATE2024冬 デシジョンテーブルテスト ◼ テストモデル: デシジョンテーブル ⚫ 直感性においてはベン図に劣るが、すべての組み合わせの洗い出しが容易。 - 横に並んだ「ルール」は8個。これは先のスライドのベン図で区分された8つのエリアに対応。 ⚫ 以下は、鈴木の好みの表現形式。仕様に関連するパラメタが何か、 それぞれのパラメタがどんな値を取り得るかを明確に把握できる。 - それぞれのパラメタを同値分割していることが見て取れる。 パラメタ 値 1 2 3 4 5 6 7 8 中学生か？ YES • • • • NO • • • • 都内在住か？ YES • • • • NO • • • • 都内在学か？ YES • • • • NO • • • • 入園料 無料 • • • 200円 • 500円 • • • •
41. 41 / 91 Kazuhiro SUZUKI @ WACATE2024冬 デシジョンテーブルテスト ◼ カバレッジアイテム ⚫ 各パラメタの同値パーティションの可能な組み合わせを網羅することが、 カバレッジアイテムの基本となる。 - 3つのパラメタがそれぞれ2つの値を取り得るので、カバレッジアイテムは8つのルール。 ⚫ パラメタの判定の処理順がわかっている場合は、テーブルを簡単化（圧縮）できる。 - 下の例では、パラメタを上から順に処理しているとわかっている場合の簡単化。 他に表現方法はないか？ パラメタ 値 5 - 8 1-2 3 4 中学生か？ YES • • • NO • 都内在住か？ YES • NO • • 都内在学か？ YES • NO • 入園料 無料 • • 200円 • 500円 • 都内在住でも都内在学でも中学生でもない 5-8 1-2 都内在住 都内在学 3 4 中学生
42. 42 / 91 Kazuhiro SUZUKI @ WACATE2024冬 CFD法 ◼ 原因流れ図（CFD） ⚫ 「原因」は、デシジョンテーブルでいう条件。 「結果」は、デシジョンテーブルでいう動作。 ⚫ 原因となるノードを、処理の順番に従って 結んでいくことでモデリングする(*1)。 ⚫ その結果は、デシジョンテーブルで表現できる。 ◼ あらためて、デシジョンテーブルとは‥ 2つの役割があると理解するとわかりやすい。 ⚫ 組み合わせをモデリングするための記法 ⚫ カバレッジアイテムを表現するための記法 デシジョンテーブルテストでは➊➋両方で使う。 CFDでは、デシジョンテーブルを➋の用途で使う。 あんまりわかりやすくないか‥？ (*1) 加瀬 正樹氏が開発した「Draw CFD」を用いて作成。 原因 結果 1 2
43. 43 / 91 Kazuhiro SUZUKI @ WACATE2024冬 有則の組み合わせテスト ◼ カルノー図(*1)（Karnaugh map） ⚫ カルノー図、ベイチ図といった記法もある。 - 実務で使ったことはないけれど‥ (*1) Qiita記事『複雑なif文をカルノー図/ベイチ図で単純化しよう』を参考にした。 都内在住 : 都内在学 00 01 11 10 中学生 0 1 500円 0円 200円 0円
44. 44 / 91 Kazuhiro SUZUKI @ WACATE2024冬 ◼ テスト設計技法 整理テーブル あれ？ そういえば「複数パラメタ」って、 ドメイン分析テストの対象だったのでは‥？ 有則の組み合わせテスト カテゴリー テスト設計技法 カバレッジ対象 = 網羅したいもの 代表的なモデル 代表的なカバレッジ 基準 値のテスト 同値分割法 パラメタの範囲（＝同値パーティ ション） ベン図など 同値パーティション から最低1つ値を選択 境界値分析 順序性のある単一パラメタの範囲 の境界 数直線など 境界値の周り2値、3 値 ドメイン分析テスト 順序性のある複数パラメタの範囲 の境界 直交座標など 境界値分析と同様 値の組み合わ せテスト（有 則） デシジョンテーブルテ スト 論理関係のあるパラメタ同士の組 み合わせ デシジョンテーブル すべての組み合わせ 圧縮した組み合わせ CFD法 原因流れ図 圧縮した組み合わせ
45. 45 / 91 Kazuhiro SUZUKI @ WACATE2024冬 有則の組み合わせテスト ◼ 複数パラメタの組み合わせのテスト ⚫ ドメイン分析テストと、デシジョンテーブルテストなどのテスト、何が違う？ ⚫ 両者は無関係ではなく、以下のように関係づけられるのではないか。 デシジョンテーブルテスト ドメイン分析テスト パラメタの性質 限定しない 値が連続するパラメタのみ カバーしたい部分 複数パラメタの値の組み合わせ 複数パラメタからなる値の領域の 境界 同値分割 境界値分析 デシジョン テーブル ドメイン分析 連続値に限定し、 境界に注目 複数のパラメタを扱う拡張 複数のパラメタを扱う拡張 連続値に限定し、 境界に注目
46. 46 / 91 パラメタの 組み合わせのテスト （論理関係なし） 想定経過時間 55:00
47. 47 / 91 Kazuhiro SUZUKI @ WACATE2024冬 前のセクションは、各パラメタの値が 決まって初めて、結果が決まった。 次に、独立しているはずのパラメタの 値の組み合わせを見ていきます。
48. 48 / 91 Kazuhiro SUZUKI @ WACATE2024冬 ◼ チケット購入の仕様 ◼ 「有則」ではない ⚫ あるパラメタによって決まる挙動が、他のパラメタの影響を受けない。 - 発券されるチケット種別は、指定した「チケット種別」によってのみ決まる。 「枚数」が何枚でも「支払方法」が何でも、発券されるチケット種別には影響がない。 ⚫ この性質を、「有則」に対して「無則」という。 券売機では以下を選択してチケットを購入できる。 選択の順番は任意である。 ▶ チケット種別: 一般、中高生、小学生以下 ▶ チケットデザイン: 通常版、期間限定版（2枚まで） ▶ 枚数: 1枚、2枚、3枚 ▶ 支払方法: 現金、交通系IC、クレカ 直交表・オールペア法
49. 49 / 91 Kazuhiro SUZUKI @ WACATE2024冬 ◼ 有則: 複数のパラメタの値の組み合わせで結果が決まる。 ◼ 無則: 複数のパラメタの値が、それぞれ別の結果にのみ影響する。 パラメタ: 支払内容は？ 結果: 支払内容 直交表・オールペア法 (*) 並木さんのセッションを聴きながら突貫で作りました‥。 結果: 金額 パラメタ1: 中学生か？ パラメタ2: 都内在住か？ パラメタ3: 都内在学か？ パラメタ: 支払内容は？ 結果: 支払内容 パラメタ1: 枚数は？ パラメタ2: 種別は？ パラメタ3: 支払方法は？ 結果1: 枚数 結果2: 種別 結果3: 支払方法 よく見ると パラメタ1: 枚数は？ パラメタ2: 種別は？ パラメタ3: 支払方法は？
50. 51 / 91 Kazuhiro SUZUKI @ WACATE2024冬 直交表・オールペア法 ◼ テストモデル ⚫ 選択した直交表に因子を割り当てたものは、モデルといえるだろう。 ⚫ オールペア法のツール「PICT」の記法に応じた記述や、GIHOZ(*1)・PictMasterなどの ツールで用いるパラメタ表・制約表も、モデルといえるだろう。 (*1) GIHOZによるモデリング。パラメタのリストと制約のリストを表形式で表現している。 PICTの場合 IF [チケットデザイン] = “期間限定版” THEN [枚数] IN {1枚, 2枚}; のように書く。 ちなみにこの1行1行も、 各パラメタの同値分割
51. 52 / 91 Kazuhiro SUZUKI @ WACATE2024冬 直交表・オールペア法 ◼ カバレッジアイテム ⚫ 今回の例だと、4つのパラメタがそれぞれ3・2・3・3個の値を取りうるため、 すべての値を組み合わせようとすると54パターンのテストが必要となる。 ⚫ 組み合わせテストは、「部分的な組み合わせ」を網羅することで、 組み合わせの数を抑制する方法を提供している。 - 右の例では「2-wiseカバレッジ」、つまり任意の2つの パラメタ間で、値の組み合わせを網羅している。 - 制約の指定により、「期間限定版は2枚までしか買えない」 ことも考慮されている。 (*1) GIHOZによるテストケース生成。
52. 53 / 91 Kazuhiro SUZUKI @ WACATE2024冬 クラシフィケーションツリー ◼ テストモデル ⚫ クラシフィケーションツリーという記法は、考慮すべきパラメタ、パラメタの取る値、 パラメタ同士の関係を視覚的にモデリングできる。 ⚫ ここからカバレッジアイテムを識別する方法も提示しているが、どちらかといえば モデリング目的の要素が強く、その結果を直交表やオールペア法のインプットとして カバレッジアイテムを識別する、という補完関係と見なすのがよいのではないか。 (*) 参考: JaSST’24東北のワークショップ資料 購入オプ ション チケット 種別 チケット デザイン 交通系IC 一般 中高生 通常版 枚数 支払方法 1枚 現金 2枚 3枚 小学生 以下 期間 限定版 クレカ クラシフィケーション クラス
53. 54 / 91 Kazuhiro SUZUKI @ WACATE2024冬 ◼ テスト設計技法 整理テーブル 無則の組み合わせテスト カテゴリー テスト設計技法 カバレッジ対象 = 網羅したいもの 代表的なモデル 代表的なカバレッジ基準 値のテスト 同値分割法 パラメタの範囲（＝同値パーティショ ン） ベン図など 同値パーティションから 最低1つ値を選択 境界値分析 順序性のある単一パラメタの範囲の境 界 数直線など 境界値の周り2値、3値 ドメイン分析テスト 順序性のある複数パラメタの範囲の境 界 直交座標など 境界値分析と同様 値の組み合わせ テスト（有則） デシジョンテーブルテス ト 論理関係のあるパラメタ同士の組み合 わせ デシジョンテーブル すべての組み合わせ 圧縮した組み合わせ CFD法 原因流れ図 圧縮した組み合わせ 組み合わせテス ト（無則） 直交表 論理関係のないパラメタ同士の組み合 わせ 直交表 n因子網羅 オールペア法 パラメタリストと制約リ スト n因子網羅 クラシフィケーションツ リー法 クラシフィケーションツ リー ー
54. 55 / 91 Kazuhiro SUZUKI @ WACATE2024冬 無則の組み合わせテスト ◼ 有則と無則の比較 ⚫ 有則にしろ無則にしろ、「パラメタの値を組み合わせる」点では同じ。 ⚫ 有則の組み合わせテストは、値を組み合わせることで、 パラメタ同士の論理が正しく動作することを網羅的に確認する。 ⚫ 無則の組み合わせテストは、値を組み合わせることで、 パラメタ同士に論理がないことを網羅的に確認する。 ⚫ 有則の組み合わせテストは、以下の2つの手段で組み合わせ数を減らす。 - 入力の範囲が広いため、同値分割法を使って値のグルーピング(*1)する - 処理順を意識して、組み合わせを簡単化する ⚫ 無則の組み合わせテストは、以下の手段で組み合わせ数を減らす。 - 全組み合わせではなく、組み合わせるパラメタの数を絞ることで、組み合わせ爆発を 抑制する (*1) オールペア法でも、同じ挙動をすると考えられる値を「エイリアス」という形でまとめることが可能である。
55. 56 / 91 順序のテスト 想定経過時間 63:00
56. 57 / 91 Kazuhiro SUZUKI @ WACATE2024冬 パラメタ・値とはまったく違う視点、 それが「順序」です。
57. 58 / 91 Kazuhiro SUZUKI @ WACATE2024冬 状態遷移テスト ◼ 動物園の期間チケットの仕様 ⚫ 期間チケットの「状態」という切り口を考えると、状態遷移テストが適用候補になる。 「期間チケット」の仕様は以下の通り。 ▶ 指定された期間内で、1日選んで 使用することができる。 ▶ 入園すると「使用中」状態となり、 その日は何度でも入退園ができる。 ▶ 使用した日の閉園時間が過ぎると 「使用済み」となる。 ▶ 指定された期間を過ぎると、 「期限切れ」となる。
58. 59 / 91 Kazuhiro SUZUKI @ WACATE2024冬 状態遷移テスト ◼ テストモデル ⚫ 状態遷移図・表で、テスト対象の状態についてのふるまいをモデリングできる。 ⚫ 状態遷移図(*1)は主な遷移パターンや全体像が見えやすく、 状態遷移表は例外的なパターンも含めた網羅性を確認しやすい。 (*1) GIHOZで作図。「使用中かつ入園中」と「使用中かつ退園中」を状態として区別するか、「同値」と見なすかは、何をテストしたいかによる。
59. 60 / 91 Kazuhiro SUZUKI @ WACATE2024冬 状態遷移テスト ◼ カバレッジアイテム ⚫ 状態カバレッジ(*1): すべての状態を網羅 ⚫ 有効遷移カバレッジ: 単一の有効な遷移をすべて網羅 ⚫ 全遷移カバレッジ: 単一の有効または無効な遷移をすべて網羅 ⚫ スイッチカバレッジ: n回連続の遷移を網羅 - 1スイッチの例: 未使用 (入園する) 使用中かつ入園中 (閉園時間が過ぎる) 使用済み (*1) イベントを網羅する「イベントカバレッジ」というものもある。 イベント 状態 入園する 退園する 使用日の閉園 時間が過ぎる 使用期限が 過ぎる 未使用 使用中 かつ 入園中 使用中 かつ 退園中 can’t happen 期限切れ 使用中 かつ 入園中 ignore 使用中 かつ 退園中 使用済み can’t happen 使用中 かつ 退園中 使用中 かつ 入園中 ignore 使用済み can’t happen 使用済み ignore ignore can’t happen ignore 期限切れ Ignore ignore can’t happen can’t happen
60. 61 / 91 Kazuhiro SUZUKI @ WACATE2024冬 状態遷移テストが注目しているのは、 システム側の「状態」の順序。 人のふるまいの順序も考えてみましょう。
61. 62 / 91 Kazuhiro SUZUKI @ WACATE2024冬 ユースケーステスト ◼ ユースケーステスト ⚫ 状態遷移テストは、システム側の「状態」に着目していた。 ⚫ ユースケースはその名の通り、ユーザーによるシステム「利用」の流れに着目する。 ◼ 入園チケット購入の手順(*1) (*1) この記述は、特定のユースケース記述ルールに従っているものではない。 券売機でのチケット購入の手順は以下の通り。 1. ユーザは、チケット種別・枚数・支払方法を選び、「次へ」ボタンを押す。 2. システムは入力情報を元に、購入内容を表示する。 3. ユーザは購入内容を確認し、問題なければ「支払いへ」ボタンを押す。 a. 購入内容を変更したい場合は、ユーザは「戻る」ボタンを押し、1.に戻る。 4. システムは支払画面を表示する。 5. ユーザは、最初に選択した方法で支払を行う。 a. 残高不足などエラー時には、システムはメッセージを表示し、1.に戻る。
62. 63 / 91 Kazuhiro SUZUKI @ WACATE2024冬 ユースケーステスト ◼ テストモデル ⚫ ユースケース記述自体がモデルであると言える。 ⚫ これをフローチャートのような形で表現したものも モデルになりそう。 ◼ カバレッジアイテム ⚫ 基本的な流れと、「代替」と呼ばれる例外的な流れを 最低限カバーする。 ⚫ 「代替の流れで手順が前に戻り、その後は基本的な流れで 進める」 といった、制御フローテスト的なカバレッジもある。 状態遷移テストとユースケーステストは、 ルールのある順序を網羅する技法といえる。 購入内容を選択 次へ 戻る 支払いへ 開始 終了 内容に問 題なし? 正常決済 された？ 戻る
63. 64 / 91 Kazuhiro SUZUKI @ WACATE2024冬 ◼ テスト設計技法 整理テーブル 順序のテスト カテゴリー テスト設計技法 カバレッジ対象 = 網羅したいもの 代表的なモデル 代表的なカバレッジ基準 値のテスト 同値分割法 パラメタの範囲（＝同値パーティショ ン） ベン図など 同値パーティションから最 低1つ値を選択 境界値分析 順序性のある単一パラメタの範囲の境界 数直線など 境界値の周り2値、3値 ドメイン分析テスト 順序性のある複数パラメタの範囲の境界 直交座標など 境界値分析と同様 値の組み合わせ テスト（有則） デシジョンテーブルテスト 論理関係のあるパラメタ同士の組み合わ せ デシジョンテーブル すべての組み合わせ 圧縮した組み合わせ CFD法 原因流れ図 圧縮した組み合わせ 組み合わせテス ト（無則） 直交表 論理関係のないパラメタ同士の組み合わ せ 直交表 n因子網羅 オールペア法 パラメタリストと制約リス ト n因子網羅 クラシフィケーションツ リー法 クラシフィケーションツ リー ー 順序のテスト 状態遷移テスト 順序に制約のあるシステムの遷移順序 状態遷移図 状態遷移表 状態網羅・イベント網羅 遷移網羅、nスイッチ ユースケーステスト 順序の制約のあるユーザの実行順序 ユースケース記述 基本/代替ユースケース
64. 65 / 91 網羅技法の網羅性 想定経過時間 67:00
65. 66 / 91 Kazuhiro SUZUKI @ WACATE2024冬 ここからは、何らかの結論ではなく、 わたしの問いをみなさんに ぶん投げていきます。
66. 67 / 91 Kazuhiro SUZUKI @ WACATE2024冬 もう一度、整理表を見てみましょう。
67. 68 / 91 Kazuhiro SUZUKI @ WACATE2024冬 網羅技法の網羅性 ◼ テスト設計技法 整理テーブル カテゴリー テスト設計技法 カバレッジ対象 = 網羅したいもの 代表的なモデル 代表的なカバレッジ基準 値のテスト 同値分割法 パラメタの範囲（＝同値パーティショ ン） ベン図など 同値パーティションから最 低1つ値を選択 境界値分析 順序性のある単一パラメタの範囲の境界 数直線など 境界値の周り2値、3値 ドメイン分析テスト 順序性のある複数パラメタの範囲の境界 直交座標など 境界値分析と同様 値の組み合わせ テスト（有則） デシジョンテーブルテスト 論理関係のあるパラメタ同士の組み合わ せ デシジョンテーブル すべての組み合わせ 圧縮した組み合わせ CFD法 原因流れ図 圧縮した組み合わせ 組み合わせテス ト（無則） 直交表 論理関係のないパラメタ同士の組み合わ せ 直交表 n因子網羅 オールペア法 パラメタリストと制約リス ト n因子網羅 クラシフィケーションツ リー法 クラシフィケーションツ リー ー 順序のテスト 状態遷移テスト 順序に制約のあるシステムの遷移順序 状態遷移図 状態遷移表 状態網羅・イベント網羅 遷移網羅、nスイッチ ユースケーステスト 順序の制約のあるユーザの実行順序 ユースケース記述 基本/代替ユースケース 4 3 1 2
68. 69 / 91 Kazuhiro SUZUKI @ WACATE2024冬 網羅技法の網羅性 ◼ 「網羅したいもの」はこれだけ？ ⚫ テストでは「網羅」「網羅」とメチャクチャ言われる。 ⚫ この表では、網羅したい対象を網羅できているのか‥？ ◼ 4つの点に注目して掘り下げてみる ⚫ 同値分割法の下にあるのは「順序性のあるパラメタ」だけか？ ⚫ 値を網羅するアプローチは、同値分割法のみなのか？ ⚫ 「順序の制約のある実行手順」があるなら、「制約のない実行手順」もあるのでは？ ⚫ 網羅したいもののカテゴリーって、 「パラメタの範囲」、「パラメタの組み合わせ」、「順序」の他にもないか？ 1 2 3 4
69. 70 / 91 Kazuhiro SUZUKI @ WACATE2024冬 順序性のないパラメタ ◼ 同値分割法の下にあるのは「順序性のあるパラメタ」だけか？ ◼ なぜ同値分割法は「分け方」を具体的に教えてくれないのか ⚫ 「分け方」は仕様そのものだから。 - たとえば「パスワードに許容する文字」は、システムによって仕様が違うだろう。 ◼ 連続値以外では、同値分割法を具体化できないのか ⚫ 仕様への依存が強い部分はパターン化しても汎用性が低いが、 よく使うものはテスト設計としてパターン化することができる。 1
70. 71 / 91 Kazuhiro SUZUKI @ WACATE2024冬 順序性のないパラメタ ◼ 同値分割パターン ⚫ たとえばパラメタが「文字」の時 - CSVファイルの入出力機能: カンマ , 、ダブルクォーテーション “ 、改行文字 ¥n 、その他の 特殊文字・絵文字 などは、別の同値パーティションとして扱うだろう。 ⚫ 日時は連続値だと思われがちだが(*1) - うるう日や、特定の月にしかない29・30・31日は、他の日と同じパーティションにないかも。 > 2000年問題、昭和100年問題(*1)、497日問題(*2)は、連続値における境界値だろう。 ⚫ このように、「あまり明文化されていない特殊値」みたいなものがある。 「よく使うテスト入力セット」は、 名もなき同値分割パターンの1つといえるのでは？ それをナレッジとして蓄積しているか？ (*1) 2025年は昭和でいうと100年目にあたり、年数を2桁で扱っていた場合に昭和100年を昭和0年と誤判断しうる問題。 (*2) システム稼働時間を1/100秒単位、32bitカウンターで管理している場合、約497日でカウンターが上限に達してしまう問題。
71. 72 / 91 Kazuhiro SUZUKI @ WACATE2024冬 同値分割法の限界 ◼ 値を網羅するアプローチは、同値分割のみなのか？ ◼ テスト設計技法 整理テーブルを見てみよう ◼ 同値分割法の網羅対象は？ ⚫ 網羅対象は「同値パーティション」とした。でも本来カバーしたいのは「値」のはず。 ⚫ 同値分割法は以下を前提に、同値パーティションを通じて値を網羅する。 - 入力値の範囲が広大であっても、少数の領域に分割して代表値をテストすることで、 すべての入力値をカバーできる。 - 分割する方法は、明示的あるいは暗黙的な仕様に含まれている。 この前提が成り立たないとき、どのように値を網羅する？ 1 2 2 カテゴリー テスト設計技法 カバレッジ対象 = 網羅したいもの 代表的なモデル 代表的なカバレッジ基準 値のテスト 同値分割法 パラメタの範囲（＝同値パーティショ ン） ベン図など 同値パーティションから最 低1つ値を選択 境界値分析 順序性のある単一パラメタの範囲の境界 数直線など 境界値の周り2値、3値 ドメイン分析テスト 順序性のある複数パラメタの範囲の境界 直交座標など 境界値分析と同様
72. 73 / 91 Kazuhiro SUZUKI @ WACATE2024冬 同値分割法の限界 ◼ 同値分割法の前提が成り立たないケース ⚫ 同値パーティションの定義である「同等に処理される」かがわからないことがある。 - たとえば画像の分類を行うAIのプログラムで、 「画像Aが正しく分類されたから、それに似た画像Bもうまく分類されるだろう」 と自信を持つことができない。 - 生成AIでも、「同じ意味で、表現が少しだけ違う」プロンプトでも結果が全然違ったりする。 ⚫ よって、「少ない代表値で多くの値をカバー」することが難しい。 ◼ 同値分割法の考え方を振り返ると ⚫ 値を網羅するには、「同値パーティションに分けて代表値のみをテストする」が 唯一合理的な選択肢に思えた。つまり「テストケースを減らす」ことが正義。 ⚫ 同値分割が効きづらい分野では逆に、「テストケースをロジカルに増やす」ことが 解決策になっている。 (*1) メタモルフィックテストでは、機械学習のテストにおけるテストオラクル問題（期待結果を決めづらい）も、「元のテストケースの正しさをベースにして、期 待結果も生成する」ことで軽減していると言えるだろう。と言いつつ、メタモルフィックテストについてわたしは実践経験がございません‥。
73. 74 / 91 Kazuhiro SUZUKI @ WACATE2024冬 同値分割法の限界 ◼ メタモルフィックテスト ⚫ 正しいとわかっている元テストケースから、別のテストケースをたくさん生成する。 - 画像分類において、ある画像が「猿」だとわかっていれば、 その画像を90度回転させても「猿」と判定されるべき。という考え方。 ⚫ 同値分割法を適用しづらいという課題を、大量のテストケースのパワーで軽減。 ◼ テストケース数のパラダイム ⚫ テスト設計技法の目的の1つは「テストケースを合理的に少なくする」。 極論すると、「テストケースが多いことは悪」というパラダイムである。 しかし、できるだけ多くのテストケースを作りたい場合が生まれてきている。
74. 75 / 91 Kazuhiro SUZUKI @ WACATE2024冬 同値分割法の限界 ◼ 「テストケースを増やしたい」場合とは？ A) カバレッジが足りない - たとえば制御カバレッジにおいて、命令網羅では不足しているため、判定網羅を適用する。 B) 殺虫剤のパラドックスを防ぎたい - たとえば、抽象的には同じテストケースでも、具体値としては様々なパターンを試す。 - プロパティベースドテストがこれに類する発想の技術と思われる。 C) 同値パーティションが無数にある - たとえば動的セキュリティツールで、怪しい文字・文字列をひたすら入力確認する。 - ファズテストなどがこれに対応しそう。 D) 同値パーティションが識別できない - 「ここからここまでの入力は、全部同じ出力になる」と言いづらく、多くのパターンを試すことが必要。 テストケースを簡易・合理的に「増やす」手法を もっと開拓する必要が出てくるのではないか？
75. 76 / 91 Kazuhiro SUZUKI @ WACATE2024冬 順序制約のない実行手順 ◼ 「順序制約のない実行手順」もあるのではないか？ ◼ チケット購入の仕様 ⚫ 選択の順番を変えても挙動が変わらないことを確認したい場合がある。 ⚫ 「チケット種別」 「デザイン」 「枚数」「支払方法」を選ぶ順番は、24通り。 - 種デ枚法、種デ法枚、種枚法デ、種枚デ法、種法デ枚、種法枚デ、 デ枚法種、デ枚種法、デ法種枚、デ法枚種、デ種枚法、デ種法枚、 枚法種デ、枚法デ種、枚種デ法、枚種法デ、枚デ法種、枚デ種法、 法種デ枚、法種枚デ、法デ枚種、法デ種枚、法枚種デ、法枚デ種、 3 券売機では以下を選択してチケットを購入できる。 選択の順番は任意である。 ▶ チケット種別: 一般、中高生、小学生以下 ▶ チケットデザイン: 通常版、期間限定版（2枚まで） ▶ 枚数: 1枚、2枚、3枚 ▶ 支払方法: 現金、交通系IC、クレカ
76. 77 / 91 Kazuhiro SUZUKI @ WACATE2024冬 順序制約のない実行手順 ◼ シーケンスカバリングアレイ ⚫ 要素がn個ある時、ありうる順番はn!通りになり、すぐに爆発してしまう。 ⚫ 無則の組み合わせテストと同じ発想で、 「n個の要素から任意のk個を選んだ時に、そのk個のとりうる順番をすべて網羅する」 ことで、合理的に組み合わせを削減することができる。 - k = 3 とすると、以下の24個の順番を含みたい。 種とデと枚: 種デ枚、種枚デ、デ枚種、デ種枚、枚種デ、枚デ種 デと枚と法: デ枚法、デ法枚、枚法デ、枚デ法、法デ枚、法枚デ 種とデと法: 種デ法、種法デ、デ法種、デ種法、法種デ、法デ種 種と枚と法: 枚法種、枚種法、法種枚、法枚種、種枚法、種法枚 - 以下の8パターンで、すべてをカバーすることができる。 種デ枚法、デ法枚種、法枚種デ、枚法デ種、枚デ種法、法デ種枚、種法デ枚、種枚デ法 (*1) 秋山浩一さんのnote記事『Software Testing ManiaXへの寄稿』を参考に作成。
77. 78 / 91 Kazuhiro SUZUKI @ WACATE2024冬 順序制約のない実行手順 ◼ モデル ⚫ 順番付ける要素の列挙自体がモデルと言えるか。 ◼ カバレッジアイテム ⚫ 秋山浩一さんの2010年の記事(*1)によると、以下の通り。 - 最小の sequence-covering array を生成するアルゴリズムは今のところ開発されていない。 - D. Richard Kuhn氏が quick and dirty‘ greedy algorithm を公開している。 パラメタの組み合わせと同じく実行順序についても、 「有則」「無則」のテストがある、と言えるのかもしれない。 この発想を、さらに活かすことはできないだろうか？ (*1) 『シーケンスカバリングアレイ』
78. 79 / 91 Kazuhiro SUZUKI @ WACATE2024冬 網羅したいもののカテゴリー ◼ テスト設計技法 整理テーブル カテゴリー テスト設計技法 カバレッジ対象 = 網羅したいもの 代表的なモデル 代表的なカバレッジ基準 値のテスト 同値分割法 パラメタの範囲（＝同値パーティション） ベン図など 同値パーティションから最低 1つ値を選択 境界値分析 順序性のある単一パラメタの範囲の境界 数直線など 境界値の周り2値、3値 ドメイン分析テスト 順序性のある複数パラメタの範囲の境界 直交座標など 境界値分析と同様 文字の網羅 文字種別 ー ー ‥ 値の組み合わせテ スト（有則） デシジョンテーブルテスト 論理関係のあるパラメタ同士の組み合わせ デシジョンテーブル すべての組み合わせ 圧縮した組み合わせ 原因流れ図 原因流れ図 圧縮した組み合わせ 組み合わせテスト （無則） 直交表 論理関係のないパラメタ同士の組み合わせ 直交表 n因子網羅 オールペア法 パラメタリストと制約リスト n因子網羅 クラシフィケーションツリー 法 クラシフィケーションツリー ー 順序のテスト 状態遷移テスト 順序に制約のあるシステムの遷移順序 状態遷移図 状態遷移表 状態網羅・イベント網羅 遷移網羅、nスイッチ ユースケーステスト 順序の制約のあるユーザの実行順序 ユースケース記述 基本/代替ユースケース シーケンスカバリングアレイ 順序の制約のないユーザの実行順序 アクションリスト n因子網羅 ‥
79. 80 / 91 Kazuhiro SUZUKI @ WACATE2024冬 網羅したいもののカテゴリー ◼ 網羅したいもののカテゴリーは、他にもないか？ ◼ たとえば、「リソースの操作」パターン ⚫ CRUDテスト: 作成（Create）・参照（Refer）・更新（Update）・削除（Delete）の 4つの操作を網羅する。 - この4つに対し、対象リソースの数が「単一」の場合と「複数」の場合に分けることもある。 ◼ テストモデル ⚫ CRUD図(*1)をモデルとして使えるだろう。 ◼ カバレッジアイテム ⚫ まずは、CRUD各セルにおけるC/R/U/Dの単品網羅。 ⚫ 機能ごとのリソース操作を組み合わせる網羅もありそう。 - 機能Aで作成したリソースを機能Dで削除する、 - 機能Cで作成したリソースを機能Dで削除 (*1) リレーショナルデータベースにおけるデータや、Webアプリケーションにおけるリソースに対する操作を整理した表。 4 ユーザ グループ … 機能A C 機能B C C 機能C U U 機能D R D 機能E R D …
80. 81 / 91 Kazuhiro SUZUKI @ WACATE2024冬 ここで立ち止まって、 「テストモデル」の列を見てみる。
81. 82 / 91 Kazuhiro SUZUKI @ WACATE2024冬 網羅したいもののカテゴリー ◼ テスト設計技法 整理テーブル カテゴリー テスト設計技法 カバレッジ対象 = 網羅したいもの 代表的なモデル 代表的なカバレッジ基準 値のテスト 同値分割法 パラメタの範囲（＝同値パーティショ ン） ベン図など 同値パーティションから最 低1つ値を選択 境界値分析 順序性のある単一パラメタの範囲の境界 数直線など 境界値の周り2値、3値 ドメイン分析テスト 順序性のある複数パラメタの範囲の境界 直交座標など 境界値分析と同様 値の組み合わせ テスト（有則） デシジョンテーブルテスト 論理関係のあるパラメタ同士の組み合わ せ デシジョンテーブル すべての組み合わせ 圧縮した組み合わせ CFD法 原因流れ図 圧縮した組み合わせ 組み合わせテス ト（無則） 直交表 論理関係のないパラメタ同士の組み合わ せ 直交表 n因子網羅 オールペア法 パラメタリストと制約リス ト n因子網羅 クラシフィケーションツ リー法 クラシフィケーションツ リー ー 順序のテスト 状態遷移テスト 順序に制約のあるシステムの遷移順序 状態遷移図 状態遷移表 状態網羅・イベント網羅 遷移網羅、nスイッチ ユースケーステスト 順序の制約のあるユーザの実行順序 ユースケース記述 基本/代替ユースケース リソース操作の テスト CRUDテスト リソース操作のパターン CRUD図 全網羅など
82. 83 / 91 Kazuhiro SUZUKI @ WACATE2024冬 網羅したいもののカテゴリー テストモデルについて、以下のことが言える。 ◼ テストモデルとは、「テストのために作られたモデル」という意味である。 そのモデリング技法がテストにしか使えないという意味ではない。 事実これらのモデリング技法は、どれも設計において利用できる。 ◼ つまりテスト設計技法とは、 ⚫ ソフトウェア開発のモデリング技法をテストに利用し、 ⚫ そこから有用なテストケースを導出する ための技術と言える。 有用というのは、網羅的であったり、必要最低限であったり、バグを見つけやすかったり、 ということ。 裏を返すと、モデリング技法には、 その対となるテスト設計技法がありうるのではないか？ 1 2
83. 84 / 91 Kazuhiro SUZUKI @ WACATE2024冬 問いかけたかったこと: テスト設計技法って、 何かまだいろいろあるんじゃないのか？
84. 85 / 91 まとめ 想定経過時間 84:00
85. 86 / 91 Kazuhiro SUZUKI @ WACATE2024冬 まとめ ◼ 今日お話したこと ⚫ 個々のテスト設計技法を理解したら、次にそれらの関係を考えてみることで、 見えてくることがあるかもしれない。 ないかもしれない。 ⚫ テスト設計には、「モデルの作成」と「カバレッジアイテムの識別」が含まれる。 ここで使用されるモデリング技法はテストの専有物ではなく、 むしろ設計時点で使っていく方が有効だろう。 いわゆる「シフトレフト」にもつながるかもしれない。 ⚫ ふだん技法と意識せず使っているナレッジも、テスト設計技法の一種と考えられる。 知識を散逸させず、ツールボックスに納めていくことが大切。 ⚫ テスト設計技法は「技術としてすべて出そろい、自然に使われている」わけではない。 未発掘の技法や、十分に使われてない技法がある。 テスト設計技法を自分で作り出すこともできるのではないか？
86. 87 / 91 Kazuhiro SUZUKI @ WACATE2024冬 テストの世界は決して完成されていない。 みんなで新しい道を切り開いていくことで、 テストというドメイン全体が強くなる。 そういう世界で仕事していくのが 楽しいと思いませんか！？ （思ってくれ～）
87. 88 / 91 ご清聴ありがとうございました！ Image: Generated by GPT4o
88. 89 / 91 Kazuhiro SUZUKI @ WACATE2024冬 Happy Quality!!
89. 90 / 91 Kazuhiro SUZUKI @ WACATE2024冬 Q & A
90. 91 / 91 Kazuhiro SUZUKI @ WACATE2024冬 参考文献 ◼ 多くの書籍・記事を参照していますが、代表的なもののみでご容赦ください‥。 # コンテンツ名 コンテンツ種別 対象 1 テスト技法の本質 ブログ記事 テスト設計技法全般 2 テスト技術者資格制度 Foundation Level シラバス Version 2023V4.0.J02 PDF資料 テスト設計技法全般 3 テスト技術者資格制度 Advanced Level シラバス日本語版 テストアナ リスト Version 3.1.1.J03 PDF資料 テスト設計技法全般 4 テスト技術者資格制度 Foundation Level シラバス AI テスティング Verison1.0.J01 PDF資料 テスト設計技法全般 5 ISTQB Glossary Webサイト テスト用語全般 6 テスト設計技法ドリル 書籍 テスト設計技法全般 7 テスト設計技法練習帳 書籍 テスト設計技法全般 8 はじめて学ぶソフトウェアのテスト技法 書籍 テスト設計技法全般