Wer Tests schreibt, sollte zwangsläufig auch Assertions verwenden. Bevor man Assertions verwenden kann, sollte man aber natürlich eine geeignete Assertionsbibliothek auswählen. Dieser Artikel vergleicht fünf der populärsten Bibliotheken: JUnit Assert, TestNG Assert, AssertJ, Hamcrest und Truth.
Unter dem Motto „meetup automate innovate“ fand vom 28. bis 30. März die Selenium Konferenz in Chicago statt. Ich hatte das Vergnügen, diese besuchen zu. Die Keynote präsentierte Diego Molina von Sauce Labs mit einem Vortrag, in dem er den Stand der Entwicklung umriss (Selenium: State of the Union). Man kann es wohl nicht oft genug sagen, dass Selenium ein Werkzeug zur Browserautomatisierung ist, auf dem Frameworks aufsetzen können. Es sieht sich selbst als „low level“ Bibliothek oder Plattform, welche die Grundfunktionen bereitstellt.
Diego Moline legt besonderen Wert darauf zu betonen, dass das Selenium Projekt ein Gemeinschaftsprojekt ist und durch die Zusammenarbeit mit Anderen das Software-Testen verbessern möchte. Als prominentes Beispiel führt er an, wie Jason Huggins (Selenium) und Simon Stewart (WebDriver) zusammenarbeiten. Des Weiteren gibt er Ausblick auf kommende Verbesserungen und Entwicklungen, die in absehbarer Zukunft verfügbar werden. Wie der Selenium Manager, der die Einrichtung der Treiber vereinfacht. Besonders interessant auch die Entwicklung zu WebDriver BiDi, welches das Potenzial hat, die Browserautomatisierung auf ein neues Level zu heben.
Außerdem wird die Community hinter dem Projekt vorgestellt und einige Wege aufgezeigt, wie man sich in diese einbringen kann. Unter anderem direkt im Chat über IRC oder Slack. Oder das Melden eines Bugs im Tracker auf GitHub.
Die zweite Keynote des Eröffnungstages wurde von Erika Chestnut präsentiert. Ihr Themenschwerpunkt: Verpasste Chancen oder Missed Opportunities. Sie spricht darüber, wie Qualität leidet, wenn die QA-Mitarbeiter in Schubladen gesteckt werden. Denn so viele Bereiche beeinflussen die Qualität eines Produkts, dass man als QA-Verantwortlicher die Chancen ergreifen sollte, wo man sie sieht, um die eigene Firma zu verbessern. Als Tester braucht man ein umfassendes Verständnis für die Software, was sie tut, womit sie interagiert und wie die Kunden sie benutzt. Wenn das nicht klar kommuniziert wird, ist es auch die Aufgabe der QA-Verantwortlichen darauf zu verweisen und Lösungen aufzuzeigen.
Die Keynote des zweiten Konferenztags präsentierte Mark Winteringham vom Ministry of Testing mit der berechtigten Frage, was genau machst du denn in der Testautomatisierung? Unter Einbeziehung des Publikums geht er der Frage nach, was wir als Testautomatisierer denn täglich, wöchentlich und monatlich so machen. Er berichtet, wie er zu Beginn seiner Karriere als Erstes die Frage stellte, welches Tool er lernen sollte. Eine Analyse des Stellenmarkts zeigt auch, dass immer nach den Werkzeugen gefragt wird, die man kann.
Im weiteren Verlauf kommt er zu dem Punkt, dass die Tools nur Mittel zum Zweck sind. Das Ziel bei der Automatisierung ist, die sich wiederholenden Aufgaben wegzuautomatisieren, Überprüfungen einzubauen, die allen Beteiligten schnell Rückmeldung geben und diese Ergebnisse zu kommunizieren. Es gibt kein Framework, mit dem man alles erschlägt. Unsere Aufgabe ist, das richtige Werkzeug für die anstehende Aufgabe zu wählen, was auch heißt neue Werkzeuge auszuprobieren. Entsprechend auch eine Strategie entwickeln, was automatisiert werden soll, in welcher Reihenfolge und mit welchen Mitteln. Dazu gehört auch die Risikoabschätzung für die Aufgaben. Wo haben wir den größten Nutzen?
Ich kann jedem nahelegen, sich die drei verlinkten Keynotes anzusehen. Sie decken eine Menge allgemeingültige Bereiche des weiter gefassten Umfelds der Qualitätssicherung ab. Einige der Folgevorträge gehen zum Teil näher auf angesprochene Themen ein oder richten sich an spezielle Problemstellungen. Alle Vorträge wurden aufgezeichnet und sind auf dem YouTube-Kanal der Selenium Conference verfügbar.
Der Vortrag über WebDriver BiDi bietet einen detaillierteren Einblick in die Entwicklung und was uns dort erwartet. Sehr spezifisch war der Vortrag über Crawler von Noemi Ferrera, wenn auch eher selten in der Anwendung im Alltag des Testers (Shift Left), ist es doch immer hilfreich, außerhalb der eigenen Box etwas zu lernen. Wer kennt es nicht bei dem Test einer Webseite, diesen einen Knopf zu drücken, funktioniert manuell wunderbar, aber aus irgendeinem Grund scheitert die Automatisierung. Wem das vertraut vorkommt, dem sei der Vortrag UNTestable nahegelegt, in dem Shi Ling-Tai einige der gemeinen Konstrukte moderner Webseiten aufzeigt und wie man sie testet.
Hier alle Vorträge aufzulisten, würde den Rahmen sprengen. Lest die Kurzbeschreibungen der Vorträge auf der Agenda-Seite der Selenium Conf Webseite. Schaut euch die Aufzeichnungen auf YouTube an. Interessiert euch ein Thema, seht es euch an. Und wenn ihr die Gelegenheit habt, persönlich auf ein Treffen zu gehen, nutz diese. Die Gespräche mit anderen Teilnehmern zwischen den Vorträgen waren auch sehr aufschlussreich. Menschen aus den unterschiedlichsten Branchen, mit ähnlichen Herausforderungen und unterschiedlichen Lösungen.
Mir hat es Spaß gemacht, die Konferenz zu besuchen und meine Auffassung, was alles in den Bereich der Qualitätssicherung fällt, wurde deutlich erweitert. Wenn ihr ein Meetup besucht habt oder eines empfehlen wollt, lasst es mich in den Kommentaren wissen. Vielleicht trifft man sich dann schon bald persönlich.
Cloud Performance Testing ToolsDie Cloud Performance Testing Tools bieten die Möglichkeit, die Tests auf einer Cloud-Infrastruktur auszuführen. Der Hauptvorteil von Cloud-basierten Performance Test ist die Simulation verschiedener geografischer Standorte, die dabei helfen, die Last auf den Server aus verschiedenen Regionen, Ländern und Gebieten anzuwenden.
Das Konzept des Cloud-basierten Performance Test besteht darin, das Skript auf einem lokalen Computer zu erstellen, das Skript in der Cloud hochzuladen, das Online-Szenario zu erstellen, den Test auszuführen und den Bericht zu erstellen. Viele Cloud-basierte Tools haben ihr eigenes Skripting-Tool, während einige von ihnen Open-Source-Tools wie Apache JMeter verwenden.Das schnelle Wachstum der Cloud-basierten Technologie erhöht auch die Verwendung von Cloud-basierten Testwerkzeugen. Sie sind leistungsstark und einfach zu bedienen.
Im Zusammenhang mit der Qualitätssicherung von Software hat sich der Begriff Mutation Testing etabliert. Mithilfe von Mutationstests werden Änderungen am Quellcode durchgeführt, um die Tests zu testen, die die Software testen. 🙂
Ein populäres Werkzeug für solche Tests ist Stryker. Sehen wir uns an, wie uns Stryker dazu bewegt, qualitativere Tests zu schreiben.
Das Beispielprojekt findet ihr auf GitHub.
Für dieses Tutorial verwenden wir Visual Studio Code und npm. PowerShell oder CMD öffnen und folgende Befehle eingeben, um die benötigten Ordner zu erstellen. Unter src wird unser Softwarecode liegen (da wir für Mutationstests den Quellcode brauchen) und die entsprechenden Tests unter test:
mkdir BaseConverter
cd BaseConverter
mkdir src
mkdir test
code .
Nun ist Visual Studio Code offen und wir können mit der Initialisierung des Projekts beginnen. Dazu im Terminal aus VS Code npm init eintippen und die Anweisungen im Terminal befolgen. Optional können die Felder ausgelassen werden und später in package.json nachträglich geändert werden.
Als Testrunner und Assertion Library werden Mocha und Chai, sowie ts-node für die TypeScript Tests installiert. Um die Type Definitions für Mocha und Chai zu installieren, benötigen wir @types/chai und @types/mocha Packages.
npm install mocha chai ts-node --save-dev
npm install @types/chai @types/mocha --save-dev
Da wir mit einem TypeScript Projekt arbeiten, sollten wir tsc --init ausführen, was uns standardmäßig eine tsconfig.json erstellt.
Wir wollen den Ansatz von Test-Driven-Development verfolgen und zuerst die Tests für das Projekt BaseConverter implementieren, welches 2 Funktionen besitzt: Konvertieren einer Dezimalzahl ins binäre Format und andersherum. Dazu eine Datei unter test anlegen und die entsprechenden Tests schreiben:
import { expect } from 'chai';
import 'mocha';
describe('Base Converter Tests', () => {
it('Should convert positive decimal to binary.', () => {
expect(convert_decimal_to_binary(8))
.to.equal('01000', 'Converted number was not as expected!');
});
it('Should convert negative decimal to binary.', () => {
expect(convert_decimal_to_binary(-8))
.to.equal('11000', 'Converted number was not as expected!');
});
it('Should convert negative binary to decimal.', () => {
expect(convert_binary_to_decimal('11000'))
.to.equal(-8, 'Converted number was not as expected!');
});
it('Should convert positive binary to decimal.', () => {
expect(convert_binary_to_decimal('01000'))
.to.equal(8, 'Converted number was not as expected!');
});
});
Bevor wir die Tests starten, müssen wir in package.json „scripts“: { „test“: .. } anpassen, damit mocha die TypeScript Tests findet und ausführen kann:
"mocha -r ts-node/register test/**/*.ts"
Die Tests können einfach mit dem Befehl npm test ausgeführt werden, diese werden jedoch nicht kompiliert, weil die Methoden convert_decimal_to_binary() und convert_binary_to_decimal() fehlen. Also unter src/BaseConverter.ts diese implementieren:
function convert_decimal_to_binary(n: number): string {
if(n == 0 ) return '0';
const sign: string = n < 0 ? '1' : '0';
let absoluteNumber: number = Math.abs(n);
let convertedDecimal = '';
while(absoluteNumber > 0) {
const reminder: number = absoluteNumber % 2;
convertedDecimal += reminder.toString();
absoluteNumber = Math.floor(absoluteNumber / 2);
}
convertedDecimal += sign;
const separator = '';
return convertedDecimal.split(separator).reverse().join(separator);
}
function convert_binary_to_decimal(binaryNumber: string): number {
const sign: number = binaryNumber.at(0) === '1' ? -1 : 1;
const absoluteBinary: string = binaryNumber.slice(1);
const absoluteDecimal: number = absoluteBinary.split('').reverse()
.reduceRight((_, curr, index) => _ + Math.pow(2, index) * parseInt(curr), 0);
return sign * absoluteDecimal;
}
export {
convert_decimal_to_binary,
convert_binary_to_decimal
};
Wenn alles richtig implementiert wurde, sollten die Tests jetzt alle erfolgreich laufen.
Die Tests waren alle erfolgreich, wir haben also abgeprüft, ob die implementierten Funktionen sowohl positive als auch negative Zahlen von einem Zahlensystem ins andere konvertiert. Mit Stryker sollten diese Tests auf Vollständigkeit überprüft werden. Folgende Befehle eingeben und wieder die Anweisungen im Terminal befolgen:
npm install --save-dev @stryker-mutator/core
npx stryker init
Ein letztes Package muss für unser TypeScript Projekt installiert werden, Stryker TypeScript Checker:
npm install --save-dev @stryker-mutator/typescript-checker
Die Konfigurationsdatei stryker.conf.json muss zuletzt noch angepasst werden, damit Stryker richtig konfiguriert wird. Diese beinhalten u.a. Optionen für unseren Test Runner (in unserem Fall Mocha), welche Dateien mutiert werden sollen und TypeScript-spezifische Konfigurationen:
"mochaOptions": {
"spec": ["test/**/*.js"],
"package": "./package.json"
},
"checkers": ["typescript"],
"tsconfigFile": "tsconfig.json",
"buildCommand": "tsc -b",
"mutate": [ "src/**/*.ts"]
Nach der Ausführung von npx stryker run gibt es im Ordner reporter einen HTML-Report.
Wir haben einen Mutation Score von 90% erreicht. Wenn wir uns den geänderten Quellcode ansehen, können wir herausfinden, welche Mutanten nicht von unseren Tests getötet worden sind. Hier haben wir einen Testfall vergessen, und zwar einen direkten Test mit 0:
it('Should convert decimal zero to binary.', () => {
expect(convert_decimal_to_binary(0))
.to.equal('0', 'Converted number was not as expected!');
});
Nachträglich hinzugefügt erreichen wir trotzdem keinen Mutation Score von 100%.
Warum? Laut Stryker hat der Mutant aus Zeile 2 mit der geänderten Bedingung zu false überlebt. Das ist auch richtig so, denn bei false wird die Zeile bei einem Parameter von 0 übersprungen und in Zeile 4 abgeprüft, ob diese Zahl unter 0 liegt. Wenn nicht, wird die Konstante sign auf 0 gesetzt, welche im Quellcode in Zeile 14 zum Rückgabewert der Funktion eingefügt wird convertedDecimal += sign; Die Programme sind also äquivalent! Die Abfrage auf n === 0 kann im Quellcode weggelassen werden und erreichen somit vollständige Testüberdeckung!
Ist das aber trotzdem richtig? Nicht ganz. Hier kommen die Einschränkungen von Stryker ins Spiel. Die Methode convert_binary_to_decimal() wurde gar nicht mutiert, da Stryker nicht die entsprechenden Mutationsoperatoren für die Logik hinter dem Code besitzt.
Durch das Werkzeug Stryker zur Unterstützung von Mutationstests haben wir die Möglichkeit, unsere Tests auf Vollständigkeit zu testen. Falls es Mutanten eines Programms gibt, die trotz unserer Tests überleben, sollten wir uns Gedanken über bessere Tests machen. Nichtsdestotrotz kommt es auf die tatsächliche Implementierung der Software an und wie stark ein Werkzeug ein Programm mutieren kann, andernfalls kann es zu false positives kommen, da wir, wie in der obigen Grafik zu sehen ist, einen Mutationsscore von 100% erreichen, obwohl wir nicht alles getestet haben (z.B. Testfall von 0 aus dem Binärsystem ins Dezimalsystem fehlt, oder falls ein String für convert_binary_to_decimal() leer ist…).
Lizenzierte Performance Test-Tools sind kommerzielle Tools. Diese Tools können nur durch den Kauf des Lizenzpakets bei dem jeweiligen Unternehmen verwendet werden. Die Testtool-Unternehmen bieten Lizenzen basierend auf:
Einige Unternehmen bieten die Möglichkeit, ein benutzerdefiniertes Paket der Lizenzen zu erstellen.Abgesehen von der kostenpflichtigen Lizenz, stellen Unternehmen auch die Probe(Trial) Version des Tools aus, die eine begrenzte Benutzerzahl, generische Protokollunterstützung oder eine begrenzte Nutzungsdauer des Tools hat. Eine Testversion kann hilfreich sein, um einen PoC (proof of concept) durchzuführen.
Open Source Performance Testing ToolsOpen Source-Performance-Testing-Tools sind frei verfügbar und benötigen keine kommerzielle Lizenz. Diese Tools sind eher einfach einzurichten als ein kommerziell lizenziertes Tool, aber auch mit bestimmte Einschränkungen verbunden.
ÜbersichtTesten Sie ein neues Tool oder bereiten eine Demo/POC vor? Hier sind einige nützliche Websites, die Sie immer zur Hand haben sollten.
Testseiten werden immer zum Üben benötigt. Sei es für Kurse, Workshops, Webinare, das Testen neuer Tools usw. Hier eine Liste von Testseiten, die sich zum Ausprobieren eignen.
In diesem Artikel möchte ich demonstrieren, wie sich auf einfache Weise eine Swagger Spezifikation in Postman importieren lässt, was uns letztlich eine Collection von Testfall Grundgerüsten für alle spezifizierten Endpunkte anlegt.
Abb. 1 – Swagger Logo
Bei OpenAPI handelt es sich um einen Industriestandard zur Beschreibung von REST-konformen API‘s, der von der OpenAPI Initiative verwaltet wird.
Swagger stellt letztlich ein Open-Source Framework für die Entwicklung von API’s für http-Webservices dar, das konform zur OpenAPI-Spezifikation ist. Swagger ist also das zugehörige Toolset.
Das Postman Projekt wurde 2012 ins Leben gerufen und ist ein skalierbares Tool für API-Integrationstests, dass sich in CICD Pipelines integrieren lässt. Inszwischen hat das Tool über 4 Mio. Nutzer, da es einige große Vorteile mit sich bringt:
Schauen wir uns exemplarisch eine REST-API in der Swagger-UI an:
Abb. 2 – SwaggerUI
oder die API-Docs die aus der Schnittstelle generiert werden:
Abb. 3 – Swagger Docs
Es gibt verschiedene Wege, eine Swagger-API Spezifikation in Postman hochzuladen und daraus die Grundgerüste für unsere Testfälle generieren zu lassen. Der Import wird hier z.B. im JSON Format durchgeführt, es sind aber auch andere Formate möglich.
Wir wollen eine Textdatei, im JSON Format, hochladen die in etwa wie folgt aussieht:
Abb. 4 – Datei Import
Wir wählen also in Postman den Button „Import“ im linken Bereich oben (Scratch Pad), wo wir auch unsere Collections anlegen können.
Abb. 5 – Postman Scratch Pad
Der folgende Dialog gibt uns verschiedene Auswahlmöglichkeiten, wir wählen „File“ und „Upload Files“:
Abb. 6 – Postman File-Import Dialog
Im nächsten Dialog bestätigen wir mit „Import“:
Abb. 7 – Postman File-Import Dialog (2)
Wie wir in Abbildung 9 sehen, wird eine Projektstruktur in Reiter Collections angelegt.
Abb. 8 – Postman Test-Collection
Hier wählen wir im Import Dialog die Option „Link“ und bestätigen mit „Continue“.
Abb. 9 – Postman Import via Link
Im folgenden Dialog bestätigen wir mit Import.
Abb. 10 – Postman Import via Link (2)
Im Folgenden sehen wir, dass eine weitere Collection angelegt wurde, die der Ersten entspricht.
Abb. 11 – Postman Test Collection (2)
Wir können aber auch einfach den Text (JSON) in den Postman Dialog kopieren und importieren.
Abb. 12 – Postman Import via Raw-Text
Wir müssen allerdings beachten, dass hier nur die reinen Requests, ohne Authentifizierung, Prerequisites oder Testscripts angelegt werden (Abb. 13, Abb. 14).
Die Authentifizierung/Authorisierung, Testvorbereitungslogik und die eigentliche Testlogik, müssen wir also selbst implementieren.
Abb. 13 – Postman Testscripts
Abb. 14 – Postman Vorbereitungs-Skripte
Die Import-Funktion aus einem Git-Repository heraus ist eine der Premium-Funktionen von Postman und wird an dieser Stelle daher nicht im Detail erörtert. Es sei nur darauf verwiesen, dass dies mit dem sog. Postman-Workspace ebenfalls, mit wenigen einfachen Schritten, möglich ist.
JetBrains führt mit dem neuen Produkt JetBrains Aqua eine leistungsstarke IDE zur Testautomatisierung ein. Laut Entwicklern „beinhaltet die IDE alles, was ein QA Engineer braucht“ – Unterstützung mehrerer Programmiersprachen (darunter Python, Java, JavaScript, TypeScript und Kotlin), Verwendung verschiedener Datenbanken sowie Generierung von Testdaten mit einem Zufallsdaten-Generator, Vorbereitung von Testumgebungen mithilfe von Docker, integrierter Web-Inspektor etc.
Folgender Ausschnitt zeigt eine Liste vielversprechender Funktionen:
Die IDE befindet sich noch in Entwicklung, weitere Features wie z.B. Support für Playwright und Cypress folgt noch. Während der Preview-Phase kann Aqua über die JetBrains Toolbox App oder als Plugin in bestehenden IDEs heruntergeladen oder hinzugefügt werden. Sehen wir uns mal die Entwicklungsumgebung an.
Das Anlegen eines neuen Selenium-Projekts erfolgt schnell und unkompliziert über eine saubere UI. Durch ein Paar Mausklicks wird die JDK, Projektsprache, Testrunner (JUnit oder TestNG), sowie Build Tool (Maven/Gradle) ausgewählt.
Zusätzliche Projekt-Abhängigkeiten wie beispielsweise Selenide oder Assertions Libraries können gleich im nächsten Dialog-Fenster ausgesucht werden und schon ist ein Projekt angelegt.
Über das New File Menu können POs hinzugefügt werden. Diese werden nach bestimmten Templates kreiert, die nach Belieben ergänzt oder neu erstellt werden können.
Nach dem Erstellen des Page Objects erscheint neben der Klasse ein „Web“-Symbol. Darüber kann der integrierte Web-Inspektor geöffnet werden. Dieser stellt eine Live-View der zu testenden Seite dar und unterstützt die Entwickler bei der Auswahl von eindeutigen CSS oder XPath-Selektoren für die automatisierten Tests:
Solange der Web-Inspektor in der IDE offen ist, zeigt die Code Completion für CSS und XPath die wichtigsten oder die gerade eingetippten Lokatoren an:
Über das „+„-Symbol werden DOM-Elemente aus dem Web-Inspektor direkt als Variable in der Page Object Klasse angelegt:
Außerdem bietet Aqua umfangreiche Unterstützung für die Selenium-API und Selenide und gibt uns einen Einblick in den Code der CSS-, XPath-Selektoren, die in der Selenium-API und vielen anderen Bibliotheken für UI-Tests verwendet werden. So wird auch falsche XPath-Syntax erkannt und entsprechend markiert:
Tests beinhalten normalerweise Links zu auftretenden Issues in einer Applikation. QA Engineers verwenden oft externe Libraries wie Allure Framework oder Selenide BDD, um auf diese Issues in den Tests aufmerksam zu machen. JetBrains Aqua bietet nun auch Annotationen für diese Libraries und lässt den Issue Link mit einem Klick öffnen. Die Reporters werden in den Einstellungen konfiguriert.
Dank des integrierten HTTP-Clients lassen sich HTTP-Requests verschicken und empfangen. Die Code Completion erspart uns ihrerseits eine Menge Arbeit.
Die Anfragen können direkt aus der IDE gestartet und deren Responses unter View > Tool Windows > Services anzeigen lassen (in dem Fall mit Status 401, da wir bei der GET-Anfrage keine Authentifikation angegeben haben) :
Ein weiteres Feature von JetBrains Aqua ist die (gleichzeitige) Unterstützung von Datenbanken, z.B. direkter Zugriff auf Oracle, SQL Server, PostgreSQL, MySQL usw. aus der IDE. SQL-Abfragen können auch direkt implementiert werden.
Die Preview-Phase der IDE ist vor kurzem veröffentlicht worden und wir haben in diesem Artikel ein paar Features davon gesehen. Weitere werden entwickelt, die bestehenden erweitert und noch leistungsfähiger gemacht, also auch wenn die gewünschten noch nicht dabei sind, können wir davon ausgehen, dass sie in naher Zukunft ebenfalls angeboten werden. Warten wir also ab, was JetBrains uns demnächst anbietet.
In diesem kurzen Beitrag möchte ich die Impressionen meines kurzen Besuches desdiesjährigen Software QS-Tag 2022 – Frankfurt am Main (05.10.2022-06.10.2022) zusammenfassen. Rund um das Thema Reinventing Quality wurden viele Strategien, Techniken, Tools und Best Practices präsentiert und diskutiert. Ich habe viele dieser Vorträge besucht und kann darüber kurz berichten. Weiterlesen