Rauchprüfung gegen Vernunftprüfung: Unterschied zu Beispielen

smoke testing vs sanity testing

Untersuchen Sie die Unterschiede zwischen Rauch- und Sanity-Tests im Detail anhand von Beispielen:

In diesem Tutorial erfahren Sie, was Sanity Testing und Smoke Testing in Software Testing sind. Wir werden auch die wichtigsten Unterschiede zwischen Sanity- und Smoke-Tests anhand einfacher Beispiele kennenlernen.

In den meisten Fällen verwechseln wir die Bedeutung von Sanity Testing und Smoke Testing. Zuallererst sind diese beiden Tests übrigens “ anders ”Und werden in verschiedenen Phasen eines Testzyklus durchgeführt.

Was du lernen wirst:

• Sanity Testing
• Meine Erfahrung
• Sanity Testing Vs Regressionstest
• Strategie für das Testen mobiler Apps
• Vorsichtsmaßnahmen
• Rauchprüfung
• Beispiele für Rauchtests
  • # 1) Abnahmetests
  • # 2) Integrationstests
  • # 3) Systemtests
• Bedeutung in der SCRUM-Methodik
• Rauchtest gegen Build-Akzeptanztest
• Rauchtestzyklus
• Wer sollte den Rauchtest durchführen?
• Warum sollten wir Rauchtests automatisieren?
• Vorteile und Nachteile
• Unterschied zwischen Rauch- und Gesundheitstests
  • RAUCHPRÜFUNG
  • SANITY TESTING
• Literatur-Empfehlungen

Sanity Testing

Sanity Testing wird durchgeführt, wenn wir als QS nicht genügend Zeit haben, um alle Testfälle auszuführen, sei es Funktionsprüfung , UI-, OS- oder Browsertests.

Daher würde ich definieren,

'Sanity Testing als Testausführung, die durchgeführt wird, um jede Implementierung und ihre Auswirkungen zu berühren, jedoch nicht gründlich oder gründlich. Je nach Implementierung und Auswirkungen kann es sich um Funktions-, Benutzeroberflächen-, Versions- usw. Tests handeln.'

Fallen wir nicht alle in eine Situation, in der wir uns in ein oder zwei Tagen abmelden müssen, aber der Build zum Testen noch nicht veröffentlicht ist?

App, mit der Sie ein anderes Telefon ausspionieren können

Ah ja, ich wette, dass Sie sich in Ihrer Erfahrung mit Softwaretests mindestens einmal dieser Situation gestellt haben müssen. Nun, ich habe mich sehr damit auseinandergesetzt, weil meine Projekte größtenteils agil waren und wir manchmal gebeten wurden, sie am selben Tag zu liefern. Hoppla, wie könnte ich den Build innerhalb von Stunden testen und freigeben?

Ich war manchmal verrückt, denn selbst wenn es sich um eine kleine Funktionalität handelte, konnte die Implikation enorm sein. Und als Sahnehäubchen weigern sich Kunden manchmal einfach, zusätzliche Zeit zu geben. Wie könnte ich den gesamten Test in wenigen Stunden abschließen, alle Funktionen überprüfen? Bugs und loslassen?

Die Antwort auf all diese Probleme war sehr einfach, d. H. Nichts als Verwenden Sanity Testing Strategie.

Wenn wir diese Tests für ein Modul oder eine Funktionalität oder ein komplettes System durchführen, wird die Testfälle zur Ausführung werden so ausgewählt, dass sie alle wichtigen Teile desselben berühren, d. h. breite, aber flache Tests.

Manchmal werden die Tests sogar zufällig ohne Testfälle durchgeführt. Aber erinnere dich, Der Sanity-Test sollte nur durchgeführt werden, wenn Ihnen die Zeit ausgeht. Verwenden Sie diesen Test niemals für Ihre regulären Veröffentlichungen. Theoretisch ist dieser Test eine Teilmenge von Regressionstests .

Meine Erfahrung

Nach mehr als 8 Jahren Karriere im Bereich Softwaretests habe ich 3 Jahre lang gearbeitet Agile Methodik y und das war die Zeit, als ich meistens einen Gesundheitstest benutzte.

Alle großen Releases wurden systematisch geplant und ausgeführt, aber manchmal wurden kleine Releases gebeten, so schnell wie möglich geliefert zu werden. Wir hatten nicht viel Zeit, um die Testfälle zu dokumentieren, auszuführen, die Fehlerdokumentation durchzuführen, die Regression durchzuführen und den gesamten Prozess zu verfolgen.

