Testlayout? Einfach

Dieser Artikel wurde von Anna anna-che und Ksenia KseMish erstellt .

Einer der Gründe, warum wir aktiv mit dem Testen von Layouts begonnen haben, war wie üblich ein Rechen. Wir sind auf einen Fehler gestoßen, der nach dem nächsten Update von Chrome auftrat. Es stellte sich heraus, dass Benutzer innerhalb von 3 Stunden kein Geld vom Konto über das persönliche Konto unserer Internetbank überweisen konnten. Und das alles aufgrund der Tatsache, dass in der neuen Version des Browsers die Form der Überweisung von Geld von einem Konto auf ein anderes das Fenster verlassen hat.

Ähnliche Fehler sind harmlos. Zum Beispiel stieß auch eine bekannte Bekleidungsmarke auf diesen Rechen. Aufgrund unzureichender Layout-Tests sahen Benutzer der Website dieser Marke anstelle der Schaltfläche "Weitere Informationen" lange Zeit "Learn the pain ...".


Die Inschrift auf dem Button ist natürlich nah an der Wahrheit, die Preise dort sind wirklich schmerzhaft, aber dies ist eindeutig nicht das, was die Macher der Site beabsichtigt haben. Im Allgemeinen müssen solche Momente überwacht und korrigiert werden, unabhängig davon, was sie verursachen - eine Unannehmlichkeit oder ein Lächeln.

Im Bewusstsein dieser Probleme haben wir die Praxis der obligatorischen Designprüfung durch unsere Produktdesigner angewendet, aber sie war nicht vorhanden. Es stellte sich heraus, dass nicht alle Teams einen engagierten Designer haben oder dass sie nicht genug Zeit haben, oder, noch schlimmer, dass die Vorderseite und der Designer nicht zu einem gemeinsamen Ansatz für das Layout einer Seite, eines Formulars oder eines Elements gelangen können.

Ohne nachzudenken, machten wir uns auf die Suche nach Optionen, wie wir sowohl die Anzahl der Layoutfehler als auch die Front VS Designer-Abstandshalter minimieren können. Nachdem wir die möglichen Praktiken und Werkzeuge zur Automatisierung von Testlayouts und zum Sammeln von Kegeln untersucht haben, haben wir den folgenden Ansatz implementiert.

Kurz über uns:
Jetzt entwickeln wir ein einziges Produkt, über das mehr als 20 Scrum-Teams arbeiten, von denen jedes für eine bestimmte Funktionalität verantwortlich ist, während wir versuchen, einen einzigen Stil und ein einheitliches Design des Produkts selbst beizubehalten - visuelle Präsentation, Layout der Hauptelemente usw.

In Bezug auf die Verteilung der Benutzer nach Browsern verwenden unsere Benutzer heute (Werte sind gerundet):

• 60% Chrom
• 30% - Firefox,
• 10% - andere Browser.

Wir testen die Funktionalität mit unserem Akita BDD Framework (Java + Cucumber + Selenide), wir haben hier darüber geschrieben .

Zunächst wollten wir das Problem mit den Vereinbarungen zwischen Front und Designer lösen. In der Anfangsphase der Erstellung eines Funktionsmodells beschreiben die Front und der Designer gemeinsam den „Vertrag“. In diesem Vertrag beschreiben sie alle Vorkehrungen für die Anordnung von Elementen, ihre Stile, Abstände usw. Aus diesem Grund müssen die Jungs beim Erkennen von Nichtübereinstimmungen des Layouts mit dem Seitenlayout lange nicht herausfinden, wer Recht hat und wer schuld ist.

Sie beschreiben ihre Arrangements in einer Galen-Spec-Datei.

Was ist Galen-Spec?

Um Layouttests zu automatisieren und damit die Anzahl der Fehler zu minimieren, haben wir uns für die Implementierung des Galen Framework-Tools entschieden. Es basiert nur auf einer .spec-Datei (Spezifikation oder, wie wir es nannten, "Vertrag"). Und es lässt sich leicht in Selentests integrieren.

Nachdem der Designer und die Front den „Vertrag“ erstellt haben, erstellt der Tester eine darauf basierende .spec-Datei gemäß den Anforderungen von Galen. Das Framework verwendet eine eigene Sprache, um Verifizierungsspezifikationen zu schreiben.

Woraus besteht eine .spec-Datei?

Logischerweise kann es in zwei Teile unterteilt werden:

1. Objektdefinitionen

Hier müssen wir angeben, welche Objekte sich auf unserer Seite befinden - Kopf-, Fuß-, Menü-, Inhalts- usw. Im Allgemeinen listen wir die Hauptelemente auf, die wir überprüfen, geben ihnen Namen und definieren Locators.


