【テスト手法】システム・ソフトウェアの代表的なテスト手法を徹底解説!

【テスト手法】システム・ソフトウェアの代表的なテスト手法を徹底解説!
ハテオ君

システムやソフトウェアのテスト手法の理解ができないし、何のために存在しているのかも分からない。

今回はこの悩みを解決していきます。

本日の記事テーマ

システム・ソフトウェアで行うテストの基礎知識~手法の鮎類まで徹底解説

IT技術を活用したサービスを提供するには、機械を動かすプログラム(ソフトウェア)でシステムを開発しサービスとして提供します。

ITサービスを安心・安全に利用するためには、開発工程で正常に動作するかチェックをする「テスト」を行わないといけません。

そのため今回は、テストの基礎知識と各テスト手法を解説して行きます。

このテストは、IT資格の試験でも出題される内容ですので是非参考にしてください。

本日の記事内容

  • テストを行う目的
  • ①:ソフトウェアユニットテスト
  • ②:ソフトウェア結合テスト
  • ③:ソフトウェア適格性確認テスト
  • ④:システム結合テスト
  • ⑤:システム適格性確認テスト
  • ⑥:導入~受け入れテスト
  • ⑦:ソフトウェア保守

記事の最後には、今回の内容に関しての確認問題も用意していますので、インプットとアウトプットとしても是非活用してみてください。

元中卒の私が誰でも理解できるように解説していきます。

それでは早速見ていきましょう!

黄島 成

テストを行う目的

テストを行う目的

プログラムのテストの目的は、バグを発見することです。プログラムの中に潜んでいる誤りや欠陥を「バグ」呼ぶ。

そのため、可能な限りエラーを見つけることができるようテストデータを作成する必要があります。

一般的にテスト開始段階では多くのバグが潜んでいますが、テストを消化するにつれてバグが修正され減少し、高品質のプログラムに変わっていきます。

テスト開始後からの累積バグ件数をグラフに表すと、「信頼度成長曲線(ゴンペルツ曲線)」と呼ばれる曲線が現れます。

この曲線のようにならない場合は、まだバグが内在している可能性が高いということになる。

ちなみに、プログラムの中のバグを取り除くことを「デバッグ」といいます。

信頼度成長曲線(ゴンペルツ曲線図)

テストの流れ

テストは、以下図の順番で進めていきます。

テスト手法図

各テストとも、各設計段階で定義したテスト仕様に基づいて、それに沿ったテストデータを準備して行われます。

それでは順番に各テストについて詳しく見て行きましょう。

①:ソフトウェアユニットテスト

①:ソフトウェアユニットテスト

ソフトウェアユニットテストは、プログラムを機能単位に分割したモジュール単位で行うテストです。別名「単体テスト」や「モジュールテスト」とも呼ばれる。

このテストでは、ソフトウェア詳細設計で定義したテスト仕様に従って行い、要求事項を満たしているかどうかを確認して行きます。

代表的な手法には主に以下2つの手法が使われています。

  • ホワイトボックステスト
  • ブラックボックステスト

ホワイトボックステスト

ホワイトボックステストは、モジュールの内部構造に着目して行うテストです。

プログラムの内部構造や論理が記述された内部仕様書に基づくテストであり、主にプログラム開発者自身が実施します。

いろいろな条件を網羅するほど品質は上がりますが、システム完成までの時間がかかってしまうことになります。

例えば、次のようなテストデータ作成方法があります。

データー作成方法一覧

名称概要
命令網羅すべての命令を少なくとも1回以上実行するようにする
分岐網羅(判定条件網羅)すべての判定条件文において、結果が真になる場合と偽になる場合の両方をテスト
条件網羅すべての判定条件文を構成する各条件式が、真になる場合と偽になる場合の両方がテストされるようにする(分岐は考慮しない)
複数条件網羅すべての判定条件中にある個々の条件式の起こり得る真と偽の組み合わせと、それに伴う判定条件を網羅するようにする

例えば、次のような場合のテストケースを考えてみましょう。

ホワイトボックス図

それぞれ、以下のようなテストケースを仕様することになります。

命令綱>

すべての命令を1回以上→真となる①②③のいずれか(偽の処理はない)

分岐網羅(判定条件網羅)

結果が真となる場合と偽になる場合→真となる①②③のいずれかと、偽になる④

条件網羅

各条件式が真になる場合と偽になる場合①(真,真)、②(偽,真)、③(真,偽)、④(偽,偽)→①と④、または、②と③のいずれか複数条件

網羅

個々の条件の起こりうる真と偽の組み合わせ→①②③④のすべて

ブラックボックステスト

ブラックボックステストは、モジュールの内部構造を考慮することなく、仕様書通りに機能するかどうかをテストします。

プログラマーが設計者の意図した機能を実現しているかどうかを確認するテストです。

このテストでは、主にプログラム開発者以外の第三者が実施します。