Daher sind im Folgenden einige der wichtigsten Hinweise aufgeführt, denen ich in solchen Situationen gefolgt bin:

# 1) Setzen Sie sich mit dem Manager und dem Entwicklerteam zusammen, wenn sie die Implementierung besprechen, da sie schnell arbeiten müssen und wir daher nicht erwarten können, dass sie uns separat erklären.

Dies würde Ihnen auch helfen, eine Vorstellung davon zu bekommen, was sie implementieren werden, welchen Bereich es betreffen wird usw. Dies ist eine sehr wichtige Sache, da wir manchmal einfach die Auswirkungen und die vorhandenen Funktionen einfach nicht erkennen wird (im schlimmsten Fall) behindert.

#zwei) Da Ihnen die Zeit fehlt, können Sie zu dem Zeitpunkt, an dem das Entwicklungsteam an der Implementierung arbeitet, die Testfälle grob in Tools wie Evernote usw. notieren. Stellen Sie jedoch sicher, dass Sie sie irgendwo schreiben, damit Sie sie später hinzufügen können das Testfall-Tool.

#3) Halten Sie Ihr Testbed gemäß der Implementierung bereit. Wenn Sie der Meinung sind, dass rote Fahnen wie eine bestimmte Datenerstellung vorhanden sind, wenn ein Testbed Zeit benötigt (und dies ist ein wichtiger Test für die Veröffentlichung), heben Sie diese Flags sofort an und informieren Sie Ihren Manager oder PO über die Straßensperre.

Nur weil der Kunde so schnell wie möglich möchte, bedeutet dies nicht, dass eine Qualitätssicherung auch dann freigegeben wird, wenn sie zur Hälfte getestet wurde.

# 4) Vereinbaren Sie mit Ihrem Team und Manager, dass Sie aufgrund von Zeitproblemen die Fehler nur dem Entwicklungsteam mitteilen. Der formale Prozess des Hinzufügens und Markierens der Fehler für verschiedene Phasen des Fehlerverfolgungstools erfolgt später, um Zeit zu sparen .

# 5) Wenn das Entwicklungsteam am Ende testet, versuchen Sie, mit ihnen zu koppeln (Dev-QA-Pairing genannt), und führen Sie eine grundlegende Runde für das Setup selbst durch. Dies hilft, das Hin und Her des Builds zu vermeiden, wenn die grundlegende Implementierung fehlschlägt .

# 6) Nachdem Sie den Build erstellt haben, testen Sie zuerst die Geschäftsregeln und alle Anwendungsfälle. Sie können Tests wie die Validierung eines Feldes, die Navigation usw. für später aufbewahren.

# 7) Welche Fehler Sie auch finden, notieren Sie sich alle und versuchen Sie, sie gemeinsam den Entwicklern zu melden, anstatt sie einzeln zu melden, da sie leicht an einem Haufen arbeiten können.

# 8) Wenn Sie eine Anforderung für die Gesamt haben Leistungstest Stellen Sie dann sicher, dass Sie über ein geeignetes Automatisierungsframework für dasselbe verfügen. Weil es nahezu unmöglich ist, diese manuell mit einem Gesundheitstest zu testen.

# 9) Dies ist der wichtigste Teil und in der Tat der letzte Schritt Ihrer Strategie für Gesundheitstests: „Wenn Sie die Release-E-Mail oder das Dokument erstellen, erwähnen Sie alle von Ihnen ausgeführten Testfälle, die mit einer Statusmarkierung gefundenen Fehler und ob noch etwas übrig ist ungetestet erwähnen Sie es mit den Gründen '' Versuchen Sie, eine klare Geschichte über Ihre Tests zu schreiben, die alle darüber informiert, was getestet, verifiziert und was nicht.

Ich folgte dem religiös, als ich diese Tests verwendete.

Lassen Sie mich meine eigenen Erfahrungen teilen:

# 1) Wir haben an einer Website gearbeitet, auf der Anzeigen basierend auf den Keywords angezeigt wurden. Die Werbetreibenden gaben das Gebot für bestimmte Keywords ab, für die ein Bildschirm vorgesehen war. Der Standardgebotswert wurde früher als 0,25 USD angezeigt, was der Bieter sogar ändern konnte.

