In diesem Tutorial erstellen wir gemeinschaftlich ein kleines Beispielprojekt mit den folgenden Technologien und Methoden:
Node.js
npm
Visual Studio Code
Cypress
Gherkin
Cucumber
Page Object Model
Als Erstes werden die einzelnen Technologien erläutert, diese danach installiert und anschließend das Projekt aufgesetzt.
Das Tutorial ist primär für Anfänger konzipiert, wobei jeder Teil bei bereits vorhandenem Wissen,
einfach übersprungen, und zum nächsten Teil übergegangen werden kann.
https://www.testautomatisierung.org/wp-content/uploads/Cypress_Logo.png685793Christian Purmannhttps://www.testautomatisierung.org/wp-content/uploads/ta5.pngChristian Purmann2023-11-27 17:27:172023-12-26 12:33:35Testautomatisierung mit Cypress 13, Gherkin und Cucumber unter Anwendung des Page-Object-Modells
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.
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.
Dependencies installieren
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.
Da wir mit einem TypeScript Projekt arbeiten, sollten wir tsc --init ausführen, was uns standardmäßig eine tsconfig.json erstellt.
Tests implementieren
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:
Wenn alles richtig implementiert wurde, sollten die Tests jetzt alle erfolgreich laufen.
Stryker einsetzen
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:
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:
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.
Zusammenfassung
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…).
Redakteur auf Testautomtisierung.org
Geschäftsführer, Schulungsleiter bei SimplyTest GmbH, Nürnberg www.simplytest.de
Passionierter Softwareentwickler und Testautomatisierungsverfechter mit langjähriger beruflicher Erfahrung als Softwareentwickler, Test Automation Manager, Teamleiter und Projektleiter
Testen 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.
Demo Sites:
Demoblaze ist ein beispielhaftes E-Commerce-System, das von BlazeMeter bereitgestellt wird, um die Automatisierung mit JMeter zu üben und es mit Blazemeter auszuführen. Es enthält sogar einen Abschnitt mit einem Video, damit Sie das HLS-Protokoll testen können.
OpenCart Für Schulungen kann es hilfreich sein, eine Version des Open-Source-E-Commerce-Systems OpenCart zu installieren.
WPmobilepack ist ein sehr einfaches E-Commerce-System, das sich hervorragend zum Testen geeignet.
Juice-Shop ist eine bekannte Website zum Testen von Sicherheitslücken.
Computer-Database ist eine von Gatling (Performance Test) bereitgestellte Testseite. Es ist eine Website mit einer Computerdatenbank, auf der es eine Liste mit mehreren Spalten und einem Suchfilter gibt.
DemoQA enthält eine Vielzahl an Elementen, die auf Websites typisch sind. Die Seite ist gut darauf ausgerichtet, Testautomatisierung zu üben, mit verschiedenen Objekten in unterschiedlichem Kontext. Elemente einer Liste, die per Drag & Drop geordnet werden, Eingänge verschiedener Formate, Buttons und Alarme, usw.
SwagLabs ist eine weitere Demo-Web-Storefront, die zum Testen von Anmelde- und Warenkorbabläufen nützlich ist. Ein wichtiger Punkt bei diesem ist, dass es 4 verschiedene Logins gibt, die Sie für verschiedene Erfahrungen für dieselbe Site verwenden können; normaler, gesperrter, problematischer Benutzer und Benutzer mit Leistungsstörungen.
Selenium Easy ähnelt DemoQA, wird aber von Smartbear CrossBrowserTesting bereitgestellt.
Test Pages for automating ist voll von Beispielseiten, von Alan Richardson, auch bekannt als „Evil Tester“, die für automatisierte Prüfungen verwendet werden können.
The-Internet Dave Haeffner, Schöpfer von Elemental Selenium, bietet diese Seite an, um verschiedene Dinge wie Dropdown-Menüs, Hover usw. zu testen.
UI Testing Playground Diese Website ist möglicherweise kleiner als die anderen, enthält jedoch Edge Cases für Ladeverzögerungen, Mouseover-Verhalten, dynamische IDs und Automatisierungsprobleme, die sich aus verborgenen Schichten ergeben.
Basic Calculator bietet ein Objekt mit grundlegenden Funktionen, mit denen Sie Ihren ersten Versuch unternehmen können, Selenium zu verwenden, bereitgestellt von Mike Talks.
Swagger Pet Store ist eine andere Tierhandlung, die von Swagger.io bereitgestellt wird.
https://www.testautomatisierung.org/wp-content/uploads/Software_Demo.png309540Casian Stetihttps://www.testautomatisierung.org/wp-content/uploads/ta5.pngCasian Steti2022-11-16 00:18:232022-11-28 10:29:38Demo Websites und API zum Üben verschiedener Arten von Softwaretests
Diese Website verwendet Cookies, einschließlich Google Analytics. Durch die Nutzung der Website stimmst du der Verwendung von Cookies zu. Die durch Google Analytics generierten Informationen über deine Nutzung der Website können in die USA übertragen und dort gespeichert werden. Weitere Informationen zur Verarbeitung und Speicherung deiner Daten findest du in unserer Datenschutzerklärung.OKNeinDatenschutzerklärung