単体テスト、統合テスト、スモークテスト、回帰テストとは何ですか？

単体テスト、統合テスト、スモークテスト、回帰テストとは何ですか？それらの違いは何ですか？それぞれに使用できるツールは何ですか？

たとえば、ユニットテストと統合テストにはJUnitとNUnitを使用しています。最後の2つ、スモークテストまたは回帰テスト用のツールはありますか？

• 単体テスト：クラスの単一メソッドのコントラクトの1点を指定してテストします。これは非常に狭く、明確に定義されたスコープを持つ必要があります。外の世界への複雑な依存関係と相互作用は、スタブ化またはモック化されます。

• 統合テスト：複数のサブシステムの正しい相互運用をテストします。2つのクラス間の統合のテストから、実稼働環境との統合のテストまで、そこにはすべてのスペクトルがあります。

• スモークテスト（別名 健全性 チェック）：テスト対象のシステムが呼び出されたときに正常に戻り、爆発しないことを確認するだけの単純な統合テスト。

  • 煙のテストはどちらも電子機器との類推であり、最初のテストは回路の電源投入時に行われます（煙が出ると、それは悪いことです！）...
  • ...そして、どうやら、配管システムでは、パイプのシステムが文字通り煙で満たされ、その後視覚的にチェックされます。何かが煙る場合は、システムに漏れがあります。

• 回帰テスト：バグが修正されたときに書かれたテスト。この特定のバグが再び発生しないようにします。正式名称は「非回帰テスト」です。また、アプリケーションを変更する前に行われるテストで、アプリケーションが同じ結果を提供することを確認できます。

これに、私は追加します：

• 受け入れテスト：機能またはユースケースが正しく実装されていることをテストします。これは統合テストに似ていますが、関連するコンポーネントではなく、使用するユースケースに重点を置いています。

• システムテスト：システムをブラックボックスとしてテストします。他のシステムへの依存関係は、多くの場合、テスト中にモック化またはスタブ化されます（それ以外の場合は、統合テストの詳細になります）。

• プレフライトチェック：「マシン上のビルド」症候群を緩和するために、本番環境のような環境で繰り返されるテスト。多くの場合、これは、環境のような生産環境で受け入れテストまたは煙テストを行うことによって実現されます。

• 単体テスト：クラスの内部動作をテストする自動テスト。他のリソースとは関係のないスタンドアロンのテストでなければなりません。
• 統合テスト：環境で行われる自動テスト。単体テストに似ていますが、外部リソース（db、ディスクアクセス）を使用します。
• 回帰テスト：新しい機能またはバグ修正を実装した後、過去に機能していたシナリオを再テストします。ここでは、新しい機能が既存の機能を壊す可能性について説明します。
• 煙のテスト：テストを続行するかどうかをテスターが結論付ける最初のテスト。

定義はそれぞれ少しずつ異なり、多くの場合灰色の領域があります。しかしながら：

• 単体テスト：これは（可能な限り隔離された）少しだけ機能しますか？
• 統合テスト：これらの2つ（またはそれ以上）のコンポーネントは一緒に動作しますか？
• 煙のテスト：このシステム全体（できる限り実動システムに近い）は、かなりうまく連動していますか？（つまり、ブラックホールが発生しないと私たちは合理的に確信していますか？）
• 回帰テスト：以前に修正したバグを誤って再導入していないか？

私が気付いたばかりの新しいテストカテゴリは、カナリアテストです。カナリアテストがされ、自動化、非破壊検査で定期的に実行中のライブ、それは今までに失敗した場合、本当に悪い何かが起こったように、環境。

例は次のとおりです。

• 開発/証言でのみ利用できるはずのデータがライブで表示されましたか？
• バックグラウンドプロセスの実行に失敗しましたか？
• ユーザーはログオンできますか？

ソフトウェアテスト手法に最適なWeb​​サイトの1つからの回答：

ソフトウェアテストの種類–完全なリストはここをクリック

これはかなり長い説明なので、ここには貼り付けません。すべてのテスト手法を知りたい人には役立つかもしれません。

単体テスト：特定のコンポーネント（つまりクラス）が設計どおりに関数を作成または変更したことを確認します。このテストは手動でも自動でも可能ですが、コンポーネントの境界を超えて移動することはありません。