Es gab noch eine Stelle, an der dieses Standardgebot angezeigt wurde und die auch in einen anderen Wert geändert werden konnte. Der Kunde kam mit der Bitte, den Standardwert von 0,25 USD auf 0,5 USD zu ändern, erwähnte jedoch nur den offensichtlichen Bildschirm.

Während unserer Brainstorming-Diskussion haben wir diesen anderen Bildschirm vergessen (?), Da er für diesen Zweck nicht viel verwendet wurde. Aber beim Testen, als ich den Grundfall des Gebots von 0,5 USD ausführte und von Ende zu Ende überprüfte, stellte ich fest, dass der Cronjob für dasselbe fehlschlug, weil an einer Stelle 0,25 USD gefunden wurden.

Ich habe dies meinem Team gemeldet und wir haben die Änderung vorgenommen und sie am selben Tag selbst erfolgreich geliefert.

#zwei) Im Rahmen desselben Projekts (oben erwähnt) wurden wir gebeten, ein kleines Textfeld für Notizen / Kommentare zum Bieten hinzuzufügen. Es war eine sehr einfache Implementierung und wir haben uns verpflichtet, sie noch am selben Tag zu liefern.

Daher habe ich, wie oben erwähnt, alle Geschäftsregeln und Anwendungsfälle getestet und bei einigen Validierungstests festgestellt, dass die Seite abgestürzt ist, als ich eine Kombination von Sonderzeichen wie eingegeben habe.

Wir haben darüber nachgedacht und festgestellt, dass die tatsächlichen Bieter solche Kombinationen auf keinen Fall verwenden. Daher haben wir es mit einer gut formulierten Notiz zu diesem Thema veröffentlicht. Der Kunde akzeptierte dies als Fehler, stimmte jedoch zu, dass wir es später implementieren sollten, da es sich um einen schwerwiegenden, aber keinen vorherigen Fehler handelte.

#3) Vor kurzem habe ich an einem mobilen App-Projekt gearbeitet, und wir mussten den in der App angezeigten Lieferzeitpunkt gemäß der Zeitzone aktualisieren. Es sollte nicht nur in der App getestet werden, sondern auch für den Webdienst.

Während das Entwicklungsteam an der Implementierung arbeitete, erstellte ich die Automatisierungsskripte für die Webdiensttests und die DB-Skripte für die Änderung der Zeitzone des Lieferartikels. Dies ersparte mir meine Bemühungen und wir konnten innerhalb kurzer Zeit bessere Ergebnisse erzielen.

Sanity Testing Vs Regressionstest

Nachstehend sind einige Unterschiede zwischen den beiden angegeben:

Strategie für das Testen mobiler Apps

Sie müssen sich fragen, warum ich hier speziell über mobile Apps spreche?

Der Grund dafür ist, dass Betriebssystem und Browserversion für Web- oder Desktop-Apps nicht sehr unterschiedlich sind und insbesondere die Bildschirmgrößen Standard sind. Bei mobilen Apps wirken sich jedoch die Bildschirmgröße, das mobile Netzwerk, die Betriebssystemversionen usw. auf die Stabilität, das Aussehen und kurz gesagt auf den Erfolg Ihrer mobilen App aus.

Daher wird eine Strategieformulierung kritisch, wenn Sie diese Tests auf einer mobilen App durchführen, da ein Fehler Sie in große Schwierigkeiten bringen kann. Die Tests müssen intelligent und mit Vorsicht durchgeführt werden.

Im Folgenden finden Sie einige Hinweise, mit denen Sie diese Tests erfolgreich in einer „mobilen App“ durchführen können:

# 1) Analysieren Sie zunächst mit Ihrem Team die Auswirkungen der Betriebssystemversion auf die Implementierung.

Versuchen Sie, Antworten auf Fragen wie: Wird das Verhalten in den verschiedenen Versionen unterschiedlich sein? Funktioniert die Implementierung mit der niedrigsten unterstützten Version oder nicht? Wird es Leistungsprobleme bei der Implementierung von Versionen geben? Gibt es bestimmte Funktionen des Betriebssystems, die sich auf das Verhalten der Implementierung auswirken können? usw.

#zwei) Analysieren Sie in diesem Zusammenhang auch die Telefonmodelle, d. H. Gibt es Funktionen des Telefons, die sich auf die Implementierung auswirken? Ändert sich die Implementierung von Verhaltensänderungen mit GPS? Ändert sich das Implementierungsverhalten mit der Kamera des Telefons? usw. Wenn Sie feststellen, dass keine Auswirkungen auftreten, vermeiden Sie Tests an verschiedenen Telefonmodellen.

