Was ist ein Rauchtest?

Was ist ein Rauchtest?

Rauchprüfung ist ein Softwaretestprozess, der bestimmt, ob der bereitgestellte Software-Build stabil ist oder nicht. Smoke-Tests sind eine Bestätigung für das QA-Team, mit weiteren Softwaretests fortzufahren. Sie bestehen aus einer minimalen Anzahl von Tests, die für jeden Build ausgeführt werden, um die Softwarefunktionen zu testen. Smoke-Tests werden auch als „Build Verification Testing“ oder „Confidence Testing“ bezeichnet.

Smoke-Testing bedeutet vereinfacht gesagt, dass überprüft wird, ob die wichtigsten Funktionen funktionieren und ob der zu testende Build keine schwerwiegenden Fehler aufweist. Es handelt sich um einen kurzen und schnellen Regressionstest der Hauptfunktionen. Dadurch lässt sich feststellen, ob der Build fehlerhaft ist und weitere Tests somit Zeit- und Ressourcenverschwendung wären.

Vergleichen Testen von Rauch und geistiger Gesundheit

Warum führen wir Rauchtests durch?

Smoke-Tests spielen eine wichtige Rolle in der Softwareentwicklung, da sie die Korrektheit des Systems in frühen Phasen sicherstellen. Dadurch können wir Testaufwand sparen. Erst nach Abschluss der Smoke-Tests beginnen wir mit den Funktionstests.

• Alle potenziellen Stolpersteine ​​des Projekts werden durch Rauchtests identifiziert.
• Mithilfe von Rauchtests werden die meisten Defekte in den Anfangsstadien erkannt. Software-Entwicklung.
• Mit der Rauchprüfung vereinfachen wir die Erkennung und Behebung schwerwiegender Mängel.
• Durch Rauchtests kann das QA-Team Fehler in der Anwendungsfunktionalität finden, die möglicherweise durch den neuen Code zutage getreten sind.
• Bei der Rauchprüfung werden die schwerwiegendsten Mängel festgestellt.

Beispiel 1: Protokollierungsfenster: Durch Klicken auf die Schaltfläche „Senden“ kann mit gültigem Benutzernamen und Passwort zum nächsten Fenster gewechselt werden.

Beispiel 2: Der Benutzer kann sich nicht von der Webseite abmelden.

Wann führen wir den Rauchtest durch?

Diese Vorteile kommen nur zum Tragen, wenn die Prüfung zum richtigen Zeitpunkt ausgelöst wird. Smoke-Tests werden immer dann durchgeführt, wenn neue Softwarefunktionen entwickelt und in einen bestehenden Build integriert werden, der in der QA-/Staging-Umgebung bereitgestellt wird. Sie stellen sicher, dass alle kritischen Funktionen korrekt funktionieren. Das folgende Diagramm zeigt, wie ein Build die QA-Umgebung erreicht, bevor die Smoke-Tests beginnen.

Bei dieser Testmethode stellt das Entwicklungsteam den Build in der Qualitätssicherung bereit. Tester wählen eine Teilmenge der Testfälle aus und führen sie gegen die kritischen Funktionen des Builds aus. Diese Testfälle dienen dazu, Fehler im Build aufzudecken. Wenn diese Tests erfolgreich sind, fährt das Qualitätssicherungsteam mit der weiteren Vorgehensweise fort. Funktionsprüfung.

Jeder Fehler weist darauf hin, dass das System an das Entwicklungsteam zurückgegeben werden muss. Bei jeder Änderung am Aufbau führen wir Rauchtests durch, um die Stabilität sicherzustellen.

Beispiel: -Im Anmeldefenster wird eine neue Registrierungsschaltfläche hinzugefügt und der Build mit dem neuen Code bereitgestellt. Wir führen einen Smoke-Test an einem neuen Build durch.

