ソフトウェアテストのキーワード

本編

第1章 ソフトウェアテストとは

ソフトウェアテストとは，欠陥を取り除いて，ユーザの要求を満たす，品質の良いソフトウェアを作ること．
欠陥とは，誤動作の原因がソフトウェアにあると特定されたものを指す．
不具合とは，原因の特定される前のものを指す．
品質はISO/IEC 9126で定義されている．機能性・信頼性・使用性・効率性・保守性・移植性がある．
品質意識を高めるために，「検証と妥当性確認 V&V」と「品質とユーザ満足度の関係」を意識する．
欠陥には検証で見つかる欠陥と妥当性確認で見つかる欠陥がある．
ユーザの満足度を考えるために，狩野モデルがある．狩野モデルには「当たり前品質」と「一元的品質」と「魅力的品質」がある．

第2章 ソフトウェア開発の流れとテスト工程

ウォーターフォール型開発では，テスト工程を含めるとV字モデルになる．「単体テスト」「機能テスト」「結合テスト」「システムテスト」がある．

単体テストは詳細設計通りに動くかテストする．

結合テストは複数のモジュールを組み合わせてテストする．

機能テストは組み合わせたモジュールを1つの機能としてテストする．

システムテストは要求定義の内容を実現しているかテストする．

開発者とテスト担当者が開発からテストまで関与するW字モデルがある．

ソフトウェアの内部構造に着目するorしないという観点で，ホワイトボックステストとブラックボックステストがある．

ソフトウェアを動作させるorさせないで，静的テストと動的テストがある．

開発工程ではレビューが行われ，テスト工程ではテストが行われる．

開発工程で行うテストとして，「インスペクション」「テクニカルレビュー」「非公式レビュー」「ウォークスルー」「机上デバッグ」がある．

単体テストとして，「機能確認テスト」「制御フローテスト」「データフローテスト」がある．

結合テスト・機能テストとして，「状態遷移テスト」「機能確認テスト」がある．

システムテストとして，「確認テスト」「評価テスト」「負荷テスト」「環境テスト」「機能確認テスト」「アドホックテスト」「探索型テスト」「リスクベースドテスト」がある．

ユーザによるテストとして，「受け入れテスト」「運用テスト」「アルファテスト」「ベータテスト」がある．

第3章 ホワイトボックステスト

単体テストの話．

命令文の処理順序を確認する「制御フローテスト」，データの流れを確認する「データフローテスト」

制御フローテストでは，以下の5つの手順を踏む．

1. ソースコードをもとにフローチャートを書く
2. ガバレッジ基準（網羅したい基準）を決める
3. ガバレッジ基準を網羅する経路を抽出する
4. 抽出した経路を通るようにテストを行う
5. 結果を確かめる

制御フローテストで着目する要素を「命令文 : ステートメントガバレッジ」「分岐した経路 : デシジョンガバレッジ」「条件 : 複合条件ガバレッジ」から選ぶ．これらの要素のことを「ガバレッジ基準」という．

複合条件ガバレッジが100%になるようになるべくテストする．

データフローテストでは，データや変数が「定義」「使用」「消滅」の順に正しく処理されているか確認するテスト．

第4章 ブラックボックステスト

機能テストやシステムテストの話．

テストフェーズには「テスト計画」「テスト設計」「テストケース作成」「テスト実施」「テスト報告」がある．

1. テスト全体計画書を見て，テストの目的を確認する．また，テストの範囲や内容・方法を決定する．
2. すべての機能の洗い出しを行う．テストするしないは考えない．
3. テスト観点（テストの切り口）の抽出を行う．テスト目的に沿ったものでないとダメ．テストの目的を品質特性に変換し，品質特性に対応したテスト観点を抽出するという方法がある．
4. 洗い出した機能のひとつひとつにおいて，どのテスト観点のテストを行うべきか検討する．機能観点一覧表を作成すると良い．
5. 機能とテスト観点の組み合わせが決まったら，ひとつひとつの組み合わせに対して，テスト設計を進める．

テスト観点は，テストの方向性が明らかになるような具体的な指示である．他者との共通認識を持つことができる．

テスト観点一覧表を使用すれば，これまでのテストノウハウを利用できる．

テスト観点一覧表を作成する場合，最初にいくつかの段階に分類し，大きな観点から小さな観点へと分類を進めていくと良い．

以下の指標を分類基準としても良い．

• IOS/IEC 9126の6つの品質特性 : 機能性，効率性，信頼性，保守性，使用性，移植性
• Ostrandの4つのビュー : ユーザビュー，設計・実装ビュー，仕様ビュー，バグビュー
• Myersの14のシステムテスト・カテゴリ : ボリューム，設置，ストレス，回復，効率，操作性，ストレージ，セキュリティ，信頼性，サービス性，構成，文書，互換性，手続き

