単体・結合・ｼｽﾃﾑ・運用ﾃｽﾄ,保守

以下記事の続き。

◆情報システム開発の流れ（ウォーターフォール型の場合）

開発の各手順を時系列的に順番に一つずつ完了させながら進める。

この前半を「上流工程」、後半を「下流工程」と呼ぶ。

代表的な各手順は次。

①「システム化計画」

②「要件定義」

③「システム要件定義」「システム方式設計」

④「ソフトウェア要件定義」「ソフトウェア方式設計」「ソフトウェア詳細設計」

⑤「ソフトウェア構築（プログラミング）」（コードレビュー）

⑥「単体テスト」（④ソフトウェアレベルの確認）

⑦「結合テスト」（④ソフトウェアレベルの確認）

⑧「システムテスト」（③システムレベルの確認）

⑨「運用・受入れテスト」（②要件レベルの確認）

◆テスト工程

ソフトウェア詳細設計書に基づきプログラミングされた各モジュールに対して、各レベルでの動作確認を行う。

各レベル：「単体」「結合」「システム」「運用」「受入れ」

モジュール：独立した機能を持ったソフトウェア構成単位

ホワイトボックステスト、ブラックボックステスト 等により動作確認が行われる。

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

ソフトウェアやシステムのテスト手法のひとつ。

プログラムの内部構造を理解したうえで、それら一つ一つが意図した通りに動作しているかを確認する。

基本的にはプログラム内の全ての命令、全てのルーチンが最低一回は実行・検証されるようになっている。

システムの機能よりも、内部構造の整合性を重視したテストともいえる。

「命令網羅」「判定条件網羅」「条件網羅」「複数条件網羅」「経路組み合わせ網羅」等の方式がある。

記述者の意図との整合性を確認するだけなので、記述者自身に誤解があった場合、対処できない。

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

ソフトウェアやシステムのテスト手法のひとつ。

テスト対象の内部構造を考慮に入れず、外部から見た機能や振る舞いが正しいかどうかだけを検証する。

つまり、入力・出力のみに着目し、様々な入力に対して想定通りの出力が得られるかどうかを確認する。

「同値分割」「限界値分析（境界値分析）」等の手法がある。

同値分割：仕様上同じ処理が行われるはずの値の範囲やグループから、代表値を選んで正しく処理されるかテスト実行する。

限界値分析（境界値分析）：仕様上同じ処理が行われるはずの値の範囲の限界値（境界値）が正しく処理されるかテスト実行する。

◆単体テスト（情報システム開発の⑥工程）

情報システム開発工程の④段階である「ソフトウェア」レベルの確認を行う。

ソフトウェアを構成する個々のプログラム（モジュール）に誤りが無いかを確認する。

単体テスト、ユニットテスト(Unit Test)、コンポーネントテスト(Cmponent Test)、パーツテスト(Part Test)、等の呼び方をされることもある。

テスト条件を記述するとテストプログラムを自動的に生成してテストを実行し、結果を提示するテストツールが利用されることが多い。

多くのモジュールは、それ単体ではプログラムとして完結して実行できないため、テストドライバ・スタブ 等が必要になる。

テストドライバ（サンプルドライバ）：テスト対象の下位モジュールを呼び出すための、テスト用の上位モジュール（プログラム）。

スタブ：上位モジュールに場合に呼び出される、空（ダミー）のモジュール。テスト対象の上位モジュールをテストしたいが、下位モジュールが未完成な場合 等に用いられる。stubは「切り株・半券」等の意味で、IT分野では、本物が用意できないときに「とりあえずおいて置く代表品」の意味で用いられることが多い。

◆結合テスト（情報システム開発の⑦工程）

情報システム開発工程の④段階である「ソフトウェア」レベルの確認を行う。

複数のモジュールを組み合わせて正しく連結できるかどうかのテスト。

また、モジュール間のインターフェース（接続点）が仕様通りに作成され、整合していることを検証する。

結合テスト(Join Test)、統合テスト(Intergration Test)、連結テスト(Link Test)、インターフェーステスト(Interface Test) 等の呼び方をされることもある。

ボトムアップテスト：最下位モジュールから上位に向かって順番にテストしていく方式。

トップダウンテスト：最上位モジュールから下位に向かって順番にテストしていく方式。

◆システムテスト（情報システム開発の⑧工程）

情報システム開発工程の③段階である「システム要件」レベルの確認を行う。

開発の最終段階にシステム全体を対象に行われるテスト。

本番同様の環境を構築して、ハードウェア・通信回線 等も含めシステム全体が適切に機能するかを検証する。

具体的には、システム仕様書通りに動作するか、性能・負荷への耐性は十分か、操作性・セキュリティに問題ないか 等を検証する。

◆運用・受入れテスト（情報システム開発の⑨工程）

情報システム開発工程の②段階である「要件」レベルの確認を行う。

発注元の協力が必要なテスト。

発注元が、実際に本番環境下でシステムを運用して、業務の運用が要件通り実施できることを検証する。

運用マニュアルが適切であり、決められた業務手順書通りにシステムが稼働するか 等を確認する。

ユーザ受入テスト(User Acceptance Test)、検収テスト、承認テスト 等と呼ばれることも有る。

特に、発注元が完成したシステムの納品を受け付けるか否かを判定するための試験については「受入れテスト」と言われ、このテストにパスすると開発は終了。

◆（ソフトウェアの）運用・保守

運用：受入れテストをクリア後、発注元によりシステム稼働、使用し続けること。発注元は運用にあたり、利用者に対して教育訓練 等の運用支援を行う。

保守：発見された障害の是正、新規要件対応 等。具体例は以下。

・稼働中のソフトウェアの不具合に対する修正。

・法律改正に伴い、ソフトウェアを修正。

・ソフトウェアの修正に伴い、設計時のドキュメント（文書）を修正。

・修正後、レグレションテストを行う。

◆レグレション（リグレッション）テスト

回帰テスト・退行テスト・デグレードテスト とも呼ばれる。

ソフトウェア保守に当たり、修正箇所が他の正常箇所に影響を及ぼしていないことを検証すること。