Geekly articles weekly

Erfahrung mit BDD


Vor ungefähr sieben Jahren hat Dan North in seinem Artikel die praktische Anwendung des BDD-Ansatzes beschrieben, mit dem Sie den Entwicklungsprozess durch den Aufbau interner Kommunikation verständlicher und überschaubarer gestalten können. Die Branche zeigt täglich zunehmendes Interesse an dieser Methodik, die auf die produktive Interaktion von Standardteams wie „Analytics-Development-Testing“ abzielt.


Derzeit entscheidet sich jedoch nur ein kleiner Teil der Unternehmen für BDD. Warum?


Also, lass es uns herausfinden. BDD (Behavior Driven Development) ist eine flexible Methode, die eng mit TDD (Test Driven Development - „Entwicklung durch Testen“) verbunden ist. Erfahrungsgemäß sehen selbst erfahrene Tester den Unterschied zwischen diesen Methoden oft nicht. In der Tat ist es auf den ersten Blick schwierig zu isolieren: Beide Ansätze beinhalten das Schreiben von Dokumentation und Tests vor Beginn der Entwicklungsphase. Der Unterschied besteht darin, dass Sie in BDD zur Beschreibung der Tests eine natürliche Sprache verwenden müssen, die für jeden Projektteilnehmer verständlich ist, um die Problemstellung, die Tests und die Dokumentation tatsächlich miteinander zu kombinieren. Mit anderen Worten, DSL (spezifische fachorientierte Sprache) wird definiert, und dann wird ein standardmäßiger begrenzter Satz von Phrasen erstellt, der das Verhalten der erforderlichen Elemente beschreibt. Anschließend wird mit ihrer Hilfe ein Szenario unter Verwendung der neuen Funktionalität entwickelt, das für alle klar ist.


Lassen Sie uns den Unterschied einmal sehen, und es wird offensichtlich:



Wir werden auf dieses Beispiel eingehen, aber lassen Sie uns zunächst die gesamte Vielfalt der Methoden betrachten, die derzeit nicht von Null relevant sind.


Vergleichen Sie verschiedene Methoden


Das folgende Diagramm zeigt einen Vergleich von drei Ansätzen: TDD, TLD (Test Last Development) und BDD:



  • Wenn wir nach der BDD-Methodik arbeiten, begleiten Autotest- und Entwurfsspezifikationen jede Phase des Softwareentwicklungszyklus, wodurch die konstante Relevanz von Autotests und Dokumentation sichergestellt wird.
  • Die TDD- und ATDD-Methoden (Acceptance Testing) werden in einem Diagramm in einem Block zusammengefasst, weil geschrieben in der Analysephase. Wie oben erwähnt, basiert TDD auf dem Schreiben von Tests vor der Entwicklung der Funktionalität. Der Entwickler muss Tests schreiben, um die Funktionalität für den Test schreiben zu können.
  • TLD (Test Last Development) umfasst das Testen nach der Implementierung der Funktionalität.
  • BDD ist universell und kann in jeder Entwicklungsphase aufgenommen werden.

Das zweite Diagramm zeigt die Beteiligung der Teilnehmer am Entwicklungsprozess beim Schreiben von Skripten.



  • In BDD kann jedes Mitglied des Teams jederzeit eine Verbindung zu den Tests herstellen, z. B. Analyst, Geschäftsbenutzer, Entwickler und Tester, da die Tests allen Teilnehmern des Prozesses klar sind.
  • BDD ist auch insofern nützlich, als Sie nicht viel Zeit damit verbringen müssen, verschiedene Arten von Dokumentation zu schreiben. Das klassische Entwicklungsschema benötigt mindestens Spezifikationen und Testskripte, die normalerweise von verschiedenen Personen geschrieben werden. In BDD ist eine Spezifikation ein Testfall, während es sich auch um einen Autotest handelt. Tester müssen keine separate Testdokumentation schreiben - der Analyst, der die Spezifikation aus Konstrukten in natürlicher Sprache geschrieben hat (die für jedes Teammitglied lesbar und verständlich ist), hat dies bereits für sie getan.

Zweifellos ist BDD ein gutes Instrument, um Produktqualität zu erreichen. Tests und Dokumentation werden schneller geschrieben. Für ein Unternehmen wird ein Projekt transparenter, dank Konstrukten in natürlicher Sprache, die für jede Person verständlich sind, die weit vom Programmieren entfernt ist.


