ISTQB Syllabus

Ziele einer Testautomatisierung

• Erhöhung der Testeffizienz

• Erhöhung der Funktionsüberdeckung

• Senkung der Gesamtkosten für Tests

• Durchführung von Tests, die manuell nicht oder nicht zielführend durchgeführt werden können

• Verkürzung der Testausführungszeit

• Erhöhung der Testausführungshäufigkeit/Verkürzung der für die Testzyklen benötigten Zeit

Nachteile der Testautomatisierung

• Es fallen zusätzliche Kosten an

• Anfangsinvestitionen für die Entwicklung einer TAS werden benötigt

• Es werden zusätzliche Technologien benötigt

• Das Testteam benötigt Kompetenzen im Bereich der Softwareentwicklung und Testautomatisierung

• Es besteht ein ständiger Wartungsbedarf der TAS

• Testautomatisierung kann von den eigentlichen Testzielen ablenken, z. B. durch Fokussierung auf die Automatisierung von Testfällen zu Lasten der Testausführung

• Tests können komplexer werden (auch Vorteil)

• Durch Testautomatisierung können zusätzliche Fehler eingeschleust werden

Vorteile einer Testautomatisierung

• Je Software-Version können mehr Tests durchgeführt werden

• Es lassen sich Tests entwickeln, die sich manuell nicht durchführen lassen (beispielsweise Echtzeit-Tests, verteilte Tests, parallele Tests)

• Tests können komplexer sein (auch Nachteil)

• Tests laufen schneller

• Tests sind weniger anfällig für Bedienfehler

• Testressourcen werden effektiv und effizienter genutzt

• Es gibt eine schnellere Rückmeldung bezüglich der Softwarequalität

• Testautomatisierung trägt zu einer größeren Ausfallsicherheit des Systems (z. B. Wiederholbarkeit, Konsistenz) bei

• Testautomatisierung verbessert die Konsistenz der Tests

Beschränkungen der Testautomatisierung

• Nicht alle manuellen Tests lassen sich automatisieren

• Nur maschineninterpretierbare Ergebnisse sind prüfbar

• Es lassen sich nur tatsächliche Ergebnisse prüfen, die von einem automatisierten Testorakel verifiziert werden können

• Testautomatisierung ist kein Ersatz für exploratives Testen

Technische Erfolgsfaktoren für die Automatisierung

• Testautomatisierungsarchitektur (TAA)

• Testbarkeit des SUT

• Testautomatisierungsstrategie

• Testautomatisierungsframework

Testautomatisierungsarchitektur (TAA)

• Die TAA (Testautomatisierungsarchitektur) ist die Architektur der TAS - d.h. sie beschreibt die Schichten, Komponenten, Dienste und Schnittstellen.

• Gute Softwarearchitektur unterstützt Qualitätsattribute wie

  • Wartbarkeit

  • Performanz

  • Erlernbarkeit (Usability)

• TAA orientiert sich an der Architektur des SUT

• Details zu Qualitätsattributen findet man in [IS025000]

Testbarkeit des SUT

• Testschnittstellen definieren (mit dem SW Architekten)

• ein SUT muss auf Testbarkeit und Testautomatisierung ausgelegt sein

• Testbarkeit erhöht die Bedienfreundlichkeit

• mit den testbaren Teilen anfangen

• beim GUI-Test: Elemente und Daten soweit wie möglich von ihrem Layout entkoppeln (MVC: Model-View-Controller)

• API-Testen: zusätzliche (Test-)Schnittstellen, SUT-Schnittstellen (von Klassen, Modulen/Komponenten etc. oder der Kommandozeile) öffentlich bereitstellen

Aspekte der Testautomatisierungsstrategie

• kümmern Sie sich um Wartbarkeit und Konsistenz des SUT

• Veraltete Teilsysteme (Legacy) können ein Problem sein

  • Legacy: ältere Teile des Systems (besonders die, die vor der Einführung der Testautomatisierung entwickelt wurden)

  • typische Probleme: fehlende Spezifikationen, fehlende Testschnittstellen, andere Technologien

• betrachten Sie Kosten, Nutzen und Risiken

• testen Sie beides. Ul + API

Vorteile des Testautomatisierungsframework (TAF)

• Bedienungsfreundlich

• gut dokumentiert

• wartbar

• einheitlicher Ansatz für die Automatisierung von Tests

Testautomatisierungsframework (TAF): darauf muss man aufpassen!

• Berichtsfunktionen: Informationen für verschiedene Stakeholder adäquat aufbereiten

• Einfachen Fehlersuche und -beseitigung (liegt der Fehler im SUT, im TAS, in den Testskripten oder der -umgebung?)

• Korrekte Einrichtung der Testumgebung und der Testdaten

• Testfälle klar dokumentieren

• Rückverfolgbarkeit der Testausführung zu den Testfällen

• Einfach Wartung

• Testfälle zeitnah anpassen, korrigieren, verbessern

• Softwareverteilung (Deployment) planen

• Testfälle außer Betrieb nehmen, wenn sie nicht mehr hilfreich sind oder nicht mehr benötigt werden

• Überwachung und (falls nötig) Wiederherstellung des SUT (SUT in einen konsistenten Zustand führen nach einem Absturz)

Testautomatisierungsframework (TAF): was man beachten sollte!

• Testautomatisierungscode kann komplex sein (und kompliziert zu warten)

• Testautomatisierung ist Software-Entwicklung

• Testautomatisierungscode kann so umfangreich und komplex wie das SUT sein (manchmal sogar komplexer)

• Wartbarkeit des Codes ist ein zentrales Problem

• Auch die Testwerkzeuge, Verifikationsarten und Testmittelartefakte des Frameworks müssen gewartet werden

Testautomatisierungsframework (TAF): was man vermeiden sollte!

• Testcode mit technischen Abhängigkeiten zu verwendeten Schnittstellen vermeiden (e.g. GUI Änderungen sollen keine Testfalländerungen verursachen - eine generische Objektidentifikation verwenden)

• Code soll nicht anfällig gegenüber Datenänderungen sein (Clean Code Methoden auch für Testfälle verwenden [Martin2008])

• Code soll vom technischen Kontext unabhängig sein (Datum und Uhrzeit, Lokalisierungsparameter, Inhalt anderer Anwendungen)

SUT-Faktoren mit Einfluss auf die Testautomatisierung

• SUT Schnittstellen

• Fremdsoftware

• Grad der Intrusion

• Unterschiedliche SUT-Architekturen

• Größe und Komplexität des SUT

SUT Schnittstellen

• Aktionen im SUT auslösen (PoC: Points of Control):

  • GUI- oder niedrigere Ebene

  • auf der Kommunikationsebene (TCP/IP, USB, CAN, proprietäre Nachrichten-Schnittstellen)

