Fehlermeldung

Deprecated function: The each() function is deprecated. This message will be suppressed on further calls in menu_set_active_trail() (Zeile 2404 von /kunden/92451_10115/webseiten/campero.de/drupal7_en/includes/menu.inc).

Sammlung von Newsfeeds

Aufgaben eines Testautomation Engineers

Qytera News -

Lesedauer: 4 Minuten

In Zeiten zunehmender Digitalisierung ist die Automatisierung der Tests ein essenzieller Bestandteil von Softwareentwicklungsprojekten. Gerade in komplexeren Projekten empfiehlt es sich, professionelle Hilfe durch einen Testautomation Engineer einzuholen. Zudem gehen wir in diesem Blogartikel auch darauf ein wie man zu einer ISTQB Advanced Level Test Automation Engineer Zertifizierung kommt. Zunächst beginnen wir mit den unterschiedlichen Tätigkeiten, die sich ein professioneller Test Automation Engineer in seiner täglichen Arbeit stellt.

Was ist ein Testautomation Engineer?

Ein Testautomation Engineer ist ein Entwickler oder Tester mit soliden Kenntnissen in den Bereichen Qualitätssicherung, Qualitätsmanagement und Entwicklung. Die Tiefe der benötigten Kenntnisse differiert hierbei stark je nach Art des Entwicklungsprozesses, des System Under Test (SUT) und der eingesetzten Tools.

Typische Aufgaben eines Testautomation Engineers

Zu den typischen Aufgaben einen Testautomation Engineers gehört das Schreiben, Warten und Ausführen von automatisierten Testfallskripten. Diese können auf jeder Ebene der Testpyramide angesiedelt sein. So können Tests auf Komponentenebene (z.B. Unit Test), Integrationsebene (z.B. API Test) und/oder der UI-Ebene (z.B. Seleniumtest) zu den Aufgaben eines Testautomation Engineers gehören.

Bild: Rolle eines Testautomation Engineers bei Testautomatisierungslösungen. (Klicken zum Vergrößern) [Quelle: Qytera] × Auswahl der Testautomatisierungs-Tools

