ソフトウェアテストを学ぶ　その６．システムテストについてもっさり書いてみた

こんちは。太郎ふっくらです。

今回はシステムテストについて「もっさり」勉強したいと思います。

テストのこと。

システムテストは「システムの要求仕様に基づき製品が正しく作られていること」を確認するテストで、結合テスト終了後に実施する。

単体・結合テストでは、プログラム仕様や詳細設計に基づき、ソフトウェアが正しく動作することをテストしてきたが、システムテストでは、要求通りソフトウェアが作られ、製品が動くことをテストする。

前段のテストは「仕様の検証」が目的で、システムテストは「仕様の検証」と「仕様の妥当性」確認がテストの目的。

これまでのテスト (単体・結合テスト) は開発担当者がテストをしてきたが、システムテストはテスト担当者や、開発と独立したテストチームがテストを担当する。

テスト担当者やチームが担当する理由は・・・

ソフトウェア開発工程に携わっていない第三者が検証することで、開発者が気付かない問題を検出できる。
類似製品やシステムを検証した経験を活かしたテストが行える。
テスト専門のエンジニア・チームが入ることで様々な種類のテストを実施できる。
システムテストで検出される欠陥は、システム結合状態で検出されることや、性能や負荷等の非機能要件に関する問題も含まれる。そのため、原因特定や修正が、単体・結合テストに比べ困難である。テスト作業と開発作業を分業することで、開発担当者は修正作業に注力でき、効率的に作業ができる。

などが挙げられる。

システムテストでは、基本設計書をもとに「機能要件」と「非機能要件」をテストする。

ソフトウェアで実現する全ての機能。「機能テスト」を実施して確認する。

ソフトウェアの機能に関係ない特性。性能であったり、負荷耐性や堅牢性など。

システムテストでは、非機能要件を下表のように計測できるように項目化して、評価する。

(ここで挙げているのは非機能要件の一例。他にも色々ある)

非機能要件	システムテストで評価する方法
性能	機能実行時の処理時間、応答時間を計測し、期待した時間内に処理が完了するか評価する。
負荷	運用負荷が発生するデータ状態、運用フローをシナリオ化して、テストを行い、問題無くシステムが動作することを評価する。
堅牢性	Webアプリケーションやネットワーク脆弱ツールを用いてテストを行い、検査項目に全てパスすることを確認する。

確認する要件ごとにテスト手法・技法を使い分けて確認する。

画面遷移や運用フローの確認は、ホワイトボックステストを用いて確認する。

※ブラックボックステストとホワイトボックステスト両方を用いてテストすることを「グレーボックステスト」と呼ぶこともある。

機能テストは、「デシジョンテーブル」と呼ばれるテスト技法を用いる。

デシジョンテーブルは、ソフトウェアが仕様通り動作することを確認するためのテスト技法で、システムテストでは、仕様や運用条件を組み合わせてテストする。

操作画面の遷移やシナリオテスト (運用フローの確認) は、ホワイトボックステストを用いる。

ステートメントテストと呼ばれるテスト技法を用いて、画面遷移パターンや、運用フローをテストする。

システムテストは運用と同等の環境化でテストする。

つまり、製品と同じハードウェアを使用したり、運用時に用いるデータを使用してテストする。

システムテストは運用環境化でテストを行うため、運用環境と異なる環境化でテストを実施しても意味がない。環境の設定ミス等が無いように、環境構築マニュアル等の作成が重要。
システムテストは単体・結合よりもスケジュール調整が難しい。なぜなら、ソフトウェアだけでは無く、ハードウェアや試験環境の調達・スケジュール調整が影響するため。事前にどれだけ調整できるかが、システムテストの成否を決める。
システムテストはテスト担当者、テストチームが担当する。ここで問題になるのは、インシデントレポート (障害票・不具合票)。欠陥が発生した際のモジュールや発生条件、再現手順など、開発者が調査・修正を行う上で必要な情報を事前に開発者と決めておかなければならない。また、欠陥修正のタイミングや、テスト対象プログラムのリリースタイミング、再テストのテストフロー等の情報共有も重要。

システムテストはシステムやソフトウェアの振る舞いをテストする工程で、仕様の確認だけでは無く、要求と仕様の整合性も確認する。
システムテストはテスト担当者やテストチームが開発と独立してテストする。
システムテストは機能要件と非機能要件をテストする。テスト方法は、ブラックボックステストとホワイトボックステストを用いたグレーボックステストを使用する。
システムテストは運用と同等環境でテストする。
システムテストは単体・結合テスト以上にスケジュール調整、部材調達が難しく、早め早めの調整が重要。また、開発者とテスト担当者・チーム間でテストについての情報共有ができる仕組み作りも大切。(これは心底思う)