Layout testen? Einfach


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

    Einer der Gründe, warum wir uns aktiv mit dem Testen von Layouts befasst haben, war wie immer ein Rechen. Im Großen und Ganzen sind wir auf einen Fehler gestoßen, der nach dem nächsten Chrome-Update auftrat. Es stellte sich heraus, dass Benutzer innerhalb von 3 Stunden kein Geld von dem 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 des Geldtransfers von einem Konto auf ein anderes das Fenster verlassen hat.

    Ähnliche Fehler sind harmlos. Zum Beispiel ist auch eine bekannte Bekleidungsmarke auf diesen Schwader gestoßen. Aufgrund unzureichender Layout-Tests sahen die Benutzer der Website dieser Marke lange Zeit "Learn the pain ...", anstatt auf die Schaltfläche "Learn more" zu klicken.


    Die Beschriftung auf dem Button ist natürlich der Wahrheit sehr ähnlich, die Preise dort sind wirklich schmerzhaft, aber das ist eindeutig nicht das, was die Macher der Seite beabsichtigt haben. Im Allgemeinen sollten solche Momente überwacht und korrigiert werden, unabhängig davon, was sie verursachen - Unannehmlichkeiten oder ein Lächeln.

    Im Bewusstsein dieser Probleme haben wir die Praxis der obligatorischen Designprüfung durch unsere Produktdesigner angewendet, aber es war nicht vorhanden. Es stellte sich heraus, dass nicht alle Teams über einen engagierten Designer verfügen oder dass sie nicht genügend Zeit haben. Schlimmer noch, Front und Designer können sich nicht auf eine gemeinsame Herangehensweise an das Layout einer Seite, eines Formulars oder eines Elements einigen.

    Ohne nachzudenken, machen wir uns auf die Suche nach Möglichkeiten, wie wir sowohl die Anzahl der Layoutfehler als auch die Front VS Designer-Abstände minimieren können. Nachdem wir die möglichen Vorgehensweisen 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, an dem mehr als 20 Scrum-Teams arbeiten, die jeweils für eine bestimmte Funktionalität verantwortlich sind, während wir versuchen, einen einzigen Stil und ein einziges Design des Produkts selbst beizubehalten - visuelle Darstellung, Anordnung der Hauptelemente usw.

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

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

    Wir testen die Funktionalität mit unserem Akita BDD-Framework (Java + Cucumber + Selenide), darüber haben wir hier geschrieben .
    Zunächst wollten wir das Problem mit den Vereinbarungen zwischen der Front und dem Designer lösen. In der Anfangsphase der Erstellung eines Modells der Funktionalität beschreiben Front und Designer gemeinsam den „Vertrag“. In diesem Vertrag beschreiben sie alle Vorkehrungen für die Anordnung der Elemente, ihre Stile, Distanz usw. Aus diesem Grund müssen die Jungs beim Erkennen von Unstimmigkeiten des Layouts mit dem Seitenlayout lange Zeit nicht herausfinden, wer Recht hat und wer schuld ist.

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


    Was ist Galen-Spec?


    Um das Testen des Layouts zu automatisieren und damit die Anzahl der Fehler zu minimieren, haben wir uns für das Tool Galen Framework entschieden. Es basiert lediglich auf einer .spec-Datei (Spezifikation oder, wie wir es nannten, „Vertrag“). Und es lässt sich problemlos in Selentests integrieren.

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

    Woraus besteht eine .spec-Datei?

    Logischerweise kann es in zwei Teile unterteilt werden:

    1. Objektdefinitionen

    Hier müssen wir festlegen, welche Objekte sich auf unserer Seite befinden - Kopfzeile, Fußzeile, Menü, Inhalt usw. Im Allgemeinen listen wir die Hauptelemente auf, die wir überprüfen werden, 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 Sie Stile und Spezifikationen für bestimmte Objekte definieren. Hierfür verwenden wir einen Teil der Objektspezifikation , in der wir beispielsweise ausführlich beschreiben, dass sich unser Textblock (Beschreibungstext) innerhalb des Beschreibungsformulars unterhalb der Überschrift befindet und bestimmten Text enthält.


    Hauptabschnitt - Für jedes in @Objects beschriebene Element werden die Überprüfungsparameter beschrieben.

    * die galenische spezifikationssprache ist empfindlich gegenüber einrückungen im hauptteil, achten sie also besonders auf einrückungen und beachten sie die tabs :)

    somit ermöglicht der zwischen der vorderseite und dem designer geschlossene und in die galenische sprache übertragene vertrag die automatische überprüfung der lage und des internen inhalts von elementen, sowie Anpassungsfähigkeit und Cross-Browser-Kompatibilität.

    Schnellstart-Beispiel



    1. Wir beschreiben die Elemente einer bestimmten Seite und checken die .spec-Dateien in der Sprache Galen Spec ein 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 mit dem üblichen Cucumber Runner aus.

    In diesem Szenario überprüfen wir die GitHub-Homepage. Im letzten Schritt haben wir das Korrekturlesen hinzugefügt. Ähnliche Tests können vorhandene Funktionstests ergänzen oder separat ausgeführt werden. Wenn im Layout Unstimmigkeiten festgestellt werden, erhalten Sie ein Bild mit dem erwarteten Ergebnis und dem Ergebnis sowie den Unterschieden darin. Das Ganze 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 sind 10% zulässig.]

    Hier sehen wir, dass die Überprü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.

    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 bekommen wir Bilder von unseren Blöcken, die wir vergleichen und in den Bilderordner legen, von wo aus die Spezifikationen Links zu ihnen ziehen.

    Was haben wir mit diesem Ansatz kommen


    • Es gelang, die Anzahl der Rauchtests und die Dauer ihres Durchgangs um etwa 20% zu reduzieren, da die Überprüfung einiger Formen und ähnlicher Elemente zu einem Test zusammenfiel, der ihre visuelle Komponente prüft und sofort Unstimmigkeiten aufdeckt
    • Jetzt können wir sicher sein, dass unsere Anwendungen in den ausgewählten Browsern korrekt angezeigt werden
    • wir wissen, dass anpassungsfähigkeit in ordnung ist, nicht getrennt
    • kam zu einer automatischen Designüberprü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 wir werden mehr auf dem Blog schreiben.

    Die Möglichkeit, galen-spec zu verwenden und die neuen Schritte, um das Layout zu überprüfen, das wir in unserer Akita-Bibliothek erstellt haben. Dort gibt es eine Vorlage für einen schnellen Start . Außerdem führen wir einen Telegramm-Chat durch, in dem Sie Fragen von Interesse stellen können.

    Und wir werden antworten.

    Jetzt auch beliebt: