単体テスト、統合テスト、スモークテスト、回帰テストとは何ですか。それらの違いは何ですか。そして、それぞれに使えるツールはどれですか?
例えば、私はユニットテストと統合テストにJUnitとNUnitを使います。煙テストや回帰テストのツールはありますか?
単体テスト :クラスの単一メソッドの契約の1点を指定してテストします。これは非常に狭くて明確に定義された範囲を持つべきです。複雑な依存関係や外部への相互作用は スタブまたはモック です。
統合テスト :複数のサブシステムの正しい相互動作をテストします。 2つのクラス間の統合のテストから、実稼働環境との統合のテストまで、あらゆる分野があります。
スモークテスト(別名健全性チェック) :テスト対象のシステムが呼び出されたときに正常に戻って爆発しないことを確認する単純な統合テスト。
回帰テスト :バグが修正されたときに書かれたテスト。それはこの特定のバグが二度と起こらないことを保証します。そのフルネームは "non-regression test"です。アプリケーションが同じ結果を提供することを確認するために、アプリケーションを変更する前に行われるテストもあります。
これに、私は加えます:
受け入れテスト :機能またはユースケースが正しく実装されていることをテストします。これは統合テストと似ていますが、関係するコンポーネントではなく提供するユースケースに焦点を当てています。
システムテスト :システムをブラックボックスとしてテストします。テスト中に他のシステムへの依存関係がモックされたりスタブされたりすることがよくあります(そうでなければ統合テストになります)。
飛行前チェック :「私のマシンで構築する」シンドロームを軽減するために、プロダクションのような環境で繰り返されるテスト。多くの場合、これはプロダクションのような環境で受け入れテストまたは煙テストを行うことによって実現されます。
誰もがわずかに異なる定義を持つでしょう、そしてしばしば灰色の領域があります。しかしながら:
黙示録的な歴史のトリビア:「煙探知」は潜水艦工学から来たものであり、そこから文字通りの煙が再び出てくるかどうかを調べるために船体に汲み上げられるものであり、潜水艦にとっては劇的な失敗となるだろう!
ソフトウェアテストのテクニックに関する最も良いWebサイトの1つからの回答:
ソフトウェアテストの種類 - 完全なリスト ここをクリック
これはかなり長い説明です。ここに貼り付けるつもりはありません。しかし、すべてのテスト手法を知りたいという人には役に立つかもしれません。
役に立つことを願っています:)
単体テスト:特定のコンポーネント(つまりクラス)が設計どおりに機能を作成または変更したことを検証する。このテストは手動でも自動でも可能ですが、コンポーネントの境界を超えては動きません。
統合テスト:特定のコンポーネントの相互作用が設計どおりに機能することを確認します。統合テストは、ユニットレベルまたはシステムレベルで実行できます。これらのテストは手動でも自動でも可能です。
回帰テスト:新しい欠陥が既存のコードに導入されていないことを確認します。これらのテストは手動でも自動でも可能です。
あなたのSDLC(滝、ルップ、アジャイルなど)に応じて、特定のテストが「段階」で実行されるか、またはすべて、多かれ少なかれ同時に実行されるかもしれません。たとえば、単体テストは、統合テストおよび回帰テストのためにコードをテスターに引き渡す開発者に限定される場合があります。ただし、別のアプローチでは、開発者が単体テストとある程度の統合および回帰テストを実行することがあります(TDDアプローチと継続的統合および自動化された単体および回帰テストを使用)。
ツールセットはコードベースに大きく依存しますが、単体テスト(JUnit)のための多くのオープンソースツールがあります。 HP(水銀)QTPまたはBorlandのSilktestは、どちらも自動統合および回帰テストのためのツールです。
単体テスト :アプリケーション内の個々のモジュールまたは独立したコンポーネントのテストは単体テストであることが知られています。単体テストは開発者によって行われます。
統合テスト :すべてのモジュールを組み合わせてアプリケーションをテストし、モジュール間の通信とデータフローが適切に機能しているかどうかを確認します。このテストは開発者によっても実行されます。
スモークテスト INスモークテスト彼らはアプリケーションを浅くて広い方法でチェックします。スモークテストで彼らはアプリケーションの主な機能性をチェックします。テストチームはそれを修正して欠陥を修正し、テストチームに返却します。テストチームはすべてのモジュールをチェックして、一方のモジュールで行われた変更が他方のモジュールに影響するかどうかを検証します。スモークテストではテストケースはスクリプト化されています
回帰テスト 変更されていないモジュールが欠陥を引き起こさないことを保証するために同じテストケースを繰り返し実行する。リグレッションテストは機能テスト中
「回帰テストでは、現在のソフトウェアで行われた変更が既存のソフトウェアの機能に影響を与えないように、変更されたソフトウェアに対して以前のテストを再実行します。」
ユニットテスト は、可能な限り実装の最小部分に向けられています。 Javaでは、これは単一のクラスをテストしていることを意味します。クラスが他のクラスに依存している場合、これらは偽造されています。
あなたのテストが複数のクラスを呼び出すとき、それは 統合テスト です。
フルテストスイートは実行するのに長い時間がかかることがあります、従って変更の後で多くのチームは重大な破損を検出するためにいくつかの迅速で完全なテストを実行します。たとえば、URIを重要なリソースに分割しました。これらは 煙試験 です。
回帰テスト すべてのビルドで実行し、あなたが壊れたものを捉えることによって効果的にリファクタリングすることを可能にします。どのようなテストでも回帰テストになり得ますが、ユニットテストが障害の原因を見つけるのに最も役立ちます。
単体テスト:特定のコンポーネント(つまりクラス)が設計どおりに機能を作成または変更したことを検証する。このテストは手動でも自動でも可能ですが、コンポーネントの境界を超えては動きません。
統合テスト:特定のコンポーネントの相互作用が設計どおりに機能することを確認します。統合テストは、ユニットレベルまたはシステムレベルで実行できます。これらのテストは手動でも自動でも可能です。
回帰テスト:新しい欠陥が既存のコードに導入されていないことを確認します。これらのテストは手動でも自動でも可能です。
あなたのSDLC(滝、ルップ、アジャイルなど)に応じて、特定のテストが「段階」で実行されるか、またはすべて、多かれ少なかれ同時に実行されるかもしれません。たとえば、単体テストは、統合テストおよび回帰テストのためにコードをテスターに引き渡す開発者に限定される場合があります。ただし、別のアプローチでは、開発者が単体テストとある程度の統合および回帰テストを実行することがあります(TDDアプローチと継続的統合および自動化された単体および回帰テストを使用)。
このスレッドで言及する価値があると思われるテストの1つのタイプは、ストレス/パフォーマンス/負荷テストです。これは、特定のソフトウェアが破る限界を見つけることとして単純に置くことができます。ツーリングに関しては、システムの観点からストレステストに提案するものの範囲を正確に決定することが不可欠です。たとえば、 "Webアプリケーション"の場合、ストレステストにはWebサーバーアプリケーション自体を含めることができます。そのため、そのためにcouldというツールが介入します。これは http負荷テストについてのいい記事です
単体テスト: - 単体テストは通常開発者側で行われます。テスターはこの種のテストで部分的に進化するため、テストは単体で行われます。 Java Junitのテストケースでは、書かれたコードが完全に設計されているかどうかをテストすることも可能です。
統合テスト: - このタイプのテストは、すべての/一部のコンポーネントが統合されている場合の単体テストの後に可能です。
スモークテスト: - このタイプのテストは、システムが正常に統合され、本番サーバーに移行する準備ができたときに最後に行われます。この種のテストでは、最初から最後までのすべての重要な機能が正常に機能していること、およびシステムを運用サーバーに展開する準備ができていることを確認します。
回帰テスト: - このタイプのテストは、開発者が問題を修正したときに意図しない/望ましくない欠陥がシステムに存在しないことをテストするために重要です。このテストでは、すべてのバグが正常に解決されていること、および他の問題が発生していないことも確認します。
テストを開始するかどうかを識別するために、ソフトウェアのビルド後に、スモークテストと健全性テストの両方が実行されます。健全性は、煙検査の後で執行される場合とされない場合があります。それらは別々にまたは同時に執行することができます - 健全性は煙の直後です。
健全性テストはより綿密で時間がかかるため、ほとんどの場合、自動化することは適切です。
スモークテストは通常、実行に5〜30分以内で完了します。それはより一般的です:それはソフトウェアの安定性がさらなるテストのために十分に良好であり、問題がないことを検証するためにシステム全体の少数のコア機能をチェックし、計画されたテストケースの実行をブロックします。
健全性テストは煙よりも詳細であり、新しいビルドの規模に応じて15分から1日までかかる場合があります。進行テストまたは再テストの後に実行される、より特殊化された種類の受け入れテストです。回帰テストを大規模に実行する前に、必要な演算ロジックに関して機能していることを確認するために、特定の新機能のコア機能および/またはそれらの機能に密接に関連する機能をチェックします。
これらのレベルのテストがある理由、実際に例で意味することについて、さらにコンテキストを追加して提供したかっただけです
Mike Cohnの著書「Succeeding with Agile」は、プロジェクトの自動化されたテストにアプローチする方法として「Testing Pyramid」を考案しました。このモデルにはさまざまな解釈があります。このモデルは、どの種類の自動テストを作成する必要があるか、テスト対象のアプリケーションに関するフィードバックをどのくらい迅速に提供できるか、誰がこれらのテストを作成するかを説明します。プロジェクトには基本的に3つのレベルの自動テストが必要であり、それらは次のとおりです。
ユニットテスト-これらは、ソフトウェアアプリケーションの最小コンポーネントをテストします。これは文字通り、いくつかの入力に基づいて値を計算するコード内の1つの関数になります。この機能は、アプリケーションを構成するハードウェア/ソフトウェアコードベースの他のいくつかの機能の一部です。
たとえば、Webベースの電卓アプリケーションを見てみましょう。単体テストが必要なこのアプリケーションの最小コンポーネントは、加算を実行する関数、減算を実行する関数などです。これらすべての小さな機能を組み合わせて、電卓アプリケーションを構成します。
歴史的に、開発者は通常、ソフトウェアアプリケーションと同じプログラミング言語で記述されているため、これらのテストを記述します。この目的には、JUnitおよびNUnit(Java用)、MSTest(C#および.NET用)、Jasmine/Mocha(JavaScript用)などのユニットテストフレームワークが使用されます。
単体テストの最大の利点は、UIの下で非常に高速に実行され、アプリケーションに関する迅速なフィードバックが得られることです。これは、自動テストの50%以上を構成する必要があります。
API/Integration Tests-これらは、ソフトウェアシステムのさまざまなコンポーネントを一緒にテストします。コンポーネントには、テストデータベース、API(アプリケーションプログラミングインターフェイス)、サードパーティのツールとサービス、アプリケーションが含まれます。
たとえば、上記の計算機の例では、Webアプリケーションはデータベースを使用して値を保存し、APIを使用してサーバー側の検証を行い、サードパーティのツール/サービスを使用して結果をクラウドに公開し、さまざまな場所で利用できるようにしますプラットフォーム。
歴史的に、開発者または技術QAは、Postman、SoapUI、JMeterなどのさまざまなツールやTestimなどの他のツールを使用してこれらのテストを記述していました。
これらはまだフードの下で実行されるため、UIテストよりもはるかに速く実行されますが、システムのさまざまな独立したコンポーネント間の通信を確認し、シームレスな統合を確保する必要があるため、ユニットテストよりも少し時間がかかる場合があります。これは、自動テストの30%以上を構成する必要があります。
Iテスト-最後に、アプリケーションのUIを検証するテストがあります。これらのテストは通常、アプリケーションを介したエンドツーエンドのフローをテストするために作成されます。
例えば-電卓アプリケーションでは、エンドツーエンドのフローは、ブラウザを開く->電卓アプリケーションのURLを入力する->ユーザー名/パスワードでログインする->電卓アプリケーションを開く->電卓でいくつかの操作を実行する-> UIからこれらの結果を確認します->アプリケーションからログアウトします。これは、UIオートメーションの優れた候補となる、エンドツーエンドのフローの1つです。
従来、技術QAまたは手動テスターはUIテストを作成します。 SeleniumなどのオープンソースフレームワークまたはTestimなどのUIテストプラットフォームを使用して、テストを作成、実行、および保守します。これらのテストでは、スクリーンショット、ログ、テストレポートを通じて、テストの実行方法、期待される結果と実際の結果の違いを確認できるため、より視覚的なフィードバックが得られます。
UIテストの最大の制限は、ユニットおよびAPIレベルのテストに比べて比較的遅いことです。そのため、自動テスト全体の10〜20%のみを構成する必要があります。
次の2種類のテストはプロジェクトによって異なる場合がありますが、アイデアは
煙テスト
これは、上記の3レベルのテストの組み合わせにすることができます。アイデアは、コードをチェックインするたびに実行し、システムの重要な機能が期待どおりに機能していることを確認することです。新しいコードの変更がマージされた後。通常、障害に関するより迅速なフィードバックを得るには、5〜10分で実行する必要があります。
回帰テスト
通常、少なくとも1日に1回実行され、システムのさまざまな機能をカバーします。アプリケーションが期待どおりに動作していることを確認します。これらはスモークテストよりも詳細であり、重要でないものを含むアプリケーションのより多くのシナリオをカバーしています。
単体テスト:開発者がテストを行ってからQAの要件を満たす前に、問題を発見するために開発者が常に実行します。
統合テスト:データ/機能の出力があるモジュールから別のモジュールへ駆動されるとき、テスターがモジュールからサブモジュールへの検証を行わなければならないことを意味します。またはあなたのシステムに統合のためにあなたのシステムデータを使用するサードパーティ製のツールを使用している場合。
スモークテスト:テスターは、ハイレベルのテストのためにシステムを検証し、変更やコードが実行される前にショーストッパーのバグを見つけようとしました。
回帰テスト:テスターは、新たな機能強化のためにシステムに実装された変更またはシステムの変更により、既存の機能を検証するための回帰を実行しました。
簡単な方法で。
単体テスト: 単一のコード、アルゴリズム、クラス、またはシステムをテストします。このテストは独立している必要があり、依存関係はモックまたはスタブである必要があります。
統合テスト: は、コンポーネント、アルゴリズム、クラス、またはシステムが他のコンポーネントによって使用されているときにうまく機能するかどうかをテストする必要があります。
スモークテスト: 最初に大きなテストセットを実行する必要がある非常に小さなテストセットです。アップグレード後もシステムの最も重要な機能が確実に機能するようにします。
回帰テスト: 古いプログラミングがまだ新しい変更でも機能することを確認するために、コンピュータプログラムへの変更をテストするプロセスです。スモークテストよりも大きなテストのセットです。
あなたがUdemyでこのコースに入ることができる統合テストについてもっと知りたいならば、それはよい割引を持っています。
https://www.udemy.com/testes-de-integracao-com-spring-boot/?couponCode=TISB_ODESC2019
単体テスト 単体テストはアプリケーションのソースに近い非常に低いレベルです。それらはあなたのソフトウェアによって使用されるクラス、コンポーネントまたはモジュールの個々のメソッドと機能をテストすることから成ります。単体テストは一般に自動化するのが非常に安価であり、継続的インテグレーションサーバーによって非常に迅速に実行することができます。
統合テスト 統合テストでは、アプリケーションで使用されるさまざまなモジュールまたはサービスが連携して動作することを確認します。たとえば、データベースとの対話をテストしたり、マイクロサービスが期待どおりに連携して動作していることを確認したりできます。これらの種類のテストは、アプリケーションの複数の部分を起動して実行する必要があるため、実行するのにコストがかかります。
機能テスト 機能テストは、アプリケーションのビジネス要件に焦点を当てています。それらは、アクションの出力を検証するだけで、そのアクションを実行するときにシステムの中間状態をチェックしません。
統合テストと機能テストは、相互にやり取りするために複数のコンポーネントを必要とするため、混乱が生じることがあります。違いは、機能テストでは製品要件で定義されているようにデータベースから特定の値を取得することを期待しながら、統合テストではデータベースにクエリを実行できることを単純に検証できることです。
エンドツーエンドテスト エンドツーエンドテストでは、完全なアプリケーション環境でソフトウェアによるユーザーの行動を再現します。これは、さまざまなユーザーフローが期待どおりに機能することを確認し、Webページの読み込みやログイン、あるいは電子メール通知、オンライン支払いなどを検証するためのはるかに複雑なシナリオと同じくらい簡単になります。
エンドツーエンドのテストは非常に便利ですが、実行には費用がかかり、自動化されていると保守が困難になる可能性があります。重大な変更を迅速に識別できるようにするために、いくつかの重要なエンドツーエンドのテストを行い、低レベルのタイプのテスト(単体テストおよび統合テスト)に頼ることをお勧めします。
受け入れテスト 受け入れテストは、システムがそのビジネス要件を満たしているかどうかを検証するために実行される正式なテストです。それらは、アプリケーション全体が稼働していること、そしてユーザーの振る舞いを再現することに集中することを要求します。しかし、さらに進んでシステムのパフォーマンスを測定し、特定の目標が達成されない場合は変更を拒否することもできます。
パフォーマンステスト パフォーマンステストは、システムに大きな負荷がかかっているときのシステムの動作をチェックします。これらのテストは機能しておらず、プラットフォームの信頼性、安定性、および可用性を理解するためのさまざまな形式を取ります。たとえば、大量の要求を実行するときの応答時間を観察したり、システムが大量のデータに対してどのように動作するかを確認したりすることができます。
パフォーマンステストはその性質上、実装と実行にかなりのコストがかかりますが、新しい変更によってシステムが劣化するかどうかを理解するのに役立ちます。
スモークテスト スモークテストはアプリケーションの基本機能をチェックする基本テストです。それらは実行するのが速いことを意図されており、そして彼らの目標はあなたのシステムの主要な機能が期待通りに働いているという保証をあなたに与えることです。
スモークテストは、より高価なテストを実行できるかどうかを判断するために新しいビルドを作成した直後、またはアプリケーションが新しく展開された環境で正しく実行されていることを確認するために展開した直後に役立ちます。
ソース: https://www.atlassian.com/continuous-delivery/software-testing/types-of-software-testing
回帰テスト - バグ修正をカバーまたは確認しようとする一種のSWテストです。提供されている修正により、バグ修正に関する機能が変更または変更されることはありません。このようなプロセスで見つかった問題は回帰問題と呼ばれます。
スモークテスト:さらなるQAテストのためにビルド/ソフトウェアを受け入れるかどうかを決定するために行われる一種のテストです。
いくつかの良い答えはすでにありましたが、それらをさらに洗練したいと思います。
ここでは、ユニットテストがホワイトボックステストの唯一の形式です。他はブラックボックステストです。ホワイトボックステストは、あなたが入力を知っていること、あなたがメカニズムの内部の仕組みを知っていること、そしてそれを検査することができ、あなたが出力を知っていることを意味します。ブラックボックステストでは、入力が何か、出力がどうあるべきかだけがわかります。
したがって、明らかに単体テストがここでの唯一のホワイトボックステストです。
スモークテストは既にここで説明されており、簡単です。回帰テストは統合テストの対象になります。
自動テストは2つに分けることができます。
単体テストと統合テスト。 (これがすべて重要です)
統合テスト、機能テスト、回帰テスト、UIテストなどのすべてのテストに「長期テスト」(LT)という語句を使用します。単体テストを「短期テスト」と呼びます。
LTの例は、自動的にWebページをロードし、アカウントにログインして本を購入することです。テストに合格すれば、ライブサイトでも同じように実行される可能性が高くなります(したがって、「よりよい睡眠」参照)。 Long = Webページ(開始)とデータベース(終了)の間の距離。
これは、単体テストに対する 統合テスト(長期テスト))の利点を説明する素晴らしい記事です