Was ist Automatisierungstests (Ultimativer Leitfaden zum Start der Testautomatisierung)

Ein vollständiger Leitfaden zum Start von Automatisierungstests für Ihr Projekt:

Was sind Automatisierungstests?

Automatisierungstests sind eine Softwaretesttechnik, um das tatsächliche Ergebnis mit dem erwarteten Ergebnis zu vergleichen. Dies kann durch das Schreiben von Testskripten oder durch den Einsatz eines Automatisierungstools erreicht werden. Testautomatisierung wird verwendet, um sich wiederholende Aufgaben und andere Testaufgaben zu automatisieren, die manuell nur schwer durchzuführen sind.

Möchten Sie mit der Testautomatisierung für Ihr Projekt beginnen, haben aber Probleme mit den unten aufgeführten grundlegenden Schritten:

• Wie führt man die Automatisierung in seinem Projekt ein?
• Wie wählt man das beste und richtige Automatisierungstool aus?
• Wie entwickelt man effektiv Skripte?
• Wie führt man Testskripte aus und pflegt sie?
• Und was sind schließlich die besten Praktiken, die Sie für erfolgreiche Automatisierungstests befolgen müssen?

Heute haben wir geplant, Ihr Wissen mit einer Reihe von Tutorials zum Thema „Erste Schritte mit Automatisierungstests“ zu erweitern. Diese Serie von Automatisierungs-Tutorials wird alle oben genannten Fragen Schritt für Schritt mit einfachen Beispielen beantworten.

Lassen Sie uns einen Blick auf die Serie von Tutorials zum Start der Automatisierung in Ihrem Projekt werfen!!!

Automation End-to-End Prozess:

Tutorial #1: Bester Leitfaden zum Start der Automatisierung in Ihrem Projekt
Tutorial #2: Arten von automatisierten Tests und einige Missverständnisse
Tutorial #3: 10 Schritte zur Einführung der Automatisierung in Ihrem Projekt
Tutorial #4: Der A bis Z Leitfaden zur Auswahl des besten Automatisierungstools
Tutorial #5: Skriptentwicklung und Automatisierungsframeworks
Tutorial #6: Durchführung und Reporting der Automatisierung
Tutorial #7: Best Practices und Strategien der Testautomatisierung

Automatisierungstipps:

Tutorial #8: 10 Tipps, die Sie lesen sollten, bevor Sie Ihre Testarbeit automatisieren
Tutorial #9: Wie unterscheidet sich die Testplanung für manuelle und automatisierte Projekte
Tutorial #10: Wann sollte man sich für die Automatisierung entscheiden?
Tutorial #11: Herausforderungen bei Automatisierungstests
Tutorial #12: Anleitung zur Implementierung von Proof of Concept (POC) in der Automatisierung
Tutorial #13: Wie man die richtigen Testfälle für die Automatisierung auswählt
Tutorial #14: Wie man manuelle Testfälle in Automatisierungsskripte übersetzt

Karriere in der Automatisierung:

Tutorial #15: Tipps, um ein besserer Automatisierungstester zu werden
Tutorial #16: Testautomatisierung – ist es ein spezialisierter Beruf? Können normale Tester auch automatisieren?

Populäre Automatisierungstools:

Tutorial #17: Selenium Tutorials 31+ Beste kostenlose Selenium Training Tutorials
Tutorial #18: QTP-Tutorials
Tutorial #19: SoapUI Web Services Testing Tool
Tutorial #20: HP LoadRunner for Performance Testing

Automation Frameworks:

Tutorial #21: Warum brauchen wir Frameworks für die Automatisierung
Tutorial #22: Die beliebtesten Automatisierungs-Frameworks

Automatisierung in der agilen Welt:

Tutorial #23: Wie man effiziente Automatisierung in der agilen Welt implementiert

Andere Automatisierungstools:

Tutorial #24: Die besten Automatisierungstest-Tools
Tutorial #25: Sikuli GUI Automation Tool
Tutorial #26: PowerShell: Desktop Application UI Automation With PowerShell
Tutorial #27: Katalon Automation Recorder (Selenium IDE Alternative)
Tutorial #28: Geb Tool: Browser-Automatisierung mit Geb Tool
Tutorial #29: AutoIt: Wie man Windows-Pop-ups mit AutoIt handhabt
Tutorial #30: Cucumber: Automatisierung mit Cucumber Tool und Selenium
Tutorial #31: Protractor Testing Tool für End-to-End Testing von AngularJS Anwendungen

Mobile Automation Testing:

Tutorial #32: Appium Studio Hands-on Tutorial
Tutorial #33: Appium Tutorial für Einsteiger
Tutorial #34: Selendroid Tutorial: Android Mobile Automation Framework
Tutorial #35: Ranorex Tutorial: Ein leistungsfähiges Desktop-, Web- und Mobile-Testing-Tool

Domänenspezifische Automatisierungsbeispiele:

Tutorial #36: Automatisierung von JAVA/J2EE-Anwendungen

Interview-Vorbereitung für Automatisierungsjobs:

Tutorial #37: Automatisierungs-Testing-Interview-Fragen
Tutorial #38: Selenium-Interview-Fragen

Lassen Sie uns das erste Tutorial aus der Reihe „The Ultimate Guide to Automation Testing“ erkunden!!

Was ist Automation Testing?

Wenn eine Software alles kann, warum kann eine Software dann nicht auch eine Software testen?

Hört sich diese Aussage für Sie logisch an?

Wenn ja, dann herzlichen Glückwunsch, Sie denken jetzt über Testautomatisierung nach, um die es in dieser Reihe informativer Tutorials gehen wird.

Stellen Sie sich Ihren ersten Arbeitstag als SQA vor. Ihnen wird eine zu testende Anwendung vorgelegt. Es handelt sich um eine ERP-Anwendung mit Hunderten von Formularen und Tausenden von Berichten. Sie beginnen Ihre Erkundungstests, indem Sie ein Formular öffnen, das etwa 50 verschiedene Felder enthält.

Sie versuchen, zufällige Daten in dieses Formular einzugeben, was etwa 20 Minuten dauert. Dann drücken Sie auf Absenden. Wolla!!! Es wird eine Fehlermeldung angezeigt, die wie eine unbehandelte Ausnahme aussieht. Sie sind sehr glücklich. Stolz notieren Sie sich die Schritte und melden den Fehler in Ihrem Fehlerverwaltungssystem. Eine großartige Leistung, Sie fühlen sich sehr zuversichtlich und energiegeladen. Sie setzen die Tests bis zum Ende des Tages fort und finden noch einige Fehler. „Ein toller erster Tag“, dachten Sie.

Nun kommt der nächste Tag, der Entwickler hat das Problem behoben und veröffentlicht eine neue Version des Builds. Sie testen das gleiche Formular mit den gleichen Schritten und stellen fest, dass der Fehler behoben ist. Sie markieren ihn als behoben. Großer Aufwand. Sie haben zur Qualität des Produkts beigetragen, indem Sie den Fehler identifiziert haben, und da dieser Fehler behoben ist, wird die Qualität verbessert.

Nun kommt der dritte Tag, ein Entwickler hat wieder eine neuere Version veröffentlicht. Jetzt müssen Sie das Formular erneut testen, um sicherzustellen, dass kein Regressionsproblem gefunden wird. Dieselben 20 Minuten. Jetzt fühlen Sie sich ein wenig gelangweilt.

Stellen Sie sich vor, dass von nun an einen Monat lang ständig neue Versionen veröffentlicht werden und Sie bei jeder Veröffentlichung dieses langwierige Formular und 100 weitere Formulare dieser Art testen müssen, nur um sicherzustellen, dass es keine Regression gibt.

Jetzt fühlen Sie sich wütend. Sie fühlen sich müde. Sie fangen an, Schritte auszulassen. Sie füllen nur etwa 50 % aller Felder aus. Ihre Genauigkeit ist nicht mehr dieselbe, Ihre Energie ist nicht mehr dieselbe und Ihre Schritte sind definitiv nicht mehr dieselben.

