Bisherige Timeline

Mit dem Release Blog Post zu Angular 12, hatte das Angular Entwicklerteam bekannt gegeben das Support- / Entwicklungsende von Protractor zu evaluieren.
Nach einem Request for Comments wurde dann entschieden, die Entwicklung von Protractor mit dem Angular 15 Release Ende 2022 einzustellen. Die Zukunft für Teams, die auf Protractor unbedingt angewiesen sind, blieb ungeklärt.

Diese Nachrichten bedeuteten für unzählige Automatisierungsteams weltweit Recherche- und Handlungsbedarf,
Alternativen mussten gesucht werden und umfangreiche Migrationen waren einzuplanen.

Alternative Frameworks

Mit dem Release von Angular 12 wurde frühzeitig Support von weiteren Frameworks realisiert.
Neben Nightwatch, Cypress und WebdriverIO hat auch Playwright mit einem Migration Guide für Zukunftsfähigkeit gesorgt.

Hierbei hat sich Cypress laut npm trends als der populärste „Ersatz“ für Protractor positioniert.

Breaking News

Bis hierhin sind das alles altbekannte Fakten, wozu also dieser Artikel?
Seit Mitte Q3 2022 gibt es endlich ein Update zu dieser für viele QA Kollegen kritischen Frage.

 

Das vorläufige Support-Ende von Protractor ist verschoben!

 

In einem offiziellen Statement wurde bekannt gegeben, dass uns der Protractor Support noch ein weiteres Angular Major Release erhalten bleibt.
Die neue Timeline sieht vor, dass Protractor nicht wie bisher geplant Ende des Jahres 2022 deprecated wird, sondern erst mit Angular 16 im Sommer 2023 sein Lebensende erreicht.
Bis dahin beschränkt sich die Weiterentwicklung allerdings auf sicherheitsrelevante Themen und Browserkompatibilitäten.

Dies wird den vielen Projekten mehr Luft zur Migration geben und sorgt für ein wenig Entspannung in den betroffenen Teams.

Das endgültige Ende von Protractor?

Breaking News Teil 2

Eine weitere äußerst positive Nachricht wurde zeitgleich veröffentlicht.
Die Angular / Protractor Entwickler planen zusammen mit HeroDevs einen public fork, um das langfristige Überleben / den Support von Protractor zu sichern.

PERFORMANCE ENGINEERING VS PERFORMANCE TESTING

Software Performance-Testing und Software Performance-Engineering sind zwei unterschiedliche Seiten derselben Medaille.

Ebenso unterscheiden sich die Rollen eines Performance-Engineer von denen eines Performance-Testers.

Daher sind PTLC (Performance Testing Life Cycle) und PELC (Performance Engineering Life Cycle) definiert, um die Aktivitäten von Performance-Testing bzw. Performance-Engineering zu rationalisieren.

 

 

 

 

