2.1 ソフトウェア開発モデル ★★
2.1.1 V字モデル(シーケンシャル開発モデル)
- ウォーターフォールモデル
- 「分析」「設計」「実装」「テスト」という順に開発が進む。
- V字モデル
- ウォーターフォールモデルの上流と下流を対応付けて、アルファベットのVの字で表したもの。
- 左半分が品質を作りこむ工程、右半分が品質を確認する工程。
- テストレベル
- V字モデルのテスト工程は以下4段階
- コンポーネントテスト(ユニットテスト)
- 統合テスト
- システムテスト
- 受入テスト
- V字モデルのテスト工程は以下4段階
- ウォーターフォールモデルの欠点
- 手戻りに弱い
- 変更に弱い
- ソフトウェア開発での成果物
- 上流工程で作成した成果物(ビジネスシナリオ、ユースケース、要求仕様、設計書、コードなど)がテスト設計をする際のベースになる。
2.1.2 イテレーティブ – インクリメンタル開発モデル
ウォーターフォールモデルの問題を解消するためのモデルの一つ。
- イテレーティブ – インクリメンタル開発
- ウォーターフォールモデルのサイクルを何度か繰り返す。1回の繰り返しをイテレーションという。
- プロトタイピング
- 要件定義の段階でソフトウェアのプロトタイプを作成し、ユーザからのフィードバックをもとに仕様を確立した後で、本番開発を行うソフトウェア開発モデル。
- RAD(Rapid Application Development)
- 迅速にソフトウェアを作り上げる手法。
- RUP(Rational Unified Process)
- IBMが提唱する開発方法論。UML(Unified Modeling Language)を用いて設計を行い、スパイラル型で開発する。
- アジャイル開発モデル
- 無駄な作業を省いて短期間で開発するプロセス。その代表にXP(eXtreme Programming)やScrumがある。
- XPには12のプラクティスがあり、その中の一つに「テストファースト」がある。ユニットテストは以下のようにすすめる。
- テストケース設計／テストコード作成⇒ユニットテスト実行⇒ソースコードの実装⇒ユニットテストがすべて成功するまで繰り返し
2.1.3 ライフサイクルモデルの中のテスト
良いテストを実施するときには、以下のような特徴がある。
- 各開発活動に対応してテスト活動がある
- 各テストレベルには、そのレベル特有の目的がある
- テストレベルのテスト分析や設計は、対応する開発活動を実施している間に実施すべきである
- テストベースは早期にレビューを行う
2.2 テストレベル ★★
各テストレベルで押さえておくべき事柄は以下。
- 一般的な目的
- テストベース(テストケースを導き出す場合に参照する開発成果物)
- テスト対象
- テストで見つかる典型的な欠陥や故障
- テストツールの必要性
- ツールによる環境
- 特定のアプローチ
- 責任割り当て
多くの組織で使われている4つのレベルについて解説する。
2.2.1 コンポーネントテスト ★★
単体テスト、ユニットテスト、モジュールテスト、プログラムテストとも呼ばれる。
| 一般的な目的 | テスト対象の欠陥を摘出するため |
| テストベース |
|
| テスト対象 |
|
| テストツール |
|
| ツールによる環境 |
|
| テストの種類 |
|
| 欠陥の扱い |
|
| 特定のアプローチ |
|
| 責務割り当て |
|
2.2.2 統合テスト ★★
大きく分けて以下2種類。
- コンポーネント間、またはシステム間のインターフェース
- テスト対象となるソフトウェアと、OS、ファイルシステム、ハードウェアなどシステムの別の部分との相互処理
| 一般的な目的 |
|
| テストベース |
|
| テスト対象 |
|
| テストレベル |
|
| テストの種類 |
|
| 特定のアプローチ |
|
| 責務割り当て |
|
2.2.3 システムテスト ★★
システムのスコープ全体をテストするもの。システムやソフトウェアプロダクトの振る舞いをテストする。
| 一般的な目的 | 指定された要件を満たすことを実証するため |
| テストベース |
|
| テスト対象 |
|
| テスト環境 | 運用と同等の環境 |
| テストの種類 |
|
| テスト技法の例
※主にブラックボックス技法を用いるが、一部ホワイトボックス技法を用いる。 |
|
| 責務割り当て |
|
開発環境で実行することはない。環境関連の故障を検出するため。ステージング環境。
2.2.4 受け入れテスト ★★
システムが稼働できるかどうかをテストする。最後のテストである必要はない。
| 一般的な目的 |
|
| テストベース |
|
| テスト対象 |
|
| テストの種類 |
|
| 責務割り当て |
|
欠陥の摘出を目的とすることはない。また、リリース直前だけでなく、以下のような様々な場面で行われる。
- 市販ソフトウェアプロダクト(COTS)
- インストールや開発しているソフトウェアとの統合時点で受入テストを実施する。
- コンポーネントのユーザビリティの受入テスト
- コンポーネントテストで実施する。
- 新機能の拡張分の受入テスト
- システムテスト前に実施。
受入テストは通常以下のような種類がある。
- ユーザ受入テスト
- 契約による受入テスト
- 規定による受入テスト
- 法律や安全基準などに合致しているか
- アルファテスト、ベータテスト(フィールドテスト)
2.3 テストタイプ ★★
特定のテストの目的に焦点を合わせたもの。ソフトウェアの機能だけでなく、信頼性や使用性といった非機能要件をテストすることもある。また、欠陥が修正されていることを確認するテストや、意図しない変更がないことを確認するテストもある。以下でテストタイプの基本的な概念を確認する。
2.3.1 機能のテスト(機能テスト) ★★
機能：何をするのか(What)であり、どのようにするのか(How)ではない。
機能が仕様通りに実装されているかどうかを検証する。
・機能の表現方法とテスト
機能を表現したドキュメントは、要求仕様書、ユースケース、機能仕様書など様々ある。
ドキュメントがある場合は、ドキュメントの記載内容に基づいて行う。
ドキュメントがない場合は、テスト担当者が理解している事柄に基づいてテストする。
・機能テストの適用対象
機能はシステム、サブシステム、コンポーネントといった様々なレベルで表現される。すなわち機能は階層構造を持つため、機能テストはそれぞれのレベルで実施する必要がある。
・機能テストのモデル
プロセスフローモデル、状態遷移モデル、自然言語で記述した仕様などのソフトウェアモデルを用いることがある。
・使用できる技法
ソフトウェアの外部動作を検証するため、ブラックボックステストに分類される仕様ベースのテスト技法を使うことができる。
仕様ベースのテスト技法とは、同値分割法、境界値分析、デシジョンテーブルテスト、状態遷移テストなどがある。※第四章参照
・機能テストの例
セキュリティテストを例とすると、テスト対象にセキュリティ機能が実装されているかどうかをテストする。
例えば、外部から悪意ある脅威や攻撃を検知する機能が仕様通りに動くかどうかをテストする。
2.3.2 機能以外の特性のテスト(非機能テスト) ★★
非機能：どのようにするのか(How)であり、何をするのか(What)ではない。
コンポーネントやシステムで機能に関係しない特性を検証するのが非機能テストである。
・非機能の表現とテスト
テストに使用できる非機能の表し方は、計測可能な項目(例えば応答時間など)を定めること。非機能テストでは、定量的に特定した項目を計測して数値化し、それを評価する。
機能以外すべてが対象なので、性能テスト、ロードテスト、ストレステスト、ユーザビリティテスト、相互運用性テスト、保守性テスト、信頼性テスト、移植性テストなど様々ある。
- 性能テスト(performance testing)
- ソフトウェア製品のパフォーマンスを判定するためのテスト
- パフォーマンス：システムやコンポーネントが、処理時間やスループットの制約内で、定義した機能を果たす度合い。
- ロードテスト(load testing)
- コンポーネントやシステムの動作を測定するテスト。負荷(並列実行ユーザ数やトランザクション数など)を増加させ、コンポーネントやシステムがどの程度の負荷に耐えられるかを判定する。
- ストレステスト(stress testing)
- 要件で定義した限界、またはそれを超えた条件で、システムやコンポーネントを評価するテスト。
- ユーザビリティテスト(usability testing)
- ソフトウェア製品が指定された条件下で理解され、学びやすく、使用しやすく、ユーザにとって魅力的である能力を判定するテスト。
- 相互運用性テスト(interoperability testing)
- 相互運用性：1つ以上の指定されたコンポーネントやシステムと情報を交換できるソフトウェア製品の能力のこと。
- 保守性テスト(maintainability testing)
- 保守性：ソフトウェア製品の変更の容易さ。変更には、欠陥の修正、新しい要求を支援するための変更、将来の保守性を上げるための変更、稼働環境の変更に対応する変更などがある。
- 信頼性テスト(reliability testing)
- 信頼性：あらかじめ決めた運用回数、または、指定した期間、決められた条件下で、必要な機能を果たせるソフトウェア製品の能力。
- 移植性テスト(portability testing)
- 移植性：ソフトウェア製品を別のハードウェア環境やソフトウェア環境に対して容易に移植できる度合い。
・非機能テストの適用対象
システムテストレベル、受入テストレベルで実施するものと思われがちだが、コンポーネントテストレベル、統合テストレベルにおいても実施できる。
・非機能テストのモデル
パフォーマンスモデル、ユーザビリティモデル、セキュリティ脅威モデルなどのソフトウェアモデルを用いることがある。
・使用できる技法
ソフトウェアの外部動作を検証するため、ブラックボックステストに分類される仕様ベースのテスト技法を使うことができる。
・品質特性(ISO/IEC 9126)
非機能テストを実施する場合、ISO/IEC 9126の品質モデルを参照することができる。
2.3.3 ソフトウェアの構造／アーキテクチャのテスト(構造テスト) ★★
構造とは、コンポーネント呼び出しの上下関係のようにシステムのアーキテクチャと関わる。構造をどの程度網羅したかで評価するのが構造テストである。
・構造の表現方法とテスト
構造を視覚化したドキュメントには、制御フローグラフ、コールフローダイアグラム、画面遷移図などがある。
構造テストでは、一般的にドキュメントに有無にかかわらずツールを用いてテストを行うが、ドキュメントを用いてどの程度網羅したかを評価することもできる。
構造テストは、機能テストつまり仕様ベースのテストを実施し、機能テストで構造をどの程度網羅したかを計測した後で、構造に対する網羅性を上げるために実施すると良い。
・構造テストの適用対象
コンポーネントテストレベル、統合テストレベルで実施されると思われているが、システムテストレベル、受入テストレベルにおいても実施することができる。
コンポーネントテストやコンポーネント統合テストでは、ツールを使ってコードのカバレッジを計測する。システムテスト、システム統合テスト、受入テストでは、メニュー構造やビジネスモデルのカバレッジなどを計測する。
・構造テストのモデル
制御フローモデルやメニュー構造モデルなどのソフトウェアモデルを用いることがある。
・使用できる技法
構造テストでは、用意したテストスイート(テストケースのセット)を実行した結果、ソフトウェアの構造の何%をカバーしたか検証する。そのため、ホワイトボックステストに分類されるコードカバレッジ技法を使うことができる。
コードカバレッジには、ステートメントカバレッジやデシジョン(ブランチ)カバレッジなどがある。※第四章参照
・構造テストの例
カバレッジが100%でない場合、実行していない部分をテストするために、未実行部分を通るテストを設計してカバレッジを上げるようにする。
2.3.4 変更部分のテスト：再テスト、および回帰テスト ★★
欠陥を修正した後には再テストを実施する必要がある。この再テストには以下2種類がある。
- 確認テスト：欠陥部分が正しく修正されているかどうかを確認するテスト
- 回帰テスト：新たに作りこんだ欠陥がないこと、および他への影響が無いことを確認するテスト
・確認テスト
欠陥を修正した後、この欠陥に起因する故障が再現しなくなることを確認するためのテスト。デバッグと間違いやすいので注意が必要。
・回帰テスト
すでにテストしたソフトウェアを何度もテストする。テスト実施済みのソフトウェアを再度テストすることにより、変更によって作りこんだ欠陥を見つけ、修正によって引き起こされる別の欠陥を発見することが目的。
この欠陥は修正したコンポーネントから見つかるだけでなく、まったく別のコンポーネントの故障となって現れる場合もあるため、回帰テストの実施範囲が重要な意味を持つ。実施範囲は、正常に動いていたソフトウェアに欠陥があった場合のプロダクトリスクをもとに決定する。
・回帰テストの適用対象
すべてのテストレベルに適用可能。また、機能テスト、非機能テスト、構造テストの中に取り込んで行うこともできる。テストスイートは何度も実行し、テストの内容に応じて少しずつ内容を変えるので、自動化による効果が期待できる。
2.4 保守テスト ★★
開発が終了したあとの保守の段階で実施するテストについて確認する。
2.4.1 保守テスト ★★
あらかじめ計画していた機能追加のようなリリースと、欠陥に対する修正パッチの提供のような突発的なリリースとを区別することは、保守テストを成功させるためのポイントとなる。
保守テストを行わなければならないケースには、以下のようなものがある。
- ソフトウェアの変更作業を行ったとき
- ソフトウェアの動作環境が変わったとき
- 新しい環境への移行作業を行ったとき
- システムの入れ替え(回収作業)を行ったとき
2.4.2 回帰テスト ★★
自動テストと主導テストをバランスよく実施することが現実的な方法といえる。
2.4.3 影響度分析 ★★
あるモジュールや機能を変更する前に、ほかのどのモジュールや機能と関連性があるかをチェックすることで、既存のモジュールや機能への影響範囲が分かる。これを影響度分析と呼び、回帰テストの範囲を見極め、テストの量を予測できる。
ただし、影響度分析を行うには、既存システムの最新の状態に対する変更の影響を分析する必要がある。現実的には、「保守作業の40~60%程度の保守工数は改変すべきソフトウェアの理解のために割かれている」というデータもあり、保守テストは困難なものとなっている。
Follow me!