今回は，大分類に「機能」「非機能」「ユーザ」「テスト」とし，「機能」の中分類に「正常系」「異常系」「組合せ」を設ける．
「正常系」は，基本機能，表示，遷移，UI，設定，セキュリティ
「異常系」は，異常値入力，記憶装置異常，エラー検知，異常状態，エラー復旧，異常環境，異常データ，異常操作
「組合せ」は，同時動作，構成，割り込み動作，相互運用性，排他処理，付属品，互換性
「非機能」は，処理速度，連続動作，負荷，通信帯域不足，大容量，リソース不足
「ユーザ」は，出力品質，業務シナリオ，ユーザビリティ，導入・保守，魅力性
「テスト」は，修正テスト，回帰テスト，過去欠陥，テスタビリティ

第5章 同値クラステスト・境界値テスト

同値クラステスト・境界値テストは「ソフトウェアの動作が変わる条件の境目」に注目するテスト技法．

同値クラステストは同値クラス（同じ動作をする条件の集めり）ごとにテストを行う．代表値でテストをした結果，欠陥が見つかれば，同値クラスの他の値でも同じ欠陥が見つかるだろう．欠陥が見つからなければ，同値クラス内の他の値でも同じ欠陥は見つからないだろう，という考え．

同値クラステストを行う時に，プログラムの内部構造について注意する必要がある．同値クラスと内部構造が一致しているとは限らないため．

境界値テストは仕様条件の境界となる値とその隣の値に対してテストを行う．欠陥は境界に潜む可能性が高いため．開発時の仕様変更によって，隠された境界値が生まれる可能性がある．内部構造を見れば隠された境界値が分かる可能性がある．

第6章 デシジョンテーブルテスト

デシジョンテーブルとは，「複数の条件によって決定されるソフトウェアの動作を一覧するための表」である．
デシジョンテーブルを作成することで，複数条件に着目してテストを行える．

表の上半分は「条件 : Y/Nの二値」と下半分「アクション : 結果，処理，動作」を記述する．条件を埋めながら，疑問や気づきがあれば，調べたり尋ねたりすること．完全なデシジョンテーブルを作ることを心掛ける．

デシジョンテーブルを見やすくするために，矛盾した条件を削除したり，表を簡略化したり，表を分割することができる．表を分割したときに，アクション欄に「○○デシジョンテーブルを使用」と書いておけばよい．

デシジョンテーブルが3値以上の場合，Y/Nの二値ではなく，3値の条件で記入しても良い．

デシジョンテーブルのルール数以上にテストして良い．

デシジョンテーブルは「発見した結果の原因分析」と「静的テスト」に利用できる．

第7章 状態遷移テスト

状態遷移図や状態遷移表を使ったテストのこと．

ある状態が別の状態へ変化することを「状態遷移」と呼び，状態遷移のきっかけとなる操作や条件のことを「イベント」と呼ぶ．

状態には「部位の状態」「処理の状態」「モードの状態」の3つがある．

状態遷移図のメリットは「状態遷移の流れを容易に把握できる」ことと「図示することによって新たな発見がある」ことである．

状態遷移表のメリットは「使用が曖昧な箇所に潜む欠陥を発見できる」ことと「状態遷移図の不備を見つけることができる」ことである．

状態遷移図は機能ごと分割すると良い．

状態遷移図をもとにテストケースを作成するばあい，「すべての状態は1回は通る」「すべてのイベントを1回は発生させる」「すべての遷移を1回は通る」ことに注意する．機能単位のソフトウェアができたら「すべての状態は1回は通る」テストを行う．機能間でのデータの受け渡しや割り込み処理といった，イベントに関わる機能が完成したらすべてのイベントを1回は発生させる」テストを行う．システム全体が出来上がったら「すべて遷移を1回は通る」テストを行うとすると良い．

ユーザのシナリオに沿ったテストも行うこと．

状態遷移表を用いることで，できることに加え，できないことのテスト計画も立てられるようになる．

状態遷移表には「状態×状態」型と「状態×イベント」型がある．「状態×イベント」型は抜け漏れを防ぎやすいが表が大きくなりやすい．

どこにも遷移しないイベントと起こりえないイベントは区別すること．

状態遷移表も機能ごとに作成すると良い．

第8章 組み合わせテスト

複数条件を組み合わせてソフトウェアの動作を確認するテスト．

組み合わせテストをする前に，十分に単一テストを行うこと．

組み合わせは膨大になるため，2因子間網羅を行うとほとんどの欠陥を発見できる．

All-Pairs法を使って，2因子間網羅を行うことができる．PICT master : https://sourceforge.net/projects/pictmaster/

直行表を使って，2因子間網羅を行うことができる．直行表テンプレートを使って，組み合わせを手動で作成する．

All-Pairs法は組み合わせ数が少ないが3因子間の欠陥を見つけにくい，直行表は組み合わせ数が多いが，3因子間の欠陥を見つけやすい，という特徴がある．

