Was ist Unit-Test, Integrationstest, Rauchtest, Regressionstest?

• Unit Test : Ein automatischer Test zum Testen der internen Abläufe einer Klasse. Es sollte ein eigenständiger Test sein, der sich nicht auf andere Ressourcen bezieht.
• Integrationstest : Ein automatischer Test, der in einer Umgebung durchgeführt wird, also ähnlich wie Komponententests, jedoch mit externen Ressourcen (db, Festplattenzugriff).
• Regressionstest : Nachdem Sie neue Funktionen oder Fehlerbehebungen implementiert haben, testen Sie Szenarien erneut, die in der Vergangenheit funktioniert haben. Hier behandeln Sie die Möglichkeit, mit der Ihre neuen Funktionen bestehende Funktionen durchbrechen.
• Rauchprüfung : Erste Tests, bei denen Tester feststellen können, ob sie weiter testen.

Jeder hat etwas andere Definitionen und es gibt oft graue Bereiche. Jedoch:

• Unit-Test: Funktioniert dieser ein bisschen (so isoliert wie möglich)?
• Integrationstest: Funktionieren diese zwei (oder mehr) Komponenten zusammen?
• Rauchtest: Hängt das gesamte System (so nah wie möglich an einem Produktionssystem) einigermaßen gut zusammen? (d. h. sind wir einigermaßen zuversichtlich, dass kein schwarzes Loch entsteht?)
• Regressionstest: Haben wir versehentlich Fehler korrigiert, die wir zuvor behoben hatten?

Eine neue Testkategorie, auf die ich gerade aufmerksam geworden bin, ist: 

Kanarien-Test

Beispiele könnten sein:

• Hat Daten, die nur in DEV/TEST verfügbar sein sollten, in LIVE erschienen.
• Wurde ein Hintergrundprozess nicht ausgeführt?
• Kann sich ein Benutzer anmelden?

apokryphisches historisches Trivia: "Rauchprüfung" kommt vom U-Boot-Engineering (geerbt von Sanitäranlagen), bei dem buchstäblicher Rauch in den Rumpf gepumpt wurde, um zu sehen, ob etwas davon wieder herauskam, was für ein U-Boot ein dramatischer Misserfolg wäre!

Antwort von einer der besten Websites für Softwaretesttechniken:

Arten von Softwaretests - Vollständige Liste Klicken Sie hier

Es ist eine lange Beschreibung, ich werde es hier nicht einfügen: aber es kann für jemanden hilfreich sein, der alle Testtechniken kennenlernen möchte.

Ich hoffe es wird hilfreich sein :)

Komponententest: Überprüfung der von der jeweiligen Komponente (d. H. Klasse) erstellten oder geänderten Funktionen wie geplant. Dieser Test kann manuell oder automatisiert durchgeführt werden, überschreitet jedoch nicht die Grenzen der Komponente.

Integrationstest: Sicherstellen, dass das Zusammenspiel bestimmter Komponenten wie geplant funktioniert. Integrationstests können auf Einheiten- oder Systemebene durchgeführt werden. Diese Tests können manuell oder automatisiert sein.

Regressionstest: Überprüfung, dass keine neuen Fehler in den vorhandenen Code eingefügt werden. Diese Tests können manuell oder automatisiert sein.

Abhängig von Ihrem SDLC (Wasserfall, Rup, Agilität usw.) können bestimmte Tests in "Phasen" oder alle mehr oder weniger gleichzeitig durchgeführt werden. Zum Beispiel kann das Testen von Einheiten auf Entwickler beschränkt sein, die den Code dann an Tester zur Integration und zum Regressionstest übergeben. Bei einem anderen Ansatz könnten Entwickler jedoch Komponententests und einen gewissen Grad an Integrations- und Regressionstests durchführen (unter Verwendung eines TDD-Ansatzes zusammen mit kontinuierlicher Integration und automatisierten Unit- und Regressionstests).