• durch eine sinnvolle Dekomposition des SUT ist es möglich, auf unterschiedlichen Teststufen unterschiedliche Schnittstellen anzusprechen

• mitunter müssen dedizierte (Test-) Schnittstellen bereitgestellt werden (so genannte "Test Hooks")

Rollen von TAM und TAE in der Werkzeugauswahl

• Der TAM ist (in erster Linie) für die Auswahl und Bewertung von Werkzeugen verantwortlich.

• Es gehört jedoch zu den Aufgaben des TAE, dem TAM diesbezüglich zuzuarbeiten

• Werkzeugevaluation sowie die schlussendliche Auswahlempfehlung werden zumeist vom TAE durchgeführt

• Beachte: Werkzeugauswahl und -evaluation sind bereits im Grundkurs eingeführt worden, und werden im Advanced Level Test Manager detailliert

Bewertung und Auswahl von Werkzeuge

• Bewertung der organisatorischen Reife und der Möglichkeiten einer Testwerkzeugunterstützung

• Bewertung realistischer Zielvorstellungen durch eine Testwerkzeugunterstützung

• Ermittlung und Sammlung von Informationen zu potentiell einsetzbaren Werkzeugen

• Analyse von Werkzeugeigenschaften unter Berücksichtigung der Ziele und Projektrestriktionen

• Abschätzung des Kosten-Nutzen-Verhältnisses auf Basis eines soliden Business Case

• Aussprechen von Empfehlungen für geeignete Werkzeuge

• Ermittlung der Werkzeugkompatibilität mit Ihrem SUT (bzw. seinen Komponenten)

Beispiele I

Beispiele I

Beispiele I

Beispiele III

Beispiele III

Beispiele III

Beispiele III

Softwareschnittstellen, die Testbarkeit unterstützen

• Skripterstellungsfunktionen der Software

  • viele Applikationen bieten ein API für Skripterstellung und/oder definieren ihre eigene Skriptsprache, um damit die Software automatisiert fernzusteuern

  • Beispiele sind Textverarbeitungen, Editoren, Tabellenkalkulationen, Präsentationssoftware, Modellierungssoftware, Simulatoren, Performanzwerkzeuge, etc.

• Platzhalter und Mocks

• Treiber

• Schnittstellen, die Fehlerbedingung imitieren (z.B. Simulation einer rutschigen Straße im Automobilbereich) - Fault Injection

• interne Schnittstellen statt des Ul (oder wenn es kein Ul gibt) - passen oft besser und sind effizienter

• Schnittstellen, die systeminterne Zustände nach außen führen (insbesondere beim zustandsbasierten Test) - mit der Gefahr der Intrusion

Was ist der Nutzen einer generische Testautomatisierungsarchitektur?

• eine gTAA wird zu einer konkreten TAA verfeinert für eine spezifische TAS

• die gTAA ist die Abstraktion des Testautomatisierungsbedarfs der Firma

• Die gTAA ermöglicht:

• das Definieren des funktionalen und nicht-funktionalen Umfangs, der Schichten, Dienste und Schnittstellen einer TAS

• die Unterstützung einfacher Komponenten

• die Wiederverwendung von Komponenten in verschiedenen TAS

• die Vereinfachung der Wartung und Weiterentwicklung von einer TAS

• das Definieren der essentiellen Funktionen für einen Benutzer einer TAS

Testautomatisierungslösungen und - frameworks

• Eine Testautomatisierungslösung besteht aus:

  • Testumgebung (+ Artefakte)

  • Testsuiten

• Das Testautomatisierungsframework wird zur Realisierung einer TAS verwendet

• Das TAF liefert Werkzeuge, Testrahmen und Bibliotheken

Fest definierte Aufgabe (engl. single responsibility)

• Jede Komponente soll eine fest definierte Aufgabe (Zuständigkeit) haben

• Zuständigkeit soll komplett in der Komponente gekapselt sein

• d.h. jede Komponente ist genau für eine Aufgabe zuständig

• z.B. Schlüsselworte oder Daten erzeugen, Testszenarien erstellen, Ergebnisse protokollieren, etc.

• Der CEO der Firma sollte nicht auch gleichzeitig für die Bestellung der Radiergummis zuständig sein

Erweiterbarkeit

• Komponenten sollten

  • offen für Erweiterung sein,

  • aber geschlossen gegenüber Modifizierung.

• geschlossen für Modifizierung = die Rückwärtskompatibilität nicht beeinträchtigen

• Bertrand Meyer: Open-Closed-Prinzip [Meyer1998]

• Es ist schön, wenn man an sein Haus einen Wintergarten anbauen kann. Es ist problematisch, wenn man danach die Eingangstür nicht mehr benutzen kann.

Ersetzbarkeit

• Substitutionsprinzip (LSP) nach Barbara Liskov [Liskov1994]

• Komponenten sind ersetzbar, ohne Veränderung des Gesamtverhaltens der TAS.

• auch bekannt als behavioral subtyping - die substituierende Komponente soll dasselbe beobachtbare Verhalten haben wie die substituierte Komponente

• Wenn Sie ein Taxi bestellen, sollte die Automarke keine Rolle spielen. Ein Mercedes Taxi, aber auch ein Renault Taxi, beide können ein Taxi "ersetzen".

Komponentensegregation

• Segregation = Trennung

• Interface-Segregation-Prinzip (ISP) (Robert C. Martin, 'Uncle Bob') [Martin1996]

• Komponenten sollten nicht von Methoden abhängen, die sie nicht verwenden

• Verwende spezifischere Komponenten statt einer allgemeinen Komponente mit mehreren Aufgaben

• Wenn man seinen Wagen aus der Garage holt, braucht man einen Schlüssel für die Garage. Man sollte keinen Schlüssel für den Keller brauchen.

Abhangigkeitsumkehr

• Komponenten entkoppeln

• Komponenten auf den oberen Ebenen müssen - statt von Details niederer Ebenen - von Abstraktionen abhängen.

• Komponenten dürfen nicht von spezifischen automatisierten Testszenarios abhängen

• Wenn Sie Ihre Maus benutzen, sollte es keinen Unterschied machen, ob die Maus über einen seriellen Anschluss, USB oder Bluetooth verbunden ist

Implementierung der TAS

• verwenden Sie einen beliebigen Softwareentwicklungsansatz:

  • strukturiert,

  • objektorientiert,

  • serviceorientiert,

  • modellgetrieben, etc.

• häufig mit Werkzeugen von der Stange, mit SUT-spezifische Zusätzen und/oder Anpassungen

• verwenden Sie Softwareentwicklungsstandards

• verwenden Sie branchenübliche Programmier- und Dokumentationsstandards und Best Practices

  • MISRA für C oder C++

  • JSF-Standard für C++

  • AUTOSAR-Regeln für Math Works Matlab/Simulink®