#3) Sofern es keine Änderungen an der Benutzeroberfläche für die Implementierung gibt, würde ich empfehlen, die UI-Tests auf der niedrigsten Priorität zu halten. Sie können das Team (falls gewünscht) darüber informieren, dass die Benutzeroberfläche nicht getestet wird.

# 4) Vermeiden Sie Tests in guten Netzwerken, um Zeit zu sparen, da es offensichtlich ist, dass die Implementierung in einem starken Netzwerk wie erwartet funktioniert. Ich würde empfehlen, mit dem Testen in einem 4G- oder 3G-Netzwerk zu beginnen.

# 5) Dieser Test muss in kürzerer Zeit durchgeführt werden. Stellen Sie jedoch sicher, dass Sie mindestens einen Feldtest durchführen, es sei denn, es handelt sich lediglich um eine Änderung der Benutzeroberfläche.

# 6) Wenn Sie auf eine Matrix mit verschiedenen Betriebssystemen und deren Version testen müssen, würde ich vorschlagen, dass Sie dies auf intelligente Weise tun. Wählen Sie beispielsweise die niedrigsten, mittleren und neuesten OS-Versionspaare zum Testen aus. Sie können im Release-Dokument erwähnen, dass nicht jede Kombination getestet wird.

# 7) Verwenden Sie in ähnlicher Weise für den UI-Implementierungstest kleine, mittlere und große Bildschirmgrößen, um Zeit zu sparen. Sie können auch einen Simulator und einen Emulator verwenden.

Vorsichtsmaßnahmen

Sanity Testing wird durchgeführt, wenn Sie wenig Zeit haben. Daher ist es Ihnen nicht möglich, jeden einzelnen Testfall auszuführen, und vor allem haben Sie nicht genügend Zeit, um Ihre Tests zu planen. Um die Schuldzuweisungen zu vermeiden, ist es besser, Vorsichtsmaßnahmen zu treffen.

In solchen Fällen kommt es häufig zu mangelnder schriftlicher Kommunikation, Testdokumentation und Fehlschlägen.

Stellen Sie Folgendes sicher, um sicherzustellen, dass Sie diesem nicht zum Opfer fallen:

• Akzeptieren Sie niemals einen Build zum Testen, bis Sie keine schriftliche Anforderung erhalten, die vom Client geteilt wird. Es kommt vor, dass Kunden Änderungen oder neue Implementierungen mündlich oder im Chat oder in einem einfachen 1-Liner in einer E-Mail mitteilen und von uns erwarten, dass wir dies als Voraussetzung behandeln. Fordern Sie Ihren Kunden auf, einige grundlegende Funktionspunkte und Akzeptanzkriterien anzugeben.
• Machen Sie sich immer grobe Notizen zu Ihren Testfällen und Fehlern, wenn Sie nicht genügend Zeit haben, um sie ordentlich zu schreiben. Lassen Sie diese niemals ohne Papiere. Wenn es etwas Zeit gibt, teilen Sie es Ihrem Lead oder Team mit, damit sie leicht darauf hinweisen können, wenn etwas fehlt.
• Wenn Sie und Ihr Team wenig Zeit haben, stellen Sie sicher, dass die Fehler in einer E-Mail im entsprechenden Status markiert sind. Sie können die vollständige Liste der Fehler per E-Mail an das Team senden und von den Entwicklern entsprechend markieren lassen. Halten Sie den Ball immer im Spielfeld des anderen.
• Wenn Sie haben Automatisierungs-Framework Verwenden Sie das und vermeiden Sie es Manuelle Prüfung Auf diese Weise können Sie in kürzerer Zeit mehr abdecken.
• Vermeiden Sie das Szenario „Veröffentlichung in 1 Stunde“, es sei denn, Sie sind zu 100% sicher, dass Sie liefern können.
• Last but not least, wie oben erwähnt, erstellen Sie eine detaillierte Release-E-Mail, in der mitgeteilt wird, was getestet wird, was ausgelassen wird, Gründe, Risiken, welche Fehler behoben werden, was später erfolgt usw.

Als Qualitätssicherung sollten Sie beurteilen, was der wichtigste Teil der Implementierung ist, der getestet werden muss, und welche Teile weggelassen oder grundlegend getestet werden können.

Planen Sie auch in kurzer Zeit eine Strategie, wie Sie vorgehen möchten, und Sie werden in der Lage sein, das Beste in dem vorgegebenen Zeitrahmen zu erreichen.

