differences between unit testing
ユニット、統合、機能テストの詳細な比較:
どのソフトウェアアプリケーションでも、単体テストと統合テストの両方が非常に重要です。それぞれが独自のプロセスを使用してソフトウェアアプリケーションをテストするためです。
しかし、いずれかまたは両方でさえ、どの時点でも機能テストを置き換えることはできません。
学習内容:
単体テストと統合テストと機能テスト
ユニットテスト これは、アプリケーションの個々のモジュールを分離して(依存関係との相互作用なしに)テストして、コードが正しく機能していることを確認することを意味します。
統合テスト 異なるモジュールをグループとして組み合わせたときに正常に機能しているかどうかを確認することを意味します。
機能テスト システムの機能のスライスをテストして(依存関係と相互作用する可能性があります)、コードが正しいことを行っていることを確認することを意味します。
機能テストは統合テストに関連していますが、すべてのコードが一緒に実行されているアプリケーション全体の機能をチェックするテストを意味します。これはほぼスーパー統合テストです。
単体テストでは、システムの単一コンポーネントをチェックすることを検討しますが、機能テストでは、システム要件仕様に記載されている目的の機能に対してアプリケーションの動作をチェックすることを検討します。一方、統合テストでは、システム内の統合モジュールをチェックすることを検討します。
そして、最も重要なことは、投資収益率(ROI)を最適化するために、コードベースには、可能な限り多くの単体テスト、少ない統合テスト、および最小限の機能テストを含める必要があります。
これは、次のテストピラミッドで最もよく示されています。
単体テストは、記述が簡単で、実行も高速です。上記のピラミッドに示されているように、テストの実装と保守にかかる時間と労力は、単体テストから機能テストへと増加します。
例:
単純化しすぎた例を使用して、これら3つのタイプのテストを理解しましょう。
例えば 。機能的な携帯電話の場合、必要な主要部品は「バッテリー」と「SIMカード」です。
ユニットテストの例 –バッテリーの寿命、容量、およびその他のパラメーターがチェックされます。 Simカードのアクティブ化がチェックされます。
統合テストの例 –バッテリーとSIMカードが統合されている、つまり携帯電話を起動するために組み立てられている。
機能テストの例 –携帯電話の機能は、その機能とバッテリー使用量、およびsimカード機能の観点からチェックされます。
素人の言葉で例を見てきました。
それでは、ログインページの技術的な例を見てみましょう。
xmlファイルを開く方法
ほとんどすべてのWebアプリケーションでは、ユーザー/顧客がログインする必要があります。そのためには、すべてのアプリケーションに次の要素を含む「ログイン」ページが必要です。
- アカウント/ユーザー名
- パスワード
- ログイン/サインインボタン
単体テストの場合、次のテストケースが考えられます。
- フィールド長–ユーザー名とパスワードのフィールド。
- 入力フィールドの値は有効である必要があります。
- ログインボタンは、有効な値(フォーマットと縦方向)が両方のフィールドに入力された後にのみ有効になります。
統合テストの場合、テストケースは次のとおりです。
- 有効な値を入力してログインボタンを押すと、ユーザーにウェルカムメッセージが表示されます。
- 有効な入力を行って(ログイン)ボタンをクリックすると、ユーザーはウェルカムページまたはホームページに移動する必要があります。
さて、ユニットテストと統合テストが完了したら、追加のテストを見てみましょう。 機能テストの対象となるテストケース:
- 期待される動作がチェックされます。つまり、ユーザーは有効なユーザー名とパスワードの値を入力した後、ログインボタンをクリックしてログインできます。
- ログインに成功した後に表示されるウェルカムメッセージはありますか?
- 無効なログインで表示されるはずのエラーメッセージはありますか?
- ログインフィールド用に保存されたサイトCookieはありますか?
- 非アクティブ化されたユーザーはログインできますか?
- パスワードを忘れたユーザーのための「パスワードを忘れた」リンクはありますか?
機能テストを実行しているときに機能テスターの頭に浮かぶそのようなケースはもっとたくさんあります。ただし、開発者は、ユニットと統合のテストケースを作成するときにすべてのケースを取り上げることはできません。
したがって、ユニットテストと統合テストの後でさえ、まだテストされていないシナリオがたくさんあります。
今度は、ユニット、統合、機能テストを1つずつ検討します。
ユニットテストとは何ですか?
名前が示すように、このレベルには「ユニット」のテストが含まれます。
ここで、ユニットは、テスト可能なアプリケーションの最小部分である可能性があります。それは、最小の個々の関数、メソッドなどです。ソフトウェア開発者は、ユニットテストケースを作成する人です。ここでの目的は、要件とユニットの予想される動作を一致させることです。
以下は、ユニットテストとその利点に関するいくつかの重要なポイントです。
- 単体テストは、ソフトウェア開発者が使用する統合テストの前に行われます。 ホワイトボックステスト手法 。
- ユニットテストでは、肯定的な動作、つまり有効な入力の場合の正しい出力だけでなく、無効な入力で発生する障害もチェックされます。
- 早い段階で問題/バグを見つけることは非常に役立ち、プロジェクト全体のコストを削減します。コードを統合する前に単体テストが行われるため、この段階で見つかった問題は非常に簡単に解決でき、その影響も非常に少なくなります。
- 単体テストは、コードの小さな断片または個々の関数をテストするため、これらのテストケースで見つかった問題/エラーは独立しており、他のテストケースに影響を与えません。
- もう1つの重要な利点は、単体テストケースが単純化され、コードのテストが容易になることです。そのため、コードの最新の変更のみがテストされるため、後の段階でも問題を解決することが容易になります。
- 単体テストは時間とコストを節約し、再利用可能で保守が容易です。
JUnit (( Javaフレームワーク )、PHPUnit(PHPフレームワーク)、NUnit(.Netフレームワーク)などは、さまざまな言語で使用される一般的な単体テストツールです。
統合テストとは何ですか?
統合テストとは、システムのさまざまな部分の統合をテストすることです。システムの2つの異なる部分またはモジュールが最初に統合され、次に統合テストが実行されます。
統合テストの目的は、統合されたときのシステムの機能、信頼性、およびパフォーマンスをチェックすることです。
統合テストは、最初に単体テストされるモジュールで実行され、次に統合テストは、モジュールの組み合わせが目的の出力を提供するかどうかを定義します。
統合テストは、独立したテスターまたは開発者のいずれかが実行できます。
統合テストのアプローチには3つの異なるタイプがあります。それらのそれぞれについて簡単に説明しましょう。
a)ビッグバン統合アプローチ
このアプローチでは、すべてのモジュールまたはユニットが統合され、全体として一度にテストされます。これは通常、システム全体が単一の時点で統合テストの準備ができたときに行われます。
統合テストのこのアプローチをシステムテストと混同しないでください。モジュールまたはユニットの統合のみがテストされ、システムテストで行われるようにシステム全体はテストされません。
ビッグバンアプローチの主要な 利点 統合されたすべてが一度にテストされるということです。
1つのメジャー 不利益 障害の特定が困難になるということです。
例: 次の図では、ユニット1からユニット6が統合され、ビッグバンアプローチを使用してテストされています。
b)トップダウンアプローチ
ユニット/モジュールの統合は、トップレベルからボトムレベルまで段階的にテストされます。
最初のユニットは、書くことによって個別にテストされます スタブをテストする 。この後、最後のレベルがまとめられてテストされるまで、下位レベルが1つずつ統合されます。
トップダウンアプローチは、実際の環境で物事がどのように発生するかと一致しているため、非常に有機的な統合方法です。
唯一の 懸念 このアプローチでは、主要な機能が最後にテストされます。
c)ボトムアップアプローチ
ユニット/モジュールは、すべてのレベルのユニット/モジュールが統合され、1つのユニットとしてテストされるまで、下から上に段階的にテストされます。と呼ばれる刺激プログラム 運転手 このアプローチで使用されます。下位レベルで問題やエラーを検出する方が簡単です。
メジャーな 不利益 このアプローチの利点は、すべてのユニットが統合された場合にのみ、上位レベルの問題を特定できるということです。
単体テストと統合テスト
単体テストと統合テストについて十分に議論したので、次の表で2つの違いを簡単に見ていきましょう。
ユニットテスト | 統合テスト |
---|---|
テストの初期段階で実行され、その後いつでも実行できます | 単体テストの後、システムテストの前に実行する必要があります |
システム全体の単一のコンポーネントをテストします。つまり、ユニットを分離してテストします。 | 連携して動作するシステムコンポーネントをテストします。つまり、複数のユニットのコラボレーションをテストします。 |
実行が速く | 遅くなる可能性があります |
外部依存はありません。外部の依存関係はすべてモックアウトまたはスタブアウトされます。 | 外部の依存関係(データベース、ハードウェアなど)との相互作用が必要です |
シンプル | 繁雑 |
開発者が実施 | テスターによる実施 |
ホワイトボックステストの一種です | ブラックボックステストの一種です |
安いメンテナンス | 高価なメンテナンス |
モジュール仕様から始まります | インターフェイス仕様から始まります |
単体テストは、コードの各小さな部分が意図したとおりに実行されているかどうかをチェックするだけなので、範囲が狭くなります。 | アプリケーション全体をカバーするため、より広い範囲があります |
単体テストの結果は、コードの詳細な可視性です | 統合テストの結果は、統合構造の詳細な可視性です。 |
個々のモジュールの機能内の問題のみを明らかにします。統合エラーやシステム全体の問題は公開されません。 | 異なるモジュールが相互作用してシステム全体を形成するときに発生するバグを明らかにする |
機能テスト
に ブラックボックステスト手法 、特定の入力を提供することで目的の出力を生成するためにアプリケーションの機能がテストされる場合、「機能テスト」と呼ばれます。
私たちの中で ソフトウェアテストプロセス 、要件とシナリオに従ってテストケースを作成することでこれを行います。どの機能でも、作成されるテストケースの数は1つから多数までさまざまです。
テストケースは基本的に次の部分で構成されています。
- テストの概要
- 前提条件(ある場合)
- テストケースの入力手順
- テストデータ(ある場合)
- 期待される出力
- メモ(ある場合)
「要件ベース」および「ビジネスシナリオベース」 実行される機能テストの2つの形式です。
要件ベースのテストでは、要件に従ってテストケースが作成され、それに応じてテストされます。ビジネスシナリオベースの機能テストでは、ビジネスの観点からすべてのシナリオを念頭に置いてテストを実行します。
しかし、メジャー 不利益 機能テストの可能性は、テストの冗長性といくつかの論理エラーを見逃す可能性です。
正確な違い
それらの違いを見てみましょう。
主なものは次のとおりです。
ユニットテスト | 統合テスト | 機能テスト | |
---|---|---|---|
定義と目的 | 最小のユニットまたはモジュールを個別にテストします。 | タスクを実行するために組み合わされた2つ以上のユニット/モジュールの統合をテストします。 | 要件に従ってアプリケーションの動作をテストします。 |
複雑 | 最小のコードが含まれているため、それほど複雑ではありません。 | 単体テストよりも少し複雑です。 | ユニットテストや統合テストに比べて複雑です。 |
テスト技術 | ホワイトボックステスト手法。 | ホワイトボックスとブラックボックスのテスト手法。グレーボックステスト | ブラックボックステスト手法。 |
主な注意 | 個々のモジュールまたはユニット。 | モジュールまたはユニットの統合。 | アプリケーション全体の機能。 |
エラー/対象となる問題 | ユニットテストは、モジュールで頻繁に発生する可能性のある問題を見つけます。 | 統合テストでは、さまざまなモジュールの統合中に発生する可能性のある問題を見つけます。 | 機能テストでは、アプリケーションがその機能を実行できない問題が見つかります。これには、シナリオベースの問題も含まれます。 |
エスケープを発行 | 問題が回避される可能性はありません。 | 問題が回避される可能性が低くなります。 | 実行するテストのリストは常に無限であるため、問題が回避される可能性が高くなります。 |
また読む=> 機能テストとは
ポートフォワーディングとポートトリガーの違いは何ですか
結論
これら3つのテストタイプはすべて相関しています。
完全なカバレッジを実現するには、コードのパス/行の単体テスト、「ユニット」が連携して機能することを保証するための機能テストと統合テストが必要です。
この記事で、ユニット、統合、機能テストとその違いについて明確なアイデアが得られたと思いますが、これらの形式のテストにはさらに多くのことがあります。