読書メモ 『ソフトウェアテストの教科書』

• この1冊でよくわかる ソフトウェアテストの教科書 ― 品質を決定づけるテスト工程の基本と実践
• SBクリエイティブ
• 2012/01/28
• 石原一宏、田中英和、田中真史
• https://www.amazon.co.jp/dp/4797365811/

メモ

• 2020/03
• 本書は資料、図表が豊富に掲載されるが、本メモでは文章のみ抜き出す

ソフトウェアテストの基礎

ソフトウェアテストとは

• ソフトウェアの多機能化
• 開発期間短縮

フィリップ B クロスビー （実業家）

• 「品質とは要求を満たすこと」

G M ワインバーグ （作家、心理学教師、人類学者）

• 品質のよいソフトウェアとは「ユーザーの要求を満たしユーザーに価値を提供するソフトウェア」

ISO/IEC 9126

• 品質の6分類定義
  • 機能性、信頼性、使用性、効率性、保守性、移植性

Verification（検証） and Validation（妥当性確認）

Verification（検証）

• 仕様書通りに作成されていること
• 仕様書の工程単位ごとに検証する

Validation（妥当性確認）

• ユーザー要求に対する妥当性の確認
• ソフトウェアだけでなく仕様書の内容も妥当性確認する

狩野モデル

• 当たり前品質
  • 充足 ： 当たり前
  • 不充足 ： 不満
• 一元的満足
  • 充足 ： 満足
  • 不充足 ： 不満
• 魅力的満足
  • 充足 ： 満足
  • 不充足 ： 仕方がない
• 各機能を狩野モデルの品質要素で分類しておく

※ @sekiyaeiji 引用

狩野モデル （Wikipedia）
https://ja.wikipedia.org/wiki/%E7%8B%A9%E9%87%8E%E3%83%A2%E3%83%87%E3%83%AB

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

V字モデル

• 要件定義 ・・・・・・・・・・・・・・・・・ システムテスト
• 　　　　基本設計 ・・・・・・・・・・ 機能テスト、結合テスト
• 　　　　　　詳細設計 ・・・・・・ 単体テスト
• 　　　　　 　　　　　　　開発

テスト工程の流れ

単体テスト

• モジュールごとに行う
• プログラマ自身が担当

結合テスト

• 複数モジュールを組み合わせてテスト
• モジュールを横断した入出力をテスト
• 動作順序やタイミングも確認

機能テスト

• 組み合わせたモジュールを1つの機能として確認
• 機能として正しく役割を果たしていることを確認

システムテスト

• ユーザーの立場から様々な使い方を試して欠陥を検出する

ホワイトボックステスト

• 内部構造を理解した上で意識しながら行うテスト
• 単体テストで用いる
  • 制御フローテスト
  • データフローテスト

制御フローテスト

• 「制御パステスト」とも呼ぶ
• フローチャートを描く
• カバレッジ基準を決める
  • ステートメントカバレッジ
    • 命令文に着目
    • すべての命令文を最低1回通る
  • デシジョンカバレッジ
    • 「ブランチカバレッジ」とも呼ぶ
    • 条件分岐のすべての経路を最低1回通る
  • 複合条件カバレッジ
    • 条件に含まれるすべての条件パターンをテストする
• デシジョンカバレッジ 100% >= ステートメントカバレッジ 100%
• 複合条件カバレッジ 100% >= デシジョンカバレッジ、ステートメントカバレッジとも 100%

データフローテスト

• 定義 → 使用 → 消滅
• エラーの例
  • 未定義で使用
  • 定義済未使用
  • 未消滅使用

ブラックボックステスト

• 内部構造を意識しないテスト
  • 機能テスト
  • システムテスト

テストの工程

• テスト計画
  • テストの目的とアプローチを検討
  • 設備、環境、人員、スケジュールも定める
• テスト設計
  • テストの種類、目的、対象機能、使用する技法、入出力手段などを定める
  • 機材や合否判定の詳細を定める
• テストケース作成
  • 開始前の状態、期待結果、判定欄などを記入するドキュメントを作成
• テスト実施
  • テスト実施、判定記入
  • 不具合報告書の作成
• テスト報告
  • テスト結果を要約して報告
  • リリース後に懸念されるリスクや次期プロジェクトの推奨事項を提案

テスト計画、テスト設計の流れ

• テスト目的の確認
  • テスト目的の確認
  • テストアプローチの決定
    • テスト範囲
    • テスト内容
    • テスト方法
• 機能一覧の作成
  • 機能洗い出し
• テスト観点の抽出
  • テストの切り口
  • テスト目的を品質特性に変換し、品質特性に対応したテスト観点を抽出する
• テスト観点の機能への割当
  • 機能観点一覧表を作成
• テスト技法の検討と適用

テスト観点一覧表

• 属人的ではない体系的なテストの実施
• スキル差に依存しない
• テスト観点の漏れ、抜け、重複の回避
• テスト観点の位置づけ、重要度を検討できる

さまざまなテスト技法

同値クラステスト

• 動作が変わる条件の境目に注目するテスト
• 同値クラスごとに行うテスト
  • 同じ処理結果になる入力値の集まり
  • 同じ処理結果になる時間の集まり
  • 同じ入力値から処理される処理結果の集まり
  • など
• 有効同値クラス
  • 正常系
• 無効同値クラス
  • 異常系