Die Smoke-Tests qualifizieren den Build für weitere formale Tests und dienen dem Nachweis der Systemstabilität und der Einhaltung der Anforderungen. Hauptziel ist die frühzeitige Erkennung schwerwiegender Probleme. Ein Build umfasst alle Datendateien, Bibliotheken, wiederverwendbaren Module und entwickelten Komponenten, die zur Implementierung einer oder mehrerer Produktfunktionen erforderlich sind.

Was passiert, wenn wir keinen Rauchtest durchführen?

Wenn wir in frühen Phasen keine Rauchtests durchführen, können in späteren Phasen Mängel auftreten, die kostspielig sein können. Defekt Wird ein Problem erst in späteren Phasen entdeckt, kann dies ein Showstopper sein, der die Veröffentlichung der Ergebnisse beeinträchtigt.

Wer wird den Rauchtest durchführen?

Nach der Freigabe des Builds für die QA-Umgebung werden die Rauchtests von QA-Ingenieuren/QA-Leitern durchgeführt. Bei jedem neuen Build bestimmt das QA-Team die Hauptfunktionalität der Anwendung, um Rauchtests durchzuführen. Das QA-Team prüft, ob die Anwendung, die getestet wird, Probleme bereitet.

Wie führt man einen Rauchtest durch?

Rauchtests werden normalerweise manuell durchgeführt, es besteht jedoch die Möglichkeit, dies durch Automatisierung zu erreichen. Es kann von Organisation zu Organisation unterschiedlich sein.

Manueller Rauchtest

Smoke-Tests werden durchgeführt, um sicherzustellen, dass die Navigation auf kritischen Pfaden wie erwartet funktioniert und die Funktionalität nicht beeinträchtigt wird. Es werden Funktionstestfälle mit hoher Priorität ausgewählt und getestet, um kritische Fehler im System zu finden. Bei erfolgreichem Test wird der Funktionstest fortgesetzt. Schlägt der Test fehl, wird der Build abgelehnt und zur Korrektur an das Entwicklungsteam zurückgesendet.

Die Qualitätssicherung (QS) startet erneut einen Funktionstest mit einer neuen Build-Version. Dieser Funktionstest wird mit dem neuen Build durchgeführt und anschließend in die bestehenden Builds integriert, um die Systemkorrektheit zu gewährleisten. Vor dem Funktionstest sollte das QS-Team die korrekten Build-Versionen überprüfen.

Automatisierte Rauchtests

Automatisierungstests wird verwendet für RegressionstestsAlternativ können wir auch automatisierte Testfälle für den Smoke-Test verwenden. Mithilfe dieser automatisierten Tests können Entwickler den Build sofort überprüfen, sobald ein neuer Build zur Bereitstellung bereitsteht.

Anstatt bei jeder Bereitstellung des neuen Software-Builds die Tests manuell zu wiederholen, werden aufgezeichnete Smoke-Testfälle für den Build ausgeführt. Dabei wird überprüft, ob die Hauptfunktionen noch ordnungsgemäß funktionieren. Wenn der Test fehlschlägt, können Sie den Build korrigieren und sofort erneut bereitstellen. Auf diese Weise können wir Zeit sparen und einen qualitativ hochwertigen Build für die QA-Umgebung sicherstellen.

Mit einem automatisierten Tool zeichnet der Testingenieur alle manuellen Schritte auf, die im Software-Build ausgeführt werden.

Rauchtestzyklus

Das folgende Flussdiagramm veranschaulicht den Ablauf von Smoke-Tests. Sobald der Build in der Qualitätssicherung bereitgestellt ist und die Smoke-Tests erfolgreich bestanden wurden, fahren wir mit den Funktionstests fort. Schlägt ein Smoke-Test fehl, beenden wir die Testphase, bis das Problem im Build behoben ist.

Best Practices für die Entwicklung von Smoke-Testfällen

Den Zyklus zu kennen ist eine Sache; keeping Eine andere Sache ist die Suite, die sie vertrauenswürdig macht. Eine Rauchreinigungsanlage verdient ihren Platz nur dann, wenn sie kompakt, schnell und wiederholbar ist.

