Media:V7 Zusammenfassung_lang.pdf - FOM-Wiki

Zusammenfassung V7 - Verifikation und ValidierungZusätzlich aus SCR (=> Verständnis)Verifikation:– Sicherstellung, dass Ergebnisse einer Phase des Projektes mit der vorangegangenen Phasekonsistent sind– => Wurde das System richtig entwickelt?Validierung:– Überprüfung, ob das Endergebnis des Projektes den Bedürfnissen des Kunden entspricht– => Wurde das richtige System entwickelt?Kosten im Zeitverlauf:– Wird ein Fehler in einer frühen Entwicklungsphase (Analyse, Entwurf, Implementierung) gemachtund erst in einer späten Phase (Systemtest, Wartung) entdeckt, so sind die dadurch entstehendenKosten besonders hochQualitätsprioritäten:– Korrektheit, Sicherheit, Performance, schnelle Entwicklung (baldige Verfügbarkeit), geringerAufwand (geringe Kosten), Wartbarkeit, hoher Deckungsgrad der Anforderungen, Flexibilität,Stabilität.Testziele:– Hoher Deckungsgrad der Funktionen, hohe Fehlerfindungsrate, schneller Test, geringer Aufwand(geringe Kosten für die Durchführung der Tests), Beweis der Korrektheit, Wiederholbarkeit, geringeAnforderungen an TesterZusammenfassung der Vorlesungsfolien(Software-)QualitätssicherungJede geplante und systematische Tätigkeit, die innerhalb des Systems verwirklicht wird und dargelegt wird,um Vertrauen dahingehend zu schaffen, dass eine Einheit die Qualitätsanforderungen erfüllen wird.Qualitätssicherung ist die Summe aller Maßnahmen, um konstante Produktqualität sicherzustellen.Verifikation und Validierung planen• geeigente Kombination aus statischen und dynamischen Verfahren• Entwurf von Standards und Prozeduren für Inspektion und Test• Ausarbeitung von Checklisten und Testplänen• je kritischer ein System, umso mehr Gewicht sollte auf statischen Verfahren der Verifikation liegen

Softwaretestplan Struktur:• Testablauf, Nachvollziehbarkeit, Testobjekt, Zeitplan, Aufzeichnung, HW/SW-Anforderungen,EinschränkungenSoftwaretestprozess Ziele:• SW erfüllt ihre Anforderungen > Testfälle entsprechen Systemnutzung• Aufspüren von Fehlern > Testfälle passend um Defekte aufzuspüren• Vertrauen in die SW entwickeln• SW soll für den betrieblichen Einsatz ausreichend ??? (Fehler in Folie)Teststufen (V-Modell)• Komponenten-, Modultest => Test durch Entwickler, ob isoliert fehlerfrei funktionsfähig• Softwareeinheit mit wohldefinierter Schnittstelle (Datenkapselung)• Bestandteile: Testtreiber, Platzhalter (Stub) für Simulation, Testrahmen als Infrastruktur mitbenötigten Treibern und Stubs• Komponentenarten: Einzelfunktionen oder Methoden innerhalb eines Objekts, Objektklassen,Zusammengesetzte Komponenten• Integrationstest => Überprüfen des Zusammenspiels zwischen Komponenten• Aufspüren von Systemfehlern• Test unvollständiger Systeme• Regressionstests• Systemtest => Test funktionaler und nicht-funktionaler Anforderungen durchunabhängiges Testteam• Testumgebung möglichst gleich Produktivumgebung• Grundlage: Anforderungsspezifikation, Anwendungsfälle, Geschäftsprozesse, Risikoanalysen,Erfahrungen, Systemressourcen• 2 Phasen:• Integrationstest (siehe oben; => Widerspruch zu Teststufen im V-Modell !?)• Auslieferungstest => Validierung gegen Anforderungen• Black-box Verfahren, funktionales Testen E/A• ggf. Abnahmetest bei Kundenbeteiligung• Beweis von Funktionalität, Leistung und Verlässlichkeit (Leistungstests)• (Schnittstellentest) => übergreifend in Modul-, Integrations- und Systemtest vertreten lt.Wikipedia• Parameterschnittstellen, Schnittstellen mit gemeinsamem Speicher, Prozedurschnittstellen,Schnittstellen zur Nachrichtenübergabe

