Zenn
💨

はじめて学ぶソフトウェアのテスト技法を読んでみた

2023/04/29に公開
Test
tech

はじめて学ぶソフトウェアのテスト技法を読んでみた

あまり読書した内容を記事のような形でアウトプットしてこなかった。今回はじめて記事を作成してみる。内容の定着などに良さそうなら今後も続けていきたい。

また、自分が思ったことは別途memoという形で記載するようにする。

なぜこの本を読もうと思ったのか

自分が勤務する会社でテストを作成する場合、以前に作成された似たようなテストをベースにして作成することが多かった。そんななかで、自分が作成するテストケースは果たして適切なものなのだろうかと思うこともあり、一度テストについて一から学び直そうと思ったのがきっかけである。

はじめて学ぶソフトウェアのテスト技法は、国際的に著名なソフトウェアテストコンサルタントのLee Copeland（リー・コープランド）の著書である。この本は、テスト設計の技法をまとめたものであり、ソフトウェアテストについて焦点を絞っているとのことだったので、実務でテストケースを作成する際の１つの指針になると考えた。

テストのプロセス

テストとは

テストの一番本質的部分は、「実際どうなっているか」と「本来はどうあるべきか」を比較するプロセスだということ。組織や人が異なれば、ソフトウェアテストの目的に対する見方もさまざまに変わる。

IEEE
IEEE標準規格610.12-1990の "IEEE Standard Glossary of Software Engineering Terminology" の定義は、「ある特定の条件下でシステムまたはコンポーネントを操作するプロセスであり、その結果を観察または記録して、システムまたはコンポーネントのある側面を評価すること」。この定義における 「ある特定の条件」を具体化したものが、テストケースである。

Systematic Software Testing（邦訳「体系的ソフトウェアテスト入門」）
Rick CraigとStefan Jaskielは、ソフトウェアテストの定義を以下のように拡張している。「テストとは、テストされるソフトウェアの品質を測定して改善するために、テストウェアをエンジニアリングし、利用し、保守しながら、同時並行的に進めるライフサイクルプロセスである」。これには、IEEEの定義が重点をおいているテスト実行の側面に加えて、計画、分析、テストケース設計の視点が含まれる。

テストの5つの成熟度

Boris Beizerは、テストの成熟度を５つのレベル[1]に分けて記述している。

レベル０ テストとデバッグには何の差もない。デバッグ以外にはテストには特別な目的はない。
欠陥は偶然見つかるかもしれないが、検出するための公式な努力はない。

レベル１ テストの目的は、ソフトウェアが動くことを示すことである。
このアプローチは、ソフトウェアが基本的に正しいだろうという前提から始まっているため、欠陥を見つけ出そうとする我々の眼を曇らせる可能性がある。

レベル２ テストの目的は、ソフトウェアが動かないということを示すことである
テスト担当者は欠陥を見つけ出そうと努力する必要がある。重箱の隅をつつくようにシステムを評価するテストケースを意識して選択する。

レベル３ テストの目的は、何かを証明することではなく、プログラムが動かないことによって発生する危険性をある許容範囲まで減らすことである
システムが正しくないことは１つのテストケースだけでも証明できるが、正しく動作することを証明することは不可能。ここでの目的は、欠陥という観点からソフトウェアの品質を理解し、ソフトウェアがどれくらい不完全かという情報をプログラマに提供するとともに、もしシステムを現段階で顧客に提供したら、自社にとってどれだけマイナスのインパクトがあるかという評価を、経営陣に伝えること。

レベル４ テストは行動ではない。大袈裟なテストをすることなく品質の高いソフトウェアを作るための精神的な規律である。
よりテストの容易なソフトウェアを開発することに重点が置かれる。要件定義、設計、コードのレビューとインスペクションまでが含まれる。

テストケースについて

きちんと設計されたテストケースは以下の３つの部分で構成されている。

  • 入力
  • 出力
  • 実行の順番

入力

キーボートからの入力以外にも、インターフェースシステムやインターフェース機器からのデータ、ファイルやデータベースからのデータ読み出し、データが到着したときのシステムの状態、システム実行環境などからのデータも入力になる。

出力

テストケース設計において、期待する結果が何かを決定してくれる役目を果たすのが、「オラクル」（神のご宣託）である。オラクルとは、テストの期待結果をテスト設計者に提供するための、プログラム、プロセス、データなどを意味している。

Boris Beizerは、オラクルとして次の５つのタイプを挙げている。

  • 子供のオラクル - 単にプログラムを実行して結果を眺める。正しそうに見えれば、それが正しいものだと信じる。
  • 回帰テストのテストスイート - プログラムを実行して、以前のバージョンのプログラムに適用したテストケースの結果を、今回の結果と比較する
  • 正当性が実証されたデータ - プログラムを実行して、テーブル、公式、その他の正当な出力の定義として認められた基準と、プログラムを実行した結果の出力を比較する。
  • 市販のテストスイート - 既存の検証済み標準テストスイートに対して、プログラムを実行する。コンパイラ、Webブラウザ、SQLプロセッサのようなプログラムは、この種のテストスイートでテストされることが多い。
  • 既存のプログラム - プログラムを実行して、その結果を異なるバージョンのプログラムでの結果と比較する。

