【ソフトウェアテスト】

シリーズ記事の目次

---

---

序文

---

第 4 章 単体テスト

4.1 ソフトウェアテストプロセスの概要

• ソフトウェアテストプロセスモデル - W モデル
• 単体テスト - モジュール/ホワイトボックステクノロジー
• 統合テスト - モジュール インターフェイス/ブラック ボックス + ホワイト ボックス テクノロジー
• システムテスト - 要件を満たす/ブラックボックス
• 受け入れテスト - 顧客の役割/ブラックボックスを明らかにする

4.2 単体テストとは何ですか?

4.2.1 単体テストの定義

• 単体テストは、ソフトウェアのテスト可能な最小要素の正確性を検証するテスト作業です。
• モジュールにエラーがないか、機能を正しく実装でき、パフォーマンスとインターフェイスの要件を満たせるかどうかを確認します。
• 「ユニット」とは、ソフトウェア内で独立してコーディングできる最小単位のことです。
• ユニット選択の基準: 機能的に独立しており、テスト可能、観察可能、明確に定義可能な境界またはインターフェイスがある
• 単位を決定するための最も基本的な原則: 高い凝集性、低い結合性
• テストオブジェクト: 重要なモジュールの重要な制御パス
• 各プログラムモジュールは並列かつ独立してテスト可能

4.2.2 単体テストの重要性

• 時間的側面
• テスト効果の観点から（①テストの基本 ②根深い問題 ③コード制御プロセスに焦点を当てる）
• テスト費用
• 製品の品質
• プログラミング プロセスでは、コードを 100 行記述するごとに 150 件の間違いが発生します。
• プログラミングとコンパイルの後、コード 100 行ごとに約 1 ～ 3 個のバグが残ります。
• プログラムのエラーを見つけて修正するコストは、開発投資全体の 40% ～ 80% を占めます。
• 開発プロセス全体でバグが早期に発見されるほど、修正コストが低くなります。

4.2.3 単体テストの原則

• 単体テストは早ければ早いほど良い
• 単体テストは「ソフトウェア詳細設計仕様書」に基づいて実施してください。
• 変更されたコードについては単体テストをやり直す必要がある
• テスターは実際のテスト結果を正直に記録する必要があります
• テスト対象のソフトウェアユニットのサイズの選択には注意が必要です
• 陽性テストと陰性テストの両方を含める必要があります
• 単体テストツールの使用に注意する

4.3 単体テストの目標とタスク

4.3.1 単体テストの目標: 単体モジュールが正しくコーディングされる

• データや情報がユニットに正しく出入りできるかどうか
• ユニットの作業プロセス中に、内部データの形式、内容、相互関係をエラーなく維持できるかどうか、またユニット内のグローバル変数の処理と影響も含めて、内部データが完全性を維持できるかどうか
• データ処理の境界で正しく動作しますか?
• ユニットの動作が特定のロジックカバレッジを満たすことができるかどうか
• ユニットにエラーが発生しました。エラー対処は有効ですか？
• ポインタが誤って参照されているかどうか、メモリが時間内に解放されるかどうか
• 安全上の危険はありますか

4.3.2 単体テストの主なタスク

• モジュールインターフェース:モジュールインターフェースが正しいかどうかを確認します[モジュール単位のデータ入出力が正しいかどうかを確認します]
  • モジュールが受け取った実パラメータが仮パラメータの数、型、単位と一致しているかどうか
  • 他のモジュールを呼び出す実際のパラメータが、呼び出されるモジュールの仮パラメータと一致しているかどうか
  • グローバル変数の定義は各モジュールで一貫していますか?
  • 外部入力、出力
  • ファイル、バッファ、エラー処理
• ローカル データ構造:ローカル データ構造の整合性をチェックします[モジュール内の内部データの整合性と正確性をチェックします]
  • タイプの指定が正しくないか、一貫性がありません
  • 変数の初期化またはデフォルト値が間違っています
  • 変数名が間違っているか、一度も使用されていません
  • 互換性のないデータ型
  • オーバーフローまたはアンダーフローおよびアドレス例外が発生する
  • グローバル データ構造がモジュールに与える影響
• 独立した実行パス:
  • それぞれの独立した実行パスのテストを確認します。各ステートメントが少なくとも 1 回実行されるようにしてください。[独立したパスをテストして計算、決定、制御フローのエラーを検出する]
    • 算術優先順位の誤解または誤った使用
    • 混合型の操作
    • 変数の初期値が間違っています
    • 計算精度が不十分
    • アルゴリズムエラー
    • 式の記号が間違っています
  • 判断と状態の網羅のため。
    • 異なるデータ型のオブジェクトを比較する
    • 論理演算と優先順位の不適切な使用
    • コンピューター表現の制限により、期待値は理論的には等しいが、実際にはそうではありません
    • 間違った決定または間違った変数
    • 異常または存在しないループ終了
    • ループ制御変数が誤って変更された
• エラー処理:予見可能かつ事前に設定されたエラー処理が正しく効果的であるかどうか。【モジュールでエラーが発生しました。システムのエラー処理が有効かどうか】
  • 出力されるエラーメッセージがわかりにくい
  • 報告されたエラーは現実と一致しません
  • プログラム定義のエラー処理の前にシステムが介入しました
  • 不適切な例外処理
  • エラーを特定するのに十分な情報が提供されていない