Und eines Tages meldet der Kunde denselben Fehler in demselben Formular. Sie fühlen sich erbärmlich. Sie fühlen sich jetzt unsicher. Sie denken, Sie seien nicht kompetent genug. Manager stellen Ihre Fähigkeiten in Frage.

Ich habe eine Neuigkeit für Sie; dies ist die Geschichte von 90% der manuellen Tester da draußen. Sie sind nicht anders.

Regressionsprobleme sind die schmerzhaftesten Probleme. Wir sind Menschen. Und wir können nicht jeden Tag dieselbe Aufgabe mit derselben Energie, Geschwindigkeit und Genauigkeit erledigen. Das ist es, was Maschinen tun. Dafür braucht man die Automatisierung, um die gleichen Schritte mit der gleichen Geschwindigkeit, Genauigkeit und Energie zu wiederholen, wie beim ersten Mal.

Ich hoffe, Sie verstehen, worauf ich hinaus will!

Wann immer eine solche Situation auftritt, sollten Sie Ihren Testfall automatisieren. Testautomatisierung ist Ihr Freund. Sie hilft Ihnen, sich auf neue Funktionen zu konzentrieren, während Sie sich um die Regressionen kümmern. Mit der Automatisierung können Sie dieses Formular in weniger als 3 Minuten ausfüllen.

Das Skript füllt alle Felder aus und teilt Ihnen das Ergebnis zusammen mit Screenshots mit. Im Falle eines Fehlers kann es die Stelle lokalisieren, an der der Testfall fehlgeschlagen ist, und Ihnen so helfen, ihn mit Leichtigkeit zu reproduzieren.

Automatisierung – eine kostengünstige Methode für Regressionstests

Die Kosten für die Automatisierung sind anfangs wirklich höher. Sie umfassen die Kosten für das Tool, dann die Kosten für die Automatisierungs-Testressource und deren Schulung.

Aber wenn die Skripte fertig sind, können sie Hunderte von Malen wiederholt mit der gleichen Genauigkeit und ziemlich schnell ausgeführt werden. Dadurch werden viele Stunden manueller Tests eingespart. So sinken die Kosten allmählich, und schließlich wird es zu einer kosteneffektiven Methode für Regressionstests.

Szenarien, die eine Automatisierung erfordern

Das obige Szenario ist nicht der einzige Fall, in dem Sie Automatisierungstests benötigen. Es gibt mehrere Situationen, die nicht manuell getestet werden können.

Zum Beispiel,

1. Vergleich zweier Bilder Pixel für Pixel.
2. Vergleich zweier Tabellenkalkulationen mit Tausenden von Zeilen und Spalten.
3. Testen einer Anwendung unter der Last von 100.000 Nutzern.
4. Performance-Benchmarks.
5. Testen der Anwendung auf verschiedenen Browsern und auf verschiedenen Betriebssystemen parallel.

Diese Situationen erfordern und sollten mit Tools getestet werden.

Wann also automatisieren?

In der Ära der agilen Methodik im SDLC, in der die Entwicklung und das Testen fast parallel verlaufen, ist es sehr schwierig zu entscheiden, wann automatisiert werden soll.

Betrachten Sie die folgenden Situationen, bevor Sie in die Automatisierung einsteigen

• Das Produkt kann sich in seinen primitiven Stadien befinden, wenn das Produkt noch nicht einmal eine Benutzeroberfläche (UI) hat, in diesen Stadien müssen wir einen klaren Gedanken darüber haben, was wir automatisieren wollen. Die folgenden Punkte sollten beachtet werden.
  • Tests sollten nicht veraltet sein.
  • Wenn sich das Produkt weiterentwickelt, sollte es einfach sein, die Skripte zu übernehmen und zu ergänzen.
  • Es ist sehr wichtig, sich nicht zu verzetteln und dafür zu sorgen, dass die Skripte leicht zu debuggen sind.
