システム開発におけるテストは、プログラムの機能や品質をチェックする大切な工程です。開発中のさまざまな段階でテストを行うことで、納品前にシステムの不具合やバグを修正できます。今回は、システムテストについて詳しく知りたい方向けに、システム開発におけるさまざまなテストの手法やテストの流れを詳しく解説します。
システム開発におけるテストとは？
システムテストは、開発したシステムが要件通りに動作するかどうかを検証するテストです。本番に近い環境を構築し、開発者・ユーザー双方の目線から品質や不具合の有無をチェックします。これらのテストは、さまざまな手法を用いて多角的に行われます。
システム開発で行う4つのテストを解説
システム開発では、開発段階ごとに4つのテストを実施します。
単体テスト
単体テストは、システム内の最小単位である関数やモジュールを対象としたテストです。開発の初期段階で行うテストで、各部品が設計通りに動作するか、バグが発生しないかを確認します。単体テストの時点で不具合を修正することで、後の工程での不具合を最小限にとどめられます。
結合テスト
結合テストは、複数のプログラムやモジュールを組み合わせた状態で動作を確認するテストです。単体テストをクリアした後に行うテストで、モジュール間のデータ連携やインタフェースに問題がないかを確認します。単体では問題なく動作するシステムが結合した際に起こるバグを検出することができます。
システムテスト
システムテストは、システム全体が要件通りに動作するかどうかを検証するテストです。総合テストとも呼び、選任のテスターが納品前の最終確認として行います。システムテスト仕様書をもとに、ユーザーの操作を想定した一連の機能・負荷への対応・セキュリティ・エラー発生時の処理などを検証します。
受け入れテスト
受け入れテストは、クライアント側が実施する品質テストです。ユーザーテストとも呼び、システムテストを経て納品されたシステムが指定の要件やパフォーマンスを満たしているかどうかを総合的に判断します。システム開発の最終工程であり、実際の運用環境に近い条件で行われます。
実施目的別に整理したテストの種類
システムテストは、目的ごとのさまざまなテスト方法を組み合わせて構成されています。
機能テスト
機能テストは、システム設計通りにプログラムが動作するかを確認するテストです。本番と同等の環境でシステム機能全体を検証し、不具合の有無をチェックします。
性能テスト
性能テストは、システムの処理速度や応答時間などを条件ごとに測定するテストです。実際の環境を想定し、さまざまな状況で滞りなく性能が維持できるかを客観的に評価します。
ユーザビリティテスト
ユーザビリティテストは、システムの操作性や視認性を実際のユーザー目線に立って確認するテストです。開発者ではなくエンドユーザーがテストを行い、システムの機能や性能の潜在的な課題点を収集します。
セキュリティテスト
セキュリティテストは、不正アクセスや情報漏洩のリスクをチェックするテストです。システムにおけるセキュリティ対策が充分に行われているか、脆弱性がないかを開発段階で検証します。
リグレッションテスト（回帰テスト）
リグレッションテストは、すでに修正済みの不具合箇所が正しく修正できているかを確認するテストです。単体テスト・結合テスト・システムテストの各フェーズで発生したエラーの修正後にチェックを行います。
構成テスト（機種テスト）
構成テストは、パソコンのOSやブラウザ、タブレットやスマートフォンの端末ごとの動作を確認するテストです。機種テストとも呼び、さまざまな条件下でシステムが問題なく動作するか、環境依存によるバグがないかを確認する目的があります。
シナリオテスト
シナリオテストは、ユーザーが実際にシステムを操作する際に、システム全体の動作や連携に問題がないかを確認するテストです。想定される操作手順をもとに用意したシナリオを用いて検証を行います。
ロングランテスト
ロングランテストは、システムを長時間稼働させた際の性能の低下や不具合の有無を確認するテストです。一定時間システムを連続して稼働させ、パフォーマンスに問題がないかを検証します。
負荷テスト
負荷テストは、システムに本番環境下で想定される負荷をかけ、処理速度や応答時間に問題がないかを検証するテストです。アクセスが集中した際にシステムがスムーズに動作するかを確認します。
ストレステスト・高負荷テスト
ストレステスト（高負荷テスト）は、システムに極端な負荷をかけた際に耐久できるかどうかを検証するテストです。短時間に多数の処理を行ったりシステムに大容量のデータを送信したりし、動作を確認します。
耐障害テスト
耐障害テストは、障害発生時を想定したテストです。万が一の際に最低限のサービスを継続できるか、自動での復旧が可能か、データの回復ができるかなどを検証します。
システムテストの流れと役割分担
システムテストはテスト計画・環境構築・テスト実行・テスト分析の4段階に分かれており、各工程ごとにさまざまな技術者が関わっています。
テスト計画・設計
はじめに、テストの目的・テスト対象範囲・スケジュールなどを定義した「システムテスト計画書」を作成します。計画書が完成したら、それをもとに実際のテスト内容を明記した「システムテスト仕様書」を作成します。仕様書には、テストの項目・評価基準・テストを行う担当者などの詳細を定める必要があります。
テスト環境の構築
システムテスト計画書とシステムテスト仕様書が定まったら、これらに基づいてテスト用のシステム環境・データベース・ネットワーク環境などを整備します。テスト環境は、ユーザーが使用する環境にできるだけ近づけることが重要です。
テスト実行
構築したテスト環境の下で、システムテスト仕様書に沿ってテストを実行します。テスト結果と評価基準を照らし合わせ、不具合が見つかった場合は修正と再検証を繰り返します。最終的に全ての箇所で仕様書どおりにシステムが動作するようになったら、テスト終了です。
テスト分析
テストが終了したら、システムの品質評価やテスト結果の分析を行い、課題点や改善点がないかを確認します。システム全体に問題がなければ、クライアントへ納品されます。
開発モデルとテスト方法の違い
システム開発にはV字モデルとW字モデルの2種類の開発モデルがあり、それぞれテストを行うタイミングが異なります。
V字モデル
V字モデルは、開発工程を終えてからテスト工程に移行する開発モデルです。開発工程とテスト工程の流れを表した際に、V字のように見えることから名付けられました。
詳細設計と単体テスト、基本設計と結合テストなどと各開発工程とテスト工程が対になっており、大規模な開発に適しています。
| 開発工程 | テスト工程 |
|---|---|
| 1. 要求分析 | ⇆8. 受け入れテスト |
| 2. 要件定義 | ⇆7. システムテスト |
| 3. 基本設計 | ⇆6. 結合テスト |
| 4. 詳細設計 | ⇆5. 単体テスト |
W字モデル
W字モデルは、開発工程とテスト工程を同時並行で行う開発モデルです。開発工程とテスト工程の流れを表した際に、W字のように見えることから名付けられました。
W字モデルは開発工程の各フェーズで細かいレビューやテスト設計が行われるため、不具合を随時修正できるのが利点です。
| 開発工程 | テスト工程 | 開発工程 | テスト工程 |
|---|---|---|---|
| 1. 要件定義 | →2. システムテスト設計・受け入れテスト設計・レビュー | 11. システムテスト・受け入れテスト | ⇄12. デバッグ・修正 |
| 3. 基本設計 | →4. 結合テスト設計・レビュー | 9. 結合テスト | ⇄10. デバッグ・修正 |
| 5. 詳細設計 | →6. 単体テスト設計・レビュー | 7. 単体テスト | ⇄8. デバッグ・修正 |
システムテストのその他の分類
システムテストは、それぞれの手法によってさらに分類できます。
機能テスト・非機能テスト
機能テストは、システムが仕様どおりに正しく動作するかを確認するテストです。機能テスト・リグレッションテスト・構成テストなどが該当します。
非機能テストは、システムの機能以外の部分をチェックするテストです。性能テスト・ユーザビリティテスト・セキュリティテスト・負荷テストなどがこれにあたります。
ホワイトボックステスト・ブラックボックステスト
ホワイトボックステストは、システムの内部構造を認識した状態で行うテストです。プログラムのコードを見ながら、内容に問題がないかを確認します。
ブラックボックステストは、システムの内部構造を知らない状態で行うテストです。外部仕様書とシステムを照らし合わせ、「この動作をすればこの画面に遷移するだろう」といった推測をしながら操作性を確認します。
ホワイトボックステストは開発者目線、ブラックボックステストはユーザー目線でシステムを検証するのが大きな違いです。
動的テスト・静的テスト
動的テストは、実際にシステムプログラムを実行しながら動作を確認するテストです。単体テスト・結合テスト・システムテストは、すべてこれにあたります。
静的テストは、システムを動かさずに、コードや設計書の内容をレビューするテストです。コーディングのミスや設計上の欠陥がないかを探し、問題点を早い段階であぶり出す狙いがあります。
手動テスト・自動テスト
手動テストは、人間の手によって行われるテストです。手間はかかりますが、ユーザー目線に立ってテストを行えるため、さまざまな問題点に気付けます。
自動テストは、事前にテスト用のスクリプトやツールを組み、それをコンピューターに実行させるテストです。連続テストや大量データの処理に適しており、手動テストより効率的です。
スクリプト型テスト・非スクリプト型テスト
スクリプト型テストは、事前にテスト計画や手順書を準備してから行うテストです。テストの条件や考えられる結果などを事前に洗い出しておくことで、システム全体を網羅的に検証できます。
非スクリプト型テストは、事前準備を行わず、テスター個人の知見や経験をもとに行うテストです。スクリプト型テストに比べて再現性が低いものの、事前に予想できていなかった不具合が見つかる可能性があります。
まとめ
スムーズなシステム開発には、各工程での適切なテストが必要不可欠です。さまざまな観点からテストを行うことで、高品質なシステムを作り上げられます。
Sun Asteriskでは、DXコンサル・設計から本格的な開発までを一気通貫でサポートしています。プロジェクトにおける効率的なリソース配分を行いたい方は、ぜひご利用ください。
WBS（Work Breakdown Structure）について、基本の解説と、作成方法を具体的にご紹介いたしました。
ラボ型オフショア開発のパートナーをお探しなら。Sun*ベトナム開発チームの強みや実績をまとめた資料を無料でダウンロード。1,000名超の体制でPoCからグロースまで支援します
