Get best of the week

Automatisierungstests von schlüsselfertigen Webanwendungen ohne Registrierung und SMS

Es kommt häufig vor, dass eine Webanwendung aus einer großen Anzahl dynamisch umstrukturierter Formulare mit unterschiedlichem Text und Steuerelementen besteht. Das Testen einer solchen Anwendung wird zum Albtraum.

Sie müssen auf 100500 Seiten klicken und alle Funktionen überprüfen ... Und vor der nächsten Version überprüfen Sie dasselbe noch einmal ... Und noch einmal ... Und morgen noch einmal. Irgendwann dauert die Überprüfung länger als die Entwicklung neuer Funktionen. "Was ist mit e2e-Tests?" - du fragst. Aber zuerst müssen sie noch geschrieben werden. Und zweitens müssen Sie Testfälle schreiben, bevor Sie mit dem Schreiben beginnen. Viele Testfälle.

Wenn Ihre Stirn beim Lesen dieser Zeilen schweißgebadet ist, machen Sie sich keine Sorgen. In diesem Artikel werde ich Ihnen die Idee mitteilen, wie wir bei Tinkoff das Testen einer der Webanwendungen automatisiert haben, ohne einen einzigen Testfall und einen e2e-Test zu schreiben.




Testfälle automatisch schreiben


Es ist einfach so passiert, dass das Testen unserer Webanwendung hauptsächlich mit Schnittstellenprüfungen zusammenhängt. Sie müssen überprüfen, ob die Schaltfläche auf dem Bildschirm vorhanden ist, der gewünschte Titel und Text angezeigt werden. Wenn Sie einen ungültigen Wert in die Eingabe eingeben , wird eine Fehlermeldung angezeigt.

Dementsprechend müssen Sie beim Schreiben eines Testfalls alle Aktionen aufzeichnen:

  • "Drückte die Taste"
  • "Geben Sie den Wert von XXX ein"
  • "Wählen Sie den Wert JJJ in der Dropdown-Liste"

und prüft:

  • "Der Text erschien: XXX"
  • "Fehlermeldung angezeigt: JJJ"
  • "Die Überschrift erschien: ZZZ"

Nachdem wir alle Funktionen unserer Webanwendung analysiert hatten, identifizierten wir ungefähr 30 eindeutige Aktionen und Überprüfungen. Es wurde deutlich, dass dieser Prozess automatisiert werden kann. Dazu müssen Sie nur alle Aktionen des Testers auf der Seite und die Reaktion der Site auf diese Aktionen verfolgen.

Beginnen wir mit dem Abfangen von Ereignissen. Um die Interaktion mit Steuerelementen wie Schaltflächen, Optionsfeldern und Kontrollkästchen zu verfolgen, müssen Sie das Klickereignis abonnieren. Jedes Framework hat hierfür seine eigenen Methoden. Zum Beispiel fromEvent in Angular und document.addEventListener in JavaScript und React. Bei Eingabesteuerelementen wie Kalender oder Eingabe ändert sich nur die Art des Ereignisses, das Sie abonnieren möchten: Anstelle von Klicken wird Focusout angezeigt.

fromEvent(this.elementRef.nativeElement, 'click')
.subscribe(tagName => {
 	if (tagName === 'BUTTON') {
   		this.testCaseService.addAction(`   "${action.name}"`);
 	} else if (tagName === 'INPUT-CALENDAR') {
   		this.testCaseService
     			.addAction(`  "${action.name}" "${action.value}"`);
 	}
});

Und schließlich ist das Wichtigste die Überprüfung. Das Verhalten der Site als Reaktion auf die Aktionen des Testers.

Was prüft der Tester normalerweise? Zum Beispiel gab er einen ungültigen Wert in die Eingabe ein , die Site antwortete mit einer Fehlermeldung. Angenommen, wir haben auf eine Schaltfläche geklickt und als Antwort darauf wurde ein neuer Bildschirm angezeigt, der Titel geändert, neuer Text angezeigt und die Steuerelemente neu erstellt. Alle diese Änderungen beziehen sich auf die Änderung im DOM-Baum. Es gibt viele Möglichkeiten, sie zu verfolgen. Sie können beispielsweise MutationObserver in React und JavaScript oder ngAfterViewInit in Angular verwenden (indem Sie eine Direktive auf die Formularelemente setzen, die auf der Site von Interesse sind).

ngAfterViewInit() {
    const tagName = this.nativeElement.nodeName;
	const text = this.nativeElement.textContent;
    if (['SPAN', 'P'].includes(tagName)) {
 	 	 this.testCaseService.addContent(`** ** "${text}"\n`);
     } else if (tagName === 'H1') {
 	  	this.testCaseService.addContent(`** ** "${text}"\n`);
     } …	
}

Der Code hängt stark vom Layout ab. Werfen wir einen Blick auf das Markup. Diese Schaltflächen stammen aus dem Google Übersetzer.


<div class="tlid-input-button input-button header-button tlid-input-button-text text-icon" role="tab" tabindex="-1">
  	<div class="text"></div>
</div>
<div class="tlid-input-button input-button header-button tlid-input-button-docs documents-icon" role="tab" tabindex="-1">
 	 <div class="text"></div>
</div>

Trotz der Tatsache, dass Schaltflächen nicht als Schaltflächen- Tags dargestellt werden , können Sie im Markup alle Schaltflächen auf der Seite mithilfe der CSS-Klasse "Eingabetaste" auswählen und Schaltflächennamen aus der verschachtelten CSS-Klasse "Text" abrufen.