• Versuchen Sie nicht, die UI-Automatisierung in der Anfangsphase durchzuführen, da die UI häufigen Änderungen unterworfen ist, was dazu führt, dass die Skripte nicht funktionieren. Entscheiden Sie sich so weit wie möglich für eine Automatisierung auf API-Ebene/Nicht-UI-Ebene, bis sich das Produkt stabilisiert hat. API-Automatisierung ist einfach zu beheben und zu debuggen.

Wie entscheidet man über die besten Automatisierungsfälle:

Automatisierung ist ein integraler Bestandteil eines Testzyklus und es ist sehr wichtig zu entscheiden, was wir mit der Automatisierung erreichen wollen, bevor wir uns für die Automatisierung entscheiden.

Die Vorteile, die die Automatisierung zu bieten scheint, sind sehr attraktiv, aber gleichzeitig kann eine schlecht organisierte Automatisierungssuite das ganze Spiel verderben. Die Tester müssen die meiste Zeit mit dem Debuggen und Reparieren der Skripte verbringen, was zu einem Verlust an Testzeit führt.

In dieser Serie erfahren Sie, wie eine Automatisierungssuite so effizient gestaltet werden kann, dass sie die richtigen Testfälle aufgreift und mit den vorhandenen Automatisierungsskripten die richtigen Ergebnisse liefert.

Außerdem habe ich die Antworten auf Fragen wie „Wann automatisieren?“, „Was automatisieren?“, „Was nicht automatisieren?“ und „Wie kann man die Automatisierung strategisch planen?“

Die richtigen Tests für die Automatisierung

Der beste Weg, dieses Problem anzugehen, ist, sich schnell eine „Automatisierungsstrategie“ auszudenken, die zu unserem Produkt passt.

Die Idee ist, die Testfälle so zu gruppieren, dass jede Gruppe eine andere Art von Ergebnis liefert. Die folgende Abbildung zeigt, wie wir unsere ähnlichen Testfälle gruppieren können, je nach dem Produkt/der Lösung, das/die wir testen.

Lassen Sie uns nun in die Tiefe gehen und verstehen, was jede Gruppe uns helfen kann zu erreichen:

#1) Erstellen Sie eine Testsuite mit allen grundlegenden Funktionen, die positiv getestet werden. Diese Suite sollte automatisiert werden, und wenn diese Suite gegen ein beliebiges Build ausgeführt wird, werden die Ergebnisse sofort angezeigt. Jedes Skript, das in dieser Suite fehlschlägt, führt zu einem S1- oder S2-Fehler, und der betreffende Build kann disqualifiziert werden. So haben wir hier eine Menge Zeit gespart.

Als zusätzlichen Schritt können wir diese automatisierte Testsuite als Teil der BVT (Build Verification Tests) hinzufügen und die QA-Automatisierungsskripte in den Produktentwicklungsprozess einbinden. Wenn der Build fertig ist, können die Tester die Ergebnisse der Automatisierungstests prüfen und entscheiden, ob der Build für die Installation und den weiteren Testprozess geeignet ist oder nicht.

Damit werden die Ziele der Automatisierung klar erreicht, die da lauten:

• Reduzierung des Testaufwands.
• Finden von Fehlern in früheren Stadien.

#2) Als nächstes haben wir eine Gruppe von End-to-End-Tests.

Bei großen Lösungen ist das Testen einer End-to-End-Funktionalität der Schlüssel, besonders in den kritischen Phasen des Projekts. Wir sollten ein paar Automatisierungsskripte haben, die auch die End-to-End-Tests der Lösung betreffen. Wenn diese Suite ausgeführt wird, sollte das Ergebnis zeigen, ob das Produkt als Ganzes so funktioniert, wie es erwartet wird oder nicht.

Die Automationstest-Suite sollte angezeigt werden, wenn eines der Integrationsstücke defekt ist. Diese Suite muss nicht jedes kleine Feature/jede kleine Funktionalität der Lösung abdecken, aber sie sollte das Funktionieren des Produkts als Ganzes abdecken. Wann immer wir eine Alpha- oder Beta-Version oder andere Zwischenversionen haben, sind solche Skripte nützlich und geben dem Kunden ein gewisses Maß an Vertrauen.