Hier geht es um die Profis. Wie bereits erwähnt, implementieren trotz der Vielzahl von Vorteilen nur wenige diese Methodik.


BDD ist gut für alle, aber warum nicht?


Die Antwort ist einfach: Es ist lang und teuer. Die meisten IT-Unternehmen werden dieser Aussage zustimmen. Und zuerst waren wir keine Ausnahme. BDD ist unpraktisch, selbst wenn die Einbeziehung von Testspezialisten erforderlich ist, die sich bereits in der Phase der Ausarbeitung der Anforderungen befinden.


BDD stellt die klassische Entwicklungsrichtlinie (TLD) auf den Kopf. Es ist schlecht implementiert, weil es schwierig ist. Der Entwicklungszyklus verlängert sich.


BDD ist zweifellos ein Weg, um Qualität zu erreichen. Aber nicht jeder ist bereit, Zeit und Spezialisten für diese Qualität zu bezahlen.


Was kann ich jedoch tun, wenn ich BDD weiterhin implementieren möchte?


Sie können versuchen, vorgefertigte Frameworks zu verwenden. Zum Beispiel Gurke, Squish, Yulup.


Das Hauptproblem der BDD-Komplexität liegt nicht im Prozess, sondern in der Implementierung und den vorhandenen Tools. Nehmen Sie WEB als Beispiel für die Entwicklung eines Unternehmensinformationssystems. Bei einer Webimplementierung stoßen wir auf einen WebDriver, der derzeit der Standard für die Automatisierung von Anwendungen ist, die in einem Webbrowser ausgeführt werden. Er hat ziemlich viele Möglichkeiten. Um verschiedene Anpassungen von Seitenelementen zu berücksichtigen, müssen Sie Optionen für den Zugriff darauf finden. Und hier helfen verschiedene Bibliotheken (Selenide usw.), um die Entwicklung des Tests zu erleichtern, wodurch ein eigenes Ökosystem entsteht, das Sie kennen müssen. Um mit WebDriver arbeiten zu können, benötigen Sie einen Programmierer oder eine Tester-Automatisierung, weil Alles wird mit Code und gerissenen Designs implementiert.


Der Einstieg in das BDD-Framework ist schwierig und zeitaufwändig.


Unser Fokus liegt auf einem Instrument namens Gauge. Dies ist ein flexibles und leichtes Framework, das unter einer kostenlosen Lizenz vertrieben wird. Ehrlich gesagt haben wir die Alternativen nicht wirklich untersucht, weil Die Verwendung von Messgerät wurde von unseren Kunden aggressiv diktiert.


In Gauge werden Tests in Spezifikationsdateien (Dateien mit der Erweiterung .spec) geschrieben. Die Spezifikation enthält Testschritte in natürlicher Sprache. Diese Schritte sind in einer Programmiersprache implementiert (wir haben die Programmiersprache Java verwendet). Bei der Implementierung der Schritte ist es wichtig, die Namenskonvention sowohl in den Namen der Skriptdateien und der Implementierung als auch in den Namen der Implementierungsmethoden und der Schritte des Skripts einzuhalten. Sie müssen vollständig übereinstimmen. Eine zusätzliche Flexibilität dieses Tools besteht darin, dass Schritte Parameter haben können.


Mit Gauge konnten wir die Vorteile von BDD nutzen. Wir sind jedoch immer noch auf Probleme gestoßen, die die Komplexität der Implementierung betreffen: die Probleme der Tools und die Implementierung des Prozesses.


Es stellte sich heraus, dass sich die frühzeitige Einbeziehung von Testern negativ auf das Endergebnis auswirkt. Erhöhte Zeit für die Entwicklung von Tests. Die Verwendung eines Frameworks erfordert große Anstrengungen des Testers, der zweifellos über gute Programmierkenntnisse verfügen muss. Zunächst wurde mit dem Skript wie folgt gearbeitet: Der Analyst teilte dem Tester den Test mit, und der technische Redakteur schrieb ihn auf. Während sich der Tester mit der Software-Implementierung befasste, änderte sich die Bedeutung der getesteten Funktionalität. Dies wirkt sich auf die Trennung des Einstiegspunkts aus und sollte einer sein, da der Prozess geteilt wird und sich in einen „normalen“ Prozess verwandelt, von dem ich nur gehen wollte. Das heißt, Der Einstiegspunkt wurde geteilt, die Kommunikation verbreitet, der Tester ging direkt in die Durchführung des Tests ein, der technische Redakteur verstand es auf seine Weise, und der Analyst schrieb seine Docks um und änderte seine Meinung, der Entwickler ging in „seine Welt“.