統合テスト：特定のコンポーネントの相互作用が設計どおりに機能することを確認します。統合テストは、ユニットレベルまたはシステムレベルで実行できます。これらのテストは手動または自動で行うことができます。

回帰テスト：新しい欠陥が既存のコードに導入されていないことを確認します。これらのテストは手動または自動で行うことができます。

SDLC（ウォーターフォール、RUP、アジャイルなど）に応じて、特定のテストが「フェーズ」で実行されることもあれば、多かれ少なかれすべて同時に実行されることもあります。たとえば、ユニットテストは、統合および回帰テストのためにテスターに​​コードを引き渡す開発者に限定される場合があります。ただし、別のアプローチでは、開発者が単体テストとある程度の統合および回帰テストを行う場合があります（TDDアプローチと継続的な統合および自動化された単体テストと回帰テストを併用）。

ツールセットは、コードベースに大きく依存しますが、ユニットテスト（JUnit）のための多くのオープンソースツールがあります。HP（Mercury）QTPまたはBorlandのSilk Testは、どちらも自動統合および回帰テスト用のツールです。

単体テスト：アプリケーション内の個々のモジュールまたは独立したコンポーネントのテストは、単体テストとして知られています。単体テストは開発者が行います。

統合テスト：すべてのモジュールを組み合わせ、アプリケーションをテストして、モジュール間の通信とデータフローが適切に機能しているかどうかを確認します。このテストは開発者によっても行われました。

煙のテスト 煙のテストでは、アプリケーションを浅く広い方法でチェックします。煙のテストでは、アプリケーションの主な機能をチェックします。アプリケーションにブロッカーの問題がある場合、開発者チームに報告し、開発チームはそれを修正して欠陥を修正し、テストチームに返します。テストチームは、すべてのモジュールをチェックして、1つのモジュールで行われた変更が他のモジュールに影響を与えるかどうかを確認します。煙のテストでは、テストケースはスクリプト化されています。

変更されていないモジュールが欠陥を引き起こさないことを確認するために、同じテストケースを繰り返し実行する回帰テスト。回帰テストは機能テストの対象になります

回帰試験-

「リグレッションテストでは、変更されたソフトウェアに対して以前のテストを再実行し、現在のソフトウェアで行われた変更が既存のソフトウェアの機能に影響しないことを確認します。」

なぜこれらのレベルのテストがあるのか​​、例でそれらが実際に何を意味するのかについていくつかのコンテキストを追加して説明したかっただけです

マイクコーンの著書「Succeeding with Agile」では、プロジェクトの自動テストにアプローチする方法として「Testing Pyramid」が登場しました。このモデルにはさまざまな解釈があります。モデルは、どのような種類の自動テストを作成する必要があるか、テスト対象のアプリケーションに関するフィードバックをいかに早く提供できるか、誰がこれらのテストを作成するかを説明します。基本的に、どのプロジェクトにも必要な自動テストには3つのレベルがあり、それらは次のとおりです。

単体テスト- これらは、ソフトウェアアプリケーションの最小コンポーネントをテストします。これは文字通り、一部の入力に基づいて値を計算するコード内の1つの関数である可能性があります。この関数は、アプリケーションを構成するハードウェア/ソフトウェアコードベースの他のいくつかの関数の一部です。

たとえば、Webベースの電卓アプリケーションを見てみましょう。ユニットテストが必要なこのアプリケーションの最小コンポーネントは、加算を実行する関数、減算を実行する関数などです。これらの小さな関数をすべて組み合わせて、計算機アプリケーションを構成します。

これらのテストは通常​​、ソフトウェアアプリケーションと同じプログラミング言語で記述されるため、これまで開発者はこれらのテストを記述しています。JUnitおよびNUnit（Java用）、MSTest（C＃および.NET用）、およびJasmine / Mocha（JavaScript用）などのユニットテストフレームワークがこの目的で使用されます。

単体テストの最大の利点は、UIの下で非常に高速に実行され、アプリケーションに関する迅速なフィードバックを得ることができることです。これは、自動テストの50％以上を構成する必要があります。

API /統合 テスト-これらは、ソフトウェアシステムのさまざまなコンポーネントを一緒にテストします。コンポーネントには、テストデータベース、API（アプリケーションプログラミングインターフェース）、サードパーティのツール、およびアプリケーションと共にサービスが含まれます。

たとえば、上記の計算機の例では、Webアプリケーションはデータベースを使用して値を保存し、APIを使用してサーバー側の検証を実行し、サードパーティのツール/サービスを使用して結果をクラウドに公開し、さまざまな場所で利用できるようにします。プラットフォーム。

これまで、開発者または技術的なQAは、Postman、SoapUI、JMeter、およびTestimのような他のツールなどのさまざまなツールを使用して、これらのテストを記述していました。

これらは内部で実行されるため、UIテストよりもはるかに高速に実行されますが、システムのさまざまな独立したコンポーネント間の通信をチェックしてシームレスな統合を確保する必要があるため、単体テストよりも少し時間がかかる場合があります。これは自動テストの30％以上を構成する必要があります。

UIテスト- 最後に、アプリケーションのUIを検証するテストがあります。これらのテストは通常​​、アプリケーション全体のフローをエンドツーエンドでテストするために作成されます。

例-電卓アプリケーションでは、エンドツーエンドのフローは、ブラウザを開く->電卓アプリケーションのURLを入力する->ユーザー名/パスワードでログインする->電卓アプリケーションを開く->電卓でいくつかの操作を実行する-> UIからの結果の確認->アプリケーションからのログアウト。これは、エンドツーエンドのフローであり、UIの自動化に適しています。

歴史的に、テクニカルQAまたは手動のテスターはUIテストを作成します。彼らは、SeleniumのようなオープンソースフレームワークやTestimのようなUIテストプラットフォームを使用して、テストの作成、実行、保守を行っています。これらのテストでは、スクリーンショット、ログ、テストレポートを通じて、テストの実行方法、期待される結果と実際の結果の違いを確認できるため、より視覚的なフィードバックが得られます。

UIテストの最大の制限は、ユニットおよびAPIレベルのテストと比較して遅いことです。そのため、自動テスト全体の10〜20％にすぎません。

次の2種類のテストはプロジェクトによって異なる場合がありますが、アイデアは

煙のテスト

これは、上記の3つのレベルのテストを組み合わせることができます。アイデアは、すべてのコードチェックイン中に実行し、システムの重要な機能が期待どおりに機能していることを確認することです。新しいコードの変更がマージされた後。障害に関するフィードバックを迅速に得るには、通常5〜10分で実行する必要があります。

回帰テスト

通常、少なくとも1日に1回実行され、システムのさまざまな機能をカバーします。アプリケーションが期待どおりに機能していることを確認します。これらは、煙のテストよりも詳細であり、重要ではないものを含む、アプリケーションのより多くのシナリオをカバーしています。

単体テストは、可能な実装の最小部分に向けられています。Javaでは、これは単一のクラスをテストしていることを意味します。クラスが他のクラスに依存している場合、これらは偽物です。

テストが複数のクラスを呼び出す場合、それは統合テストです。

完全なテストスイートは実行に時間がかかる場合があるため、変更後、多くのチームがテストを実行して、重大な破損を検出します。たとえば、URIを重要なリソースに分割しました。これらは煙のテストです。

回帰テストはすべてのビルドで実行され、壊れたものをキャッチすることで効果的にリファクタリングできます。どのような種類のテストでも回帰テストを実行できますが、障害の原因を見つけるには単体テストが最も役立ちます。

• 統合テスト：統合テストは別の要素の統合です
• 煙のテスト：煙のテストは、ビルドバージョンテストとも呼ばれます。煙のテストは、テスト中のソフトウェアがさらなるテストの準備ができている/安定しているかどうかを確認するために実行される最初のテストプロセスです。
• 回帰テスト：回帰テストは繰り返しテストです。新しいソフトウェアが別のモジュールで影響を受けるかどうか。
• 単体テスト：ホワイトボックステストです。開発者のみが関与します

単体テスト：開発が完了した後、QAの要件を準備する前に、テスト側から問題を見つけるために、常に開発者が実行します。

統合テスト：一部のデータ/機能出力が1つのモジュールから他のモジュールに駆動される場合、テスターはモジュールからサブモジュールへの検証を検証する必要があります。または、システムデータを使用して統合するサードパーティツールを使用している場合は、システム内。

煙のテスト：システムを高レベルのテスト用に検証し、変更またはコードが公開される前に、表示ストッパーのバグを見つけようとするテスター。

