プログラミング・テスト・導入

snack
snack

今回は前回の続きで、開発プロセスのプログラミングからやっていくっす。

ボキタロー
ボキタロー

今まで、システム開発ってプログラミングのことだと思ってたよ。

snack
snack

そう思っている人は多いみたいっすね。しかし、プログラミングは開発プロセスの中の1つの工程に過ぎないんすよ。

プログラミング

赤字の部分が今回の学習内容です。

システム設計が終わったら、次はプログラミングの工程に入っていきます。このプログラミングの工程は、コーディング単体テストという作業から成っています。

プログラミング工程

コーディング

単体テスト

プログラミングの次にテストの工程がありますが、ITパスポート試験ではプログラミングの工程には単体テストの実施までを含むとされています。

コーディング

実際にコード(プログラム文)を書く作業をコーディングといいます。

人間が理解しやすいプログラム言語で書いたコードをソースコードと呼びます。ソースコードはコンピューターには理解できないため、翻訳プログラム(コンパイラ)によって、これをコンピューターが理解可能な機械語へ変換して実行します。

コーディング

単体テスト

コーディングしたモジュール(機能ごとのプログラムの単位)が設計通りに動作するかを確認する作業を単体テストといいます。単体テストでは、実際にプログラムを動作させ、バグと呼ばれるプログラムの不具合を発見します。

ソースコードのエラーやバグを見つけて修正することをデバッグといいます。

なお、単体テストはホワイトボックステストという手法で行われます。

ホワイトボックステスト

ホワイトボックステストは、プログラムの内部構造に着目しながら、意図したとおりに動作するかを確認するテスト手法です。プログラムのすべての命令や条件分岐を一通り実行できるテストデータを使用して開発者(プログラム担当者)が行います。

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

単体テストはプログラム担当者がテストを行うため、そもそも設計書の理解に誤りがあった場合にはミスに気付くことができないという弱点があるっす。

コードレビュー

ソースコードのレビュー(点検など)を行うことをコードレビューといいます。プログラム担当者ではなく、別の人がレビューすることで、見落としや誤りなどを発見することができます。

テスト

テストの工程は、結合テストシステムテスト運用テストという順で行われます。

テスト工程

結合テスト

システムテスト

運用テスト

結合テスト

単体テストが完了したモジュールを結合しながら、データの受け渡しや連携(プログラム間のインターフェース)がうまくできているかなど、プログラムの動作を開発者が確認していきます。

システムテスト

すべてのモジュールを組み合わせて、システムが設計に沿った正しい動作をするか、性能要件を満たしているか、などを開発者が確認するシステム全体の総合テストになります。

運用テスト

実際の業務で使うものと同じテストデータを利用して、実際の運用環境で検証を行います。要件定義(業務要件)どおりにシステムが動作するかを検証するテストです。

運用テストの実施は、依頼元の責任者(システムアドミニストレータ)が立ち会って行われます。

ブラックボックステスト

結合テスト、システムテスト、運用テストはブラックボックステストという手法で行われます。単体テストによって、1個1個のモジュール単体は正しく動作することを確認済みですが、それらを結合したときにデータの受け渡し等がうまくいくか、システム全体としてうまく動作するか、ということを確認するテストが必要になります。

そこで、システム内部の構造は考慮せずに、システムの入力情報と出力情報のみに着目して、プログラムで処理した結果から仕様書通りの出力が得られるかを検証します。

ブラックボックステスト
さらっと学習【ブラックボックステストの方式】

ブラックボックステストは、限界値分析同値分割などの方式で行われます。

限界値分析

データの許容範囲の上限と下限およびその前後のデータを使って行うテスト。

例)身長の入力データの許容範囲(下限50~上限250)の場合、使用するデータは「49」「50」「250」「251」。「49」と「251」を入力するとエラーが出ることを確認する。

同値分割

起こりうる事象をいくつかのグループに分けて、その代表値を使って行うテスト。

例)身長の入力データの許容範囲(下限50~上限250、半角数字)の場合、半角数字の「150」、全角数字の「150」、文字の「あ」、記号の「?」などを使用。半角数字以外を入力するとエラーが出ることを確認する。

導入・受入れ

テストが完了し、業務要件に沿ったシステムが実現できていることを確認したら、いよいよ導入・受入れです。

受入れ側(依頼元企業)においては、開発元の支援を受けながら、意図した運用環境でシステムを使用し、システムが意図した用途を達成しているかを確認する受入れテストを実施し、処理速度やエラー時の対応などに問題が生じないかを確認します。

受入れテストで問題がなければ、システムの納入(納品)が行われます。

ソフトウェア導入の工程においては、本番環境にソフトウェアを導入するための導入計画書を作成し、依頼元の合意を得てソフトウェア導入作業を実施します。

また、システムの操作方法を説明した利用者マニュアルを用いて、運用者、利用者及びその他の利害関係者への教育訓練を行います。

確認○×問題

問1

納入されたソフトウェアの一連のテストの中で、開発を発注した利用者が主体となって実施するテストは単体テストである。

答え:×

単体テストは、開発者(プログラム担当者)が主体となって行います。なお、利用者が主体となって実施するテストは受入テストです。

問2

開発者Aさんは、入力データが意図されたとおりに処理されるかを、プログラムの内部構造を分析し確認している。現在Aさんが行っているテストはホワイトボックステストである。

答え:〇

ホワイトボックステストは、プログラムの内部構造に着目しながら、意図したとおりに動作するかを確認するテスト手法です。プログラムのすべての命令や条件分岐を一通り実行できるテストデータを使用して、開発者(プログラム担当者)が行います。

問3

システム開発のテストを、単体テスト、結合テスト、システムテスト、運用テストの順に行う場合、システムテストの内容はbである。

a個々のプログラムに誤りがないことを検証する。
b性能要件を満たしていることを開発者が検証する。
cプログラム間のインタフェースに誤りがないことを検証する。
d利用者が実際に運用することで、業務の運用が要件どおり実施できることを検証する。

答え:〇

a.単体テスト個々のプログラムに誤りがないことを検証する。
b.システムテスト性能要件を満たしていることを開発者が検証する。
c.結合テストプログラム間のインタフェースに誤りがないことを検証する。
d.運用テスト利用者が実際に運用することで、業務の運用が要件どおり実施できることを検証する。

問4

ソフトウェアのテストで使用するブラックボックステストにおけるテストケースの作り方として、すべての命令や条件分岐を一通り実行できるテストデータを選ぶのが適切である。

答え:×

入力情報と出力情報のみに着目して行われるブラックボックステストにおいては、正常ケースやエラーケースなど、起こりうる事象をいくつかのグループに分けて、各グループが1回は実行されるようにテストデータを選びます。

問5

発注したソフトウェアが要求事項を満たしていることをユーザが自ら確認するテストは受入れテストである。

答え:〇

受入れ側(依頼元企業)においては、開発元の支援を受けながら、意図した運用環境でシステムを使用し、システムが意図した用途を達成しているかを確認する受入れテストを実施し、処理速度やエラー時の対応などに問題が生じないかを確認します。

問6

ソフトウェア導入作業においては、ソフトウェア導入作業を実施した後、速やかに導入計画書と導入報告書を作成し、合意を得る必要がある。

答え:×

ソフトウェア導入作業の実施前に導入計画書を作成し、依頼元の合意を得る必要があります。なお、導入報告書は作業実施後に作成します。