Die wichtigste Unterschiede zwischen Performance-Testing und Performance-Engineering :

  • Performance-Testing ist eine Qualitätsprüfung der Anwendung in Bezug auf die Reaktionsfähigkeit und Belastbarkeit. Performance-Test überprüfen, wie sich ein System unter Produktion nähe Last verhält, und um Probleme zu antizipieren, die unter Bedingungen hoher Last auftreten können. Andererseits zielt Performance-Engineering darauf ab, die Anwendung unter Berücksichtigung der Leistungsmetriken zu entwerfen und potenzielle Probleme früh im Entwicklungszyklus zu erkennen.
  • Performance-Testing ist ein besonderer QA-Prozess, der nach Abschluss einer Entwicklungsrunde stattfindet, während Performance-Engineering ein fortlaufender Prozess ist, der sich durch alle Phasen des Entwicklungszyklus erstreckt, z.B. von der Designphase über die Entwicklung bis hin zur QA.
  • Ein dedizierter Performance-Tester oder ein Team führen die Leistungstests durch, die über fundierte Kenntnisse des Leistungstestkonzepts, des Werkzeugbetriebs, der Ergebnisanalyse usw. verfügen. Ein Performance-Engineer ist eine Person, die über ausreichende Kenntnisse in den Bereichen Anwendungsdesign, Architektur, Entwicklung, Tuning, Leistungsoptimierung verfügt, um Engpässe zu finden und weiter Ursachenforschung und -Behebung zu arbeiten.
  • Wenn während des Performance-Tests ein Engpass identifiziert wird, besteht die Rolle des Performance-Testers darin, das Testergebnis zu analysieren und einen Fehler zu melden. Auf der anderen Seite besteht die Aufgabe eines Performance-Engineer darin, die Grundursache zu untersuchen und eine Lösung zur Behebung des Engpasses vorzuschlagen.
  • Der Performance-Tester kümmert sich nicht sehr um das Design und die Architektur der Anwendung. Er konzentrierte sich nur auf das Anwendungsverhalten unter Last, während der Performance-Engineer kümmert sich darum, wie effizient jede Komponente der Anwendung unter Last arbeitet.
  • Der während der Performance-Test identifizierte Engpass erfordert mehr Geld als ein gut abgestimmtes Anwendungsdesign, das von einem Performance-Engineer überprüft und zertifiziert wird.
  • Der PTLC deckt alle Phasen des Performance-Testing ab, während der PELC alle technischen Aktivitäten und Ergebnisse abdeckt.
  • Während Performance-Test in der Regel nach der Entwicklung der Anwendung durchgeführt werden, ist das Performance-Engineering tief in SDLC integriert, um sicherzustellen, dass das System mit hohen Standards erstellt wurde, um sicherzustellen, dass es für die Leistung optimiert ist.
  • Ein Performance-Tester mit guten Leistungstestfähigkeiten wird ein guter Performance-Engineer, wenn er Interesse an Engpassidentifikation, Ursachenanalyse und Anwendungsoptimierung hat. Um dieser Rolle gerecht zu werden, muss er jedoch über gute Kenntnisse des Anwendungsdesigns und der Anwendungsarchitektur verfügen.
  • Performance-Engineering ist jedoch eine breite Palette von Prozessen und auch eine Kultur, die ermöglicht Teams schnelle, effiziente und reaktionsschnelle Systeme und Applikationen bereitstellen
  • Performance-Engineering ist auch sehr geeignet für die Shift Left Ansätze.

VERWANDTE BEGRIFFE

JaCoCo ist eine Open-Source-Bibliothek für Java, die die Code-Abdeckung (Code Coverage) einer Applikation misst. Die Code-Abdeckung ist ein wichtiges Kriterium für die Beurteilung der Testabdeckung einer Applikation, denn durch geeignete Tests und eine hohe Testabdeckungsrate wird der Produktionscode gründlich überprüft.

Einige Features von JaCoCo sind beispielsweise die Erstellung von Reports in verschiedenen Formaten (HTML, XML, CSV) und die Integration in IDEs und CI – Pipelines. In Kombination mit SonarQube oder Jenkins kann somit die Code Coverage außerhalb der IDE stattfinden und durchs Reporting für das Entwicklungsteam zentral und transparent verfügbar gemacht werden.

In diesem Artikel zeige ich die Einrichtung von JaCoCo mit JUnit Tests, sowie die Integration der Ergebnisse in SonarQube.

Weiterlesen

Allure Reporting ist eines der beliebtesten Open Source Produkte im Testbereich. Aus gutem Grund! Die Reports aggregieren die benötigten Daten sehr übersichtlich. Die Anbindung an die meisten Testframeworks wie Cucumber, TestNG, Selenide und andere funktioniert in der Regel reibungslos.

