ソフトウェアテスト

ソフトウェアテストとは、選択された入力を用いてプログラムを動的に実行し、欠陥を検出し、ソフトウェアが意図したとおりに動作するという確信を得るための活動です。

Definition

ソフトウェアテストとは、実際の動作と要求される動作との間の不一致を明らかにし、ソフトウェアの信頼性を推定するために、テストケース（入力と期待される出力の組み合わせ）を設計し実行する活動です。

Scope

このトピックでは、テストレベル（単体、統合、システム、受け入れ）、同値分割、境界値分析、組み合わせテストなどのブラックボックステクニック、コードカバレッジ基準に基づくホワイトボックステクニック、回帰テスト、パフォーマンステスト、探索的テスト、テスト自動化、テストの適切性とカバレッジの理論について扱います。

Core questions

• 扱いきれないほど膨大な入力空間から、どのように効果的なテストケースを選択するのか？
• テストスイートの適切性を測るカバレッジ基準とは何か？
• 単体テストから受け入れテストまでのテストレベルは、どのように互いに補完し合うのか？
• テストはどのように自動化され、デリバリーパイプラインに統合できるのか？

Key theories

ブラックボックスおよびホワイトボックスのテスト設計

ブラックボックステクニックは、分割と境界分析を通じて仕様からテストを導出し、ホワイトボックステクニックは、カバレッジ基準に導かれてコード構造からテストを導出します。これら二つは相補的です。

カバレッジとテストの適切性基準

ステートメント、ブランチ、条件カバレッジなどの適切性基準、および制御フローグラフやデータフローグラフに基づくモデルベースの基準は、テストスイートがプログラムをどれだけ徹底的に実行するかについて測定可能な目標を与えます。

Clinical relevance

テストは、リリース前にソフトウェアが正しく動作することを保証するための最も広く実践されている手段です。適切に設計された自動テストは、早期に回帰を検出し、リファクタリングと継続的デリバリーをサポートし、信頼性の高いソフトウェアにとって中心的な役割を果たします。

Evidence & guidelines

ISO/IEC/IEEE 29119は、ソフトウェアテストのプロセス、文書化、および技術に関する国際標準を提供しており、SWEBOKのソフトウェアテスト知識領域は、合意された概要を示しています。

History

テストは、1979年のマイヤーズによる体系的な扱いにより、アドホックなデバッグから専門分野へと成熟しました。カバレッジ理論、モデルベーステスト、テスト自動化は、その後の数十年で発展し、テスト駆動開発と継続的インテグレーションにより、自動テストはアジャイルプラクティスの中心となりました。

Debates

どの程度の自動テストが価値があるか

単体テスト、統合テスト、エンドツーエンドの自動テストの適切なバランスについては議論があります。テストピラミッドは、遅いエンドツーエンドテストよりも多くの高速な単体テストを推奨しますが、批評家は、このバランスはシステムの種類とリスクに依存すると指摘しています。

Key figures

• Glenford Myers
• Paul Ammann
• Jeff Offutt
• Boris Beizer

Seminal works

• myers2011
• ammann2016
• swebok2014

Frequently asked questions

なぜ可能なすべての入力をテストできないのですか？

ほとんどのプログラムにとって、可能な入力と実行パスの空間は天文学的に大きいか無限であるため、網羅的なテストは実現不可能です。代わりに、テストは、テストあたりの欠陥検出を最大化するために、体系的な手法を用いて代表的なケースと境界ケースを選択します。

テストレベルの違いは何ですか？

単体テストは個々のコンポーネントを単独で検証し、統合テストはそれらの相互作用をチェックし、システムテストはシステム全体を要件に対して評価し、受け入れテストはユーザーのニーズを満たしていることを確認します。各レベルは異なる種類の欠陥を対象としています。