Qytera News

Webinar: Testautomatisierung mit Cypress

Lesedauer: 1 Minute

Automatisiertes, anschauliches Reporting macht mit den richtigen Plug-ins auch in Cypress froh – und mit CI/CD Anbindung & automatisierten Uploads nach Xray den Manager ebenso.

Testautomatisierung mit Cypress

Was nützt das Testen von Software, wenn man Testergebnisse nicht vernünftig visualisiert und archiviert? Reporting ist das A und O wenn es darum geht, Trends zu analysieren und daraufhin weitere Maßnahmen abzuleiten. Idealerweise sogar ganz automatisch, ohne dass ein leicht zu vergessendes Testknöpfchen gedrückt werden muss. Allerdings kommt nicht jedes Testtool von Haus aus mit vernünftigem Reporting daher und auch Cypress ist da keine Ausnahme – trotz der hohen Popularität.

Zum Glück bietet Cypress jedoch mit einer Plug-in-Architektur die Möglichkeit, sich das gewünschte Reporting ganz im Sinne der Open Source ohne viel Aufwand zusammenzustecken.

In diesem Webinar werden deswegen im Rahmen eines Beispielprojekts die folgenden Themen behandelt:
  • Testergebnisse im Cypress-Umfeld
  • HTML-Reporting mit Cypress
  • Integration von Cypress in GitHub Actions
  • Upload von Testergebnissen nach Jira Xray

Wann und Wo?

Am 2. Feb. 2023 17:00 im Zoom-Meeting

Sprecher

Sebastian Vollbrecht:

Sebastian Vollbrecht ist nach Erhalt seines M. Sc. Informatik direkt im Testing gelandet. Dort konnte er als Consultant innerhalb kürzester Zeit bereits mehrere Projekte erfolgreich abschließen, in denen hauptsächlich JMeter, Cypress und Selenium zum Einsatz kamen. Auch durch die im Studium gesammelte Praxiserfahrung konnte er sich einen essentiellen Erfahrungsschatz erarbeiten und weiß mittlerweile, dass das Reporting von (Test-)Ergebnissen oft eines der wichtigsten Element gelungener Projektarbeit ist. Als Verfechter der Open Source weiß er Plugin-Architekturen und Modifizierbarkeit zu schätzen und freut sich, dass auch die Tester-Community diesen Gedanken wertschätzt. Zurzeit ist er als Junior Test Automation Engineer für die Qytera Software Testing Solutions GmbH tätig.

Moderator

Markus Thaler:

Markus Thaler war 22 Jahre in der Commerzbank tätig, wo er sich mehr als 10 Jahre um Teststandards, Testwerkzeuge und Testautomatisierung in einer zentralen Funktion gekümmert hat, bevor er nach einer Zwischenstation im Testinfrastrukturmanagement acht Jahre als Testmanager in der Risikofunktion der Commerzbank gewirkt hat. Vor der Commerzbank konnte er Testerfahrungen bei Lufthansa, Siemens, Nestle und der DZ-Bank gewinnen. Aktuell ist er als Senior Testmanager und Testarchitekt bei Qytera tätig.

Wir freuen uns auf Eure Teilnahme und Fragen!


Gerne beantworten wir Ihnen Fragen und beraten Sie genauer zur Testautomatisierung in Ihrem Projekt. Kontaktieren Sie uns hierfür einfach oder vereinbaren Sie direkt einen kostenlosen Testautomatisierungs-Workshop mit unseren Qytera-Testexperten. Wir wünschen Ihnen viel Erfolg bei Ihrer Testautomatisierung!

31. Januar 202331. Januar 2023Finden Sie weitere interessante Artikel zum Thema:  Artikel weiterempfehlen:

Cypress mit Upload nach Xray

Lesedauer: 5 Minuten

Seit der Erstveröffentlichung in 2017 ist Cypress zu einer Schlüsselfigur im Testingumfeld geworden: Mit mehr als 4.000.000 wöchentlichen Downloads ist es ohne Zweifel eines der beliebteren Packages in npm, dem Paketmanager für Node.js. Aus Testersicht überzeugt Cypress durch Schnelligkeit, der Zugänglichkeit der doch großen Fülle an Features und der nahtlosen Integration vieler bereits bekannter Frameworks wie Mocha oder Chai. Einen Überblick über weitere Vor-und Nachteile bietet dieser Blogbeitrag.

Aber wie schaut es mit dem Reporting aus? Klar, Cypress kann eigenständig Screenshots machen und Videos aufnehmen. Mit Plugins kann man die Testergebnisse sogar zu HTML-Reports zusammenfügen. Auch ein Export der Testergebnisse in eine JUnit-XML-Datei lässt sich einrichten, die man dann beispielsweise in Xray importieren kann. Das Problem dabei: es lassen sich keine Screenshots einbetten und die Wiederverwendung bestehender Testfälle in Xray durch die Testfälle in Cypress ist auch eher mühsam.

Bei Qytera wurde deswegen ein einfach zu verwendendes Plugin für Cypress entwickelt, welches die Einbindung beliebiger Xray-Projekte in Cypress möglich macht – inklusive Uploads von Videos oder Screenshots. Zusätzlich spielt dabei die Jira-Infrastruktur keine Rolle: Das Plugin funktioniert sowohl mit einer serverbasierten Jira-Instanz, als auch mit der cloudbasierten Variante.

Die grundlegende Verwendung des Xray Plugins wird in diesem Blogbeitrag demonstriert.

Testfälle

Das Plugin lässt sich am einfachsten anhand von ein paar winzigen Testfällen demonstrieren. Die Testfälle, die in diesem Blogbeitrag vorkommen, verwenden dabei example.org als Testobjekt. Auf der Seite gibt es nicht viel zu sehen, abgesehen von etwas Text – insbesondere keine Bilder. Insgesamt gibt es drei Testfälle:

  • Es wird überprüft, dass die Seite eine Überschrift mit Text Example Domain enthält.
  • Es wird überprüft, dass die Seite einen Hyperlink mit www.iana.org/domains/example als Ziel enthält.
  • Es wird überprüft, dass die Seite ein Bild enthält. Dieser Testfall wird immer fehlschlagen (und soll das auch), da die Seite wie erwähnt kein Bild enthält.

Im Screenshot ist der entsprechende Testcode in Cypress zu sehen und welche der Elemente von den Funktionen jeweils abgedeckt werden.

Bild: Die Elemente des Testobjekts, die mit den drei Testfällen abgedeckt werden. Oder auch nicht, da das Testobjekt kein Bild enthält. [Quelle: atlassian.com] ×

