Was sind Unit-Tests, Integrationstests, Smoke-Tests und Regressionstests?

Question

Was sind Unit-Tests, Integrationstests, Smoke-Tests und Regressionstests? Was sind die Unterschiede zwischen ihnen und welche Tools kann ich für jedes von ihnen verwenden?

Ich verwende zum Beispiel JUnit y NUnit para Unit-Tests y Integrationsprüfung . Gibt es Werkzeuge für die letzten beiden, Rauchprüfung o Regressionstests ?

Answer 1

Einheitstest Unit Testing: Das Testen eines einzelnen Moduls oder einer unabhängigen Komponente in einer Anwendung wird als Unit Testing bezeichnet. Die Unit-Tests werden von den Entwicklern durchgeführt.

Integrationstest Kombination aller Module und Testen der Anwendung, um zu überprüfen, ob die Kommunikation und der Datenfluss zwischen den Modulen ordnungsgemäß funktionieren oder nicht. Diese Tests werden auch von den Entwicklern durchgeführt.

Rauchtest Bei einem Smoke-Test wird die Anwendung in einer flachen und breiten Weise geprüft. Beim Smoke-Test wird die Hauptfunktionalität der Anwendung überprüft. Wenn ein Problem in der Anwendung auftritt, wird es dem Entwicklerteam gemeldet, das den Fehler behebt und ihn an das Testteam zurückgibt. Nun prüft das Testteam alle Module, um sicherzustellen, dass sich Änderungen in einem Modul auch auf die anderen Module auswirken oder nicht. Bei der Rauchprüfung die Testfälle sind in einem Skript zusammengefasst.

Regressionstests die wiederholte Ausführung der gleichen Testfälle, um sicherzustellen, dass das unveränderte Modul keinen Fehler verursacht. Regressionstests gehören zu den funktionalen Tests.

Answer 2

REGRESSIONSTESTS

"Ein Regressionstest führt frühere Tests mit der geänderten Software erneut durch, um sicherzustellen, dass die in der aktuellen Software vorgenommenen Änderungen die Funktionalität der bestehenden Software nicht beeinträchtigen."

Answer 3

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

Mike Cohn hat in seinem Buch "Succeeding with Agile" die "Testing Pyramid" als Ansatz für automatisierte Tests in Projekten entwickelt. Es gibt verschiedene Interpretationen dieses Modells. Das Modell erklärt, welche Art von automatisierten Tests erstellt werden müssen, wie schnell sie Rückmeldung über die zu testende Anwendung geben können und wer diese Tests schreibt. Grundsätzlich gibt es 3 Stufen automatisierter Tests, die für jedes Projekt benötigt werden, und zwar folgende.

Einheitstest- Diese testen die kleinste Komponente Ihrer Softwareanwendung. Dabei kann es sich buchstäblich um eine Funktion in einem Code handeln, die auf der Grundlage einiger Eingaben einen Wert errechnet. Diese Funktion ist Teil mehrerer anderer Funktionen der Hardware/Software-Codebasis, aus der die Anwendung besteht.

Ein Beispiel: Nehmen wir eine webbasierte Taschenrechneranwendung. Die kleinsten Komponenten dieser Anwendung, die einem Unit-Test unterzogen werden müssen, könnten eine Funktion sein, die eine Addition durchführt, eine andere, die eine Subtraktion durchführt, und so weiter. All diese kleinen Funktionen zusammengenommen ergeben die Taschenrechneranwendung.

Historisch gesehen schreibt der Entwickler diese Tests, da sie in der Regel in der gleichen Programmiersprache wie die Softwareanwendung geschrieben werden. 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 ist, dass sie sehr schnell unter der Benutzeroberfläche ablaufen und wir schnelles Feedback über die Anwendung erhalten können. Dies sollte mehr als 50 % Ihrer automatisierten Tests ausmachen.

API/Integrationstests- Diese testen verschiedene Komponenten des Softwaresystems gemeinsam. Die Komponenten können Datenbanken, APIs (Application Programming Interface), Tools und Dienste von Drittanbietern zusammen mit der Anwendung testen.

In unserem obigen Beispiel für einen Taschenrechner kann die Webanwendung eine Datenbank verwenden, um Werte zu speichern, APIs verwenden, um einige serverseitige Validierungen durchzuführen, und ein Tool/Dienst eines Drittanbieters verwenden, um die Ergebnisse in der Cloud zu veröffentlichen, damit sie auf verschiedenen Plattformen verfügbar sind.

