Qualitätssicherung von Software (SWQS)
Prof. Dr. Holger Schlingloff
Humboldt-Universität zu Berlinund
Fraunhofer FOKUS
7.5.2013: Integrationstests
Folie 2H. Schlingloff, Software-Qualitätssicherung
Fragen zur Wiederholung
• Welche Überdeckungskriterien kennen Sie?
• Warum ist Überdeckungsmessung wichtig?
• Welche Problematik gibt es dabei?
• Was versteht man unter MC/DC?
• Wie konstruiert man eine vollständige Testsuite?
Folie 3H. Schlingloff, Software-Qualitätssicherung
Wo stehen wir?
Kapitel 2. Softwaretest
2.1 Testen im SW-Lebenszyklus2.2 Funktionale Tests, Modultests,
Testfallauswahl2.3 Strukturelle Tests,
Integrationstests2.4 Modellbasierte Tests
Kapitel 1: Einleitung, Begriffe, Software-Qualitätskriterien
Folie 4H. Schlingloff, Software-Qualitätssicherung
Wdh.: Datenflussorientierter Test
• Variablen und Parameter Lebenszyklus:
erzeugen – (schreiben – lesen*)* – vernichten computational use versus predicate use Zuordnung von Datenflussattributen zu den
Knotens des Kontrollflussgraphen
• Berechnung der Variablenzugriffe für jeden Definitionsknoten n für Variable x die
Mengen dcu(x,n) und dpu(x,n) aller Knoten, in der x (berechnend oder prädikativ) verwendet wird
Literatur: S. Rapps, Selecting Software Test Data Using Data Flow Information
IEEE Transactions on Software Engineering, April 1985
Folie 5H. Schlingloff, Software-Qualitätssicherung
attributierter Kontrollflussgraph
void ZaehleZchn (int& VokalAnzahl, int& Gesamtzahl){char Zchn;cin>>Zchn;while ((Zchn>=`A´) && (Zchn<=`Z´) && (Gesamtzahl<INT_MAX)){
Gesamtzahl+=1;if ((Zchn==`A´)||
(Zchn==`E´) || (Zchn==`I´) || (Zchn==`O´) || (Zchn==`U´)){
VokalAnzahl +=1;}cin>>Zchn
}}
def(VokalAnzahl)
def(Gesamtzahl)start
n1
n2
n4
n5
n6
ende
n3
def(Zchn)
p-use(Zchn), p-use(Gesamtzahl)
c-use(Gesamtzahl)
def(Gesamtzahl)
p-use(Zchn)
c-use(VokalAzahl)
def(VokalAnzahl)
def(Zchn)
c-use(VokalAzahl)
c-use(Gesamtzahl)
Folie 6H. Schlingloff, Software-Qualitätssicherung
Defs/Uses-Kriterien zur Testabdeckung
• Testfallerzeugung berechne Pfade zwischen Definition und Verwendung ungenutzte Definitionen markieren Fehler
• Kriterien all defs: Jeder Pfad von einer Definition zu mindestens einer
Verwendung enthalten all p-uses: Jeder Pfad von einer Definition zu irgendeiner
prädikativen Verwendung- subsumiert Zweigüberdeckung
all c-uses: analog, zu computational use all c-uses/some p-uses: jede berechnende oder mindestens
eine prädikative Verwendung all uses: jede Verwendung du-paths: Einschränkung auf wiederholungsfreie Pfade
Folie 7H. Schlingloff, Software-Qualitätssicherung
Pause!
Endbenutzer-Abnahmetest
Folie 8H. Schlingloff, Software-Qualitätssicherung
Integrations- und Systemtest
Tested Subsystem
SubsystemCode
SystemtestIntegrations
Unit
TestedSubsystem
RequirementsAnalysis
Document
SystemDesign
Document
Tested Subsystem
test
Test
Unit Test
Unit Test
User Manual
RequirementsAnalysis
Document
SubsystemCode
SubsystemCode
DeliverableSystem
IntegratedSubsystems
TestAbnahme
Folie 9H. Schlingloff, Software-Qualitätssicherung
Integrationstest
• Ziel: Systematische Erprobung des korrekten Zusammenspiels von Modulen
• „Modultest auf höherer Abstraktionsebene“• White-Box auf Modulebene
Komponenten und Verbindungen sind sichtbar
• Vorbedingung: die elementaren Module sind gut getestet; man kann annehmen, dass sie weitgehend fehlerfrei sind (neu auftretende Fehler sind auf Inkompatibilitäten zwischen den Modulschnittstellen zurückzuführen)
• Methode: Platzhalter und Treiber
Folie 10H. Schlingloff, Software-Qualitätssicherung
Platzhalter (stubs, Stümpfe)
• Ein Platzhalter (stub) ist ein Pseudo-Modul, der die Funktionalität einer noch nicht geschriebenen oder integrierten Komponente (partiell) emuliert
• Implementierungsmöglichkeiten z.B. Rückgabe eines konstanten Wertes statt eines
berechneten Funktionswertes z.B. Anzeigen der Eingabewerte und Zurückgeben
von vom Benutzer eingegebener Werte z.B. Erzeugung von schnellen Prototypen oder
schlecht synthetisierten Funktionen, die mit wenig Aufwand erstellt werden kann („Wegwerfsoftware“)
Folie 11H. Schlingloff, Software-Qualitätssicherung
Treiber und Orakel
• Ein Treiber ist ein Modul welches ein zu testendes Modul (IUT, Implementation under Test) aufruft und mit Eingabedaten versorgt
• Orakelproblem: Entscheidung ob die von der IUT zurück gelieferten Werte korrekt sind lösbar: automatische Testauswertung im Treiber unlösbar: manuelle Bewertung der Tests
• Beispiele für lösbare bzw. unlösbare Orakelprobleme Treiber zum Test einer Additionsfunktion sende „i“, prüfe ob Turingmaschine „i“ terminiert wird ein Programmtext korrekt übersetzt? Erfolgt die Berechnung innerhalb einer
Millisekunde?
Folie 12H. Schlingloff, Software-Qualitätssicherung
Beispiel
NextDate (int *t,m,j) {... x=tim(m) ...}
int tim (int m) {return 31}
void TestIt () {... NextDate(i,j,k)) ...} Treiber
Stub
Modul unter Test
Folie 13H. Schlingloff, Software-Qualitätssicherung
Ergebnisse Integrationstest
•Was kann bei der Integration schiefgehen? undokumentierte Seiteneffekte Eigenschaften des Betriebssystems,
Speicherlecks Parallelität, Verklemmungen Kommunikationsverzögerungen
•Oft wird für die Integration zusätzliche „glueware“ benötigt, die nicht im Modultest getestet wurde
Folie 14H. Schlingloff, Software-Qualitätssicherung
Durchführung (1)
• Möglichkeiten: Big-Bang, Top-down, Bottom-Up, Sandwich• Big-Bang
Alle individuellen Komponenten werden an einem Tag zusammengesetzt und getestet
Klingt verwegen, ist aber manchmal nicht anders machbar(z.B. wegen Verfügbarkeit spezieller Ressourcen, organisatorische Trennung zwischen Testphasen nicht möglich o.ä.)
• Top-Down Platzhalter (Stubs) für alle Komponenten vorbereitet Übergeordnetes Modul wird mit Platzhaltern getestet diese werden einer nach dem anderen durch untergeordnete
Module ersetzt- breadth-first oder depth-first
während die Module integriert werden, müssen einige Tests erneut durchgeführt werden (Regressionstest)
Folie 15H. Schlingloff, Software-Qualitätssicherung
Durchführung (2)
• Bottom-Up Treiber für alle Komponenten vorbereitet Basismodule werden in sogenannte „Builds“ gruppiert und
integriert idealerweise wertet der Treiber die Ergebnisse der Testläufe
aus Treiber werden nach und nach ersetzt, Funktionsumfang
wächst ständig• Inkrementell (Sandwichmethode, 3-Schichten-Methode)
Zusammenwachsen des Systems von oben und unten Stümpfe für übergeordnete Module, Treiber für Basismodule Platzhalter bzw. Treiber werden bedarfsgerecht (in
Abhängigkeit der Testphase) ersetztModul A
Modul F
Modul C Modul DModul B
Modul E
Folie 16H. Schlingloff, Software-Qualitätssicherung
Vor- und Nachteile (1)
• Big-bangkeinerlei Zusatzaufwand für Treiber/Platzhalterunsystematische Methode, Test problematischFehlerlokalisation evtl. schwierig
• inkrementell Integration bei Fertigstellung der Komponente
möglich Testfälle können vergleichsweise einfach
konstruiert werden, Testüberdeckung kann gewährleistet werden
Gegebenenfalls viele Testtreiber/Platzhalter nötig
Folie 17H. Schlingloff, Software-Qualitätssicherung
Vor- und Nachteile (2)
• Top-down frühe Verfügbarkeit des Systems aus Benutzersicht („Prototyp“) Verzahnung von Entwurf und Implementierung schwierige Implementierung der Platzhalter mit zunehmender Integrationstiefe Schwierigkeiten bei der
Konstruktion von Testfällen für tiefer liegende Komponenten Zusammenspiel der Systemsoftware, Hardware und
Anwendungsebene wird erst sehr spät getestet• Bottom-up
keine Platzhalter nötig Testbedingungen leicht herstellbar Testergebnisse einfach zu interpretieren Fehleingaben zur Prüfung der Ausnahmebehandlung lauffähiges Gesamtsystem erst sehr spät verfügbar und getestet Fehler in der Produktdefinition werden spät erkannt, können zu
umfangreichen Änderungen führen
Folie 18H. Schlingloff, Software-Qualitätssicherung
Beispiel: Währungsrechner
• Funktionalität: Währungsumrechner, textuelle Eingabe, benutzbar auch als Webservice
(a) Entwerfen sie eine Systemdekomposition(b) Entwerfen Sie ein Konzept für die
Integrationstests
• jetzt!
Folie 19H. Schlingloff, Software-Qualitätssicherung
System- und Abnahmetest
• abschließender Test bei der Produkt(neu)- entwicklung
• Kundensicht statt Entwicklersicht• mit oder ohne Auftraggeberbeteiligung• möglichst in kontrollierter Testumgebung• Basis: Produktdefinition (Pflichtenheft, Spezifikation
etc.) und Produkt (Software, Handbücher etc.)• Ziele
Vollständigkeit Leistung bzw. Effizienz Zuverlässigkeit und Robustheit Sicherheit (Security) Benutzbarkeit, Dokumentation
Folie 20H. Schlingloff, Software-Qualitätssicherung
Systemtest: Vollständigkeit
•Überprüfung aller in der Spezifikation geforderten Systemeigenschaften
•Black-Box-Sicht auf das SUT
•Testdokumentation nach standardisierter Beschreibung
• Installation, Interoperabilität, Inbetriebnahme?
Folie 21H. Schlingloff, Software-Qualitätssicherung
Systemtest: Leistung
•Massen- bzw. Zeittest: Wieviele Daten können wie schnell verarbeitet werden Massentestdatengenerierung
- durch automatische Skripte, Testdatengenerator- Importschnittstelle- praxisgerechtes Datenprofil?- reale Daten vom Auftraggeber?
Realzeitverhalten- Spezifikation mit festen Daten?- Tester muss schneller als Testling sein- Kommunikations-Verzögerungszeiten?
Folie 22H. Schlingloff, Software-Qualitätssicherung
Systemtest: Zuverlässigkeit
• Lasttest: Test des Systems an den (geforderten) Grenzen der Leistungsfähigkeit Beispiel: Mehrbenutzerbetrieb mit maximaler Benutzeranzahl,
alle Benutzer verlangen gleichzeitig hohe Systemleistung
• Stresstest: temporäres Überschreiten der Grenzen Wie verhält sich das System bei Überlast? Normalisiert sich das System anschließend wieder?
• Robustheitstest: Test des Systemverhaltens bei Ausfall einzelner Teile oder unter anormalen Umgebungsbedingungen (Fehlertoleranz!) z.B. Nichtverfügbarkeit von Systemressourcen, Ausfall von
externen Softwareteilen, fehlerhafte Schnittstellenbenutzung nichtzerstörende Methoden erwünscht!
Folie 23H. Schlingloff, Software-Qualitätssicherung
Systemtest: Sicherheit
•Überprüfung der spezifizierten (!) Sicherheitsmaßnahmen z.B. Zugriffsrechtsverletzungen auf
Systemdaten z.B. Abgleich von Passwörtern mit Lexika
•„systematische“ Einbruchsversuche schwierig
•mindestens: Überprüfung bekannter Sicherheitslöcher
Folie 24H. Schlingloff, Software-Qualitätssicherung
Systemtest: Benutzbarkeit
• Benutzerakzeptanz entscheidend!• Evaluation von Oberflächen schwierig!
• meist nicht durch systematische Test, sondern Ausprobieren Benutzung durch ausgewählte nichtvorgebildete Benutzer Inspektion der Handbücher und Hilfe bzgl. Verständlichkeit
• Systematische Möglichkeiten Aufzeichnung von Benutzerinteraktionen (wann wurde
welcher Knopf geklickt) Aufzeichnung von Mausspuren (Wegeminimierung) Videoüberwachung in der Initialphase
(wann musste das Handbuch konsultiert werden)
• Beispiel: Otto-Versand
Folie 25H. Schlingloff, Software-Qualitätssicherung
Abnahmetest
• immer mit Auftraggeberbeteiligung normalerweise in realer Einsatzumgebung ggf. mit echten Daten, normale Betriebsbedingungen
• Unterteilung Abnahmekriterien aus der Produktdefinition,
Beispiele aus dem Benutzerhandbuch Testfälle aus dem Systemtest Test des typischen Verhaltens über einen gewissen
Zeitraum unsystematisches Ausprobieren (protokolliert)
• juristische Relevanz! (Unterschriften)
Folie 26H. Schlingloff, Software-Qualitätssicherung
Vorgehensweise Abnahmetest
• Neuerzeugen bzw. Installieren des SUT• danach Ausführen der Tests• Gewichtung der aufgetretenen Probleme
Abnahmebescheinigung Nachbesserungsforderungen Rückgabe bzw. Minderung
• Feldtests (durch die künftigen Anwender) alpha-Test: beim Hersteller beta-Test: beim Kunden bzw. Anwender
- Protokollierung der Fehler!- Problematik Public-domain-Feldtests