本要約)はじめて学ぶソフトウェアのテスト技法

https://www.nikkeibp.co.jp/atclpubmkt/book/05/P82510/
初版: 2005年11月7 (13刷: 2020年6月30)

テストのプロセス

■テストとは何か

• 本書の定義

  「実際どうなっているか」と「本来はどうあるべきか」を比較するプロセス
  

• IEEE標準規格の定義

  ある特定の条件下でシステムまたはコンポーネントを操作するプロセスであり、
  その結果を観察または記録して、システムまたはコンポーネントのある側面を評価すること
  

  → この定義における「ある特定の条件」を具体化したものがテストケース
• 「体系的ソフトウェアテスト入門」の(拡張した)定義

  テストとは、テストされるソフトウェアの品質を測定して改善するために、
  テストウェアをエンジニアリングし、利用し、保守しながら、
  同時並行的に進めるライフサイクルプロセスである
  

■テストレベル

単体テスト

• 単体: 開発者が作成する最小部品のこと
  • 通常、1人のプログラマの作業成果であり、1このファイルとして保管される
  • ex)C言語の単体 → 関数

統合テスト

• 単体を結合した時に現れる欠陥を見つける

システムテスト

• システムコンポーネント: 顧客に届けられるすべてのソフトウェアから構成される
  • ハードウェア、マニュアル、トレーニング教材なども含まれる(こともある)
• 最も高いレベルの統合時に起こる欠陥に焦点を絞る
  • 主には機能性のテストだが以下の様な観点も必要となる場合もある
    • ユーザビリティ
    • セキュリティ
    • パフォーマンス
    • 信頼性
    • 可用性
    • その他もろもろ

受入れテスト

• 顧客がソフトウェアを受け入れて、代金を支払うテスト
• 受入れテスト前に考えておきたいこと
  • 受入れテストのレベルを決めるのは誰か
  • テストスクリプトを書くのは誰か
  • テストを実行するのは誰か
  • 受入れテストの合否の基準は何か
  • 誰がどの様に支払いをするのか

その他テストレベル

• コード品質
• 機能性
• ユーザビリティ
• パフォーマンス
• セキュリティ

ブラックボックステストとホワイトボックステスト

※パス → 命令(処理)を指す

■ブラックボックステスト

定義

• 要件と仕様書だけをよりどころにしたテスト戦略
  • ソフトウェアの内部パスや構造に関する知識を必要としない
• 手順
  • 要件や仕様書を分析
  • 仕様書をもとに有効な入力値を選択
    • 正しい値
    • 無効な値
  • 入力値に対して期待する出力を決定
  • 選択した入力値を使ったテストケースを作成
  • テストを実行
  • 実際の出力と期待する出力を比較
  • 正常に機能しているかを判定

適応対象

• すべてのテストレベル(単体・統合・システム・受入れ)

難点

• ソフトウェア内部のどれだけの部分をテストできたか、テスト担当者が知る方法がない
• 欠陥を全て見つけ出そうとすると、可能な入力値のすべての組み合わせを実施する必要がある
• 実行されないパスが残ってしまう
  • 不正な機能が残ってしまう可能性がある

利点

• 有効で効率の高いテストケースを選択できる
  • 無作為に作られたテストケースよりも多くの欠陥を発見することが出来る

■ホワイトボックステスト

定義

• ソフトウェアの内部パス・構造・実装に関する知識をよりどころにしたテスト戦略
  • プログラミングのスキルが必要
• 手順
  • ソフトウェアの実装を分析
  • ソフトウェアのパスを識別
  • ソフトウェアの特定のパスを実行する入力を求める
  • テストを実行
  • 実際の出力結果と期待する出力値を比較
  • 正常に機能しているかを判定

適応対象

• すべてのテストレベル(単体・統合・システム・受入れ)

難点

• テストケースがすべてテストできないくらい多くなる
• テストケースの選択によっては、値に依存する欠陥を発見できない
• 存在しないパス(実行されないパス)を発見できない
• プログラミングスキルが必要

利点

• 全パスを識別してテストしたこととなる

■グレーボックステスト

• どの様に実装されているかわかる程度まで調べる
• ブラックボックステストのテストケースをより効果的にするために利用する

ブラックボックステスト技法

※有効で効率的なテストケースを選定して数を減らすための技法たち
※テストケースを増やすと安心して気持ちよくなるかもしれないが、それで欠陥が見つかることはあまりない

■同値クラステスト

同値クラスとは？

• どの値を選んでも有効な値の範囲のこと
  • 同一範囲の値は、「同じ値」と見なす
  • ex)
    • 成人の同値クラス → 20以上　※有効値という。反対は無効値。

解説

• 同値クラスを判別し、それぞれの同値クラスに対してテストケースを1つ作る
• 無効値のテストケースを作る
  • 値0~30があり、有効値が10~20の場合は、無効値は0~9 と 21~30 の2ケースとなる

