ユニットテスト、インテグレーションテスト、ファンクショナルテストの詳細な比較:
ソフトウェアアプリケーションのテストには、単体テストと統合テストの両方が非常に重要であり、それぞれがユニークなプロセスを採用しています。
しかし、どちらか一方、あるいは両方が、いつの間にか機能テストに取って代わることはできません。
単体テストと統合テストと機能テストの比較
単体テスト アプリケーションの個々のモジュールを分離して(依存関係との相互作用なしに)テストし、コードが正しく動作していることを確認することです。
統合テスト とは、異なるモジュールをグループとして組み合わせたときに、正常に動作するかどうかを確認することです。
機能テスト は、システム内の機能の一部(依存関係との相互作用がある)をテストして、コードが正しいことを行っていることを確認することです。
機能テストは統合テストと関連しますが、すべてのコードが一緒に動作している状態でアプリケーション全体の機能をチェックするテストを意味し、ほぼ超統合テストと言えます。
ユニットテストはシステムの単一コンポーネントをチェックするものであり、機能テストはシステム要求仕様に記述された意図した機能に対してアプリケーションの動作をチェックするものです。 一方、統合テストはシステム内の統合モジュールをチェックするものです。
そして、最も重要なことは、投資収益率(ROI)を最適化するために、コードベースにはできるだけ多くのユニットテスト、少ない統合テスト、最小限の機能テストが必要であるということです。
このことは、次のテストピラミッドによく表れています:
単体テストは書きやすく、実行も早いのですが、単体テストから機能テストになるにつれ、上記のピラミッドのようにテストの実装やメンテナンスにかかる時間や労力が増えていきます。
例
この3種類のテストを、簡略化しすぎた例で理解してみましょう。
例 携帯電話には、主に「電池」と「SIMカード」が必要です。
ユニットテスト例 - バッテリーの寿命や容量などをチェックします。 シムカードの起動をチェックします。
統合テスト例 - 電池とSIMカードが一体となり、携帯電話がスタートします。
ファンクショナルテスト例 - 携帯電話の機能は、SIMカードの設備だけでなく、機能やバッテリーの使用状況もチェックされます。
素人目にもわかる例を見てきました。
さて、ここで技術的な例として、ログインページを取り上げてみましょう:
ほとんどのWebアプリケーションでは、ユーザーや顧客がログインする必要があります。 そのため、すべてのアプリケーションは、以下の要素を持つ「ログイン」ページを持つ必要があります:
- アカウント/ユーザー名
- パスワード
- ログイン/サインインボタン
ユニットテストの場合、以下のようなテストケースが考えられます:
- フィールドの長さ - ユーザー名とパスワードのフィールド。
- 入力フィールドの値は有効でなければならない。
- ログインボタンは、両方のフィールドに有効な値(Formatとlengthwise)が入力された場合にのみ有効になります。
統合テストの場合、以下のようなテストケースが考えられます:
- ユーザーは、有効な値を入力し、ログインボタンを押すと、ウェルカムメッセージを見ることができます。
- ユーザーは、有効な入力を行い、ログインボタンをクリックした後、ウェルカムページまたはホームページに移動する必要があります。
さて、単体テストと統合テストが終わった後、追加で見てみましょう。 機能テストに考慮されるテストケース
- ユーザー名とパスワードを入力し、ログインボタンをクリックすることで、ユーザーがログインできるかどうかという期待される動作がチェックされます。
- ログイン成功後に表示されるウェルカムメッセージはありますか?
- 無効なログイン時に表示されるべきエラーメッセージはありますか?
- ログインフィールドのための保存されたサイトクッキーはありますか?
- 不活性化されたユーザーはログインできるのか?
- パスワードを忘れてしまったユーザーのために、「パスワードを忘れる」リンクはないのですか?
しかし、開発者がユニットテストやインテグレーションテストのケースを作成する際に、すべてのケースを取り上げることはできません。
そのため、単体テストや統合テストを行っても、まだテストできていないシナリオがたくさんあるのです。
ここで、ユニットテスト、インテグレーションテスト、ファンクショナルテストを一つずつ検証していくことにします。
ユニットテストとは?
このレベルでは、その名の通り、「ユニット」をテストします。
ここでいうユニットとは、テスト可能なアプリケーションの最小の部分であり、個々の関数やメソッドなどを指します。 ソフトウェア開発者は、ユニットのテストケースを作成します。 ここでの目的は、要件とユニットの期待される動作の一致です。
以下、ユニットテストに関する重要なポイントとそのメリットについて説明します:
- ユニットテストは、統合テストの前に、ソフトウェア開発者がホワイトボックステスト技法を用いて実施します。
- ユニットテストでは、有効な入力があった場合の正しい出力というポジティブな動作だけでなく、無効な入力で発生する不具合も確認します。
- ユニットテストはコードを統合する前に行われるため、この段階で発見された問題は非常に簡単に解決でき、その影響も非常に小さくなります。
- ユニットテストは、コードの小さな断片や個々の機能をテストするもので、これらのテストケースで見つかった問題やエラーは独立しており、他のテストケースに影響を与えることはありません。
- また、ユニットテストケースを使うことで、コードのテストが簡略化され、最新の変更点のみをテストすることができるため、後の段階での問題解決も容易になります。
- ユニットテストは時間とコストを削減し、再利用可能でメンテナンスが容易です。
JUnit(Javaフレームワーク)、PHPUnit(PHPフレームワーク)、NUnit(.Netフレームワーク)などは、言語ごとに使い分けるユニットテスト・ツールとして有名です。
インテグレーション・テストとは?
統合テストとは、システムの異なる部分を統合してテストすることです。 システムの2つの異なる部分またはモジュールをまず統合し、その後統合テストを行います。
統合テストの目的は、システムを統合したときの機能、信頼性、性能を確認することである。
統合テストは、まずユニットテストされたモジュールに対して行われ、モジュールの組み合わせが望ましい出力を与えるかどうかを定義する。
統合テストは、独立したテスターが行う場合と、開発者が行う場合があります。
統合テストのアプローチには3つの種類があります。 それぞれについて簡単に説明します:
a) ビッグバン統合アプローチ
この方法では、すべてのモジュールまたはユニットを統合し、全体として一度にテストします。 これは通常、システム全体が一度に統合テストできる状態にあるときに行われます。
統合テストは、モジュールやユニットの統合だけをテストするもので、システムテストのようにシステム全体をテストするものではありません。
ビッグバン・アプローチの主要な りえき は、統合されたすべてのものが一度にテストされることです。
1つの主要な 不利 は、故障の特定が困難になることです。
例 下図では、ユニット1~ユニット6をビッグバン方式で統合し、テストしています。
b) トップダウンアプローチ
ユニット/モジュールの統合は、トップレベルからボトムレベルまで、段階的にテストされます。
最初のユニットはテストSTUBSを書くことで個別にテストされ、その後、下位のレベルが1つずつ統合され、最後のレベルがまとめられテストされます。
トップダウンのアプローチは、現実の環境での物事の起こり方と一致するため、非常に有機的な統合の方法です。
のみである。 かんしん この方法では、主要な機能が最後にテストされることになります。
c) ボトムアップ・アプローチ
ユニット/モジュールは、ボトムレベルからトップレベルまで、段階的にテストされ、すべてのレベルのユニット/モジュールが統合され、1つのユニットとしてテストされます。 というスティミュレータープログラム。 DRIVERS 低レベルの問題やエラーを検出しやすくするためです。
主要な 不利 このアプローチでは、すべてのユニットが統合された時点で初めて、より高いレベルの問題を特定することができます。
ユニットテストとインテグレーションテスト
単体テストと統合テストについて十分な議論ができたので、次の表で両者の違いを簡単に説明しよう:
単体テスト | 統合テスト |
---|---|
システム全体を構成する単一のコンポーネントをテストします。つまり、ユニットを分離してテストします。 | システムの構成要素が連携して動作するテスト、すなわち複数のユニットの連携をテストします。 |
実行の迅速化 | 動作が遅くなることがある |
外部依存がない。 外部依存がある場合は、モック化またはスタブ化される。 | 外部の依存関係(データベース、ハードウェアなど)とのやりとりを必要とする。 |
シンプル | コンプレックス |
開発者により実施された | テスターによる実施 |
ホワイトボックステストの一種である | ブラックボックステストの一種である |
テストの初期段階で実施し、その後はいつでも実施可能 | 単体テスト後、システムテスト前に実施すること。 |
安価なメンテナンス | 高価なメンテナンス |
モジュール仕様から始まる | インターフェース仕様から始まる |
ユニットテストは、コードの各小片が意図したとおりに動作しているかどうかをチェックするだけなので、範囲が狭い。 | アプリケーション全体をカバーするため、より広い範囲をカバーすることができる |
ユニットテストの成果は、コードの詳細な可視化である | 統合テストの成果は、統合構造を詳細に可視化することである |
個々のモジュールの機能内の問題のみを明らかにします。 統合エラーやシステム全体の問題を明らかにするものではありません。 | 異なるモジュールが相互に作用してシステム全体を形成する際に発生するバグを発見する。 |
ファンクショナル・テスト
ブラックボックステストとは、アプリケーションの機能をテストし、特定の入力があったときに目的の出力が得られるようにする手法で、「機能テスト」と呼ばれます。
私たちのソフトウェアテストプロセスでは、要件とシナリオに従ってテストケースを作成することでこれを行います。 どの機能についても、作成するテストケースの数は1つから多数まで様々な場合があります。
結論
これら3つのテストタイプは、すべて相関関係にあります。
完全なカバレッジを達成するためには、コードのパス/ラインに対するユニットテスト、機能テスト、そして「ユニット」がまとまった形で動作することを保証する統合テストが必要です。
この記事で、ユニットテスト、インテグレーションテスト、ファンクショナルテストについて、それぞれの違いと共に明確なアイデアを得られたと思いますが、これらのテスト形態にはもっと多くのものがあります!