• achten Sie auf Wartbarkeit, Zuverlässigkeit und Sicherheit

• Konfigurationsmanagement (Git)

• Testmanagement (Testrail)

• Testprozeduren (Testskripte)

Projektmanagement

• behandeln Sie Ihr Testautomatisierungsprojekt wie ein normales Software-Entwicklungsprojekt

• TAF und TAS können ein gemeinsames oder getrenntes Projektmanagement haben

Die Testgenerierungsschicht unterstützt diese Aktivitäten

• Hier werden Testfällen entworfen und die Testdaten entwickelt

• Testfälle: Schicht enthält Mittel um

  • Testfälle manuell zu entwerfen

  • Testfälle automatisch aus Modellen herzuleiten (wenn möglich)

• Testdaten: Schicht enthält Mittel um Testdaten

  • zu entwickeln,

  • aufzuzeichnen

  • und herzuleiten

Funktionalität der Testgenerierungsschicht

• Bearbeitung und Navigation in den Testsuite-Strukturen Es ist sinnvoll seine Testsuiten und -fälle in einer baum-/verzeichnis-artigen Struktur zu arrangieren

• Rückverfolgbarkeit: Verknüpfen von Testfällen mit Testzielen oder SUT- Anforderungen

• Dokumentieren des Testentwurfs

Funktionen einer Testgenerierungsschicht mit automatisierter Testerzeugung

• Modellierung

  • des SUT,

  • der Umgebung,

  • des Testsystems

• Definition von Testrichtlinien

• Konfiguration/Parametrierung der Testgenerierungsalgorithmen

• Rückverfolgbarkeit zwischen generierten Tests und den Modellen definieren und bearbeiten

Unterstützung auf der Testdefinitionsschicht

• Festlegen von Testfällen (auf abstrakter oder konkreter Ebene)

• Definieren von Testdaten für konkrete Testfälle

• Spezifizieren von Testabläufen (für einen oder mehrere Testfälle)

• Definieren von Testskripten

• Zugang zu Testbibliotheken

Aufgaben der Testausführungsschicht

• automatisches Ausführen von Testfällen

• Protokollierung der Ausführungen von Testfälle

• Aufbereiten der Testergebnisse in Berichten

Aufgaben der Testadaptierungsschicht

• Steuerung des Testrahmens

• Interaktion mit dem SUT

• Überwachung des SUT

• Simulieren oder Emulieren der SUT-Umgebung

Objekte des Konfigurationsmanagements in der TAS

• Testmodelle

• Testdefinitionen/-spezifikationen einschließlich Testdaten, Testfällen und Bibliotheken

• Testskripte

• Maschine für die Testausführung und ergänzende Werkzeuge und Komponenten

• Testadapter für das SUT

• Simulatoren und Emulatoren für die SUT-Umgebung

• Testergebnisse und Testberichte

Projektmanagement einer TAS

• Projektmanagement einer TAS sollte etablierten SDLC-Methodiken folgen

  (SDLC - Software Development Life Cycle)

• TAE soll sicherstellen, dass Statusinformationen (Metriken) einfach extrahiert oder dem Projektmanagement der TAS automatisch in Berichtsform übermittelt werden können

Testmanagement und TAS

• Die TAS muss reibungslos mit dem Testmanagement der SUT zusammenarbeiten

• Testberichte einschließlich Testprotokolle und Testergebnisse müssen einfach extrahiert werden können und dem Testmanagement (Mensch oder System) des SUT automatisch übermittelt werden.

Aktivitäten des TAA-Entwurfs

• Erfassung der Anforderungen

• Vergleich und Gegenüberstellung verschiedener Entwurfs-/Architekturansätze

• Ermitteln von Bereichen, in denen eine Abstraktion Vorteile bieten kann

• Verstehen von SUT-Technologien und deren Vernetzung mit der TAS

• Verstehen der SUT-Umgebung

• Zeitaufwand und Komplexität der Implementierung einer Testautomatisierungsarchitektur

• Einfachheit der Verwendung der Implementierung einer Testautomatisierungsarchitektur

Erfassung der Anforderungen

• Phasen/Aktivitäten, die automatisiert werden sollen: Testmanagement, Testentwurf, Testgenerierung oder Testausführung

• Unterstützte Teststufen: Komponententest, Integrationstest, Systemtest

• Unterstützte Testarten: funktionale Tests, Konformitätstests, Interoperabilitätstests

• Unterstützte Testrollen: Testausführender, Testanalyst, Testarchitekt, Testmanager

• Unterstützte Softwareprodukte, Softwareproduktreihen oder Softwareproduktfamilien

• unterstützte SUT-Technologien

Architekturansätze: Testgenerierungsschicht

• manuelle oder automatisierte Testgenerierung

• Quelle der Testgenerierung?

  • Anforderungen

  • Daten (insbesondere bei datengetriebenem Test)

  • Szenarien

  • Verhalten, wie z.B. beim BDD (behavior driven development)

• Testgenerierungsstrategien:

  • Modellüberdeckung, wie Klassifikationsbäume für datenbasierte Ansätze

  • Anwendungsfall-/Ausnahmefall-Überdeckung bei szenariobasierten Ansätzen

  • Übergangs-/Zustands-/Pfadüberdeckung bei verhaltensbasierten Ansätzen

  • etc.

• Wählen Sie eine Testauswahlstrategie (uneingeschränkte kombinatorische Testgenerierung oft nicht möglich: praktische Überdeckungskriterien, Gewichtungen, Risikobewertungen verwenden)

Architektur-Ansätze: Testausführungsschicht I

• Welches Testausführungswerkzeug?

• Interpretation (virtuelle Maschine) oder Kompilierung der Testabläufe (hängt vom Testausführungswerkzeug ab)

• Interpretation des Testablaufs: im Systemtest wird oft mit Scriptsprachen (z.B. Python) automatisiert

• Kompilierung des Testablaufs: im Komponententest wird meistens dieselbe Programmiersprache verwendet, wie in der Applikation (z.B. Java)

Architekturansätze: Testadaptierungsschicht

• Testschnittstellen zum SUT

• Werkzeuge zur Stimulierung und Beobachtung der Testschnittstelle

• Werkzeuge zur Überwachung des SUT während der Testausführung

• Werkzeuge zur Rückverfolgung der Testausführung (z.B. Timing)

Abstraktion

• Abstraktion ist eine leistungsstarke Methode beim Architektur-Entwurf

• Abstraktion heißt, dass Abläufe auf der konzeptionellen und nicht der Implementierungs-Ebene beschrieben werden

• Spezifiziere "Ins System Einloggen" statt "ID in das Benutzerfeld eintragen, Passwort in das Passwortfeld eintragen, Return drücken"