In der Vergangenheit hat ein Entwickler oder ein technischer QA diese Tests mit verschiedenen Tools wie Postman, SoapUI, JMeter und anderen Tools wie Testim geschrieben.

Diese laufen viel schneller ab als UI-Tests, da sie immer noch unter der Haube ablaufen, können aber etwas mehr Zeit in Anspruch nehmen als Unit-Tests, da sie die Kommunikation zwischen verschiedenen unabhängigen Komponenten des Systems überprüfen und sicherstellen müssen, dass sie nahtlos integriert sind. Dies sollte mehr als 30 % der automatisierten Tests ausmachen.

UI-Tests. Schließlich gibt es noch Tests, die die Benutzeroberfläche der Anwendung überprüfen. Diese Tests werden in der Regel geschrieben, um die End-to-End-Flows durch die Anwendung zu testen.

Ein Beispiel: In der Taschenrechneranwendung könnte ein End-to-End-Flow wie folgt aussehen: Öffnen des Browsers -> Eingabe der URL der Taschenrechneranwendung -> Anmelden mit Benutzername/Passwort -> Öffnen der Taschenrechneranwendung -> Ausführen einiger Operationen mit dem Taschenrechner -> Überprüfen der Ergebnisse auf der Benutzeroberfläche -> Abmelden von der Anwendung. Dies könnte ein End-to-End-Flow sein, der sich gut für eine UI-Automatisierung eignen würde.

In der Vergangenheit haben technische QAs oder manuelle Tester UI-Tests geschrieben. Sie verwenden Open-Source-Frameworks wie Selenium oder UI-Testplattformen wie Testim, um die Tests zu erstellen, auszuführen und zu pflegen. Diese Tests geben mehr visuelles Feedback, da Sie anhand von Screenshots, Protokollen und Testberichten sehen können, wie die Tests ablaufen und welche Unterschiede zwischen den erwarteten und den tatsächlichen Ergebnissen bestehen.

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

Die nächsten beiden Arten von Tests können je nach Projekt variieren, aber die Idee ist

Rauch-Tests

Dabei kann es sich um eine Kombination der oben genannten 3 Prüfungsstufen handeln. Die Idee ist, sie bei jedem Code-Check-in durchzuführen und sicherzustellen, dass die kritischen Funktionen des Systems immer noch wie erwartet funktionieren, nachdem die neuen Codeänderungen zusammengeführt wurden. Sie müssen in der Regel 5 - 10 Minuten laufen, um schnelleres Feedback zu Fehlern zu erhalten.

Regressionstests

Sie werden in der Regel mindestens einmal am Tag durchgeführt und decken verschiedene Funktionen des Systems ab. Sie stellen sicher, dass die Anwendung weiterhin wie erwartet funktioniert. Sie sind detaillierter als die Smoke-Tests und decken mehr Szenarien der Anwendung ab, auch die unkritischen.

Answer 4

• Integrationstests: Integrationstests sind die Integration eines weiteren Elements
• Rauchtest: Smoke-Tests werden auch als Build-Versionstests bezeichnet. Smoke-Testing ist der anfängliche Testprozess, mit dem überprüft wird, ob die zu testende Software für weitere Tests bereit/stabil ist.
• Regressionstests: Regressionstests sind wiederholt Prüfung. Ob neue Software in ein anderes Modul eingearbeitet wird oder nicht.
• Einheitstests: Es ist ein White-Box-Test. Nur Entwickler hineingezogen werden

Answer 5

Einheitliche Prüfung ist auf den kleinstmöglichen Teil der Umsetzung gerichtet. In Java bedeutet dies, dass Sie eine einzelne Klasse testen. Wenn die Klasse von anderen Klassen abhängt, werden diese vorgetäuscht.

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

Vollständige Testsuiten können viel Zeit in Anspruch nehmen, daher führen viele Teams nach einer Änderung einige schnell durchzuführende Tests durch, um signifikante Fehler zu erkennen. Zum Beispiel haben Sie die URIs zu wichtigen Ressourcen beschädigt. Diese sind die Rauchversuche .

Regressionstests werden bei jedem Build ausgeführt und ermöglichen ein effektives Refactoring, indem sie die Fehler aufspüren. Jede Art von Test kann ein Regressionstest sein, aber ich finde, Unit-Tests sind am hilfreichsten, um die Fehlerquelle zu finden.