• Fehlerklassen: Falsche Verwendung, Schnittstellenmissverständnis, Zeitabstimmungsfehler• Abnahmetest• => ab hier bzw. ab Auslieferungstest Bereich Validierung (nicht mehr Verifikation)• Anwender-Abnahmetest => Kunde prüft Einsatztauglichkeit• Feldtest => Repräsentant prüft vor Auslieferung• Alpha- und Beta-Test => Alpha beim Hersteller, Beta beim Kunden• Betrieblicher Abnahmetest => Abnahme durch Systemadministrator• Vertragsabnahmetest => Gegen vertragliche Abnahmekriterien• Regulative Abnahmetests => Gegen alle Regularien denen das System entsprechen muss• ProduktabnahmeIntegrationsstrategienBig-Bang:– Integration aller Komponenten/Module in einem Arbeitsschritt– Kein Aufwand für Simulatoren, aber aufwändige Fehlersuche und -behebung– Einsatz: Falls keine andere Strategie anwendbar; in späten Phasen der SW EntwicklungBottom-Up:– Beginn auf unterster Ebene– Aufrufende Funktionen durch Testtreiber simuliert– Keine Platzhalter benötigt, aber kein Prototyp und erst späte Präsentation– Einsatz: Klare Anforderungen, kurze Projektdauer, kein Prototyp nötigTop-Down:– Beginn auf oberster Ebene– Aufgerufene Funktionen werden simuliert– Früher Prototyp, Präsentation und Validierung der Bedienlogik, aber Aufwand für Platzhalter– Einsatz: Evaluierung der Bedienlogik, schnell sichtbare Ergebnisse, mittlere/langeProjektlaufzeit => z.B. in Verbindung mit funktionsorientierter I. für GUI ProgrammierungVertikale/Funktionsorientierte Strategien:– Komp./Module Integrieren die gemeinsame Systemfunktion realisieren– Benutzerorientiertes zielgerichtetes Vorgehen, aber Gefahr der Vernachlässigungrisikoreicher Funktionen, aufwändige Fehlersuche und ggf. später Testbeginn– Einsatz: Kombination mit anderen Strategien wie bottom-upSonstige Strategien:– Hardest-first => für kritische Komponenten/Module– „bei Verfügbarkeit“– Transaktionsorientierte IntegrationAuswahl richtiger Kombination von Strategien und Anpassung der Projektplanung an Reihenfolge

Prüfung / PrüfverfahrenStatische Prüfung (Analyse => Prüft die Beschreibung des Testobjektes)zur Verbesserung der Qualität; früh einsetzbar; frühe Fehlererkennung; Wissenstransfer;Untersuchung auf Fehler, Lücken, Anomalien; Fokus auf Quellcode; Wechselwirkungen irrelavant;auch von unvollständigen Versionen möglich; ermöglicht weitergehende Betrachtunghäufig effektiver und billiger als dynamische Tests– (Stellungnahme => Autor stellt Code zum Lesen zur Verfügung)– Walkthrough => Autor geht Prüfling mit Gutachtern durch; geringe Entdeckungsrate– begrenzte Vorbereitung, kritische Betrachtung durch Gutachter– Review => Qualifiziertes Team beurteilt Produkt– Identifikation von Abweichungen von der Spezifikation oder verwendeten Standards– Phasen: Planung, Initialisierung, Vorbereitung, Sitzung, (Dritte Stunde), Nacharbeit,(Analyse)– Rollen: Review-Leiter, Protokollant, Reviewer, Autor, Vorleser– Inspektion => Identifikation von Anomalien sowie Schwächen im Entwicklungsprozess– Startsitzung: Vorstellen des Prüflings– Vorbereitung: jeder Teilnehmer individuell– Sitzung: Code wird Zeile für Zeile vorgelesen, Einhaken und Befunde vorbringen– Überarbeitung/Nachkontrolle: Beschließen/Durchführen von Änderungen, Nachkontrolle– Rollen: Manager, Moderator/Protokollant, Autor, Reviewer– Phasen: Planung, Überblick, indiv. Vorbereitung, Inspektionssitzung, Überarbeitung,Nachbereitung– Voraussetzungen: genaue Spezifikation des Codes; Mitglieder mit organisationseigenenStandards vertraut; aktuelle kompilierbare Codeversion verteilt– Zeit und Codemenge einer Inspektion:– Überblicksphase: 500 Quelltextanweisungen / h– Individuelle Vorbereitung: 125 Anweisungen / h– Inspektionssitzung: 90-125 Anweisungen / h (Dauer ca. 1 h)– Ideal zur Datenerhebung über Fehlerarten, aber Gefahr von „Finger-Pointing“Dynamische Prüfung (Test => Prüft den aus der Beschreibung resultierenden Prozess)– Funktional / Spezifikationsorientierter Test– Black-box, E/A, Äquivalenzklassen, Grenzwerte– Strukturorientierter Test– White-box, daten-/kontrollflussbezogen, BedingungsüberdeckungAutomatisierte statische Analyse– Inspektionen vielfach von Fehlerchecklisten und Heuristiken gestützt– Parsen des Codes und Erkennen von Anomalien– Erkennen von Programmierfehlern oder Versäumnissen– Analyse-Phasen: Steuerungsablauf, Datenverwendung, Schnittstellen, Informationsfluss, Pfade