ソフトウェアユニットテストを始め、各テスト工程で行います。

テストデータ作成方法には「限界値分析」と「同値分割」が存在します。

データー作成方法一覧

名称概要
限界値分析有効値と無効値の境界となる値とテストデータとする
同値分割有効値と無効値のグループに分け、それぞれのグループの代表的な値をテストデータとする

例えば、入力項目”年齢”(整数値)の正常データ範囲が15≦年齢≦60である場合を考えてみましょう。

ブラックボックス図

限界値分析では、有効同値クラスの最小値と最大値、およびそれらを1つ超えた値をテストデータとします。

この例の場合は「14,15,60,61」となります。

同値分割では、有効同値クラスと無効同値クラスから、それぞれ代表的な値をテストデータとします。

この例の場合は「10,30,70」などの値となります。

②:ソフトウェア結合テスト

②:ソフトウェア結合テスト

ソフトウェア結合テストは、ソフトウェアユニットテスト済みのモジュール同士を結合して行うテストです。別名、結合テストとも呼ばれる。

ソフトウェア方式設計で定義したテスト仕様に従って行い、モジュール間のインタフェースを確認します。

代表的な手法には主に以下2つの手法が使われています。

  • トップダウンテスト
  • ボトムアップテスト

トップダウンテスト

トップダウンテストは、上位のモジュールから下位のモジュールへと順次結合して検証する手法です。

下位のモジュールが完成していない場合、テスト対象のモジュールからの呼び出し命令の条件に合わせて値を返すダミーモジュールの「スタブ」が必要となります。

トップダウンテスト図

ボトムアップテスト

ボトムアップテストは、下位のモジュールから上位のモジュールへと順次結合して検証する手法です。

上位のモジュールが完成していない場合、テスト対象モジュールに引数を渡して呼び出すダミーモジュールの「ドライバ」が必要です。

ボトムアップテスト図

③:ソフトウェア適格性確認テスト

③:ソフトウェア適格性確認テスト

ソフトウェア適格性確認テストは、ソフトウェア要件定義で定義したソフトウェア適格性要件に従って行うテストです。

このテストでは、ソフトウェア要件通りに実現されているかどうかを確認します。

④:システム結合テスト

④:システム結合テスト

システム結合テストは、システム方式設計で定義したテスト仕様に従って行うテストです。

このテストでは、ソフトウェア、ハードウェア、手作業のすべてを結合したシステムが要件を満たしているかどうかを確認します。

代表的な手法には、以下のようなものがあります。

システム結合テスト代表的な手法一覧

テスト概要
機能テストシステム要件に定められている機能が、すべて含まれているかどうかを検証する
性能テスト要求される処理能力や応答時間を満たしているかどうかを検証する
例外処理テスト間違ったデータを入力したときにエラーとして認識されるかどうか検証する
負荷テスト(ストレステスト)量的な負荷をかけてシステムが業務に耐えられるかどうかを検証する
操作性テスト操作性の良さや表示されるエラーのわかりやすさを検証する
状態遷移テスト設計されたイベントと内部状態の組み合わせ通りにシステムが動作することを検証する

⑤ :システム適格性確認テスト

⑤ :システム適格性確認テスト

システム適格性確認テスト(システムテスト)は、実際に実務で使うデータや、業務上例外として処理されるデータを使って行うテストです。

システム要件定義で定義した適格性条件に従って行い、システム要件通りに実現されているかどうかを確認します。

:導入~受け入れテスト

⑥:導入~受け入れテスト

システムが完成すると、開発環境から実際の本番環境または本番疑似環境へ導入し問題点を発見する運用テストを行います。

問題点が解消し、仕様通りに完成していることを開発者の支援のもとで利用者が確認し(受け入れテスト)「システムの納品・システム移行・本番運用開始・保守プロセス」へ移行ということになります。

運用テストは、本番システム稼働後に行うテストのことを言うこともあります。

:ソフトウェア保守

⑦:ソフトウェア保守

ソフトウェア保守は、稼働中のソフトウェアに対して、発見された障害を是正したり、新しい要件に対応するために機能を拡張したりすることです。

リグレッションテスト(退行テスト)は、ソフトウェア保守に当たり、修正や変更によって影響を受けないはずの箇所に影響を及ぼしていないかどうかを確認します。

リファクタリングは、外部仕様は変更せず、コードの重複部分を排除したり、より理解しやすいコードにしたりするなどしてプログラムの内部構造を改善し、保守性を高めます。

JISではソフトウェアの品質特性について、次のような6つの品質特性を定めています。

品質特性内容
機能性使用目的な要件に従って正しく動作すること
使用性利用者にとって理解、習得、操作しやすいこと
信頼性必要なときに使用でき、故障時には速やかに回復できること
効率性応答時間や処理時間など求められる性能が備わっていること
保守性修正のしやすいこと
移植性ある環境から他の環境へ移しやすいこと

