システム開発のテスト工程で重要な事とは?
公開日: 2022/7/18
更新日: 2022/7/18
システム開発では、不具合やバグが無いかを検証するテスト工程と呼ばれる期間が存在します。
テスト工程には大きく分けて下記4つのテスト内容が存在します。
・単体テスト・・画面や機能ごとに、動作の検証をする
・結合テスト・・他の機能やシステムと連携させて、動作の検証をする
・総合テスト・・本運用を想定して、システム全体の動作を検証する
・ 受入れテスト・・納品前に仕様書の通り完成しているか確認する
システム開発におけるテストの役割は、開発したシステム、記述したプログラムが不具合なく動作するか、バグなどがないかをチェックして修正する工程のことを指します。
どれだけ優秀なエンジニアが開発していようと、人の手が介在するシステム開発では、バグがないということは絶対にあり得ません。
たとえば、システム開発の現場でもっともポピュラーな開発の流れの「ウォーターフォール型」を採用している場合、「単体テスト」「結合テスト」「システムテスト(総合テスト)」「受け入れテスト(ユーザーテスト)」の、大きく4つのテスト工程が実施されます。
テスト工程には大きく分けて下記4つのテスト内容が存在します。
・単体テスト・・画面や機能ごとに、動作の検証をする
・結合テスト・・他の機能やシステムと連携させて、動作の検証をする
・総合テスト・・本運用を想定して、システム全体の動作を検証する
・ 受入れテスト・・納品前に仕様書の通り完成しているか確認する
システム開発におけるテストの役割は、開発したシステム、記述したプログラムが不具合なく動作するか、バグなどがないかをチェックして修正する工程のことを指します。
どれだけ優秀なエンジニアが開発していようと、人の手が介在するシステム開発では、バグがないということは絶対にあり得ません。
たとえば、システム開発の現場でもっともポピュラーな開発の流れの「ウォーターフォール型」を採用している場合、「単体テスト」「結合テスト」「システムテスト(総合テスト)」「受け入れテスト(ユーザーテスト)」の、大きく4つのテスト工程が実施されます。
1. なぜ各工程に分かれているのか?
テスト工程が複数存在していることはわかりましたが、何故テスト工程は分かれているのか?
理由は下記のとおりです。
①設計時にシステムを細かいモジュールに分解し、プログラムごとに開発を進める
②テスト工程ごとに目的・重要性が異なる
具体的な手法とともに、それぞれのテスト工程における目的・重要性を解説していきましょう。
2. 単体テスト
単体テストとは、分割されたモジュール(部品を集めて機能を持たせたもの)やプログラム単体ごとに実施するテストのこと。
構成単位(Unit)ごとに実施されるため、開発現場によってコンポーネントテスト、ユニットテストと呼ばれる場合もあります。
テストの知識に長けている選任のテスターが担当する場合もありますが、基本的にはプログラミング作業を担当したシステムエンジニアが単体テストを実施するケースが多いです。
そのため、単体テストではプログラム内部に着目した「ホワイトボックステスト」という手法を中心にしたテストが行われます。
ホワイトボックステストとは、開発されたプログラムが設計通りの処理を実現できるか? などを網羅的に検証するテストのこと。
あくまでもプログラムの内部構造や処理を検証するテストであることから、設計時の仕様が正しいかどうかを検証するものではありません。
具体的には、プログラムに記述されている「条件」「条件の分岐」「分岐後の命令」などを確認する制御フローテスト、プログラム内で定義した変数・固定値が適切に使用されているか確認する、データフローテストなどが挙げられます。
構成単位(Unit)ごとに実施されるため、開発現場によってコンポーネントテスト、ユニットテストと呼ばれる場合もあります。
テストの知識に長けている選任のテスターが担当する場合もありますが、基本的にはプログラミング作業を担当したシステムエンジニアが単体テストを実施するケースが多いです。
単体テストの代表的な手法
単体テストでは、ユーザーインターフェースがない「ドライバ」など、一時的に制作されたプログラムをテストする場合が多いです。そのため、単体テストではプログラム内部に着目した「ホワイトボックステスト」という手法を中心にしたテストが行われます。
ホワイトボックステストとは、開発されたプログラムが設計通りの処理を実現できるか? などを網羅的に検証するテストのこと。
あくまでもプログラムの内部構造や処理を検証するテストであることから、設計時の仕様が正しいかどうかを検証するものではありません。
具体的には、プログラムに記述されている「条件」「条件の分岐」「分岐後の命令」などを確認する制御フローテスト、プログラム内で定義した変数・固定値が適切に使用されているか確認する、データフローテストなどが挙げられます。
3. 結合テスト
結合テストとは、単体テストの完了したモジュールが意図した通りに動作するかを検証するテストのことを指します。
こちらも多くの場合は、各プロジェクトごとに選任のテスターが担当しますが、プログラミングを担当したSEがテストする場合があります。
結合テストは、基本設計時に決定された「結合テスト仕様書」に従って実施されます。
仕様書を基にテストを実施するため、テストのスキルのほかに仕様書などのドキュメントを読み解く力などが要求されます。
結合テストの目的は、設計書通りに動作するか?不具合がないか?確認することです。
モジュール単体ではエラーが発生しなくても、組み合わせた場合に起こり得る、想定外のエラーを排除するためにも、結合テストは重要性の高い工程です。
また、外部システムなどを使用している場合は、システム内部の機能を検証する「内部結合テスト」以外に、外部システムとの連携を検証する「外部結合テスト」が実施される場合もあります。
テスト手法としては単体テストでも紹介した「ホワイトボックステスト」に加え、「ブラックボックステスト」を行うことが一般的です。
ブラックボックステストとは、結合されたサブシステムにデータを入力し、正しい出力データが返ってくるかを検証するテストのことを指します。
ホワイトボックステストと違う部分は、プログラムの内部構造は検証せず、サブシステムが仕様書通りに意図した動作をするか。を検証することです。
ブラックボックステストは、プログラムを「発注側・利用側の視点」に立って検証する、非常に重要なテストの1つといわれています。
ブラックボックステストを行うことで、プログラムの内部に着目した単体テストでは見逃してしまう、仕様の不備や設計ミスなどを探しだし、細かなミスに事前に気づけるというメリットがあります。
こちらも多くの場合は、各プロジェクトごとに選任のテスターが担当しますが、プログラミングを担当したSEがテストする場合があります。
結合テストは、基本設計時に決定された「結合テスト仕様書」に従って実施されます。
仕様書を基にテストを実施するため、テストのスキルのほかに仕様書などのドキュメントを読み解く力などが要求されます。
結合テストの目的は、設計書通りに動作するか?不具合がないか?確認することです。
モジュール単体ではエラーが発生しなくても、組み合わせた場合に起こり得る、想定外のエラーを排除するためにも、結合テストは重要性の高い工程です。
また、外部システムなどを使用している場合は、システム内部の機能を検証する「内部結合テスト」以外に、外部システムとの連携を検証する「外部結合テスト」が実施される場合もあります。
テスト手法としては単体テストでも紹介した「ホワイトボックステスト」に加え、「ブラックボックステスト」を行うことが一般的です。
ブラックボックステストとは、結合されたサブシステムにデータを入力し、正しい出力データが返ってくるかを検証するテストのことを指します。
ホワイトボックステストと違う部分は、プログラムの内部構造は検証せず、サブシステムが仕様書通りに意図した動作をするか。を検証することです。
ブラックボックステストは、プログラムを「発注側・利用側の視点」に立って検証する、非常に重要なテストの1つといわれています。
ブラックボックステストを行うことで、プログラムの内部に着目した単体テストでは見逃してしまう、仕様の不備や設計ミスなどを探しだし、細かなミスに事前に気づけるというメリットがあります。
4. システムテスト(総合テスト)
単体テストと結合テストが終了したら、システムテストというものを開始します。
システムテストとは、すべてのプログラムを結合し、システム全体として仕様書に記載の要件通りに動作するかを検証するテストのことを指します。
既に単体テストと結合テストは終わっているので、実質最終チェックのフェーズです。
システムテストでは、ユーザーが使う本番環境、もしくはそれを想定した環境にシステムを置き、実稼働と同様の負荷をかけて、機能・パフォーマンスに問題がないかを確認します。
これまでのテストとは異なり、システムテストでは選任のテスターが担当するケースがほとんどです。
サブシステムごとの機能検証は結合テストまででほぼ完了しているため、総合的に検証する「確認テスト」「評価テスト」「負荷テスト」などが実施されます。
確認テストで実施される主要な手法は以下の2つです。
・リグレッションテスト・・プログラムの修正が、ほかのプログラムへの不具合を起こしていないかを検証するテスト
・デグレードチェックテスト・・修正プログラムの不具合再発が発生していないか検証するテスト
・セキュリティテスト・・情報漏えいなど、セキュリティに関連する要件を満たしているか検証するテスト
・ユーザビリティテスト・・実際のユーザー側の視点に立って視認性や使いやすさを検証する
・障害許容性テスト・・障害発生時に稼働できるか検証
・負荷テスト・・システムに大きな負荷をかけて稼働させ、耐久性やパフォーマンスに問題が生じないかを確認・検証するテスト
実際に負荷テストで実施される主要な手法は以下の5つです。
・性能テスト・・仕様を満たす処理能力を発揮できるかを、システムに負荷をかけて検証するテスト
・ロングランテスト・・システムの稼働率・パフォーマンスを検証
・ストレステスト・・システムのストレス耐性を検証
・ロードテスト・・耐久性・パフォーマンスを検証するテスト
・キャパシティテスト・・データ量や同時アクセス数の増大にシステムがどのような挙動を示すかの確認・検証
システムテストとは、すべてのプログラムを結合し、システム全体として仕様書に記載の要件通りに動作するかを検証するテストのことを指します。
既に単体テストと結合テストは終わっているので、実質最終チェックのフェーズです。
システムテストでは、ユーザーが使う本番環境、もしくはそれを想定した環境にシステムを置き、実稼働と同様の負荷をかけて、機能・パフォーマンスに問題がないかを確認します。
これまでのテストとは異なり、システムテストでは選任のテスターが担当するケースがほとんどです。
システムテストの方法
上述したようにシステムテストでは、実稼働時と同様の負荷をかけても機能要件・非機能要件を満たせるか?開発したシステムを機能以外の部分を含めて総合的に検証します。サブシステムごとの機能検証は結合テストまででほぼ完了しているため、総合的に検証する「確認テスト」「評価テスト」「負荷テスト」などが実施されます。
確認テスト
各モジュール・サブシステムのテスト・修正を経て変更されたプログラムや、プログラム同士の連携に不具合がないか?正しい挙動を示しているかを検証するために実施されるのが、この確認テストです。確認テストで実施される主要な手法は以下の2つです。
・リグレッションテスト・・プログラムの修正が、ほかのプログラムへの不具合を起こしていないかを検証するテスト
・デグレードチェックテスト・・修正プログラムの不具合再発が発生していないか検証するテスト
評価テスト
評価テストとは、使いやすいか、セキュリティ面、障害時の耐性など、システムの性能を評価して検証するテストのことを指し、評価テストで実施される主要な手法は以下の3つです。・セキュリティテスト・・情報漏えいなど、セキュリティに関連する要件を満たしているか検証するテスト
・ユーザビリティテスト・・実際のユーザー側の視点に立って視認性や使いやすさを検証する
・障害許容性テスト・・障害発生時に稼働できるか検証
・負荷テスト・・システムに大きな負荷をかけて稼働させ、耐久性やパフォーマンスに問題が生じないかを確認・検証するテスト
実際に負荷テストで実施される主要な手法は以下の5つです。
・性能テスト・・仕様を満たす処理能力を発揮できるかを、システムに負荷をかけて検証するテスト
・ロングランテスト・・システムの稼働率・パフォーマンスを検証
・ストレステスト・・システムのストレス耐性を検証
・ロードテスト・・耐久性・パフォーマンスを検証するテスト
・キャパシティテスト・・データ量や同時アクセス数の増大にシステムがどのような挙動を示すかの確認・検証
5. まとめ
システム開発には、開発以外にも重要なテスト工程が存在しています。
これもシステム開発を行う上では重要な役割なので、積極的に行っていきましょう。