Rauchprüfung

Rauchtests sind keine erschöpfenden Tests, sondern eine Gruppe von Tests, die ausgeführt werden, um zu überprüfen, ob die grundlegenden Funktionen dieses bestimmten Builds wie erwartet ordnungsgemäß funktionieren oder nicht. Dies ist und sollte immer der erste Test sein, der an einem „neuen“ Build durchgeführt wird.

Wenn das Entwicklungsteam einen Build für die Qualitätssicherung zum Testen freigibt, ist es offensichtlich nicht möglich, den gesamten Build zu testen und sofort zu überprüfen, ob eine der Implementierungen Fehler aufweist oder ob eine der Arbeitsfunktionen fehlerhaft ist.

Wie wird vor diesem Hintergrund eine Qualitätssicherung sicherstellen, dass die grundlegenden Funktionen einwandfrei funktionieren?

Die Antwort darauf wird sein, a Rauchprüfung .

Sobald die Tests als bestanden markiert sind (in der Testsuite), wird der Build erst dann von der Qualitätssicherung für eingehende Tests und / oder Regressionen akzeptiert. Wenn einer der Rauchtests fehlschlägt, wird der Build abgelehnt und das Entwicklungsteam muss das Problem beheben und einen neuen Build zum Testen freigeben.

Theoretisch wird der Rauchtest als Test auf Oberflächenebene definiert, um zu bestätigen, dass der Build, den das Entwicklungsteam dem QS-Team zur Verfügung gestellt hat, für weitere Tests bereit ist. Diese Tests werden auch vom Entwicklungsteam durchgeführt, bevor der Build an das QA-Team freigegeben wird.

Diese Tests werden normalerweise in Integrationstests, Systemtests und Akzeptanzstufentests verwendet. Behandeln Sie dies niemals als Ersatz für die tatsächlichen vollständigen Tests . Es umfasst sowohl positive als auch negative Tests, abhängig von der Build-Implementierung.

Beispiele für Rauchtests

Diese Tests werden normalerweise für Integration, Akzeptanz und verwendet Systemtests .

In meiner Karriere als QS akzeptierte ich einen Build immer erst, nachdem ich einen Rauchtest durchgeführt hatte. Lassen Sie uns anhand einiger Beispiele verstehen, was ein Rauchtest aus der Perspektive all dieser drei Tests ist.

# 1) Abnahmetests

Immer wenn ein Build für die Qualitätssicherung freigegeben wird, wird ein Rauchtest in Form eines durchgeführt Abnahmetests Sollte gemacht werden.

In diesem Test besteht der erste und wichtigste Rauchtest darin, die grundlegende erwartete Funktionalität der Implementierung zu überprüfen. Auf diese Weise sollten Sie alle Implementierungen für diesen bestimmten Build überprüfen.

Nehmen wir die folgenden Beispiele als Implementierungen in einem Build, um die Rauchtests für diese zu verstehen:

• Die Anmeldefunktion wurde implementiert, damit sich die registrierten Treiber erfolgreich anmelden können.
• Implementierte die Dashboard-Funktionalität, um die Routen anzuzeigen, die ein Treiber heute ausführen soll.
• Die Funktion wurde implementiert, um eine entsprechende Nachricht anzuzeigen, wenn für einen bestimmten Tag keine Routen vorhanden sind.

Im obigen Build bedeutet der Rauchtest auf Akzeptanzstufe, dass überprüft wird, ob die drei grundlegenden Implementierungen ordnungsgemäß funktionieren. Wenn einer dieser drei Fehler auftritt, sollte die Qualitätssicherung den Build ablehnen.

# 2) Integrationstests

Dieser Test wird normalerweise durchgeführt, wenn die einzelnen Module implementiert und getestet werden. In dem Integrationstests Auf dieser Ebene werden diese Tests durchgeführt, um sicherzustellen, dass alle grundlegenden Integrations- und End-to-End-Funktionen wie erwartet ordnungsgemäß funktionieren.

Es kann sich um die Integration von zwei Modulen oder allen Modulen handeln, daher variiert die Komplexität des Rauchtests je nach Integrationsgrad.

Betrachten wir die folgenden Beispiele für die Implementierung der Integration für diesen Test:

• Implementierung der Integration von Routen- und Stoppmodulen.
• Die Integration der Aktualisierung des Ankunftsstatus wurde implementiert und auf dem Stoppbildschirm wiedergegeben.
• Implementierung der Integration der kompletten Abholung bis zu den Lieferfunktionsmodulen.