今回のまとめ&確認問題

今回のまとめ&確認問題

テスト手法については上記内容で以上となります。

それではまず今回の内容をまとめていきましょう。

まとめ

  • テストの目的は、バグを発見すること
  • ソフトウェアユニットテストは、モジュール単位で行うテスト
  • ソフトウェア結合テストは、モジュール同士を結合して行うテスト
  • ソフトウェア適格性確認テストは、ソフトウェア適格性要件に従って行うテスト
  • システム結合テストは、システム方式設計で定義したテスト仕様に従って行う
  • システム適格性確認テストは、実際に実務で使うデータや処理されるデータを使って行うテスト
  • 導入~受け入れテストは、本番疑似環境へ導入し問題点を発見するテスト
  • ソフトウェア保守は、稼働中のソフトウェアに対し発見された障害を是正したり、新しい機能の拡張などを行う

今回の確認問題「アウトプット用」

確認問題

システム確認問題-⑤

「次へ」で問題スタート!

①解説

【問題①】

ブラックボックステストに関する記述として、適切なものはどれか。

:テストデータの作成基準として、命令や分岐の網羅率を使用する。
不正解× ホワイトボックスの説明
:被テストプログラムに冗長なコードがあっても検出できない。
不正解◯ ブラックボックステストではプログラムの内部構造に着目しないため適切。
:プログラムの内部構造に着目し、必要な部分が実行されたかどうかを検証する。
不正解× ホワイトボックスの説明
:分岐命令やモジュールの数が増えると、テストデータが急増する。
不正解× ホワイトボックスの説明

【解説】

ブラックボックステストは、モジュールの内部構造を考慮することなく、仕様書通りに機能するかどうかをテストします。

プログラマーが設計者の意図した機能を実現しているかどうかを確認するテストです。このテストでは、主にプログラム開発者以外の第三者が実施します。

つまり答えは「」となる。

②解説

【問題②】

整数1~1,000 を有効とする入力値が、1~100 の場合は処理Aを、101~1,000の場合は処理B を実行する入力処理モジュールを、同値分割法と限界値分析によってテストする。次の条件でテストするとき、テストデータの最小個数は幾つか。
〔条件〕
①:有効同値クラスの1クラスにつき、一つの値をテストデータとする。ただし、テストする値は限界値でないものとする。
②:有効同値クラス、無効同値クラスの全ての限界値をテストデータとする。

:5 不正解×
:6 不正解×
:7 不正解×
:8 正解◯

【解説】

「同値分割法」と「限界値分析」が使われるテスト手法はブラックボックスです。

同値分割

有効値と無効値のグループに分け、それぞれのグループの代表的な値をテストデータとする。

限界値分析

有効値と無効値の境界となる値とテストデータとする。

例えば、100点満点の試験の結果のデータを扱った場合

同値分割法では、マイナスの点数50 点,100以上の点数をテストデータとして選ぶ。また、限界値分析では0点,1点,100点,101点を選ぶ。

この問題では、条件①で「①有効同値クラスの 1 クラスにつき,一つの値をテストデータとする。 ただし,テストする値は境界値でないものとする」とあるため、

  • 同値分割法では「50、500
  • 境界値分析では「0 、1 、100 、101、1000、1001

このテストデータから、どれか1つでも減らしてしまうと設問の条件を満たせなくなるため、テストケースの最小個数は「8」となります。

つまり答えは「」となる。

③解説

【問題③】

階層構造のモジュール群から成るソフトウェアの結合テストを、上位のモジュールから行う。この場合に使用する、下位モジュールの代替となるテスト用のモジュールはどれか。

:エミュレータ
不正解×:命令プログラムを解読しながら実行するマイクロプログラム
:シミュレータ 
不正解×:実の事象や業務をモデル化して模擬試験を行う装置やプログラム
:スタブ
正解○
:ドライバ
不正解×:上位モジュールの代替となるテスト用モジュール

【解説】

ソフトウェア結合テストにおいて、未完成のモジュールの代わりに接合されるテスト用モジュールに「スタブ」と「ドライバ」があります。

スタブ

トップダウンシテストにおいて、下位のモジュールが完成していない場合、テスト対象のモジュールからの呼び出し命令の条件に合わせて値を返すダミーモジュールの「スタブ」が必要となります。

ドライバ

ボトムアップテストにおいて、上位のモジュールが完成していない場合、テスト対象モジュールに引数を渡して呼び出すダミーモジュールの「ドライバ」が必要です。

問題では下位モジュールの代替となるものが問われています。つまり答えは「」となる。

最後まで読んでいただきありがとうございました!

今回の内容が、役に立ったな!と思ったらシェア&ブクマ登録よろしくお願いします。

また、質問や問い合わせに関しては、コメント欄かお問い合わせフォームを活用ください。

それではまたお会いしましょう。

黄島 成

-システム
-