• Zuerst die kritischen Pfade ermitteln: Listen Sie die Arbeitsabläufe auf, die das Produkt kommerziell nutzbar machen, wie z. B. Anmeldung, Suche, Dateneingabe, Zahlung und Abmeldung. Wenn einer dieser Arbeitsabläufe nicht funktioniert, ist die Version für einen Tester wertlos.
• Die Suite sollte flach, aber breit sein: Berühren Sie jedes Hauptmodul einmal, anstatt ein einzelnes Modul eingehend zu untersuchen. Grenzwerte, negative Daten und Fehlermeldungen gehören in den Funktionstest, nicht hierher.
• Die Ausführungszeit begrenzen: Die meisten Teams halten den Lauf zwischen zehn und fünfzehn Minuten und begrenzen die Suite auf etwa zwanzig bis dreißig Minuten. TestfälleEin Lauf, der eine Stunde dauert, hört auf, ein Tor zu sein, und wird zum Flaschenhals.
• Führen Sie dieselben Fälle bei jedem Build aus: Konsistenz ermöglicht es, einen Fehler dem Code und nicht einer geänderten Testauswahl zuzuschreiben.
• Instabile und abhängigkeitsintensive Fälle entfernen: Ein Testfall, der ohne Codeänderung sowohl erfolgreich als auch fehlschlägt, zerstört das Vertrauen in die Testumgebung. Instabile Drittanbieterdienste sollten simuliert oder als Stubs verwendet werden, wenn… Testautomatisierungs-Framework erlaubt.
• Ein eindeutiges Urteil fällen: Jeder Fall benötigt ein eindeutiges erwartetes Ergebnis, damit der Build ohne Diskussion angenommen oder abgelehnt werden kann.
• Versionieren Sie die Suite mit dem Build: Speichern Sie die Smoke-Cases im selben Repository wie den Anwendungscode, damit das Gate immer mit der zu testenden Version übereinstimmt.

RevÜberprüfen Sie die Suite bei jeder neuen Version: Entfernen Sie Anwendungsfälle für Funktionen, die nicht mehr relevant sind, und fügen Sie neue, kritische Arbeitsabläufe hinzu.

Smoke-Testing in CI/CD-Pipelines

Eine so konzipierte Suite ist kostengünstig genug, um bei jedem Commit ausgeführt zu werden, was moderne Bereitstellungsprozesse erfordern. kontinuierliche integration Server wie z.B. Jenkins Der Code wird kompiliert, in einer Staging-Umgebung bereitgestellt und anschließend als erster automatisierter Schritt die Smoke-Suite gestartet. Bei einem erfolgreichen Durchlauf gelangt das Artefakt in die Funktions- und Regressionstests, während ein fehlgeschlagener Durchlauf die Pipeline beendet und den verantwortlichen Entwickler innerhalb weniger Minuten benachrichtigt.

Zwei Testläufe sind üblich. Ein Testlauf vor dem Merge sichert den Hauptzweig ab, indem er jeden Pull Request validiert, und ein Testlauf nach der Bereitstellung bestätigt, dass die bereitgestellte Umgebung erreichbar und korrekt konfiguriert ist. Teams, die Continuous Deployment praktizieren, fügen oft direkt nach der Veröffentlichung einen dritten, reduzierten Testlauf gegen die Produktionsumgebung hinzu.

Da die Pipeline die Testsuite mehrmals täglich ausführt, müssen die Testfälle nicht interaktiv, selbstreinigend und unabhängig sein. Jeder Testfall, der auf eine menschliche Entscheidung wartet oder Testdaten hinterlässt, führt zu einem Stillstand der Pipeline.

Vorteile des Smoke-Tests

Hier sind einige Vorteile für Rauchtests aufgeführt.

• Einfach durchzuführen und schnell.
• Kritische Fehler und Mängel lassen sich in frühen Phasen leicht erkennen und beheben.
• Verbessert die Qualität des Systems
• Reduziert das Risiko
• Der Fortschritt lässt sich leichter beurteilen.
• Spart Testaufwand und Zeit
• Minimiert Integrationsrisiken