Zum besseren Verständnis nehmen wir an, dass wir ein Online-Einkaufsportal testen, als Teil der End-to-End-Tests sollten wir nur die wichtigsten Schritte abdecken.

Wie unten angegeben:

• Benutzeranmeldung.
• Browsen und Artikel auswählen.
• Zahlungsoption – dies deckt die Front-End-Tests ab.
• Backend-Bestellmanagement (beinhaltet die Kommunikation mit mehreren integrierten Partnern, Überprüfung des Lagerbestands, E-Mail an den Benutzer usw.) – dies hilft beim Testen der Integration der einzelnen Teile und auch des Kerns des Produkts.

Wenn also ein solches Skript ausgeführt wird, gibt es die Gewissheit, dass die Lösung als Ganzes gut funktioniert.

#3) Die dritte Gruppe sind die funktionsbasierten Tests.

Zum Beispiel können wir die Funktion haben, eine Datei zu durchsuchen und auszuwählen. Wenn wir dies automatisieren, können wir Fälle automatisieren, um die Auswahl verschiedener Dateitypen, Dateigrößen usw. einzubeziehen, so dass Funktionstests durchgeführt werden. Wenn es Änderungen/Ergänzungen zu dieser Funktionalität gibt, kann diese Suite als Regressionssuite dienen.

#4) Der nächste Punkt auf der Liste wären UI-basierte Tests. Wir können eine weitere Suite haben, die rein UI-basierte Funktionalitäten testet, wie z.B. Paginierung, Textfeld-Zeichenbegrenzung, Kalender-Schaltfläche, Dropdowns, Graphen, Bilder und viele solche UI-zentrischen Funktionen. Das Versagen dieser Skripte ist normalerweise nicht sehr kritisch, es sei denn, die Benutzeroberfläche ist komplett ausgefallen oder bestimmte Seiten werden nicht wie erwartet angezeigt!

#5) Wir können eine weitere Reihe von Tests durchführen, die einfach, aber sehr mühsam sind und manuell ausgeführt werden müssen. Mühsame, aber einfache Tests sind die idealen Kandidaten für die Automatisierung, z.B. die Eingabe der Daten von 1000 Kunden in die Datenbank ist eine einfache Funktionalität, aber extrem mühsam manuell auszuführen, solche Tests sollten automatisiert werden. Wenn nicht, werden sie meist ignoriert und nicht getestet.

Was sollte man NICHT automatisieren?

Nachfolgend sind einige Tests aufgeführt, die nicht automatisiert werden sollten.

#1) Negativtests/Failover-Tests

Wir sollten nicht versuchen, Negativ- oder Failover-Tests zu automatisieren, da die Tester bei diesen Tests analytisch denken müssen und Negativtests nicht wirklich ein einfaches Ergebnis liefern, das uns helfen kann.

Negative Tests erfordern eine Menge manueller Eingriffe, um ein tatsächliches Disaster Recovery-Szenario zu simulieren. Um ein Beispiel zu nennen, testen wir Funktionen wie die Zuverlässigkeit von Webdiensten – um es hier zu verallgemeinern, wäre das Hauptziel solcher Tests, absichtliche Fehler zu verursachen und zu sehen, wie gut das Produkt zuverlässig ist.

Die oben genannten Fehler zu simulieren ist nicht einfach, es kann das Einfügen einiger Stubs oder die Verwendung einiger Tools dazwischen beinhalten und Automatisierung ist hier nicht der beste Weg.

#2) Ad-hoc-Tests

Diese Tests sind möglicherweise nicht immer relevant für ein Produkt und dies kann sogar etwas sein, woran der Tester in dieser Phase der Projektinitiierung denken könnte. Außerdem muss der Aufwand für die Automatisierung eines Ad-hoc-Tests gegen die Kritikalität der Funktion, die die Tests betreffen, abgewogen werden.