不要な因子を取り除いたり，組み合わせてはいけない「禁則事項 : 禁止になっている組み合わせや不可能な組み合わせ」を回避したり，「3因子間以上をまたぐ重要な組み合わせ」を追加したりする．

第9章 テスト技法適用チャート

仕様書レビュー段階

1. 処理内容の抜け漏れを確認したい : デシジョンテーブル・状態遷移図・状態遷移表
2. 状態遷移に関する抜け漏れを確認したい : 状態遷移図・状態遷移表
3. 条件と処理の関連を整理したい : デシジョンテーブル・状態遷移図・状態遷移表
4. 画面や処理の遷移が分かりにくい : 状態遷移図
5. 無効な動作・動作を可視化したい : 同値クラス分割．状態遷移表
6. 仕様を視覚的に把握したい : デシジョンテーブル・状態遷移図・状態遷移表
7. 入力値の範囲を確認したい : 同値クラス分割

テスト設計段階

1. 入力値の範囲を整理したい : 同値クラス分割
2. 入力値を効率的に選択したい : 同値クラス分割・境界値分析・組み合わせ技法
3. テスト項目を削減したい : 同値クラス分割・境界値分析・組み合わせ技法
4. テストの入力値を削減したい : 同値クラス分割
5. すべての条件とアクションを網羅したい : デシジョンテーブル
6. 欠陥のありそうなところを重点的に確認したい : 境界値分析
7. 入力値の範囲が曖昧 : 同値クラス分割・境界値分析・デシジョンテーブル
8. テスト対象の項目が多く工数が不足する : 組み合わせ技法
9. テストに有効な状態，イベント，遷移を抽出したい : 状態遷移図・状態遷移表
10. 複数機能が関係する欠陥を効率的に発見したい : デシジョンテーブル・組み合わせ技法
11. さまざまな機能の同時動作・競合させたい : 状態遷移表・組み合わせ技法

テスト実施段階

1. 回帰テストの確認項目を最低限に抑えたい : 組み合わせ技法

回帰テストとは，欠陥修正後に欠陥以外の部分に修正の影響がないか確認したり，ソフトウェアのリリース前にもう一度全体的に動作させたりすること．

第10章 テストドキュメントの作成

各テストフェースで「テスト計画書」「テスト使用設計書」「不具合報告書」「テストサマリレポート」などの各種書類を作成・提出する．

「テスト工程間で品質が劣化することを防ぐため」と「テスト対象のソフトウェアの品質状況を可視化するため」である．

テスト全体計画書には，全テスト工程の計画を記述する．
個別テスト計画書には，個別のテスト工程の計画を記述する．
テスト設計仕様書には，機能ごと，あるいは確認したいテストの目的ごとに作成する．
テストケースには，具体的な入力値を記述する．
テストログには，テスト実施結果を記述する．テストケースとは別に保存する．
不具合報告書には，テストの過程で検出された不具合を記載する．
進捗管理表には，現在どのフェーズにいるのか管理するため記載する．
テストサマリレポートには，テスト結果を要約したものを記述する．

IEEE 829-2008でテストドキュメントについて標準化されている．

テスト設計仕様書には，追跡性・関連性を注意し，各ドキュメントに識別番号を付け，関連性のあるドキュメントの情報を記載する．なぜその定義にしたのかきちんと理由を書くこと．記述の粒度には気を付ける．テストの規模を書くことで目安をつけられる．

テスト設計仕様書には，追跡性・関連性を注意し，各テストケースに識別番号を付け，関連性のあるドキュメントの情報を記載する．テスト実施のしやすさに気を付ける．記述の粒度には気を付ける．

第12章 テスト実施のモニタリング

これまでの文章からグラフを作成し，テスト実施状況のモニタリングを行う．

「信頼度成長曲線」「解決済み不具合累積数の推移グラフ」「実施済みテストケース累積数の推移グラフ」「不具合が解決されるまでの平均日数の推移グラフ」などがある．

• 信頼度成長曲線 : 横軸，時間 縦軸，不具合報告数
• 解決済み不具合累積数の推移グラフ : 横軸，時間 縦軸，不具合報告数 解決済み不具合累積数
• 実施済みテストケース累積数の推移グラフ : 横軸，時間 縦軸，実施済みテストケース累積数
• 不具合が解決されるまでの平均日数の推移グラフ : 横軸，時間 縦軸，不具合が解決されるまでの平均日数

不具合報告書の項目による分類では「重大度別」「原因別」「現象別」がある．
ソフトウェアの作り方による分類では「ユーザの要求事項別」「サブシステム別・機能別」「ソフトウェアの処理分類別」「データ項目別」がある．
テストの方法による分類では「テスト工程別」「テストの種類別」「テスト観点別」がある．
他にもカバレッジや密度・割合・発見率・効率を求めても良い．

感想

実際に手を動かしながらやってみたい．
テスト技法だけでなく，ドキュメントもきちんと作成しましょう．