Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Qualitätssicherung von Software (SWQS) Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin und Fraunhofer FOKUS 7.5.2013: Integrationstests.

Ähnliche Präsentationen


Präsentation zum Thema: "Qualitätssicherung von Software (SWQS) Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin und Fraunhofer FOKUS 7.5.2013: Integrationstests."—  Präsentation transkript:

1 Qualitätssicherung von Software (SWQS) Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin und Fraunhofer FOKUS : Integrationstests

2 Folie 2 H. 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?

3 Folie 3 H. Schlingloff, Software-Qualitätssicherung Wo stehen wir? Kapitel 2. Softwaretest 2.1 Testen im SW-Lebenszyklus 2.2 Funktionale Tests, Modultests, Testfallauswahl 2.3 Strukturelle Tests, Integrationstests 2.4 Modellbasierte Tests Kapitel 1: Einleitung, Begriffe, Software-Qualitätskriterien

4 Folie 4 H. 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

5 Folie 5 H. Schlingloff, Software-Qualitätssicherung attributierter Kontrollflussgraph void ZaehleZchn (int& VokalAnzahl, int& Gesamtzahl){ char Zchn; cin>>Zchn; while ((Zchn>=`A´) && (Zchn<=`Z´) && (Gesamtzahl>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)

6 Folie 6 H. 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

7 Folie 7 H. Schlingloff, Software-Qualitätssicherung Pause! Endbenutzer-Abnahmetest

8 Folie 8 H. Schlingloff, Software-Qualitätssicherung Integrations- und Systemtest Tested Subsystem Code Systemtest Integrations Unit Tested Subsystem Requirements Analysis Document System Design Document Tested Subsystem test Test Unit Test Unit Test User Manual Requirements Analysis Document Subsystem Code Subsystem Code Deliverable System Integrated Subsystems Test Abnahme

9 Folie 9 H. 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

10 Folie 10 H. 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)

11 Folie 11 H. 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?

12 Folie 12 H. 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

13 Folie 13 H. 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

14 Folie 14 H. 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)

15 Folie 15 H. 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) ersetzt Modul A Modul F Modul C Modul DModul B Modul E

16 Folie 16 H. Schlingloff, Software-Qualitätssicherung Vor- und Nachteile (1) Big-bang keinerlei Zusatzaufwand für Treiber/Platzhalter unsystematische Methode, Test problematisch Fehlerlokalisation 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

17 Folie 17 H. 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

18 Folie 18 H. 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!

19 Folie 19 H. 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

20 Folie 20 H. 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?

21 Folie 21 H. 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?

22 Folie 22 H. 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!

23 Folie 23 H. 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

24 Folie 24 H. 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

25 Folie 25 H. 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)

26 Folie 26 H. 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


Herunterladen ppt "Qualitätssicherung von Software (SWQS) Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin und Fraunhofer FOKUS 7.5.2013: Integrationstests."

Ähnliche Präsentationen


Google-Anzeigen