• Abstraktion hilft bei der Definition universeller Lösungen, die flexibler sind

• Achtung! Abstraktion kann übertrieben werden!

• "Führe einen nützlichen Test aus" ist keine gute Spezifikation für einen Testfall - zu abstrakt

Warum und wo Abstraktion hilft l

• ermöglicht Unabhängigkeit von Technologie

• erhöht die Portabilität der Testartefakte

• gewährleistet Anbieterneutralität

• verbessert Wartbarkeit

• verbessert Adaptierbarkeit an neue oder sich weiterentwickelnde Technologien

Wie findet man Bereiche, in den Abstraktion hilft?

• mit an der Softwareentwicklung, Qualitätssicherung und Testdurchführung beteiligten Personen diskutieren

• festlegen, welche Schnittstellen der Testadaptierungs- und/oder - ausführungsschicht müssen über die gesamte Lebensdauer der TAA hinweg externalisiert, formal definiert und stabil gehalten werden

• entscheiden, ob eine abstrakte Testdefinition oder nur eine Testausführungsschicht mit Testskripten verwendet wird

• entscheiden über die Verwendung von Testmodellen und modellbasierten Testansätzen

SUT-Technologien und deren Vernetzung mit der TAS

• Es ist wichtig zu verstehen, wo und wie das SUT mit der TAS vernetzt ist

• Wo? Zugriff zu den Testschnittstellen auf

  • Softwareebene

  • API-Ebene

  • Protokollebene

  • Dienstebene

  • etc.

• Wie? Paradigmen für die Interaktion

  • Ereignisgetrieben

  • Client-Server

  • Peer-to-Peer

Verstehen der SUT-Umgebung

• Verstehen der Möglichkeiten für die SUT-Umgebung

• SUT kann wie folgt aufgebaut sein:

  • eigenständige Software (Standalone),

  • System von Systeme,

  • eingebettetes System,

  • cyber-physisches System (Fahrzeug)

• TAS simuliert oder emuliert die SUT-Umgebung

• Beispiel für den Aufbau:

  • SUT + TAS auf einem Computer

  • SUT + TAS in einem Netzwerk

  • zusätzliche Testgeräte

• durch Netzwerk miteinander verbundene Testgeräte zur Emulation der Betriebsumgebung des SUT

• Simulatoren zur Simulation der physischen Umgebung des SUT

Zeitaufwand und Komplexität der TAS

TAE muss den TAM unterstützen, indem er Input für die Schätzung von Zeitaufwand und Komplexität des TAA-Designs liefert, z. B. durch folgende Maßnahmen:

• analogiebasiertes Schätzen:

  • Funktionspunkte,

  • Dreipunktschätzung,

  • Breitband-Delphi,

  • Expertenschätzung

• Projektstrukturplan (PSP, engl. WBS: Work breakdown structures)

• parametrische Schätzung (z.B. COCOMO: Constructive Cost Model)

• größenbasierte Schätzungen:

  • Funktionspunktanalyse (FPA),

  • Story-Point-Analyse,

  • Anwendungsfallanalyse

• Gruppenschätzungen (z.B. Planungspoker)

Faktoren für die Benutzbarkeit der TAS

• Tester-orientierter Entwurf

• Einfachheit der Verwendung

• Unterstützung für andere Rollen in der Softwareentwicklung, Qualitätssicherung und im Projektmanagement

• effektive Organisation, Navigation und Suche in der TAS

• hilfreiche Dokumentation, Handbücher und Hilfetexte für die TAS

• praktische Berichterstattung durch und über die TAS

• iterative Entwürfe, um Feedback zur TAS und empirischen Erkenntnissen Rechnung zu tragen

Unterschiedliche Ansätze zur Testautomatisierung

• Testfälle direkt implementieren in automatisierten Testskripten (am wenigsten ratsam)

• Testabläufe entwerfen und diese in automatisierte Testskripte umwandeln

• ein Werkzeug zur Umsetzung der Testabläufe in automatisierte Testskripte nutzen

• ein Werkzeug verwenden, das automatisierte Testabläufe generiert und/oder die Testskripte direkt aus den Modellen ableitet

Ansätze zur Automatisierung von Testfällen

Hierarchie ist wichtig. Grad der TA ist detaillierter.

Konkret

• Mitschnitt-Ansatz (Capture/Playback):

  • direkte Codierung

• lineare Skripterstellung

• strukturierte Skripterstellung:

  • aus Testabläufen herleiten (mit und ohne Werkzeug)

• datengetriebenes Testen:

  • Testskripte aus Testabläufen herleiten (mit und ohne Werkzeug)

• schlüsselwortgetriebener Ansatz:

  • Testskripte aus Testabläufen herleiten (mit und ohne Werkzeug)

• prozessgetriebener Ansatz:

  • Testskript aus schlüsselwortgetriebenen Szenarienbeschreibungen generieren

• Modellbasiertes Testen:

  • Testskript direkt aus den Modellen ableiten, oder daraus automatisierte Testabläufe generieren (Diese Option hat den höchsten Automatisierungsgrad)

Abstrakt

Mitschnitt-Ansatz (Capture/Replay)

Grundkonzept

• Die Interaktionen während der manuellen Ausführung des Testfalls erfassen

• Ausgaben können ggf. auch aufgezeichnet werden

• Möglichkeiten der Prüfung der Ausgaben während der Wiedergabe:

  • Manuell: Der Tester muss die SUT-Ausgaben auf Anomalien beobachten

  • Vollständig: Alle aufgezeichneten Ausgaben müssen reproduziert werden

  • Exakt: Alle aufgezeichneten Ausgaben müssen bis auf die Detailebene der Aufzeichnung reproduziert werden

  • Checkpoints: nur ausgewählte Ausgaben an bestimmten Punkten für festgelegte Werte prüfen

Lineare Skripterstellung:

Grundkonzept

• Manuelle Testfälle in Skripte übersetzen (Testfall für Testfall)

• Oft: Mitschnitt (Capture/Replay) verwenden, um ein Grundskript zu erhalten

• Modifizierte Skripte werden für die Ausführung der Testfälle verwendet

• Ein lineares Skript ist im Prinzip nur die Sequenz der Schritte, die man während eines manuellen Tests ausführt, geschrieben in einer Programmiersprache

Strukturierte Skripterstellung:

Grundkonzept

• Manuell erstellte Testskripte

• Verwenden einer gemeinsamen Bibliothek für sich wiederholende Schritte

• Typische Bibliothek: Zugangsfunktionen zum SUT

• Wesentliches Element der strukturierten Skripterstellung ist die Skriptbibliothek mit gemeinsamen Abläufen, die wiederholt in den Skripten verwendet werden (Abstraktion)

• In der Praxis verwenden strukturierte Skripte oft Kontrollstrukturen (if-then-else, Schleifen) (aber der TAE Lehrplan erwähnt dies nicht)

Datengetriebenes Testen:

Grundkonzept

• baut auf der strukturierten Skripterstellung auf

• Trennt Testskript (Steuerungsskript) von den Testeingaben

• Testeingaben werden in einer externen Datei abgelegt (Datendatei)

• Steuerungsskript lesen Testdaten aus der Datendatei

Schlüsselwortgetriebenes Testen:

Grundkonzept

• baut auf der datengetriebenen Skripterstellung auf

• die Datendatei enthält nicht nur die Testdaten (Eingabe und erwartetes Ergebnis), sondern auch die Schlüsselwörter (Aktionswörter)

• ein Schlüsselwort beschreibt eine Aktion/einen Schritt im Testfall, für den Testanalysten leicht verständlich (z.B. "Anwender einloggen")

• Datendateien heißen auch Testdefinitionsdatei oder Aktionswortdateien

• lediglich ein Steuerungsskript, das die Einrichtung des Tests enthält

• das Steuerungsskript führt die Schlüsselwörter aus der Datendatei nach der Einrichtung aus

• dies muss entweder explizit implementiert werden oder geschieht automatisch, abhängig vom verwendeten Framework

• Beachten Sie, dass die verschiedenen schlüsselwortgetriebenen Frameworks andere Namenskonventionen für die Testelemente verwenden

• Testanalyst ist zuständig für das Erstellen und Warten der Schlüsselwortdateien

• Ist ein Schlüsselwort durch ein passendes Skript implementiert, so können automatisierte Tests einfach durch Verwenden des Schlüsselworts hinzugefügt werden

• Schlüsselwörter repräsentieren (meist) abstrakte Interaktionen mit dem System

Prozessgetriebene Skripterstellung:

Grundkonzept

• baut auf der schlüsselwortgetriebenen Skripterstellung auf

• Szenarios (Anwendungsfälle und ihre Varianten) bilden die Skripte

• Beispiele

  • check order status after place order (positiver Test)

  • check order status without place order (Robustheit)

Modellbasiertes Testen:

Grundkonzept

• automatisierte Generierung von Testfällen

• verwenden (semi-)formaler Modelle, die von den Skripterstellungstechniken der TAA abstrahieren

Erfolgsfaktoren für den Rollout

• Schrittweiser Rollout

• Anpassung und Optimierung von Prozessen in Abstimmung auf die Nutzung der TAS

• Bereitstellung von Schulungen und Coaching/Mentoring für neue Benutzer

• Definieren der Nutzungsrichtlinien

• Implementierung eines Instruments zur Erfassung von Informationen zur Nutzung in der Praxis

• Überwachung der Nutzung, des Nutzwertes und der Kosten der TAS

• Leisten von Unterstützung für das Test- und Entwicklungsteam für eine TAS

• Sammeln von gewonnenen Erkenntnissen von allen Teams

• Ermitteln und Umsetzen von Verbesserungen

Typische technische Probleme

• Zu starke Abstraktion kann es erschweren, die tatsächlichen Abläufe zu verstehen (z. B. bei Schlüsselwörtern).

• Datengetrieben: Datentabellen können zu groß/ komplex/ unübersichtlich werden.

• Abhängigkeit der TAS, bestimmte Betriebssystem-Bibliotheken oder andere Komponenten verwenden zu müssen, die nicht in allen Zielumgebungen des SUT verfügbar sind. (Bsp. XML Bibliothek unter Windows SE)

Typische Risiken eines Softwareverteilungsprojekts:

• Personelle Ausstattung: die richtigen Leute für die Wartung der Codebasis zu bekommen

• Neue SUT-Arbeitsergebnisse können den fehlerhaften Betrieb der TAS bewirken

• Verzögerungen bei der Einführung der Automatisierung

• Verzögerungen bei der Aktualisierung der TAS auf Basis der Änderungen am SUT

• Die TAS kann die (nicht standardmäßigen) Objekte nicht erfassen, die sie verfolgen soll

Aktivitäten für die Erstbereitstellung/Erstverteilung der TAS

• Definieren der Infrastruktur, in der die TAS ausgeführt wird

• Erstellen der Infrastruktur für die TAS

• Erstellen eines Verfahrens für die Wartung der TAS und ihrer Infrastruktur

• Erstellen eines Verfahrens für die Wartung der Testsuite, die die TAS ausführen wird

Schritte bei der Wartungsverteilung

• Bewertung durchführen: Änderungen in der neuen Version der TAS im Vergleich zur alten Version

• Die TAS testen bezüglich:

  • neuer Funktionen und

  • Regressionen (Verschlechterungen)

• Prüfen, ob die Testsuite in Abstimmung auf die neue Version der TAS geändert werden muss

Risiken beim Update (+ Minderungsstrategien)

• Die Testsuite muss geändert werden, um in der aktualisierten TAS zu laufen:

  • Testsuite anpassen und testen

• Beim Testen verwendete Platzhalter, Treiber und Schnittstellen müssen an die aktualisierte TAS angepasst werden:

  • Testrahmen anpassen und testen

• Die Infrastruktur muss in Abstimmung auf die aktualisierte TAS geändert werden:

  • Bewertung, welche Infrastrukturkomponenten Anpassungen brauchen

  • anpassen und testen

• Die aktualisierte TAS hat weitere Defekte oder Performanzprobleme:

  • Aktualisierung nur ausführen, falls die Defekte/Performanzprobleme im Vergleich zum Nutzen der Aktualisierung vernachlässigbar sind

  • Unbedingt Release Notes mit bekannten Problemen verfassen

  • Versuchen Sie abzuschätzen, wann die Probleme behoben werden

Arten/Kategorien der Wartung

• Präventive Wartung: Es werden Änderungen vorgenommen, damit die TAS mehr Testarten unterstützt, an mehreren Schnittstellen testet, mehrere Versionen des SUT testet oder die Testautomatisierung für ein neues SUT unterstützt.

• Korrektive Wartung: Es werden Änderungen vorgenommen, um Fehler der TAS zu beheben. Am besten und mit dem geringsten Risiko lässt sich eine in Betrieb befindliche TAS warten, indem man regelmäßige Wartungstests durchführt.

• Verbessernde Wartung: Die TAS wird optimiert und nichtfunktionale Fehler werden behoben. Sie kann die Leistungsfähigkeit der TAS, ihre Benutzbarkeit, ihre Robustheit oder Zuverlässigkeit verbessern.

• Adaptive Wartung:

  Wenn neue Softwaresysteme auf den Markt kommen (Betriebssysteme, Datenbankverwaltungsprogramme, Webbrowsers usw.), muss die TAS sie

  u. U. unterstützen können. Es kann auch der Fall sein, dass die TAS neue Gesetze, Vorschriften oder branchenspezifische Anforderungen erfüllen muss. In diesem Fall werden Änderungen an der TAS vorgenommen, um sie entsprechend anzupassen.

  Hinweis: Konformität mit Gesetzen und Vorschriften bedingt in der Regel eine verpflichtende Wartung mit speziellen Regeln, Anforderungen und mitunter vorgeschriebenen Prüfungen (Audits). Zudem gilt: Wenn integrierende Werkzeuge aktualisiert und neue Versionen erstellt werden, müssen die Endpunkte der Werkzeugintegration gewartet und funktional gehalten werden

Benennungsstandards und andere Konventionen

• Zweck von Benennungsstandards:

  • einfacher Informationen aufzuzeichnen und zu speichern - Team weiß, welche Namen verwendet werden

  • einfacher Informationen zu finden - Team weiß, wonach man suchen muss (ist heute 2018-08-06 oder Aug-6-18)

  • einfacher Informationen zu lesen und zu verstehen

• Benennungsstandards erhöhen Effizienz:

  • Testsuite und TAS selbst müssen einfach lesbar, verständlich, änderbar und wartbar sein

    • Es ist einfacher, neue Mitarbeiter an ein Testautomatisierungsprojekt heranzuführen

• Benennungsstandards können verwendet werden für

  • Variablen und

  • Dateien,

  • Testszenarios,

  • Schlüsselwörter und

  • Schlüsselwortparameter,

  • etc.

• Benennungsstandards sollten einfach sein -

• Benennungsstandards sollten den Firmenregeln folgen - Begriffe verwenden, die in der Firma/im Projekt akzeptiert oder sogar erwartet werden

• Benennungsstandards sollen Eindeutigkeit sicherstellen

• Halten Sie an existierenden Standards fest - z.B. sollen Daten nach [IS08601] geschrieben werden

• Standards definieren für

  • Voraussetzungen und

  • Anschlussmaßnahmen der Testausführung,

  • den Inhalt der Testdaten,

  • die Testumgebung,

  • den Status der Testausführung sowie

  • Ausführungsprotokolle und

  • -berichte

• Benennungsstandards und Konventionen müssen vereinbart und dokumentiert werden

Aufwand für die Analyse von SUT-Fehlern

• Manchmal ist die Analyse fehlgeschlagener automatisierter Tests deutlich schwieriger als im manuellen Fall

• vgl. Unterabschnitt 3.1.4, Abschnitt 5.3, 5.4

• Gemessen als

• durchschnittliche Zeit pro fehlgeschlagenem Test oder

• als Teil der EMTE (äquivalenter manueller Testaufwand)

• Vorzugsweise als Teil der EMTE messen, wenn die Ausführung der automatisierten Tests sehr unterschiedlich ist

• Zusätzlich sollten alle Ereignisse im SUT und der TAS aufgezeichnet werden (für automatisierte wie manuelle Tests):

• SUT und TAS Protokollierung synchronisieren

• alle im TAS ausgeführten Aktionen protokollieren

• das erwartete wie das tatsächliche Verhalten protokollieren

• alle im SUT ausgeführten Aktionen protokollieren

• alle internen Fehler protokollieren

• Absturz-Speicherabbilder (Crash Dumps) und Stack Traces des SUT verfügbar machen

Aufwand für die Wartung automatisierter Tests

• Die Wartung der automatisierten Tests ist einer der wichtigsten Kostentreiber der Automatisierung

• Diese Tatsache zu übersehen, führt oft zu fehlgeschlagenen Automatisierungsansätzen

• Den Wartungsaufwand messen als

• Gesamtwert aller automatisierten Test und/oder

• Durchschnitt pro geänderten automatisierten Test und/oder

• Teil des EMTE

• Anzahl/Prozentsatz der Tests messen, die gewartet werden müssen

• Abschätzen des Wartungsaufwands kann wesentlich sein für Entscheidungen, was getan werden soll oder nicht

• Jede Änderung des SUT sollte den Automatisierungs-Wartungsaufwand mit einbeziehen

Anzahl der falsch-negativen und falsch-positiven Ergebnisse

• Fehlalarme (falsch-positiv wie falsch-negativ) deuten auf Probleme hin und sollten vermieden werden

• Falsch-positive Tests (false-fails) senken das Vertrauen in die TAS

• Falsch-negative Tests (false-pass): ein Fehler, der nicht bemerkt wurde - der Kunde wird ihn finden!

• Falsch-negative Resultate sollten gründlich analysiert werden

• Gründe für falsch-negative Ergebnisse:

  • Fehler in den Testskripten/dem Testframework (siehe "Fehlerdichte des Automatisierungscodes")

  • instabiles (nicht-deterministisches) SUT

  • Test Hooks (beim intrusiven Test)

• Analyse

  • Verifizierung des Ergebnisses nicht richtig erfolgt?

  • ungültiges Testorakel?

  • das falsche Ergebnis erwartet?

Kosten der Messung

• Gute Metriken brauchen oft

  • eine große Anzahl Messungen,

  • eine gute Auswertung der Messungen.

• Dies kann anstrengend und zeitaufwendig sein - für den Tester ebenso wie für den TAE, TAM und den Testprojektmanager

• Automatisierung so viel wie möglich verwenden, um den Messaufwand gering zu halten

• Test- und Fehlermanagementwerkzeuge sollten bei der Automatisierung der Messungen hilfreich sein

Implementierung der Messwerterfassung

• Testmittel (als Teil der TAS) können erweitert werden, um Informationen zur Nutzung aufzeichnen

• Durch Kombination mit Abstraktion kann diese Funktionalität auch auf höheren Ebenen genutzt werden

• Beispiel: Hinzufügen der Aufzeichnung der Start- und Endzeit der Testausführung

Inhalt der TAS-Protokollierung

• Aktueller Testfall, einschließlich Start- und Endzeit

• Status der Testfallausführung

• Details des Testprotokolls auf hoher Ebene (Protokollierung wichtiger Schritte) einschließlich Zeitangaben

• Dynamische Informationen über das SUT (z. B. Speicherlecks)

• Zähler für wiederholte Testfälle (z.B. in Zuverlässigkeits- und Stresstests)

• Für zufällige Elemente im Testfall (z. B. Zufallsparameter) die Zufallswerte/-entscheidungen protokollieren

• Detaillierte Informationen (Schritte + Timing) für Testwiederholung (Reproduzierbarkeit)

• Screenshots, andere visuelle Dokumentationsarten, weitere Dumps (für die Fehleranalyse)

• Alle wichtigen Informationen im Fall einer Fehlerwirkung aufzeichnen

• Farbe verwenden, um die Lesbarkeit zu erhöhen

Berichte veröffentlichen

• Bericht sollte für jeden verfügbar sein, der Interesse hat

• Methoden für die Veröffentlichung:

  • Pull-Methoden

    • Website,

    • In Werkzeugen wie das Testmanagementwerkzeug

  • Push-Methoden

    • Mailingliste,

    • Subskriptionsliste

• Berichtshistorie erstellen (dies ermöglicht, statistische Zahlen über Testfälle oder Testsuites zu erstellen, insbesondere zur Ermittlung problematischer Teile des SUT

Vorbereitung für die Automatisierung

• Aktuellen Zustand der manuellen Tests bewerten

• Effektivsten Ansatz für die Automatisierung ermitteln

• Vorhandene Struktur eines manuellen Tests kann für die Automatisierung geeignet sein oder nicht

  • eventuell können relevante Komponenten vorhandener manueller Tests extrahiert werden oder

  • ein vollständiges Neuschreiben des Tests ist erforderlich

• Die manuelle Teststrategie sollte bereits die Automatisierung planen

• Nicht alle Tests können automatisiert werden

• Mitunter ist auch die erste Iteration eines Tests manuell

• Deshalb in zwei Schritten vorgehen:

  • Erstumwandlung existierender Tests

  • anschließende Umstellung neuer manueller Tests auf Automatisierung

Weitere Aspekte der Automatisierung

• Bestimmte Testarten können nur automatisiert ausgeführt werden

  • Zuverlässigkeitstests,

  • Stresstests,

  • Performanztests

• Automatisierung ist auch ohne Ul möglich - typisch auf der Integrationsebene

• Diese Tests können eventuell nicht (praktisch) manuell durchgeführt werden

• Auf diesen Ebenen kann das Testen eher beginnen - wenn ein manuelles Testen (noch) nicht möglich ist

Eignungskriterien für Testautomatisierung

• Verwendungshäufigkeit

• Komplexität der Automatisierung

• Werkzeugunterstützung

• Reifegrad des Testprozesses

• Eignung der Automatisierung für die Phase des Softwareprodukt-Lebenszyklus

• Nachhaltigkeit der automatisierten Umgebung

• Steuerbarkeit des SUT

• Technische Planung zur Unterstützung der ROl-Analyse

Verwendungshäufigkeit

• Meistens ist die Entwicklung eines automatisierten Testfalls ein größerer Aufwand als das Schreiben des manuellen Tests, aber die Ausführung des automatisierten Testfalls ist schneller als die manuelle Ausführung

• Testfälle, die häufig ausgeführt werden, haben wahrscheinlicher eine hohe Investitionsrendite (ROI)

• Deshalb beginnen viele Automatisierungsprojekte mit dem Regressionstest

• Je mehr Testzyklen, desto wahrscheinlicher reduziert sich der durchschnittliche Aufwand pro Testfall

• Verwendungshäufigkeit und Änderungsrate stehen in Beziehung: wenn ein Testfall (aufgrund von SUT Änderungen) für jede Ausführung angepasst werden muss, ist dieser Testfall wahrscheinlich nicht gut geeignet

Komplexität der Automatisierung

• Bei komplexen Systemen und komplexen Testfällen kann Automatisierung von enormem Vorteil sein, da es dem Tester eine Menge langwieriger, zeitaufwendiger und fehleranfälliger Aufgaben erspart

• In komplexen Situationen kann jedoch Automatisierung auch zu schwierig oder nicht kosten-effektiv sein

• Typische Faktoren für diese Situation

  • SUT ist nicht kompatibel mit bestehenden, verfügbaren, automatisierten Testlösungen;

  • Automatisierung braucht umfangreichen Programmcode (z.B. APIs erstellen, Aufrufe an APIs für die Automatisierung zu entwickeln) im SUT;

  • Vielfalt verschiedener Systeme im TAF;

  • komplexe Interaktion mit externen Schnittstellen und/oder proprietären Systemen;

  • bestimmte Aspekte von Benutzbarkeitstests (z.B. wenn intuitive Mustererkennung gebraucht wird);

  • hoher Aufwand für das Testen der Automatisierungsskripte

Werkzeugunterstützung

• Innerhalb des SUT, seiner Entwicklungsumgebung und der TAS werden eine Vielzahl Werkzeuge verwendet

• Diese Werkzeuge müssen ordnungsgemäß unterstützt werden

• Werkzeuge von kommerziellen Anbietern

  • bieten in der Regel bezahlten Support,

  • haben meist ein Netzwerk mit Experten, die Unterstützung leisten können

• Open-Source und/oder Freeware Werkzeuge haben oft Online-Foren

• Für im eigenen Haus entwickelte Testwerkzeuge braucht man interne Experten aus dem vorhandenen Personal

• TAE sollten wissen, wie man die beste Unterstützung für die jeweiligen Werkzeuge der TAS bekommt

Eignung der Automatisierung für die Phase des Softwareprodukt-Lebenszyklus

• Erfolg der Automatisierung hängt davon ab, in welcher Phase des Software-Produktlebenszyklus des SUT sie angewendet wird

• Frühe Phasen des Produktlebenszyklus:

  • Änderungsrate ist oft noch hoch

  • Kontinuierliche Verbesserungen können dazu führen, dass Automatisierung ineffizient und teuer ist

• Am Ende des Produktlebenszyklus:

  • nicht viele Releases zu erwarten und Tests werden nicht oft wiederholt

  • initiale Automatisierungskosten sind vielleicht zu hoch und Investitionsrendite (ROI) bleibt negativ

• Automatisierung ist besonders erfolgreich für stabile Systeme

• Deshalb ist es eine gute Idee, mit der Automatisierung nicht zu früh und nicht zu spät im Lebenszyklus zu beginnen

• Ein veränderliches System ist kein guter Kandidat für Automatisierung

• Wenn sich jedoch die Architektur des SUT ändert, aber die Funktionalität gleich bleibt, können Testdaten wiederverwendet werden, während die Testumgebung an die neue Architektur angepasst werden muss

Genauigkeit der Testdaten und Testfälle

• Testdaten müssen richtig und vollständig sein

• Testdaten werden gebraucht für

  • Eingabe,

  • Navigation,

  • Synchronisation,

  • Validierung

• Dies sichert vorhersagbare Ergebnisse der Testfälle

Umfang der Arbeiten zur Testautomatisierung

• Ein Hauptrisiko der Automatisierung ist, dass belegbarer Erfolg und ROl oft erst spät erzielt werden

• Früher Erfolg erlaubt nachzuweisen, dass die Automatisierung erfolgreich ist und sichert die weitere Unterstützung durch das Management

• Mit einem Pilotprojekt mit begrenztem Umfang beginnen

• Dies hilft auch dabei

  • genauere Schätzung des künftigen, zeitlichen Aufwands zu erhalten und

  • Bereiche zu ermitteln, für die spezialisierte, technische Ressourcen gebraucht werden

• Mit Testfällen mit kleinem Automatisierungsaufwand, aber hohem Mehrwert beginnen (besonders, wenn sie oft wiederholt werden)

  • Regressionstest,

  • Smoke-Tests,

  • Zuverlässigkeitstests

• Testfälle priorisieren und mit den Testfällen mit höchster Priorität starten

• Jedoch die Implementierung technisch aufwendiger Testfälle vermeiden

Berichterstattung über die Automatisierung

• Berichten ist wesentlich um Informationen zu liefern

• Stellen Sie sicher, dass Berichte automatisch generiert werden

  • Bestanden-/Fehlgeschlagen-Status (der Test-Skripte oder -Schritte)

  • Statistiken zur Testausführung

  • Performanz der TAS

• Berichten Sie über den ordnungsgemäßen Betrieb der TAS

• Stellen Sie sicher, dass Testergebnisse auf Korrektheit und Vollständigkeit geprüft sind (vgl. Kap. 7: Verifizieren der TAS)

Testausführungszeit

• Eine gute Idee ist, mit den zeitaufwendigen Tests zu beginnen

• Dies ist dann nützlich, wenn (insbesondere bei der Regression) die automatisierten Tests deutlich schneller sind

• Wenn die Regressions-Testfälle schneller werden, kann die Regressions-Testsuite öfter ausgeführt werden

• Auf diese Weise erhält man zusätzlichen Feedback über die Qualität des SUT und hat ein geringeres Verteilungsrisiko

Testen neuer Funktionen: Aspekte

• Oft einfacher zu automatisieren, da Funktion und Testautomatisierung während der Funktionsentwicklung synchronisiert werden können und die Funktion auf Testansprüche angepasst werden kann

• TAE soll Feedback von den Testentwicklern mit Spezialwissen einholen um zu ermitteln, ob die aktuelle TAS den Erfordernissen der neuen Funktionen genügt, bzw. angepasst werden muss

• TAE sollte Details der neuen Funktion verstehen, z.B.

  • genutzter Ansatz,

  • Entwicklungswerkzeuge von Drittanbietern,

  • verwendete Testwerkzeuge,

  • etc.

• Bei Änderungen der TAS sollen die Ergänzungen vollständig dokumentiert sein und das Verhalten (oder die Leistung) bestehender TAS-Funktionen nicht beeinträchtigen.

• Im Falle der Änderungen sollte der TAE besprechen ob z.B.

  • andere Lösungen gebraucht werden

  • das Schlüsselwort-Wörterbuch angepasst/erweitert werden muss

  Die Bewertung neuer Testwerkzeuge kann nötig sein

Weitere Aspekte beim Testen neuer Funktionen

• Auswirkungen der neuen Anforderung auf die existierende TAS überprüfen, z.B.

  • existierende Tests mit dem neuen SUT laufen lassen,

  • Veränderungen während der Ausführung aufzeichnen,

  • Abhängigkeiten zu anderen Tests notieren,

  • Neubewertung der aktuellen Testmittel und ihrer Kompatibilität mit der TAS

• Bei Änderungen der existierenden Anforderungen soll der Aufwand für die Anpassung der Testfälle durch eine Auswirkungsanalyse ermittelt werden

Grad der Intrusion automatisierter Testwerkzeuge

• Aufgrund der (meist) engen Verzahnung von TAS und SUT kann die Automatisierung am "Probe Effect" (Heisenbug) leiden: das Verhalten des SUT wird durch das TAS beeinflusst

• Grad der Intrusion des TAS verstehen

• Intrusion kann zu falsch-positiven Ergebnissen führen

• Falsch-positive Ergebnisse vermeiden, denn sie erschüttern das Vertrauen in die Automatisierung

• Niedriger Intrusionsgrad: Interaktionen mit dem SUT über externe Schnittstellen (z.B. via USB)

  • SUT wird für das Testen überhaupt nicht geändert

  • Kein Einfluss auf Verhalten und Timing des SUT

  • Interaktion kann sehr komplex sein

  • Dedizierte Hardware wird eventuell benötigt

  • Oft verwendet in eingebetteten Systemen, nicht so sehr in reinen SW Systemen

• Mittlerer Intrusionsgrad: Ansteuerung über GUI

  • SUT-Umgebung wird angepasst, um UI-Befehle einzugeben und Informationen auszulesen

  • Verhalten wird nicht direkt geändert, aber das Timing

  • Schnittstellenbasierte Interaktion mit dem SUT ist weniger komplex

  • Handelsübliche Software (COTS) existiert ("GUI Tester")

• Hoher Intrusionsgrad: Testschnittstellen/bestehende Schnittstellen

  • Verhalten und Timing können massiv abweichen

  • Äußerst einfach und kostengünstig

  • Solider Ansatz, aber das Risiko sollte verstanden sein

Schritte beim Testen automatisierter Testsuites

• Ausführung von Testskripten mit bekannten Bestanden- und Fehlgeschlagen-Ergebnissen

• Prüfen der Testsuite

• Verifizieren neuer Tests mit Fokus auf die neuen Funktionen des Frameworks

• Gewährleisten der Wiederholbarkeit von Tests

• Prüfen, ob die automatisierte Testsuite genug Verifizierungspunkte bietet

Ermitteln von Änderungen an Komponenten der Testumgebung

• Welche Änderungen/Verbesserungen werden gebraucht?

  • an der Testsoftware,

  • an systemspezifischen Funktionsbibliotheken,

  • im Betriebssystem

• Auswirkungen auf die TAS bestimmen - sicherstellen, dass die automatisierten Tests weiterhin effizient ausgeführt werden

• Änderungen inkrementell anwenden und die Auswirkungen kontinuierlich messen

• Die volle Regression durchführen nachdem Änderungen realisiert wurden

• Bei Fehlern während des Regressionstests: sicherstellen, dass sie nicht durch die Verbesserungsaktivitäten kommen

Konsolidieren mehrerer Funktionen, die auf denselben Steuerungstyp wirken

• In SW-Systemen, und auch der TAS, ist ähnliche Funktionalität über das gesamte System verteilt

• Diese Effekte entstehen durch die Weiterentwicklung des Systems und auch seine Modularität

• Regelmäßiges Refaktorisieren der Software ist wesentlich

• Teil des Refaktorisierens ist der Versuch, ähnliche Funktionalität in kompakte Prozeduren zu kombinieren, um Komplexität des System und Probleme mit Kopieren und Einfügen zu verringern, um dadurch auch die Fehleranfälligkeit und den Wartungsaufwand zu reduzieren

• Dieses Phänomen kennt man von Uls und anderen Schnittstellen, da ähnliche Funktionen mit z.B. verschiedenen Eingabemethoden und Datenformaten arbeiten