Bei der Ausführung der Tests meldet Cypress wie erwartet, dass zwei von drei Tests fehlerfrei laufen und lediglich der dritte fehlschlägt (“failed to find element: img"). Zusätzlich wird für den dritten Test automatisch ein Screenshot abgespeichert, der den Zustand zum Zeitpunkt des Scheiterns dokumentiert.

Bild: Ganz ohne Plugins findet Reporting in Cypress ausschließlich über die Standardausgabe statt. [Quelle: atlassian.com] ×

Für denjenigen, der die Tests entwickelt, reicht diese Dokumentation möglicherweise vollkommen aus. In einem Projektrahmen sollte aber persistentes Reporting stattfinden, idealerweise mit einem zentralen Ort zur Verwaltung der Testfälle. Das Xray-Plugin ermöglicht mit der Anbindung an Xray genau diese beiden Aspekte.

Verwendung des Xray-Plugins

Das Xray-Plugin ist sehr schlank gehalten und bietet aktuell eine einfache Funktionalität, die Testergebnisse hochladen kann und in Xray entsprechende Issues erstellt oder wiederverwendet. Es lassen sich zwei Richtungen identifizieren, in die die Informationen zu einzelnen Testfällen fließen können.

Erst Cypress, dann Xray

Die erste Richtung ist die von Cypress nach Xray. Das heißt, dass zu Testfällen, die in Cypress ausgeführt werden, in Xray automatisch entsprechende Issues angelegt werden. Die Namen der Issues werden dabei von den Namen der einzelnen Testfälle übernommen.

Jede Testausführung legt dabei ein Test Execution Issue an, in der die ausgeführten Test Issues verlinkt sind. Sollte für einen Testfall bereits ein Test Issue mit identischem Namen existieren, wird es wiederverwendet (für mehr Informationen siehe Abschnitt Creating Test Issues in der Xray API Dokumentation).

Vermutlich wird in dieser Variante jedoch die Verwaltung der Issues in Xray unübersichtlich aufgrund sich schnell mal ändernder Namen bei Cypress-Testfällen. Für jeden neuen Namen würde immer wieder ein neues Test Issue erstellt werden. Deswegen empfiehlt es sich, bestehende Test Issues wie im folgenden Abschnitt explizit wiederzuverwenden. Als Bonus bleiben dann auch die Testanalysten im Projekt glücklich, die weiterhin ein ordentlich gepflegtes Xray vorfinden wollen.

Erst Xray, dann Cypress

Die zweite Richtung ist die von Xray nach Cypress. In diesem Fall existieren in Xray bereits alle Test Issues, man muss Cypress lediglich beibringen, durch welche Testfällen sie abgebildet werden. Dazu reicht es aus, die Issue-Keys in die Namen der Testcases mit aufzunehmen. Bei der Testausführung ist das Plugin dann in der Lage, die Zuordnung auszulesen und den Upload anzupassen.

Insgesamt wird hierbei dann typischerweise ein neues Test Execution Issue angelegt, welches die ausgeführten Test Issues referenziert. Eine zentrale Verwaltung der Testfälle in Xray wird somit möglich gemacht.

Fazit

Das Cypress-Xray-Plugin bietet eine gute Möglichkeit, Testfälle in Xray mit Testausführungen in Cypress zu verbinden. Es erlaubt eine automatische Übermittlung der Cypress-Testergebnisse nach Xray und erleichtert die Analyse und das Management von Testfällen- und läufen. Auch die bereits bestehenden Issues in Xray können nach Minimalanpassungen in Cypress wiederverwendet werden. Alles, was man neben Cypress zur Verwendung des Plugins braucht, ist eine betriebsbereite Xray-Instanz. Ob es sich dabei um eine Server- oder eine Cloudvariante handelt, spielt keine Rolle.

Genauere Anleitungen sowie weitere Features können dem offiziellen Repository entnommen werden. In Arbeit ist zurzeit noch eine automatische Synchronisierung von Cucumber Feature Files zwischen Cypress und Xray beim Ausführen der Tests.



Gerne beantworten wir Ihnen Fragen und beraten Sie genauer zur Testautomatisierung in Ihrem Projekt. Kontaktieren Sie uns hierfür einfach oder vereinbaren Sie direkt einen kostenlosen Testautomatisierungs-Workshop mit unseren Qytera-Testexperten. Wir wünschen Ihnen viel Erfolg bei Ihrer Testautomatisierung!

24. Januar 202324. Januar 2023Finden Sie weitere interessante Artikel zum Thema:  Artikel weiterempfehlen:

Was ist Jira?

Lesedauer: 3 Minuten

Jira ist eine Webanwendung zur Verwaltung von Prozessen, Aufgaben und zum operativen Projektmanagement. Eingesetzt wird Jira vor allem in der Softwareentwicklung, findet jedoch mittlerweile auch Anklang in anderen Bereichen vieler Unternehmen.

Verwalten von agilen Projekten

Eine der populärsten Anwendungsfälle von Jira ist das Verwalten von agilen Projekten. Hierfür stellt Jira ein Kanban-Board bereit, mit dem sich Aufgaben und deren Status verwalten lassen. In der Philosophie von Jira zeichnet sich eine Aufgabe, oder auch Issue genannt, durch folgende Merkmale aus: Eine Aufgabe ist einem oder mehreren Teammitgliedern zugeordnet, besitzt einen Status, eine Priorität und kann durch die Teammitglieder kommentiert werden. Alle Änderungen an einer Aufgabe werden aufgezeichnet und können somit nachvollzogen werden. Die Nutzer:innen können ebenfalls Aufgaben mittels Aufgabentypen klassifizieren.

Darstellung von Aufgaben mittels Kanban-Boards

Ein Kanban-Board ist eine visuelle Darstellung von Aufgaben. Die grundlegende Idee eines Kanban-Boards ist es, Aufgaben in verschiedenen Spalten zu organisieren und somit die Übersichtlichkeit zu erhöhen. Eine weitverbreitete Praxis ist hierbei, dass die Spalten den Fortschritt der Aufgabe aufzeigen und dass eine Aufgabe während ihrer Bearbeitung von der ersten Spalte aus in mehreren Zwischenschritten in die letzte Spalte des Board wandert. In der ersten Spalte werden zunächst Ideen für Aufgaben gesammelt, die zukünftig bearbeitet werden sollen, jedoch noch nicht weitergehend definiert worden sind. Wird eine Aufgabe konkretisiert, wandert die Aufgabe eine Spalte weiter. Der nächste Schritt besteht darin, dass die Aufgabe einem oder mehreren Mitarbeiter:innen zugeteilt wird und eine Frist bis zur Fertigstellung der Aufgabe definiert wird. Hierbei wird die Aufgabe in die dritte Spalte verschoben. Nach dem Abschluss der Aufgabe wandert diese in die vierte Spalte des Boards. In dieser Spalte werden Aufgaben gesammelt, die von den Bearbeiter:innen als abgeschlossen betrachtet werden, jedoch noch von anderen Mitarbeiter:innen reviewet werden müssen. Schlussendlich wandert die Aufgabe nach dem Review in die letzte Spalte und gilt somit als endgültig abgeschlossen.

Jira stellt ein solches Kanban-Board als Webanwendung bereit. Durch farbliche Markierungen können Kategorien, Prioritäten und andere Attribute der Aufgabe kenntlich gemacht werden. Weiterhin erlaubt das Kanban-Board von Jira ein Trackingder Aufgaben. Die Verantwortlichen können somit genau nachvollziehen, wann und von wem eine Aufgabe bearbeitet wurde und wie lange die Person hierfür benötigt hat.

Bild: Jira Kanban Board [Quelle: atlassian.com] ×

Die Anordnung der Spalten nach dem Fortschritt der Aufgaben ermöglicht es Projektleiter:innen zudem, Engpässe frühzeitig zu erkennen. Sammeln sich zu viele Aufgaben in der Spalte für die aktuell bearbeiteten Aufgaben, kann das Projektmanagement hierauf reagieren und Aufgaben umpriorisieren oder verschieben. Auch für die anderen Mitarbeiter:innen bietet ein Kanban-Board eine gute Übersicht über den aktuellen Status des Projektes.

Um Aufgaben effizienter zu planen, hat sich eine Methode der Punktevergabe für Aufgaben etabliert. Hierbei werden Aufgaben sogenannte Story Points zugeteilt, die den Aufwand dieser Aufgaben beschreiben. Je mehr Story Points eine Aufgabe erhält, desto mehr Zeit sollte für diese eingeplant werden. Diese Methode bietet der Projektleitung eine gute Möglichkeit, die verfügbaren Kapazitäten in einem Projektsprint möglichst effizient zu nutzen.

Roadmaps

Jira bietet neben Kanban-Boards auch die Möglichkeit, einen umfassenderen Überblick über den Fortschritt des Projektes mittels Roadmaps zu geben. In Roadmaps werden allgemeine Ziele des Projektes festgehalten. Aufgaben aus den Scrum-Boards lassen sich diesen Zielen zuordnen. Somit kann der Fortschritt des Ziels erfasst werden. Projektmanager:innen können somit nachvollziehen, welche Ziele im Zeitplan erreichbar sind und für welche Ziele eventuell mehr Ressourcen erforderlich sind.

Bild: Jira Roadmap [Quelle: atlassian.com] × Erweiterbarkeit von Jira

Jira ist nicht nur auf die Verwaltung von Aufgaben beschränkt. Durch seine auf Erweiterbarkeit ausgelegte Struktur existieren eine Vielzahl von Plugins, welche die Funktionalität von Jira erweitern. Viele dieser Plugins nutzen die Fähigkeit von Jira, eigene Aufgabentypen zu erstellen und ermöglichen somit eine Interoperabilität mit den nativen Jira-Funktionen und anderen Plugins.

Integration mit anderen Atlassian-Tools

Jira lässt sich mit anderen Tools von Atlassian integrieren. Hierzu zählen u.a. das Wiki-System Confluence, das Git-Repository-Tool Bitbucket, das CI/CD-Tool Pipelines sowie das Tool Atlassian DevOps.

Testmanagement mit Jira Xray

Ein populäres Plugin zum Management von Testprojekten ist das Xray-Plugin für Jira. Hierfür empfehlen wir Ihnen unseren Blogartikel zu diesem Thema.

Fazit

Jira bietet Ihnen eine sehr umfangreiche Lösung zum Managen von agilen Projekten an und kann durch seine Funktionen wie Kanban-Boards und Roadmaps sowie seine vielen Erweiterungsmöglichkeiten ein sehr nützliches Tool für Ihre Softwareentwicklungsprojekte bzw. Testmanagementprojekte sein.



Gerne beantworten wir Ihnen Fragen und beraten Sie genauer zur Testautomatisierung in Ihrem Projekt. Kontaktieren Sie uns hierfür einfach oder vereinbaren Sie direkt einen kostenlosen Testautomatisierungs-Workshop mit unseren Qytera-Testexperten. Wir wünschen Ihnen viel Erfolg bei Ihrer Testautomatisierung!

24. Januar 202324. Januar 2023Finden Sie weitere interessante Artikel zum Thema:  Artikel weiterempfehlen:

Continuous Performance Testing in DevOps (JMeter, GitHub Actions, AWS)

Lesedauer: 5 Minuten

Continuous Performance Testing (CPT) ist eine Methode des Performance Tests, bei der die Leistung von neu entwickelten Anwendungen oder Systemen automatisch und kontinuierlich überwacht und überprüft wird. CPT ermöglicht frühzeitige Erkennung von Leistungsproblemen, automatisiert Lasttests und gibt Einblick in die Leistung Ihrer Applikation oder des Systems. Um erfolgreich CPT durchzuführen, ist es wichtig, die richtigen Prozesse und Tools einzusetzen und Kenntnisse von CI/CD, DevOps und Performance Tests zu haben. Mit diesem Artikel möchte ich auch aufzeigen, wie Performance Testing sinnvoll als Teil einer CI/CD integriert werden kann und so den DevOps Ansatz unterstützt. Dazu gehe ich auch auf die Herausforderungen ein und möchte Ansätze aufzeigen, wie diese gelöst werden können.

Allgemeines zu CI/CD und DevOps

Continuous Integration und Continuous Delivery (CI/CD) sind inzwischen nichts Neues mehr. Durch die immer schneller stattfindenden Produkt-Release-Zyklen gehört es schon zum guten Ton, in einem Projekt eine CI/CD Build Pipeline zu erstellen. Denn nicht nur das reine Kompilieren des Quellcodes wird dabei durchgeführt, sondern es finden auch statische Codeanalysen und Ausführung von Unit Tests statt. Zusätzlich zu diesen entwicklungsnahen Tätigkeiten sollten jedoch auch die Qualitätssicherungsmaßnahmen ausgeführt werden, die gewöhnlich funktionale und nicht funktionale Tests umfassen. Somit kommen neben API Tests und UI Tests in einer Testautomatisierung auch nicht funktionale Testarten wie Penetration und Performance Tests immer größere Bedeutung. Denn im Idealfall können mit einer Delivery Pipeline alle notwendigen Aktivitäten bis zur Auslieferung automatisiert und gute Aussagen über die Qualität der Anwendung oder des Systems getroffen werden.

Bild: DevOps (Klicken zum Vergrößern) [Quelle: Qytera] × Warum soll die Performance der Anwendung regelmäßig überprüft werden?

Als Testmanager, Projektmanager oder Verantwortlicher des Produktes eines Unternehmens ist es wichtig, sicherzustellen, dass die Anwendungen, die Sie entwickeln und betreiben, zu jeder Zeit optimal funktionieren. In DevOps sind nicht nur operative Überwachungen der Anwendungen durch ein Application Performance Monitoring (APM) wichtig, sondern auch im Entwicklungszyklus in der CI/CD Pipeline müssen Maßnahmen ergriffen werden, die vor der Inbetriebnahme die Leistungsfähigkeit der Anwendung bewerten. Eine sehr sinnige Maßnahme ist deswegen, Performance Tests in die Pipeline zu integrieren. Im Gegensatz zu traditionellen Performance Tests, die nur gelegentlich durchgeführt werden, ermöglicht CPT somit die frühzeitige Erkennung von Leistungsproblemen und die Möglichkeit, schnell auf sie zu reagieren, um sie zu beheben.

Reicht es nicht aus, die Anwendungen und Systeme in Produktion zu überwachen?

Immer wieder werden wir gefragt, ob nicht das Monitoring, genauer gesagt das APM ausreicht, um genügend Informationen über die Leistungsfähigkeit zu erhalten und durch intelligente Algorithmen sogar Vorhersagen von Lastgrenzen oder Überlast zu gewinnen. Hier bin ich der Meinung, dass dies zu wenig ist, um dem Risiko langsamer Applikationen oder Systemen zu begegnen. Denn APM kann nur relativ spät - also in Produktion - die schlechten Performance Werte ermitteln. Dann kann das Kind schon in den Brunnen gefallen sein.

Unzureichende Performance kann dazu führen, dass Leistungen teuer dazugekauft werden oder gar Rollback und Backups durchgeführt werden müssen, die Ausfallzeiten und extrem hohe Kosten bedeuten. Sichern Sie sich hier besser ab und leisten Sie sich Performance Tests, die Sie in Ihre CI/CD Pipeline integrieren.

Welche Performance Testarten sind sinnvoll in einer CI/CD Pipeline?

Nicht jede Performance Testart kann sinnvoll in einer Pipeline integriert werden. Es müssen Laufzeit und Ziele passen und die Ergebnisse müssen automatisch ausgewertet werden können, damit die Pipeline einen gesicherten Status erreicht. Denn es kann nur ein Erfolgreich oder Nicht Erfolgreich für eine Pipeline geben, um diese integrierbar zu machen. Lange Auswertungen und Interpretationen sind hier nicht möglich.

Wenn ich nach ISTQB gehe, gibt es unterschiedliche Performance Testarten. Meiner Meinung nach eignen sich davon nur Lasttests und Nebenläufigkeitstest. Lasttests erzeugen die realistisch zu erwartende Last durch eine kontrollierte Anzahl von Benutzern, während Nebenläufigkeitstest gleichzeitig stattfindende Aktionen simulieren, die sich untereinander beeinflussen können. Beide Testarten können gut in einem definierten Rahmen und in einer kurzen Zeit ausgeführt werden. Andere Performance Tests wie Stresstests und Dauertests lassen sich eher nicht sinnvoll in einer CI/CD integrieren.

Bild: CI/CD-Pipeline (Klicken zum Vergrößern) [Quelle: Qytera] × Umsetzung im Detail

Für eine Demo setzten wir eine Pipeline mit GitHub Actions um. Hierfür war der große Vorteil für uns, dass wir durch die Nutzung der Cloud-Services keine eigene Infrastruktur bereitstellen mussten. Dennoch ist die Lösung nicht nur auf GitHub Actions beschränkt, sondern kann auch auf andere Build-Piplines bzw. Build-Tools übertragen werden, wie GitLab CI/CD, Bamboo, CruiseControl, Azure DevOps oder Jenkins.

Da die Lösung nicht ganz ohne Infrastruktur auskommt, starten wir in der Pipeline einen Docker Container auf dem die benötigten Tools, auf dem Java JVM und JMeter installiert werden. Als nächste Aktion wird ein Copy-Deployment eines vorab erstellten JMeter Projekts und der dazugehörenden Ressourcen durchgeführt. Besondere Erwähnung soll hier finden, dass wir Logindaten und Steuerungsmöglichkeiten in die GitHub Actions Secrets ausgelagert haben. Somit sind wir trotz eines vorgefertigten Szenarios imstande, die Anzahl der Threads, Laufzeit der Durchführung und weitere Parameter dem JMeter-Projekt von außen erst zur Laufzeit mitzugeben.

Nun startet der eigentliche Test. Auf dem bereitgestellten Docker Container kommt das JMeter-Projekt zur Ausführung. Dieses wird in diesem Beispiel 4 Minuten ausgeführt und durchläuft das geskriptete Szenario. Dabei werden Requests gegen eine URL abgegeben und die Responses ausgewertet. JMeter selbst läuft wie gewohnt ab und sammelt alle Informationen zu den Requests in den eigenen JTL-Logs. Nach der Durchführung wird zusätzlich automatisch der JMeter HTML Report erzeugt, in dem detaillierte Graphen der Durchführung enthalten sind.

Bild: GitHub Action Pipeline (Klicken zum Vergrößern) [Quelle: Qytera] × Unterschied zu einem gewöhnlichen Performance Test

Bis hierhin unterscheiden wir uns nicht viel von einem klassischen Performance Test. Lediglich die Bereitstellung der Infrastruktur und die Ausführung wurden automatisiert. Nur wie erreichen wir das für die Pipeline notwendige Ergebnis, ob der Test ein Erfolg oder ein Fehlschlag war?

Hierzu haben wir eine ganz spezielle Assertion (Prüfung) entwickelt. Die darin enthaltene Logik analysiert den Testlauf dahingehend, ob technische Fehler bei der Ausführung vorkamen oder ob sich vorgegebene Performanz-Werte im erlaubten Bereich befanden. Die technischen Fehler sind zum einen Fehler-Requests, die aus der Applikation entstehen, z.B. unerwartet HTTP/S-Statuscodes, aber auch Informationen über die Funktionsfähigkeit des Lastagenten mit JMeter. Teilweise könnten einige Informationen direkt innerhalb von JMeter ausgewertet werden. Nur führen Probleme bei der Ausführung dazu, dass JMeter abbricht und wir keine JTL-Logs erhalten, die die bis dahin stattgefundenen Requests und Responses enthalten. Zusätzlich zu den technisch bedingten Fehlern werden in der Assertion vorgegebene Performance-Counter abgefragt, die von Außen steuerbar unterschiedliche Performanzwerte (SLAs) prüfen, beispielsweise die maximale Antwortzeit eines Requests. Hier können so ziemlich alle als Performanz-kritisch eingestuften Messwerte ausgewertet werden.

Bild: Run SuiteCRM JMeter Test (Klicken zum Vergrößern) [Quelle: Qytera] × Fazit und Zusammenfassung

In der Anwendungsentwicklung erreichen wir mit agilen Ansätzen und Continuous Delivery ungeahnte Geschwindigkeiten beim Erstellen von Funktionen und Services. Dies bedarf einer immer höheren Automatisierung, die von Quellcodeerzeugung bis zur Auslieferung in wenigen Momenten Ergebnisse liefern muss. Gerade hier müssen alle möglichen Qualitätssicherungsmaßnahmen, von funktionalen bis nicht funktionalen Tests, mit in diese schnelle Auslieferungspipeline aufgenommen werden, damit wir ein Höchstmaß an Qualität liefern können. Werden diese Tests nicht unternommen, dann hindert diese mindere Qualität den Anwender in der Anwendung oder lässt Services inkorrekt ablaufen. Dies kann nicht nur viel Geld kosten, da die Fehler in Produktion am teuersten sind, sondern auch Verlust an Reputation bedeuten und somit einen Umsatzverlust bringen. Deshalb wäre mein Rat: Lassen Sie es nicht so weit kommen. Entwickeln Sie Ihr Deployment weiter und achten Sie darauf, auch die Qualitätssicherung in Ihrer Pipeline entsprechende Mittel zukommen zu lassen, sodass Sie Risiken minimieren und finanziellen Schaden von sich fernhalten.

Wenn Sie einen besseren Einblick in eine mögliche Umsetzung erhalten möchten, sehen Sie sich einfach unser aufgezeichnetes Webinar zu diesem Thema an:


Gerne beantworten wir Ihnen Fragen und beraten Sie genauer zur Testautomatisierung in Ihrem Projekt. Kontaktieren Sie uns hierfür einfach oder vereinbaren Sie direkt einen kostenlosen Testautomatisierungs-Workshop mit unseren Qytera-Testexperten. Wir wünschen Ihnen viel Erfolg bei Ihrer Testautomatisierung!

23. Januar 202326. Januar 2023Finden Sie weitere interessante Artikel zum Thema:  Artikel weiterempfehlen:

Erfahrungsbericht Agile Testing Days 2022 (virtuell)

Lesedauer: 4 Minuten

An den diesjährigen Agile Testing Days (21.11.-24.11.22 in Potsdam) konnte ich virtuell an einem Konferenztag teilnehmen.

In der Keynote Human Impact nahm Fiona Charles ethische und praktische Perspektiven auf unsere softwaregesteuerte Welt in den Fokus. Jeder, der an der Softwareentwicklung beteiligt ist, trägt eine ethische Verantwortung dafür, den Schaden, den Software für Menschen verursachen kann, zu minimieren und den Nutzen zu maximieren. Als Beispiel für Softwarefehler mit großer negativer Wirkung führte Jones die Abstürze der Boeing MAX 737 an. Auch die gerichtliche Verfolgung und Entlassung von Angestellten der britischen Post auf Grund von Fehlern in der Buchhaltungssoftware brachte sie als weiteres Beispiel. In diesen Fällen hätten ethische und praktische Positionen die Fehlerentstehung verhindern können. Um nur einige der Konsequenzen zu nennen: Jeder, der als Nutzer von Software betroffen sein könnte, sollte als Stakeholder im Softwareentwicklungsprozess berücksichtigt werden. Technische Entwicklungen sollten auf ethischen Prinzipien beruhen. Als Leitlinie hat Fiona Charles 10+1 ethische Grundsätze veröffentlicht. Auch die Grenzen der Technologie sollten stets im Blick bleiben und bei Entscheidungen berücksichtigt werden. Letztlich “können wir es uns als Menschen in der Gesellschaft nicht leisten, die potenziellen Schäden der Technik zu ignorieren”.


Lily Higham präsentierte in "Testing the BBC worldwide service" Herausforderungen und Lösungen für das Testen einer weltweit nutzbaren Nachrichten-Website. Zu den Herausforderungen gehören Nachrichten in 41 verschiedenen Sprachen, die von den Testern nicht alle beherrscht werden, Unterschiede in Netzbandbreiten und Zugriffsberechtigungen, mannigfaltige Gerätetypen einschließlich älterer Modelle, verschiedene Browser und diverse Anforderungen an die Zugänglichkeit. Lösungen bestehen in der Nutzung von Testautomatisierung, in dem Fall Cypress mit spezifischen Erweiterungen (z.B. Automatic Retries, Time Travel,...), der Anbindung von Browserstack und dem Engagement von verteilten Testern über einen weltweit agierenden Dienstleister. Insgesamt eine mächtige Testaufgabe, die von drei Testern mit einem pragmatisch gewählten Mix aus Methoden, Tools und Testdienstleistungen offenbar erfolgreich gestemmt wird.


Einen 360 Grad Blick auf Herausforderungen und Chancen der Testautomatisierung als Teil der Softwareentwicklung nahm Toyer Mamoee in Refining your Test Automation approach in modern contexts. Toyer stellte das Festhalten an bewährten Testvorgehensweisen in Frage angesichts ständig neu aufkommender Begriffe, Frameworks, Architekturen und Technologien, sieht aber eine eher chaotische Entwicklung bei der Testautomatisierung bedingt durch eine große Anzahl neuer Werkzeuge. Auf Basis von Studien in 2012, 2016 und 2022 kommt er zu dem Schluss, dass sich die Herausforderungen der Testautomatisierung in den letzten zehn Jahren nicht wesentlich geändert haben. Zu den Herausforderungen rechnet Toyer langlaufende Tests, Isolation der Testautomatisierer, Wartungsalpträume, fehlende Verfolgbarkeit, nicht-funktionales Testen als BigBang, sowie Verzögerungen zwischen Deployment und Tests. Chancen sieht er dagegen in modernen Architekturen, wie Mikroservices, Containerisierung und Cloud-Technologien, soweit sich die Testautomatisierer mit diesen auseinandersetzen. In einer Prozesslandschaft vielfältiger Tools positioniert er die Testautomatisierung als Schlüssel zur Verfolgbarkeit von Produktionsfeedback zu zugehörigen Anforderungen. Abschließend stellte er einen Ansatz zur Verfeinerung der Testautomatisierung in 8 Schritten vor, zu den u.a. eine klare Definition des Automatisierungsansatzes auf den verschiedenen Ebenen gehört, aber auch die Verbesserung der Testbarkeit von Anwendungen und die Änderung von Denkweisen. In der Fragerunde nahm er u.a. Stellung zu Testautomatisierung ohne Code, der Kluft zwischen Entwicklern und Testautomatisierern, Lösungen für frühzeitige nicht-funktionale Tests, sowie die Rolle von Testern bei Unit-Tests.


Mit dem Quality Practices Assessment Model (=QPAM) will Janet Gregory dem agilen Testen einen Rahmen geben. Das Modell soll der Selbsteinordnung von Teams dienen und nicht dem Vergleich verschiedener Teams. QPAM hat Janet Gregory zusammen mit Senea Delesie entwickelt und inzwischen in einem Buch veröffentlicht hat. Gegenstand sind die Qualitätsprozesse in agilen Organisationen. Das Modell hat sich aus eher informalen Assessments entwickelt und ist noch in Entstehung. Im Mittelpunkt von QPAM stehen 10 Qualitätsaspekte, die drei Gruppen untergeordnet werden:
  1. Soziale Qualitätsaspekte
  2. Kombiniert soziale & technische Qualitätsaspekte
  3. Technische Qualitätsaspekte

Welche Faktoren eine lernende Organisation bestimmen, war Gegenstand des Keynote “Creating a Learning Culture” von Vincent Wijnen und Huib Schoots. Lernen wird von Vincent und Huib als eine Voraussetzung für das Wachstum und die Leistung von Menschen verstanden. Im Vortrag ging es erst einmal um das Lernen an sich: die Arbeit des Gehirns beim Lernen stand im Fokus. Dann wurden Vorteile einer lernenden Organisation dargestellt und warum sich lernen lohnt. Typische Anti-Pattern, also Umstände, die das Lernen behindern, ermittelten Vincent und Huib interaktiv mit dem Publikum. Sie hatten im Verlauf Schwierigkeiten, das Publikum nach der aufgekommenen Diskussion wieder zum Zuhören zu bewegen. Schließlich zeigten sie, wie der Wandel zu einer lernenden Organisation gelingen kann. Dafür gaben sie Tipps und brachten Learning Culture Stories.


Anne Marie Charret in Scaling Quality: it's more than numbers blickte als Quality Coach auf den Kontext von Wachstumsfirmen und vergleicht zwei dieser Firmen hinsichtlich einer passenden Qualitätsstrategie. Passend für die Situation ist eine aufkommende ("emergent") Qualitätsstrategie. In diesem Zusammenang beleuchtete Anne Marie die Unterschiede verschiedener Aspekte (Produkte, Ergebnisse, Beteiligte, Prozesse und Infrastruktur) für zwei Unternehmen, in denen Sie als Quality Coach gearbeitet hat.

FazitAlles in allem haben die besuchten Vorträge meinen Blick auf die Bewertung von Qualitätsprozessen, das Testen, die Testautomatisierung und Lernprozesse bereichert. Letztlich bleibt das Gefühl, mit der auf einen Tag reduzierten Teilnahme Wesentliches versäumt zu haben. Nächstes Jahr sollte ich unbedingt wieder die Agile Testing Days besuchen, nach Möglichkeit aber vor Ort teilnehmen. Allein das Begleitprogramm würde dafür sprechen und natürlich die Chancen zur Kontaktaufnahmen mit Referenten oder anderen Interessierten. Die Möglichkeit, sich die Vorträge per Video noch mal anzusehen, bliebe natürlich auch in diesem Fall der geschätzte Vorteil einer hybriden Veranstaltung.

Gerne beantworten wir Ihnen Fragen und beraten Sie genauer zur Testautomatisierung in Ihrem Projekt. Kontaktieren Sie uns hierfür einfach oder vereinbaren Sie direkt einen kostenlosen Testautomatisierungs-Workshop mit unseren Qytera-Testexperten. Wir wünschen Ihnen viel Erfolg bei Ihrer Testautomatisierung!

21. Dezember 202222. Dezember 2022 Artikel weiterempfehlen:

Für Tester und Entwickler: Aus der Praxis für die Praxis

Lesedauer: 1 Minute

youtubeembedcode esuno regler byta hand kort

Liebe Tester und Entwickler,

wir möchten Euch hiermit zu unserer Community einladen und kurz erläutern, welche Inhalte wir als Experten aus der Praxis für Euch produzieren.

Unsere Inhalte

Für Tester und Entwickler: Wir teilen unsere Expertise und Netzwerk mit unserer Community! Die jahrelangen Erfahrungen aus der Praxis, den Austausch zwischen Experten zu den Themen "Agile Testing und Continuous Testing" sowie tägliche Herausforderungen aus der Welt der Software-Entwicklung und -Qualitätssicherung teilen wir gerne mit Euch auf unterschiedlichen Kanälen. Folgende Inhalte stehen Dir kostenlos zur Verfügung:


    • Webinare (Quartalsweise):
      Experten und Gastredner zu den Themen, Softwaretests und Qualitätssicherung
      YouTube Channel


    • Blogartikel:
      Ideen, Wissen und Tägliches rund um die Themen eines Software-Entwicklers und insbes. eines Testers
      Blogartikel


Gerne beantworten wir Ihnen Fragen und beraten Sie genauer zur Testautomatisierung in Ihrem Projekt. Kontaktieren Sie uns hierfür einfach oder vereinbaren Sie direkt einen kostenlosen Testautomatisierungs-Workshop mit unseren Qytera-Testexperten. Wir wünschen Ihnen viel Erfolg bei Ihrer Testautomatisierung!

30. November 202230. November 2022 Artikel weiterempfehlen:

Einladung zum Coding-Meetup am 12. April 2023

Lesedauer: 2 MinutenVideo-Einladung

Liebe Studierende,
wir möchten Euch hiermit zu unserem Coding-Meetup am 12.04.2023 einladen, in dem wir uns mit den Themen Testautomatisierung von Webanwendungen, Last- und Performance-Testing sowie API-Testing befassen werden. Für einen möglichst praxisnahen Abend haben wir uns drei Aufgaben ausgesucht, die ihr während des Meetups lösen dürft.

Was Euch erwartetZunächst werden wir uns die Automatisierung von Webseiten mittels Selenium anschauen. Selenium ist eine Open Source Lösung sowohl für die Testautomatisierung als auch für die Automatisierung anderer webbasierter Prozesse. Wir werden einen kleinen Bot bauen, welcher sich automatisiert auf einer Website einloggen und diese steuern kann. Danach werden wir in das Thema Automatisierung von REST APIs einsteigen, eine Technologie mit der häufig Daten zwischen einer Benutzeroberfläche einer Webapp und dem Backend transportiert werden. Hierfür werden wir uns das Tool Postman anschauen, welches u.a. für die Entwicklung von APIs als auch für das Testing und die Automatisierung von API-basierten Prozessen verwendet werden kann. Schlussendlich schauen wir uns das Tool JMeter an, mit dem Ihr eine Website unter Last testen könnt. Mittels JMeter können wir sowohl testen, wie viel Last unsere Website aushält als auch Angriffe mittels DDos simulieren.


Was Ihr mitbringen solltetZunächst solltet Ihr auf jeden Fall Begeisterung für die Themen Automatisieurng, Testing und Softwareentwicklung mitbringen. Unser Meetup richtet sich vor allem auch an Studierende, die bereits Erfahrung im Beriech Coding oder Softwareentwicklung sammeln konnten. Wir erwarten hier natürlich keine professionellen Kenntnisse in diesen Bereichen von euch. Etwas Erfahrung mit einer Programmiersprache wie JavaScript, Python oder einer ähnlichen Sprache ist jedoch von Vorteil. Ansonsten solltet ihr für die interaktiven Aufgaben euren Laptop mitbringen. Für Essen und Getränke ist gesorgt, den restlichen Abend werden wir für Networking und besseres Kennenlernen untereinander nutzen.

Wir freuen uns darauf Euch am 12.04. in unserem Office an der Hanauer Landstraße 114 begrüßen zu dürfen.


Zum Meetup Event

Gerne beantworten wir Ihnen Fragen und beraten Sie genauer zur Testautomatisierung in Ihrem Projekt. Kontaktieren Sie uns hierfür einfach oder vereinbaren Sie direkt einen kostenlosen Testautomatisierungs-Workshop mit unseren Qytera-Testexperten. Wir wünschen Ihnen viel Erfolg bei Ihrer Testautomatisierung!

23. November 202223. November 2022 Artikel weiterempfehlen:

Erfahrungsbericht QS-Tag 2022: Reinventing Quality

Lesedauer: 3 Minuten

Am 5.10/6.10. fand der QS-Tag 2022 als Präsenzveranstaltung im Steigenberger Airport Hotel am Flughafen Frankfurt statt. Auch wenn Corona und Remote-Work in den Vorträgen Thema waren, bestand während der QS-Tage reichlich Gelegenheit zur persönlichen Kontaktaufnahme: in gemeinsamen Pausen, an den Ständen der Aussteller und nicht zuletzt während der inkludierten Abendveranstaltung.

Der QS-Tag stand unter dem Motto "Reinventing Quality" und fächerte sich nach der Keynote in die Tracks Process, Products, People und Special Topics. Zusätzlich war die Robocon zu Gast und stellte einen weiteren Track. Meine Auswahl an Vorträgen war eine persönliche und ich habe sicherlich in den parallelen Tracks Interessantes verpasst.


Mit der Keynote "Paradigmenwechsel! Neue Denkweisen, neue Ansätze für Management und Qualität in der VUCA-Welt" ( VUCA = Volatility, Uncertainty, Complexity, Ambiguity) hat Prof. Ayelt Komus den Rahmen für das Motto des QS-Tags abgesteckt. Seiner Analyse nach befinden wir uns im Übergang von der komplizierten in die komplexe Welt und "tradierte Ansätze" seien da möglicherweise "nicht nur wirkungslos, sondern kontraproduktiv". "Neue Rollen und ein neues Selbstverständnis von QM und QS-Prozess und -Rollen" müssten her.


Die Keynote fokussierte allerdings eher die Managementebene ("Erfolgreiches Managen im Komplexen"). So wundert es auch nicht, dass agile Skalierungsansätze (SAFe, LeSS, Nexus, Scrum@Scale, Spotify Model, Disciplined Agile) im Vordergrund standen.


Ein Schwerpunkt meiner Vortragsbesuche am ersten Tag waren nach der Keynote Testintelligenz und der Einsatz von künstlicher Intelligenz beim Testen.


“Test Intelligence” soll helfen, "auf Basis der eigenen Daten mehr Fehler in kürzerer Zeit zu finden". Dr. Elmar Jürgens stellte im gewohnt engen Publikumsdialog die Verwendung der statischen Analyse zur aktiven Steuerung des Testprozesses vor, insbesondere zu Feinabstimmung der Testabdeckung und der Ausführungsreihenfolge von Testsuiten. Praktisch wurde der Vortrag ergänzt durch einem Solution-Workshop, in dem der Referent mit einem Kollegen (Dr. Sven Aman) Test Intelligence im praktischen Einsatz mit dem Werkzeug Teamscale demonstrierte.

Einen eher allgemeineren Einstieg brachte Prof. Winter nach der Mittagspause mit "Testen und künstliche Intelligenz - wo stehen wir heute." Die in vielen Systemen eingesetzten Verfahren des Machine Learning wurden dargestellt, wobei insbesondere für den Test relevante Eigenschaften dieser Verfahren auch praktisch beleuchtet wurden. Der Vortragende musste neben inhaltlichen Herausforderungen auch technische bewältigen und hat sein Improvisationstalent bei den aufgetretenen Schwierigkeiten überzeugend zum Einsatz gebracht.


Mit "From Usage Analysis to Automated Regression Testing supported by Machine Learning: Experience Report" zeigte Prof. Legeard, University of Franche-Comté, einen weit entwickelten Einsatz von KI beim Testen. Machine Learning wird nicht nur zur Analyse des Benutzerverhaltens in der Praxis, zur automatisierten Ableitung von Testfällen auf dieser Basis, sondern auch zu Messung und Optimierung von Testläufen eingesetzt. Autonomous Testing scheint bei diesem Ansatz zum Greifen nah.


“Testsuiteoptimierung mit Machine Learning”: Dr. Gregor Endlers Erfahrungsbericht zeigte, wie mittels des Machine Learning Systems Scryer mit Echtwelt-Daten eines Großprojekts aus dem Bereich Medizintechnik Testsuites optimiert werden konnten. Der Einsatz von KI für die Steuerung des Ablaufs von Testsuiten ist offenbar in vergleichbaren Fällen eine Alternative zum Einsatz von Test Intelligence auf Basis statischer Analyse.


Im einzigen Vortrag zum Thema Testdaten:“Reinventing Test Data - Anonymization, Pseudonymization and Synthetic Data: A State of The Art Review”, präsentierte Christian Alexander Graf die Unterschiede zwischen synthetischen Daten und anonymisierten, bzw. pseudonymisierten Produktionsdaten. Detailliert ging er auf die Risiken der Pseudonymisierung persönlicher Daten ein, insbesondere auf Möglichkeiten der De-Anonymisierung. Zur Beherrschung von Offenlegungsrisiken pseudonymisierter Daten empfahl er eine differenzierte Testdatenstrategie.


Mit "Lästige Dokumentation ? Wie sollte eine Dokumentation sein, die alle lieben" beschrieb Andre Mainka praktische Erfahrungen bei der Einführung eines Repositories zur Dokumentation verschiedener Artefakte im Entwicklungs-und Testprozess. Der Zuhörer wurde mit auf eine Reise vom ersten Piloten bis zur erfolgreichen Migration in einem ganzen Projekt genommen. Am zweiten Tag bewegte ich mich im Track Prozesse und Products. Während Frau Dr. Klaudia Dussa-Zieger in ihrem Vortrag “Testen in DevOps - Was ist neu oder anders? “ eher methodische Aspekte in der DevOps-Acht beleuchtete, gab Michael Mirold in “Aktuelle agile Testpraktiken und -muster” einen Überblick über die zuletzt grundlegend gewandelten technischen Rahmenbedingungen des Testens. Beide Vorträge ergänzten sich, auch wenn die beiden Referenten zum Thema des jeweils anderen wenig Berührungspunkte sahen.


Nach Prof. Ayelt Komus besteht die Chance in der VUCA-Welt auf "Bessere, echte SW-Qualität, frühere und gelebte echte Einbindung, verbesserte Akzeptanz und Wertschätzung". Das sind allerdings keineswegs neue Hoffnungen und gerade von Seiten des GTB (Dr. Armin Metzger) wurden in der Panel-Diskussion “Agiles Testen 2022 - Herausforderungen und Handlungsbedarf “ wehmütige Erinnerungen an die "guten alten" Zeiten um 2010 laut, als die Agilität die Fortschritte methodischen Softwaretestens noch nicht zu unterlaufen begonnen hatte. Die in die Podiumsdiskussion einbezogenen Besucher aus dem Publikum relativierten diese Sicht allerdings.


FazitDas mit dem QS-Tag 2022 abgedeckte Themenspektrum war erheblich und die Gelegenheit zur persönlichen Kontaktaufnahme mit Testexperten nicht nur aus Deutschland ein unschätzbarer Vorteil. Aus meiner Perspektive wurden die mit dem Titel “Reinventing Quality” gesteckten Erwartungen nicht durchgängig erfüllt, insbesondere weil außer der Keynote die wenigsten Vorträge Bezug zum Thema des QS-Tags nahmen.

Gerne beantworten wir Ihnen Fragen und beraten Sie genauer zur Testautomatisierung in Ihrem Projekt. Kontaktieren Sie uns hierfür einfach oder vereinbaren Sie direkt einen kostenlosen Testautomatisierungs-Workshop mit unseren Qytera-Testexperten. Wir wünschen Ihnen viel Erfolg bei Ihrer Testautomatisierung!

11. November 202211. November 2022 Artikel weiterempfehlen:

QTAF: Qytera Test Automation Framework (Open Source)

Lesedauer: 6 Minuten

Liebe Community, in diesem Artikel möchten wir euch unser neu entwickeltes Open Source Testframework namens QTAF vorstellen. Das Qytera Test Automation Framework (QTAF) ist ein von der Qytera GmbH entwickeltes Java-Testframework basierend auf TestNG, welches ein einfaches Aufsetzen neuer Java-Testprojekte, mit HTML-Reporting, Cucumber-Unterstützung, Anbindung an Jira Xray und einfache Erweiterbarkeit bietet. Ein kostspieliger Zeitfaktor beim Aufsetzen eines neuen Testprojektes ist die Einrichtung der Dokumentation der Testfälle. Ein möglichst allgemein nutzbares Reporting-Format wie JSON wird benötigt, um die ausgeführten Testfälle und eventuell aufgetretene Fehler zu dokumentieren und in ein anderes Tool wie etwa ein Testmanagementsystem zu übertragen. Weiterhin wäre ein HTML-Reporting sinnvoll, um den Testern einen schnellen Überblick über die durchgeführten Tests zu gewähren und Fehler schnell zu finden. Das Aufsetzen einer solchen Umgebung ist zeitaufwändig und bindet unnötig viele Ressourcen. Zudem ist es ineffektiv, diesen Prozess für jedes neue Testprojekt zu wiederholen. Effektiver wäre es, ein Framework zu entwickeln, welches genau diese Aufgaben übernehmen würde, sodass die Tester:innen sich um ihre eigentliche Aufgabe kümmern können: das Testen. QTAF ist die Realisierung genau dieser Idee, das Aufsetzen der Testumgebung und die Dokumentation der Testfälle zu übernehmen. Und QTAF bietet den Tester:innen noch einiges mehr.

QTAF auf GitHub

Die Vorteile von QTAF

QTAF ist ein Projekt, welches aus der Praxis heraus entstanden ist und die Erfahrung von Tester:innen aus jahrelanger Arbeit mit Testing-Tools bündelt. Mittels QTAF werden drei grundlegende und zeitaufwändige Probleme des Testens gelöst:

  • Das schnelle Einrichten einer konfigurierbaren Testumgebung
  • Das Reporting einer durchgeführten Testsuite
  • Die anschließende Dokumentation der Testresultate

Die Implementierung dieser aufgezählten Problemstellungen verlangt von den Testern zum einen gute Kenntnisse in der Programmierung und des Entwurfs von Softwareprojekten, zum anderen ist sie sehr zeitaufwendig und somit teuer. Die Testumgebung sollte auf Wiederverwendbarkeit ausgerichtet sein, sodass viele ihrer grundlegenden Komponenten auch in anderen Testumgebungen verwendet werden können. Somit lässt sich in anderen Projekten wertvolle Zeit einsparen. Bevor die eigentlichen Testfälle geschrieben werden können, muss in einem neuen Projekt die Testumgebung aufgesetzt und in Betrieb genommen werden. Hierfür vergehen meist Tage bis Wochen und dies kostet Ihr Unternehmen unnötig viel Zeit und Geld. Hierbei entstand die Idee von QTAF, welches dem Tester das Aufsetzen einer solchen wiederverwendbaren Testumgebung abnehmen sollte. QTAF löst genau diese Probleme, da es den Tester:innen die Entwicklung einer eigenen Testumgebung abnimmt und somit keine Kenntnisse in Softwareentwicklungsprojekten vorausgesetzt sein müssen. Die Einrichtung eines QTAF-Projektes dauert wenige Minuten, nach denen sofort mit der Entwicklung der Testfälle begonnen werden kann. Den Tester:innen steht nach der Aufsetzung eine vollständige Selenium-Testumgebung zur Verfügung, welche in der Lage ist, auf den gängigsten Browsern wie etwa Chrome, Edge, Firefox, Opera und Safari automatisierte Tests durchzuführen. Auch die Dokumentation der Testfälle wird durch QTAF übernommen und kann nach dem Durchlauf der Testsuite automatisiert in ein Testmanagementtool wie etwa Xray übernommen werden.

Wie funktioniert QTAF? Bild: Das QTAF Modell (Klicken zum Vergrößern) [Quelle: Qytera] ×

QTAF klinkt sich zunächst in das Eventsystem eines Testframeworks wie etwa TestNG oder Cucumber ein, um die Ausführung und die Ergebnisse von Testfällen zu überwachen. Die nativen Events dieser Testframeworks werden zunächst von QTAF entgegengenommen und standardisiert. Standardisierung bedeutet, dass die nativen Events der Testframeworks in ein neues Format überführt werden. Somit müssen sich Plugins, welche eine Weiterverarbeitung der Events vornehmen, um beispielsweise Reports zu erzeugen, nicht an unterschiedliche Testframeworks wie etwa TestNG oder Cucumber angepasst werden. Die Plugins nehmen nun die standardisierten Events entgegen und verarbeiten diese weiter, beispielsweise indem sie die Testergebnisse auf eine Plattform wie Xray oder in einen Cloudspeicher wie etwa Amazon S3 hochladen.

Das Aufsetzen eines neuen Testprojekts

Das Aufsetzen eines neuen Testprojektes gestaltet sich mittels QTAF sehr einfach. Hierfür ist lediglich das Erstellen eines Maven-Projektes erforderlich, wofür eine geeignete Entwicklungsumgebung wie etwa Eclipse oder IntelliJ verwendet werden kann. Anschließend muss lediglich QTAF als Dependency für das Projekt eingerichtet werden und schon ist die Testumgebung bereit. Die Tester:innen können sofort mit der Erstellung von Testfällen beginnen. Das Reporting dieser Testfälle erfolgt automatisch durch das QTAF-Framework. Welche Features das nun aufgesetzte Testprojekt noch bietet werden wir in den folgenden Abschnitten erläutern.

Testfälle anlegen

Das Anlegen eines Testfalls ist mit QTAF genauso einfach wie bei einem gewöhnlichen TestNG-Projekt. Tester:innen, die mit diesem Framework vertraut sind, werden sich mit QTAF ohne Probleme zurechtfinden. Die Tester:innen legen ihre Testklassen an und versehen diese zusätzlich mit Annotations, welche QTAF bereitstellt. QTAF überwacht während des Testens welche Testfälle ausgeführt wurden und erstellt sowohl JSON- als auch HTML-Reportings aus den aufgezeichneten Daten.

Konfigurierbarkeit

Alle Konfigurationsparameter können entweder über ein JSON-File, über Umgebungsvariablen oder als Kommandozeilenparameter übergeben werden. Dabei bietet QTAF auch die Möglichkeit, Standardwerte aus einer JSON-Datei mittels Umgebungsvariablen oder Kommandozeilenparametern zu überschreiben. Dieses Feature ist vor allem nützlich, wenn Sie das selbe QTAF-Projekt in mehreren Umgebungen mit anderen Konfigurationswerten nutzen möchten. Beispielsweise können Sie eine Standardkonfiguration in einer JSON-Datei angeben und beim Ausführen den Namen des Webdrivers mittels einer Umgebungsvariable oder eines Kommandozeilenparameters überschreiben. Somit können Sie parallel eine Webapp auf mehreren Browsern testen ohne eine Änderung in Ihrem Quellcode vornehmen zu müssen.

Docker und Kubernetes

QTAF ist darauf ausgelegt als Microservice verwendet werden zu können. Durch die Konfigurierbarkeit mittels Umgebungsvariablen ist es möglich, folgendes Szenario zu realisieren: Sie möchten eine Webapp auf den gängigsten Browsern testen (Chrome, Firefox, Edge). Erstellen Sie aus Ihrem QTAF-Projekt ein Docker-Image und erzeugen Sie aus diesem Image mehrere Container-Instanzen. Jede Instanz testet die Webapp mittels eines Webdrivers, dessen Namen Sie über eine Umgebungsvariable übergeben. Somit lassen sich mit der gleichen Codebasis und dem gleichen Docker-Image mehrere Tests parallel auf unterschiedlichen Browsern durchführen. Mittels Docker und Kubernetes ist es ebenfalls möglich, die Docker-Container auf mehrere Server zu verteilen und mit den gängigsten Cloudanbietern wie etwa AWS und Azure zu nutzen.

Selenium Webdriver

QTAF lädt automatisch die aktuellsten Seleniumtreiber für die gängigsten Webbrowser wie etwa Chrome, Firefox, Edge, Internet Explorer oder Opera. Die Tester:innen müssen nach dem Einrichten eines QTAF-Projektes weder die benötigten Treiber installieren noch sich um die Aktualisierung dieser kümmern. QTAF nimmt Ihnen diese Aufgaben ab und kümmert sich selbst um die Beschaffung und Aktualisierung der entsprechenden Treiber.

Android Testing via Appium

QTAF bietet die Möglichkeit, Android-Geräte mittels Appium zu Testen. Die benötigten Treiber für das Testen von Android-Geräten bietet QTAF von sich aus an.

Remote Webdriver

QTAF erlaubt es Ihnen ebenfalls Webtreiber über ein Netzwerk anzusteuern. Dies ist vor allem in Cloud-Umgebungen ein nützliches Feature. Für viele der gängigsten Treiber stehen bereits Docker-Container im offiziellen Docker Registry zur Verfügung.

Saucelabs

QTAF unterstützt die Testausführung auf der Plattform Saucelabs. Saucelabs ist eine Cloudumgebung, in der virtuelle Maschinen mit vorinstallierten Browsern bereitgestellt werden. Dies bietet den Vorteil, dass in kurzer Zeit auf einer großen Anzahl von verschiedenen Browsern, Browserversionen und Betriebssystemen Tests durchgeführt werden können. Die aufgezählten Parameter können QTAF hierbei von außen übergeben werden. Saucelabs unterstützt neben dem Testen von Webanwendungen auch das Testen von mobilen Apps auf den Betriebssystemen Android und iOS. Auch hier liegt der Vorteil von Saucelabs darin, dass die benötigten Geräte nicht durch den Kunden angeschafft werden müssen sondern über Saucelabs geleased und remote gesteuert werden können. Auch hier liegt der Vorteil darin, dass sich Testfälle auf unterschiedlichen Versionen der Betriebssysteme und unterschiedlichen Geräten verschiedener Hersteller effizient testen lassen. Saucelabs wartet mit weiteren Features wie etwa Videomittschnitten und Screenshots der Testläufe auf. Diese können nach der Ausführung des Testdurchlaufs eingesehen und heruntergeladen werden. Sie können jeden Testschritt eines Testfalls mittels Bildschirmaufnahmen nachvollziehen.

QTAF Plugins

QTAF bietet ein eigenes Event-System an, über das Tester:innen eigene Logik in den Testablauf einbringen können oder eigene Plugins für QTAF entwickeln können. So lassen sich beispielsweise eigene Verarbeitungen der erzeugten Reporting-Daten realisieren, beispielsweise eine Anbindung an eine REST-API, eine automatische Benachrichtigung per E-Mail etc. Somit lassen sich Plugins erstellen, die Sie in mehreren Projekten verwenden können oder auch der Community zur Verfügung stellen können.

GitHub Link

QTAF auf GitHub

Gerne beantworten wir Ihnen Fragen und beraten Sie genauer zur Testautomatisierung in Ihrem Projekt. Kontaktieren Sie uns hierfür einfach oder vereinbaren Sie direkt einen kostenlosen Testautomatisierungs-Workshop mit unseren Qytera-Testexperten. Wir wünschen Ihnen viel Erfolg bei Ihrer Testautomatisierung!

10. November 202210. November 2022 Artikel weiterempfehlen:

AI-Unterstützung von IoT-Tests durch trainierbare Bilderkennungssoftware

Lesedauer: 7 Minuten

In diesem Artikel möchten wir Ihnen ein Beispiele zeigen, wie das Testen von IoT-Geräten mittels AI-gestützter Bilderkennung unterstützt werden kann.

Vorstellung des ProjektsDas Testobjekt

In diesem Beispiel wollen wir automatisiert Informationen über den Zustand einer Kaffeemaschine herausfinden. Wir wollen anhand der Anzeige der Maschine automatisiert erfassen, ob der Wassertank in der Maschine eingesetzt wurde und ob sich eine Tasse unterhalb des Auslaufs befindet. Die Schwierigkeit besteht in diesem Beispiel darin, dass die Maschine keine expliziten Testschnittstellen für beide Testfälle anbietet. Es müssten hierfür Sensoren entwickelt und an der Maschine angebracht werden um diese Informationen automatisiert verarbeiten zu können. Dies ist sehr aufwendig, da dies technische Kenntnisse voraussetzt und die Testmethodik einen hohen Grad der Intrusion aufweist und somit einer erfolgreichen Automatisierung im Weg steht. Daher muss eine bessere Lösung gefunden werden.

Die Teststrategie

Wir wollen mit diesem Beispiel zeigen, dass sich mittels AI-gestützter Bilderkennungssoftware diese Testfälle automatisiert durchführen lassen. Hierfür entwickeln wir mittels des Frameworks Tensorflow ein Tool, welches zum einen aus Bildern des Displays der Kaffeemaschine erkennen kann, ob auf diesem eine Warnung wegen des nicht eingesetzten Wassertanks erscheint und zum anderen aus Bildern einer Frontalaufnahme der Kaffeemaschine erkennen kann, ob eine Tasse auf diesen Bildern zu sehen ist. Der Einsatz einer Bildklassifizierungssoftware ist hier sinnvoll, da wir eine begrenzte Anzahl von fest voneinander abgrenzbaren Zuständen haben.

Die Testschnittstelle

Für das automatisierte Testen ist es notwendig, dass die erfassten Daten der Bilderkennung von einer TAS (Test Automation Solution) genutzt werden können. Hierfür sollte es über eine API möglich sein, den Status der Kaffeemaschine abzufragen. Hier empfiehlt es sich eine spezialisierte REST-API zu entwickeln, die über die TAS Daten abfragen oder Daten aktiv durch die Bilderkennungssoftware in eine Datenbank schreiben kann.

Verwendete Technologien

Für die Erstellung des Modells, sowie die Anwendung des Modells auf den Bilddateien, wird die Programmiersprache Python und das Framework Tensorflow verwendet. Die REST-API kann ebenfalls mit Python und einem Framework wie etwa Flask implementiert werden. Es wurden keine kommerziellen Tools von Drittanbietern genutzt.

Erstellung des AI-Modells zur Erkennung der ZuständeTrainingsbilder erstellen

Zum Trainieren des Modells benötigen wir zunächst Bilder, die die Zustände unserer beiden Szenarien zeigen. Für den ersten Testfall benötigen wir zum einen Bilder, die das Display im Normalzustand und zum anderen die entsprechende Fehlermeldung bei fehlendem Wassertank zeigen. Für den zweiten Testfall werden entsprechend Bilder mit und ohne Tasse unter dem Auslauf benötigt. 

Hier sehen Sie eine Auswahl von Trainingsbildern für den ersten Testfall. In der oberen Bildreihe sehen Sie das Display im Normalzustand, unten das Display wenn der Wasserbehälter entfernt wurde. Für den ersten Testfall wurden jeweils 450 Trainings- und 150 Testbilder für jeden der beiden Fälle aufgenommen. Die Bilder wurden von einem Smartphone mit dem Serienbildmodus aufgenommen, daher stellte die Erstellung großer Bildmengen kein Problem dar. Bei der Aufnahme der Bilder wurde die Kamera bewegt und geneigt, sodass Bilder aus verschiedenen Blickwinkeln aufgenommen wurden.

Bild: AI - Bilderkennung (Klicken zum Vergrößern) [Quelle: Qytera] ×

Für den zweiten Testfall wurden Bilder von der Kaffeemaschine einmal mit und einmal ohne Tasse aus verschiedenen Blickwinkeln aufgenommen. Die Tasse wurde hierbei mehrmals an eine andere Position verschoben. Die Bilder wurden zudem aus verschiedenen Blickwinkeln aufgenommen, um eine gewisse Varianz im Trainingsdatenset zu erhalten. Würden die Bilder immer aus dem gleichen Blickwinkel aufgenommen könnte dies später zu schlechteren Ergebnissen bei der Bildklassifizierung führen.

Bild: AI - Bilderkennung - Training (Klicken zum Vergrößern) [Quelle: Qytera] ×

Training des Modells

Nachdem die Trainingsbilder erstellt wurden wird das Modell mit diesen trainiert und lernt dabei die Bilder verschiedener Zustände voneinander zu unterscheiden. Der Zeitaufwand des Trainingsprozesses steigt linear mit der Anzahl der Bilder. In unserem Beispiel haben wir das Modell auf einem Laptop mit einer Intel Core i5 CPU der zehnten Generation trainiert. Für das Training wurde keine Grafikkarte genutzt. Insgesamt benötigte das Training für die insgesamt 1200 Bilder des ersten Testfalls etwa 20 Minuten. Für den zweiten Testfall wurden insgesamt 2100 Bilder aufgenommen, das Training dauerte dementsprechend etwa 40 Minuten. Deutliche Performanceverbesserungen lassen sich beispielsweise schon durch die Verwendung einer Desktop-CPU erzielen. Mittels einer AMD Ryzen 7 CPU konnten die Trainingszeiten um fast 70 Prozent gesenkt werden. Steigt die Bildmenge noch weiter an sollte man zu einer Grafikkarte greifen, um die Zeit für das Training zu verringern. Verfügen Sie selbst nicht über entsprechende Grafikkarten können Cloud-Dienste wie etwa AWS SageMaker weiterhelfen.

Wartbarkeit des Modells

Bei einem AI-gestützten Tool muss vor allem darauf Wert gelegt werden, dass auch Anwender ohne Erfahrung im Bereich des maschinelles Lernens und in unserem konkreten Projekt ohne Erfahrung mit dem Framework Tensorflow den Trainingsprozess des Modells steuern und bedienen können. Tensorflow reduziert den Implementierungsaufwand des Trainingsprozesses bereits erheblich indem es eine API mit einer sehr abstrakten Sichtweise auf den Trainingsprozess anbietet. In unserem konkreten Projekt bauten wir wiederum eine eigene API um das Tensorflow-Framework herum, sodass für das Training des Modells lediglich eine vorgegebenen Benennung für die Verzeichnisse der Bilddateien befolgt werden muss, um neue Bildkategorien bzw. mehr Bilder für vorhandene Kategorien hinzuzufügen. Möchten die Tester:innen neue Bildkategorien hinzufügen, müssen sie dafür lediglich ein neues Verzeichnis anlegen und dort die Trainingsbilder ablegen. Das Modell interpretiert das neu angelegte Verzeichnis automatisch als neue Bildkategorie. Somit können die Tester:innen die AI-Software als Blackbox behandeln und benötigen keinerlei AI-Kenntnisse, um den Trainingsprozess zu starten bzw. um Bilder zu klassifizieren.

Ein AI-Engineer wird jedoch weiterhin unverzichtbar bleiben, wenn es um die Beurteilung der Performanz des Modells geht. Weist ein Modell beispielsweise hohe Trefferquoten auf einem Trainingsdatensatz, aber schlechte Trefferquoten im realen Einsatz auf, kann dies dafür sprechen, dass die Trainingsbilder nicht repräsentativ genug waren oder diese zu wenig Varianz aufwiesen. In unserem Beispiel hätte dies auftreten können, wenn die Kaffeemaschine immer nur aus dem gleichen Blickwinkel fotografiert worden wäre. In diesem Fall sollten Expert:innen zur Beurteilung der Trainingsdaten herangezogen werden.

Evaluation des Modells

Nachdem wir unser Modell trainiert haben müssen wir evaluieren, ob dieses korrekte Vorhersagen macht. Hierfür erstellen wir erneut Bilder, die wir dem Modell zeigen und für die das Modell eine Vorhersage macht. Wichtig ist bei der Evaluierung, dass das Modell Bilder gezeigt bekommt, die es im Trainingsprozess nicht gesehen hat. Somit wird sichergestellt, dass das Modell während des Trainings Informationen über die Bilder gelernt hat, die nicht nur auf die Trainingsbilder anwendbar sind sondern so gut generalisieren, dass diese Informationen auch auf neue, noch nicht gesehene Bilder anwendbar sind.

In unserem Test erreichten wir eine Trefferquote von 100% für die beiden Szenarien. Diese hohen Werte sind vor allem dadurch möglich, da wir beim Training des Modells auf Transfer Learning setzten - ein Verfahren, bei dem große Unternehmen wie etwa Google oder Microsoft Modellarchitekturen entwickeln und auf einem großen Datensatz vortrainieren und diese vortrainierten Modelle Anwendern zur Verfügung stellen.

Nutzung des Modells in einer ProduktionsumgebungAufbau der Produktionsumgebung

Zunächst muss vor der Kaffeemaschine eine Kamera angebracht werden. Hierfür lassen sich beispielsweise Werkzeuge wie ein Raspberry Pi verwenden, da dieser bereits über eine Kameraschnittstelle verfügt und die erzeugten Daten auf dem Raspberry Pi direkt weiterverarbeitet werden können. Auf dem Raspberry Pi wird außerdem das AI-Modell zur Erkennung der Zustände der Kaffeemaschine aufgesetzt, welches die Bilder des Kameramoduls entgegennimmt und die Bilder klassifiziert (Normalbetrieb / Wasser auffüllen) bzw. ( Tasse vorhanden / Tasse nicht vorhanden). Nach der Klassifizierung der Aufnahme stellt der Pi diese Informationen über eine REST-API zur Verfügung, über welche die TAS diese abfragen kann.

Bild: AI - Bilderkennung - Modell (Klicken zum Vergrößern) [Quelle: Qytera] × Verfeinerung der Testmethode durch Objekterkennung in Bildern

In unserem Beispiel haben wir immer das gesamte aufgenommene Bild zur Klassifizierung verwendet. Das verwendete Modell konnte jeweils nur das gesamte Bild klassifizieren (Tasse / keine Tasse bzw. normale Displayanzeige / Wassertank auffüllen). Für einige Use Cases ist eine einfache Bildklassifizierung möglicherweise jedoch nicht ausreichend. Von Interesse könnte ebenfalls sein, ob bestimmte Elemente auf dem Display zu sehen sind, wie etwa die Symbole für Kaffee, Espresso, etc. und auch an welcher Stelle diese zu sehen sind. Dies kann sinnvoll sein, da diese Symbole auch in anderen Kontexten auf dem Display erscheinen, beispielsweise wenn die entsprechende Kaffeesorte ausgewählt wurde und der Kaffee zubereitet wird. Für diesen Use Case haben wir einen Objekterkennungsalgorithmus namens YOLO (You Look Only Once) auf fünf Symbole des Displays trainiert: Kaffee, Espresso, Cappuccino, Heißwasser und das Symbol für das Einsetzen des Wassertanks. Anschließend wurde das trainierte Modell auf eine Videoaufnahme des Displays angewendet. In dem Video wird der Wassertank der Kaffemaschine mehrmals aus der Maschine herausgezogen, sodass das Display abwechselnd die Kaffee-Symbole und den Hinweis zum Einsetzen des Wassertanks zeigt. Der Algorithmus ist nun in der Lage zu erkennen , wann und wo im Video die jeweiligen Symbole zu sehen sind. Das Resultat sehen Sie in folgendem Video:

In einem weiteren Test haben wir den Algorithmus auf die Erkennung unseres Unternehmenslogos trainiert. Ein beispielhaftes Ergebnis dieses Tests sehen Sie in folgendem Bild:

Bild: AI - Bilderkennung - Logo erkennen (Klicken zum Vergrößern) [Quelle: Qytera] × Potential der AI-gestützten Bildverarbeitung

Wie wir anhand dieses Beispielprojekts gezeigt haben können mittels AI-gestützter Bilderkennung Objekte getestet werden, die sich bislang der Testautomatisierung durch fehlende Schnittstellen entzogen haben. Die Bildklassifizierung bietet vor allem bei Anwendungsfällen Potential, bei denen Zustände eines IoT-Geräts anhand von optischen Merkmalen erkannt werden können. Einige denkbare Use-Cases haben wir hier aufgelistet:

Weitere beispielhafte Use Cases

Automatisches Auslesen von Displayinformationen LCD-Displays (Haushaltsgeräte, Industriemaschinen, 7-Segment-Anzeigen) Status-LEDs (leuchtet / leuchtet nicht) Armaturenbrett auslesen (Feststellung ob das Symbol für die Handbremse leuchtet) Testen auf Vorhandensein von Objekten in Bildern Automatische Validierung von Screenshots, welche im Testprozess entstanden sind (Welchem Testschritt ist der Screenshot zuzuordnen?) Testen, ob auf einem Screenshot ein bestimmtes Element zu sehen ist (Button, Formular, etc.) Bestimmung der Anzahl und Position bestimmter Objekte auf einem Bild Testen, wie viele Objekte eines Typs auf einem Screenshot zu sehen sind und wo diese sich befinden Bestimmung der Anzahl und der Art von Objekten auf einem Fließband in einer Fertigungsanlage Klassifizierung von Dokumenten anhand Logos / Bildern / anderer graphischer Informationen auf den Dokumenten Viele eingescannte Dokumente sollen automatisch klassifiziert werden Prüfen, ob eine Unterschrift auf einem Dokument vorhanden ist

Risiken der AI-gestützten Bildverarbeitung

Zu den Risiken der AI-gestützten Bilderkennung zählt, dass Modelle, die mit einem kleinen Datenset trainiert wurden (einige dutzend Bilder pro Kategorie), sensibel auf Änderungen der Eingabebilder reagieren. Ändern sich Elemente auf dem LCD-Display im Laufe der Entwicklung des Testobjekts, wie in unserem Fall der Kaffeemaschine, kann das die Qualität der Vorhersage der AI beeinflussen. AI-Lösungen bieten sich daher an, wenn das Entwicklungsprojekt bereits eine gewisse Stabilität erreicht hat. Für Regressionstests wäre ein AI-Tool hervorragend geeignet, da bereits bekannte Testergebnisse überprüft werden können. Doch auch während der Entwicklung des Testobjekts kann mit dem Aufbau einer AI-Lösung begonnen werden. Es können bereits automatisierte Pipelines für das Trainieren der Modelle auf dem Bildmaterial angelegt, sowie Bilder für das Training der Modelle erstellt werden. Generell gilt, dass die Trainingsbilder stets mit den tatsächlichen optischen Merkmalen der Kaffeemaschine übereinstimmen müssen.

Die AI-Pipeline im Betrieb

Während des Testprozesses sollte die Klassifizierung der Bilder durch die AI überprüft werden. Dies kann zum Teil automatisiert geschehen, indem Bilder, für die die AI keine eindeutige Klassifizierung vornehmen kann, zunächst an einem separaten Ort abspeichert und diese später manuell einer Bildkategorie zuordnet und anschließend dem Trainingsdatenset hinzufügt werden. Anschließend kann die AI auf dem erweiterten Datenset erneut trainiert werden, wodurch das Risiko von falsch klassifizierten Bildern im Laufe Zeit immer weiter gesenkt wird.

Fazit

AI-gestützte Bildverarbeitung bietet ein großes Potential in der Testautomatisierung bei der Beobachtung von IoT-Geräten, die nur unzureichend automatisierbare Testschnittstellen zur Verfügung stellen. Mittels AI-Werkzeugen werden alle denkbaren Ausgaben des IoT-Gerätes, sei es von einfachen Status-LEDs bis hin zu LCD-Displays zu Testschnittstellen, die mit einem minimalen Grad der Intrusion abgefragt werden können. Das gesamte physische Gerät wird somit zu einer testbaren UI.

Gerne beantworten wir Ihnen Fragen und beraten Sie genauer zur Testautomatisierung in Ihrem Projekt. Kontaktieren Sie uns hierfür einfach oder vereinbaren Sie direkt einen kostenlosen Testautomatisierungs-Workshop mit unseren Qytera-Testexperten. Wir wünschen Ihnen viel Erfolg bei Ihrer Testautomatisierung!

Image by macrovector on Freepik

25. Oktober 202201. November 2022Finden Sie weitere interessante Artikel zum Thema:  Artikel weiterempfehlen: