基本情報技術者試験など情報処理技術者試験を受験する方にとっては必須の,ソフトウェア構築・テストについてシンプルにまとめています。ソフトウェア構築では,プログラミング(ソフトウェアユニットの作成)(コーディング規約),単体テスト(ソフトウェアユニットのテスト)(ブラックボックステスト(同値分割,限界値分析,原因-結果グラフ(因果グラフ)),ホワイトボックステスト(命令網羅,判定条件網羅(分岐網羅),条件網羅,判定条件/条件網羅,複数条件網羅)),ソフトウェアコードとテスト結果の評価及びレビューを,テストでは,ソフトウェア結合テスト(ボトムアップテスト(ドライバ),トップダウンテスト(スタブ),折衷テスト(サンドイッチテスト),ビッグバンテスト),ソフトウェア適格性確認テスト,システム結合テスト,システム適格性確認テスト(機能テスト,性能テスト,操作性テスト,障害回復テスト,負荷テスト,耐久テスト,例外テスト,セキュリティテスト),運用テストを説明します。たくさんありますが,頑張りましょう。
このページの内容は,システム開発の全体像を理解した上で読んだ方が理解が深まると思いますので,先に次のページを読むことをお勧めします。

ソフトウェア構築
プログラミング(ソフトウェアユニットの作成)
プログラミングでは,ソフトウェア詳細設計の内容に基づいて,各モジュール(ソフトウェアユニット)を作成(コーディング)し,ソース(原始)プログラムを作成します。
コーディング規約
プログラミングについては,誰が見ても読めるように,コーディング規約を定めます。
- 命名規則を定める(変数名や関数名などに統一性のある名前を付ける)
- コーディングのスタイルを定める(括弧の付け方やインデントなどの記述を統一する)
- 禁止事項を定める(利用してはいけない機能などを定める)
※ プログラミングの詳細は「」を参照
単体テスト(ソフトウェアユニットのテスト)
単体テストでは,テスト手順やテストデータを作成し,作成したモジュールが要求事項を満たしているかを,ソフトウェア詳細設計で定義した内容に従いテストします。
※ 1つのモジュールやプログラム単位で機能の確認を行う
ブラックボックステスト
ブラックボックステストは,モジュールの仕様に基づき,モジュールの外部から見た機能やインタフェースに着目して行うテストです。
※ モジュールの内部に冗長なコードがあった場合,それを検出することはできない
※ すべてのテスト工程で使用できるテスト手法である
同値分割
同値分割では,モジュールへの入力データを,正しい値を持つ有効同値クラスと,正しくない値を持つ無効同値クラスに分割し,各クラスから1つの値を取り出してテストデータとします。
限界値分析
限界値分析では,モジュールへの入力データを,正しい値を持つ有効同値クラスと,正しくない値を持つ無効同値クラスに分割し,各クラスの境界値を取り出してテストデータとします。
原因-結果グラフ(因果グラフ)
原因-結果グラフでは,入力(原因)と出力(結果)の因果関係をグラフで表し,それを基に決定表(デシジョンテーブル)を作成して,テストケースを洗い出します。
※ モジュールへの入力データが明確にクラス分けできない場合に有効な方法である
ホワイトボックステスト
ホワイトボックステストは,モジュールの内部構造に着目して行うテストで,モジュールの論理構造が正しいかをテストします。
※ すべての実行経路を検証するのが望ましいが作業量の面から困難であるため,網羅性と生産性を考慮したうえで,分岐や繰返しなど重要な部分をテストするようにする
命令網羅
命令網羅では,すべての命令を少なくとも1回は実行するようにテストケースを作成します。
判定条件網羅(分岐網羅)
判定条件網羅では,分岐の判定条件で真となる場合と偽となる場合を,それぞれ少なくとも1回は実行するようにテストケースを作成します。
条件網羅
条件網羅では,分岐の判定が複数の条件から成る場合に,各条件が真となる場合と偽となる場合を組み合わせたテストケースを作成します。
※ 各条件の真と偽を,1回はテストするようにする
判定条件/条件網羅
判定条件/条件網羅では,判定条件網羅と条件網羅を組み合わせてテストケースを作成します。
※ 分岐の判定が複数の条件から成る場合の方法
複数条件網羅
複数条件網羅では,分岐の判定条件において,取り得るすべての組合せを網羅するようにテストケースを作成します。
※ 分岐の判定が複数の条件から成る場合の方法
ソフトウェアコードとテスト結果の評価及びレビュー
ソフトウェアコードとテスト結果の評価及びレビューでは,ソフトウェアコードとテスト結果を評価し,レビューを行います。
※ レビューの詳細は,「レビュー -情報処理シンプルまとめ」を参照
ソフトウェア結合テスト
ソフトウェア結合テストでは,プログラムの動作確認を,ソフトウェア方式設計で定義した内容に従いテストします。
また,ソフトウェア結合テストの評価及びレビューも行います。
※ レビューの詳細は,「レビュー -情報処理シンプルまとめ」を参照
ボトムアップテスト
ボトムアップテストでは,下位のモジュールから上位のモジュールへと順に結合しながらテストします。未完成の上位のモジュールの代わりにドライバが必要になります。
※ ドライバ…上位モジュールの働きをするテスト用モジュール
トップダウンテスト
トップダウンテストでは,上位のモジュールから下位のモジュールへと順に結合しながらテストします。未完成の下位モジュールの代わりにスタブが必要になります。
※ スタブ…下位モジュールの働きをするテスト用モジュール
折衷テスト(サンドイッチテスト)
折衷テストでは,あらかじめ折衷ラインを定めておき,その折衷ラインの上位をトップダウン,下位をボトムアップで並行してテストします。
※ スタブとドライバが必要になる
ビッグバンテスト
ビッグバンテストでは,プログラムを構成するすべてのモジュールの単体テストが終了した後に,全モジュールを結合して一気にテストします。
※ 一気にテストできるが,モジュール間インタフェースのエラーが見つけにくく,エラーが見つかった場合でもデバッグが難しい
ソフトウェア適格性確認テスト
ソフトウェア適格性確認テストでは,ソフトウェアが要件どおりに作成されているかの確認を,ソフトウェア要件定義で定義した内容に従いテストします。
また,ソフトウェア適格性確認テストの評価及びレビューも行います。
※ レビューの詳細は,「レビュー -情報処理シンプルまとめ」を参照
システム結合テスト
システム結合テストでは,ハードウェア,ソフトウェア,人による活動,その他すべてを結合したシステムの動作確認を,システム方式設計で定義した内容に従いテストします。
また,システム結合テストの評価及びレビューも行います。
※ レビューの詳細は,「レビュー -情報処理シンプルまとめ」を参照
システム適格性確認テスト
システム適格性確認テストでは,システムが要件どおりに作成されているかの確認を,システム要件定義で定義した内容に従いテストします。
※ 実際に業務で使用するデータを使用してテストするが,テストは本番環境とは隔離した環境で行う
機能テスト | 求められたシステム要件を満たしているかをチェックする |
性能テスト | 求められたシステム性能(スループットやレスポンスタイムなど)を満たしているかをチェックする |
操作性テスト | 操作しやすいかなど,ユーザーインタフェースをチェックする |
障害回復テスト | 障害発生時における回復機能をチェックする |
負荷テスト | 通常時よりも大きな負荷がかかったときの性能や機能をチェックする |
耐久テスト | 長時間の連続運転に耐えられるかをチェックする |
例外テスト | 例外的なデータや異常なデータの入力に対する動作が適切であるかをチェックする |
セキュリティテスト | 十分なセキュリティ対策が施されているかをチェックする |
運用テスト
運用テストでは,本番環境(または,リリース前の環境)で,システムが実際の業務手順通りに稼働することをテストします。
※ 利用者がテストを行い,テストに問題がなければ,システムは利用者側に引き渡される
まとめ
今回は,ソフトウェア構築・テストについて,シンプルにまとめてみました。たくさんありましたが,今回の内容は,基本情報技術者試験や応用情報技術者試験など,実際の情報処理技術者試験で出題されます。繰り返し読んで覚えるようにしましょう。