テストの観点をどう決めるか
テスト仕様書を作るには最初のどのような観点でテストを行なうかのテストの観点を決める必要があります。テストの観点をどう決めるのかはテストの質を決定する重要なものです。ただテストの観点といっても何がテストの観点となるのかが分かりにくいものです。
テストの観点については「テスト分析とテストの観点３０選」の記事で取り上げたことがあります。このときにあげたテストの観点は、どちらかといえばエラー推測テスト向けの観点が多くを占めていました。今回はより一般的なテストの観点をあげることにします。
その前にテストの観点に関係する事柄について今一度明確にしておきましょう。
テスト設計の前には「テスト分析」が必要となります。
テスト分析とは、「テスト対象」について「テストの観点」を抽出することです。
テスト対象とは、テストによってその振る舞いを確認するシステムの機能およびシステムの特性のことです。
テストの観点とは、テスト対象が持つ様々な性質のどの点に注目してテストを行なうかを明らかにしたものです。
ここでは表１に一般的と考えられるテストの観点を取り上げてみました。システムテストにおいてはテスト対象が機能仕様書通りに動作するかを確認する機能要件テストとともに機能仕様書には書かれていないことについても確認する非機能要件テストを行ないます。表１にあげた一般的なテストの観点はそのどちらにも適用できます。また、テストの観点に対応する明確なテスト技法がある場合はそれも明記しています。
このテストの観点には同値や境界値など、テスト技法と同じものがいくつか含まれています。テストの観点にテスト技法が含まれるかどうかについては議論のあるところです。ここでテストの観点とは、テスト対象が持つ性質のどこに注目したものであるかという意味からすれば、テスト対象が同値クラスを持つという性質があれば当然同値の観点でのテストが必要になります。テストの観点はテスト技法とイコールではありませんが、同じものも含まれます。テスト技法の中には聞きなれないものも含まれているかもしれませんが、これらについては別の機会に取り上げてみたいと思います。
※ この記事は2014.5.9に改訂しています。
テストの観点については「テスト分析とテストの観点３０選」の記事で取り上げたことがあります。このときにあげたテストの観点は、どちらかといえばエラー推測テスト向けの観点が多くを占めていました。今回はより一般的なテストの観点をあげることにします。
その前にテストの観点に関係する事柄について今一度明確にしておきましょう。
テスト設計の前には「テスト分析」が必要となります。
テスト分析とは、「テスト対象」について「テストの観点」を抽出することです。
テスト対象とは、テストによってその振る舞いを確認するシステムの機能およびシステムの特性のことです。
テストの観点とは、テスト対象が持つ様々な性質のどの点に注目してテストを行なうかを明らかにしたものです。
ここでは表１に一般的と考えられるテストの観点を取り上げてみました。システムテストにおいてはテスト対象が機能仕様書通りに動作するかを確認する機能要件テストとともに機能仕様書には書かれていないことについても確認する非機能要件テストを行ないます。表１にあげた一般的なテストの観点はそのどちらにも適用できます。また、テストの観点に対応する明確なテスト技法がある場合はそれも明記しています。
表１．一般化した３０のテストの観点
| No. | テストの観点 | 内容 | 対応するテスト技法 |
| １ | 同値の観点 | 処理が同じと見なせるグループの代表値を用いる | 同値分割 |
| ２ | 境界値の観点 | 処理が異なるグループの境界値を用いる | 境界値分析 |
| ３ | 状態の観点 | 状態の遷移をともなう動作 | 状態遷移テスト |
| ４ | 優先の観点 | 処理に優先度が関係する動作 | デシジョンテーブル |
| ５ | 時間の観点 | 日付・時刻・時間が関係する動作 | |
| ６ | 資源の観点 | 限られた資源を最大限まで使用する | |
| ７ | 論理の観点 | 複雑な論理が関係する | デシジョンテーブル |
| ８ | 組み合わせの観点 | いくつかの機能や要因の組み合わせ | 組み合わせテスト |
| ９ | タイミングの観点 | イベントの同時発生などタイミングが関係する | タイミングテスト |
| １０ | 中断の観点 | 操作などを途中で取りやめるテスト | エラー推測 |
| １１ | 繰り返しの観点 | 同じ操作を何回も繰り返す | 繰り返しテスト |
| １２ | 順序の観点 | 処理の待ち合わせによる処理順序が関係する動作 | |
| １３ | 競合の観点 | 同じ資源の奪い合いが起きる動作 | |
| １４ | 例外の観点 | 例外的な条件での動作 | エラー推測 |
| １５ | 割り込みの観点 | 機能が動作中に別機能を動作させる | 機能複合テスト |
| １６ | 同時動作の観点 | 機能が動作中に別機能を同時に動作させる | 機能複合テスト |
| １７ | 移行動作の観点 | ある機能を操作中に可能な別機能の操作に移行する | 機能複合テスト |
| １８ | 異常入力の観点 | 規定外の入力を与える | エラー推測 |
| １９ | 動作しない観点 | 機能が動作しない条件で行なう | 無効値テスト |
| ２０ | 矛盾設定の観点 | 矛盾した設定を行なって動作させる | エラー推測 |
| ２１ | 切断再接続の観点 | 動作中に強制的にケーブルを切断、その後再接続する | エラー推測 |
| ２２ | 負荷の観点 | システムに高い負荷をかける | 負荷テスト |
| ２３ | 性能の観点 | システムの性能を測定する | 性能テスト |
| ２４ | ユーザの観点 | ユーザの利用シーンを想定する | シナリオテスト |
| ２５ | セキュリティの観点 | システムのセキュリティに関するテスト | セキュリティテスト |
| ２６ | 構成の観点 | 動作するソフトウェアの構成、ハードウェア構成など | 構成テスト |
| ２７ | ユーザビリティの観点 | ユーザの使い勝手に関するテスト | ユーザビリティテスト |
| ２８ | 保守の観点 | データ設定、データ変換、リモートメンテナンスなど | 保守性テスト |
| ２９ | プライバシーの観点 | 個人情報保護の対象となるユーザデータの扱い | プライバシーテスト |
| ３０ | 意地悪の観点 | 意地悪でキーの連打などシステムへの異常操作を行なう | 意地悪テスト |
このテストの観点には同値や境界値など、テスト技法と同じものがいくつか含まれています。テストの観点にテスト技法が含まれるかどうかについては議論のあるところです。ここでテストの観点とは、テスト対象が持つ性質のどこに注目したものであるかという意味からすれば、テスト対象が同値クラスを持つという性質があれば当然同値の観点でのテストが必要になります。テストの観点はテスト技法とイコールではありませんが、同じものも含まれます。テスト技法の中には聞きなれないものも含まれているかもしれませんが、これらについては別の機会に取り上げてみたいと思います。
※ この記事は2014.5.9に改訂しています。
ソフトウェアテスト技法の概要とメリット・デメリット一覧、テストの分類・適用テストレベル
今回は主なテスト技法についてその概要とメリット・デメリットについての一覧表を紹介します。これはあくまでも個人的な覚書程度のものです。参考程度に見ていただければ幸いです。
テスト技法ごとのメリットはすぐに思い浮かべられますが、デメリットとなると難しいです。そのテスト技法にふさわしいテスト対象に使用すればデメリットはない場合が多いものです。ここでのデメリットは、そのテスト技法を広く適用しようとした場合に起きるものと考えて下さい。
なお、テスト技法ごとにその分類と適用テストレベルの一覧表も掲載しています。これも個人的な考えですので御承知おき下さい。
ホワイトボックスのテスト技法は制御パステストとデータフローテストのみです。ほとんどのテスト技法はテスト仕様書を用いるスクリプトテストです。統合テストで用いることのできるテスト技法についてはこの表で示したものと異なるものがあるかもしれません。
テスト技法ごとのメリットはすぐに思い浮かべられますが、デメリットとなると難しいです。そのテスト技法にふさわしいテスト対象に使用すればデメリットはない場合が多いものです。ここでのデメリットは、そのテスト技法を広く適用しようとした場合に起きるものと考えて下さい。
なお、テスト技法ごとにその分類と適用テストレベルの一覧表も掲載しています。これも個人的な考えですので御承知おき下さい。
テスト対象の性質に基づいた最適なテスト技法の選択方法
ブラックボックステストでは、機能説明書に記述されている仕様がテスト設計時のテスト対象となります。記述されている仕様ごとに最適なテスト技法は同じとは限りません。本章では、テスト対象の性質に応じて最適なテスト技法を選択する方法を説明します。
ここでの説明はあくまでも一例であり、これ以外にも様々な方法があり得ます。
テスト対象の性質に基づく分類
テストする観点から見た仕様の性質には、以下のタイプがあります。
① 端末からの操作に関する仕様
② 回線種別、端末種別、設定内容など複数の要因が関係する多くの組み合わせが考えられる仕様
③ 要因の値間に処理の優先順位がある仕様
④ 比較的他の仕様より複雑な論理を持つか、または要因間に明らかな関係性がある仕様
⑤ 状態の遷移をともなう仕様
⑥ 同一リソースへの同時アクセスまたは多重アクセスの動作が可能な仕様
⑦ 動作に時間が関係する仕様
⑧ 同時に使用可能なリソース数に制限がある仕様
⑨ 機能が動作しない条件の仕様
⑩ その他の仕様
以上のうち、⑥、⑧、および⑨の性質は、機能説明書に明記されていない場合があり得ます。テスト設計の際は、仕様に明記されていないテスト対象が持っている隠れた性質を見つけ出し、それにふさわしいテスト技法を適用する必要があります。
テスト技法の分類
おもなテスト技法には以下の種類があります。
A) 同値分割／境界値分析
同値分割とは、ソフトウェアやシステムへの入力を同じ処理をするグループに分割し、グループ内の各入力を同等として扱う方法であり。境界値分析とは、同値に分割したグループの境界上の動作が正しくないことが多いという経験的事実をもとに、境界値に的を絞ったテストを行なうための方法です。
B) 要因組み合わせテスト
テスト結果に影響を与える可能性のある要因は無数に考えられるが、ほとんどの欠陥が二つまでの要因の組み合わせで発生していることが知られていることから、２要因間のすべての組み合わせを網羅したテストケースを作成して行なうテストです。すべての要因を組み合わせるとテストケース数が非常に多くなってしまう場合に有効です。
C) 要因列挙テスト
各要因の値を列挙するだけで、要因間の組み合わせは行なわず、最も数の多い値の数と同じテストケースを作成して行なうテストです。各要因の組み合わせで発生する欠陥の可能性については、別途組み合わせテストで排除されていることが前提となります。
D) 要因限定テスト
各要因から特定の値だけをピックアップしてテストケースを作成する。各要因の組み合わせで発生する欠陥の可能性が無視でき、かつ各要因に共通する性質があると考えられる場合に行なうテストです。
E) デシジョンテーブル
論理的で複雑な条件を含む仕様、または要因間で明からな関係性をもつルールの組み合わせを分かりやすく視覚化することにより、漏れのないテストを行なうための方法です。
F) CFD
仕様から直接デシジョンテーブルを作成するよりも、図に書き出して条件を明確にしたほうがよいと思われる場合に使用します。
G) 状態遷移テスト
ある状態で、あるイベントが発生したときに何を行ない、次にどの状態に遷移するかを表で表したものであり、状態の遷移を伴う仕様を把握するための方法。仕様の記述内容を状態の遷移としてモデル化できる場合に使用します。
各テスト技法のうち、E) デシジョンテーブル～ G) 状態遷移表は、要因列挙テストまたは要因限定テストと組み合わせて行なう場合があります。例えば、状態遷移テストを端末種別（これが要因）ごとに実施する場合などがそうです。
要因組み合わせテストで動作が確認できている場合に、改めて組み合わせてテストを行なうまでもない場合に、要因列挙テストまたは要因限定テストで済ますことになります。これはリスクベーステストの考え方の適用になります。
テスト対象の性質と適用するテスト技法
テストする観点から見たテスト対象の性質に対応するテスト技法を以下に示します。
一つの仕様で、２つ以上の性質を有する場合があります。その場合は、原則としてそれぞれの性質に対応したテスト技法によるテスト項目を作成します。
操作に関係する仕様に要因組み合わせテストを適用することになっていますが、これはごく簡単な状態遷移が対象であり、少し複雑な状態遷移となる場合は状態遷移テストを適用すべきです。
ここでの説明はあくまでも一例であり、これ以外にも様々な方法があり得ます。
テスト対象の性質に基づく分類
テストする観点から見た仕様の性質には、以下のタイプがあります。
① 端末からの操作に関する仕様
② 回線種別、端末種別、設定内容など複数の要因が関係する多くの組み合わせが考えられる仕様
③ 要因の値間に処理の優先順位がある仕様
④ 比較的他の仕様より複雑な論理を持つか、または要因間に明らかな関係性がある仕様
⑤ 状態の遷移をともなう仕様
⑥ 同一リソースへの同時アクセスまたは多重アクセスの動作が可能な仕様
⑦ 動作に時間が関係する仕様
⑧ 同時に使用可能なリソース数に制限がある仕様
⑨ 機能が動作しない条件の仕様
⑩ その他の仕様
以上のうち、⑥、⑧、および⑨の性質は、機能説明書に明記されていない場合があり得ます。テスト設計の際は、仕様に明記されていないテスト対象が持っている隠れた性質を見つけ出し、それにふさわしいテスト技法を適用する必要があります。
テスト技法の分類
おもなテスト技法には以下の種類があります。
A) 同値分割／境界値分析
同値分割とは、ソフトウェアやシステムへの入力を同じ処理をするグループに分割し、グループ内の各入力を同等として扱う方法であり。境界値分析とは、同値に分割したグループの境界上の動作が正しくないことが多いという経験的事実をもとに、境界値に的を絞ったテストを行なうための方法です。
B) 要因組み合わせテスト
テスト結果に影響を与える可能性のある要因は無数に考えられるが、ほとんどの欠陥が二つまでの要因の組み合わせで発生していることが知られていることから、２要因間のすべての組み合わせを網羅したテストケースを作成して行なうテストです。すべての要因を組み合わせるとテストケース数が非常に多くなってしまう場合に有効です。
C) 要因列挙テスト
各要因の値を列挙するだけで、要因間の組み合わせは行なわず、最も数の多い値の数と同じテストケースを作成して行なうテストです。各要因の組み合わせで発生する欠陥の可能性については、別途組み合わせテストで排除されていることが前提となります。
D) 要因限定テスト
各要因から特定の値だけをピックアップしてテストケースを作成する。各要因の組み合わせで発生する欠陥の可能性が無視でき、かつ各要因に共通する性質があると考えられる場合に行なうテストです。
E) デシジョンテーブル
論理的で複雑な条件を含む仕様、または要因間で明からな関係性をもつルールの組み合わせを分かりやすく視覚化することにより、漏れのないテストを行なうための方法です。
F) CFD
仕様から直接デシジョンテーブルを作成するよりも、図に書き出して条件を明確にしたほうがよいと思われる場合に使用します。
G) 状態遷移テスト
ある状態で、あるイベントが発生したときに何を行ない、次にどの状態に遷移するかを表で表したものであり、状態の遷移を伴う仕様を把握するための方法。仕様の記述内容を状態の遷移としてモデル化できる場合に使用します。
各テスト技法のうち、E) デシジョンテーブル～ G) 状態遷移表は、要因列挙テストまたは要因限定テストと組み合わせて行なう場合があります。例えば、状態遷移テストを端末種別（これが要因）ごとに実施する場合などがそうです。
要因組み合わせテストで動作が確認できている場合に、改めて組み合わせてテストを行なうまでもない場合に、要因列挙テストまたは要因限定テストで済ますことになります。これはリスクベーステストの考え方の適用になります。
テスト対象の性質と適用するテスト技法
テストする観点から見たテスト対象の性質に対応するテスト技法を以下に示します。
一つの仕様で、２つ以上の性質を有する場合があります。その場合は、原則としてそれぞれの性質に対応したテスト技法によるテスト項目を作成します。
操作に関係する仕様に要因組み合わせテストを適用することになっていますが、これはごく簡単な状態遷移が対象であり、少し複雑な状態遷移となる場合は状態遷移テストを適用すべきです。
PictMaster 5.7.2をリリースしました
PictMaster 5.7.2をリリースしました。
主な変更点は以下の通りです。
・ネットワークドライブの割り当てを行なっていないサーバ上に置かれたPictMasterで生成を行なった場合、生成されたファイルはこれまでのProgram Filesフォルダ内ではなく、ログインしているユーザの”マイドキュメント”フォルダ内に作成されるようにした。
PictMaster 5.7.2は以下のサイトからダウンロードすることができます。
http://sourceforge.jp/projects/pictmaster/
主な変更点は以下の通りです。
・ネットワークドライブの割り当てを行なっていないサーバ上に置かれたPictMasterで生成を行なった場合、生成されたファイルはこれまでのProgram Filesフォルダ内ではなく、ログインしているユーザの”マイドキュメント”フォルダ内に作成されるようにした。
PictMaster 5.7.2は以下のサイトからダウンロードすることができます。
http://sourceforge.jp/projects/pictmaster/
サーバ上にPictMasterを置いた場合に作成されるファイルの場所について
現行のPictMasterでは、サーバ上（ネットワークドライブの割り当てなし）に置かれたPictMasterで生成を行なうと、Program Filesフォルダ内のPICTフォルダ内に生成されたファイルが書き込まれます。
この場合、Windows 7以降ではProgram Filesフォルダ内のフォルダはリードオンリーであるため、そのままではファイルが書き込めないエラーとなります。管理者権限でログインし、PICTフォルダのプロパティからセキュリティタブの指定でフルコントロールなどに変更すれば問題は解決しますが、これは一般的なやり方とは言えません。
まもなくリリースするv5.7.2では、サーバ上に置かれたPictMasterで生成を行なった場合、Program Filesフォルダ内ではなく、ログインしているユーザの”マイドキュメント”フォルダ内に作成されるようになります。
この場合、Windows 7以降ではProgram Filesフォルダ内のフォルダはリードオンリーであるため、そのままではファイルが書き込めないエラーとなります。管理者権限でログインし、PICTフォルダのプロパティからセキュリティタブの指定でフルコントロールなどに変更すれば問題は解決しますが、これは一般的なやり方とは言えません。
まもなくリリースするv5.7.2では、サーバ上に置かれたPictMasterで生成を行なった場合、Program Filesフォルダ内ではなく、ログインしているユーザの”マイドキュメント”フォルダ内に作成されるようになります。