• 境界条件:重要なデータ処理の正確性をチェックします。【境界値解析手法を用いて境界で発生する誤差を発見する】
  • 一般的な法的データの処理。
  • 一般的な違法データの処理。
  • 境界値内の法的境界データの処理。
  • 境界値外の不正な境界データの扱い

4.4 単体テスト環境の構築

合格

4.5 単体テストの主な手法

• 主にホワイトボックステスト技術を採用し、ブラックボックステスト技術を補完
• 単体テストの主な手法:
  • 手動静的テスト
  • テストの動的実行 (ホワイト ボックス + ブラック ボックス)
  • 状態遷移テスト

4.5.1 静的テスト

• プログラムを実行せずにユニットコードのみを確​​認し、コードレビューや検査を行う
• 外部インターフェイスとプログラム コードの主要部分はデスクトップ検査とコード レビューの対象となります
• 目的: コード アルゴリズムの論理的な正確性、明確性、標準化、一貫性、およびアルゴリズムの効率性を確保すること
• 新しく開発されたコードや再利用されたコードに適しています
• 通常、コードがエラーなくコンパイルされてコンパイルされた後、自動ツールスキャン分析、コードレビュー、その他の方法が使用されます。
• ソフトウェア開発者と開発チームメンバーが共同で完成
• 一般的に使用される方法:
  • デスクチェック
  • コードウォークスルー
  • コードインスペクション（プログラムインスペクション）

4.5.2 テストを動的に実行する

• 動的ホワイトボックステスト: ロジックカバレッジと基本パステスト
• テストの基本原則:
  • ユニット内の各独立したパスが少なくとも 1 回実行されるようにする
  • すべての判断の各分岐が少なくとも 1 回実行されるようにする
  • 各ループが境界条件および一般条件の下で少なくとも 1 回実行されることを保証します。
  • すべてのユニット内部データ構造の妥当性を検証する
  • 動的ブラックボックステスト: 機能テストと非機能テストに分割
  • 要件を満たすカバレッジ基準を選択することに加えて、境界値分析、エラー推測などの手法を使用できます。

4.5.3 状態遷移テスト

• ユニットが異なる状態遷移にある可能性がある場合、ユニットが入る可能性のある状態、それらの状態間の遷移、遷移を引き起こす可能性のある状態などの観点からテストする必要があります。

4.6 単体テストの評価

• 単体テストに合格するための一般的なガイドライン:
• ソフトウェアユニットの機能が設計要件と一致している
• ソフトウェアユニットのインターフェースは設計要件と一致しています
• 入力エラーと実行時エラーを正しく処理できる
• 単体テストで見つかったバグは修正され、合格しました
• 関連する補償要件が満たされている
• 完全なソフトウェア単体テストレポート

4.7 単体テストの管理

• 単体テストのプロセス
  • 詳細設計段階で単体テスト計画を完了します。
  • 単体テスト環境を確立し、テスト設計と開発を完了します。
  • 単体テスト ケースを実行し、テスト結果を詳細に記録します。
  • テスト ケースが合格するかどうかを評価します。
  • 「単体テストレポート」を提出してください。
• 単体テストのドキュメント
  • 「ソフトウェア要件仕様書」「ソフトウェア詳細設計書」→「単体テスト計画書」
  • 「単体テスト計画」「ソフトウェア詳細設計手順」→「単体テストケース」
  • 「単体テストケース」文書、「ソフトウェア要件仕様書」、「ソフトウェア詳細設計書」→「不具合追跡報告書」/「不具合チェックリスト」
  • 「単体テストケース」「欠陥追跡レポート」/「欠陥チェックリスト」→「単体テストチェックリスト」
  • 評価→「単体テストレポート」

4.8 単体テストツール

• 単体テストツールの概要
  • 自動単体テスト ツールの動作原理は、ドライバー モジュールとスタブ モジュールを使用してテスト対象のソフトウェア ユニットを実行し、入力テスト ケースがソフトウェアの詳細な設計仕様に従って関連する操作を実行するかどうかを確認することです。
  • 共通カテゴリ: 静的解析ツール、コード仕様レビュー ツール、メモリおよびリソース検査ツール、テスト データ生成ツール、テスト フレームワーク ツール、テスト結果比較ツール、テスト測定ツール、テスト ドキュメント生成および管理ツール
• JUnit の概要
  • JUnit は、反復可能なテストを作成および実行するためのオープンソース Java テスト フレームワークです。
  • 単体テスト フレームワーク システム xUnit のインスタンスです。
  • xUnit シリーズのフレームワークは、さまざまな言語に応じて一般的に使用され、JUnit (java)、CppUnit (C++)、DUnit (Delphi)、NUnit (.net)、PhpUnit (Php) などに分かれています。

---

要約する

• 目標: モジュールが正しくコーディングされていることを確認する
• 基礎: 詳細な設計指示
• プロセス: 設計、スクリプト開発、実行、デバッグ、結果の分析
• 試験方法：ホワイトボックス+ブラックボックス
• 評価方法: すべてのテストケースに合格し、コードに重大な欠陥がない
• 実行者: プログラム開発者 + テスター

---

第 4 章のハイライト

• ①単体テストの目的と主な作業をマスターする
• ②単体テスト環境の構築と使用する主要技術を習得する
• ③単体テストの評価技術と管理プロセスに精通している
• ④単体テスト自動化ツールの事前理解、Javaプログラムテストを実現するJUnitの基本的な手法を理解している