■境界値テスト

解説

• 境界毎に3つの値をテストケースとする
  • 境界上の値
  • 境界値のすぐ下の値
  • 境界値のすぐ上の値
• ex)有効値が 10~20 の場合
  • 境界値=10 のテストケース → 9,10,11
  • 境界値=20 のテストケース → 19,20,21

■デシジョンテーブルテスト

解説

• システム要求を把握して内部システム設計の文書化するためのツール
  • テストケースを作成するだけのためのツールではない
• 条件の集合に基づいてルールを表現する

	ルール1	ルール2
条件
条件１	YES	NO
条件2	YES	NO
アクション
アクション１	Aをする	Bをする
アクション2	Xをする	Yをする

■ペア構成テスト

※これ理解するのに時間がかかるので概要だけにする。必要な時は専用アプリ使ってテストケースを作成する

解説

• すべての組み合わせをテストしようとすると膨大の数になるテストケースを大幅に削減してくれる
• 「直交表」と「全ペアアルゴリズム」という技法を使ってすべてのペアを見つけ出す

■状態遷移テスト

用語

• 状態
  • システムが1つまたは複数のイベントを待っている状況
  • ex) なし・申請中・承認済み・完了 など
• 遷移
  • イベントによってある状態から別の状態へと変わること
  • ex) なし → 申請中 → 商人済み → 完了 みたいなイメージ
• イベント
  • システムの状態を変更させる何か
  • ex) 申請書登録(なし → 申請中) なイメージ

解説

• 状態遷移図や状態遷移表を利用してテストケースを作成する
• カバレッジレベルが定義できる
  1. すべての状態を少なくても1回訪れる1組のテストケース
  2. すべてのイベントが少なくとも1回は起動される1組のテストケース
  3. テスト対象の全てのパスが少なくとも1回実行される1組のテストケース
  4. すべての遷移をすくなくとも1回はテストする1組のテストケース

■ドメイン分析テスト

複数の変数を同時にテストする技法
理解できなかった

■ユースケーステスト

用語

• ユースケース
  • アクターがある特定の目的を達成するためにシステムをどう使うかを示すシナリオのこと

特徴

• ユースケース図を使うのが一般的
• 技術的な視点ではなくユーザーの視点から機能要件を把握できる
• システムテストと受け入れテストのテストケースを開発するための基盤として役立つ
• どれだけ行っても、入力値の組み合わせのほとんどは未テストのまま

ホワイトボックステスト技法

■制御フローテスト

用語

• カバレッジ
  • 実際にテストされたコードの割合(網羅率)
• カバレッジレベル
  • テストされた コードの定義/観点

制御フローテストとは？

• コードの実行パスを認識し、パスの網羅性を検証する
• カバレッジレベルは 0~7 があり、レベルが上がるほど網羅率が上がる
  • どのカバレッジレベルが適切であるか決める必要がある
  • カバレッジ100%を目標とする事は本質ではない。
    • この様な目標を掲げてる場合は、低レベルなカバレッジレベルが設定されているので、テストとしての価値を疑う必要がある

カバレッジレベル

レベル0

• 呼称
  • なし
• 概要
  • テストできるところまでテストをし、あとはユーザーにテストしてもらう

レベル1

• 呼称
  • ステートメントカバレッジ
  • 命令網羅
  • C0
• 概要
  • ステートメント(命令)を1回でも実行する
• 関心事
  • 実行される行

/*
 * ケース1: a = 1, b = 0
 */
if (a > 0) {
    x = 0;
}
if (b === 0) {
    y = 0;
}

レベル2

• 呼称
  • デシジョンカバレッジ(ブランチカバレッジ)
  • 分岐網羅
  • C1
• 概要
  • 条件判定に対して1回ずつ評価する
• 関心事
  • 実行されるパス(条件が一致した時のパスでか、一致しない時のパスか)

/*
 * ケース1: a = 1, b = 0
 * ケース2: a = 0, b = 1
 */
if (a > 0) {
    x = 0;
}
if (b === 0) {
    y = 0;
}

レベル3

• 呼称
  • コンディションカバレッジ
  • 条件網羅
  • C2
• 概要
  • 全ての条件が真と偽の判定結果となる評価をする
• 関心事
  • それぞれの条件が真と偽の評価されたか

/*
 * ケース1: a = 1, b = 0
 * ケース2: a = 0, b = 1
 */
if (a > 0) {
    x = 0;
}
if (b === 0) {
    y = 0;
}

レベル4

• 呼称
  • 100%デシジョン/コンディションカバレッジ
• 概要
  • 条件網羅に分岐網羅を加えた評価をする
• 関心事
  • 条件と実行パス