Das Tool-Set hängt weitgehend von der Codebase ab, es gibt jedoch viele Open Source-Tools für Unit-Tests (JUnit). HP (Quecksilber) QTP oder Borland's Silktest sind Tools für die automatisierte Integration und für Regressionstests.

Unit-Test : Das Testen einzelner Module oder unabhängiger Komponenten in einer Anwendung ist als Unit-Test bekannt. Die Unit-Tests werden vom Entwickler durchgeführt.

integration test : Kombiniert alle Module und testet die Anwendung, um zu überprüfen, ob die Kommunikation und der Datenfluss zwischen den Modulen ordnungsgemäß funktionieren oder nicht. Diese Tests werden auch von Entwicklern durchgeführt.

Rauchtest IN-Rauchtest sie überprüfen die Anwendung in flacher und breiter Weise. Bei der Rauchprüfung prüfen sie die Hauptfunktionalität der Anwendung, ob Blockerprobleme in der Anwendung vorliegen, die sie dem Entwicklerteam und dem Entwicklungsteam melden behebt und behebt den Fehler und gibt ihn an das Testteam zurück. Das Testteam überprüft nun alle Module, um festzustellen, ob Änderungen an einem Modul Auswirkungen auf das andere Modul haben oder nicht. Beim Smoke-Test werden die Testfälle mit einem Skript erstellt 

Regressionstest Wiederholen der gleichen Testfälle, um sicherzustellen, dass das unveränderte Modul keinen Fehler verursacht. REGRESSION TESTING fällt unter Funktionsprüfung

REGRESSIONSTESTS-

"Ein Regressionstest führt vorherige Tests mit der geänderten Software erneut aus, um sicherzustellen, dass die Änderungen an der aktuellen Software die Funktionalität der vorhandenen Software nicht beeinträchtigen."

Unit Testing richtet sich an den kleinsten möglichen Teil der Implementierung. In Java bedeutet dies, dass Sie eine einzelne Klasse testen. Wenn die Klasse von anderen Klassen abhängt, werden diese gefälscht.

Wenn Ihr Test mehr als eine Klasse aufruft, ist dies ein Integrationstest .

Vollständige Testsuiten können lange dauern, daher führen viele Teams nach einer Änderung einige schnelle Tests durch, um signifikante Brüche zu erkennen. Sie haben zum Beispiel die URIs in wichtige Ressourcen aufgeteilt. Dies sind die Rauchprüfungen .

Regressionstests Führen Sie jeden Build aus und ermöglichen Sie eine effektive Refaktorisierung, indem Sie feststellen, was Sie kaputt machen. Jede Art von Test kann ein Regressionstest sein, aber ich finde, dass Unit-Tests am hilfreichsten sind, um die Fehlerquelle zu finden. 

Komponententest: Überprüfung der von der jeweiligen Komponente (d. H. Klasse) erstellten oder geänderten Funktionen wie geplant. Dieser Test kann manuell oder automatisiert durchgeführt werden, überschreitet jedoch nicht die Grenzen der Komponente.

Integrationstest: Sicherstellen, dass das Zusammenspiel bestimmter Komponenten wie geplant funktioniert. Integrationstests können auf Einheiten- oder Systemebene durchgeführt werden. Diese Tests können manuell oder automatisiert sein.

Regressionstest: Überprüfung, dass keine neuen Fehler in den vorhandenen Code eingefügt werden. Diese Tests können manuell oder automatisiert sein.

Abhängig von Ihrem SDLC (Wasserfall, Rup, Agilität usw.) können bestimmte Tests in "Phasen" oder alle mehr oder weniger gleichzeitig durchgeführt werden. Zum Beispiel kann das Testen von Einheiten auf Entwickler beschränkt sein, die den Code dann an Tester zur Integration und zum Regressionstest übergeben. Bei einem anderen Ansatz könnten Entwickler jedoch Komponententests und einen gewissen Grad an Integrations- und Regressionstests durchführen (unter Verwendung eines TDD-Ansatzes zusammen mit kontinuierlicher Integration und automatisierten Unit- und Regressionstests).