Eine weitere Aufgabe des Testautomation Engineers ist die Beratung des Testmanagers oder die direkte Auswahl des richtigen Automatisierungstools. Hierbei müssen die Anforderungen, Kenntnisse der Tester und Eigenschaften des Testobjekts berücksichtigt werden. Sollte das Tool auch von Mitarbeitern ohne tiefe Programmierkenntnisse bedient werden können, lohnt es sich oft, auf Tools mit einer integrierten Aufnahmefunktionen (z.B. Ranorex zu setzen. Der Testautomation Engineer ist hierbei vor allem für komplexere Funktionen, Konfigurationen und die Architektur zuständig.

Auswahl der richtigen Testautomatisierungsarchitektur

Der Testautomation Engineer ist auch für Entwurf, Entwicklung und Weiterentwicklung der Automatisierungslösung zuständig. Hierbei müssen die Anforderungen und Größe des SUT beachtet werden. Sollte die Test Automation Solution (TAS) für einen längeren Zeitraum eingesetzt werden sowie eine größere Anzahl von Testfällen enthalten, lohnt es sich häufig, auf bewährte Methoden oder Entwurfsmuster wie das Page Object Pattern Design zu setzen. Hierbei wird die Test Automation Architectur (TAA) so gestaltet, dass verschiedene Seiten einer Applikation in einzelne Objekte gegliedert werden. Somit ist die TAS leichter wartbar, da Änderungen nur an einer zentralen Stelle gepflegt werden müssen anstatt in jedem Testfall.

Eine andere Möglichkeit ist es, die Fachseite mit in die Automatisierung einzubinden. Hierzu empfehlen sich Ansätze wie ein Keyword oder Behaviour Driven Design (wie BDD). Bei beiden Ansätzen werden die Automatisierungsskripte in eine leicht verständliche (Meta-) Sprache übersetzt, um sie auch für Mitarbeiter mit wenig Programmierkenntnissen leichter zugänglich zu machen. Ebenso sind künftige Anforderungen, wie die Anbindung der TAS z.B. an eine CI/CD Pipeline zu berücksichtigen.

Bild: Testautomatisierungs-Framework für den Testautomation Engineer. (Klicken zum Vergrößern) [Quelle: Qytera] × Reporting

Bei der Erstellung des TAF ist zudem auf das richtige Reporting zu achten. Die Ergebnisse können je nach Anforderungen, z.B. per Mail, über eine eigene Reportingseite oder direkt im Testmanagementtool gespeichert werden. Die Auswertung und die Ergebnismeldung an den Testmanager oder Kunden liegen ebenfalls im Verantwortungsbereich des Testautomation Engineers.

Optimierung einer bestehenden Test Automation Solution

In vielen Projekten sind bereits kleine Testsuiten für Regressionstests oder Smoke Tests vorhanden. Diese stoßen jedoch ohne sorgfältige Planung oft schnell an ihre Grenzen, da sie schlecht wartbar oder langsam sind. Deshalb ist ein wesentlicher Bestandteil der Aufgaben eines Testautomation Engineers die Optimierung der bestehenden TAS.

Dies kann über verschiedene Wege verfolgen: z.B. eine solide Grundarchitektur zu entwickeln, um die Wartbarkeit zu steigern oder die TAS für eine Parallelausführung durch z.B. Jenkins oder Selenium Grid vorzubereiten. Eine andere Möglichkeit ist es, bestehende, mehrfach ausgeführte Testschritte oder Testfälle die z.B. auf der Systemeben ausgeführt werden, durch schnellere Funktionen auf der Integrationsebene auszutauschen. Außerdem sollten auch die Testfälle regelmäßig einem Review unterzogen werden, um gegebenenfalls alte und nicht mehr kritische Testfälle durch aktuelle zu Ersetzen.

Bild: Software-Entwicklungs-Lebenszyklus für einen Testautomation Engineer. (Klicken zum Vergrößern) [Quelle: Qytera] × Auswahl der Testautomatisierungsstrategie

Der Testautomation Engineer entscheidet oder berät den Testmanager ebenfalls in der Auswahl der richtigen Testautomatisierungsstrategie. Testautomatisierung lohnt sich vor allen bei Tätigkeiten, die oft wiederholt werden müssen, wie dem Regressionstest. Es lohnt sich jedoch oft auch, Ansätze wie risikobasiertes Testen oder der Automatisierung nach User Journey (szenariobasiertes Testen) mit in die Automatisierung einfließen zu lassen. Hierbei kann aus verschiedenen Ansätzen gewählt und kombiniert werden. Dadurch besteht ein Teil der Aufgaben auch darin, die bereitgestellten manuellen Testfälle zu überarbeiten und für die Automatisierung zu optimieren.

Ebenso ist eine Planung für die Durchführung der Testfälle nötig. So kann ein Regressionstest z.B. über ein Nightly Build ausgeführt werden, wohingegen ein Smoketests durch eine Änderungen in der Software ausgelöst werden kann.

Wie wird man Testautomation Engineer und welche Rolle spielen dabei Zertifizierungen?

Eine Ausbildung zum Testautomation Engineer im herkömmlichen Sinne existiert nicht. Es gibt allerdings die Möglichkeit, sich nach ISTQB (International Software Testing Qualifications Board) zertifizieren zu lassen. Hierfür muss man zuerst das Zertifikat ISTQB Certified Tester Foundation Level erlangen, für welches man mindestens 18 Monate Tätigket im Testbereich nachweisen muss. Im Anschluss kann man dann das Zertifikat ISTQB Advanced Level Test Testautomation Engineer anstreben.

Das Erwerben von Zertifizierungen hat mehrere Vorteile für Ihre Berufslaufbahn als professioneller Tester. Zum einen punkten Sie bei der Bewerbung für eine Stelle im Bereich Testautomation Engineer. Hier ist es auch nicht falsch, wenn man zusätzlich noch Zertifikate im Bereich Test Analyst oder Technical Test Analyst vorweisen kann. Häufig wird bei der Wahl einer Besetzung darauf geachtet, dass die nötigen Zertifizierungen vorliegen.

Zum anderen lernt man viele Standards in unterschiedlichen Bereichen wie Testarchitektur oder Testautomatisierung Planung. Die Standards, welche mit den ISTQB-Zertifizierungen erlernt werden können, sind in der Praxis erprobt und bilden eine Basis, auf der man schnell mit anderen Personen zusammenarbeiten kann. Sowohl Begrifflichkeiten als auch Abläufe sind bei gleicher Basis des Teams eine spürbare Erleichterung.

Zusätzlich ist es mit dem Wissen, welches man durch die Zertifizierungen erlangt, eine spürbare Erleichterung, sich in einem neuen Umfeld zurechtzufinden.

Fazit

Die Aufgaben eines Testautomation Engineer sind vielschichtig und haben Bezug zu vielen anderen Tätigkeiten in der Softwareentwicklung. Deshalb ist eine gute Kommunikationsfähigkeit ein Bestandteil der Fähigkeiten eines Testautomation Engineers. Durch eine schnelllebige digitale Welt und der Anforderung, neue oder geänderte Funktionalitäten immer schneller dem Anwender zu Verfügung zu stellen, ist Testautomatisierung ein fester Bestandteil der modernen Softwareentwicklung geworden. Ein Testautomation Engineer kann ihnen hierbei helfen, die Qualität ihrer Software besser abzusichern.

13. Oktober 202013. Oktober 2020Finden Sie weitere interessante Artikel zum Thema:  Artikel weiterempfehlen:

Testdatenmanagement mit XDM - Effiziente und moderne Testdatenversorgung

Qytera News -

Lesedauer: 2 Minuten

Immer schneller werdende Softwareentwicklungszyklen, steigende Kosteneffizienz und sich stetig verbessernde Qualität haben dazu geführt, dass Testdatenmanagement integraler Bestandteil der Softwareentwicklung geworden ist.

Praktiken wie Continous Delivery, Continous Integration und DevOps sind maßgeblich an dessen Entwicklung beteiligt, da sich die Bereitstellung von Testdaten an die schnellen Entwicklungszyklen der Softwareentwicklung anpassen muss. Automatisierung und Flexibilität sind unverzichtbar, damit passende Testdaten zu jedem Zeitpunkt bereitstehen können. Es darf keine wertvolle Zeit darauf verwendet werden, Testfälle vor jedem Test mühsam zusammenzustellen oder immer dieselben starren Testfälle zu verwenden.

Testdatenmanagement wird damit zu einer der wichtigsten Bedingungen für den Erfolg der Software. Ziel des Testdatenmanagements ist die Planung, Organisation und Bereitstellung zielgerichteter Testumgebungen.

XDM – Agile Testdaten für agile Softwareentwicklung

XDM stellt Testdaten flexibel und automatisch in zeitlich definierten Abständen oder bei Bedarf ad-hoc bereit. Dabei automatisiert XDM sämtliche Datenbankoperationen und garantiert regelmäßige Ausführung über einen Scheduler. Die dabei transportierten Daten können inhaltlich verändert oder maskiert (anonymisiert / pseudonymisiert) werden. Ein sicherer Testdatenaustausch wird somit garantiert – Testdaten sind zu jedem Zeitpunkt verfremdet.

XDM ist nicht auf die reine Datenbereitstellung beschränkt, sondern ist ebenso in der Lage, Strukturanpassungen vorzunehmen. Die mit XDM kopierten Daten werden in für Testdaten vorgesehene Umgebungen abgelegt, die dann für einzelne Tests verwendet werden können oder als Basis für weitere Testumgebungen dienen.

Der XDM DataShop stellt das abteilungsübergreifende, zentrale Kommunikationsmittel der Testdatenbereitstellung dar – hier werden Kopieraufträge formuliert, überwacht und koordiniert.

Der DataShop ermöglicht es Bedarfsträgern, wie Entwicklern und Testern, Testdaten flexibel über ein Bestellportal anzufordern. Testdaten werden entweder auf Basis von Testfällen (zusammenhängenden Tabellenzeilen; ideal für kleinere Softwarekomponenten) bereitgestellt oder in Form von Massendaten (komplette Tabellen). Letztere eignen sich optimal für Tests, die größere Datenmengen benötigen, wie Stresstests oder Systemtests – also solche, die Anwendungen holistisch und auf Belastbarkeit testen.

Effizienz durch Spezialisierung

Mit Hilfe von XDM können verschiedene Arbeitsbereiche und Teilgebiete des Testdatenmanagements funktional getrennt werden. Dadurch ist es im Unternehmen möglich, einzelne Aufgaben bestimmten Abteilungen zuzuteilen. Alle Beteiligten nutzen eine bestimmte Komponente von XDM, welches dadurch als zentrales Kommunikationsmittel fungiert und gemäß modernen Praktiken, wie DevOps, die bessere Vernetzung der Bereiche Entwicklung (Development) und Betrieb (Operations) vorantreibt.

Unterschieden wird grundsätzlich zwischen Modellierern und Bestellern. Während Modellierer in Form von Datenbankadministratoren und Anwendungsarchitekten als technisch versierte Benutzer Grundlagen für eine flexible Testdatenbereitstellung – wie Bestellmasken, Kopieraufträge, Verbindungen und Regeln schaffen, müssen Besteller in Form von Testern und Entwicklern lediglich Testdaten anfordern.

Bild: Test Data Delivery Pipe mit XDM. (Klicken zum Vergrößern) [Quelle: UBS Hainer] × Erstellen Sie Ihre eigene Test Data Delivery Pipe

Ausgangsbasis des skalierbaren Testdatenmanagementkonzepts ist die Golden Copy, eine von der Produktion (durch Klonen) entkoppelte Testdatenumgebung, die in der Regel aus mehreren Datenbanken unterschiedlichen Typs besteht, welche gemäß geltenden DSGVO-Richtlinien während des Erstellprozesses anonymisiert (bzw. pseudonymisiert) wird.

Aus der Golden Copy können fachlich zusammenhängende Teile selektiert werden, die anschließend in eine neue Umgebung geladen werden.

Die Inhalte dieser Umgebungen entsprechen dem dafür vorgesehenen Zweck. Beispielsweise kann eine System-Test-Umgebung erstellt werden, die Datengrundlage für einen System-Test bereitstellt. Umgebungen können dabei entweder für den vorhergesehenen Zweck jedes Mal neu erstellt oder sukzessive erweitert werden.

Ein Testfall kann beispielsweise von einem Entwickler oder einem Tester über den DataShop bestellt werden. Dazu ruft dieser die Bestellmaske auf, die dem Zweck seiner Bestellung am besten entspricht, bestimmt die Parameter und führt die Bestellung schließlich durch.

Beispielsweise können gewünschte Testfälle spezifiziert oder deren Anzahl bestimmt werden. Möglich ist auch die Nutzung integrierter Modifikationsmethoden, die Daten während des Kopiervorgangs anpassen können. Sämtliche in XDM genutzte Prozesse können von Dritt-Software über eine Schnittstelle bedient werden. Darüber hinaus lassen sich externe Skripte oder Tools über XDM anstoßen.

Fazit

Die XDM Test Data Delivery Pipe fügt sich somit nahtlos in bestehende Prozesslandschaften ein und hebt diese auf ein neues Level! Lange Wartezeiten beim Beschaffen wichtiger Testdaten gehören damit der Vergangenheit an.

Über den Autor

Florian Kattner

Florian Kattner ist technischer Consultant bei UBS Hainer und berät Kunden zu Themen wie Testdatenmanagement und (DSGVO-konformer) Datenverfremdung. Darüber hinaus führt er zu diesen Themen Seminare durch und tritt als Redner auf Veranstaltungen auf.

01. Oktober 202001. Oktober 2020Finden Sie weitere interessante Artikel zum Thema:  Artikel weiterempfehlen:

Pentesting mit OWASP ZAP: Erfahrungsbericht, Vor- und Nachteile

Qytera News -

Lesedauer: 2 Minuten

Der Penetrationstest ist eine besondere Form des Softwaretests, bei der die Applikation auf Sicherheitsrisiken und Verwundbarkeiten geprüft wird. Das Ziel des Testers ist es, von außen Zugriff auf das System zu erlangen und damit die Möglichkeiten von Datendiebstahl oder gezielten Angriffen auf das System aufzudecken. Hierfür gibt es verschiede Tools auf den Markt, wovon wir eines in diesem Beitrag näher beleuchten werden.

OWASP ZAP

OWASP ZAP ist ein Open-Source Security Scanner für Webapplikationen. Es stellt dem Anwender verschiedene Möglichkeiten für einen Penetration Test bereit, womit es für Einsteiger als auch für Fortgeschrittene eine gute Alternative zu kommerziellen Anwendungen darstellt. OWASP ZAP ist für Linux, Windows und OS X verfügbar.

Hauptkomponenten von OWASP ZAPAutomated Scan

Der wohl einfachste Weg, einen Securitytest auszuführen, ist über den Automated Scan von OWASP ZAP. Es wird nur die zu testende URL benötigt und das Tool führt den Rest von alleine aus. Über einen Webcrawler werden nun alle verfügbaren Ressourcen erfasst und anschließend auf gängige Sicherheitsfehler, wie unsichere Header, geprüft.

Bild: Automated Scan mit OWASP ZAP. [Quelle: OWASP ZAP] Manual Scan

OWASP ZAP bietet neben dem Automated Scan auch die Möglichkeit, einen manuellen Scan durchzuführen. Hierzu wird ein interner Browser auf Chrome- oder Firefox-Basis benutzt, der den Internettraffic aufzeichnet und diesen passiv auf bekannte Verwundbarkeiten, wie unsichere Cookies oder ungeschützte Session-IDs, scannt. Diese Funktionalität lässt sich einfach in den manuellen Testprozess einbinden und bietet so die Möglichkeit, ohne nennenswerten Mehraufwand einen rudimentären Pentest auszuführen.

Bild: Die potenziellen Sicherheitslücken werden in einer Session aufgezeichnet, welche exportiert und später ausgewertet werden kann. [Quelle: OWASP ZAP] Bild: OWASP ZAP bietet auch eine Erklärung zu den gängigsten Sicherheitslücken. [Quelle: OWASP ZAP] Resend Tool

Mit dem Resend Tool ist es möglich, bereits aufgezeichnete Requests erneut zu senden und gegebenenfalls zu manipulieren. Dies ist vor allem beim Testen von Zugriffsrechten oder Authentifizierungen interessant.

Bild: Mit dem Resend Tool können aufgezeichnete Requests erneut gesendet werden. [Quelle: OWASP ZAP] Deamon Mode

Es ist möglich, OWASP ZAP ohne UI auszuführen und im Hintergrund passiv zu scannen. Dies ist vor allem für bestehende Automatisierungslösungen interessant. Starten Sie OWASP ZAP mit einer Batchdatei vor Ihren Automatisierungsskripten und werten Sie anschließend die entstandenen Logfiles aus. OWASP ZAP bietet für Selenium sogar eine noch einfachere Anbindung. Hierzu hat OWASP eine kurze und verständliche Anleitung erstellt, wie OWASP ZAP mit Selenium angebunden werden kann.

The ZAP Marketplace

ZAP bietet außerdem einen internen Marktplatz, über den sich schnell und einfach Plugins und Erweiterungen installieren lassen.

Vorteile
  • Open Source
  • Vielseitig konfigurierbar und anpassbar
  • Einfache Bedienung
  • Schneller Start in den PenTest
Nachteile
  • Die Auswertung der LogFiles benötigt Pentest Kenntnisse
  • Die Anpassung der Scanrules erfordert tiefe fortgeschrittene Kenntnisse in Entwicklung und Test
  • Der aktive Scan stellt eine potenzielle Gefahr für die getestete Applikation dar
Kommerzielle AlternativenFazit

OWASP ZAP bietet eine solide Grundlage an Funktionen, die für den Pentest benötigt werden. Durch die verfügbaren Scanrules und den automatischen Scan ist es ohne viel Vorkenntnis möglich, die gängigsten Sicherheitslücken aufzuspüren. Für die Auswertung und das Aufspüren weiterer Fehler wird jedoch tieferes Fachwissen benötigt. Hierzu empfiehlt sich eine Schulung zum Thema ISTQB Advanced Level Security Tester zu besuchen.

17. September 202017. September 2020Finden Sie weitere interessante Artikel zum Thema:  Artikel weiterempfehlen:

Erfahrungsbericht "German Testing Days" 2020

Qytera News -

Lesedauer: 3 Minuten

Die „German Testing Days“ fanden im September 2020 zum ersten Mal als reine Onlinekonferenz statt. Die Konferenzbeiträge wurden in drei parallelen Tracks präsentiert.

Besuchte Vorträge - Tag 1

In der Keynote „Delivery is still all about people“ von Lindsay Uittenbogaard am 1. Konferenztag ging es um Verständigungsprobleme im Team auf Grund unterschiedlicher Perspektiven der Beteiligten und Möglichkeiten, diese durch ein Team Alignment zu verringern.

Auch im Vortrag von Michael Mahlberg zu Continuous Delivery standen die Menschen im Vordergrund: die Toolseite alleine kann die Funktionsfähigkeit von Continuous Delivery nicht garantieren. Mahlberg zeigte Kriterien für geeignete Integrationszeitpunkte auf und stellte die Verantwortlichkeit der Featureentwickler für eine gelungene Integration heraus.

Im Mittelpunkt der Präsentation von Stephan Schramm stand das Testen in der CI/CD-Pipeline eines Unternehmens der Automobilbranche. Auf Basis eines praxiserprobten Testarchitekturmodells wurden im dargestellten Projekt für jede Teststufe Testfälle entwickelt, automatisiert und in Pipelines ausgeführt. Neben der Vorstellung des Prozesses stellte Schramm auch Metriken vor, insbesondere zum prozentualen Automatisierungsanteil jeder einzelnen Teststufe.

Mit dem QA Navigation Board gibt es ein Visualisierungsmittel für die QA-Strategie in agilen Teams. Kay Grebenstein stellte dar, wie sich über Anti-Patterns Handlungsempfehlungen aus den dokumentierten Konstellationen von QA Navigation Boards ableiten lassen.

Bastian Baumgartner und Katja Meyer beschrieben in „Testmaster“ eine Rolle, die bei Projekten mit mehr als 5 Scrum-Teams Vorteile bringt für die teamübergreifende Testkoordination. Die Rolle Testmaster wurde explizit von der Rolle Testmanager abgegrenzt. Auf Basis einer Umfrage mit ca. 500 Teilnehmern wurde der Handlungsraum für die Rolle abgesteckt, wobei die Referenten detaillierter auf seine Aufgaben im übergreifenden Fehlermanagement und beim Management von Testumgebungen eingingen.

Für die Selbstorganisation agiler Teams ist die Bildung einer Testgilde vorteilhaft. Gründungsgesichtspunkte, Zusammensetzung und Aufgaben einer Testgilde wurden von Gerhard Haupt dargestellt.

Besuchte Vorträge - Tag 2

Politische und ethische Aspekte von Technologie als Handlungsfelder standen zu Beginn des 2. Konferenztags im Mittelpunkt der Keynote „Ethical Tech“ von Cennydd Bowles. Die Situation von „Ethical Tech“ innerhalb von Technologie-Konzernen und bei Technologienutzern wurde vorgestellt. Ethische Gesichtspunkte beim Einsatz von Informationstechnologien sollten nach Meinung des Referenten künftig das Handeln der Tech-Konzerne stärker bestimmen. Auch bei der QA von Software sollten die Aspekte von „Ethical Tech“ berücksichtigt werden.

In „Jirautomatic“ zeigten Markus Duus und Roelof Meyer, wie das Process Automation Tool Servicetrace mit dem Testmanagementtool XRay für Jira integriert werden kann. Wesentliches Ziel dieser Integration ist es, die Ergebnisse der automatisierten Testausführung mit den übrigen Artefakten in Jira zusammen zu führen.

Im Vortrag „Spock und AsciiDoc“ stellten Christian Fischer und Ralf Müller vor, wie Testgerüste mit Specflow generiert und aus den erstellten Testfällen mit AsciiDoc eine spezifikationsähnliche Dokumentation abgeleitet werden kann. Umgekehrt zeigten sie auch auf, wie aus AsciiDoc Spezifikationen Tests generiert werden können.

Unter dem Titel „OWASP Top 10“ stellte Frank Ully das Thema Security in den Vordergrund. OWASP steht für „Open Web Application Security Project“. Der Referent stellte die 10 wichtigsten Bedrohungsarten der OWASP kurz vor und zeigte Wege auf, wie den einzelnen Bedrohungen zu begegnen ist.

In der Präsentation von Andreas Rau ging es um themenorientiertes Testen. Zusammenhänge zwischen Webelementen und deren Nutzung in einem bestimmten Kontext werden dabei mit maschinellem Lernen erschlossen. Im Zielbild des Referenten stand das geräte- und anwendungsunabhängige Ausfüllen von Webformularen im Rahmen von Tests, wobei er das Vorgehen beispielhaft am Test eines Kreditkartenantrags demonstrierte.

Alexander Käsbohrer und Steve Barreto präsentierten die Herausforderungen der Testautomatisierung und stellten die Vorteile des Einsatzes der Produkte der Firma Eggplant dar.

Weitere Vorträge

Nicht von mir besucht, aber sicherlich von Interesse waren Vorträge zu modell-basiertem Testen, Crowd Testing, Compatibility Testing of Microservices, Fuzz Testing, sowie zum Testen von Testinfrastruktur, von APIs und von neuronalen Netzen. Testcontainer mit Docker konnten von Konferenzteilnehmern sogar praktisch erprobt werden.

Entwicklungsnah wurden Unit Tests, TDD sowie Möglichkeiten zur Generierung von Unittests behandelt. Competitive Pair Programming und das Mocken von APIs wurden ergänzend beleuchtet.

Nicht unbeachtet blieben Möglichkeiten von Text Analytics für die QS von Tests, sowie Einsatzerfahrungen mit der Test Gap Analyse.

Die Rolle von Testern im agilen Team war Gegenstand von drei Vorträgen. „Quality Titans“ helfen, die Qualitätsperspektive bei allen Beteiligten im Softwareentwicklungsprozess zu verankern.

Als Randthema wurden auch Werkverträge für den Test behandelt.

Besonderheiten des Onlineformats

Bis auf Einzelfälle haben Technik und Organisation gut geklappt.

Nach den Vorträgen gab es Gelegenheit in sogenannten Coffee Lounges Fragerunden fortzusetzen. An beiden Konferenztagen konnte jeweils ein Vortrag um die Mittagszeit in einer Networking Lounge fortgesetzt werden. Die Teilnehmer hatten in diesem Format die Gelegenheit, sich in Wort und Bild in die Diskussion einzubringen.F

Für die Vorträge wurden zwei technische Formate eingesetzt, wobei es nur bei einem der Formate möglich war, die anderen Vortragsbesucher und deren Chatbeiträge einzusehen.

Alle Vorträge wurden aufgezeichnet und so ist es möglich, sich zumindest im Nachhinein die Vorträge anzusehen, an denen man auf Grund der Parallelität nicht teilnehmen konnte.

Fazit

Die Konferenz brachte ein breites Spektrum an Testthemen, wobei die Schwerpunkte auf Testmethodik und Teamaspekten lag, während Testautomatisierung eher am Rande behandelt wurde. Auch wenn der persönliche Austausch nur eingeschränkt möglich war, hat sich aus meiner Sicht das Onlineformat der German Testing Days bewährt.

11. September 202011. September 2020Finden Sie weitere interessante Artikel zum Thema:  Artikel weiterempfehlen:

Lasttest und Performancetest mit JMeter

Qytera News -

Lesedauer: 2 Minuten

Bei JMeter handelt es sich um ein von der Apache Foundation entwickeltes Tool für Last-, Performance- und Stresstests. Die Software ist Open Source und in Java programmiert. (Zur Ausführung wird eine Java-Installation benötigt.)

Der ursprüngliche Ansatz, der beim Einsetzen von JMeter verfolgt werden sollte, war eng mit dem Testing von Web-Applikationen verbunden. Mittlerweile hat das Tool viele weitere Schnittstellen erhalten, die das Testen von weiteren Applikationsarten (wie Schnittstellen, Mailserver, Datenbanken, Verzeichnisdienste, etc.) ermöglichen. Im Folgenden zeigen wir Ihnen einige der wichtigsten Features der JMeter Software.

Verschiedene Timer

Ihre echten User klicken nicht gleichmäßig über alle Seiten: Sie lesen den Inhalt einer Seite und gehen dann weiter. Dies kann mit verschiedenen Timern (mit fest eingegebenen oder auch zufälligen Zeitintervallen) simuliert werden.

Pre- und Post-Processing

Pre-Processors führen Tasks aus, bevor ein Abruf geschieht, Post-Processors danach. Pre-Processors dienen also der Vorbereitung eines bestimmten Aufrufs, beispielsweise indem sie Daten für den Aufruf erhalten. Post-Processors machen hingegen etwas mit den erhaltenen Daten aus dem Abruf. Ein häufiges Beispiel: zur Spamvermeidung ändern sich unsichtbare Formularinhalte ("nonce" = used only once), die dann vor jedem Absenden neu abgerufen werden müssen. Dies geschieht per Pre-Processor. Vor allem für die Nutzung von APIs gibt es den JSON-Extractor, der Inhalte aus einem JSON-Objekt extrahieren kann.

Gibt es ein Reporting-Feature?

Das Thema Reporting ist insbesondere für Last-, Performance- und Stresstests nötig. Hier wird mit großen Datenmengen gearbeitet, welche mit statistischen Methoden ausgewertet werden. JMeter bietet die Möglichkeit, einfach und schnell dynamische Reports, Diagramme und Graphen aus den erfassten Messungen zu generieren. Nachfolgend sind vier Beispiele aufgelistet.

Bild: JMeter APDEX-Tabelle. [Quelle: Apache Software Foundation]

Die APDEX-Tabelle (Application Performance Index) ist ein Standard, um die Nutzerzufriedenheit aus den Daten abzulesen. Ein APDEX wird für jede Transaktion mit dem jeweiligen Schwellenwerten berechnet. Im Request-Summary-Graphen wird der prozentuale Anteil an erfolgreich bzw. nicht erfolgreich durchgeführten Transaktionen dargestellt.

Bild: JMeter Statistics-Tabelle. [Quelle: Apache Software Foundation]

Die Statistics-Tabelle ist eine Übersicht aller Metriken einer Transaktion (eingeschlossen der drei konfigurierbaren prozentualen Spalten).

Bild: JMeter Errors-Tabelle. [Quelle: Apache Software Foundation]

Mithilfe der Errors-Tabelle wird die Gesamtanzahl an Fehlern und deren prozentualer Anteil aus der Gesamtanzahl an Requests dargestellt.

Bild: JMeter Antwortzeiten Diagramm. [Quelle: Apache Software Foundation]

Ein zoombares Diagramm mit dem sämtliche Transaktionen nach folgenden Ereignissen anzeigt werden: Antwortzeiten während einer Zeitperiode; Datendurchfluss während einer Zeitperiode; Latenzen während einer Zeitperiode; Hits pro Sekunde; Codes pro Sekunde; Transaktionen pro Sekunde

JMeter mit Selenium ...?

In unserem Selenium-Seminar weisen wir immer wieder darauf hin, dass Selenium sich nicht für Last- und Peformancetests eignet. Aber manchmal wird doch mehr benötigt als JMeter allein schafft. Auf der Website von Blazemeter wird eine Schritt-für-Schritt Anleitung vorgestellt, wie die Integration beider Tools gelingen kann. Aber ist sie notwendig, was wird damit erreicht? Somit wird die Infrastruktur geschaffen, Lasttests/Performancetests durchzuführen, in den mit dem "echten" Webbrowser interagiert wird und wiederum Selenium WebDriver durch JMeter aufgerufen wird. Diese Integration verschafft den Vorteil beim Lasttest, dass auch die Rendering-Zeiten vom Webbrowser berücksichtigt werden, die sonst nicht in die JMeter-Statistik einfließen.

Fazit

JMeter ist ein hervorragendes Tool für Last- und Performancetests, das allem durch die Anwendungsbreite punktet: heute können Sie damit Lasttests mit Webseiten durchführen, morgen Stresstests mit APIs und auch Sie die Performance Ihrer Datenbanksysteme können Sie damit testen. Darüber hinaus haben Sie vielfältige Möglichkeiten, Reports zu erstellen - und diese sind für die Interpretation der Ergebnisse essenziell. Soll es außerdem eine Open Source Software sein, die von einer bekannten Organisation verwaltet wird, kommen Sie an Apache JMeter nicht vorbei.

01. September 202025. September 2020Finden Sie weitere interessante Artikel zum Thema:  Artikel weiterempfehlen:

Qytera Webinar zum Thema DevOps / Continuous Testing am 24.09.

Qytera News -

Lesedauer: 1 Minute

DevOps ist nicht erst seit der Digitalisierungsoffensive und der digitalen Transformation in aller Munde. Das Konzept greift in die Änderung von bestehenden oder die Entwicklung von neuen Produkten, die Zusammenarbeit in den Entwicklungsteams und in die Struktur von Unternehmen ein. Dabei ist sogar eingeplant, dass disruptive Energien freigesetzt werden.

DevOps sorgt für ein innovatives Klima und hat das Ziel der schnelleren Auslieferung von neuen (Software-) Versionen bei einer hohen Qualitätsstufe, dadurch soll außerdem die Zufriedenheit der Kunden steigen.

DevOps verändert auch und vor allem das Testen.

Dieser Impulsvortrag bietet einen Überblick über die Grundlagen und Prinzipien (z.B. das CALMS-Prinzip) von DevOps und zeigt auf, welche Veränderungen es beim Testen gegenüber klassischen Vorgehensmodellen wie Wasserfall und V-Modell mit sich bringt.

Doch was genau ist DevOps? Wie werden die genannten Ziele erreicht? Und wie sorgt DevOps für eine schnellere Auslieferung bei gleichzeitig höherer Qualität?

Diese Fragen beantworten wir in unserem Webinar und beleuchten dabei folgende Themen:

  • Warum DevOps?
  • Vorteile und Nutzen von DevOps
  • Die Bedeutung von Automatisierung in DevOps
  • Open Source in DevOps
  • Testautomatisierung, Tools und Testing
  • Geänderte Rollen und Zuständigkeiten
Redner

Mario Hanneken hat sich nach mehr als 12 Jahren Entwicklungserfahrung auf die Bereiche Projekt- und Application Management fokussiert. Anschließend spezialisierte er sich auf das Testumfeld, wo er als Senior Consultant in der Rolle Technical Testmanager für die Qytera Gmbh tätig ist. Darüber hinaus ist er ISTQB-Full Advanced Level zertifiziert und zertifizierter Trainer.

Wo finde ich das Webinar?

Das Meetup findet online auf Zoom statt. Über unsere Meetup Gruppe Agile Testing Frankfurt / Rhein-Main können Sie sich anmelden:

Zur Anmeldung 24. August 202024. August 2020Finden Sie weitere interessante Artikel zum Thema:  Artikel weiterempfehlen:

Agiles Testmanagement in der CI/CD Pipeline

Qytera News -

Lesedauer: 1 Minute

Viele Unternehmen haben den Wunsch, flexibel auf veränderte Kundenbedürfnisse reagieren zu können. Mit dieser Ausrichtung ist oft der Wille verbunden, die Lieferzeit für Softwareanpassungen zu verkürzen. Trotz beschleunigter Lieferzeiten darf die Qualität aber nicht leiden, denn Qualität ist ein Wettbewerbsfaktor.

Um die genannten Ziele zu erreichen, setzen immer mehr Unternehmen auf die Einführung agiler Methoden in der Softwareentwicklung oder stellen sogar wesentliche Unternehmensteile auf agile Organisationsmodelle um.

Die Beschleunigung der Lieferzeiten wird technisch meist über CI/CD-Pipelines umgesetzt, zunehmend unter Nutzung von Docker, Kubernetes und Cloud-Technologien. In den Pipelines sind automatisierte Tests ein fester Bestandteil. Ohne automatisierte Tests kann die Pipeline nicht funktionieren.

Wie kann der agile Testmanager helfen, das gesetzte Ziel zu erreichen?

Ein agiler Testmanager steht im Fokus der Sicherstellung der geforderten Qualität im veränderten Szenario, das manchmal auch als digitale Transformation bezeichnet wird. Er muss agil denken und kann operative Testmanagementaufgaben an agile Teams abgeben. Seine Aufgabe ist es aber, in seiner Organisationseinheit für die geeigneten Rahmenbedingungen zu sorgen, damit organisatorische und technische Änderungen zur Beschleunigung der Softwarelieferungen nicht zu Lasten der Qualität gehen.

Bleiben wir realistisch!

Ein vollautomatisierte Auslieferung größerer Softwareänderungen insbesondere in komplexen Systemlandschaften scheint in absehbarer Zukunft kein realistisches Szenario. Manuelle Teilprozesse, sei es zur Fehlerbearbeitung oder für die manuelle Ausführung von Tests sind auch in CI/CD-Pipelines bis auf weiteres notwendig. Zur Sicherung der notwendigen Qualität muss der agile Testmanager also weiterhin Tester berücksichtigen. Manuelle und automatisierte Tests müssen im optimalen Mix geplant, überwacht und gesteuert werden.

Der agile Testmanager ist nicht allein

Dabei können operative Testmanagementaufgaben auch von Mitgliedern agiler Teams übernommen werden. Damit sie für diese Aufgabe gut vorbereitet sind, sollte vom agilen Testmanager eine Testgilde zum teamübergreifenden Wissenstransfer genutzt werden. Über die Testgilde können auch Optimierungen der agilen Testprozesse angestoßen werden.

-->18. August 202018. August 2020Finden Sie weitere interessante Artikel zum Thema:  Artikel weiterempfehlen:

Testmanagement in agilen Organisationen (Spotify-Modell)

Qytera News -

Lesedauer: 2 Minuten

Bei dem Musik- und Video-Streamingdienst Spotify ist aus der Anwendung verschiedener agiler Methoden ein Organisationsmodell geworden. Es wird heute gemeinhin als Spotify-Modell bezeichnet. Im Rahmen der digitalen Transformation haben einige Unternehmen ihre Organisation nach dem Spotify-Modell ausgerichtet, in der Finanzbranche z.B. die ING, die Commerzbank und die Sparkassen. Mit dem Organisationsmodell von Spotify wird eine Matrixorganisation auf Basis von Tribes, Squads, Chapters und Product Ownern eingeführt.

Bild: Spotfify-Modell für agile Organisationen. [Quelle: Kniberg und Ivarsson 2012]

Squads entwickeln Softwareprodukte im Auftrag von Product Ownern. Development Engineers und Business Experts testen sie und Application Operation Engineers bringen sie anschließend in die Produktionsumgebung. Als Entwicklungsmodelle kommen Scrum oder Kanban zum Einsatz. Teamübergeifender Erfahrungsaustausch findet in Chapters und Guilds statt.

Da die Rolle Testmanager in Spotify-Modell nicht vorgesehen ist, werden notwendige Testmanagementaufgaben im Tribe agilen Rollen zugeordnet. Es hat sich praktisch bewährt, einen Mitarbeiter für übergreifende Testmanagementaufgaben im Tribe zu bestimmen und Mitgliedern der Squads operative Testmanagementaufgaben zu übertragen.

Test Guild und teamübergreifender Austausch

Im Rahmen der digitalen Transformation ist die Etablierung einer Test Guild ein hilfreicher Schritt. Vertreter mit Testschwerpunkt aus den Squads treffen regelmäßig zusammen, um sich über testbezogene Best Practices auszutauschen, über anstehende Neuerungen beim Einsatz von Verfahren und Tools zu informieren oder Optimierungsmöglichkeiten im Testprozess für den Tribe zu besprechen. Dabei sind die Mitglieder der Test Guild nicht unbedingt diejenigen, die operative Testmanagementaufgaben in den Squads wahrnehmen. Sie sind aber die bestimmten Ansprechpartner für das Thema Test in den Squads und autorisiert Anliegen in die Test Guild einzubringen.

Neben der Führung der Test Guild sind auch Vereinbarungen zu Testthemen mit anderen Tribes zu treffen, insbesondere wenn starke Abhängigkeiten bestehen. Der übergreifend tätige Testmanager im Tribe ist für diese Aufgabe prädestiniert.

Testinfrastruktur und Testautomatisierung

In der spezifischen Ausrichtung der Testprozesse werden übergreifend tätigen Testmanagern im Tribe (auch als Testmaster bezeichnet) auch tribeweite Testinfrastrukturaufgaben übertragen: Administration des eingesetzten Testmanagementtools, toolgestützte Verwaltung von Testumgebungen, Testusern, Testdaten und nicht zuletzt das Thema Testautomatisierung.

Testautomatisierung auf Komponentenebene (JUnit) - oder für die Middleware - wird tendenziell von Development Engineers übernommen. Stattdessen muss die Automatisierung fachlicher, meist frontendbasierter, Tests an Entwickler in Auftrag gegeben werden, da Fachtestern im Regelfall dazu das technische Know-How fehlt. Damit sinnvoll automatisiert werden kann, müssen die notwendigen Voraussetzungen geschaffen werden, indem z.B. ein Regressionstestportfolio für die Kernfunktionalitäten der automatisierten Anwendungen definiert und ein Pflegeprozess für das Portfolio aufgesetzt wird.

Continuous Integration und Continuous Deployment (CI/CD-Pipeline)

Übergreifendes Ziel der Einführung einer agilen Organisation ist die schnellere und flexiblere Bereitstellung der Features von Softwareprodukten unter Beibehaltung des notwendigen Qualitätsniveaus. Um dieses Ziel erreichen zu können, wird ein weitgehend einheitlicher, automatisierter Prozess bereitgestellt. Dieser beginnt mit dem Zusammenbau von Komponenten und reicht bis zum Deployment der angepassten oder neuentwickelten Komponenten in Produktion. Cloudtechnologien, Docker und Kubernetes werden dabei immer häufiger verwendet.

Automatisierte Tests sind in diesem Prozess fester Bestandteil: mit einer Änderung von Softwareprodukten werden in Testumgebungen automatisierte Tests passend bereitgestellt. Im Zielbild soll nach erfolgreicher Ausführung automatisierter Tests in vorgegebenen Testumgebungen eine Softwarekomponente ohne manuelle Eingriffe in Produktion deployed werden können.

Bis zur durchgehenden operativen Umsetzung des Zielbilds sind automatisierte und manuelle Testausführungen für Auswertungen und Entscheidungen allerdings zusammenzubringen. Auch dafür haben Testmanager in der agilen Organisation in einem geeigneten Testmanagementtool zu sorgen.

Mit der unternehmensweiten Fokussierung auf eine CI-/CD Pipeline gewinnt die Integration von Testprozessen mit Softwareentwicklungs- und Deploymentprozessen an Bedeutung. In einer Tribe Charta sind unternehmensweite Vorgaben der beteiligten Prozesse in der CI/CD-Pipeline für einen Tribe zu regeln. Testprozessbestandteile der Tribe Charta werden in der Regel vom übergreifenden Testmanager in Abstimmung mit der Test Guild eingebracht.

Fazit

In agilen Organisationen werden operative Testmanagementaufgaben von Mitgliedern der agilen Teams (Squads) übernommen. Für gemeinsame Beschlüsse, Informationsaustausch und Initiativen zur Testoptimierung empfiehlt sich innerhalb der Tribes die Einrichtung einer Test Guild, in der jede Squad von einem Teammitglied mit Testschwerpunkt vertreten wird.

Die Organisation der Test Guild, die Festlegung der Testrichtlinien für den Tribe, sowie teamübergreifende Aufgaben für Testinfrastruktur und Testautomatisierung verbleiben bei einem übergreifend tätigen Testmanager.

Dieser Überblick sollte Ihnen Anhaltspunkte für die Verteilung von Testmanagementaufgaben in einer agilen Organisation geben.

28. Juli 202028. Juli 2020Tags:  Artikel weiterempfehlen:

Lasttest (Load Testing) - Konzept und Tools

Qytera News -

Lesedauer: 3 Minuten

Der Lasttest (engl. Load Testing) oder auch Performancetest ist eine der wichtigsten nicht funktionalen Softwaretests, um die Belastbarkeit von Systemen, wie beipsielsweise Web-Applikationen, zu prüfen. In diesem Artikel gehen wir näher auf diese Testart und die verfügbaren Tools wie JMeter, Grinder, HP Loadrunner und Silk Performer ein.

Stabilität und Verlässlichkeit mit dem Lasttest prüfen

Jedes Softwaresystem ist für eine bestimmte Arbeitslast konzipiert. Manche dieser Softwaresysteme sollen dabei mehreren Nutzern gleichzeitig dienen, wie es unter anderem bei Content-Management-Systemen der Fall ist. Andere müssen zusätzlich eine Flut von Daten rechtzeitig bearbeiten können. Ein Ausfall solcher Systeme kann teils erheblichen Schaden oder finanzielle Verluste verursachen. Deswegen ist es sehr wichtig, dass diese vor ihrem Einsatz einer Reihe von Lasttests unterzogen werden.

In einem Lasttest werden im zu testenden System, wie der Name schon sagt, Lasten erzeugt. Ziel ist es zu sehen, ob das System diese Last bewältigen kann. Es wird beispielsweise getestet, ob eine Webseite mehreren Besuchern gleichzeitig in akzeptabler Zeit Antworten schicken kann oder ob ein Textverarbeitungsprogramm eine große Datei öffnen kann.

Die vier Arten von Lasttest

Es gibt verschiedene Arten von Lasttests. Allerdings sind diese nicht immer einheitlich definiert. Allgemein können Lasttests aber in vier Kategorien zusammengefasst werden:

Kategorie 1: Der "klassische" Lasttest

Diese Art von Test ist gmemeint, wenn man schlicht vom Lasttest spricht. Die dahinterliegende Frage lautet "Kann mein System das, was es soll?". Das System wird daraufhin überprüft, ob es die in den Anforderungen genannten Lasten bewältigen kann. Ein kurzes Beispiel: Angenommen, wir testen eine Web-Applikation, die gleichzeitig bis zu 100 Nutzer bedienen und Antworten innerhalb von 3 Sekunden senden soll. In einem Lasttest würde man diese Anzahl von Nutzern simulieren und überprüfen, ob die Antwortzeiten die genannte Grenze nicht überschreiten.

Kategorie 2: Der Kapazitätentest

Beim Kapazitätentest geht man einen Schritt weiter. Hier wird gefragt "Was kann mein System?". Das System wird einem Test unterzogen, der dazu dient, seine maximalen Kapazitäten zu bestimmen. In unserem vorherigen Beispiel würde man die Web-Applikation nun nicht mit hundert Usern, sondern z.B. mit 110 Usern, dann mit 120 usw. testen, bis die in den Anforderungen spezifizierte Antwortzeit von 3 Sekunden überschritten ist.

Kategorie 3: Der Stresstest

Beim Stresstest geht man noch einen Schritt weiter – das System wird unter eine Last gestellt, die es so nicht stemmen kann. Hier wird die Frage beantwortet "Was passiert, wenn ich mein System überlaste?". Ziel ist es, das Verhalten des Systems unter extremen Belastungen zu überprüfen.

Nehmen wir an, der Kapazitätentest im vorherigen Beispiel hätte ergeben, dass die Web-Applikation maximal 150 simultane Nutzer bedienen kann, ohne dass die Antwortzeiten die vorgegebenen 3 Sekunden überschreiten. Nun wird die Applikation mit 200, 300 oder mehr Nutzern getestet. Wie lange sind die Antwortzeiten? Wann stürzt die Applikation ab? Wie wird mit so einem Absturz umgegangen? Diese und ähnliche Fragen versucht der Stresstest zu beantworten.

Kategorie 4: Der Dauerlasttest

Viele Softwaresysteme arbeiten rund um die Uhr. Von daher stellt sich auch die Frage "Kann mein System auch dauerhaft arbeiten?". Bisher beschrieben wir Lasttests, die über einen kurzen Zeitraum ausgeführt wurden. Es ist aber wichtig zu überprüfen, ob das System auch über einen längeren Zeitraum korrekt funktioniert, ob z.B. Speicherlecks vermieden werden. Dies herauszufinden ist das Ziel des Dauerlasttests. Oft laufen diese Tests über einen oder mehrere Tage.

Beispiel: Unsere Web-Applikation soll 24 Stunden am Tag verfügbar sein. In einem Dauerlasttest, kombiniert mit einem „Standard“-Lasttest, wird nun überprüft, ob das System 100 User gleichzeitig über 36 Stunden bedienen kann.

Die Lasttest Tools

Nachdem wir nun die verschiedenen Arten von Lasttests beschrieben haben, stellen wir Ihnen nun kurz die verschiedenen Tools vor, mit denen man Lasttests durchführen kann.

Allgemein kann man die verfügbaren Performancetest bzw. Lasttest Tools in zwei Kategorien unterteilen. Es gibt einerseits die kostenlosen Open-Source-Projekte. Oft sind sie leicht erweiterbar und damit sehr flexibel. Die populärsten unter ihnen haben eine große Community, was dazu führt, dass der Software viele Plugins zur Verfügung stehen. Der Nachteil ist, dass bei diesen Programmen oft die Einarbeitungszeit länger ist und es keinen professionellen Support gibt.

In der zweiten Kategorie der Lasttest-Tools sind die kommerziellen Programme. Oft gibt es hier eine individuelle Betreuung und eine leichtere Einarbeitung. Der Nachteil sind die teilweise hohen Anschaffungskosten von einigen Hundert bis mehreren Tausend Euro.

JMeter - Performance Monitoring Tool

Die in Java geschriebene Open-Source-Software von Apache ist die wohl populärste unter den kostenlosen Last- Performace-Testtools. Ursprünglich wurde sie für Webanwendungen konzipiert, was auch weiterhin ihr Fokus ist. Sie wurde aber mittlerweile erweitert und bietet nun auch die Möglichkeit, andere Software zu testen, wie z.B. Datenbanken oder Message Oriented Middleware. JMeter unterstützt verschiedene Protokolle wie HTTP, HTTPS, SOAP, REST, FTP, JDBC, LDAP, JMS, SMTP und POP3.

Grinder - Performancetest-, Lasttest-Framework

Ebenfalls Open Source und sehr beliebt. Es ist in Jython und Clojure geschrieben und hat einen starken Fokus auf dem Testen von Software, die mit Java geschrieben ist.

HP LoadRunner

Das wohl bekannteste unter den kommerziellen Load-Testing-Tools von Hewlett-Packard ist ein sehr umfangreiches aber auch teures Performancetest bzw. Lasttest Tool. In einem weiteren Artikel erläutern wir Ihnen die Funktionsweise, sowie die Vor- und Nachteile von HP LoadRunner.

Silk Performer

Ein ebenfalls sehr umfangreiches Lasttest Tool von Micro Focus Borland.

Fazit

Load Testing ist heute in vielen Softwareprojekten unverzichtbar. Mit den richtigen Werkzeugen können Softwaretester diese Tests auf ihren Testobjekten erfolgreich ausführen. Gerne kümmern wir uns um das Aufsetzen, Durchführen und Auswerten der Lasttests in Ihrem IT-Projekt. Für eine umfassendere Beratung und Unterstützung bieten wir Ihnen auch komplette Testautomatisierungs-Lösungen an. Wir hoffen, dass dieser Artikel ein guter Einstieg für Sie in das Thema Load Testing ist und wünschen Ihnen viel Erfolg bei der Durchführung Ihrer eigenen Lasttests!

22. Juli 202023. Juli 2020Tags: 
Subscribe to Testdatenmanagement - Testdaten, Testmanagement Aggregator