Spannend wird es bei Allure nur, wenn es um spezielle Anforderungen geht. Es können Postprocessing Aggregationen von unterschiedlichen Runs sein, aber auch das Anhängen von Dateien (Log Files oder Screenshots…) im Test-Lebenszyklus. Um den letzten Punkt geht es in diesem Artikel.

Weiterlesen

Tester führen Tests gerne in Docker Containern aus, soweit so bekannt.. Auch dass wir alle ganz gerne git verwenden, wundert eigentlich nicht wirklich. Nur kann die Kombination von beiden auch kleinere Probleme bereiten. So sind auch bei uns spontan, von einem Tag auf den anderen sämtliche Testfälle beim Cleanup der Umgebung ausgestiegen mit der Fehlermeldung:

+ git clean -fdx
fatal: unsafe repository ('/usr/share/jenkins/workspace/tests/nightly' is owned by someone else)
To add an exception for this directory, call:

	git config --global --add safe.directory '/usr/share/jenkins/workspace/tests/nightly'

Weiterlesen

Mit der Version 1.17 hat Playwright seine API aktualisiert und bietet seitdem neue Methoden zur Interaktion mit iframes. Hinzu kommen außerdem für Java neue Playwright- und LocatorAssertions-Klassen, die für Assertions in Testfällen verwendet werden können. Diese warten bis zum Eintreffen einer Bedingung, beispielsweise bis ein DOM-Node einen bestimmten Text hat. Sehen wir uns die einzelnen Updates an.

Weiterlesen

Playwright Framework unterstützt mehrere Verfahren zum Auffinden von Oberflächenelementen auf einer Webseite. Neben den allgemein bekannten Selektoren gibt es in Playwright noch weitere Konzepte wie  ElementHandle und Locator, die die Suche nach DOM-Elementen auf einer Webseite unterstützen und im diesem Artikel näher beleuchtet werden.

Weiterlesen

Einbindung von Playwright unter JUnit

Nachdem wir in einem anderen Artikel die grundlegende Einrichtung und Verwendung von Playwright demonstriert haben, wollen wir nun Playwright einsetzen, um mit JUnit die echten Tests einer Webanwendung zu schreiben. Weiterlesen

E2E-Tests haben u.a. den Nachteil, instabil und langsam zu sein. Aus diesem Grund hat Microsoft die Open-Source Playwright-API entwickelt, die als E2E Testframework der nächsten Generation gilt. Mit Playwright verfolgt man das Ziel, die browserübergreifende Webautomatisierung schneller und zuverlässiger zu gestalten. Dabei basiert Playwright auf einer ereignisgesteuerten (sog. event-driven) Architektur, welche automatisch auf Browser-Ereignisse wie Seitennavigation, Netzwerkanfragen oder DOM-Änderungen wartet. Mit neueren Versionen kommen immer weitere Features hinzu wie beispielsweise Geolokalisierung oder Mobile Emulation, um mobile Webseiten zu testen. Playwright API wird für verschiedene Programmiersprachen bereitgestellt: Java, Python, C#, JavaScript / TypeScript. In diesem Beitrag geht es um die Einrichtung von Playwright mit Java.

1. Einrichtung der Entwicklungsumgebung

Wir benötigen zuerst eine Entwicklungsumgebung für Java, die auf der folgenden Seite heruntergeladen werden kann: https://www.jetbrains.com/de-de/idea/download/. Einfach die Community-Version auswählen, die .exe-Datei ausführen und die Installationsschritte durchführen.

2. Maven installieren

Zur schnellen und einfachen Einrichtung von Playwright verwenden wir das Build-Management-Tool Maven, mit welchem die Playwright API Bibliotheken als Abhängigkeiten in Java Projekte automatisiert eingebunden werden. Zur Installation von Maven gehen wir wie folgt vor:

  1. https://maven.apache.org/download.cgi besuchen und das Binary zip-Archiv herunterladen
  2. Die Datei in einem beliebigen Ordner entpacken, z.B. in C:/ program files /
  3. Nach dem Entpacken, den bin-Ordner zum Systempfad hinzufügen