Eine Art von Tests, die in diesem Thread erwähnenswert zu sein scheint, sind Belastungs-/Leistungs-/Belastungstests, die einfach als das Herausfinden der Grenzen bezeichnet werden, ab denen eine bestimmte Software bricht. Beachten Sie, dass es in Bezug auf die Werkzeugausstattung unerlässlich ist, den Umfang dessen, was Stresstests aus Systemsicht vorschlägt, genau zu bestimmen. Im Fall einer "Webanwendung" können Stresstests beispielsweise die Webserveranwendung selbst in ihren Geltungsbereich einbeziehen, sodass das Werkzeug an diesem Ende eingreifen könnte. Hier ist ein netter Beitrag über http load testing

Unit-Tests: - Unit-Tests werden normalerweise von den Entwicklern durchgeführt, wobei Testgeräte teilweise in dieser Art von Tests entwickelt werden, bei denen der Test Unit für Unit durchgeführt wird . In Java Junit können Testfälle auch getestet werden ob der geschriebene Code perfekt gestaltet ist oder nicht.

Integrationstests: -.__: Diese Art von Tests ist nach dem Komponententest möglich, wenn alle/einige Komponenten integriert sind. Durch diese Art von Tests wird sichergestellt, dass sich Komponenten bei der Integration auf die Arbeitseigenschaften oder die Funktionale der anderen auswirken.

Smoke Testing: - Diese Art von Tests wird zuletzt ausgeführt, wenn das System erfolgreich integriert ist und auf dem Produktionsserver ausgeführt werden kann. Diese Art von Tests stellt sicher, dass alle wichtigen Funktionen von Anfang bis Ende einwandfrei funktionieren Das System kann nun auf dem Produktionsserver bereitgestellt werden.

Regressionstests: - Diese Art von Tests ist wichtig, um zu testen, dass im System nicht unbeabsichtigte/unerwünschte Defekte vorhanden sind, wenn der Entwickler einige Probleme beseitigte dass keine anderen Probleme aufgetreten sind.

Rauch- und Sanitätsprüfungen werden nach einem Software-Build durchgeführt, um festzustellen, ob mit dem Testen begonnen werden soll. Sanity kann nach dem Rauchtest ausgeführt werden oder nicht. Sie können einzeln oder gleichzeitig ausgeführt werden - die Vernunft ist unmittelbar nach dem Rauch.

Da die Prüfung der Hygiene tiefer gehend und zeitaufwändig ist, lohnt es sich in den meisten Fällen, automatisiert zu werden.

Die Durchführung von Rauchprüfungen dauert normalerweise nicht länger als 5-30 Minuten. Es ist allgemeiner: Es überprüft eine kleine Anzahl von Kernfunktionalitäten des gesamten Systems, um sicherzustellen, dass die Stabilität der Software für weitere Tests ausreichend ist und dass keine Probleme auftreten, wodurch der Ablauf der geplanten Testfälle blockiert wird.

Die Dichtigkeitsprüfung ist detaillierter als der Rauch und kann je nach Größe des neuen Gebäudes 15 Minuten bis zu einem ganzen Tag dauern. Es handelt sich um eine speziellere Art der Abnahmeprüfung, die nach dem Fortschreiten oder erneuten Testen durchgeführt wird. Es überprüft die Hauptmerkmale bestimmter neuer Funktionen und/oder Fehlerbehebungen zusammen mit einigen eng verwandten Funktionen, um zu überprüfen, ob sie die erforderliche Betriebslogik erfüllen, bevor Regressionstests in größerem Maßstab ausgeführt werden können.