回帰テスト：テスターは、新たに強化されたシステムに実装された変更またはシステムの変更により、既存の機能を検証するために回帰を実行しました。

ユニットテスト

ユニットテストは通常​​開発者側で行われますが、テスターはテストがユニットごとに行われるこのタイプのテストで部分的に進化しています。Java JUnitのテストケースでは、記述されたコードが完全に設計されているかどうかをテストすることもできます。

統合テスト：

このタイプのテストは、すべてまたは一部のコンポーネントが統合されている単体テストの後に実行できます。このタイプのテストは、コンポーネントが統合されたときに、互いの作業能力または機能に影響を与えることを確認しますか？

煙のテスト

このタイプのテストは、システムが正常に統合され、運用サーバーに移行する準備ができたときに最後に行われます。

このタイプのテストは、最初から最後まですべての重要な機能が正常に動作し、システムが運用サーバーに展開できる状態であることを確認します。

回帰試験

このタイプのテストは、開発者がいくつかの問題を修正したときに、システムに意図しない/望ましくない欠陥がないことをテストするために重要です。このテストでは、すべてのバグが正常に解決されていること、および他の問題が発生していないことも確認します。

ソフトウェアのビルド後に煙と健全性のテストが実行され、テストを開始するかどうかが識別されます。サニティは、煙のテスト後に実行される場合とされない場合があります。それらは個別に、または同時に実行できます-正気は煙の直後です。

健全性テストはより詳細で時間がかかるため、ほとんどの場合、自動化する価値があります。

煙のテストの実行には通常5〜30分かかりません。それはより一般的です。ソフトウェア全体の安定性がさらなるテストに十分であり、問​​題がないことを確認するために、システム全体の少数の中核機能をチェックし、計画されたテストケースの実行をブロックします。

健全性テストは煙よりも詳細であり、新しいビルドの規模によっては15分から1日かかる場合があります。これは、進行または再テスト後に実行される、より特殊なタイプの受け入れテストです。回帰テストを大規模に実行する前に、特定の新しい機能やバグ修正のコア機能とそれらに密接に関連する機能をチェックして、必要な運用ロジックに関して機能していることを確認します。

すでにいくつかの良い答えがありますが、私はそれらをさらに洗練させたいと思います：

単体テストは、ここでのホワイトボックステストの唯一の形式です。その他はブラックボックステストです。ホワイトボックステストは、入力を知っていることを意味します。あなたはメカニズムの内部の仕組みを知っており、それを検査することができ、出力を知っています。ブラックボックステストでは、入力が何であるか、出力が何であるかがわかります。

したがって、ここでは単体テストのみがホワイトボックステストです。

• ユニットテストでは、特定のコードをテストします。通常はメソッド。
• 統合テストでは、新しい機能のソフトウェアが他のすべてと統合できるかどうかをテストします。
• 回帰試験。これは、何も壊していないことを確認するために行われたテストです。以前は機能していたものはすべて機能するはずです。
• 煙のテストは、より強力なテストに参加する前に、すべてが問題ないことを確認するためのクイックテストとして行われます。

煙のテストはここですでに説明されており、簡単です。回帰テストは統合テストの下にあります。

自動テストは2つだけに分けることができます。

単体テストと統合テスト（これがすべての問題です）

統合テスト、機能テスト、回帰テスト、UIテストなどのすべてのテストに「ロングテスト（LT）」というフレーズを使用し、ユニットテストを「ショートテスト」と呼びます。

LTの例としては、Webページの自動読み込み、アカウントへのログイン、本の購入などがあります。テストに合格すると、ライブサイトで同じように実行される可能性が高くなります（したがって、「より良いスリープ」リファレンス）。Long = Webページ（開始）とデータベース（終了）の間の距離。

そして、これは単体テストよりも統合テスト（ロングテスト）の利点を議論する素晴らしい記事です。

回帰テスト-バグ修正をカバーまたはチェックするソフトウェアテストの一種です。提供された修正により、バグ修正に関連する機能が変更または変更されることはありません。このようなプロセスで見つかった問題は、回帰問題と呼ばれます。

煙のテスト：ビルド/ソフトウェアをさらにQAテストに受け入れるかどうかを決定するために行われる一種のテストです。