Systemumgebungsvariablen bearbeiten

In der Suchleiste env eintippen und Systemumgebungsvariablen bearbeiten auswählen

Umgebungsvariablen auswählen

Auf Umgebungsvariablen klicken

Path bearbeiten

Path auswählen und auf Bearbeiten klicken

bin-Ordner auswählen

Neuen Eintrag erstellen, zum bin-Ordner von dem entpackten Apache-Maven Archiv navigieren und diesen selektieren

  1. cmd.exe öffnen und mit mvn -v oder mvn –version überprüfen, ob Maven richtig installiert wurde

Bei Problemen die Hinweise zur Installation beachten: https://maven.apache.org/install.html

3. Neues Playwright Projekt erstellen

Mit Maven sollen möglichst viele Schritte automatisiert werden, wie etwa die Erstellung eines Projekts, das Testen usw. Die sog. Archetypes bieten eine Art „Gerüst“ für unterschiedliche Typen von Softwareprojekten an, deren Struktur dem Standard von Maven entspricht. Der Befehl mvn -B archetype:generate -DgroupId=de.simplytest -DartifactId=mein-maven-projekt -DarchetypeArtifactId=maven-archetype-quickstart -DarchetypeVersion=1.4 erstellt das einfachste Maven-Projekt in einem Verzeichnis mit dem Namen mein-maven-projekt . Mehr über die Maven-Archetypes erfährt man hier. Den Ordner öffnen wir in Intellij und fügen Playwright unter dem XML-Knoten dependencies in der pom.xml-Datei ein. Falls eine Warnung kommt, einfach auf Trust Project klicken.

<dependencies>
    <dependency>
      ...
    </dependency>
 
    <dependency>
      <groupId>com.microsoft.playwright</groupId>
      <artifactId>playwright</artifactId>
      <version>1.14.1</version>
    </dependency>
     
  </dependencies>

Außerdem sollten wir unter dem properties-Tag maven compiler source und maven compiler target zu 1.8 ändern, um die aktuellen Java 8 Features verwenden zu können.

<properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <maven.compiler.source>1.8</maven.compiler.source>
    <maven.compiler.target>1.8</maven.compiler.target>
  </properties>

4. Erste Schritte mit Playwright in Java – „Titel einer Seite ausgeben“

In mein-maven-projekt > src > main > java > de.simplytest > App.java befindet sich die main-Methode, die automatisch mit der Generierung der Archetype angelegt wird. Wir können natürlich aber ebenfalls weitere Java-Klassen erstellen und zum Projekt hinzufügen. Nehmen wir den folgenden Code als Programmbeispiel. Hier starten wir Firefox, navigieren dann zur offiziellen Playwright-Webseite und geben anschließend den Titel der Seite aus.

package de.simplytest;
 
import com.microsoft.playwright.*;
 
public class App 
{
    public static void main(String[] args )
    {
        try (Playwright playwright = Playwright.create()) {
            Browser browser = playwright.firefox().launch(new BrowserType.LaunchOptions().setHeadless(false));
            Page page = browser.newPage();
            page.navigate("http://playwright.dev");
            System.out.println(page.title());
        }
    }
}

Playwright öffnet den Browser standardmäßig ohne User Interface im sogenannten headless-Modus, also sehen wir nicht wirklich die interaktive Ausführung des Programms. Um das zu ändern, setzen wir mittels LaunchOptions den headless-Flag auf false und eventuell auch setSlowMo, um die Ausführungszeit der API zu verlangsamen.

Programm starten

Als Letztes geben wir den folgenden Befehl ein, um das Programm über Terminal auszuführen: mvn compile exec:java -Dexec.mainClass=de.simplytest.App

Am Ende sehen wir den Titel der Webseite : Fast and reliable end-to-end testing for modern web apps