テスト技法の選択
- コンポーネントまたはシステムの種類
- コンポーネントまたはシステムの複雑さ
- 規則や標準
- 顧客または契約上の要件
- リスクのレベルやタイプ
- テスト目的
- 入手可能なドキュメント
- テスト担当者の知識とスキル
- 利用できるツール
- スケジュールと予算
- ソフトウェア開発ライフサイクルモデル
- ソフトウェアの想定される使用方法
- テスト対象のコンポーネントまたはシステムに関してテスト技法を使用した経験
- コンポーネントまたはシステムで想定される欠陥の種類
今の仕事だと悩ましいのが想定される使用方法ですね。
業務システムだと、お客さんがどう使うか、何を解決したいのかが業務知識がわからないため足りないことがあるのです。
こちらが想定しない使われ方をしてしまうなんてことがあります。
想定される欠陥の種類には、着目したいですね。
テスト技法のカテゴリと特徴
Glenford J.Myersのソフトウェアの技法では、次の手順でテスト設計を行うことを推奨しています。
- 仕様が入力条件の組み合わせを含んでいる場合は、原因・結果グラフの作成から行います。
- どんな場合でも境界値分析を行います。
- 入力と出力の有効と無効の同値クラスを見分け、必要ならテストケースを補足します。
- エラー推測技法により、テストケースを補足します。
- ホワイトボックス技法により要求されるカバレッジ基準が1-4で満たされていない場合は、この基準を満たすようなテストケースを補足します。
欠陥が残る可能性を最大限減らすためのアプローチだと言えるでしょう。
となってますが、入力条件の組み合わせは、単純なテキストボックスとかだったらまだしも、今のUIはタッチやスライドを駆使したりするので、なかなか難しいよなあと思いました。
ブラックボックステスト技法
仕様が明らかになっていることを前提にしてテスト設計する技法です。
インプットとなるドキュメントの種類は、テストアイテムをどのように定義するかによって異なります。
ドキュメントに定義、規定される仕様は機能やコンポーネントといったテストアイテムの定義に関わらず、ある程度抽象度の高い情報として表現されています。
ホワイトボックステスト技法
テスト対象のソフトウェアの内部構造を検証するテストを設計する技法です。
テストケースの作成時にはソフトウェアの構成や構造を理解しなくてはならないため、ソフトウェアの設計/実装に関する詳細情報が必要になります。
経験ベースのテスト技法
テスト設計や実行を行うテスト担当者や開発担当者が持つスキルや経験、ユーザーの利用実体に関する情報、勘などをもとにテストケースを作成します。
スキルの低い開発担当者がこの技法を用いるとなると、単なる闇雲なテストになってしまいます。反対にテスト対象に対する理解がふかく、経験豊富であるならば、一通りのテストが終わった後の最終確認的な位置付けとして一定の効果が期待できます。
このようなスキルを持った技術者によるテストを探索的テストと呼びます。
結局、この経験ベースのテスト頼みですね。
ソフトウェアが複雑すぎでカバレッジとか計測できないですし、ホワイトボックステスト技法でも追いきれないのが現状です。
グレーボックステスト技法
ホワイトボックステスト、ブラックボックステストの他にグレーボックステスト技法があります。
プログラムの構成がわかった上で実施するテスト技法で、ブラックボックスとホワイトボックスの中間に当たります。
アーキテクチャの妥当性を確認するために、ある程度内部処理に踏み込んで検証する必要性がある時に適用します。
これは知りませんでした。
ブラックボックステスト技法
同値分割法
言葉の定義が続くのですが、ふりがな入力欄で、空欄、ひらがなのみ、ひらがな＋漢字といった形で入力値を分ける方法です。
入力されるデータをパーティションに振り分けます。
同値分割法ではパーティション内の代表的なデータを1つ選び、そのデータを使ってテストすれば、同じパーティションの他のデータもテストしたものとみなします。
同値パーティション
あらゆるデータは必ず1つの同値パーティションに所属します。
有効なデータのパーティションを有効同値パーティション、無効データのパーティションを無効同値パーティションと呼びます。
テストレベル
全てのテストレベルに適用できます。
カバレッジ
カバレッジ = テスト実行した同値パーティション数 / 全同値パーティション数
特殊な条件で実行できないことがない限り、定義した全ての同値パーティションはテストされるかなと多います。
同値分割法の注意点
テストケースを設計するとき、有効同値パーティションと組み合わせることができますが、無効同値パーティションは単独で用います。
複数の無効同値パーティションを組み合わせたテストケースを設計し使用した時、１つの故障しか検出できず他の故障を隠してしまうことがあり得ます。
また、時間に依存する値にも同値パーティションは存在します。文書の保存前と保存後といったイベントの前後です。
内部仕様の都合上、文書の保存後にはUndo/Redoが出来なくなるとかありますね。
境界値分析
0~100の整数しか入れられない時に、0未満、0-100、100より大きい値と同値パーティションの境界上の値を使ってテストする技法です。
順序づけられた値をもつ同値パーティションにおける最大値もしくは最小値が境界値です。
上記の例の場合だと、-1,0,100,101が境界値となります。問題で間違えたのですが、0,100だけが境界値というわけではありません。
テストケース
- 境界値の範囲に含まれる値と含まれない値をテストケースとする（２ポイント境界値分析法）
- 境界値とその両隣をテストケースとする（３ポイント境界値分析法）
と2つがあります。が、これまで、なんとなく、テストケースを作ってましたね。どちらかというと２ポイント境界値が多いかなと思います。
テストレベル
すべてのテストレベルに適用できます。
カバレッジ
カバレッジ = テスト実行した境界値の数 / 全境界値の数
デシジョンテーブルテスト
デシジョンテーブルとは、入力データや入力条件の組み合わせに対する処理や出力結果を表にまとめたものです。
複雑なビジネスルールや論理を把握するのに効果を発揮する表です。この表を使ってテスト設計する方法を、デシジョンテーブルテストといいます。
複雑な検索条件のテストに対して、このデシジョンテーブルをうまく使って、テスト設計する人がいました。当時のぼくはデシジョンテーブルという言葉も知りませんでしたし、その表をぱっと見ても複雑で目眩がするくらいでした。
マトリックス図なんて呼んで、そうしたテストをしている頃もありましたね。
テストレベル
全てのテストレベルで可能です。
カバレッジ
カバレッジ=テスト実行したルール数（規則）/全ルール規則
ルールは条件の組み合わせです。
カバレッジを全網羅するのは厳しい場合もあります。
そうなれば、よく使われるパターンに絞って、珍しいパターンは捨てるとか、組み合わせる条件を減らしてしまうとかせざるを得ません。
あまりに慎重になりすぎて細かい条件のテストケース作ったら、そこまではしなくていい、この条件はテーブルから外していいとレビューされたことがありました。
これが問題としては、手を動かさないと正答できないので難しいです。
状態遷移テスト
システムが状態をどのように遷移するのかを表現した図を状態遷移図と言います。
状態とイベントのマトリクスで表現したものが状態遷移表になります。
状態遷移図または状態遷移表を用いてテストケースを設計するのが状態遷移テストです。
次に示す設計方法があります。
- 典型的な状態遷移の順序をカバーするテストケースを設計する
- すべての状態を網羅するようにテストケースを設計する
- すべての遷移を網羅するようにテストケースを設計する
- 特定の順序で遷移するようにテストケースを設計する
- 無効な遷移を確認するテストケースを設計する
ぼくの経験では、あまりきちんと状態遷移テストはしてないですね。
Webアプリでも戻るボタン、ブラウザバック、URL直接叩くとか、遷移方法があるのですが、toBだとそこまではやらないと思います。
典型的な状態遷移の順序をカバーするのに留め、状態遷移図もつくらないでしょう。
ただ、toCだと抜け道になったりするとまずいので、もう少し丁寧なテストになると思います。
テストレベル
全てのテストレベルで適用可能です。
適用可能というわけで、全てのテストレベルでされるかは別問題でしょうね。特に状態遷移テストは状態遷移が伴うコンポーネントでないことがあります。
例えば、ステートレスなWeb APIでは、コンポーネントテストレベルではやりようがないでしょうから。
カバレッジ
状態のカバレッジ=テスト実行した状態数/全状態数
遷移のカバレッジ=テスト実行した遷移数/全遷移数
と2つのカバレッジが存在します。
なんとなく、わかっているつもりで問題を解いてみましたが、わかりませんでした。
遷移のカバレッジを網羅するならば、状態が遷移しないケースもテストする必要があるのでした。
ユースケーステスト
ビジネスシナリオやシステムの使い方に基づいてテストケースを設計します。
ユースケース
ユースケースとは、アクターとサブジェうと（テスト対象のシステムやソフトウェア）との間の相互作用を記述したものです。
ユースケースは、ユーザーとサブジェクトとの間の全てのやりとりを記したものではなく、ユーザーや顧客にとって価値のある結果が得られるものを記述しています。
テストレベル
ユーザーや顧客が参画する受け入れテストで用いると効果があります。
カバレッジ
カバレッジ=テスト実行したユースケースの振る舞い数/ユースケースの振る舞い総数
このユースケーステストは、経験としてはないです。ユースケースを見ながらテストケースを設計しているのを見た経験も記憶にないですねえ。
ホワイトボックステスト技法
ホワイトボックステストは内部構造をもとにしたテストです。全てのテストレベルで適用できますが、主にコンポーネントテストで使用されるコードをベースにした2つの技法を取り上げます。
ステートメントテストとカバレッジ
ステートメントテストはコード内の実行可能ステートメントに着目してテストケースを設計します。
ステートメントテストで計測するカバレッジをステートメントカバレッジと呼びます。
ステートメントカバレッジ(%)=テストにより実行したステートメント数/テスト対象の実行可能ステートメントの合計数*100
ブラックボックステストのカバレッジと違って、テスト対象の実行可能ステートメントです。間違えました。
void method(int x) {
if (x!=0) print("x is not 0")
}
このコードの場合、全ての命令文をテストすればいいので、xが0以外のケースだけとなるのです。
普通は0も試すとは思いますが……。
デシジョンテストとカバレッジ
デシジョンテストはコード内の判定とその判定結果に着目してテストケースを設計します。
判定というのはif, switch, while文など。
デシジョンカバレッジ(%)=テストにより実行した判定結果の数/テスト対象の判定結果の合計数*100
void method(int x) {
if (x!=0) print("x is not 0")
}
このコードの場合、xが0以外と0の2パターン。
ステートメントテストとデシジョンテスト
ステートメントテストでは、ステートメントが実行されることで期待とは異なる結果をもたらすような欠陥を見つけるのに役立ちます。
デシジョンテストは判定の真の結果と偽の結果の両方のケースをテストして、期待とは異なる欠陥を見つけるのに役立ちます。
経験ベースのテスト技法
テスト担当者のスキル、直感、さらには同様のアプリケーションや技術における経験をベースにテストケースを設計します。
仕様に書かれていない暗黙の仕様は、ブラックボックステスト技法によってテストするのは困難です。
そのような欠陥を検出するのに、経験ベースのテスト技法は非常に有効であると言えます。
一方、経験ベースのテスト技法は、テスト担当者のテストの進め方と経験に大きく依存するため、その有効性には非常に大きなバラツキがあります。
カバレッジによる評価が難しいです。
カチッとした仕様書がない現代の開発において、ぼくが一番注目しているのが、この経験ベースのテスト技法ですね。
時間あたりの不具合検出で評価していました。やはり人によってバラツキがあるのが事実です。
エラー推測
テスト担当者の知識を基に誤り、欠陥、故障の発生を予測する技法です。
使用する知識には、例えば以下のものがあります。
- アプリケーションの過去の動作状況
- 開発担当者が犯しやすい誤りの種類
- 他のアプリケーションで発生した故障
よく起きやすい故障のリストのようなものは僕も作っていますね。
探索的テスト
探索的テストは、テスト設計、テスト実行、ログ記録、および評価を並行に実施します。
探索的テストの特徴の１つに、形式的ではない、すなわちテストケースを事前に作成しない点があります。
ただ、探索的テストは、何も準備せずにいきなりテストをする訳ではありません。
セッションベースドテストと呼ばれる体系的な探索的テストの実施方法では、テスト担当者はテストチャーターに従ってテストを実行します。
テストチャーターにはテスト目的が書かれており、テストを実行するためのガイドとなります。
形式的なテストでのテストケースの代わりになるものと考えて良いでしょう。
セッションベースドテストには、他の特徴があります。
- あらかじめ決められた時間枠内（セッション）で行う
- 実行した手順や発見した事象をテストセッションシートに記録する
また、スケジュールに余裕がない場合に、事前準備作業を省力化し、テスト設計とテスト実行を同時並行的に行うことで、効率よくテストを進めることができます。
また、形式的なテスト技法を補完する使い方として、形式的なテスト技法によるテストの後、あるいはそれと並行して探索的テストを実施することで欠陥を見つけることができます。
と、今、僕が力を入れたいテスト技法が、この探索的テストです。
ただのモンキーテストだと惰性になりがち、シナリオベースのテストでは欠陥が見つからないのですから。
とはいえ、どうしてもスキルや経験に依存する点が注意点です。
チェックリストベースドテスト
文字通りチェックリストを使用してテストケースを設計します。
チェックリストはエラー推測と同様にテスト担当者の経験を基に作成します。
- ユーザーにとって何が重要であるかという知識
- ソフトウェアが不合格となる理由と仕組みについての理解
以上、第４回でした。ここは、軽いですね。