• 代表値には範囲の中間値を選択することが多い
• 仕様書から読み取れる同値クラスと内部構造が一致しないこともある

境界値テスト

• 動作が変わる条件の境目に注目するテスト
• 仕様条件の境界値とその隣の値に対して行うテスト
• 欠陥は境界に潜んでいる可能性が高い
  • 境界を表す条件の誤解
  • コーディング時の条件の記述誤り
    • 等号、不等号の誤りなど
• 境界値テスト実施方法
  • 境界を見つける
  • 境界値を決める
  • テストする値を決める
    • 境界値
    • 境界値の1つ下 （境界値と同値クラスの関係ならば省略可能）
    • 境界値の1つ上 （境界値と同値クラスの関係ならば省略可能）
• 隠れた境界値
  • 仕様変更によりコードにだけ残った境界値など

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

• システムテストの機能確認テストで利用する
• デシジョンテーブル
  • ソフトウェアにおける複数条件によって決定される動作の一覧
• デシジョンテーブルを使用するテスト
• 条件の組み合わせの漏れに注意
• 条件、アクション（行）をリストアップする
• ルール（列）項目出しに樹形図を利用する
• 条件分岐のYes／Noに従ってY／Nを入力する
• テスト不要のアクションに「N/A」（Not Applicable ： 適用なし）を入力する
• 条件とルールの組み合わせにより、YでもNでもどちらでもよい項目に「−」を入力する
• 他の条件と関連が薄かったり独立性の高い条件は一覧表を分けた方が見やすいことがある
• 複数のルールで欠陥を発見し、ルールの類似性から原因を特定できる
• 仕様書チェックなどの静的テストにも有用

状態遷移テスト

• 結合テスト、機能テストの状態遷移テストで利用できる
• システムテストの機能確認テストでも利用できる
• さまざまに変化するソフトウェアの「状態」に着目するテスト
• 状態遷移、イベントに注目する
• 画面遷移テストも状態遷移テストのひとつ
• 「欠陥は仕様が曖昧な箇所に潜む」
• 状態遷移図を作成する
• 状態遷移図が大きくなりすぎる場合は分割する
• テストケースの作り方
  • すべての状態を1回は通ること
  • すべてのイベントを1回は発生させること
  • すべての遷移を1回は通ること
• 「できないこと」が本当にできないことの確認も必要

組み合わせテスト

• 複数の条件を組み合わせてソフトウェアの動作を確認する
• 一定のルールにしたがって組み合わせの数を減らす方法
  • 2因子間網羅
  • 2つの因子間の組み合わせを網羅する
    • All-Pairs法（Pairwise法）
    • 直交表
• 多くの欠陥は2因子間で見つかる
• 1因子と2因子間で見つかる欠陥の割合
  • サーバー用ソフトウェア ： 70%
• 3因子間で見つかる割合
  • サーバー用ソフトウェア ： 89%
• All-Pairs法の組み合わせ表ツール
  • PictMaster
• All-Pairs法の方が直交表よりも組み合わせ数は少なくなる
• 何のために行うのか、効果があるかを明確にして行う
• 無理に行わない

テストドキュメントとモニタリング

テストドキュメントの作成

テストドキュメントの必要性

• テスト工程での品質劣化防止
• 品質状況の可視化

テストドキュメントの種類

• テスト全体計画書
• 個別テスト計画書
• テスト設計仕様書
• テストケース
• テストログ
• 不具合報告書
• 進捗管理表
• テストサマリレポート

テストドキュメントの正しい書き方

• 追跡性、関連性に留意
  • ドキュメント識別番号付与
    • ドキュメント名称、ドキュメントID
  • 関連性のあるドキュメントを記載
• 定義の理由を記載する
  • 理由を考える習慣が付く
• 作成方法や流用元を記載
• テスト対象外の項目を記載

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

• テストにより収集されるデータをもとに状況把握すること
• 時間経過に伴い変化する状況のモニタリング
  • 信頼度成長曲線
  • 解決済み不具合累積数推移グラフ
  • 実施済みテストケース累積数推移グラフ
  • 不具合解決平均日数推移グラフ
• 不具合を分類して不具合の傾向をモニタリング
  • 不具合報告書の項目による分類
    • 重大度別
    • 原因別
    • 現象別
  • ソフトウェアの作り方による分類
    • ユーザーの要求事項別
    • サブシステム別、機能別
    • 処理分類別
    • データ項目別
  • テスト方法による分類
    • テスト工程別
    • テスト種類別
    • テスト観点別
• 信頼度成長曲線によるモニタリング
  • 不具合の多そうな箇所からテストする
  • 見つかった不具合をなるべく早く修正する
  • 修正された不具合をすぐに確認する

気付き

• 漠然と行っていたさまざまなテストを系統立てて分類できた
• Validation（妥当性確認）というユーザーテスト的観点もテストとして扱えることを知った
• 境界値テストとデシジョンテーブルテストが使いやすそう
• 境界値の設定方法が明確になった

ToDo

• 新サービス開発で各種テストを実施する
• 新サービスをテーマに各種テストドキュメントを書いてみる

感想

• テストコストがひじょうに高そうなテストも存在する
• 高コストのテストを選択するかどうかの判断が難しそう
• 「欠陥は仕様が曖昧な箇所に潜む」が耳が痛いが、網羅するのは大変