はじめてのソフトウェアテスト

勉強会での登壇資料です。

Transcript

1. はじめてのソフトウェアテスト 2023.03.23 @le-blau
2. 自己紹介 • @le-blau • 1年目：EC開発会社でQA ◦ セキュリティ・品質の改善活動 • 2年目〜：現職 ◦ 結婚相談所システムの開発 ◦ 公式サイト・LPの開発 • 趣味：植物🌿 料理🍳 ゲーム🎮
3. 目次 • ソフトウェアテストを学ぶ理由 ◦ ソフトウェアテストとは？ ◦ ソフトウェア7原則 • テスト技法 ◦ 同値分割法・境界値分析 ◦ デシジョンテーブル ◦ ペア構成テスト ◦ 状態遷移テスト • おまけ（時間が余ったら）
4. 目次 • ソフトウェアテストを学ぶ理由　👈 ◦ ソフトウェアテストとは？ ◦ ソフトウェア7原則 • テスト技法 ◦ 同値分割法・境界値分析 ◦ デシジョンテーブル ◦ ペア構成テスト ◦ 状態遷移テスト • おまけ（時間が余ったら）
5. ソフトウェアテストとは？ ある特定の条件下において、 「期待する結果」と「実際どうなったか」を 比較検証していくプロセスである
6. ソフトウェアテストとは？（噛み砕くと） 開発者が意図したとおりにプログラムが動いているか？ を テストケースを用いて検証し、不具合（バグ）を見つけ出すプロセスのこと。 その結果、品質の高いソフトウェアを開発することが目的
7. テストの7原則 1. テストは欠陥があることは示せるが、欠陥がないことは示せない 2. 全数テストは不可能 3. 早期テストで時間とコストを節約 4. 欠陥の偏在 5. 殺虫剤のパラドックスにご用心 6. テストは状況次第 7. 「バグゼロ」の落とし穴 引用元：テスト技術者資格制度 Foundation Level シラバス 日本語版
8. 完璧なテストはできない 「完璧なテストはできない」という前提を受け入れ、 少しでも多くのバグを見つけるという姿勢でテストに望むのが大事 　
9. 完璧なテストはできない とはいえ、闇雲にテストケースを増やしても効果的ではない 　↓ ソフトウェアのテスト技法を学んで、 「なるべく少ないテストケースで、多くの欠陥を検出する」
10. マイヤーズの三角形問題 以下のプログラムをテストするのに十分と思われる一連のテストケース（すなわち、十分なデータのセット） を書き記してみよ。 • このプログラムでは、ユーザーが3個の整数を入力する • この3つの値は、それぞれ三角形の3辺の長さをあらわすものとする • プログラムは、三角形が「正三角形」「二等辺三角形」「不等辺三角形」のうちどれであるかを決める メッセージを出力する https://www.qbook.jp/academy/curriculum/0001/lessons/ad00001/
11. 解答例 正常系 • 有効な正三角形 • 　〃　不等辺三角形 • 　〃　二等辺三角形 • 　〃　二等辺三角形で、 3種類の辺の組み合 わせをテスト ◦ [A=B], [B=C], [C=A] 異常系 • 長さが 0 の辺があるケース ◦ [A=0], [B=0], [C=0], [AとB=0], … • 長さが負の値の辺があるケース ◦ [A=-2, B=2, C=5], [A=-2, B=-3, C=5], … • 2辺の和がもう1辺と同じ • 2辺の和がもう1辺より小さい・大きい • 3辺が 0 のケース • 入力の個数が間違っている • 入力値に対して表示結果があっている 　　　　　　　　　　　　　　　　　など
12. ここから学べること 1. テストケースは、仕様から単純に抽出できるものではない 2. シンプルな仕様のテストがシンプルとは限らない 3. テストすべき観点やケースの唯一解はない
13. 目次 • ソフトウェアテストを学ぶ理由 ◦ ソフトウェアテストとは？ ◦ ソフトウェア7原則 • テスト技法　👈 ◦ 同値分割法・境界値分析 ◦ デシジョンテーブル ◦ ペア構成テスト ◦ 状態遷移テスト • おまけ（時間が余ったら）
14. 同値クラス・境界値テスト 以下のようなコードがあったとき、必要なテストケースは？ if (age <= 12) { 子供料金 } else if ( age <= 60 ){ 大人料金 } else { シニア料金 } ケースA→　age=0、age=1、age=2 ケースB→　age=3、age=40、age=63 ケースAは、子供料金しかテストしていない ケースBは、全ての結果をテストできてる 結果が同じになる条件の範囲を「同値クラス」という
15. 同値クラス・境界値テスト if (age <= 12) { 子供料金 } ↑のように書きたかったのに、不等号を間違えてしまったケース if (age < 12) { 子供料金 } →境界値にはバグが潜みやすい これをカバーするためには同値クラスの境界とその前後の値を調べれば良い このような考え方を「境界値テスト」という
16. デシジョンテーブル 複数の条件の組み合わせを表にし、その条件に対するアクションを記したもの 例：ECサイトで新規会員のみ、対象商品が10%割引になるセール 「条件」と「アクション」を書き、条件の組み合わせを列に記載していく そして、できた列（1〜8）がテストケースになる 1 2 3 4 5 6 7 8 条件 新規会員 Y Y Y N Y N N N 対象商品 Y Y N Y N Y N N 併用クーポンなし Y N Y Y N N Y N アクション 10%割引 Y N N N N N N N 表：10%割引判定
17. 「条件」が増えたら...？ 今回は2値条件(Yes/No)が3つあるので、8通り(2^3)の組み合わせができた しかし、「条件」が増えた場合、指数関数的にテストケースが増えてしまう 1 2 3 4 5 6 7 8 条件 新規会員 Y Y Y N Y N N N 対象商品 Y Y N Y N Y N N 併用クーポンなし Y N Y Y N N Y N アクション 10%割引 Y N N N N N N N
18. デシジョンテーブルの圧縮 デシジョンテーブルは、網羅性を維持しつつ圧縮することができる 例えば、 「新規会員？　→　対象商品？　→　併用クーポンある？」という順番で判定が行われ、 どれか一つでもNoが出れば、以降の判定は行わない処理になっている場合は、このように圧縮できる 1 2 3 4 条件 新規会員 Y Y Y N 対象商品 Y Y N - 併用クーポンなし Y N - - アクション 10%割引 Y N N N
19. もっと条件が増えたら...？ テストの条件が増えると、条件の組み合わせは膨大になる →全てを網羅するのは現実的に不可能になってくる 全ての条件を網羅することは諦めて、少ないテストケースである程度網羅的に、かつ重要な処理やバグ が潜んでいそうな箇所は重点的にテストしていく そのための方法がペア構成テスト
20. ペア構成テスト すべての条件のすべての組み合わせをテストするのではなく、 条件の全てのペアをテストする方法 なぜペアをテストすれば良いか？ 「ほとんどの不具合は、シングルモード欠陥とダブルモード欠陥によって引き起こされている」という経験則 に基づいている シングルモード欠陥：1つのモジュールが正しく動かない ダブルモード欠陥：2つのモジュールが組み合わさったときに正しく動かない
21. 直交表 全てのペアを網羅する方法のひとつ 例：2値条件が3つ（A, B, C）の場合の直交表 AとB、BとC、CとAに注目すると、 (0, 0) (0, 1) (1, 0) (1, 1) という全てのペアが現れている A B C 1 0 0 0 2 0 1 1 3 1 0 1 4 1 1 0 ここがペア
22. 直交表 条件をさらに増やしてみる 例：3値条件が4つ（A, B, C, D） 全網羅のテストケース数：3^4 = 81通り 直交表のテストケース数：9通り このように、直交表を使えばすべてのペアを 少ないテストケースで網羅できる A B C D 1 0 0 0 0 2 0 1 1 1 3 0 2 2 2 4 1 0 1 2 5 1 1 2 0 6 1 2 0 1 7 2 0 2 1 8 2 1 0 2 9 2 2 1 0
23. 直交表 直交表は自分でつくるものではない 以下のようなサイトから、直交表のカタログを参照する タグチ計画のカタログ A Library of Orthogonal Arrays
24. 直交表を実際に使ってみる 条件例 • ブラウザ（Chrome, Firefox） • OS（Windows, MacOS, Linux） • サーバー（Apache, IIS, WebLogic） • データベース（MySQL, PostgreSQL, SQL Server） これを直交表に当てはめるには、2値条件が1つ、3値条件が3つの直交表を選べば良い 直交表の表記で表すと「L?(2^1 3^3)」となるので、これにマッチする直交表を選ぶ
25. 直交表を実際に使ってみる 直交表のサイトにアクセスして、「L?(2^1 3^3)」 の直交表を探す ぴったりの直交表がなければ、少し大きいものを選ぶ 一番近い「L9(3^4)」を選択する
26. 直交表を実際に使ってみる L9(3^4)の直交表 空欄ができた場合は、任意の値で埋める（今回だとブラウザの3） 任意の値で埋めたとしても、すでにペアは登場しているので問題ない 
 1
 2
 3
 4
 1
 1
 1
 1
 1
 2
 1
 2
 2
 2
 3
 1
 3
 3
 3
 4
 2
 1
 2
 3
 5
 2
 2
 3
 1
 6
 2
 3
 1
 2
 7
 3
 1
 3
 2
 8
 3
 2
 1
 3
 9
 3
 3
 2
 1
 
 ブラウザ
 OS
 サーバー
 データベース 
 1
 Chrome
 Win
 Apache
 MySQL
 2
 Chrome
 Mac
 IIS
 PostgreSQL 
 3
 Chrome
 Linux
 WebLogic
 SQL Server 
 4
 Firefox
 Win
 IIS
 SQL Server 
 5
 Firefox
 Mac
 WebLogic
 MySQL
 6
 Firefox
 Linux
 Apache
 PostgreSQL 
 7
 3
 Win
 WebLogic
 PostgreSQL 
 8
 3
 Mac
 Apache
 SQL Server 
 9
 3
 Linux
 IIS
 MySQL
 条件を当てはめる ・ブラウザ（Chrome, Firefox） ・OS（Windows, MacOS, Linux） ・サーバー（ Apache, IIS, WebLogic） ・データベース （MySQL, PostgreSQL, SQL Server）