実行の順番

テストの実行の順番に関して、テストケース設計には２つのやり方がある。

順番通りのテストケース

１つ前に実行されたテストを前提に作成されたもの。良い点は、テストケースが一般的に小さく単純になること。難点は、１つのテストが失敗したら、後続のテストが全部無効になるかもしれないこと。

互いに独立なテストケース

各テストケースは、完全に自己完結している。良い点は、どんな順番でもテストを実行できること。難点は、テストケースが大きくて複雑になる傾向があり、その設計、作成、メンテナンスが難しくなること。

テストの種別について

テストはよく、「ブラックボックステスト」と「ホワイトボックステスト」の２つに分類される。

ブラックボックステスト

要件や仕様にもとづいてテストを実施する戦略。テスト対象ソフトウェアの内部パス、構造、実装に関する知識を必要としない。

ホワイトボックステスト

テスト対象ソフトウェアの内部パス、構造、実装にもとづいて、テストを実施する戦略。プログラミングの詳細なスキルを必要とする。

グレーボックステスト

テスト対象ソフトウェアがどんなふうに実装されているかがわかる程度まで調べ、その知識をブラックボックステストのテストケースをより効果的に選択するために利用する。

テストのレベル

テストは通常、次の４つのレベルで実施される。[2]

単体テスト

単体は、開発者が作成するソフトウェアの最も小さい部品を指す。通常、１つのファイルとして保管されているもの。C++、Javaでの単体はクラス。あまり構造化されていないBasicやCobolなどの言語では、単体はプログラム全体を指す。

統合テスト

統合テストでは、単体をサブシステム、最終的にはシステムとして結合します。単体としては完全に機能しても、結合すると障害が起こることがあるため、統合プロセスを進める上では結合テストは必須。

システムテスト

システムコンポーネントは、顧客に届けられる製品を作り上げているすべてのソフトウェアから構成される。システムテストは、最も高いレベルの結合時に起こる欠陥に焦点を絞っている。

システムテストには、以下に示すような様々なタイプのテストが含まれる。

  • 機能性
  • ユーザビリティ（使いやすさ）
  • セキュリティ
  • 国際化
  • 信頼性

など

受け入れテスト

受け入れテストは、このテストが成功裏に完了したときには、顧客がソフトウェアを受け入れて、代金を支払うテストとして定義されている。受け入れテストの前に考えておきたい、戦略上の質問の代表例が以下。

  • 受け入れテストのレベルを決めるのは誰か
  • テストスクリプトを書くのは誰か
  • テストを実行するのは誰か
  • 受け入れテストの合格・不合格の基準は何か
  • 誰がどのように支払いをするのか

すべてをテストすることはできない

簡単な数値計算のプログラムでも、入力として考えられる値は膨大のためすべての値をテストすることはできない。最小の時間と労力でほとんどのエラーを検出する可能性が最も高くなるようにテストケースを設計しなければならない。

ブラックボックステスト技法

ブラックボックステストの定義

ブラックボックステストは、要件と仕様書だけを拠り所にしたテスト戦略。ホワイトボックステストとの違いは、テスト対象ソフトウェアの内部パス、構造や実装に関する知識を必要としないこと。ブラックボックステストの一般的な手順が以下。

  1. 要件や仕様書を分析する
  2. 仕様書をもとにして有効な入力を選択する。有効値を正しく処理できることを確認する。無効値を検出して正しく処理することを確認するために、無効な入力値も選択する
  3. それぞれの入力値に対して、期待する出力は何かを決定する
  4. 選択した入力値を使ったテストを作成する
  5. テストを実行する
  6. 実際の出力と期待する出力とを比較する
  7. テスト対象ソフトウェアが正常に機能しているかどうか判定する

ブラックボックステストの適用対象

ブラックボックステストは、単体テスト、統合テスト、システムテスト、受け入れテストというすべてのレベルで適用できる。ソフトウェアテストの規模が大きくなるにつれ、ブラックボックステストに頼らざるを得なくなる。それは、テスト対象ソフトウェアに対して、実行すべきパス数があまりに多すぎて、ホワイトボックステストでは手に負えなくなるからである。

ブラックボックステストの難点

テスト担当者が、テストソフトウェアの内部のどれだけの部分をテストできたか、明確に知る方法がない。何らかの実行パスは実行されないまま残る。欠陥を全部ブラックボックステストで見つけ出そうとすると、有効値、無効値を含めてすべての可能性のある値の組み合わせを作成する必要がある。そのため、入力の組み合わせのサブセットのみを選択することになる。

ブラックボックステストの利点

ブラックボックステストを公式に実施すれば、欠陥を見つけるための、有効でしかも効率の高いテストのサブセットを選択できる。また、無作為に作られた同数のテストより、多くの欠陥を見つけることができる。

以降の内容については、随時更新していきます。

更新履歴

更新日 改訂内容
2023/4/29 投稿
2023/4/30 ブラックボックステスト技法を追記
脚注

  1. Borisは、フェーズと呼んでいる。 ↩︎

  2. 古典的なテストレベルと表現されている。 ↩︎

Discussion