Hallo liebe Leser. Heute möchten wir mit dem Start des Kurses "Python QA Engineer" zusammenfallen . In Erwartung möglicher Fragen warnen wir, dass der Artikel kein Wort über Python erwähnt, aber wir finden dieses Material dennoch nützlich für Tester und haben uns daher entschlossen, es mit Ihnen zu teilen.
Das Testen jedes kleinsten Details des Codes ist nicht möglich. Daher sollten Regressionstests eine umfassende Überprüfung durchführen und sich auf einen bestimmten Bereich in seiner Gesamtheit konzentrieren. Das Hauptziel besteht darin, sicherzustellen, dass kein einziger Regressionsfehler einen kritischen Geschäftsprozess beeinträchtigt. Es ist diese Anstrengung, die es ermöglicht, von der Automatisierung zu profitieren. Ein automatisierter Testansatz zur Reduzierung von Regressionsfehlern trägt wesentlich zum Aufbau guter Kundenbeziehungen und zur Steigerung des Markenwerts bei.
Mein Team ist für das Testen einer Buchhaltungsanwendung verantwortlich, die ausgefeilte Berechnungen verwendet und Bucheinträge im Buchhaltungssystem aufzeichnet. All dies ist ein Workflow, und das monatliche Schließen von Büchern ist das Wichtigste.
Mit jeder Freigabe treten einige Änderungen in den Berechnungen auf, z. B. für das Konto kann es erforderlich sein, die Belastung oder Gutschrift zu erhöhen, oder der vorhandene Wert kann zwischen den beiden Konten aufgeteilt werden. Solche Änderungen in einer komplexen Anwendung mit vielen internen und externen Abhängigkeiten führen häufig zu unvorhersehbarem Verhalten, einschließlich Regressionsfehlern, an unerwarteten und scheinbar nicht zusammenhängenden Stellen.
Lassen Sie uns einen Regressionsfehler behandeln, der manchmal als kritischer Vorfall oder Produktionsproblem bezeichnet wird. Nachdem Sie mehrere Jahre in der Softwareindustrie gearbeitet haben, stellen Sie fest, dass der Regressionsfehler, der in die Produktion gelangt ist, viel wichtiger ist als die falsch funktionierende neue Funktion. Tatsache ist, dass die neue Funktion immer noch ausgeblendet ist. Wenn sie ausfällt, sind die Auswirkungen auf die Geschäftskomponente minimal, während sich der Benutzer bei einem Regressionsfehler auf die Arbeitsfunktion verlässt und höchstwahrscheinlich keine Sicherungsversion des Arbeitssystems hat.
Regressionsfehler werden durch Änderungen verursacht, die vom Projektmanager oder Produktbesitzer bei Abnahmetests nicht berücksichtigt wurden. Architekt, Entwickler während der Codeüberprüfung in der Entwurfs- oder Implementierungsphase; oder von einem QS-Analysten und Tester in Testfällen. Alle Sicherheitsnetzwerke haben einen Fehler übersehen und der Benutzer ist darauf gestoßen. Wenn ein Fehler in einer kürzlich durchgeführten Aktualisierung in einer der obigen Stufen festgestellt wurde, d.h. Teams, Interessenten oder andere Links, die in Ihrer Organisation vorhanden sind, wurden vor der Veröffentlichung überprüft oder zumindest auf ihre Kritikalität hin bewertet.
Regressionsfehler verursachen mehrere Kosten: dringende Korrekturen, Strafen für mögliche Verstöße gegen das Service Level Agreement und vor allem das Vertrauen Ihrer Benutzer in Ihr Produkt. Sie können entscheiden, dass eine neue Version etwas kaputt macht, das bereits funktioniert.
Für mein Team wurde es wichtig, absolut alles zu überprüfen.
Es ist jedoch bekannt, dass dies nicht möglich oder zumindest zu teuer und zeitaufwändig ist. Daher konzentrierte sich „Alles testen“ auf die folgenden zwei Dinge: kritische Geschäftsprozesse und die Überzeugung, dass das Verhalten in den wichtigsten kritischen Geschäftsprozessen vor der Änderung das gleiche sein wird wie in der neuesten Version. Im Allgemeinen wollten wir sicherstellen, dass in der neuesten Version kein Regressionsfehler im kritischen Geschäftsprozess auftritt.
Wir haben unsere typischen Ansätze für automatisierte Tests bewertet, um die Berechnungen zu überprüfen und um sicherzustellen, dass die gesamte Logik im Code zum Testen der Automatisierung beschrieben ist. Dieser Ansatz warf eine klassische Frage auf: "Wer testet den Testercode?" Wenn der Testfall nicht erfolgreich war, bestand die gleiche Wahrscheinlichkeit, dass das Problem im Testercode lag. Darüber hinaus muss bei jeder Änderung in der Anwendung auch der Testcode aktualisiert werden, und solche Änderungen sind häufig aufgetreten.
Dank automatisierter Tests haben wir außerdem sichergestellt, dass wir einen festen Satz von Eingaben und einen bekannten Satz von Ausgängen haben. Aufgrund der Komplexität der Anwendung war es unmöglich, alle möglichen Sätze von Eingabedaten gleichzeitig einzureichen. Für das Ende des Monats, des Quartals und des Jahres wurden auch verschiedene Datensätze benötigt. Der Zeitplan war ein ernstes Problem, da das Generieren eines großen Satzes von Eingabedaten und entsprechenden Skripten viel Zeit in Anspruch nimmt.
Es gab noch eine andere Variable: Benutzerdaten. Wir hatten ein besonderes Privileg: Wir erhielten jeden Monat Sicherungskopien der Benutzerdaten. Die Qualität des Tests hängt direkt von den zum Testen verwendeten Daten ab. Die Daten aus der Produktion sind immer besser als die generierten Daten. Daher war unser Privileg ein großer Vorteil, den wir nicht missen wollten.
Identifizierung und Durchführung von Regressionstests
Unsere Idee war es, automatisierte Tests zu verwenden, die die minimal erforderliche Wartung erfordern und das Vertrauen der interessierten Parteien in die Qualität der Veröffentlichung stärken.
Wir brauchten also eine Teststrategie für kritische Geschäftsfälle, die das Fehlen von Regressionsfehlern garantiert und natürlich schnell in die Praxis umgesetzt werden kann.
Unser Vorbereitungsprozess sah folgendermaßen aus:
- Datenbanksicherung aus der Produktion, zweimal wiederhergestellt;
- Es sind zwei Testsysteme installiert, die parallel arbeiten:
- Eins mit einem Produktionscode;
- Eine andere mit der aktuellen Version der zu testenden Anwendung.
Dieser Ansatz bietet zwei identische Systeme mit Codeunterschieden in nur einer Version:
Es ist sehr wichtig, zwei Systeme zu haben, da es hilfreich ist zu verstehen, dass jedes Problem nur aufgrund der neuesten Codeänderungen auftritt.
Da die Tests getrennt sind, gehen wir vom Standardprozess „Ausführen einer Aktion und Erhalten einer Reaktion“ zu der Tatsache über, dass Aktionen von einem Punkt zum anderen ausgeführt werden, während der Workflow beibehalten wird. Anschließend werden die Fehlerberichte verglichen. Dies ist der Schlüssel zum Erkennen unerwarteter Fehler.
Wenn sich der Tester auf eine neue Funktion oder eine Änderung konzentriert, stellt sich heraus, dass der Test speziell darauf ausgerichtet ist, d. H. Die Relevanz einer bestimmten Änderung wird überprüft. Regressionstests unterscheiden sich darin, dass überprüft werden muss, ob sich nichts anderes geändert hat. Dieser Unterschied spiegelt sich in Automatisierungsszenarien wider. Dadurch sind bestimmte Funktionstestskripte für die Suche nach Regressionsfehlern ungeeignet. Daher ist hier ein anderer Ansatz erforderlich.
Wenn Sie beispielsweise mit einem Auftragsverwaltungssystem arbeiten, benötigen Sie ein Skript, um Bestellungen mit vielen Eingabedaten aufzugeben, um Bestellungen für zwei installierte Testsysteme aufzugeben (vorzugsweise parallel). Anschließend erhalten Sie einen Bericht über Bestellungen für den letzten Tag und vergleichen diese Wert. Anschließend werden alle Bestellungen bestätigt oder genehmigt (diese Aktion) und Berichte wie täglich bestätigte Bestellungen, Lagerbestellungen, Lagerberichte, Bestellungen von jedem Spediteur, Versandart, Zahlungsart usw. wird in zwei Systemen verglichen. Dies setzt sich während des gesamten Workflows fort. Sie können Aktionen wie das Aufgeben und Bestätigen von Bestellungen kombinieren und dann Berichte in separaten Phasen vergleichen.
Ein weiteres Beispiel ist das Hotelmanagementsystem, bei dem einzelne Aktionen als kritische Geschäftsprozesse definiert werden, z. B. Einchecken, Abrechnung in einem Restaurant und Erhalt von Inventar. Allen diesen Prozessen werden eigene Aktionen und Berichte zugewiesen. Der Unterschied zwischen diesem System und dem vorherigen Beispiel besteht darin, dass die Testsuiten parallel ausgeführt werden können und der Schritt nicht ausgeführt werden muss, bevor der nächste gestartet wird.
Ein Vergleich der beiden Berichte ist ein Moment der Wahrheit und sollte in dem Sinne einwandfrei sein, dass keine der interessierten Parteien Zweifel an ihrer Richtigkeit haben sollte. Der Unterschied in den Berichten ist der wahre Unterschied.
Für diesen Vorgang verwenden wir die Webdienstschnittstelle. Alle Berichte werden parallel auf zwei Systemen gesendet. Dadurch wird die empfangene Antwort im JSON-Format verglichen.
Der Vergleich findet an drei Fronten statt:
- Quelle (Produktion) minus Ziel (zu prüfende Anwendung);
- Ziel minus Quelle;
- Vergleich der Werte, um den Schnittpunkt zu erhalten.
Diese Methode funktioniert für XML, XLS, CSV mit fester Breite oder jedes andere Format. Wir müssen sicherstellen, dass keine unnötigen Datensätze vorhanden sind, keine Datensätze fehlen und alle Werte der Datensätze übereinstimmen.
Dies ist die Essenz des Ansatzes, über den wir sprechen. All dies sind Informationen, die in der Anwendung lesbar sind, die als Bericht ausgegeben wird oder in einigen Fällen als Schnittstelle zu anderen Anwendungen fungiert.
Der Erfolg dieses Ansatzes liegt in einem Vergleichstool oder Dienstprogramm, das Fälle im Zusammenhang mit Ihrer Anwendung verarbeitet. Sie können sich glücklich schätzen, wenn Sie etwas Passendes "out of the box" finden. Andernfalls ist es wichtig zu verstehen, dass sich eine Investition in ein solches Instrument lohnt, da es gute Ergebnisse bringt.
Nach all dem Gerede über Automatisierung müssen Sie eine Bemerkung einfügen. Da einige Unterschiede in den Berichten erwartet werden, da sie nach Bedarf vorhanden sein müssen, müssen alle Ergebnisse auch manuell analysiert werden. Es sollte eindeutig erfolgreiche Ergebnisse beim Bestehen der Testfälle geben, es müssen jedoch auch nicht erfolgreiche Ergebnisse analysiert und ihre Gültigkeit bestätigt werden. Da es sich um Regressionstestfehler handelt, sollten diese vor der Veröffentlichung behoben werden. Natürlich gibt es einige Ausnahmen, die entsprechend der Anwendung behandelt werden.
Programmeinstellung
Alle Anwendungen sind unterschiedlich, und die Installation und Konfiguration erfolgt ebenfalls auf unterschiedliche Weise. Um die Anwendung für den Test vorzubereiten, sind möglicherweise einige zusätzliche Schritte erforderlich. Sie müssen daher zum richtigen Zeitpunkt und am richtigen Ort für die Durchführung der Tests berücksichtigt werden. Hier sind einige typische Schritte:
Daten aus der Produktion „verwirren“, indem E-Mail-Kennungen oder andere vertrauliche Informationen gelöscht oder durch fiktive Daten ersetzt werden;
Holen Sie sich die Daten in der richtigen Form, um den Test auszuführen.
Passen Sie die Einstellungen für die QS-Umgebung an, indem Sie beispielsweise die Integrationsbeziehungen ändern.
Das einzige, woran Sie sich erinnern sollten, ist, dass die obigen Schritte für beide Installationen ausgeführt werden müssen. Denken Sie daran, dass die Einstellungen vor dem Starten der Testsuite identisch sein müssen.
Häufig können andere Aktionen als das Anfordern eines Berichts ein Objekt zurückgeben. Beispielsweise kann eine Aktion, z. B. das Erstellen oder Ändern einer Bestellung, ein neues Auftragsobjekt zurückgeben. In diesem Fall müssen Sie zwei Objekte vergleichen und dürfen nicht auf den Vergleich von Berichten warten. Dies kann helfen, den Fehler in den frühen Stadien an der Wurzel zu identifizieren.
Es wird außerdem empfohlen, den gesamten Satz in kleinere Sätze aufzuteilen, indem Sie beispielsweise Transaktionen und zugehörige Berichte zusammenfassen. Sets können parallel ausgeführt werden, um Laufzeit zu sparen. Für eine Anwendung mit einem typischen Workflow funktioniert dies jedoch nur, wenn Sie die Fälle vertikal und horizontal teilen können oder umgekehrt.
Variationen können mit Technologien beginnen - JSON, XML oder Skalierer (int / string / float) - und erweitert werden, bis die getestete Anwendung und Produktion mit unterschiedlichen Strukturen reagieren, aber dennoch der Architektur entsprechen. Beispielsweise kann die Produktionsversion die alte JAR-Datei verwenden, die in einem bestimmten Format ausgeführt wird. In der neuen Version wurde die JAR-Datei aktualisiert, und jetzt hat sich das Antwortformat geändert, sodass beim Vergleich Inkonsistenzen auftreten. Um sie richtig zu vergleichen, benötigen Sie ein temporäres Plug-In.
Es wird wahrscheinlich nur wenige solcher Situationen geben. In solchen Fällen ist es manchmal einfacher, das Design zu optimieren oder im Rahmen einer Problemumgehung zu betrachten.
Es gibt verschiedene Möglichkeiten, solche Vergleiche durchzuführen:
Ignorieren Sie einige Felder, z. B. Bezeichner und Datumsangaben.
Zahlenunterschiede unter 0,0001 ignorieren;
Groß- und Kleinschreibung ignorieren;
Strukturänderungen in zwei Antworten.
Verbesserung der Regressionstests
Regressionstests sollten ganzheitlich sein und sich auf einen ganzen Bereich konzentrieren. Dieses Gleichgewicht wird dazu beitragen, die Automatisierung zu nutzen. Ein automatisierter Testansatz wird dazu beitragen, die Anzahl der Regressionsfehler zu verringern und auf dem Weg zu guten Kundenbeziehungen und zur Steigerung des Markenwerts zu helfen.
In einem Rhythmus ständiger Vorwärtsbewegung möchte unser Team nun versuchen, die beiden identischen Systeminstallationen, die wir jetzt verwenden, aufzugeben und dieselbe Strategie für eine Installation zu implementieren. Wir wollen die Antworten vergangener Errungenschaften behalten und zum Vergleich heranziehen. Der Testansatz kann jederzeit verbessert werden. Wünschen Sie uns viel Glück!
Die Übersetzung wurde speziell für Studenten des Kurses "Python QA Engineer" erstellt .