27. 直交表を実際に使ってみる 最終的に行がテストケースになり、すべてのペアをテストすることができる 今回は9つのケースをテストすれば良い 
 ブラウザ
 OS
 サーバー
 データベース 
 1
 Chrome
 Win
 Apache
 MySQL
 2
 Chrome
 Mac
 IIS
 PostgreSQL 
 3
 Chrome
 Linux
 WebLogic
 SQL Server 
 4
 Firefox
 Win
 IIS
 SQL Server 
 5
 Firefox
 Mac
 WebLogic
 MySQL
 6
 Firefox
 Linux
 Apache
 PostgreSQL 
 7
 Chrome
 Win
 WebLogic
 PostgreSQL 
 8
 Chrome
 Mac
 Apache
 SQL Server 
 9
 Firefox
 Linux
 IIS
 MySQL

28. ペア構成テストのポイント • 組み合わせの数が膨大になる場合に有効 • ペア構成テストは100%の網羅性は得られない ◦ 2因子間網羅（70〜97%） ◦ 3因子間網羅（89〜99%） • 重要な組み合わせや、バグが起きそうな組み合わせは、テストケースを足す必要がある
29. 状態遷移テスト 現在の状態と何らかのイベントによって振る舞いが変わるような処理をテストする方法 状態遷移図 - システムの振る舞いをグラフ化し、直感的に表現したもの 状態遷移表 - システムの振る舞いを表に起こしたもので、状態とイベントの組み合わせを網羅的に表現で きる
30. ストップウォッチの例 ストップウォッチの仕様 • ストップウォッチには「スタート」「 ストップ」「 リセット」の3つのボタンがある • 「スタート」ボタンを押下すると計測を開始する • 「ストップ」ボタンを押下すると計測を一時停止し、計測結果時間を表示する • 結果表示中に「スタート」ボタンを押下すると、計測を再開する • 結果表示中に「リセット」ボタンを押下すると、計測結果時間をリセットする
31. 状態遷移図 ストップウォッチを状態遷移図で書くと... 状態遷移図は状態を◦、遷移を矢印、イベントを矢印のラベルで表す 文章の仕様を見るより、遷移状態をより直感的に確認することができる →しかし実際どんなテストケースを用意すればよいかは分からない 待機中 計測中 一時 停止中 スタート ストップ スタート リセット
32. 状態遷移表 直感的には状態遷移図が分かりやすかったが、 テストケースを考える際は状態遷移表を使う方が分かりやすい 状態遷移図では表現されなかった「遷移しない」ケースが明らかになる スタート ストップ リセット 待機中 計測中 - - 計測中 - 一時停止中 - 一時停止中 計測中 - 待機中 イベント 遷 移 前 の 状 態 遷移後の状態
33. 状態遷移表と状態遷移図の使い分け 状態遷移図は「遷移できること」にフォーカスして可視化する 状態遷移表は「遷移できないこと」も網羅的に可視化する 仕様書には「できないこと」はあいまいであったり、記載されないことが少なくない 状態遷移表を作成することで、テストケース洗い出しと仕様の抜け漏れもチェックできる
34. 最後に テストの目的を忘れない あくまでもソフトウェアテストは、ソフトウェアの品質を向上させることが目的であり、それを支える手段とし てテスト技法があります。 テスト技法を実際に使ってみる 今日学んだテスト技法を、実際の開発で実践していただけたら嬉しいです。
35. おまけ ベストな直交表を探すのが面倒くさい！ 　→「ペアワイズ法」という方法があります あまりテスト時間を確保できない！ 　→探索的テスト（次のスライド）がおすすめです テストの勉強をしてみたいけど、どの本がおすすめ？ 　→ソフトウェアテスト読書マップ（次の次のスライド）に、目的・レベル別に書籍がまとめられています
36. 探索的テスト 事前にテストケースを作成するのではなく、ソフトウェアを操作して、振る舞いを確認しながら柔軟にテスト を行っていく方法。 メリット • スピードが早い（アジャイルと相性がいい） • テストケースとして用意しにくい部分のテストができ、検出困難なバグを見つけやすい • 設計書がなくてもテストができる デメリット • テストする人の経験・スキルへの依存度が高い • 網羅性の担保はできない • テストの管理・コントロールが難しい
37. ソフトウェアテスト読書マップ https://docs.google.com/spreadsheets/u/1/d/1IK6LFFy-SJck1Pnmrka3_OfdjAkUgPbccGMiwBsOOOw/edit#gid=0 https://speakerdeck.com/kzsuzuki/software-testing-reading-map-for-developers?slide=22