Regressionstests sind Black-Box-Testtechniken. Es wird verwendet, um zu authentifizieren, dass eine Codeänderung in der Software keinen Einfluss auf die bestehende Funktionalität des Produkts hat. Durch Regressionstests wird sichergestellt, dass das Produkt mit neuen Funktionen, Fehlerbehebungen oder Änderungen an der vorhandenen Funktion einwandfrei funktioniert.
Java-flüchtiges Schlüsselwort
Regressionstests sind eine Art von Softwaretest . Testfälle werden erneut ausgeführt, um zu überprüfen, ob die vorherige Funktionalität der Anwendung einwandfrei funktioniert und die neuen Änderungen keine Fehler verursacht haben.
Regressionstests können für einen neuen Build durchgeführt werden, wenn sich die ursprüngliche Funktionalität erheblich ändert. Dadurch wird sichergestellt, dass der Code auch dann noch funktioniert, wenn Änderungen vorgenommen werden. Regression bedeutet, die unveränderten Teile der Anwendung erneut zu testen.
Regressionstests werden auch als Verifizierungsmethode bezeichnet. Testfälle werden häufig automatisiert. Testfälle müssen viele Male ausgeführt werden, und die wiederholte manuelle Ausführung desselben Testfalls ist zeitaufwändig und mühsam.
Beispiel für einen Regressionstest
Hier nehmen wir einen Fall, um den Regressionstest effizient zu definieren:
Stellen Sie sich ein Produkt Y vor, bei dem eine der Funktionen darin besteht, Bestätigung, Annahme und den Versand von E-Mails auszulösen. Es muss auch getestet werden, um sicherzustellen, dass die Änderung im Code keine Auswirkungen auf sie hat. Regressionstests hängen nicht von einer Programmiersprache ab Java , C++ , C# usw. Diese Methode wird verwendet, um das Produkt auf Änderungen oder durchgeführte Aktualisierungen zu testen. Dadurch wird sichergestellt, dass Änderungen an einem Produkt keine Auswirkungen auf das vorhandene Modul des Produkts haben. Stellen Sie sicher, dass die behobenen Fehler und die neu hinzugefügten Funktionen in der vorherigen Arbeitsversion der Software keine Probleme verursacht haben.
Wann können wir Regressionstests durchführen?
Wir führen Regressionstests durch, wann immer der Produktionscode geändert wird.
Wir können Regressionstests im folgenden Szenario durchführen:
1. Wenn der Anwendung neue Funktionen hinzugefügt werden.
Beispiel:
Eine Website verfügt über eine Anmeldefunktion, die es Benutzern ermöglicht, sich nur per E-Mail anzumelden. Bietet jetzt eine neue Funktion für die Anmeldung über Facebook.
2. Wenn ein Änderungsbedarf besteht.
Beispiel:
Merken Sie sich das zuvor gültige Passwort, das von der Anmeldeseite entfernt wurde.
3. Wenn der Mangel behoben ist
Beispiel:
Angenommen, die Anmeldeschaltfläche funktioniert auf einer Anmeldeseite nicht und ein Tester meldet einen Fehler, der besagt, dass die Anmeldeschaltfläche defekt ist. Sobald der Fehler von den Entwicklern behoben wurde, testet der Tester ihn, um sicherzustellen, dass die Anmeldeschaltfläche wie erwartet funktioniert. Gleichzeitig testet der Tester andere Funktionen, die mit der Anmeldeschaltfläche zusammenhängen.
4. Wenn ein Leistungsproblem behoben wird
Beispiel:
Das Laden einer Homepage dauert 5 Sekunden, wodurch sich die Ladezeit auf 2 Sekunden reduziert.
5. Wenn sich die Umgebung ändert
Beispiel:
Wenn wir die Datenbank von MySql auf Oracle aktualisieren.
Wie führt man einen Regressionstest durch?
Der Bedarf an Regressionstests entsteht, wenn die Softwarewartung Verbesserungen, Fehlerkorrekturen, Optimierungen und die Löschung bestehender Funktionen umfasst. Diese Änderungen können die Systemfunktionalität beeinträchtigen. In diesem Fall sind Regressionstests erforderlich.
Regressionstests können mit den folgenden Techniken durchgeführt werden:
1. Alle erneut testen:
Re-Test ist einer der Ansätze zur Durchführung von Regressionstests. Bei diesem Ansatz sollten alle Testfallanzüge erneut ausgeführt werden. Hier können wir einen erneuten Test definieren, wenn ein Test fehlschlägt und wir feststellen, dass die Ursache des Fehlers ein Softwarefehler ist. Wenn der Fehler gemeldet wird, können wir mit einer neuen Version der Software rechnen, in der der Fehler behoben ist. In diesem Fall müssen wir den Test erneut durchführen, um zu bestätigen, dass der Fehler behoben ist. Dies wird als erneutes Testen bezeichnet. Manche bezeichnen dies als Bestätigungstest.
Der erneute Test ist sehr teuer, da er enormen Zeit- und Ressourcenaufwand erfordert.
2. Auswahl des Regressionstests:
- Bei dieser Technik wird ein ausgewählter Testfallanzug und nicht ein ganzer Testfallanzug ausgeführt.
- Die ausgewählten Testfallanzüge sind in zwei Fälle aufgeteilt
- Wiederverwendbare Testfälle.
- Veraltete Testfälle.
- Wiederverwendbare Testfälle können in nachfolgenden Regressionszyklen verwendet werden.
- Veraltete Testfälle können im nachfolgenden Regressionszyklus nicht verwendet werden.
3. Priorisierung von Testfällen:
Priorisieren Sie den Testfall je nach geschäftlicher Auswirkung, kritischer und häufig genutzter Funktionalität. Durch die Auswahl von Testfällen wird die Regressionstestsuite reduziert.
Was sind die Regressionstest-Tools?
Regressionstests sind ein wesentlicher Bestandteil des Qualitätssicherungsprozesses. Bei der Durchführung der Regression können wir mit den folgenden Herausforderungen konfrontiert werden:
Die Durchführung von Regressionstests nimmt viel Zeit in Anspruch. Bei Regressionstests werden bestehende Tests noch einmal in Anspruch genommen, sodass Tester keine Lust haben, den Test noch einmal durchzuführen.
Auch Regressionstests sind komplex, wenn ein Produkt aktualisiert werden muss; Auch die Listen der Tests nehmen zu.
Regressionstests stellen sicher, dass die vorhandenen Produktfunktionen weiterhin funktionsfähig sind. Die Kommunikation über Regressionstests mit einem technisch nicht versierten Leiter kann eine schwierige Aufgabe sein. Die Führungskraft möchte, dass das Produkt weiterentwickelt wird, und investiert viel Zeit in Regressionstests, um sicherzustellen, dass die vorhandenen Funktionen funktionieren.
Regressionstestprozess
Der Regressionstestprozess kann übergreifend durchgeführt werden baut und das Veröffentlichungen .
Regressionstests über die Builds hinweg
Sobald der Fehler behoben ist, testen wir den Fehler erneut und führen einen Regressionstest durch, wenn es ein abhängiges Modul gibt.
Zum Beispiel , Wie wir die Regressionstests durchführen, wenn wir unterschiedliche Builds haben Build 1, Build 2 und Build 3 , die unterschiedliche Szenarien haben.
Build1
- Zunächst stellt der Kunde die Geschäftsanforderungen bereit.
- Anschließend beginnt das Entwicklungsteam mit der Entwicklung der Funktionen.
- Danach beginnt das Testteam mit dem Schreiben der Testfälle. Beispielsweise schreiben sie 900 Testfälle für die Veröffentlichung Nr. 1 des Produkts.
- Und dann beginnen sie mit der Implementierung der Testfälle.
- Sobald das Produkt freigegeben ist, führt der Kunde eine Abnahmetestrunde durch.
- Und am Ende wird das Produkt auf den Produktionsserver verschoben.
Build2
- Nun bittet der Kunde um die Hinzufügung von 3-4 zusätzlichen (neuen) Funktionen und stellt auch die Anforderungen für die neuen Funktionen bereit.
- Das Entwicklungsteam beginnt mit der Entwicklung neuer Funktionen.
- Danach beginnt das Testteam mit dem Schreiben des Testfalls für die neuen Funktionen und schreibt etwa 150 neue Testfälle. Daher beträgt die Gesamtzahl der geschriebenen Testfälle für beide Versionen 1050.
- Jetzt beginnt das Testteam mit dem Testen der neuen Funktionen anhand von 150 neuen Testfällen.
- Sobald dies erledigt ist, beginnen sie mit dem Testen der alten Funktionen mithilfe von 900 Testfällen, um zu überprüfen, ob das Hinzufügen der neuen Funktion die alten Funktionen beschädigt hat oder nicht.
- Hier nennt man das Testen der alten Features Regressionstests .
- Sobald alle Funktionen (neu und alt) getestet wurden, wird das Produkt an den Kunden übergeben und anschließend führt der Kunde den Abnahmetest durch.
- Sobald der Abnahmetest abgeschlossen ist, wird das Produkt auf den Produktionsserver verschoben.
Build3
- Nach der zweiten Version möchte der Kunde eine der Funktionen wie „Sales“ entfernen.
- Anschließend löscht er/sie alle Testfälle, die zum Vertriebsmodul gehören (ca. 120 Testfälle).
- Testen Sie dann die andere Funktion, um sicherzustellen, dass alle anderen Funktionen nach dem Entfernen der Testfälle des Verkaufsmoduls einwandfrei funktionieren. Dieser Vorgang wird im Rahmen des Regressionstests durchgeführt.
Notiz:
- Testen Sie die stabilen Funktionen, um sicherzustellen, dass sie aufgrund der Änderungen fehlerhaft sind. Hier bedeuten Änderungen, dass die Änderung, Ergänzung, Fehlerbehebung oder Löschung .
- Durch die erneute Ausführung derselben Testfälle in den verschiedenen Builds oder Releases soll sichergestellt werden, dass Änderungen (Änderungen, Hinzufügungen, Fehlerbehebungen oder Löschungen) keine Fehler in stabilen Funktionen verursachen.
Regressionstests im gesamten Release
Der Regressionstestprozess beginnt immer dann, wenn es eine neue Version für dasselbe Projekt gibt, da die neue Funktion möglicherweise Auswirkungen auf die alten Elemente in den vorherigen Versionen hat.
Um den Regressionstestprozess zu verstehen, führen wir die folgenden Schritte aus:
Schritt 1
Es gibt keine Regressionstests Veröffentlichung Nr. 1 weil in der Version Nr. 1 keine Änderungen vorgenommen wurden, da die Version selbst neu ist.
Schritt 2
Das Konzept des Regressionstests beginnt mit Veröffentlichung Nr. 2 wenn der Kunde etwas gibt neue Anforderungen .
Schritt 3
Nachdem sie zunächst die neuen Anforderungen (Änderungsfunktionen) kennengelernt haben, werden sie (die Entwickler und Testingenieure) die Anforderungen verstehen, bevor sie mit dem fortfahren Einflussanalyse .
Schritt 4
Nachdem wir die neuen Anforderungen verstanden haben, werden wir eine Runde durchführen Einflussanalyse Um das große Risiko zu vermeiden, stellt sich hier jedoch die Frage: Wer führt die Auswirkungsanalyse durch?
Schritt 5
Die Wirkungsanalyse erfolgt durch die Kunde basierend auf ihrer Geschäftswissen , Die Entwickler basierend auf ihrer Programmierkenntnisse , und was am wichtigsten ist, es wird von der gemacht Testingenieur weil sie das haben Produktkenntnisse .
Hinweis: Wenn eine einzelne Person dies tut, deckt sie möglicherweise nicht alle Auswirkungsbereiche ab. Daher schließen wir alle Personen ein, damit wir einen maximalen Auswirkungsbereich abdecken können. Die Auswirkungsanalyse sollte in den frühen Phasen der Veröffentlichungen durchgeführt werden.
Schritt 6
Sobald wir damit fertig sind Aufprallbereich , dann wird der Entwickler das vorbereiten Aufprallbereich (Dokument) , und das Kunde werde das auch vorbereiten Dokument zum Aufprallbereich damit wir das erreichen können maximale Abdeckung der Wirkungsanalyse .
Schritt7
Nach Abschluss der Auswirkungsanalyse senden der Entwickler, der Kunde und der Testingenieur die Berichte# der Einschlagsgebietsunterlagen an die Messleitung . Und in der Zwischenzeit arbeiten der Testingenieur und der Entwickler fleißig am neuen Testfall.
Schritt 8
Sobald der Testleiter die Berichtsnummer erhält, wird er/sie diese erhalten konsolidieren die Berichte und gespeichert in der Testfall-Anforderungs-Repository für die Veröffentlichung Nr. 1.
Hinweis: Testfall-Repository: Hier speichern wir alle Testfälle von Releases.
Schritt 9
Danach nimmt der Testleiter die Hilfe von RTM in Anspruch und wählt das Notwendige aus Regressionstestfall von dem Testfall-Repository , und diese Dateien werden im abgelegt Regressionstest-Suite .
Notiz:
- Der Testleiter speichert den Regressionstestfall in der Regressionstestsuite, um weitere Verwirrung zu vermeiden.
Schritt 10
Danach, wenn der Testingenieur mit der Arbeit an den neuen Testfällen fertig ist, wird der Testleiter dies tun Weisen Sie den Regressionstestfall zu an den Prüfingenieur.
Schritt 11
Wenn alle Regressionstestfälle und die neuen Funktionen vorhanden sind stabil und pass , dann überprüfen Sie die Aufprallbereich anhand des Testfalls bis es für die alten Funktionen und die neuen Funktionen haltbar ist und dann an den Kunden übergeben wird.
Arten von Regressionstests
Die verschiedenen Arten von Regressionstests sind wie folgt:
- Unit-Regressionstest [URT]
- Regionaler Regressionstest[RRT]
- Vollständiger oder vollständiger Regressionstest [FRT]
1) Unit-Regressionstest [URT]
Dabei testen wir nur die geänderte Einheit, nicht den Aufprallbereich, da dieser die Komponenten desselben Moduls beeinträchtigen kann.
Beispiel 1
In der folgenden Anwendung und im ersten Build entwickelt der Entwickler die Suchen Schaltfläche, die akzeptiert 1-15 Zeichen . Anschließend testet der Testingenieur die Suchschaltfläche mithilfe des Testfallentwurfstechnik .
Jetzt nimmt der Client einige Änderungen an der Anforderung vor und fordert auch an, dass die Schaltfläche „Suchen“. kann das akzeptieren 1-35 Zeichen . Der Testingenieur testet nur die Schaltfläche „Suchen“, um sicherzustellen, dass sie 1–35 Zeichen lang ist, und überprüft keine weiteren Funktionen des ersten Builds.
Beispiel2
Hier haben wir Baue B001 , und ein Fehler wird identifiziert und der Bericht wird an den Entwickler übermittelt. Der Entwickler wird den Fehler beheben und einige neue Funktionen mitsenden, die im zweiten Schritt entwickelt werden Baue B002 . Danach testet der Prüfingenieur erst, nachdem der Fehler behoben ist.
- Der Testingenieur wird das durch Klicken auf erkennen Einreichen Mit der Schaltfläche gelangen Sie zur leeren Seite.
- Und es handelt sich um einen Defekt, der zur Behebung an den Entwickler geschickt wird.
- Wenn der neue Build mit den Fehlerbehebungen geliefert wird, testet der Testingenieur nur die Schaltfläche „Senden“.
- Und hier werden wir nicht andere Funktionen des ersten Builds überprüfen und die neuen Funktionen testen und den zweiten Build einsenden.
- Wir sind sicher, dass die Behebung der Einreichen Die Schaltfläche hat keinen Einfluss auf die anderen Funktionen, daher testen wir nur den behobenen Fehler.
Daher können wir sagen, dass durch das Testen nur die geänderte Funktion aufgerufen wird Unit-Regressionstests .
2) Regionaler Regressionstest [RRT]
Dabei werden wir die Modifikation zusammen mit dem oder den Einwirkungsbereichen testen, die als bezeichnet werden Regionaler Regressionstest . Hier testen wir den Auswirkungsbereich, denn wenn zuverlässige Module vorhanden sind, wirkt sich dies auch auf die anderen Module aus.
Zum Beispiel:
Im Bild unten können wir sehen, dass wir vier verschiedene Module haben, wie z Modul A, Modul B, Modul C und Modul D , die von den Entwicklern zum Testen während des ersten Builds bereitgestellt werden. Jetzt wird der Testingenieur die Fehler identifizieren Modul D . Der Fehlerbericht wird an die Entwickler gesendet, und das Entwicklungsteam behebt diese Fehler und sendet den zweiten Build.
Im zweiten Build werden die bisherigen Mängel behoben. Jetzt versteht der Testingenieur, dass sich die Fehlerbehebung in Modul D auf einige Funktionen in ausgewirkt hat Modul A und Modul C . Daher testet der Testingenieur zunächst das Modul D, in dem der Fehler behoben wurde, und überprüft dann die Aufprallbereiche Modul A und Modul C . Daher wird dieser Test als bezeichnet Regionaler Regressionstest.
Bei der Durchführung der regionalen Regressionstests kann das folgende Problem auftreten:
Problem:
Im ersten Build sendet der Kunde einige Änderungen an den Anforderungen und möchte dem Produkt auch neue Funktionen hinzufügen. Die Anforderungen werden an beide Teams gesendet, d. h. an die Entwicklungs- und Testteams.
Nachdem die Anforderungen vorliegen, beginnt das Entwicklungsteam mit der Änderung und entwickelt auch die neuen Funktionen basierend auf den Anforderungen.
Nun sendet der Testleiter eine E-Mail an die Kunden und fragt sie, ob alle betroffenen Bereiche betroffen sein werden, nachdem die erforderlichen Änderungen vorgenommen wurden. Dadurch erhält der Kunde eine Vorstellung davon, welche Funktionen noch einmal getestet werden müssen. Außerdem sendet er/sie eine E-Mail an das Entwicklungsteam, um zu erfahren, welche Bereiche der Anwendung von den Änderungen und Hinzufügungen neuer Funktionen betroffen sein werden.
Und in ähnlicher Weise sendet der Kunde eine E-Mail an das Testteam, um eine Liste der Auswirkungsbereiche anzufordern. Daher sammelt der Testleiter auch die Auswirkungsliste vom Kunden, vom Entwicklungsteam und vom Testteam.
Das Auswirkungsliste wird an alle Testingenieure gesendet, die sich die Liste ansehen und prüfen, ob ihre Funktionen geändert wurden, und wenn ja, dann werden sie dies tun regionale Regressionstests . Die Aufprallbereiche und modifizierten Bereiche werden alle von den jeweiligen Ingenieuren getestet. Jeder Prüfingenieur testet nur die Funktionen, die durch die Änderung beeinträchtigt sein könnten.
Das Problem bei diesem oben genannten Ansatz besteht darin, dass der Testleiter möglicherweise nicht den gesamten Überblick über die Auswirkungsbereiche erhält, da das Entwicklungsteam und der Kunde möglicherweise nicht so viel Zeit haben, seine E-Mails rückgängig zu machen.
Lösung
Um das oben genannte Problem zu lösen, gehen wir wie folgt vor:
Wenn ein neuer Build mit den neuesten Funktionen und Fehlerbehebungen ausgestattet ist, wird das Testteam ein Treffen vereinbaren, bei dem darüber gesprochen wird, ob die oben genannten Änderungen Auswirkungen auf die Funktionen haben. Deshalb werden sie eine Runde machen Einflussanalyse und generieren Sie die Auswirkungsliste . In dieser speziellen Liste versucht der Testingenieur, die wahrscheinlichsten Aufprallbereiche einzuschließen, wodurch auch die Wahrscheinlichkeit von Fehlern verringert wird.
Wenn ein neuer Build kommt, befolgt das Testteam das folgende Verfahren:
- Sie führen Rauchtests durch, um die grundlegende Funktionalität einer Anwendung zu überprüfen.
- Anschließend werden sie neue Funktionen testen.
- Anschließend prüfen sie die geänderten Funktionen.
- Sobald die Überprüfung der geänderten Funktionen abgeschlossen ist, testet der Testingenieur die Fehler erneut.
- Anschließend überprüfen sie den Wirkungsbereich, indem sie regionale Regressionstests durchführen.
Nachteil der Verwendung von Unit- und Regional-Regressionstests
Im Folgenden sind einige der Nachteile der Verwendung von Einheits- und regionalen Regressionstests aufgeführt:
- Es kann sein, dass wir einige Aufprallbereiche übersehen.
- Es ist möglich, dass wir den falschen Aufprallbereich identifizieren.
Hinweis: Wir können sagen, dass die umfangreiche Arbeit, die wir an den regionalen Regressionstests leisten, dazu führen wird, dass wir mehr Fehler erhalten. Wenn wir aber mit der gleichen Hingabe an den vollständigen Regressionstests arbeiten, werden wir weniger Fehler bekommen. Daher können wir hier feststellen, dass eine Verbesserung des Testaufwands uns nicht dabei helfen wird, mehr Fehler zu erkennen.
3) Vollständiger Regressionstest [FRT]
Während der zweiten und dritten Version des Produkts bittet der Kunde um das Hinzufügen von drei bis vier neuen Funktionen und außerdem müssen einige Mängel gegenüber der vorherigen Version behoben werden. Anschließend führt das Testteam eine Auswirkungsanalyse durch und stellt fest, dass die oben genannte Änderung dazu führen wird, dass wir das gesamte Produkt testen.
Daher können wir sagen, dass das Testen des geänderte Funktionen Und alle übrigen (alten) Funktionen heißt das Vollständiger Regressionstest .
Wann führen wir vollständige Regressionstests durch?
Wir führen die FRT durch, wenn die folgenden Bedingungen vorliegen:
- Wenn die Änderung in der Quelldatei des Produkts erfolgt. Zum Beispiel , JVM ist die Stammdatei der JAVA-Anwendung, und wenn in JVM Änderungen vorgenommen werden, wird das gesamte JAVA-Programm getestet.
- Wenn wir n-Anzahl Änderungen durchführen müssen.
Notiz:
Der regionale Regressionstest ist der ideale Ansatz für Regressionstests. Das Problem besteht jedoch darin, dass wir bei der Durchführung des regionalen Regressionstests möglicherweise viele Fehler übersehen.
Und hier werden wir dieses Problem mit Hilfe des folgenden Ansatzes lösen:
- Wenn der Antrag für den Test gestellt wird, testet der Testingenieur die ersten 10–14 Zyklen und führt die folgenden Schritte durch RRT .
- Dann machen wir im 15. Zyklus FRT. Und auch für den nächsten 10-15-Zyklus tun wir das Regionaler Regressionstest , und für den 31. Zyklus machen wir das Vollständiger Regressionstest , und wir werden so weitermachen.
- Aber für die letzten zehn Zyklen der Veröffentlichung werden wir nur Auftritte durchführen Vollständiger Regressionstest .
Wenn wir also dem oben genannten Ansatz folgen, können wir mehr Fehler bekommen.
Der Nachteil der wiederholten manuellen Durchführung von Regressionstests:
- Die Produktivität wird sinken.
- Es ist eine schwierige Aufgabe.
- Es gibt keine Konsistenz bei der Testausführung.
- Und auch die Testdurchführungszeit wird erhöht.
Daher werden wir uns für die Automatisierung entscheiden, um diese Probleme zu lösen. Wenn wir die n-Nummer des Regressionstestzyklus haben, werden wir uns für die entscheiden Automatisierungs-Regressionstestprozess .
Automatisierter Regressionstestprozess
Im Allgemeinen entscheiden wir uns für die Automatisierung, wenn es mehrere Releases oder mehrere Regressionszyklen gibt oder es sich wiederholende Aufgaben gibt.
Der automatisierte Regressionstestprozess kann in den folgenden Schritten durchgeführt werden:
Anmerkung 1:
Der Prozess des Testens der Anwendung mithilfe einiger Tools wird als Automatisierungstest bezeichnet.
Nehmen wir an, wir nehmen ein Beispiel von a Login-Modul , wie wir dann den Regressionstest durchführen können.
Finde mein iPhone von Android
Dabei kann die Anmeldung auf zwei Arten erfolgen, nämlich wie folgt:
Manuell: Dabei führen wir die Regression nur einmal und zweimal durch.
Automatisierung: Dabei werden wir die Automatisierung mehrmals durchführen, da wir die Testskripte schreiben und die Ausführung durchführen müssen.
Hinweis 2: In Echtzeit, wenn wir auf einige Probleme gestoßen sind, wie zum Beispiel:
Probleme | Behandeln Sie |
---|---|
Neue Eigenschaften | Manueller Testingenieur |
Regressive Testfunktionen | Automatisierungstestingenieur |
Verbleibend (110 Feature + Release#1) | Manueller Testingenieur |
Schritt 1
Wenn die neue Version startet, entscheiden wir uns nicht für die Automatisierung, da es kein Konzept für Regressionstests und Regressionstestfälle gibt, wie wir dies im obigen Prozess verstanden haben.
Schritt 2
Wenn die neue Version und die Erweiterung beginnen, haben wir zwei Teams, nämlich das manuelle Team und das Automatisierungsteam.
Schritt 3
Das manuelle Team wird die Anforderungen durchgehen, auch den Aufprallbereich identifizieren und übergeben Anforderungstestsuite an das Automatisierungsteam.
Schritt 4
Jetzt beginnt das manuelle Team mit der Arbeit an den neuen Funktionen, und das Automatisierungsteam beginnt mit der Entwicklung des Testskripts und beginnt auch mit der Automatisierung des Testfalls, was bedeutet, dass die Regressionstestfälle in das Testskript umgewandelt werden.
Schritt 5
Bevor sie (das Automatisierungsteam) mit der Automatisierung des Testfalls beginnen, analysieren sie auch, welche Fälle automatisiert werden können und welche nicht.
Schritt 6
Basierend auf der Analyse starten sie die Automatisierung, d. h. die Konvertierung aller Regressionstestfälle in das Testskript.
Schritt7
Während dieses Prozesses werden sie die Hilfe in Anspruch nehmen Regressionsfälle weil sie nicht so gut über Produktkenntnisse verfügen Werkzeug und das Anwendung .
Schritt 8
Sobald das Testskript fertig ist, beginnen sie mit der Ausführung dieser Skripte in der neuen Anwendung [alte Funktion]. Da das Testskript mit Hilfe der Regressionsfunktion oder der alten Funktion geschrieben wird.
Schritt 9
Sobald die Ausführung abgeschlossen ist, erhalten wir einen anderen Status wie Bestanden/nicht bestanden .
Schritt 10
Wenn der Status „fehlgeschlagen“ ist, was bedeutet, dass er manuell erneut bestätigt werden muss, und wenn der Fehler vorhanden ist, wird er dem betroffenen Entwickler gemeldet. Wenn der Entwickler diesen Fehler behebt, muss der Fehler zusammen mit dem Auswirkungsbereich vom manuellen Testingenieur erneut getestet werden, und auch das Skript muss vom Automatisierungstestingenieur erneut ausgeführt werden.
Schritt 11
Dieser Prozess wird fortgesetzt, bis alle neuen Funktionen und die Regressionsfunktion übergeben wurden.
Vorteile der Durchführung von Regressionstests durch automatisierte Tests:
- Das Testskript kann über mehrere Releases hinweg wiederverwendet werden.
- Obwohl die Anzahl der Regressionstestfälle von Release zu Release zunimmt, müssen wir die Automatisierungsressourcen nicht erhöhen, da einige Regressionstestfälle bereits aus der vorherigen Version automatisiert wurden.
- es ist ein zeitsparender Prozess weil die Ausführung immer schneller ist als die manuelle Methode.
Wie wählt man Testfälle für Regressionstests aus?
Es wurde bei einer Industrieinspektion gefunden. Die mehreren vom Kunden gemeldeten Mängel waren auf kurzfristige Fehlerbehebungen zurückzuführen. Diese Nebenwirkungen zu erzeugen und daher den Testfall für Regressionstests auszuwählen, ist eine Kunst und keine leichte Aufgabe.
Der Regressionstest kann durchgeführt werden durch:
- Ein Testfall, der häufig Fehler aufweist
- Funktionalitäten, die für Benutzer besser sichtbar sind.
- Testfälle überprüfen die Kernfunktionen des Produkts.
- Alle Integrationstestfälle
- Allesamt komplexe Testfälle
- Grenzwerttestfälle
- Eine Auswahl erfolgreicher Testfälle
- Scheitern von Testfällen
Regressionstest-Tools
Wenn sich die Software häufig ändert, steigen auch die Kosten für Regressionstests. In diesen Fällen erhöht die manuelle Ausführung von Testfällen sowohl die Testausführungszeit als auch die Kosten. In diesem Fall sind Automatisierungstests die beste Wahl. Die Dauer der Automatisierung hängt von der Anzahl der Testfälle ab, die für aufeinanderfolgende Regressionszyklen wiederverwendbar bleiben.
Im Folgenden sind die wesentlichen Tools aufgeführt, die für Regressionstests verwendet werden:
Selen
Selenium ist ein Open-Source-Tool. Dieses Tool wird zum automatisierten Testen einer Webanwendung verwendet. Für browserbasierte Regressionstests wird Selen verwendet. Selen wird für den Regressionstest auf UI-Ebene für webbasierte Anwendungen verwendet.
Ranorex Studio
All-in-One-Regressionstestautomatisierung für Desktop-, Web- und mobile Apps mit integriertem Selenium Web Driver. Ranorex Studio enthält die vollständige IDE sowie Tools für die codelose Automatisierung.
Quick Test Professional (QTP)
QTP ist ein automatisiertes Testtool für Regressions- und Funktionstests. Es handelt sich um ein datengesteuertes, schlüsselwortbasiertes Tool. Zur Automatisierung wurde die Sprache VBScript verwendet. Wenn wir das QTP-Tool öffnen, sehen wir die drei Schaltflächen Aufnehmen, abspielen und stoppen . Diese Schaltflächen helfen dabei, jeden Klick und jede Aktion aufzuzeichnen, die auf dem Computersystem ausgeführt wird. Es zeichnet die Aktionen auf und spielt sie ab.
Rational Functional Tester (RTF)
Rational Functional Tester ist ein Java-Tool zur Automatisierung der Testfälle von Softwareanwendungen. RTF wird zur Automatisierung von Regressionstestfällen verwendet und lässt sich auch in den rationalen Funktionstester integrieren.
Weitere Informationen zu Regressions- und Automatisierungstesttools finden Sie unter dem folgenden Link:
https://www.javatpoint.com/automation-testing-tool
Regressionstests und Konfigurationsmanagement
Das Konfigurationsmanagement im Regressionstest wird in agilen Umgebungen, in denen ein Code kontinuierlich geändert wird, unerlässlich. Um einen gültigen Regressionstest sicherzustellen, müssen wir die folgenden Schritte ausführen:
- Während der Regressionstestphase sind keine Änderungen am Code zulässig.
- Ein Regressionstestfall muss von Entwickleränderungen unberührt bleiben.
- Die für Regressionstests verwendete Datenbank muss isoliert sein. Änderungen sind in der Datenbank nicht zulässig.
Unterschiede zwischen erneutem Testen und Regressionstests
Erneutes Testen bedeutet, die Funktionalität oder den Fehler erneut zu testen, um sicherzustellen, dass der Code behoben ist. Wenn nicht festgelegt, müssen Mängel nicht erneut geöffnet werden. Wenn der Fehler behoben wurde, wurde der Fehler behoben.
Beim erneuten Testen handelt es sich um eine Testart, die durchgeführt wird, um zu überprüfen, ob die Testfälle, die bei der endgültigen Ausführung nicht erfolgreich waren, nach der Behebung der Fehler erfolgreich bestanden werden.
Regressionstests bedeutet, die Softwareanwendung zu testen, wenn sie einer Codeänderung unterliegt, um sicherzustellen, dass der neue Code keine Auswirkungen auf andere Teile der Software hat.
Regressionstests sind eine Art von Tests, die durchgeführt werden, um zu überprüfen, ob ein Code die vorhandene Funktionalität der Anwendung nicht verändert hat.
Die Unterschiede zwischen dem erneuten Testen und dem Regressionstest sind wie folgt:
Erneuter Test | Regressionstests |
---|---|
Es werden erneute Tests durchgeführt, um sicherzustellen, dass die Testfälle, die bei der endgültigen Ausführung fehlgeschlagen sind, bestanden werden, nachdem die Fehler behoben wurden. | Regressionstests werden durchgeführt, um zu bestätigen, ob die Codeänderung keine Auswirkungen auf die vorhandenen Funktionen hat. |
Das erneute Testen funktioniert bei Fehlerbehebungen. | Der Zweck von Regressionstests besteht darin, sicherzustellen, dass sich die Codeänderungen nicht negativ auf die vorhandene Funktionalität auswirken. |
Die Fehlerüberprüfung ist Teil der Nachprüfung. | Regressionstests umfassen keine Fehlerüberprüfung |
Die Priorität des erneuten Testens ist höher als die des Regressionstests und wird daher vor dem Regressionstest durchgeführt. | Je nach Projekttyp und Ressourcenverfügbarkeit können Regressionstests parallel zu Retests durchgeführt werden. |
Ein erneuter Test ist ein geplanter Test. | Regressionstests sind generische Tests. |
Wir können die Testfälle für erneute Tests nicht automatisieren. | Wir können Regressionstests automatisieren. Manuelle Tests können teuer und zeitaufwändig sein. |
Eine erneute Prüfung erfolgt für fehlgeschlagene Testfälle. | Regressionstests dienen für bestandene Testfälle. |
Durch erneute Tests stellen Sie sicher, dass der ursprüngliche Fehler behoben ist. | Regressionstests prüfen auf unerwartete Nebenwirkungen. |
Beim erneuten Testen werden Fehler mit denselben Daten und derselben Umgebung mit unterschiedlichen Eingaben in einem neuen Build ausgeführt. | Von einem Regressionstest spricht man, wenn in einem bestehenden Projekt eine Änderung vorgenommen wird oder Änderungen obligatorisch werden. |
Eine erneute Prüfung ist vor Beginn der Prüfung nicht möglich. | Durch Regressionstests können Testfälle aus der Funktionsspezifikation, Benutzer-Tutorials und -Handbüchern sowie Fehlerberichte in Bezug auf das korrigierte Problem abgerufen werden. |
Vorteile von Regressionstests
Vorteile von Regressionstests sind:
- Regressionstests erhöhen die Qualität des Produkts.
- Es stellt sicher, dass etwaige Fehlerbehebungen oder Änderungen keine Auswirkungen auf die bestehende Funktionalität des Produkts haben.
- Für Regressionstests können Automatisierungstools verwendet werden.
- Dadurch wird sichergestellt, dass die behobenen Probleme nicht erneut auftreten.
Nachteile von Regressionstests
Regressionstests bieten mehrere Vorteile, es gibt jedoch auch Nachteile.
- Regressionstests sollten für kleine Änderungen im Code durchgeführt werden, da selbst eine geringfügige Änderung im Code zu Problemen bei der vorhandenen Funktionalität führen kann.
- Wenn im Projekt keine Automatisierung zum Testen verwendet wird, ist es eine zeitaufwändige und mühsame Aufgabe, den Test immer wieder durchzuführen.
Abschluss
Regressionstests sind einer der wesentlichen Aspekte, da sie dazu beitragen, ein Qualitätsprodukt zu liefern, das Unternehmen Zeit und Geld spart. Es trägt zur Bereitstellung eines Qualitätsprodukts bei, indem sichergestellt wird, dass Änderungen am Code keine Auswirkungen auf die vorhandene Funktionalität haben.
Zur Automatisierung der Regressionstestfälle stehen mehrere Automatisierungstools zur Verfügung. Ein Tool sollte in der Lage sein, das zu aktualisieren Testsuite da der Regressionstestanzug häufig aktualisiert werden muss.