Verifikation und formale Methoden– Mathematische Analyse der Spezifikation; formale Verifikation– Umwandlung in detaillierte semantisch gleichwertige Darstellung– Gut zur Entdeckung von Spezifikationsproblemen; Konsistenz zwischen Spezifikation und Code– Teuer und aufwändig, daher speziell für systemsicherheitskritische Software– Keine Garantie für Zuverlässigkeit (Problem der Lesbarkeit, Beweisverfahren ggf. fehlerhaft; ggf.nicht zutreffendes Nutzungsmuster vorausgesetzt)– Cleanroom-Softwareentwicklung: Rigorose Inspektion mit formalen Methoden– Formale Spezifikation > Inkrementelle Entwicklung > Strukturierte Programmierung >Statistische Verifikation > Statistische SystemtestsDynamische TestsEntwurf von Testfällen (Ansätze)• Anforderungsbasiertes Testen• Äquivalenzklassen (Gruppen von Daten mit gleichen Eigenschaften; Grenzwerte)• Strukturelle Tests (Ausführung aller Programmteile anhand Struktur und Implement.)• Anweisungsüberdeckung (C0-Überdeckung)– Abdeckung aller Anweisungen des Kontrollflussgraphen durch min 1 Testfall– Sehr schwaches Abdeckungsmaß• Zweigüberdeckung (C1-Überdeckung)– Abdeckung jeder Kante des Kontrollflussgraphen durch min 1 Testfall– Schwierigkeit bestimmte Systemzustände oder Datenkonstellationen zu erreichen– Häufig Kombinationen von Programmzweigen oder komplexe Bedingungen zuwenig beachtet; Programmschliefen nicht ausreichend getestet• Einfacher Bedingungsüberdeckungstest (C2-Überdeckung)– Entscheidungsstruktur als Grundlage für Testfallermittlung– Jede atomare Entscheidung soll 1x wahr und 1x falsch annehmen– Hinreichende Bedingung:– Problem dass weitere Teilbedingungen ungetestet bleiben können– bei „oder“ muss nur erste Teilbedingung „wahr“ ergeben– bei „und“ muss nur erste Teilbedingung „falsch“ ergeben• Mehrfach-Bedingungsüberdeckungstest (C3-Überdeckung)– wie C2 plus Gesamtentscheidung und alle zusammengesetzten Teilentscheidungen– hoher Testaufwand: 2^n Testfälle bei n Teilentscheidungen– Minimaler Mehrfach-Bedingungsüberdeckungstest– wie C2 plus Gesamtentscheidung muss 1x „wahr“ und 1x „falsch“ ergeben• Pfadüberdeckungstests (C4-Überdeckung)– Erprobung jedes einzelnen unabhängigen Ausführungspfades mittels Testfällen– Nicht alle denkbaren Kombinationen aller Pfade werden überprüft– Hauptsächlich bei Komponententests verwendet– Ausgangspunkt liefert ein KontrollflussgraphTestautomatisierung– Teure und aufwändig Phase– Verwendung von Testwerkzeugen– meist Konfiguration und Anpassung für das Testobjekt nötig– Testmanager (Ausführungsverwaltung), Orakel (Voraussagen über Testergebnisse),Datenvergleichswerkzeuge (Vergleich mit früheren Testergebnissen), Berichtsgenerator,Dynamisches Analysewerkzeug (Mitzählen der Ausführungen), Simulator (Zielsimulatoren,Benutzerschnittstellensimulatoren)

Validierung kritischer SystemeGründe für Zusatzziele: höhere potentielle Kosten bei Ausfall, Zertifizierung durch Behörden• Validierung der Zuverlässigkeit• Statistischer Test zur Beurteilung Zuverlässigkeit, nicht Fehlersuche• Schwierigkeiten: Unsicherheiten des Betriebsprofils; hohe Kosten > Testdaten; statistischeUnsicherheiten wenn hohe Zuverlässigkeit spezifiziert• Vorhersagen der Zuverlässigkeit (ROCOF: Rate Of Occurrence Of Failures): Erreichunggefordertes Zuverlässigkeitsniveaus; Verwendung eines Zuverlässigkeitswachstumsmodells1. Bestimmung des Betriebsprofil (anhand bestehenden Systemen gleichen Typs)2. Erzeugung von Testdaten (Häufigkeit, Testdatengenerator)3. Anwendung der Tests (Protokollierung von Anzahl, Art und Zeitpunkt der Fehler)4. Berechnung der Zuverlässigkeit• Gewährleistung der Betriebssicherheit• Herstellen von Vertrauen über Beweise / Gegenbeweise• Reviews zur Sicherstellung der Betriebssicherheit (richtige Funktion, wartungsfreundlicheStruktur, spezifiziertes Verhalten, Konsistenz von Code und Entwurf, Angemessenheit derTestfälle)• Hoher Aufwand für Korrektheitsbeweis• Gegenbeweis als Methode zur Demonstration (Annahme: unsicherer Zustand)• Prüfung der Betriebssicherheit zur Laufzeit• Exception auslösen, wenn Randbedingungen verletzt werden• Beurteilung der Systemsicherheit• Zunehmende Bedeutung für Web-basierte Systeme• Schwierigkeit von „Darf-Nicht“-Anforderungen• Ansätze zur Überprüfung: Erfahrungs-/Werkzeugbasierte Validierung, Angreiferteams• Sicherheits und Zuverlässigkeitsszenarien• Dokumentierte Beweissammlung > Argumentation über Betriebssicherheit• Tw. durch gesetzliche Vorschriften geregelt• Logische Argumente: Absolute Argumente, Wahrscheinlichkeitsargumente• Behauptung > Nachweise > Argument