Der Tester hat viel Zeit mit dem Code verbracht. Trotzdem musste derselbe Tester über die Suche nach Elementen auf der Seite nachdenken. Die Situation erinnerte an ein berühmtes Kinderspiel: „Verwöhntes Telefon“. Ein Zusammenbruch ist aufgetreten. Und wir haben uns entschieden: BDD funktioniert nur, wenn Analysten Tests schreiben können. Es ist notwendig, die Komplexität des Schreibens von Tests zu reduzieren, um sie zu vereinfachen. Dazu müssen Sie jedoch die Testschnittstellen erheblich vereinfachen. Testwerkzeuge, die Implementierung des Prozesses in Verbindung mit allen Ansätzen und Bibliotheken sollte einfacher sein.


Die Arbeit des Testers sah zunächst so aus:


  1. Gegebenenfalls Prüfung der Unterlagen;
  2. Erstellung einer Checkliste;
  3. Ad-hoc-Tests
  4. Erstellung eines Testplans;
  5. Verfeinerung des Weltbildes des Analytikers;
  6. Verfeinerung des Weltbildes durch den Entwickler;
  7. Wenn alles zusammengewachsen ist, schreiben Sie parallel zum Testen die Testdokumentation.
  8. Warten auf Fehlerbehebung, Testen von Fehlern;
  9. Beschreibung der Seiten, Steuerelemente, Suche nach Elementen auf der Seite mit dem Web-Treiber. Suchen Sie nach dem, was bereits im Testsystem implementiert wurde.
  10. Testlogik schreiben;
  11. Lassen Sie los
  12. Support Bug / Regress Bug;
  13. Spezifikationsaktualisierung;
  14. Fehler behoben
  15. Autotest-Aktualisierung, Aktualisierung einer großen Anzahl geänderter Steuerelemente;
  16. Lassen Sie los
  17. ...
    Kursiv gedruckte Elemente (1, 5, 6, 7, 9, 13, 15) führen zu Zeitkosten. Sie können und sollen optimiert werden.

Diese Liste wird im Entwicklungsprozessdiagramm kurz dargestellt:



Unser Unternehmen ist spezialisiert auf Projekte mit Web-Implementierung von Schnittstellen. Auf dieser Grundlage verwenden wir das Web-Treiber-Tool, um mit dem Webbrowser zu interagieren.


De facto ist der Selenium Web Driver der Standard und wird verwendet, um Webobjekte in jedem Framework zu beschreiben, einschließlich Gauge-, jUnit-, Masquerade-Bibliotheken und anderen. Er hat viel Flexibilität für verschiedene Aufgaben, was bei lokalen Problemen zu übermäßiger Mühsal führt. Wir müssen eine Lösung finden, um die Komplexität zu reduzieren.


Als Beispiel zeigen wir im Diagramm, wie der Selenium-Webtreiber, das Gauge-Framework, die Masquerade-Bibliothek und die Java-Programmiersprache zusammenhängen.



In diesem Schema können Sie anstelle des BDD-Frameworks jUnit, TestNG oder ein anderes verwenden. Jedes Bundle funktioniert je nach Bedarf. Selen und Masquerade bleiben erhalten, die Programmiersprache kann geändert werden.


Beschleunigung des Code-Schreibens - Masquerade verbinden


Unser Unternehmen entwickelt sich auf der CUBA-Plattform . Speziell für diese Plattform wurde ein Tool für Autotests entwickelt: Masquerade ist eine Bibliothek, die eine übersichtliche und bequeme API für die Arbeit mit Code bei der Implementierung von Tests mit WebDriver bietet. Diese Bibliothek funktioniert mit dem Selenium Web Driver, ist mit Selenid und allen Frameworks befreundet.


In CUBA-Projekten enthält jedes Element der Webseite eine Kuba-ID, die sich nicht ändert. CUBA verwendet einen Komponentenansatz und die Masquerade-Bibliothek vereinfacht die Interaktion mit Webseitenelementen. Die Bibliothek kann auf einfachere Weise Aktionen mit Webseitenelementen ausführen, die mit CUBA implementiert wurden. Daher müssen Sie bei der Suche nach Elementen auf der Seite nicht wie zuvor sperrige Konstruktionen mit XPath verwenden:


$(new By.ByXPath("//*/div/div[2]/div/div[2]/div/div/div[3]/div/div/div[3).click();

Oder prägnantere Konstruktionen in Java, die jedoch immer noch umständlich sind:


 private static void click(String cssClass, String caption) { $(By.cssSelector(cssClass) .$(byText(caption)) .closest(".v-button") .click(); }

Nach dem Verbinden der Masquerade-Bibliothek sieht die Beschreibung des eingebetteten Steuerelements einfach und leicht zugänglich aus. Sie müssen nicht einmal nach Steuerelementen auf der Seite suchen, weil er hat es schon im projekt. Hier ist ein Beispiel für eine Schaltflächenbeschreibung für das Autorisierungsformular in der Anwendung:



Im cuba-id=”loginButton” sehen wir ein deutlich erkennbares Element cuba-id=”loginButton”



Beschreiben wir die Schaltfläche mithilfe der Masquerade-Bibliothek:


 @Wire(path = {"WebHBoxLayout", "loginButton"}) private Button loginButton;

Eine einfache Testimplementierung im jUnit-Framework ist ein Autorisierungsblock, der vor jedem Test ausgeführt wird:


 @Before public void loginAdm() { Tests loginTest = _$(Tests.class); loginTest.login(); }

Und im Hauptteil der Anmeldemethode den folgenden Code:


 LoginWindow loginWindow = _$(LoginWindow.class); assertNotNull(loginWindow.getLoginField()); loginWindow.getLoginField() .shouldBe(EDITABLE) .shouldBe(ENABLED); loginWindow.loginField.setValue("admin"); loginWindow.passwordField.setValue("admin"); loginWindow.rememberMeCheckBox.setChecked(true); loginWindow.loginButton().click();

Das Wichtigste ist, wie wir die Seite beschreiben, wie wir auf Elemente verweisen. Beschreibung der LoginWindow-Seite:


 public class LoginWindow extends Composite<LoginWindow> { @Wire(path = {"loginField"} ) private TextField loginField; @Wire(path = {"passwordField"} ) private PasswordField passwordField; @Wire(path = {"rememberMeCheckBox"} ) private CheckBox rememberMeCheckBox; @Wire(path = {"loginFormLayout", "loginButton"} ) private Button loginButton; }

Das Finden von Gegenständen ist nur ein Teil der Masquerade-Bibliothek. Durch den Zugriff auf die Elemente einer Webseite können Sie verschiedene Aktionen mit diesen Elementen ausführen. Sie können beispielsweise ein Element aus der Dropdown-Liste auswählen:


 getMaxResultsLayout().openOptionsPopup().select("5000")

Oder sortieren Sie die Tabelle:


 Table tb1 = client.getPaymentsTable(); tb1.sort("column_year", Table.SortDirection.ASCENDING);

In den folgenden Screenshots finden Sie eine Liste einiger Tabellenaktionen:





Die Verwendung von Masquerade hat das Schreiben von Tests erheblich vereinfacht. Um nun einen Test für neue Funktionen zu schreiben, benötigen Sie:


  1. Die Verwendung von Masquerade zur Beschreibung einer Seite ist einfach und erfordert keine besonderen Programmierkenntnisse.
  2. Sammeln Sie in einer Klasse alle Seiten, die zur Überprüfung der Funktionalität verwendet werden.
  3. Sammeln Sie aus den vorgefertigten Konstruktionen der natürlichen Sprache ein Testskript (ersetzen Sie dort die Namen der erforderlichen Elemente), dh schreiben Sie eine Messgerätespezifikation.

Maskerade und Messgerät integrieren


Vor der Verwendung von BDD wurde der TLD-Ansatz verwendet, und für die Arbeit damit haben wir auch den Prozess des Schreibens von Testcode optimiert. Verwendete jUnit / TestNG + WebDriver + Selenide + Masquerade-Bundles.


Um nun mit Gauge arbeiten zu können, fügen wir das entsprechende Plug-In zu Intellij IDEA hinzu. Danach ist es möglich, einen neuen Testtyp zu erstellen - Spezifikation.


Jetzt erstellen wir die Spezifikation (Skript) und implementieren die Schritte mit den Funktionen von WebDriver, Masquerade und Java.



Wir klicken auf den Schritt des Skripts und gehen zur Implementierung:



In der Implementierung können Sie die vorhandene login () -Methode verwenden.


Wie sieht diese Perfektion aus?


Erinnern Sie sich an das Beispiel, das wir ganz am Anfang des Artikels untersucht haben:



"Navigation.openMenu(menu)” enthält die Implementierung des Öffnens eines Menüs mithilfe der Masquerade-Bibliothek.


Die Bibliothek wurde anschließend erweitert und es erschienen universelle Schritte, die für jede CUBA-Anwendung verwendet werden konnten. Mit diesen Schritten können Sie mit Programmelementen arbeiten: Schaltflächen, Felder, Tabellen. Diese universellen Schritte sind zu einer Reihe von Standardphrasen geworden, die wir in BDD zum Schreiben von Skripten verwenden.


Dank Masquerade + Gauge konnten wir die Komplexität der Testerstellung erheblich reduzieren. Jetzt können Tests von Personen geschrieben werden, die keine besonderen Programmierkenntnisse haben. Ein Test kann von einer Person geschrieben werden (zuvor wurde ein Skript von einer erfunden, aber von einer anderen implementiert, was zu Verwirrung führte). Damit haben wir unser Ziel erreicht - die Schnittstellen sind vereinfacht und es wird für Analysten nicht schwierig sein, Testskripte zu schreiben.


Prozessänderungen werden unten gezeigt:


Es war:

War


Es wurde:

Ist geworden


Im Vergleich dazu sind die Anforderungen, die Spezifikation und die Testdokumentation in einem Absatz zusammengefasst. Die Testdokumentation ist auch ein Autotest, mit Ausnahme der Implementierung bestimmter Testschritte.


Zusammenfassung


Im Moment entwickeln wir uns erfolgreich nach dem oben angegebenen Schema. Und wir haben es geschafft, das Hauptproblem von BDD zu beseitigen - eine ernsthafte Zunahme aufgrund der Komplexität der Implementierung, des Hinzufügens und Finalisierens des Toolkits. Die Qualität der Produktlieferung hat sich jedoch verbessert.


Der Zeitaufwand für die Pflege der Dokumentation wird proportional zur Anzahl der geänderten Spezifikationen reduziert, weil Eine Änderung der Spezifikation (Systemlogik) führt automatisch zu einer Änderung des Autotests in einer Iteration. Das heißt, Der Tester muss für ein Update nicht in das Dokumentationssystem (z. B. Confluence usw.) gehen, und dies gilt auch für andere Teammitglieder.


Die Zeit für die Implementierung und Unterstützung von Tests in Gegenwart einer Bibliothek, die die Arbeit mit Seitenobjekten vereinfacht, hat sich im Vergleich zur Arbeit mit dem üblichen sauberen Webtreiber und den Kosten für die Neuerstellung von XP-Links halbiert.


Bei der Entwicklung jeder Geschäftslösung und beim Qualitätsmanagement steigen die Kosten für die Beseitigung von Fehlern bei der Erfassung von Anforderungen und Analysen exponentiell . Dementsprechend reduziert die Wahrscheinlichkeit von Problemen im Zusammenhang mit der Änderung des Produkts gemäß den vorhandenen Artikeln und Zeitplänen in der iterativen Entwicklung mit der Früherkennung eines Problems, das eine gute Untersuchung der Anforderungen darstellt, die Entwicklungskosten je nach Projekt erheblich. Sie kann sowohl 0% als auch ~ 40% betragen. Diese Verbesserung wird durch die Einführung von BDD erreicht. Dies kann implementiert werden, ohne das Wort BDD zu nennen, ist jedoch in BDD vorhanden. Probleme umgehen zu können, ist ein wichtiger Bestandteil der Qualitätssicherung.


Abschließend möchte ich darauf hinweisen, dass dieses Entwicklungsschema auch in die kontinuierliche Integration und das in unserem Unternehmen entwickelte QA-Objektiv-Testmanagementsystem integriert ist. In QA Lens können Sie dieselben Skripte wie in IDEA in einer fachorientierten Sprache schreiben. Diese Sprache besteht aus einem zuvor zusammengestellten Glossar der verfügbaren Aktionen, die zuvor implementiert wurden. Wenn Sie einen Autotest auf Gauge von einem Entwicklercomputer oder CI aus durchführen, notiert QA Lens automatisch, welche Skriptschritte abgeschlossen wurden und welche nicht. Nachdem die Testabteilung einen Autotest eines von einem Analysten geschriebenen Skripts ausgeführt hat, erhält sie sofort vollständige und aktuelle Informationen über den Status des Produkts.


Autoren: Sunagatov Ildar und Yushkova Julia ( Yushkova )

Source: https://habr.com/ru/post/de459134/

More articles:


All Articles