@objects - Elemente auf der Seite (Sie können CSS, XPATH, ID verwenden)

2. Wenn Locators definiert sind, müssen die Stile und Spezifikationen bestimmter Objekte definiert werden. Dazu verwenden wir den Teil der Objektspezifikationsspezifikation , in dem wir beispielsweise ausführlich beschreiben, dass sich unser Textblock (Beschreibungstext) innerhalb des Beschreibungsformulars unterhalb der Kopfzeile befindet und bestimmten Text enthält.


Hauptabschnitt - Für jedes beschriebene Element beschreibt @objects die Überprüfungsparameter.

* Die Galen-Spezifikationssprache reagiert empfindlich auf Einrückungen im Hauptabschnitt. Achten Sie daher besonders darauf und beachten Sie die Registerkarten :)

Der zwischen Front und Designer geschlossene und in die Galen-Sprache übertragene „Vertrag“ ermöglicht es uns daher, den Standort und den internen Inhalt der Elemente sowie die Anpassungsfähigkeit und browserübergreifende Kompatibilität automatisch zu überprüfen.

Beispiel für einen Schnellstart

1. Wir beschreiben die Elemente einer bestimmten Seite und überprüfen die .spec-Dateien mit der Sprache Galen Spec und fügen die Spezifikationen in das Paket ein.
2. Wir fügen die Referenz-Screenshots dem Specs / Images-Paket hinzu
3. Wir arbeiten an BDD, daher könnte das Skript in der .feature-Datei ungefähr so ​​aussehen:
   
   
   
4. Führen Sie das Testskript über den üblichen Cucumber Runner aus.

In diesem Szenario überprüfen wir die GitHub-Homepage. Im letzten Schritt haben wir die Layoutüberprüfung hinzugefügt. Ähnliche Tests können vorhandene Funktionstests ergänzen oder separat ausführen. Wenn im Layout Abweichungen festgestellt werden, erhalten wir ein Bild mit dem erwarteten Ergebnis und dem Ergebnis sowie dem Unterschied darin. Diese ganze Sache ist dem Cuckumber-Bericht beigefügt.

Der Unterschied in den Berichten ist wie folgt:


error = Error {[Element sieht nicht aus wie "./akita-testing-template/src/test/resources/specs/images/registration-form.png". Es gibt 10,47% nicht übereinstimmende Pixel, aber maximal 10%]

Hier sehen wir, dass die Prüfung fehlgeschlagen ist, die Bilder sich um mehr als 10% unterscheiden und alle diese Farbunterschiede, mit Ausnahme der schwarzen Füllung, der Unterschied zwischen den Elementen ist.

Wenn die Elemente vollständig identisch sind, wird der Unterschied in Schwarz angezeigt.

Die häufigste Frage ist, wo kann ich einen Referenz-Screenshot erhalten?

Antwort: Wir übernehmen den Standard entweder vom Designer oder führen Tests in der Prodov-Umgebung durch, die wir als Standard betrachten. Von dort erhalten wir Bilder unserer Blöcke, die wir vergleichen und in den Bilderordner legen, von wo aus die Spezifikationen Links zu ihnen ziehen.

Was haben wir mit diesem Ansatz erreicht?

• Es gelang, die Anzahl der Rauchtests und ihre Zeit um etwa 20% zu reduzieren, da die Überprüfung einiger Formen und ähnlicher Elemente in einem Test zusammengefasst wurde, der ihre visuelle Komponente überprüft und sofort Unstimmigkeiten aufdeckt
• Jetzt können wir sicher sein, dass unsere Anwendungen in den ausgewählten Browsern korrekt angezeigt werden
• wissen, dass Anpassungsfähigkeit in Ordnung und nicht getrennt ist
• kam zu einer automatischen Entwurfsprüfung.

Die Dokumentation zum Kompilieren von Galen-Spec-Dateien finden Sie hier - Galen-Spec-Language-Guide .

Wir haben im letzten Selenium Camp über die technischen Aspekte der Arbeit mit dem Galen Framework, seine Fähigkeiten und grundlegenden Überprüfungen gesprochen und werden auf dem Blog schreiben.

Die Möglichkeit, Galen-Spezifikationen und neue Schritte zur Überprüfung des Layouts zu verwenden, das wir in unsere Akita-Bibliothek aufgenommen haben , wo es eine Vorlage für einen schnellen Start gibt , und wir führen auch einen Telegramm-Chat durch, in dem Sie Fragen stellen können, die Sie interessieren.

Und wir werden antworten.