Cloud Performance Testing Tools

Die 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.

Weiterlesen

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.

Beispielprogramm – Setup

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.

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.

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.

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:

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.

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:

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
Stryker konfigurieren

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.

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…).

Lizenzierte Performance Testing Tools

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:

  • Benutzeranzahl: Lizenz zum Generieren einer bestimmten Anzahl von Last Benutzer
  • Protokoll: Protokollspezifische Lizenz
  • Zeitraum: Lizenz für einen bestimmten Zeitraum

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.

Vorteile:

  • Umfangreiche Protokollunterstützung
  • Ein spezielles Support-Team steht normalerweise zur Verfügung
  • Normalerweise gutes Knowledge Base und Community
  • Weniger Herausforderungen bei der Skripterstellung als bei Open-Source-Tools
  • Benutzerfreundliche und einfache GUI
  • Unterstützt erweiterte Skriptaufzeichnung
  • Viele Tools unterstützen lokale und Cloud-Infrastrukturen
  • Einfache Integration mit Monitoren  und Profilers Tools
  • Live-Monitoren des Tests
  • Mehr Genauigkeit im Ergebnis
  • Funktion zur detaillierten Ergebnisanalyse
  • Gute Berichtsfunktion
  • Das Vertrauen des Kunden

Nachteile

  • Lizenzkosten
  • Meistens Betriebssystem spezifisch
  • Meistens ist die Installation schwieriger als bei Open-Source-Tools
  • Etwas schwierig, auf die neue Versionen zu aktualisieren
  • Sehr wenig oder keine Anpassung
  • Meistens für Für die ON Premise Version ist Hardware erforderlich
  • Die Generierung der Last Benutzer ist auf Lizenzen mit Benutzeranzahl beschränkt. Es kann das Benutzerlimit nicht überschreiten, obwohl die Hardware verfügbar ist.
  • Die Migration von einem Tool zum anderen ist nicht einfach. Es braucht Zeit, Geld und Mühe.

 

Top Lizenzierte Performance Testing Tools

  • LoadRunner 
  • Microfocus Performance Center
  • NeoLoad
  • SoapUI /LoadUI
  • Radview WebLOAD
  • SmartMeter.io
  • SmartBear LoadNinja
  • IBM Rational Performance Tester
  • WAPT
  • StressStimulus
  • AppLoader
  • Appvance.ai

VERWANDTE BEGRIFFE

 

Open Source Performance Testing Tools

Open 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.

 

 

 

Vorteile:

  • Keine Lizenzkosten
  • Die meisten sind Plattform unabhängig(laufen auf jedem Betriebssystem)
  • einfach zu installieren und einfach aufzurüsten
  • keiner explizites Hardware erforderlich, es sei denn, die Benutzerlast ist zu hoch
  • Unbegrenzte Benutzerlastgenerierungsfunktion (abhängig von der Lasterzeuger-Maschinenkonfiguration)
  • Benutzerfreundliche und einfache GUI
  • Die meisten Tools unterstützen die Skriptaufzeichnung
  • Meistens die grundlegenden Funktionen sind verfügbar
  • Meistens die Migration von einem Open-Source-Tool zu einem anderen Tool ist einfach (aber nicht in allen Fällen)

Nachteile

  • Begrenzte Protokollunterstützung
  • Kein dediziertes Support-Team
  • Skriptherausforderungen für komplexe Szenarien
  • Eingeschränkte Plugin-Unterstützung
  • Mangel an erweiterten Funktionen
  • Integration nur mit spezifischem Monitoren Tools
  • Programmiersprache Abhängigkeit(z.B. Beanshell, Groovy) für komplexe Logik
  • Fehlende Berichtsfunktion
  • Einschränkung der eingehenden Analyse

 

Top Open Source Performance Testing Tools

VERWANDTE BEGRIFFE

 

Übersicht

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.
  • JPetStore Demo ist ein von OctoPerf (Cloud SaaS Performance Testing) bereitgestelltes Testsystem. Wie der Name schon sagt, handelt es sich um eine Demo-Tierhandlung mit verschiedenen Angeboten, Filtern usw.
  • 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.
  • GlobalsQA  
  • Bank App(Parasoft) 
  • Advance UI Flows 
  • E2E Booking Web App(Katalon) 
  • Ultimate QA  -Formulare, Zielseite, Seiteninteraktionen
  • Basic Address Book  
  • CRM  
  • Telerik Demos  -SPAs, JQuery Seiten, andere komplexe UIs
  • App VWO  -Erweiterte Mausbewegung, Aktion, Frame Switch 
  • Magento Store 
  • React Shoping Cart
  • Cypress Real World App
  • ACME demo Banking(Applitools)
  • Restfull Booker
  • Compendium
  • Conduit (Angular)
  • OpenUI5

 