Ich wollte nur hinzufügen und etwas mehr Zusammenhang darüber geben, warum wir diese Teststufen haben, was sie mit Beispielen wirklich bedeuten

Mike Cohn hat in seinem Buch „Succeeding with Agile“ die „Testing Pyramid“ als Methode für die Annäherung an automatisierte Tests in Projekten vorgestellt. Es gibt verschiedene Interpretationen dieses Modells. Das Modell erklärt, welche Art von automatisierten Tests erstellt werden müssen, wie schnell sie Feedback zu der zu testenden Anwendung geben können und wer diese Tests schreibt. Grundsätzlich sind für jedes Projekt 3 Stufen automatisierter Tests erforderlich, und zwar wie folgt.

nit Tests - Diese testen die kleinste Komponente Ihrer Softwareanwendung. Dies könnte buchstäblich eine Funktion in einem Code sein, der einen Wert basierend auf einigen Eingaben berechnet. Diese Funktion ist Teil mehrerer anderer Funktionen der Hardware-/Software-Codebasis, aus der die Anwendung besteht.

Beispiel: Nehmen wir eine webbasierte Taschenrechneranwendung. Die kleinsten Komponenten dieser Anwendung, die einem Komponententest unterzogen werden müssen, können eine Funktion sein, die eine Addition durchführt, eine andere, die eine Subtraktion durchführt usw. All diese kleinen Funktionen bilden zusammen die Taschenrechneranwendung.