In diesem Build überprüft der Rauchtest nicht nur diese drei grundlegenden Implementierungen, sondern bei der dritten Implementierung werden in einigen Fällen auch die vollständige Integration überprüft. Es ist sehr hilfreich herauszufinden, welche Probleme bei der Integration auftreten und welche vom Entwicklungsteam unbemerkt bleiben.

# 3) Systemtests

Wie der Name selbst schon sagt, umfasst die Rauchprüfung auf Systemebene Tests für die wichtigsten und am häufigsten verwendeten Arbeitsabläufe des Systems. Dies erfolgt erst, nachdem das gesamte System bereit und getestet ist. Diese Prüfung auf Systemebene kann auch als Rauchtest vor dem Regressionstest bezeichnet werden.

Bevor mit der Regression des Gesamtsystems begonnen wird, werden die grundlegenden End-to-End-Funktionen im Rahmen des Rauchtests getestet. Die Rauchtestsuite für das gesamte System umfasst die End-to-End-Testfälle, die die Endbenutzer sehr häufig verwenden werden.

Dies erfolgt normalerweise mit Hilfe von Automatisierungstools.

Bedeutung in der SCRUM-Methodik

Heutzutage folgen die Projekte bei der Projektumsetzung kaum der Waterfall-Methodik, meist folgen alle Projekte Agile und GEDRÄNGE nur. Im Vergleich zur traditionellen Wasserfallmethode genießen Rauchprüfungen bei SCRUM und Agile einen hohen Stellenwert.

Ich habe 4 Jahre bei SCRUM gearbeitet . Und da wir wissen, dass in SCRUM die Sprints von kürzerer Dauer sind, ist es äußerst wichtig, diese Tests durchzuführen, damit die fehlgeschlagenen Builds sofort dem Entwicklungsteam gemeldet und ebenfalls behoben werden können.

Es folgen einige wegbringen zur Bedeutung dieser Tests in SCRUM:

• Aus dem 14-tägigen Sprint wird die Halbzeit der Qualitätssicherung zugewiesen, aber manchmal verzögern sich die Builds der Qualitätssicherung.
• Bei Sprints ist es für das Team am besten, wenn die Probleme frühzeitig gemeldet werden.
• Jede Geschichte hat eine Reihe von Akzeptanzkriterien, daher entspricht das Testen der ersten 2-3 Akzeptanzkriterien dem Rauchtest dieser Funktionalität. Kunden lehnen die Lieferung ab, wenn ein einzelnes Kriterium fehlschlägt.
• Stellen Sie sich vor, was passieren wird, wenn das Entwicklungsteam Ihnen innerhalb von zwei Tagen den Build geliefert hat und nur noch drei Tage für die Demo verbleiben und Sie auf einen grundlegenden Funktionsfehler stoßen.
• Im Durchschnitt hat ein Sprint Storys im Bereich von 5 bis 10, daher ist es bei der Erstellung des Builds wichtig, sicherzustellen, dass jede Story wie erwartet implementiert wird, bevor der Build in die Tests aufgenommen wird.
• Wenn das gesamte System getestet und zurückgeführt werden soll, ist der Aktivität ein Sprint gewidmet. Zwei Wochen, vielleicht etwas weniger, um das gesamte System zu testen. Daher ist es sehr wichtig, die grundlegendsten Funktionen zu überprüfen, bevor Sie mit der Regression beginnen.

Rauchtest gegen Build-Akzeptanztest

Smoke Testing steht in direktem Zusammenhang mit Build Acceptance Testing (BAT).

In BAT führen wir dieselben Tests durch, um zu überprüfen, ob der Build nicht fehlgeschlagen ist und ob das System ordnungsgemäß funktioniert oder nicht. Manchmal kommt es vor, dass beim Erstellen eines Builds einige Probleme auftreten und der Build bei der Bereitstellung für die Qualitätssicherung nicht funktioniert.

Ich würde sagen, dass BAT Teil einer Rauchprüfung ist, denn wenn das System ausfällt, wie können Sie als QS den Build zum Testen akzeptieren? Nicht nur die Funktionen, sondern auch das System selbst muss funktionieren, bevor die Qualitätssicherung mit eingehenden Tests fortfährt.

Rauchtestzyklus

Das folgende Flussdiagramm erläutert den Rauchtestzyklus.