/*
 * ケース1: a = 1(真), b = 1(真) ※デシジョンカバレッジ観点
 * ケース2: a = 1(真), b = 2(偽) ※コンディションカバレッジ観点
 * ケース3: a = 0(偽), b = 1(真) ※コンディションカバレッジ観点
 */
if (a > 0 && b === 1) {
    x = 0;
}

レベル5

• 呼称
  • 複合コンディションカバレッジ
  • 複合条件網羅
  • MCC
• 概要
  • デシジョンカバレッジとコンディションカバレッジを実現する
• 関心事
  • 条件パターンと実行パス

/*
 * ケース1: a = 1, b = 1, c = 3, d = -1 ※全て「真」
 * ケース2: a = 0, b = 0, c = 0, d = 0 ※全て「偽」
 * ケース3: a = 1(真), b = 0(偽), c = 3(真), d = 0(偽)
 * ケース4: a = 0(偽), b = 1(真), c = 0(偽), d = -1(真)
 */
if (a > 0 && b === 1) {
    x = 0;
}
if (c === 3 || d < 0) {
    y = 0;
}

レベル6

• 呼称
  • なし
• 概要
  • 100%パスカバレッジのループ回数を制限した版

レベル7

• 呼称
  • 100%パスカバレッジ
  • 経路網羅
• 概要
  • 全てのパターンを評価する
    • レベル5以下はパス単独での評価基準だったが、レベル6からはコードの特定範囲(クラスや関数)に対する評価とする
    • ループ処理があるとパスの数は膨大となる
• 関心事
  • パス全体

■データフローテスト

データフローテストとは？

• 変数にはライフサイクル(生成・使用・消滅)があり、ライフサイクルに異常が存在するかを検査する
  • 静的コード解析で確認できるようなやつ
• 例
  1. 変数が存在しない状態から使用する
     →存在しないものに対して操作しようとしている
  2. 変数が存在しない状態から消滅する
     →存在しないものに対して操作しようとしている
  3. 変数が存在する状態から生成する
     →既に存在するものを再生成しようとしている

スクリプトテスト

スクリプトテストとは？

• テストアプローチの1種
• 「仕事を計画し、計画に従って仕事する」
  • テスト実施前にテストケースを作成し、作成したテストケースを実施し、結果を報告する
• 利用可能なドキュメント
  • テスト計画書
  • テスト設計仕様書
  • テストケース仕様書
  • テスト手順書
  • テスト項目移管レポート
  • テストログ
  • テスト不具合レポート
  • テストサマリーレポート

探索的テスト

探索的テストとは？

• テストアプローチの1種
• 「テスト設計とテスト実行の同時並行的な学習行為」
  • テストケースを実行しながらテストケースの設計をする
• 場当たり的なテストとは違う
  • デタラメでスキル不足なテストを指している

テストの計画

■アンチパターン

• あまりに遠い将来まで自体を予想しようとすること

  計画すると、私たちはものごとをコントロールできていると錯覚してしまいがちですが、それは間違いです
  

• あまりに詳細まで計画すること

  テスト対象システムの欠陥にいったん遭遇すれば、テスト計画書は用をなさないのです
  

• 計画の手法を制度化してしまい、計画のプロセスも計画書も固定して変えられないという硬直化した思考に陥ること

  「仕事を計画し、計画に従って仕事する」というやり方ではなく、常に「仕事を計画し、計画に従って仕事し、仕事を見直し、計画を見直す」ようにしましょう
  

• 計画を、問題に対する変更不能な唯一な解決策だと思い込んでしまうこと

  たくさんの選択肢の追求を可能にしてくれる、自由に出入り可能な建造物と見なすべき
  「最初にそれが実現されたのと厳密に同じやり方で進化を主導することは、まず不可能なのである」
  

• 計画の欠点を識別して必要な調整を行うための、フィードバック機構の必要性を無視すること

  計画を1回だけの試みで問題を解決しようとする行為と見てはならない
  作業可能な解決策を迅速に見つけて、時間の許す範囲でそれを改善していく、ということを推奨する
  

テストの終了判定

■終了判定の方法

• 終了の判断基準の正解は存在しない
  →基準は組織で決める必要がある

↓基本的な基準

1. カバレッジ目標値
   • カバレッジの目標値を設けて、目標値を上回った時にテスト終了
2. 欠陥検出率
   • 欠陥検出率の閾値を設けて、閾値を下回った時にテスト終了
3. 限界コスト
   • 出荷するリスク > 欠陥を発見するコスト となった時にテスト終了
   • ソフトウェアテストは時間経過と共に欠陥の発見が難しくなる特性がある
     • 発見しやすい欠陥がなくなっていき、隠れた欠陥だけが残る
4. プロジェクトチームの合意
   • 出荷するリスク > 障害責任額 となった時にテスト終了
5. 「いいから出荷しろ」の一言
   • 文字通り