Ein Tester, der eine Funktion testet, die sich mit der Komprimierung/Verschlüsselung von Daten befasst, könnte beispielsweise intensive Ad-hoc-Tests mit einer Vielzahl von Daten, Dateitypen, Dateigrößen, beschädigten Daten, einer Kombination von Daten, unter Verwendung verschiedener Algorithmen, über mehrere Plattformen hinweg usw. durchgeführt haben.

Wenn wir die Automatisierung planen, sollten wir Prioritäten setzen und nicht alle Ad-hoc-Tests nur für diese Funktion vollständig automatisieren, so dass am Ende ein wenig Zeit für die Automatisierung der anderen wichtigen Funktionen bleibt.

#3) Tests mit umfangreichen Voreinstellungen

Es gibt Tests, die enorme Voreinstellungen erfordern.

Zum Beispiel haben wir ein Produkt, das für einige Funktionen mit einer Software eines Drittanbieters integriert ist, da das Produkt mit einem beliebigen Warteschlangensystem integriert ist, das die Installation auf einem System, das Einrichten von Warteschlangen, das Erstellen von Warteschlangen usw. erfordert.

Die Software des Drittanbieters kann alles Mögliche sein und die Einrichtung kann komplexer Natur sein, und wenn solche Skripte automatisiert werden, dann werden diese für immer von der Funktion/Einrichtung dieser Software des Drittanbieters abhängig sein.

Voraussetzungen sind unter anderem:

Zurzeit mögen die Dinge einfach und sauber aussehen, da beide Seiten eingerichtet sind und alles in Ordnung ist. Wir haben schon oft erlebt, dass ein Projekt in der Wartungsphase an ein anderes Team übergeben wird, das dann solche Skripte debuggen muss, bei denen der eigentliche Test sehr einfach ist, das Skript aber aufgrund eines Problems mit einer Drittanbietersoftware fehlschlägt.

Das obige Beispiel ist nur ein Beispiel, im Allgemeinen sollten Sie ein Auge auf Tests haben, die aufwendige Voreinstellungen für einen einfachen Test haben, der dann folgt.

Einfaches Beispiel für Testautomatisierung

Wenn Sie eine Software testen (im Web oder auf dem Desktop), verwenden Sie normalerweise eine Maus und eine Tastatur, um Ihre Schritte auszuführen. Ein Automatisierungswerkzeug ahmt diese Schritte mit Hilfe von Skripten oder einer Programmiersprache nach.

Wenn Sie zum Beispiel einen Taschenrechner testen und der Testfall darin besteht, dass Sie zwei Zahlen addieren und das Ergebnis sehen müssen. The script will perform the same steps by making use of your mouse and keyboard.

The example is shown below.

Manual Test Case Steps:

1. Launch Calculator
2. Press 2
3. Press +
4. Press 3
5. Press =
6. The screen should display 5.
7. Close Calculator.

Automation Script:

//the example is written in MS Coded UI using c# language.public void TestCalculator(){//launch the applicationvar app = ApplicationUnderTest.Launch("C:\\Windows\\System32\\calc.exe");//do all the operationsMouse.Click(button2);Mouse.Click(buttonAdd);Mouse.Click(button3);Mouse.Click(buttonEqual);//evaluate the resultsAssert.AreEqual("5", txtResult.DisplayText,”Calculator is not showing 5);//close the applicationapp.Close();}

The above script is just a duplication of your manual steps. The script is easy to create and easy to understand as well.

What are Assertions?

The second last line of the script needs some more explanation.

Assert.AreEqual(„5“, txtResult.DisplayText,“Calculator is not showing 5);

In every test case, we have some expected or predicted result at the end. In the above script, we have an expectation that „5“ should be shown on the screen. The actual outcome is the result that is displayed on the screen. In jedem Testfall vergleichen wir das erwartete Ergebnis mit dem tatsächlichen Ergebnis.

Das Gleiche gilt auch für Automatisierungstests. Der einzige Unterschied ist, dass dieser Vergleich bei der Testautomatisierung in jedem Tool anders genannt wird.