Sobald ein Build für eine Qualitätssicherung bereitgestellt wurde, folgt der grundlegende Zyklus: Wenn der Rauchtest erfolgreich ist, wird der Build vom QS-Team für weitere Tests akzeptiert. Wenn er jedoch fehlschlägt, wird der Build abgelehnt, bis die gemeldeten Probleme behoben sind.

Testzyklus

Wer sollte den Rauchtest durchführen?

Nicht das gesamte Team ist an dieser Art von Tests beteiligt, um die Zeitverschwendung aller QS zu vermeiden.

Die Rauchprüfung wird idealerweise vom QS-Leiter durchgeführt, der auf der Grundlage des Ergebnisses entscheidet, ob der Build zur weiteren Prüfung an das Team übergeben oder abgelehnt wird. In Abwesenheit des Leads können die QS auch diese Tests selbst durchführen.

Manchmal, wenn es sich um ein großes Projekt handelt, kann eine Gruppe von Qualitätssicherern diese Tests auch durchführen, um nach Showstoppern zu suchen. Dies ist jedoch bei SCRUM nicht der Fall, da SCRUM eine flache Struktur ohne Leads oder Manager ist und jeder Tester seine eigene Verantwortung gegenüber seinen Geschichten hat.

Daher führen einzelne QS diese Tests für die Geschichten durch, die sie besitzen.

Warum sollten wir Rauchtests automatisieren?

Dieser Test ist der erste Test, der an einem Build durchgeführt wird, der von den Entwicklungsteams veröffentlicht wurde. Basierend auf den Ergebnissen dieser Tests werden weitere Tests durchgeführt (oder der Build wird abgelehnt).

Der beste Weg, um diese Tests durchzuführen, besteht darin, ein Automatisierungstool zu verwenden und die Smoke Suite so zu planen, dass sie ausgeführt wird, wenn ein neuer Build erstellt wird. Sie denken vielleicht, warum sollte ich 'Automatisieren Sie die Rauchtestsuite'?

Betrachten wir den folgenden Fall:

Nehmen wir an, Sie sind eine Woche vor Ihrer Freilassung und von den insgesamt 500 Testfällen umfasst Ihre Rauchtestsuite 80-90. Stellen Sie sich vor, wie viel Zeit Sie benötigen, wenn Sie alle diese 80-90-Testfälle manuell ausführen. Ich denke 4-5 Tage (Minimum).

Wenn Sie jedoch die Automatisierung verwenden und Skripte erstellen, um alle diese 80-90 Testfälle auszuführen, werden diese im Idealfall in 2-3 Stunden ausgeführt und Sie haben die Ergebnisse sofort bei sich. Hat es nicht Ihre kostbare Zeit gespart und Ihnen die Ergebnisse über den Einbau viel weniger Zeit gegeben?

Datenanbieter-Website für Online-Angebote

Vor 5 Jahren habe ich eine Finanzprojektions-App getestet, die Eingaben zu Ihrem Gehalt, Ihren Ersparnissen usw. vorgenommen und Ihre Steuern, Ersparnisse und Gewinne in Abhängigkeit von den Finanzregeln projiziert hat. Gleichzeitig haben wir Anpassungen für Länder vorgenommen, die vom Land und seinen Steuerregeln abhängen (im Code).

Für dieses Projekt hatte ich 800 Testfälle und 250 waren Rauchtestfälle. Mit der Verwendung von Selen konnten wir die Ergebnisse dieser 250 Testfälle in 3-4 Stunden leicht automatisieren und erhalten. Es hat nicht nur unsere Zeit gespart, sondern uns auch so schnell wie möglich die Showstopper gezeigt.

Verwenden Sie für diese Tests die Hilfe der Automatisierung, es sei denn, eine Automatisierung ist nicht möglich.

Vorteile und Nachteile

Schauen wir uns zunächst die Vorteile an, die im Vergleich zu den wenigen Nachteilen viel zu bieten haben.

Vorteile:

• Einfach durchzuführen.
• Reduziert das Risiko.
• Mängel werden sehr früh erkannt.
• Spart Aufwand, Zeit und Geld.
• Läuft schnell, wenn automatisiert.
• Geringste Integrationsrisiken und -probleme.
• Verbessert die Gesamtqualität des Systems.

Nachteile:

• Diese Prüfung ist nicht gleich oder ersetzt die vollständige Funktionsprüfung.
• Auch nach bestandenem Rauchtest können Showstopper-Fehler auftreten.
• Diese Art des Testens ist am besten geeignet, wenn Sie automatisieren können, da sonst viel Zeit für die manuelle Ausführung der Testfälle aufgewendet wird, insbesondere in Großprojekten mit etwa 700-800 Testfällen.

Rauchprüfungen sollten auf jeden Fall bei jedem Build durchgeführt werden, da sie sehr früh auf die Hauptfehler und Showstopper hinweisen. Dies gilt nicht nur für neue Funktionen, sondern auch für die Integration von Modulen, die Behebung von Problemen und die Improvisation. Es ist ein sehr einfacher Prozess, das richtige Ergebnis zu erzielen.

Diese Prüfung kann als Einstiegspunkt für die vollständige Funktionsprüfung der Funktionalität oder des Systems (als Ganzes) betrachtet werden. Aber vorher, Das QS-Team sollte sehr klar darüber sein, welche Tests als Rauchtests durchzuführen sind . Diese Tests können den Aufwand minimieren, Zeit sparen und die Qualität des Systems verbessern. Es nimmt einen sehr wichtigen Platz in Sprints ein, da die Zeit in Sprints kürzer ist.

Diese Tests können sowohl manuell als auch mit Hilfe von Automatisierungstools durchgeführt werden. Der beste und bevorzugte Weg ist jedoch die Verwendung von Automatisierungstools, um Zeit zu sparen.

Unterschied zwischen Rauch- und Gesundheitstests

In den meisten Fällen verwechseln wir die Bedeutung von Sanity Testing und Smoke Testing. Zuallererst sind diese beiden Tests übrigens “ anders ”Und in verschiedenen Phasen eines Testzyklus durchgeführt.

Es folgt eine schematische Darstellung ihrer Unterschiede:

RAUCHPRÜFUNG

• Diese Prüfung hat ihren Ursprung in der Hardware- Testen Sie die Praxis, eine neue Hardware zum ersten Mal einzuschalten, und betrachten Sie sie als Erfolg, wenn sie kein Feuer und keinen Rauch fängt. In der Softwareindustrie ist dieses Testen ein flacher und breiter Ansatz, bei dem alle Bereiche der Anwendung getestet werden, ohne zu tief zu gehen.
• Ein Rauchtest wird per Skript erstellt, entweder unter Verwendung eines schriftlichen Satzes von Tests oder eines automatisierten Tests
• Ein Rauchtest soll jeden Teil der Anwendung flüchtig berühren. Es ist flach und breit.
• Diese Tests werden durchgeführt, um sicherzustellen, dass die wichtigsten Funktionen eines Programms funktionieren, ohne sich um die Details zu kümmern. (Wie Build-Überprüfung).
• Bei diesem Test handelt es sich um eine normale Überprüfung des Zustands einer Anwendung, bevor sie eingehend getestet wird.

SANITY TESTING

• Ein Sanity-Test ist ein enger Regressionstest, der sich auf einen oder mehrere Funktionsbereiche konzentriert. Sanity Testing ist normalerweise eng und tief.
• Dieser Test ist normalerweise ohne Skript.
• Dieser Test wird verwendet, um festzustellen, dass ein kleiner Teil der Anwendung nach einer geringfügigen Änderung noch funktioniert.
• Diese Prüfung ist eine flüchtige Prüfung. Sie wird immer dann durchgeführt, wenn eine flüchtige Prüfung ausreicht, um nachzuweisen, dass die Anwendung gemäß den Spezifikationen funktioniert. Diese Teststufe ist eine Teilmenge der Regressionstests.
• Hiermit wird überprüft, ob die Anforderungen erfüllt sind oder nicht, und alle Funktionen werden zuerst überprüft.

Ich hoffe, Sie sind sich der Unterschiede zwischen diesen beiden großen und wichtigen Softwaretesttypen klar. Fühlen Sie sich frei, Ihre Gedanken in den Kommentaren unten zu teilen!

Literatur-Empfehlungen

• Beste Software-Test-Tools 2021 (QA Test Automation Tools)
• Unterschied zwischen Desktop-, Client-Server-Tests und Web-Tests
• Funktionstests gegen nichtfunktionale Tests
• Testen von Primer eBook Download
• Alpha-Tests und Beta-Tests (eine vollständige Anleitung)
• Portability Testing Guide mit praktischen Beispielen
• Arten von Softwaretests: Verschiedene Testtypen mit Details
• Funktionstests vs. Leistungstests: Sollte dies gleichzeitig durchgeführt werden?