Die halbe Arbeit war erledigt, es bleibt nur, alles, was wir verfolgt haben, in einen Testfall zu schreiben.

Wir schließen das Abfangen aller Aktionen auf der Site für eine bestimmte Tastenkombination und nur auf der Testschaltung ein. Wir stoppen das Abfangen aller Ereignisse auf der Website durch eine bestimmte Tastenkombination. Auf diese Weise können Sie die automatische Aufzeichnung des Testfalls von überall aus starten und stoppen.

Automatisches Schreiben von e2e-Tests


Wenn Sie sich den automatisch generierten Testfall ansehen, handelt es sich im Wesentlichen um Benutzerskripte, die auf dasselbe Formular reduziert sind. Sie können also in e2e-Tests umgewandelt werden. Sie können sogar sofort e2e-Tests schreiben, nachdem Sie alle Aktionen und Überprüfungen abgefangen und die Testfälle umgangen haben.

Jetzt gibt es eine große Anzahl verschiedener Frameworks mit Essiggurken-Notation, die auf Verhaltensskripten basieren: SpecFlow, xBehave.net., Cucumber.js, CodeceptJS usw.

Um Funktionen aus dem Testfall zu erhalten, müssen Sie das Schlüsselwort When vor und vor den Aktionen hinzufügen alle Schecks dann und und.

Holen Sie sich den automatisch generierten e2e-Test:

Feature:   2-
  Background:
 	When  "" ""

  Scenario:
 	When    " - "
 	Then    "  "
 	And   " - "
 	When    "  " ""
 	When    "" "  "
 	When    ""

Um den Testlauf auszuführen, gibt es nur wenige generierte Funktionen. Sie müssen einen Handler für alle Aktionen und Überprüfungen schreiben.

Es gibt gute Nachrichten: Sie müssen nicht für jede Funktion einen Handler schreiben. Wie ich bereits sagte, haben wir trotz der großen Anzahl unterschiedlicher Formulare auf der Site nur 30 eindeutige Aktionen und Überprüfungen erhalten, was bedeutet, dass für alle e2e-Tests genau die gleiche Anzahl von Methoden im allgemeinen Prozessor vorhanden ist. Der Code unterscheidet sich geringfügig - abhängig vom gewählten Framework mit Essiggurken-Notation und Layout auf der Site. Das Schreiben des Handlers selbst nimmt jedoch nicht viel Zeit in Anspruch.

When('   {string}', async function (button: string) {
	const xpath = "//button";
	const btn = await getItemByText(xpath, button);
	await waitAndClick(btn);
});
When('  {string} {string}', async function (label: string, text: string) {
	const xpath = "//*[contains(text(),'" + label + "')]/ancestor::outline";
	await inputSendKeys(currentBrowser().element(by.xpath(xpath)), text);
});

Wenn Sie nun die nächste Aufgabe überprüfen, wird automatisch ein Testfall für den Tester geschrieben und der automatisch generierte e2e-Test ausgeführt.

Kurz gesagt, Sie müssen:

  1. Abonnieren Sie Ereignisse der Interaktion mit Steuerelementen und die Reaktion der Site auf diese Aktionen (indem Sie die Neuerstellung des DOM-Baums verfolgen).
  2. Konvertieren Sie Daten aus Absatz 1 in e2e-Tests.
  3. Schreiben Sie einen allgemeinen Handler zum Ausführen von e2e-Tests.

Dieser Ansatz hilft Ihnen, sich von der Routine zu lösen. Sie können das Schreiben von Testfällen und e2e-Tests für einfache Überprüfungen der Schnittstelle automatisieren. Wir sind noch weiter gegangen und überprüfen automatisch auch den Datensatz in der Datenbank und senden ihn an Dienste von Drittanbietern.

Ich habe auf der Heisenbug-2019-Konferenz in Moskau darüber gesprochen sowie über die Versionierung, den Technologie-Stack und sogar Probleme in der ersten Phase der Implementierung und deren Lösung .

In diesem Artikel habe ich versucht, die Hauptidee zu vermitteln, ohne auf Details einzugehen.

Fazit


Jetzt brauchen wir durchschnittlich 2 Minuten, um einen Testfall und einen e2e-Test zu schreiben - dies ist 60-mal schneller als die anfänglichen Berechnungen, als wir Testfälle und e2e-Tests manuell schreiben wollten.

Wir haben die Prozesse im Team nicht geändert. Es war nicht mehr erforderlich, die Testkapazität zum Schreiben von Testfällen zuzuweisen und an das Automatisierungsteam weiterzuleiten.

Wir sind völlig vom Begriff der Regression verschwunden. Wenn früher bei einem zweiwöchigen Sprint die Regression mehr als 3 Tage gedauert hat, braucht die Regression jetzt Zeit, um alle e2e-Tests durchzuführen, und dies sind nur 2 Stunden.

Beim manuellen Schreiben von e2e-Tests ist es sehr schwierig, parallel zum Testen zu arbeiten. Jetzt werden e2e-Tests während des Testens der Aufgabe automatisch geschrieben, und der Tester muss nicht zweimal dieselbe Funktionalität überprüfen.

Infolgedessen begann unser Team, ohne die Zusammensetzung zu ändern, viel effizienter zu arbeiten.

More articles:


All Articles