Einige Tools nennen es „Assertion“, andere „Checkpoint“ und wieder andere „Validierung“. Aber im Grunde handelt es sich nur um einen Vergleich. Wenn dieser Vergleich fehlschlägt, z.B. wenn ein Bildschirm 15 statt 5 anzeigt, dann schlägt diese Behauptung/der Prüfpunkt/die Validierung fehl und Ihr Testfall wird als fehlgeschlagen markiert.

Wenn ein Testfall aufgrund einer Behauptung fehlschlägt, dann bedeutet das, dass Sie einen Fehler durch Testautomatisierung entdeckt haben. Sie müssen ihn an Ihr Fehlerverwaltungssystem melden, so wie Sie es normalerweise bei manuellen Tests tun.

Im obigen Skript haben wir in der vorletzten Zeile eine Assertion ausgeführt. 5 ist das erwartete Ergebnis, txtResult. DisplayText ist das tatsächliche Ergebnis, und wenn sie nicht gleich sind, wird die Meldung „Calculator is not showing 5“ angezeigt.

Schlussfolgerung

Oft stoßen Tester auf Projektfristen und den Auftrag, alle Fälle zu automatisieren, um die Testschätzungen zu verbessern.

Es gibt einige gängige „falsche“ Vorstellungen über Automatisierung.

Sie sind:

• Wir können jeden Testfall automatisieren.
• Die Automatisierung von Tests wird die Testzeit enorm verkürzen.
• Keine Fehler werden eingeführt, wenn die Automatisierungsskripte reibungslos laufen.

Wir sollten uns darüber im Klaren sein, dass die Automatisierung die Testzeit nur für bestimmte Arten von Tests reduzieren kann. Die Automatisierung aller Tests ohne Plan oder Reihenfolge führt zu umfangreichen Skripten, die sehr wartungsintensiv sind, häufig fehlschlagen und viel manuelles Eingreifen erfordern. Außerdem können Automatisierungsskripte bei sich ständig weiterentwickelnden Produkten veralten und bedürfen ständiger Überprüfungen.

Die Gruppierung und Automatisierung der richtigen Kandidaten spart eine Menge Zeit und bietet alle Vorteile der Automatisierung.

Dieses ausgezeichnete Tutorial kann in nur 7 Punkten zusammengefasst werden.

Automatisierungstests:

• Ist das Testen, das programmatisch durchgeführt wird.
• Verwendet das Werkzeug, um die Ausführung von Tests zu steuern.
• Vergleicht erwartete Ergebnisse mit den tatsächlichen Ergebnissen (Assertions).
• Kann einige sich wiederholende, aber notwendige Aufgaben automatisieren (z. B. Ihre Regressionstestfälle).
• Kann einige Aufgaben automatisieren, die manuell schwer zu erledigen sind (z.z. B. Lasttestszenarien).
• Skripte können schnell und wiederholt ausgeführt werden.
• Ist langfristig kosteneffektiv.

Hier wird Automatisierung in einfachen Worten erklärt, aber das bedeutet nicht, dass es immer einfach zu tun ist. Es gibt Herausforderungen, Risiken und viele andere Hindernisse, die damit verbunden sind. Es gibt zahlreiche Möglichkeiten, wie die Testautomatisierung schief gehen kann, aber wenn alles gut geht, dann sind die Vorteile der Testautomatisierung wirklich riesig.

Die nächsten Tutorials in dieser Serie:

In unseren kommenden Tutorials werden wir verschiedene Aspekte im Zusammenhang mit der Automatisierung diskutieren.

Dazu gehören:

1. Typen von automatisierten Tests und einige Missverständnisse.
2. Wie Sie die Automatisierung in Ihrer Organisation einführen und häufige Fallstricke bei der Testautomatisierung vermeiden.
3. Der Prozess der Toolauswahl und der Vergleich verschiedener Automatisierungstools.
4. Script-Entwicklung und Automatisierungs-Frameworks mit Beispielen.
5. Ausführung und Reporting von Testautomatisierung.
6. Best Practices und Strategien der Testautomatisierung.