⚠ Zu beachtende Einschränkung: Ein erfolgreicher Smoke-Test zeigt lediglich an, dass der Build testbar ist. Er prüft wichtige Funktionen nur oberflächlich, sodass kleinere Fehler, Grenzfälle und selten genutzte Features bis zum eigentlichen Funktions- und Regressionstest verborgen bleiben. Ein positives Ergebnis eines Smoke-Tests sollte niemals als Zeichen dafür gewertet werden, dass der Build fehlerfrei ist.

Rauchtest vs. Plausibilitätstest vs. Regressionstest

Alle drei werden nach einer Codeänderung ausgeführt, weshalb sie oft verwechselt werden. Sie unterscheiden sich in Umfang, Tiefe und der Fragestellung, die sie jeweils beantworten.

Tests, die in einer Entwicklungsumgebung am Code durchgeführt werden, um die Korrektheit der Anwendung vor der Freigabe an die Qualitätssicherung sicherzustellen, werden als Funktionstests bezeichnet. Dabei wird überprüft, ob die Anwendung in der Entwicklung ihre grundlegenden funktionalen Anforderungen erfüllt.

Sanity-Tests bestimmen den Abschluss der Entwicklungsphase und treffen eine Entscheidung, ob das Softwareprodukt für die weitere Testphase bestanden wird oder nicht.

BASIS	RAUCHTEST	SICHERHEITSTEST	Regressionstests
Geltungsbereich	Breit und flach	Eng und tief	Breit und tief
Frage beantwortet	Ist diese Version stabil genug für Tests?	Funktioniert diese spezielle Lösung?	Ist irgendetwas kaputtgegangen, das früher funktioniert hat?
Reihenfolge	Erstens, bei jedem Build	Nach bestandener Rauchprüfung	Nach dem Plausibilitätstest
Typische Dauer	10 bis 15 Minuten	30 bis 60 Minuten	Hours bis heute
Automatisierungspassung	Sehr hohe	Mäßig, oft manuell	Sehr hohe

In der Praxis werden sie nacheinander durchgeführt: Smoke-Tests zur Abnahme des Builds, Sanity-Tests zur Überprüfung der gelieferten Änderung und Regressionstests, wenn der Zeitplan es zulässt.

Beispiel für Rauchtestfälle

Die folgende Tabelle dokumentiert eine kurze Rauchsimulation, wobei jede Zeile einem kritischen Pfad entspricht.

T.ID	TESTSZENARIEN	BESCHREIBUNG	TESTSCHRITT	ERWARTETES ERGEBNIS	TATSÄCHLICHE ERGEBNIS	STATUS
1	Gültige Anmeldedaten	Testen Sie die Anmeldefunktion der Webanwendung, um sicherzustellen, dass sich ein registrierter Benutzer mit Benutzername und Passwort anmelden darf	1. Starten Sie die Anwendung 2. Navigieren Sie zur Anmeldeseite 3.Geben Sie einen gültigen Benutzernamen ein 4.Geben Sie ein gültiges Passwort ein 5.Klicken Sie auf die Schaltfläche „Anmelden“.	Die Anmeldung sollte erfolgreich sein	wie erwartet	Passieren
2	Artikelfunktionalität hinzufügen	Artikel können zum Warenkorb hinzugefügt werden	1.Kategorienliste auswählen 2.Fügen Sie den Artikel zum Warenkorb hinzu	Der Artikel sollte zum Warenkorb hinzugefügt werden	Der Artikel wird nicht zum Warenkorb hinzugefügt	Scheitern
3	Abmeldefunktion	Überprüfen Sie die Abmeldefunktion	1. Wählen Sie die Schaltfläche „Abmelden“.	Der Benutzer sollte sich abmelden können.	Der Benutzer kann sich nicht abmelden	Scheitern

Häufig gestellte Fragen