Public API Liste

 

Verwandte Themen

Übersicht

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.

Swagger und OpenAPI

Abb. 2 - SwaggerLogo

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.

Postman

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:

  • Einsatz von Test-Collections – Hilfe bei der Organisation von Test-Suites, durch Strukturierungsmöglichkeiten innerhalb abgeschlossener Test-Collections durch Unterordner und multiple Requests.
  • Kollaboration – Es können mehrere Personen an einer Testsuite arbeiten, einmal durch den manuellen Import/Export aber auch durch die Verwendung von Repositories (Premium Version)
  • Environments – Es ermöglicht uns verschiedene Test-Umgebungen zu definieren und diese auf Test-Collections anzuwenden.
  • Debugging – Die Postman Konsole hilft bei der Fehleranalyse
  • CICD – Eine Integration in CICD Pipelines wird unterstützt. Hier sei vor allem das Kommandozeilentool Newman erwähnt, das in der CICD Automatisierung Verwendung findet.

Swagger Specification

Schauen wir uns exemplarisch eine REST-API in der Swagger-UI an:

Abb. 3 - SwaggerUI

Abb. 2 – SwaggerUI

oder die API-Docs die aus der Schnittstelle generiert werden:

Abb. 4 – Swagger Docs

Abb. 3 – Swagger Docs

Swagger Imports in Postman

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.

Import via Datei (z.B. JSON)

Wir wollen eine Textdatei, im JSON Format, hochladen die in etwa wie folgt aussieht:

Abb. 5 – Datei Import

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 6 – Postman Scratch Pad

Abb. 5 – Postman Scratch Pad

 

Der folgende Dialog gibt uns verschiedene Auswahlmöglichkeiten, wir wählen „File“ und „Upload Files“:

Abb 7 – Postman File-Import Dialog

Abb. 6 – Postman File-Import Dialog

 

Im nächsten Dialog bestätigen wir mit „Import“:

Abb 8 – Postman File-Import Dialog (2)

Abb. 7 – Postman File-Import Dialog (2)

 

Wie wir in Abbildung 9 sehen, wird eine Projektstruktur in Reiter Collections angelegt.

Abb 9 – Postman Test-Collection

Abb. 8 – Postman Test-Collection

Import via Link zur Swagger Spezifikation

Hier wählen wir im Import Dialog die Option „Link“ und bestätigen mit „Continue“.

Abb 10 – Postman Import via Link

Abb. 9 – Postman Import via Link

 

Im folgenden Dialog bestätigen wir mit Import.

Abb 11 – Postman Import via Link (2)

Abb. 10 – Postman Import via Link (2)

 

Im Folgenden sehen wir, dass eine weitere Collection angelegt wurde, die der Ersten entspricht.

Abb 12 – Postman Test Collection (2)

Abb. 11 – Postman Test Collection (2)

Import via Raw-Text

Wir können aber auch einfach den Text (JSON) in den Postman Dialog kopieren und importieren.

Abb 13 – Postman Import via Raw-Text

Abb. 12 – Postman Import via Raw-Text

 

Vorbereitungs und Testroutinen

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 14 – Postman Testscripts

Abb. 13 – Postman Testscripts

 

Abb 15 – Postman Vorbereitungs-Skripte

Abb. 14 – Postman Vorbereitungs-Skripte

 

Import aus Code-Repository

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.

 

Verwandte Themen

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:

Einige Features, die JetBrains Aqua bietet

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.

New Project Wizard

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.

Neues Projekt anlegen

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.

Neues Projekt anlegen – zusätzliche Abhängigkeiten

Page Object Templates

Ü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.

Hinzufügen eines neuen Page Objects

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:

Ein neuangelegtes Page Object

Web-Inspektor

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:

Web-Inspektor in der IDE mit Highlight Syntax

Über das „+„-Symbol werden DOM-Elemente aus dem Web-Inspektor direkt als Variable in der Page Object Klasse angelegt:

Anlegen eines Locators und die dazugehörige Page Object Variable

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:

Falsche XPath-Syntax

Test Management Systems und Issue Tracker

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.

Issue Link über die Annotation @TmsLink

API Testing mit integriertem HTTP-Client

Dank des integrierten HTTP-Clients lassen sich HTTP-Requests verschicken und empfangen. Die Code Completion erspart uns ihrerseits eine Menge Arbeit.

Kleiner Auschnitt aus einer HTTP-Request-Datei

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) :

Antwort der obigen HTTP-Anfrage

Datenbanken

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.

Weiterentwicklung von Aqua

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.

SOFTWARE QS-TAG 2022 REINVENTING QUALITY

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

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