Historisch betrachtet schreibt der Entwickler diese Tests so, wie sie normalerweise in derselben Programmiersprache wie die Softwareanwendung geschrieben sind. Zu diesem Zweck werden Unit-Testing-Frameworks wie JUnit und NUnit (für Java), MSTest (für C # und .NET) und Jasmine/Mocha (für JavaScript) verwendet.

Der größte Vorteil von Unit-Tests besteht darin, dass sie unter der Benutzeroberfläche sehr schnell ausgeführt werden und wir schnelles Feedback zur Anwendung erhalten. Dies sollte mehr als 50% Ihrer automatisierten Tests umfassen.

API/Integrationstests - Diese testen verschiedene Komponenten des Softwaresystems gemeinsam. Zu den Komponenten könnten das Testen von Datenbanken, APIs (Application Programming Interface), Tools und Services von Drittanbietern sowie die Anwendung gehören.

Beispiel: In unserem obigen Taschenrechner-Beispiel verwendet die Webanwendung möglicherweise eine Datenbank zum Speichern von Werten, APIs zum Durchführen einiger serverseitiger Überprüfungen und ein Drittanbieter-Tool/-Dienst zum Veröffentlichen von Ergebnissen in der Cloud, um sie für verschiedene Zwecke verfügbar zu machen Plattformen.

In der Vergangenheit hat ein Entwickler oder eine technische Qualitätssicherung diese Tests mit verschiedenen Tools wie Postman, SoapUI, JMeter und anderen Tools wie Testim geschrieben.

Diese werden viel schneller ausgeführt als UI-Tests, da sie immer noch unter der Haube ausgeführt werden, jedoch möglicherweise etwas mehr Zeit als Unit-Tests in Anspruch nehmen, da die Kommunikation zwischen verschiedenen unabhängigen Komponenten des Systems überprüft und eine nahtlose Integration sichergestellt werden muss. Dies sollte mehr als 30% der automatisierten Tests umfassen.

I Tests - Schließlich haben wir Tests, die die Benutzeroberfläche der Anwendung validieren. Diese Tests werden normalerweise geschrieben, um End-to-End-Flows durch die Anwendung zu testen.

Zum Beispiel - In der Taschenrechneranwendung könnte ein End-to-End-Ablauf sein, indem Sie den Browser öffnen -> Die URL der Taschenrechneranwendung eingeben -> Mit Benutzername/Passwort anmelden -> Die Taschenrechneranwendung öffnen -> Einige Vorgänge am Taschenrechner ausführen -> Überprüfen der Ergebnisse über die Benutzeroberfläche -> Abmelden von der Anwendung. Dies könnte ein End-to-End-Ablauf sein, der ein guter Kandidat für die Benutzeroberflächenautomatisierung wäre.

Historisch gesehen schreiben technische QS oder manuelle Tester UI-Tests. Sie verwenden Open-Source-Frameworks wie Selenium oder UI-Testplattformen wie Testim, um die Tests zu erstellen, auszuführen und zu warten. Diese Tests bieten mehr visuelles Feedback, da Sie anhand von Screenshots, Protokollen und Testberichten sehen können, wie die Tests ausgeführt werden und wie unterschiedlich die erwarteten und tatsächlichen Ergebnisse sind.

Die größte Einschränkung bei UI-Tests ist, dass sie im Vergleich zu Tests auf Unit- und API-Ebene relativ langsam sind. Es sollte also nur 10-20% der gesamten automatisierten Tests ausmachen.

Die nächsten beiden Arten von Tests können je nach Projekt variieren.

Rauchtests

Dies kann eine Kombination der oben genannten 3 Teststufen sein. Die Idee ist, es bei jedem Code-Check-In auszuführen und sicherzustellen, dass die kritischen Funktionen des Systems weiterhin wie erwartet funktionieren. nachdem die neuen Codeänderungen zusammengeführt wurden. Sie müssen in der Regel mit 5 bis 10 Minuten ausgeführt werden, um eine schnellere Rückmeldung bei Fehlern zu erhalten

Regressionstests

Sie werden in der Regel mindestens einmal täglich ausgeführt und decken verschiedene Funktionen des Systems ab. Sie stellen sicher, dass die Anwendung weiterhin wie erwartet funktioniert. Sie sind detaillierter als die Rauchprüfungen und decken mehr Anwendungsszenarien ab, einschließlich der nicht kritischen.

• Integrationstest: Integrationstest ist das andere Element integrieren
• Smoke Testing: Smoke Testing ist auch als Build-Version bekannt. Testing. Smoke Testing ist der erste Testprozess, um zu prüfen, ob die getestete Software für weitere Tests bereit/stabil ist.
• Regressionstest: Der Regressionstest ist ein erneuerter Test. Ob neue Software in einem anderen Modul ausgeführt wird oder nicht.
• Komponententest: Es ist ein White-Box-Test. Nur Entwickler involvieren es

Komponententest: Es wird immer von Entwicklern nach ihrer Entwicklung durchgeführt, um das Problem von ihrer Testseite herauszufinden, bevor sie die Anforderungen an die QS stellen.

Integrationstest: Dies bedeutet, dass der Tester die Modul-zu-Submodul-Verifizierung überprüfen muss, wenn Daten-/Funktionsausgänge von einem Modul zu einem anderen Modul übertragen werden. Oder in Ihrem System, wenn Sie ein Drittanbieter-Tool verwenden, das Ihre Systemdaten für die Integration verwendet.

Smoke Testing: Test zum Testen des Systems für Tests auf hohem Niveau und beim Versuch, den Stopper-Fehler zu ermitteln, bevor Änderungen oder Code in Betrieb genommen werden.

Regressionstest: Der Tester führte eine Regression durch, um die vorhandene Funktionalität aufgrund von im System implementierten Änderungen für neue Verbesserungen oder Systemänderungen zu überprüfen.

Unit-Tests Unit-Tests sind sehr niedrig, nahe an der Quelle Ihres Anwendung. Sie bestehen darin, einzelne Methoden und Funktionen zu testen der Klassen, Komponenten oder Module, die von Ihrer Software verwendet werden. Einheit Tests sind im Allgemeinen recht kostengünstig zu automatisieren und können sehr ausgeführt werden schnell durch einen Continuous Integration Server.

Integrationstests Integrationstests überprüfen, ob verschiedene Module oder Die von Ihrer Anwendung verwendeten Dienste funktionieren gut zusammen. Zum Beispiel it kann die Interaktion mit der Datenbank testen oder sicherstellen, dass Microservices arbeiten wie erwartet zusammen. Diese Arten von Tests sind mehr teuer zu laufen, da sie mehrere Teile der Anwendung benötigen, um aufstehen und laufen.

Funktionstests Funktionstests konzentrieren sich auf die Geschäftsanforderungen einer Anwendung. Sie überprüfen nur die Ausgabe einer Aktion und nicht Überprüfen Sie die Zwischenzustände des Systems, wenn Sie das ausführen Aktion.

Manchmal besteht eine Verwirrung zwischen Integrationstests und Funktionstests, da für beide mehrere Komponenten erforderlich sind miteinander. Der Unterschied ist, dass ein Integrationstest einfach Vergewissern Sie sich, dass Sie die Datenbank abfragen können, während ein Funktionstest ausgeführt würde Erwarten Sie, einen bestimmten Wert aus der Datenbank zu erhalten, wie in .__ definiert. Produktanforderungen.

Ende-zu-Ende-Tests Ende-zu-Ende-Tests replizieren ein Benutzerverhalten mit die Software in einer vollständigen Anwendungsumgebung. Es überprüft das Verschiedene Benutzerabläufe funktionieren wie erwartet und können so einfach wie das Laden einer .__ sein. Webseite oder Anmelden oder viel komplexere Szenarien zur Überprüfung der E-Mail Benachrichtigungen, Online-Zahlungen usw.

End-to-End-Tests sind sehr nützlich, aber sie sind teuer in der Durchführung und kann schwer zu warten sein, wenn sie automatisiert sind. Es wird empfohlen, haben ein paar wichtige End-to-End-Tests und verlassen sich mehr auf die Typen der unteren Ebene von Testen (Unit- und Integrationstests), um schnell erkennen zu können Änderungen brechen.

Abnahmetests Abnahmetests sind formale Tests, die mit .__ ausgeführt werden. Überprüfen Sie, ob ein System die Geschäftsanforderungen erfüllt. Sie benötigen Die gesamte Anwendung muss betriebsbereit sein und sich auf das Replizieren konzentrieren Benutzerverhalten Sie können aber auch weiter gehen und das .__ messen. Systemleistung und lehnen Änderungen ab, wenn bestimmte Ziele nicht .__ sind. getroffen.

Leistungstest Leistungstests prüfen das Verhalten von System, wenn es unter erheblicher Belastung steht. Diese Tests sind nicht funktional und kann die verschiedene Form haben, um die .__ zu verstehen. Zuverlässigkeit, Stabilität und Verfügbarkeit der Plattform. Zum So können beispielsweise Reaktionszeiten bei der Ausführung eines hohen Werts beobachtet werden Anzahl der Anfragen oder sehen, wie sich das System mit einer .__ verhält. signifikant von Daten.

Performance-Tests sind naturgemäß ziemlich teuer und run, aber sie können Ihnen helfen zu verstehen, ob neue Änderungen an .__ vorgenommen werden. degradieren Sie Ihr System.

Smoke testing Rauchprüfungen sind grundlegende Tests, die grundlegende .__ überprüfen. Funktionalität der Anwendung. Sie sollen schnell sein ausführen, und ihr Ziel ist es, Ihnen die Gewissheit zu geben, dass der Major Die Funktionen Ihres Systems funktionieren wie erwartet.

Rauchprüfungen können unmittelbar nach der Erstellung eines neuen Builds hilfreich sein ob Sie teurere Tests ausführen können oder nicht, direkt nach einem Bereitstellung, um sicherzustellen, dass die Anwendung ordnungsgemäß in .__ ausgeführt wird. die neu implementierte Umgebung.

quelle: https://www.atlassian.com/continuous-delivery/software-testing/types-of-software-testing

Regressionstest - ist eine Art SW-Test, bei dem versucht wird, den Bugfix zu behandeln oder zu überprüfen. Die Funktionalität des Bugfixes sollte aufgrund des zur Verfügung gestellten Fixes nicht geändert oder geändert werden. Probleme, die in einem solchen Prozess gefunden werden, werden als Regressionsprobleme bezeichnet.

Smoke Testing: Eine Art von Tests, bei denen entschieden wird, ob der Build/die Software für weitere QS-Tests akzeptiert wird.

Einige gute Antworten, aber ich möchte sie weiter verfeinern:

Unit-Tests sind hier die einzige Form des White-Box-Tests. Die anderen sind Black-Box-Tests. White-Box-Tests bedeuten, dass Sie die Eingabe kennen, Sie kennen die inneren Abläufe des Mechanismus, können sie prüfen und die Ausgabe kennen. Beim Black Box Testing wissen Sie nur, was die Eingabe ist und was die Ausgabe sein soll. 

Es ist also eindeutig die Einzeltestprüfung hier.

• Unit-Test testet bestimmte Teile des Codes. Normalerweise Methoden. 
• Integrationstests Testen Sie, ob Ihre neue Feature-Software mit allem anderen kompatibel ist.
• Regressionstests. Dies wird getestet, um sicherzustellen, dass Sie nichts beschädigt haben. Alles, was früher funktioniert hat, sollte noch funktionieren.
• Der Rauchtest wird als schneller Test durchgeführt, um sicherzustellen, dass alles in Ordnung aussieht, bevor Sie sich an den intensiveren Tests beteiligen.

Der Rauchtest wurde hier bereits erklärt und ist einfach. Der Regressionstest kommt unter den Integrationstest.

Automatisierte Tests können in nur 2 unterteilt werden.

Unit-Test und Integrationstest. (das ist alles was zählt)

Ich würde die Bezeichnung "Long Test" (LT) für alle Tests wie Integrationstest, Funktionstest, Regressionstest, UI-Test usw. verwenden.

Ein LT Beispiel könnte sein, eine Webseite automatisch zu laden, sich beim Konto anzumelden und ein Buch zu kaufen. Wenn der Test bestanden wird, ist es wahrscheinlicher, dass er auf derselben Art und Weise auf der Live-Site abläuft (daher die Referenz für einen besseren Schlaf). Long = Abstand zwischen Webseite (Start) und Datenbank (Ende).

Und dies ist ein großartiger Artikel, in dem die Vorteile von Integrationstests (langer Test) gegenüber Unit-Tests erörtert werden

In vereinfachter Weise.

Unit test: Testen Sie einen einzelnen Code, Algorithmus, eine Klasse oder ein System. Dieser Test sollte unabhängig sein und die Abhängigkeiten sollten verspottet oder abgestumpft werden.

Integrationstest: sollte testen, ob die Komponente, der Algorithmus, die Klasse oder das System gut funktionieren, wenn sie von anderen Komponenten verwendet werden. Integrationstests dienen nicht zum Testen der Funktionsweise des Systems (Verhalten);.

Smoke test: Ist ein sehr kleiner Satz von Tests, der zuerst eine große Anzahl von Tests ausführen soll. Dadurch wird sichergestellt, dass die wichtigsten Funktionen des Systems auch nach einem Upgrade funktionieren.

Regression test: Überprüft Änderungen an Computerprogrammen, um sicherzustellen, dass die ältere Programmierung weiterhin mit den neuen Änderungen funktioniert. Ist eine größere Anzahl von Tests als Rauchprüfungen.

Wenn Sie mehr über den Integrationstest erfahren möchten, können Sie an diesem Kurs in Udemy teilnehmen, es gibt einen guten Rabatt.

https://www.udemy.com/testes-de-integracao-com-spring-boot/?couponCode=TISB_ODESC2019