- 作者: J.マイヤーズ,M.トーマス,T.バジェット,C.サンドラー,Glenford J. Myers,Todd M. Thomas,Tom Badgett,Corey Sandler,長尾真,松尾正信
- 出版社/メーカー: 近代科学社
- 発売日: 2006/08
- メディア: 単行本
- 購入: 7人 クリック: 267回
- この商品を含むブログ (46件) を見る
初版1979年の古典
ソフトウェア・テストの定義
「ソフトウェア・テストとは、コンピュータ・コードが意図されたように動作し意図されないことは全て実行しないように設計されていることを検証するように設計されたプロセス、あるいは、一連のプロセスである。」
ソフトウェア・テストの心理学
「テストとは、エラーをみつけるつもりでプログラムを実装する過程である。」
テストを実施する時に、プログラムにエラーがないことを証明することを目標とした場合に心理的な抑制が効いてしまう。目標がプログラムのエラーの存在を示すことであったら、エラーを見つける確率の高いデータを選ぶだろう。このような観点で行うテストは、プログラムにより高い価値を加えるものとなるであろう。
すなわち、プログラムがいくつかの入力データに対して正当に動作することを単に確かめるよりも、不完全な点を明らかにするようテストに望むべきである。
ソフトウェア・テストの経済学
- プログラムが全くエラーをもたないと証明するようなテストはできない
- プログラム・テストの基本的な考え方には経済学的な見方が必要である
つまり徹底的なテストは不可能で問題外であるから、有限の数のテストで発見されるエラーを最大にすることによってテストに対する投資の成果を最大限にすることを目的とすべきである。
ソフトウェア・テストの原則
- テスト・ケースの必須条件は、予測される出力または結果を定義しておくことである
- プログラマは自分自身のプログラムをテストしてはならない
- プログラム開発グループは、自分達のプログラムをテストしてはならない
- それぞれのテストの結果を完全に調査せよ
- テスト・ケースは、予想できる正しい入力条件ばかりでなく、予想しないあやまった場合も考えて書かなければならない
- プログラムを調べるのに、それが意図されたように動くかどうかを見ただけでは、なかば成功したにすぎない。残りの半分は、意図されなかった動きをするかどうかを調べることである
- プログラムが本当に使い捨てのものでないかぎり、そのテスト・ケースも使い捨てにしてはならない
- エラーはみつかれないだろうという仮定のもとにテストの計画をたててはならない
- プログラムのある部分でエラーがまだ存在している確率は、既にその部分で見つかったエラーの数に比例する
- テストとは、非常に創造的であり、知的に挑戦しがいのある仕事である
コンピュータによらないテスト過程(あるいは人間によるテスト過程)
人的テスト手法はエラーを発見するのに非常に有効である。プログラミング・プロジェクトのほとんどは次の人的テスト手法を含むべきである。
- チェックリストによるコード検査
- グループのウォークスルー
- 机上チェック
- 仲間内の検討
- このプログラムは理解しやすかったか
- 高いレベルでの設計は、明確で、適切か
- 低いレベルでの設計は、明確で、適切か
- このプログラムを変更するとすれば、それは容易だと思われるか
- このプログラムをあなたが書いたとしたら、それを誇りに思えるか
テストケースの設計
「可能なテストケースのどのようなサブセットが最もエラーを発見できる確率が高いか」
これが時間とコストの制約のもとでテストのかぎである。
無作為に、可能な入力値のサブセットを選択する方法では、最も多くのエラーを発見できるという観点から、最も劣った手法といえる。
テストケース設計の戦略
- 仕様が入力条件の組み合わせをふくんできる場合は、原因-結果グラフの作成から始める
- どんな場合でも限界値分析を使う。これは入力および出力限界の分析であることを覚えておこう。限界値分析によって、補助的なテスト条件のセットが得られる。しかし、これらの大部分または全ては、原因-結果テストに統合されうる。
- 入力と出力の有効と無効の同値クラスを見分け、もし必要なら見分けたテストケースを捕捉する
- さらにテストケースを得るためにエラー推測技法を使う
- テストケースのセットを考慮に入れながら、プログラムの論理を調べる。判定条件網羅、条件網羅、判定条件/条件網羅、複数条件網羅基準のうちのどれかを使う。
モジュール(単体)・テスト
モジュールテストの目的は、あるモジュールの機能を、そのモジュールを定義している機能仕様あるいはインターフェーズ仕様と比較することである。
上級テスト
- モジュールテスト あるモジュールの機能を、そのモジュールを定義している機能仕様あるいはインターフェース仕様と比較することである
- 機能テスト プログラムと外部仕様との相違点を発見する過程である
- システムテスト システムテストは完全なシステムまたはプログラムの機能をテストする過程ではない。システムまたはプログラムをもとの目的仕様と比較する過程である
- 機能部分テスト(facility testing)
- 大容量テスト(volume testing)
- ストレステスト(stress testing)
- 有用度テスト(usability testing)
- 秘密保護テスト(security testing)
- 効率テスト(performance testing)
- 記憶域テスト(storage testing)
- 構成テスト(configuration testing)
- 互換性/構成/変換テスト(compatibility/configuration/conversion testing)
- 設置テスト(installability testing)
- 信頼性テスト(reliability testing)
- 回復テスト(recovery testing)
- サービス性テスト(serviceability testing)
- 文章テスト(documentation testing)
- 手続きテスト(procedure testing)
- 認可テスト エンドユーザの初期の仕様と現在の要求とについてプログラムを比較する過程
- 導入テスト ソフトウェア・エラーを見つけることではなく、導入のエラーを見つけることである
