2.10 Testen der Anwendung
| Einführung | Entwurf | Manuelles/Automatisiertes Testen | Selenium | Cypress | Selektoren |
|
|
Nach der Installation der Anwendung in der eigenen IT-Infrastruktur und der Fertigstellung der Testdateien (Booklet-Xml, Testtaker-Xml, Unit-Xml etc.), sollte die Anwendung getestet werden. Diese Art der Testung nennt sich End-to-end-Testung oder auch Akzeptanztest. Sie soll sicherstellen, dass durch die Installation der Anwendung in der eigenen komplexen IT-Infrastruktur und das Einbringen der individuellen Testdateien, während der Studiendurchführung keine unerwarteteten Fehler auftreten und die Studiendurchführbarkeit somit sichergestellt ist. Vor Veröffentlichung der Anwendung führt das IQB eigene Testungen durch, die die gewünschten Funktionen der Anwendung sicherstellen sollen. Hierzu zählen E2E-Testungen in der eigenen IT-Infrastruktur und Testungen in anderen Phasen des Software-Lebenszyklus. Die hierbei gemachten Erfahrungen möchten wir gerne an dieser Stelle einbringen, um die Endnutzer*innen bei dem Entwurf und der Durchführung ihrer E2E-Testung zu unterstützen. Wie Ihre individuelle E2E-Testung am Ende aussieht, ist natürlich Ihnen überlassen. Wir können an dieser Stelle nur Empfehlungen geben und Ihnen Werkzeuge nennen, die die Arbeit erleichern können. Eine solche Testung nimmt in Planung und Durchführung einige Zeit in Anspruch. Wenn möglich planen Sie diese Zeiträume daher rechtzeitig ein und beginnen Sie ehr früher als später. Es ist davon abzuraten einfach drauf los zu testen. Testungen müssen reproduzierbar sein. Damit wird sichergestellt, dass ein aufgetretener Fehler auch ein zweites Mal provoziert werden kann. Die Reproduzierbarkeit wird mittels detaillierter Dokumentation erreicht. Entwurfphase und entsprechende Vorüberlegungen sind also genauso wichtig, wie die eigentliche Durchführung der Testung. |
|
Bevor eine Testung durchgeführt werden kann, muss klar umrissen werden, welche Funktionen eigentlich geprüft werden sollen. Der Anspruch alle möglichen Fehler aufzudecken, sollte aufgegeben werden. Der zeitliche und personelle Aufwand wäre einfach zu groß. Stattdessen sollten Schwerpunkte gesetzt werden. Nachfolgend ist einmal bsph. aufgeführt, welche Fragen sich die Verantwortlichen im Vorfeld stellen könnten, um diese Schwerpunkte zu definieren.
Sind Schwerpunkte definiert, können weitere Überlegungen angestellt werden:
Im nächsten Schritt können Sie beginnen Ihre gesetzten Schwerpunkte in Testfälle und detaillierte Testschritte umzuwandeln und entsprechend zu dokumentieren. Klären wir kurz die Begriffe Testfall und Testschritt. Testfall/ Testschritt: Ein Testfall ist genau das wonach es klingt: Ein Testszenario welches die Funktionalität einer Reihe von Aktionen oder Bedingungen misst, um das erwartete Ergebnis zu überprüfen. Ein Testfall enthält die einzelnen Testschritte, beginnt meist mit einer knappen Umschreibung und endet mit einer Erwartungsprüfung. Halten Sie Testfälle wenn möglich granular. Vermeiden Sie Testfälle mit einer großen Anzahl von Testschritten. Teilen Sie die Testfälle lieber auf. Dies erhöht die Übersichtlichkeit. Testschritte sollte so atomar wie möglich gehalten werden, um die Abhängigkeit von anderen Testschritten zu minimieren. Vielleicht hilft an dieser Stelle ein sehr vereinfachtes Beispiel weiter, in diesem Fall mit dem Framework: Selenium und der Programmiersprache JavaScript: //Testfall Beispiel
describe('Check Google', function () {
//1. Schritt: Prüfe ob Google geladen werden kann
it('Öffne Google Seite', async function () {
//Erzeuge Webdriver Instanz für diesen Testschritt
let driver = await new Builder().forBrowser("chrome").build();
//Versuche die Website zu laden.
await driver.get("http://google.com");
//Erwartungsprüfung: Wenn die Seite geladen wurde,
//wird ein bestimmter Title der Seite erwartet
var title = await driver.getTitle();
assert.equal(title, "Google", "Error: Seitenladefehler.");
//Schliesse Webdriver Instanz
await driver.quit();
});
//2. Schritt: Tue noch etwas auf der Google Seite
it('Tue noch etwas...', async function () {
//Erzeuge Webdriver Instanz für diesen Testschritt
let driver = await new Builder().forBrowser("chrome").build();
//tue etwas....
//Schliesse Webdriver Instanz
await driver.quit();
});
});Wie zu sehen ist, kann eine solche Testung schnell groß und komplex werden. Es ist daher entscheidend im Vorfeld eine gute Planung vorzunehmen und Prioritäten zu setzen. |
|
Sind die Testszenarien entworfen und festgehalten, muss im nächsten Schritt überlegt werden wie getestet werden soll. Es kann manuell oder automatisiert getestet werden. Es kann an dieser Stelle keine pauschale Empfehlung gegeben werden, da es von vielen individuellen Faktoren abhängt. Beides hat Vor- und Nachteile. Nachfolgend wird eine kurze Gegenüberstellung aufgezeigt, die Ihnen vielleicht hilft hinsichtlicht dieser Frage eine Entscheidung zu treffen. ℹ️ Die Anwendung enthält bereits automatisierte Testfälle. Hiermit werden Grundfunktionen der Anwendung automatisiert getestet. Diese Testungen werden vor jeder Veröffentlichung einer neuen Version IQB-seitig durchgeführt. Es steht Ihnen frei diese zu nutzen. Bei Interesse helfen wir Ihnen gerne diese Testfälle auszuführen.
ℹ️ Es sei an dieser Stelle erwähnt, dass es auch für das manuelle Testen Anbieter gibt, die das Organisieren von Testskripten vereinfachen. Somit können viele Einzeldokumente bspw. mittels Word oder Excel vermieden werden. Hier sind einmal bspw. Testomat.io und Testbench genannt. Beide Anbieter bieten freie Zugänge an, die für kleinere Testungen ausreichend sind.
Haben Sie sich für das automatisierte Testen entschieden, können wir Ihnen nachfolgend Software vorstellen, die Sie für den Testentwurf und zur Testdurchführung nutzen können. Der Markt für Software zum automatisierten E2E-Testen ist riesig und jeder Anbieter hat Vor- und Nachteile. Da auch das IQB automatisierte Testungen einsetzt, können wir an dieser Stelle nur unsere persönlichen Erfahrungen einbringen und Empfehlungen abgeben. Letztlich müssen Sie entscheiden, welche Anwendung bei Ihnen zum Einsatz kommen soll. Das IQB empfiehlt an dieser Stelle entweder Selenium oder Cypress zu verwenden. Im folgenden Abschnitt werden die beiden Anwendungen einmal näher vorgestellt. |
|
Selenium ist ein alter Hase in der Softwaretestung. Hier gibt es unzählige Foren, Tutorials etc.. Selenium führt Testungen mittels einer speziellen Browserschnittstelle gegen den Browser durch. Selenium spricht hier von einem Treiber. Es ist dann als würde eine Person vor dem Browser sitzen und die Testungen durchführen. Der große Vorteil von Selenium ist, dass es sowohl von techn. versierten als auch von techn. weniger versierten Anwender*innen angewendet werden kann. Hierfür wird Selenium in Module aufgeteilt angeboten:
Hier der Link zur Auswahlseite. Interessant sind in diesem Fall die Module Selenium-IDE und Selenium-Webdriver. |
|
Alle Informationen zu Selenium-IDE finden Sie hier Dieses Modul richtet sich an techn. weniger versierte Anwender*innen. Es handelt es sich um ein Plugin, welches dem Browser hinzugefügt wird. Mithilfe dieses Plugins können Testschritte aufgezeichnet werden. Dazu wird ein Rekorder verwendet, der jedes Event auf einer Website aufzeichnen und anschließend wieder abspielen kann. Ein auf diese Weise entworfener Testfall kann gespeichert werden und in einem anderen Browser mittels vorheriger Plugininstallation wieder abgespielt werden. Der Rekorder verwendet für die Aufzeichnung Selektoren und Befehle. Um Elemente, wie bspw. einen Button auf einer Seite zu finden, muss das entsprechende Element irgendwie selektiert werden. Anschließend kann auf dieses selektierte Element ein Befehl abgesetzt werden. Beispielsweise könnte ein Pro
Contra
|
|
Die Selenium-Webdriver Dokumentation finden Sie hier. Diese Modul ist ehr geeignet für Anwender*innen die techn. versiert sind und auch vor einer Programmiersprache nicht zurückschrecken. Folgende Programmiersprachen werden angeboten:
Testfälle können dann in dieser Programmiersprache verfasst ausgeführt werden. Hierfür wird eine entsprechende Umgebung benötigt. Diese Umgebung hat das IQB in Form eines Repository bei GitHub bereits eingerichtet. Unter entsprechender Anleitung in diesem Repositiory können Sie diese Umgebung verwenden, um ihre Testfälle anzulegen und diese zu starten. Sie können mittels bestimmter Befehle die Testung gegen lokal installierte Browser und auch gegen emulierte Browser auf emulierten Geräten ausführen. Die verwendete Programmiersprache ist in diesem Fall Javascript. Um gegen emulierte Geräte testen zu können, wird die Plattform Browserstack verwendet. Pro
Contra
ℹ️ Wie bereits unter Contra erwähnt müssen Wartebedingungen bei Selenium eigenständig angelegt werden. Wird bspw. ein Element abgefragt, welches nicht sofort sichtbar (Seite wird noch geladen etc.), muss an dieser Stelle im Testschritt expilizit gewartet werden. Es gibt auch die Möglichkeit implizite Wartezeiten zu implementieren. Diese werden dann für jeden Testschritt angewendet. Beides, sowohl explizites als auch implizites Warten haben Vor- und Nachteile mit denen man sich im Vorfeld befassen sollte. Wird an entsprechenden Stellen die Einrichtung solcher "Waits" vergessen, schlägt die Testung fehl, weil bspw. ein erwartetes Element nicht sofort gefunden wird. Mehr Informationen zum expliziten und impliziten Warten finden Sie hier zu finden. Abschließend noch ein Bsp. wie ein einfacher Testfall in SE-Webdriver aussehen kann (Javascript): //Testfall Beispiel
describe('Check Google', () => {
//1.Testschritt: Prüfe ob Google geladen werden kann
it('Öffne Google', () => {
//Öffne Seite
cy.visit(`www.google.com`);
//Erwartungsauswertung: Konnte Seite gelade werden,
//dann sollte sie "Google" enthalten
cy.contains('Google')
.should('exist');
});
//2.Testschritt: Tue noch etwas auf der Google Seite
it('Öffne Google', () => {
//Tue etwas....
});
}); |
|
Die Cypress Dokumentation ist hier zu finden. Cypress ist noch nicht so lange in der Welt des Testens unterwegs, wird aber aufgrund seiner Beliebtheit bereits großflächig eingesetzt. Cypress richtet sich eigentlich ehr an Entwickler*innen unterscheidet sich aber bzgl. benötigter Kompetenzen kaum von Selenium-Webdriver. Cypress arbeitet prinzipiell etwas anders als Selenium. Hier wird der programmierte Testcode direkt im Browser durchgeführt. Es wird also nicht wie bei Selenium ein entsprechender Treiber für den jeweiligen Browser benötigt. Es entsteht also keine zusätzliche Fehlerquelle (Flaschenhals) durch eine zusätzliche Schnittstelle (Treiber) zum Browser. Cypress unterstütz im Vergleich zu Selenium nicht alle Browser und Endgeräte. Es werden nur die folgenden Browser unterstützt:
ℹ️ Browser auf mobilen Endgeräten werden derzeitig nicht unterstützt! Testfälle können in den Sprachen: Javascript und Typescript verfasst ausgeführt werden. Hierfür wird eine entsprechende Umgebung benötigt. Diese Umgebung hat das IQB in Form eines Repository bei GitHub bereits eingerichtet. Unter entsprechender Anleitung in diesem Repositiory können Sie diese Umgebung verwenden, um ihre Testfälle anzulegen und diese zu starten. Sie können mittels bestimmter Befehle die Testung gegen lokal installierte Browser und auch gegen emulierte Browser auf emulierten Geräten ausführen. Die verwendete Programmiersprache ist in diesem Fall Javascript. Um gegen emulierte Geräte testen zu können, wird die Plattform Browserstack verwendet. Pro
Contra
Abschließend ein Beispiel wie ein Testfall mit Cypress aussieht (Javascript):
|
|
Für welche Software Sie sich entscheiden, hängt nun maßgeblich davon ab mit welchen Endgeräten und Browsern Sie testen wollen. Soll es nur Firefox, Chrome, Edge und Electron auf den Betriebssystemen Windows oder Linux sein, würden wir Cypress empfehlen. Cypress ist übersichtlicher, es müssen keine Wartebedingungen programmiert werden und es wird kein zusätzlicher Treiber für den Browser benötigt. Müssen Sie gegen Browser auf mobilen Endgeräten testen, fällt Cypress aus der Auswahl. Ebenso verhält es sich bei Apples Safari-Browser. In diesen Fällen kommen Sie um Selenium nicht herum, auch wenn es etwas sperriger ist als Cypress. |
|
Um ein Element auf einer Website zu lokalisieren, können sowohl bei Cypress als auch bei Selenium CSS-Selektoren oder XPath-Selektoren verwendet werden. Richtig gewählte Selektoren bestimmen wie schnell und zuverlässig ein Element bei einer Testung gefunden wird. Damit es Ihnen möglich ist, den richtigen Selektor hinsichtlich Schnelligkeit und Zuverlässigkeit zu finden, soll an dieser Stelle der Unterschied zwischen den beiden Selektoren aufgezeigt werden. Eine Website besteht aus unterschiedlichen HTML-Elementen wie bspw. Textfeldern, Eingabefeldern, aber auch Bereichen und vielen weiteren. Um Einfluss auf das Layout dieser Elemente zu nehmen, kommt die Gestaltungs- und Formatierungssprache CSS (Cascading Stytle Sheet) zum Einsatz. Ein CSS-Layout wird auf ein HTML-Element mittels eines Selektors angewendet. Über diesen Selektor erfolgt eine eindeutige Zuweisung des Layouts zu einem bestimmten Html-Element. Dabei kann der CSS-Selektor das Html-Element auf viele unterschiedliche Arten selektieren. Es gibt Typen-, Klassen-, ID-, Attribut-Selektoren und einige weitere. Da der Programmcode der Anwendung Testscenter Änderungen unterliegt (Fehlerbehebung, Layoutänderungen, Neuerungen etc.), müssen die Selektoren auch nach diesen Änderungen noch zuverlässig arbeiten. Wird ein ungünstiger CSS-Selektor gewählt, kann es passieren, dass dieser Selektor bspw. nach einer programmseitigen Layoutänderung nicht mehr funktioniert. Dann muss mühselig der Testcode angepasst werden, um Testabbrüche zu vermeiden. Nachfolgend sind daher einmal die zu bevorzugenden Selektoren aufgezählt:
XPath stellt eine andere Möglichkeit der Selektierung von Html-Elementen dar. Jede Html-Seite wird vom Browser mittels eines Parsers in eine spezielle Baumstruktur überführt. Diese Baumstruktur nennt sich DOM (Document Object Model). Mittels dieser Struktur kann bspw. Javascript auf einzelne Elemente zugreifen. Mit Hilfe von XPath können einzelne Elemente im DOM selektiert werden. In einer Baumstruktur gibt es Eltern und Kinderlemente, also Elemente die von anderen Elementen abhängen. Um eine Element mittels XPath zu selektieren, müssen diese Abhängigkeiten einbezogen werden. Befindet sich ein Element in tieferen DOM-Ebenen, nimmt die Suche längere Zeit in Anspruch. Außerdem ist XPath gegenüber Änderungen am DOM empfindlich. Ändert sich bspw. ein Elternelement, kann eventuell das in einer Testung verwendete Kinderelement nicht mehr gefunden werden. Nach jeder Änderungen in der Programmierung (neues Release) kann es also passieren, dass XPath-Selektoren im Testcode angepasst werden müssen. ℹ️ XPath-Selektoren sollten nur zum Einsatz kommen, wenn keine geeigneten CSS-Selektoren gefunden werden! Um den geeigneten Selektoren zu finden, sollte die Browser Entwicklerkonsole verwendet werden. In den Browsern Firefox, Chrome und Edge wird die Konsole mittels der Taste F12 aufgerufen. Die Konsole bietet sehr viele unterschiedliche Funktionen. Nachfolgend ist zu sehen, wie die Konsole zum Auffinden von Selektoren nach Betätigung von F12 verwendet wird.
Den angezeigten Informationen können wir nun die entsprechenden Attribute wie bspw. ID oder Data entnehmen und als CSS-Selektor in unserem Test verwenden. Dieses Element weist bspw. ein Data-Attribut auf. Dieses könnte nun direkt im Test verwendet werden.
Sollten Sie kein geeignetes Attribut finden können, klicken sie mit der rechten MT auf die markierten Informationen und anschließend auf "Kopieren". Es öffnet sich eine weitere Auswahl. ℹ️ Die nachfolgenden Methoden zur Selektorfindung sollten nur angewendet werden, wenn kein ID- und kein Data-Attribut vorhanden ist.
Die folgenden Kopieroptionen sind entscheidend und werden nachfolgend näher beschrieben:
|
|
|
|