Hol' Dir diese Lernkarten, lerne & bestehe Prüfungen. Kostenlos! Auch auf iPhone/Android!

Zunehmende Komplexität

Technische Komplexität
(Umfang der Datenmodelle,verteilte Implementierung,Heterogenität der Infrastruktur(Kommunikationsmedien,Protokolle,Betriebssysteme))
Funktionale Komplexität
(Umfang der Funktionalität, Mensch-Maschine-Schnittstelle,
Diversifizierung der Funktionalität)
Entwicklungskomplexität
(Einflussnahme des Kunden,Innovationsdruck,Entwicklung in Zulieferketten)


Qualität,Kosten,Termine

Qualität
(Nutzersicht:Funktionsvielfalt,Sicherheit,Perfomanz, Entwicklersich: Wartbarkeit,Wiederverwendbarkeit)
Kosten
(Entwicklungskosten, Vermarktbarkeit,Kosten im Gesamtlebenszyklus)
Entwicklungszeit
(Time to Market, Reaktionszeit bei Änderungen)


+

Steigende Anforderungen ( Leistungsfähigkeit, Zuverlässigkeit, Qualität)
Kurze Technologiezyklen ( Hardware/Software)
Hohe Anforderungsänderung
Druck der Kostenreduzierung
Dominierung von Fachlichkeit
(Entwickler: umfangreiches technisches Wissen,
Fachabteilung und Entwickler auf völlig unterschiedlichen Abstraktionsebenen, Abstraktionsiveau Entwicklungsansätze zu niedrig...)


Bedarf nach höherem Abstraktionsniveau
Forderung: durchgängigere Auswahl Ausdrucksmittel

Abstrahieren und fokussieren,
Brücken schlagen zwischen fachlicher Problemwelt und technischer Lösungswelt:

Kernideen ( z.B. UML)
konsequente Nutzung,
Vermeidung von Modellbrüchen
Einsatz von Softwaremodellen mit fachlicher Semantik
(fachliche Anforderungen von konkreter Technologien entkoppeln,
Wiederverwendung fachlicher Aspekte)

Abstraktion
Ausblenden von Detailinformationen
Einsatz von geeigneten SW-Modellen

Strukturierung / Modularisierung
Gliederung und Aufteilung in klar abgegrenzte Unterstrukturen,Module
Partitionierung der Aufgaben(Dekomposition)
Einsatz von geeigneten SW-Modellen

Methodik und Semantik
Verwendung bewährter Verfahren und Lösungsmuster
Systematisierung des Entwicklungsprozesses
Code Ebene: Design Pattern, Architektur: Referenzarchitekturen

Anwendungsfalldiagramm: Enthält die Anforderungenan das System, externe Verhalten des Systems aus Nutzersicht,
Was leistet System für seine Umwelt(Nachbarsysteme..)?
geeignet für Kontextabgrenzung, hohes Abstraktionsniveau, einfache Notationsmittel)
Klassendiagramm: Klassenstruktur des Systems, Beziehungen zwischen Klassen
Zustandsdiagramm:  dynamisches Verhalten der Komponenten, beschreibt das Verhalten von Anwendungsfällen
(eindeutig und weniger interpretierbar,können Testfälle abgeleitet werden)
Aktivitätsdiagramm: Spezifiziert Kontrollfluss zwischen den Komponenten, Details des Anwendungsfalles festlegen, realisiert mein System ein bestimmtes Verhalten?
Sequenzdiagramm: Interaktion durch Nachrichtenaustausch, Wer tauscht mit wem welche Information in welcher Reihenfolge aus?
(detailierter Austausch zw. Kommunikationspartnern,präzise Darstellung zeitlicher Abfolge mit Nebenläufigkeiten, Schachterlung von Flusssteuerung)
Verteilungsdiagramm:Verteilung der Software auf Hardware:
Wie sieht Einsatzumfeld aus(Server,Datenbanken..)?Wie Komponente wohin zur Laufzeit verteilen?,

Paketdiagramm: Fasst Diagramme eines Systemteils zusammen: Wie kann ich mein Modell schneiden,dass Überblick bewahrt? ( organisiert Modell in größere Einheiten, durch logische Zusammenfassung von Elementen, Modellieren von Abhängigkeiten und Inklusionen möglich)

Einschränkung:
OCL ist eine formale Sprache zur Definition von Einschränkungen auf einem oder mehreren Teilen eines UML-Models.

Klasseninvariante:
Eine Bedingung, die (fast) immer von allen Instanzen einer Klasse
erfüllt werden muss.

Vorbedingung:
Eine Bedingung, die erfüllt sein muss, bevor eine Operation ausgeführt werden kann.

Nachbedingung:
Eine Bedingung, die nach dem Ausführen einer Operation erfüllt sein muss.

Beschränkung von Domänen:
●Beschränkung der Werte, die Attribut annehmen kann.
Dauer nicht länger als 4 Stunden

Beschränkung auf Einmaligkeit:
●Attribut oder Attributmenge einer Klasse für die gilt:
Für zwei unterschiedliche Instanzen dieser Klasse dürfen keine
gleichen Werte zugewiesen werden.
Zwei Studenten dürfen nicht die gleiche Matrikelnummer haben

Zeitliche Beschränkung:
●Bedingungen, die abgeleitete Modellelemente definieren
(z.B abgeleitet Attribute).
Inspektion vor oder nach dem Flug

Regeln für Existenz:
●Bestimmte Objekte / Werte müssen existieren / definiert sein.
●Bevor andere Objekte / Werte definiert / erzeugt werden können
Die Person muss in der Firma angestellt sein um entlassen werden zu können

Modelle, die Modelle beschreiben:
Modelle: Instanzen ihrer Metamodelle.

Definition aller Elemente der Modellierungssprache und ihrer
Beziehungen untereinander.





Beispiel:
Infrastructure definieren Klassen Assoziationen etc.
Superstructure stell sie in Zusammenhang und definiert dann beispielsweise das Klassendiagramm
Das Modell ist das UML-Diagramm für das bestimmte System

Standards in der MDA
Meta Object Facility (MOF):
●Modellbasierte Sprache der OMG zur Definition von Metamodellen.
● importiert in Infrastruktur festgelegte abstrakte Syntax und erweitert sie um Dienste
●Bsp.: Beschreibung der sämtlichen Standards des UML-2.x-Stacks.  ( Gesamtheit der Metamodelle)
*OMG : MetaObject Facility Specification
Unified Modeling Language:
●Mittel Wahl zur Erstellung der Modelle innerhalb MDA.
XML Metadata Interchange (XMI):
●Definiert Abbildung der MOF auf XML.
●Ermöglicht standardisierten Austausch von beliebigen Meta-Modellen
zwischen Tools.
−z.B.: Transformatoren, Modellierungswerkzeugen,
Codegeneratoren usw.
−Grundvoraussetzungen zum Aufbau funktionierenden
MDA-Infrastruktur.

1.Infrastructure
- Verbesserte architekturelle Angleichung
zwischen UML, MOF und XMI.
- Einheitliche, auf Nutzerebene verfügbare
Erweiterungsmechanismen und Profile in
einer zum Metamodellkonsistenten Form.
2. Superstructure
- Direkte Unterstützung von Skalierbarkeit und
Abkapselung für Verhaltensmodellierung.
- Eindeutige Definition der Semantik von
Relationen wie Generalisierung, Abhängigkeit und Assoziation.

UML-Infrastructure (Meta-Meta-Modell)
bildet Basis aller UML-Modelle
(liefert Elemente zur Definition der UML-Diagrammtypen,
Konzepte wie Klasse,Assozation oder Multiplizität eines Attributs beschreiben)

UML-Superstructure(Meta-Modell)
Definiert UML-Diagrammtypen für ein konkretes System
(typisch:Klassen oder Aktivitätsdiagramme)

Modell eines konkreten System
(spezialisiert Layout der Diagramme)

Instanzen eines konkreten Systems
(Klassen: Flug, Passenger ...)

Meta-Metamodell

Metamodell UML

UML-Modell

Object

mit =

Vorzüge
Spezifikation der Softwarekomponente unabhängig von technischer Umsetzung
Verschiedene Abstraktionslevel
(plattformunabhängig, plattformspezifisch)


Übergang von abstrakteren zu technologiespezifischeren Modellen:
-vollautomatisiert ( Transformationswerkzeuge)
-Beschreibung der Transformation ( gesonderte Transformationsbeschreibung)

Ziele
*Wertvolles Wissen über Kerngeschäftsmodelle
*plattformunabhängige Modellierung der unterliegenden Prozesse
(Dokumentation,Evolution der Prozesse, Pflege und Weiterentwicklung Anwendungslogik
-> hilft gegend Degeneration von Dokumentation)

*Portierbarkeit ( systemat. Abstraktion):
Anwendungsentwicklung für mehr als eine Zielplattform

*Systemintegration und Interoperabilität:
Trennung fachlicher Konzepte von konkreter Repräsentation
(erleichtert Bildung von Schnittstellen),
Verwendung offener Standards ( hilft bestehende Anwendung über Technologiezyklen zu retten)
Erleichtert Wiederverwendung und steigert Produktivität

*Effiziente Softwareentwicklung
Automatisierung der Anwendungserstellung (beschelunigt Software-Prozesse)
Technologien werden gekapselt ( ermöglicht optimale und gleichzeitige Nutzung vorhandener Ressourcen)

*Domänenspezifische Modelle und Wiederverwendung von Architekturmetamodelle
Wissensvorsprung innerhalb fachlichen Domänenwissens

*Fachlichkeit innerhalbt Software-Entwicklungszyklus
Kunden: hohe Flexibilität/Agilität
ohne unnötige Beschränkung

Computation Independent Model
(CIM):
●Anforderungen an System und Umwelt.
Beschreibt die Nutzung des Systems, seine
Anforderungen an seine Umgebung, sowie den
Nutzen, den die Umgebung aus diesem System zieht.

Platform Independent Model
(PIM):
●Formale Struktur und Funktionalität eines Systems.
Spezifikation der Struktur und des Verhaltens des
Systems unabhängig von den später zur Implementation
einzusetzenden  Hardware- & Softwareplattformen.

Platform Specific Model
(PSM):
●
PIM mit plattformabhängigen Informationen.
Kann alle Informationen umfassen, die
notwendig sind, um das System zu erzeugen  
und in Betrieb zu nehmen.

Ziel: Generierung von Programmcode aus Modell.
Involviert Generator:
●Generator erzeugt Programmcodefür spezifische Anwendungs- oder Programmklasse.
●Generator kapselt generisches Programmmodell(Klassen von
Programmen).
●Konkret erzeugter Code abhängig von:
−Modell
−Transformationslogik
−Parameter



Codegenerierung Vorteile
●Codegenerierung arbeitet mit variabilisiertem Programmcode.
Programmcode mit Variationspunkten.
●Eindeutige Ausprägung durch Parametrierung des Programmcodes.
●Aufwand der Generatorentwicklung nicht trivial.
●Eignung: Für Lösungen mit entsprechend großer Zahl von Variationen in
Praxis:
− Technische Domänen: Hibernate, EJBs, Spring Beans, …
−Architekturschichten: Persistenzschicht.
−Fachliche Variationen.
Vorteil des Einsatzes:
●Gleichbleibende Qualität über alle Lösungen.
●Zentralisierter Wartungsaufwand.
●Erstellung mehrerer Lösungen in kurzer Zeit.

Problem
UML abstrahiert von jeder fachlichen Domäne
Definition der (Domänen-)Konzepte benötigt
erklärender Text ungeeignet
also:Erweiterung der UML-Notationselemente um fachliche Konzepte: UML unterstützt Anpassung auf Modellebene mit "Profilen"

UML-Profil:
●Spezialisierung von Standard UML-Elementen zu konkreten
Metatypen.
●Profil zu Modell hinzufügbar und im gesamten Modell verfügbar.
●Verschiedene Profile für verschiedene Anwendungsdomänen.
●Einige Profile vordefiniert und bei OMG verfügbar.

Definition eines Profils:
●Paket von Stereotypen und Tagged Values.
●Klassendiagramm definiert Beziehungen zwischen neuem Stereotyp und dem zu beschreibenden Element

●Stereotypen:
spezialisiert Benutzung von Modellelementen <<label>>.
(kann auch durch Symbol visualisiert werden, z.B. für

).

●Tagged value:
fügt Paare zu stereotypisierten Elementen hinzu.
●Werte beschreiben Eigenschaften eines Stereotypen(fachliches Konzept).
●Tagged Values: Name-Wert Paare.
●Einsatz von Tagged Values im Modell:
−Kommentarfeld, das mit Element verbunden ist oder
−Geschweifte Klammern{Name = Wert} direkt in Element
geschrieben.

●Constraint:
verfeinert Semantik eines stereotypisierten Elements.

●Profil:
sammelt obige Informationen.


Grundlegende Konstrukte und ihre Darstellung:
●Datenbank:UML-Komponente mit Stereotyp
●Schema:UML-Paket mit Stereotyp 
●Tabelle:UML-Klasse mit Stereotyp .
●Spalten:Attribute der als markierten Klasse;
mit Stereotyp versehen.
●Primärschlüssel:Attribut markiert mit Stereotyp für
Primärschlüssel und für (zusammengesetzte)
Sekundärschlüssel (beide Stereotype abgeleitet von).
●Fremdschlüssel:Attribut markiert mit Stereotyp

●OMG Standards:
−Model-Driven Architecture (MDA) zur modellgetriebenen
Software-Entwicklung.
−UML und andere OMG-Modellierungsnotationen (z.B. Business Process Model and Notation (BPMN))
●Eclipse Modeling Framework (EMF):
−Spezifische Realisierung der OMG MOF-Konzepte mit Eclipse und Java.
−Integriert im Eclipse Tools Projekt.
●Graphical Editing Framework (GEF):
−Framework zur Darstellung von Modellen.
−Geschieht auf Basis eines EMF-Metamodells oder eigenständig.
●Graphical Modeling Framework (GMF):
−Versuch, EMF und GEF zu integrieren.

●Modellierungsframework und Tool zur Code-Generierung basierend auf strukturiertem Datenmodell.

*Tools und Laufzeitunterstützung
(Javaklassen und Modell erstellen)
*Adapterklassen
(Einfache Sicht und kommandobasiertes Editieren des Modells)
*Grundlegender Editor

●Modelle auf unterschiedlichem Wege erstellbar:
−Aus annotierten Java-Klassen.
−Aus XML-Dokumenten.
−Aus Modellierungstools wie Rational Rose.
−Direkt mithilfe EMF Ecore Baum-Editors.

●Framework: Modelle graphisch darstellen.
●Interaktion mit Modell:
−Verarbeitung von Benutzereingaben durch Maus und Tastatur.
−Interpretation der Eingaben.
−Möglichkeiten Modell zu verändern.
−Änderungen rückgängig machbar (undo/redo).
●Workbench Funktionen:
−Aktionen und Menüs.
−Toolbars.
−Keybindings.
●Plugin von Eclipse.
●Baut auf Model-View-Controller Pattern auf.
●Ziel:Wiederverwendete Funktionalitäten nicht jedesmal neu entwickeln.

MVC

●3 Schichten Modell.
●Strikte Trennung der Schichten
●Daten in Modellschicht.
●Visualisierung der Daten in Viewschicht.
●Kommunikation zwischen 2 Schichten in Controllerschicht

simple Anwendung zur Verarbeitung und Anzeige von Zahlen
als UML-Klassendiagramm.

Realisieren Sie mit Ihrer Modellierung folgende Spezikation:
Es werden reelle Zahlen in einem zweidimensionalem Feld gespeichert.
Eine Möglichkeit, Daten mit Tastatureingaben zu manipulieren, besteht  uber eineTabellendarstellung.
Der Benutzer kann eine Darstellung  öffnen, bei der die Mittelwerte der Zahlen angezeigt werden.
Der Benutzer kann eine Tortendiagramm-Darstellung  öffnen.

Achten Sie bei Ihrer Modellierung besonders auf die Trennung in die funktionalen Einheiten Model, View und Controller und darauf, dass alle für die Realisierung des Patterns nötigen Methoden ebenfalls modelliert sind.


Wichtige Methoden:
Model: notifyListeners()
Controller: getModel():Model
                    notify(view: View)
                   main(args[]:String)
View: update()
           dispose()

Welche Software-Qualitätseigenschaften kennen Sie ?




Prozess- und Produktqualität
●Qualität des Produktionsprozesses beeinflusst Qualität des
entwickelten Produkts.
●Wichtig in Softwareentwicklung, weil einige
Produktqualitätseigenschaften schwer zu beurteilen sind.
●Komplexe Beziehung zwischen Softwareprozess und
Produktqualität:
●Anwendung von individuellen Fähigkeitenund Erfahrungen:
Wichtig in Softwareentwicklung :
●Externe Faktoren(Neuartigkeit der Anwendung oder
beschleunigte Entwicklungszeitpläne) können Produktqualität
beeinträchtigen.

Qualitätsprüfung : Analytische Maßnahmen
●Prüfung der Produkte:
●Statische Prüfung:
●Review
●Statische Analyse
●Formale Programmverifikation
●Model Checking
●Dynamische Prüfung:
●Test
●Simulation
●Prototypen
●Prüfung der Prozesse:
●Audits *
●Prozessbeurteilung

*allgemein Untersuchungsverfahren bezeichnet, die dazu dienen, Prozesse hinsichtlich der Erfüllung von Anforderungen und Richtlinien zu bewerten. Dies erfolgt häufig im Rahmen eines Qualitätsmanagements. Die Audits werden von einem speziell hierfür geschulten Auditor durchgeführt


●Dynamisch
– White-box Testen
– Black-Box Testen
●Statisch
−Software-Metriken

Was bringt Prozessverbesserung?

CMMI
bringt Prozessverbesserung, also Vereinigung an Anforderungen an den Prozess d.h. Einführung von Methoden,Techniken, Entwicklertools ... Anforderungen an Qualitätmanagement
aber auch wie ISO900x : z.B. Mitarbeitertrainings
Wurzeln:
●Systematische Prozessverbesserung(Deming 1986).
●Prozessorientierte Software-Entwicklung (Humphrey 1989).
●Beurteilung des Reifegrads der Prozesse eines
Software-Lieferanten.
●Capability Maturity Model (CMM) (Paulk et al. 1993).
●Modelle als Grundlage und Gerüst für Prozessverbesserung:
●CMM.
●SPICE – Software Process Improvement and Capability
Determination (ISO/IEC 15504).
●CMM spezialisiert für Systeme, Leute, Beschaffung,...
●Entwicklung eines umfassenden, zuschneidbaren Rahmenmodells:
CMMI (Capability Maturity Model Integrated)

●Internationale Sammlung von Standards.
Als Basis des Qualitätsmanagements verwendbar.
(1987 eingeführt)

ISO900x
Anforderungen an Organisation des Qualitätsmanagementsystems:
Dokumentation, Verteilung von Verantwortlichkeiten etc.
(Qualitätshandbuch)


Grundlage ISO 9000:
●ISO 9000 „Qualitätsmanagementsysteme - Grundlagen und
Begriffe“
●Erläutert Grundlagen für Qualitätsmanagementsysteme und in
Normenreihe ISO 900x verwendete Begriffe.
●Erklärt prozessorientierten Ansatz des Qualitätsmanagements.
●Aktuelle Version von 2005 (ISO 9000:2005)



●Kann man mit ISO 9001 Qualität eines Softwareprodukts
zertifizieren ?
●Antwort:
−Nein, ISO 9001-Zertifikat besagt nur, dass Qualitätsmanagement der Firma der ISO 9001 entspricht.



●Legt Mindestanforderungen an Qualitätsmanagementsystem fest, die Organisation erfüllen muss.
●Um Produkte und Dienstleistungen bereitstellen zu können, die
Kundenerwartungen und behördliche Anforderungen erfüllen.
●ISO 9001 wird insbesondere herangezogen, um Softwareprodukte entwerfen, entwickeln und pflegen.
−Beschreibung von allgemeinen Qualitätsmerkmalen und
Qualität von Abläufen.
−Darlegung von organisatorischen und prozeduralen Normen, die
definiert und in einem Qualitätshandbuch niedergeschrieben
werden sollten.

Äußeres Qualitätsmerkmal

Funktionalität
(Angemessenheit,Richtigkeit, Interoperabilität,Ordnungsmäßigkeit(Vorschriften),Sicherheit)
Vorhandensein von Funktionen mit festgelegten Eigenschaften. Diese Funktionen erfüllen die festgelegten oder vorausgesetzten Anforderungen.

Zuverlässigkeit
(Reife, Fehlerzoleranz, Wiederherstellbarkeit)
Merkmale, die sich auf die Fähigkeit der Software beziehen, ihr Leistungsniveau unter festgelegten
Bedingungen über einen festgelegten Zeitraum zu bewahren.


Benutzbarkeit
(Verständlichkeit, Erlernbarkeit, Bedienbarkeit)
Merkmale, die sich auf den zur Benutzung erforderlichen Aufwand beziehen, und auf die individuelle Bewertung einer solchen Benutzung durch eine festgelegte oder vorausgesetzte
Gruppe von Benutzern

Effizienz
(Zeitverhalten, Verbrauchsverhalten)
Merkmale, die sich auf das Verhältnis zwischen dem
Leistungsniveau der Software und dem Umfang der eingesetzten Betriebsmittel unter festgelegten Bedingungen beziehen.

Änderbarkeit
(Analysierbarkeit, Modifizierbarkeit, Stabilität, Testbarkeit)
Merkmale, die sich auf den Aufwand für Durchführung vorgegebener Änderungen beziehen.


Übertragbarkeit
(Anpassbarkeit, Installierbarkeit, Konformität, Austauschbarkeit)
Merkmale, die sich auf die Eignung der Software beziehen,
von einer Umgebung in eine andere übertragen zu werden.

●Nicht alle Qualitätsmerkmale lassen sich gleichzeitig gleich gut
erfüllen.
●Qualitätsplan sollte für zu entwickelnde Software wichtigste
Qualitätsmerkmale herausstellen.
●Prioritäten festlegen:
●In engster Absprache mit Auftraggebern und Anwendern.
●Qualitätsanforderungen: Bestandteil der nicht-funktionalen
Anforderungenim Pflichtenheft.
●Qualitätsplan sollte vorgeben, wie Qualitätsbewertung der
Software ablaufen soll.

Welche zwei grundlegenden Arten von Qualitätsstandards gibt es?

Produktstandards: definieren Charakteristiken, die alle Produkte aufweisen müssen bei Software z.B. ein gemeinsamer Programmierstil.
Prozessstandards: definieren die Durchführung des Softwareprozesses.

Erläutern Sie den Unterschied zwischen verfizierenden, analysierenden und statisch bzw. dynamisch testenden Prüfverfahren.

Verizierende Prüfverfahren
haben zum Ziel durch formal exakte Methoden die Konsistenz zwischen (formaler) Spezikation und Implementierung (im mathematischen Sinne) zu beweisen.
Beispiel: Programmverikation.
Analysierende Prüfverfahren
versuchen  über eine Kenngröße Aussagen  über die Qualität des Produkts oder Prozesses zu treffen.
Beispiel: Softwaremetriken.
Testende Prüfverfahren
versuchen mittels einer Stichprobenartigen Überprüfung des
zu testenden Programms mit einer gewissen Plausibilität von der korrekten Funktionsweise des Programms zu überzeugen. Es verbleibt aber immer ein Rest Unsicherheit. Dabei wird zwischen dynamischen Testverfahren, die den Code zum Testen ausführen, (z.B. kontrollussbezogene
Überdeckungstests) und statischen Testverfahren,( wie bspw. Audits und Reviews), die den Code nicht ausführen.

Was versteht man unter ISO9001 und CMMI? Welche Ziele verfolgen sie?

ISO 9001 ist ein Prozessqualitätsstandard und beschreibt ganz allgemein Modelle zur Darlegung der Qualitätssicherung in Entwicklung, Produktion, Montage und Kundendienst.
1. Dokumentation,Überprüfbarkeit oder Transparenz von bestehenden Qualitätsprozessen

Das Capability Maturity Model Integrated (CMMI) gibt Hilfestellung bei der Bewertung und Verbesserung des Qualitätsmanagements.
2. Bewertung oder Verbesserung des Qualit atsmanagements

Testen misst Qualität
( z.B. anhand Anzahl gefundener Fehlerwirkungen)

erhöht indirekt:

Produktqualität
da Fehler(zustände) vor Auslieferung entdeckt und
korrigiert werden können.

Prozessqualität
da Fehler dokumentiert, analysiert und damit
Fehlhandlungen in Zukunft vermieden werden können.

Vertrauen
in Qualität des Systems, wenn wenige oder keine Fehler
gefunden werden.

Testaufwand vs. hohe Kosten durch Fehler:
25-50% des Entwicklungsaufwands
Testintensität und - umfang in Abhängigkeit vom Risiko und Kritikalität festlegen

Frühzeitiges Prüfen
Fehler(zustände) frühzeitig erkennen und Kosten senken

Erfolgreiches Testen (Nachweis von Fehlerwirkungen) senkt (Gesamt-)Kosten

Testfall:
Eingabewert, Soll-Ergebnis, Vorbedingung, Nachbedingungen
Ausführen: Testfall zeigt Ist-Verhalten

Testorakel bestimmt Soll-Werte für jeden Testfall vor Testdurchführung

Soll-Wert != Ist-Wert ggf. Fehlerwirkung



Welche Möglichkeiten für Testorakel?

Was als Fehler oder Mangel gilt
Fehler:
●Nichterfüllung festgelegter Anforderung.
●Abweichung zwischen Ist-Verhalten und Soll-Verhalten.
Mangel:
●Gestellte Anforderung oder berechtigte Erwartung in Bezug auf beabsichtigten Gebrauch nicht angemessen erfüllt.
●Z.B. Beeinträchtigung der Verwendbarkeit bei gleichzeitiger
Erfüllung der Funktionalität oder Nichterfüllung angemessener
Erwartung.

Ursachenkette für Fehler
●Jeder Fehler oder Mangel: seit Zeitpunkt der Fertigstellung in
Software vorhanden.
Kommt erst bei Ausführung der Software zum Tragen.
●Beschreibung dieses Sachverhalts als Fehlerwirkung(failure).
●Ursache einer Fehlerwirkung: Fehlerzustand(fault) in Software (auch als Defekt, innerer Fehler bezeichnet).
●Ursache eines Fehlerzustands: Fehlhandlung(error) einer
Person.
●Beachte Fehlermaskierung: »Ein Umstand, bei dem ein
Fehlerzustand die Aufdeckung eines anderen verhindert«
[IEEE 610].

Validierung
Prüfung, ob Entwicklungsergebnis individuelle Anforderungen bezüglich einer speziellen beabsichtigten Nutzung erfüllt.
●Haben wir das richtige System realisiert?

Verifizierung
Prüfung, ob Ergebnisse einer Entwicklungsphase Vorgaben der
Phaseneingangs-Dokumente erfüllen.
●Haben wir das System richtig realisiert?

●Prüfung der spezifizierten und vom Testobjekt zu liefernden Ergebnisse und Reaktionen:

Positiv-Test
erwartete Eingaben bzw. erwartete Bedienung ( normal )


●Spezifizierte Behandlung von Ausnahme- und Fehlersituationen
überprüfen:

Negativ-Test
erwartete Fehleingaben bzw. erwartete Fehlbedienung.


●Prüfung der Reaktion des Testobjekts auf ungültige / unerwartete Eingaben / Randbedingungen, für die keine Ausnahmebehandlungen spezifiziert.

Negativ-Test bzw. Robustheittest
unerwartete Fehleingaben bzw. unerwartete Fehlbedienung

Testplanung und Steuerung:
grobe Zeitplanung, Teststeuerung ( messen und analysieren der Resultate, Überwachen / Dokumentieren Testforschritt sowie erreichter Testabeckung und der Ausgangskriterien)

Testanalyse und -entwurf
(●Testbarkeit von Anforderungen und System bewerten
●Review der Testbasis (Anforderungen, Architektur, Entwurf,
Schnittstellen, ...)
●Sicherstellung der Rückverfolgbarkeit zwischen Testbasis und Testfällen in beiden Richtungen....)

Testrealisierung
(●Konkretisierung und Priorisierung der Testfälle.
●Erstellung von Testdaten und Testszenarien.
●Zusammenstellung der Testsuiten.
●Vorbereitung der Testrahmenund Entwicklung von
Skripten zur Testautomatisierung.)

Bewertung von Ausgangskriterien und Bericht
(Abweichung feststellen, aber auch Soll-Ergebnis, Testfallspezifikation etc. kann falsch sein, Überdeckungsgrad,
Testbericht : aus Testprotokoll, Zeit und Kosten ...)

Abschluss der Testaktivitäten
(Kontrolle welche Arbeitsergebnisse abgeliefert,
Dokumentation der Abnahme des Systems, Konservierung der Testware, Verbesserung Testprozess..)

White-Box-Test:Dynamisches Testverfahren, basiert auf Analyse interner Struktur der Testobjekts.

Analysemittel : Kontrollflussgraph

Idee:
●Auswahl der Testdaten: Viele Durchläufe durch Kontrollfluss des
Programms testen; dafür wenig Testfälle gebrauchen.
Varianten, differenzieren nach:
●Art der verwendeten Kontrollflusswege oder -wegstücke.
●Art und Weise der Überdeckung.
●angestrebtem Überdeckungsgrad

Kontrollflussgraph eines Programms P
Gerichteter Graph    G= (N,E)
mit 2 ausgezeichneten Knoten nstart, nfinal
(Anfangs- und Endanweisungen eines Programms)
nur durch start-Knoten betretbar

Knoten stellt Anweisungen / sequenzielle Anweisungsfolgen dar.
●Kante beschreibt möglichen Kontrollfluss zwischen den Anweisungsfolgen ( auch Zweig).
●Maximal bezüglich ersten beiden Eigenschaften.
●Entscheidungsknoten: Knoten mit mindestens 2 Nachfolgeknoten.

Pfad / vollständiger Weg:
●Folge von Knoten und Kanten, die mit Startknoten beginnt und
Endknoten endet.

Wege (T,P):
●Menge vollständiger, endlicher Wege w des Kontrollflussgraphen, für die Testdatum t aus Menge der Testdaten T existiert, das Weg w ausführt.

●Zyklus: Weg im Kontrollflussgraphen mit mindestens zwei Knoten,
der an demselben Knoten beginnt und endet.
●Einfacher Zyklus: Zyklus, bei dem alle Knoten (außer Anfangs- und Endknoten) verschieden sind.



Analyse Pfade des Kontrollflussgraphen und zugehörige Eingaben
Bedingungen  kontrollflussbestimmende Anweisungen  und Aussagen über Programmvariablen berechnen

Achtung: unerreichbare Wegstücke, nicht erreichbare Anzahl Schleifendurchläufe..




Durch kontrollflussbezogenes Verfahren aufdeckbare Fehler:
Berechnungsfehler
Richtiger Kontrollflussweg im Programm ausgeführt aber min. ein berechneter Variablenwert falsch
Bereichsfehler
nicht richtiger Kontrollflussweg im Programm ausgeführt
Eingabebereich Kontrollflussweg stimmt nicht mit Eingabebereich Programm überein
Unterbereichsfehler
spezielle Bereichsfehler, Abfrage fehlt oder es gibt zusätzliche falsche Abfrage

● Anweisungsüberdeckung(statement coverage; C0-Überdeckung;
alle Knoten).
●Entscheidungs-/Zweigüberdeckung(decision coverage;
C1-Überdeckung, alle Zweige).
●Grenze-Inneres-Test(boundary interior coverage).
● Pfadüberdeckung(path coverage; C
∞-Überdeckung, alle Pfade).



Anweisungsüberdeckung : alle Anweisungen

100%ige Anweisungsüberdeckungnicht immer erreichbar
(Ausnahmebedingungen: erheblicher Aufwand während Testphase
oder ""dead code")
schwaches Kriterium
fehlende Anweisungen nicht erkennbar, nicht ausführbare Programmteile werden entdeckt, alle anderen Fehler nur zufällig

Zweigüberdeckung : alleZweige

besser als C0
durchlaufene Programmteile erkennbar(ggf. optimierbar)
unzureichend für Test von Schleifen, nicht ausführbare Knoten und Zweige sicher entdeckt, alle anderen Fehler nur zufällig


mit 100%iger Anweisungsüberdeckung kann keine 100%ige Zweigüberdeckung garantiert werden

umgekehrt schon

Grenze-Inneres-Überdeckung

auf Schleifen beschränktes Kriterium

Pfadüberdeckung

obere Grenzen nicht immer gegeben
Beispiel:
Schleife, in der boolescher Zufallswert generiert wird:
Kann beliebig lange Wert false generieren, bevor true generiert wird.

Warum werden durch 100%-ige Pfadüberdeckung,die ja 100% der
Pfade testet, nicht 100% der Fehler gefunden ?
Antwort:
●Es werden zwar alle Pfade getestet, aber nicht mit allen
möglichen Variablenbelegungen.
●Es wird nur vorhandene Funktionalität getestet und nicht, welche
Funktionalität evtl. fehlt.

Kontroll- und Datenflussanalyse

Suche nach Anomalien im Programmtext.
●Anomalie:Unstimmigkeit, die zur Fehlerwirkung führen kann.
–Anomal: unregelmäßig, regelwidrig.
–Kann Fehlerzustand sein, muss aber nicht.
●Statische Analyse:Nicht alle Fehlerzustände einfach nachweisbar (Fehlerzustände als Fehlerwirkung bei Ausführung).
– Z.B.: bei Division Wert des Divisors in Variable halten
Variable kann zur LaufzeitWert Null annehmen.
Fehlerwirkung, statisch nicht

Einfach aber effektiv:Manuelle Analyse des Kontrollflussgraphen auf Anschaulichkeit.
●Ziel:Abläufe durch Programmstück leicht manuell erfassen.
●Teile des Graphen unübersichtlich
Einfach aber effektiv:Manuelle Analyse des Kontrollflussgraphen
auf Anschaulichkeit.
●
Ziel:Abläufe durch Programmstück leicht manuell erfassen.
●
Teile des Graphen unübersichtlich
Zusammenhänge und Ablauf kaum nachvollziehbar.
Fehlerträchtig (und schlecht wartbar).
Überarbeitung des Programmtextes.

Einfache (oder atomare) Bedingungsüberdeckung ( C2-Überdeckung)

Idee:Zusammengesetzte Bedingungen nur einmal zu True und False auswerten ist nicht ausreichend.
( wie bsp. Zweigüberdeckung)
Teilbedingungen(atomare Prädikatterme) variieren.
Beispiel:
● if A>1 and (B=2 or C>1) and D then ... else …
●Entscheidungsprädikat: A>1 and (B=2 or C>1) and D
●Atomare Prädikatterme: A>1, B=2, C>1, D
Anderes Beispiel:
Vergleich der Zweigüberdeckung von if (a AND b AND c) {...} einer äquivalenten Konstruktion if a {if b {if c {...}}}

Einfache Bedingungsüberdeckung (C2-Test):
●Testdatenmenge T erfüllt C2-Überdeckung g.d.w. es:
−für jede Verzweigung im Programm mit zwei Ausgängen und
−für jeden Prädikatterm pdes zur Verzweigung gehörenden
Booleschen Ausdrucks
−zu jedem Wahrheitswert von p ein Testdatum t aus T gibt.
bei dessen Ausführung p diesen Wahrheitswert annimmt.
●Hinweis: Verzweigungen mit mehr als zwei Ausgängen in
äquivalentes Konstrukt mit zwei Ausgängen umformbar.

●Garantiert keine Zweigüberdeckung.
Testen beider Wahrheitswerte kompletter (zusammengesetzter) Boolescher Ausdrücke nicht garantiert.




Kann es einen C2-Testfall geben, der nicht alle Zweige testet ?


Zweig-/Bedingungsüberdeckung:
Testdatenmenge erfüllt Zweig-/ Bedingungsüberdeckung
gdw. sie  C2-Überdeckung(atomare Bedingungsüberdeckung) und C1-Überdeckung(Zweigüberdeckung) erfüllt.

dadurch werden aber nicht unbedingt alle Zweigkombinationen überdeckt.

Mehrfachbedingungsüberdeckung (C3-Überdeckung)

Testdatenmenge erfüllt Mehrfachbedingungsüberdeckung g.d.w.
●für jede Verzweigung im Programm mit zwei Ausgängen und
●für zur Verzweigung gehörenden Booleschen Ausdruck
●jede mögliche Kombination der Wahrheitswerte atomarer Prädikatterme ausgeführt wird.

Also: für 2 Ausdrücke 4 Testfälle, ,3 Ausdrücke 8 Testfälle ...
()

Kombinationen aller atomarer Prädikate, bei einigermaßen komplizierten Prädikaten nicht mehr handhabbar

Minimale Mehrfachbedingungsüberdeckung
alle bis auf erste testen:
X (A>1)    Y (B=0)     X and Y
false      false            false
false      true              false
true        false            false
true        true              true

alle bis auf letzte testen
X (A=2) Y (C>1)       X or Y
false      false           false
false      true             true
true        false           true
true         true             true

Testdatenmenge erfüllt Minimale Mehrfachbedingungsüberdeckung (C2(mM)-Überdeckung, =minimal bestimmende Mehrfachbedingungsüberdeckung ) g.d.w.:
●für jede Verzweigung im Programm mit zwei Ausgängen und
●für zur Verzweigung gehörenden Booleschen Ausdruck
●folgende Kombinationen der Wahrheitswerte der enthaltenen
atomaren Prädikatterme ausgeführt werden:
−Jede Kombination von Wahrheitswerten, für die Änderung des Wahrheitswertes eines Terms den gesamten Wahrheitswert ändert.

Man nimmt einfach ALLE Terme bei der die Änderung eines Prädikats eine Änderung des gesamten Ergebnisses zufolge hat.


Vgl. früheres Beispiel:
mit Testdaten
A=3 B=0 C=3
A=2 B=1 C=0
A=1 B=0 C=2
alle Zweige geprüft

Kompromiss zwischen C2 und C3
jedes Prädikat (egal ob atomar oder zusammengesetzt) zu True und False ausgewertet
weniger als kombinatorische Abdeckung

●Programmiersprachen und Compiler verkürzen Auswertung von
booleschen Ausdrücken, sobald Ergebnis feststeht.
●Beispiel:
AND-Verknüpfung: eine Teilbedingung »false«
-> Gesamtbedingung: »false« (egal welcher zweite Wert).
●Compiler ändern Reihenfolge der Auswertungin Abhängigkeit von booleschen Operatoren („lazy evaluation“, s. nächste Folie) aus Effizienzgründen.
●Wegen Verkürzung der Auswertung Überdeckung oft nicht
nachweisbar.


Bedingungs-Testverfahren: Anzahl Tests



Anweisungs- und Entscheidungsüberdeckung für objektorientierte Software nicht ausreichend:
●Komplexität objektorientierter Systemen in Beziehungen zwischen Klassen bzw. Interaktionen zwischen Objekten verborgen.
●Methoden in Klassen oft von geringer Komplexität.
Anweisungs- und/oder Zweigüberdeckung leicht erreichbar, aber wenig aussagekräftig (trotzdem notwendig, aber nicht hinreichend).
Datenflussbasiertes Testen (nächster Abschnitt), insbesondere Interprocedural Data Flow Testing

Idee: Testen der Interaktion zwischen Anweisungen, die Wert einer Variablen berechnen (definieren), und Anweisungen, die diesen Variablenwert benutzen (referenzieren).
●Testfälle unter Berücksichtigung der Datenverwendung herleiten.
●Vollständigkeit anhand Datenverwendung beurteilen.

Ziel(wie beim Kontrollflusstesten): Möglichst viele Fehlerfinden, ohne vollständige Pfadüberdeckung ( alle möglichen Pfade in allen möglichen Häufigkeiten ( z.B. bei Schleifen mit oberen Grenzen)) erreichen zu müssen (zu aufwendig).
●Unterscheidung datenflussorientierter Verfahren:
Alle Interaktionen oder nur Teil davon testen.
( Datenflussbasierte Überdeckungsmaße).
●
Definition der Überdeckungsmaße orientiert sich am
Kontrollflussgraphen, erweitert um zusätzliche Informationen.
  Datenflussgraph:


Lokaler Datenfluss:
●Rein lokale Datenflüsse vermeiden (wenn intern Referenz auf
Definition folgt).
finden keine Berücksichtigung bei datenflussbezogenen Testkriterien.
Zwei Arten von lokalem Datenfluss:
●Innerhalb eines Blocks von sequentiell aufeinanderfolgenden
Anweisungen.
●Bei Zuweisung innerhalb einer Bedingung (z.B. in C).

Lösung: auf zwei Knoten aufteilen

und in Entscheidungen :
Zuordnung von bedingten Anweisungen zu Knoten so wählen,dass diese Knoten („Entscheidungsknoten“) nur Referenzen von Variablen enthalten (d.h. DEF(K)=UNDEF(K)={}).
●Beispiel: If ((B=C+D)) aufsplitten in B=C+D und if B.

DR-Weg


Alle DR-Interaktionen
Alle Paare DEF-REF(ohne dazwischenliegendes erneutes DEF)
Kriterium „alle DR-Interaktionen“:
Ziel: Alle Paare von Definitionen / Referenzen einer Variablen testen
Testdatenmenge T erfüllt Kriterium„alle DR-Interaktionen“ g.d.w.
●Für jede Variable x gilt:
Für jede Definition von x und jede Referenz von x, die davon
erreicht wird, muss mindestens ein Weg in
Wege(T) existieren, auf dem die Definition
eine Referenz von x erreicht.


Alle Definitionen ( all-Defs)
Kriterium „alle Definitionen“ (all-Defs):
●Resultat jeder Zuweisung (Definition) wenigstens einmal benutzen („referenzieren“).
●Testfallmenge T erfüllt Kriterium „alle Definitionen“ g.d.w.
−Für jede Variable x und jede Definition von x existiert mindestens
ein Weg in Wege(T), auf dem die Definition eine Referenz von x
erreicht.
Analog zu den kontrollflussbasierten Kriterien: Kriterien an die Menge der Testpfade definieren.



Alle Referenzen
Motivation:Für Referenz einer Variablen im Entscheidungsknoten: Ausgang der Entscheidung wichtig.
Kriterium „alle Referenzen“:
●Ziel: Alle ausgehenden Kanten eines Entscheidungsknotens
berücksichtigen.
Testdatenmenge T erfüllt Kriterium „alle Referenzen“ g.d.w.:
Variable x
Definition von x in Knoten k
Referenz von x in Knoten l ( der von k erreicht wird)
Nachfolgerknoten m von l
Die Wegemenge Wege (T) muss mindestens ein Wegstück
u*m={k,...,l,m} enthalten, wobei die Definition von x in k die Referenz von x in l über Weg u erreicht.

u*m={k,...,l,m} ist Knotenfolge u{k,...,l} vereinigt m


Erklärung Max:
alle referenzen heißt alle DR-Interaktionen + falls die referenz eines DR-Paars in einem entscheidungsknoten auftritt brauchst du zwei pfade für dieses paar: einer sodass nach d. entscheidungskoten in true-richtung und einer sodass d. entscheidungsknoten zu false-richtung weitergelaufen wird

●Einfache Datenflusskriterien wie „Alle DR-Interaktionen“ und
„alle Referenzen“: Kriterien zum Testen aller Paare von
Definitionen und Referenzen.
Jeweils auf einem Weg von Definition zur Referenz.
●Ausreichend unter Gesichtspunkt des Datenflusses.
Zwischen Definition und Referenz findet keine Änderung der Variablen statt.
●Etwas feinkörniger: zwischen Entscheidungs-und
Berechnungs-Referenzen unterscheiden
computational und predicative use

Definition/ Definitional-use
Wertzuweisung,zustandsverändern
z.B. r = m oder r = 5: def(r)

Berechnungs-Referenz/ Computational use
Benutzung in Ausdrücken, zustandserhaltend
z.B. r = m mod n oder r = op1(m,n): c-use(m,n) und def(r)

Entscheidungs-Referenz/ Predicative use
Benutzung in Bedingungen, zustandserhaltend
z.B. while(r!=0) oder if(r!=0): p-use(r)

All-defs: Jede Definition min. einmal ohne dazwischen
liegendes erneutes def in Referenz (c-use oder p-use)
verwenden.[Bem.: Egal ob c-use oder p-use, also konsistent mit Def. auf F. 114.]Gibt es eine Testmenge, die
All-defs erfüllt ?



Erfüllt Pfad (1, 2-3, 4-6, 7, 8, 9-11, 8, 12, 13)
auch Alle DR-Interaktionen[= jedes Paar def/ref
(ohne dazwischen liegendes erneutes def)ausführen] ?



Erfüllt die Pfadmenge von der vorherigen Folie Alle-Referenzen?Reicht schon der einzelne Testfall von davor ?
Was sind jeweils die Nachfolgerknoten ?
(1, 2-3, 4-6, 7, 8, 9-11, 8, 12, 13)



Alle k-DR-Interaktionen
Verkettungen von Definition- Referenz


Kontextüberdeckung

Nicht jede Anomalie führt direkt zu fehlerhaftem Verhalten:
●du-Anomalie: keine direkte Auswirkungen, Programm kann korrekt laufen.
Genauere Untersuchung der anomalen Programmstellen, weitere Unstimmigkeiten ausfindig machen.
Bewertung der Datenfluss-Analyse
Im Beispiel: Anomalien offensichtlich.
Aber: Zwischen Anweisungen, die Anomalie führen, können beliebig viele andere Anweisungen stehen.
●Anomalien nicht mehr offensichtlich.
●Bei manueller Prüfung übersehbar.
●Werkzeug zur Datenflussanalyse deckt Anomalien auf.

Trade-off zwischen Testaufwand und Anteil gefundener Fehler niemals 100%, keine garantierte 100%ige Fehlerfreiheit

Lösung: Verifikationsansätze, die nicht (nur) auf Ausführung des Programmes (= dynamisches Testen) beruhen:
●Statische Analyse: vollautomatisch, aber nur bestimmte
Fehlerklassen
−z.B. Analyse des Kontrollflussgraphen auf Anomalien
●Symbolische Ausführung
●formale Verifikation:
−vollautomatisch (z.B. Modell-Checking): leichtere Bedienung,
eingeschränkte Mächtigkeit
−oder teilautomatisiert (z.B. interaktives Theorembeweisen):
anspruchsvolle Bedienung, prinzipiell (beinahe) uneingeschränkte Mächtigkeit

Werkzeugunterstützung

Testwell CMT Java
Unterstützte Metriken: Zeilenmetriken,
Halstead-Metrik, McCabe Zyklomatische
Komplexität,Wartungsaufwand

Eclipse Metrics Plugin
Unterstützte Metriken: McCabe
Zyklomatische Komplexität.

Ndepend
Unterstützte Metriken:
−Zyklomatische Komplexität
−Schätzung des Entwicklungsaufwands.
−Erkennung von großen Methoden und Klassen.

Sonar Source
Unterstützte Metriken: McCabe
Zyklomatische Komplexität.

Source Monitor
Unterstützte Metriken:
Zyklomatische Komplexität.

●Definition: Menge O von Operationen heisst „generierend“ für Menge X, wenn alle Elemente in X durch sukzessive Anwendung der Operationen erzeugt werden können.
●Bemerkung: Insbesondere kann Menge 0-null-stellige Operationen (= Konstanten) enthalten.

Frage:
- Was ist generierende Menge von Operationen der Booleschen
Algebra ?

Antwort:zum Beispiel {false, not}

- Was ist generierende Menge von Operationen der Algebra der
positiven, ganzen Zahlen ?

Antwort:zum Beispiel {zero, succ}

Abstrakte Datentypen als algebraische Strukturen
formale Spezifikation des Verhaltens von Modulen
Verifikation der Implementieren


Vorgehen
1) Strukturieren der Spezifikation:Alle Schnittstellen eines Systems identifizieren.
Miteinander kommunizierende Teile herausfinden
Notwendige Operationen informell beschreiben.
2) Benennen der Spezifikation:Alle abstrakten Datentypen einer Spezifikation mit Namen
versehen (z.B. Liste) und entscheiden, ob sie generische Parameter benötigen.
3) Auswahl der Operationen:Bezeichnung aller Operationen festlegen.
4) Informelles Spezifizieren der Operation:Identifizierte Operationen sowie deren Auswirkungen auf System beschreiben.
5) Definieren der Syntax:Für jede identifizierte Operation Syntax formal beschreiben.
Alle Operationen zusammen mit ihren Parametern definieren. Syntax gesamter
Spezifikation: Zusammensetzung aller abstrakten Datentypen.
6) Definieren der Semantik:Definition der Semantik der Operationen: Zutreffende Bedingungen
(Axiome) für verschiedene Kombinationen von Operationen beschreiben.

Algebraische Spezifikation eines abstrakten Datentyps besteht aus Syntax- und Semantikteil:
●Syntax:Menge von Vereinbarungen von Zugriffsoperationen:
−Operationsname: Definitionsbereich Wertebereich.
●Semantik:Menge von Gleichungen, die Beziehungen zwischen Eingabe- und Rückgabewerten verschiedener Operationen in Form von Axiomen beschreiben.




Unterscheidung zwischen:

verändernde Operation / inspizierende Operation


Beispiel


Erweiterung der algebraischen
Spezifikation String um Konstanten 'a‘, 'b'
von Typ Char (formal: nullstelligeOperation a: () 'a').

equal (add (s, 'a'), add (s, 'b')) = false?
Lässt sich nicht bestimmen:

Vervollständigung von String durch zusätzliche Operation
equalC : Char, Char Bool
mit den Axiomen:
equalC ('a','a') = true
equalC ('a','b') = false
equalC ('b','a') = false
equalC ('b','b') = true
und der Ersetzung des Axioms
equal (add (s1,c), add (s2,c)) = equal (s1,s2)
durch
equal (add (s1,c1), add (s2,c2)) = equal (s1,s2) ∧equalC (c1,c2)


„Korrekt“ ?=> Die o.g. Gleichungen sind intuitiv korrekt...
… allerdings nur, wenn bestimmte Annahmen an die Intuition erfüllt sind (die im Rahmen von
Schritt 4 des Vorgehens bereits vorab informell spezifiziert worden sein sollten). Zum
Beispiel:
• Das Axiom „append (s1, add(s2,c)) = add (append(s1,s2),c)“ setzt voraus, dass die
intendierten Implementierungen von append(s1,s2) und add (s,c) konsistent bezüglich
der Reihenfolgen von s1 und s2 bzw s und c sein sollen (z.B. append(s1,s2)=[s1::s2] und
add(s,c)=[s::c] oder append(s1,s2)=[s2::s1] und add(s,c)=[c::s], aber nicht append(s1,s2)=[s1::s2]
und add(c,s)=[c::s], wobei [s1::s2] die Konkatenation von s1 gefolgt von s2 ist).
• Das Axiom „isEmpty(add (s,c)) = false“ setzt voraus, dass es kein „leeres“ Zeichen geben
soll.


Vollständig ?   Nein. Zum Beispiel: Die Gleichungen implizieren nicht:    equal(s1,s2) = false (für s1#s2 mit length(s1)=length(s2))
obwohl dies intuitiv gelten sollte.

Anmerkung:  Kommutativität von equal folgt allerdings schon aus den Folien der vorigen Folie
(Beweis per Induktion).

Teil 1: Wichtiges Ziel:Wiederverwendbarkeit von Software-Komponenten.

Frage:Wie können Ansätze, die auf algebraischer Spezifikation basieren, dieses Ziel unterstützen ?

Antwort:
Für gegebene algebraische Spezifikation S einer Software-Komponente kann ich eine Alt-Komponente C wiederverwenden, sofern sie Spezifikation S erfüllt.


Frage:Was tun, wenn Alt-Komponente C gegen (etwas) abweichenden algebraischen Spezifikation S' entwickelt wurde ?

Antwort:
Definiere Abbildung h zwischen algebraischen Spezifikationen S und S',
die wesentlichen gewünschten Eigenschaften
bewahrt (genannt „Homomorphismus“
bzw. „Isomorphismus“)

1. Welcher Aspekt einer Software wird mit einer Spezikation beschrieben?
Die Spezifikation beschreibt das Verhalten des Softwaresystems.

2. Welche Anforderungen gibt es an gute Spezikationsmethoden?
Verständliche und  uberschaubare Spezikationstexte
Präzise und eindeutige Semantik
Abstraktion von irrelevanten Details
Erlernbarkeit
Problem-Angemessenheit

3. Welche positiven und negativen Aspekte hat die Entwicklung einer formalen Spezifikation?
+ Kann zus atzliche Erkenntnisse vermitteln
+ Eindeutigkeit, Chance auf Verizierbarkeit (Vollst andigkeit, Widerspruchsfreiheit, Redundanz)
- Handhabbarkeit und Anwendbarkeit auf Probleme relevanter Komplexit at

4. Welcher Schluss ergibt sich daraus?
=> Formale Spezifikationen sind insbesondere sinnvoll bei Anwendung auf wichtigen und schwierigen Anforderungen (Security, Safety) und besonders kritischen
Systemteilen (Protokolle, Modulschnittstellen). Bei gr osseren 'Projekten' ergibt
sich die Notwendigkeit von Werkzeug-Unterst  utzung.

Funktionaler Test
●Dynamischer Test:
– Herleitung der Testfälle unter Verwendung funktionaler
Spezifikation des Testobjekts.
– Bewertung von Vollständigkeit der Prüfung anhand funktionale Spezifikation.Funktionalität

Untermerkmale der Funktionalität nach ISO 9126:
Angemessenheit, Richtigkeit, Interoperabilität, Sicherheit, Konformität

Äquivalenzklassenbildung
– Repräsentative Eingaben
– Gültige Dateneingaben
– Ungültige Dateneingaben
– Erreichen der gültigen Ausgaben

Grenzwertanalyse
– Wertebereiche
– Wertebereichsgrenzen

Zustandsbasierter Test
– Komplexe (innere) Zustände
und Zustandsübergänge

Entscheidungstabellentest
– Bedingungen und Aktionen

Anwendungsfallbasierter Test
– Szenarien der Systemnutzung

Unterteilung Ein-/Ausgaben in Äquivalenzklassen
= äquivalentes Verhalten

Wenn Wert der Äquivalenklasse Fehler
– aufdeckt. Alle Werte der ÄK sollen diesen Fehler aufdecken.
– nicht aufdeckt. Kein Wert der ÄK soll einen Fehler aufdecken.


Gegeben ist eine Funktion zur Bestimmung der Anzahl der Tage eines Monats mit den Übergaben Monat und Jahr.
●ZahlTageMonat(int Monat, int Jahr)
Wie sehen die Äquivalenzklassen dazu aus ?
Klassen für Monat:
●Gültig:
Monate mit 30 Tagen
Monate mit 31 Tagen
Februar
●Ungültig:
●> 12
●< 1

Klassen für Jahr:
●Gültig:
●Schaltjahre
●Normaljahre



●Testfälle aus Repräsentanten kombinieren und nach »Häufigkeit« sortieren (»Benutzungsprofile«).
–Testfälle in dieser Reihenfolge priorisieren.
–Mit »benutzungsrelevanten« Testfällen testen.
–Testfälle, die Grenzwerte oder Grenzwert-Kombinationen enthalten, bevorzugen.
●Ausführung: Jeder Repräsentant einer Äquivalenzklasse mit jedem Repräsentanten anderer Äquivalenzklassen in einem Testfall.
Paarweise statt vollständiger Kombination.
●Minimalkriterium:Min. ein Repräsentant jeder Äquivalenzklasse in min. einem Testfall.
●Repräsentanten ungültiger Äquivalenzklassen nicht miteinander kombinieren:

Fehlermaskierung:
Eingabebereich
1 <= wert <= 99; farbe IN (rot, gruen, gelb)
Testdaten
wert_uÄK1 und farbe_uÄK1: z.B.wert=0, farbe=schwarz
Fehlerhafte Behandlung von farbe=schwarz bei wert_gÄK1 ggf. unentdeckt (und umgekehrt).



Auswahl von Testfälle: Minimalkriterium:
Alle ÄK‘s durch mindestens einen Testfall abdecken
Dabei pro Testfall:
●Mehrere gültige Äquivalenzklassen- für verschiedene
Beschränkungen - abdecken, oder
●Genau eine ungültige Äquivalenzklasse
Einzelne Prüfung notwendig wegen Fehlermaskierung !


Vorteile:
●Anzahl Testfälle kleiner als bei unsystematischer Fehlersuche.
●Geeignet für Programme mit vielen verschiedenen Ein- und
Ausgabebedingungen.

Nachteile:
●Betrachtet Bedingungen für einzelne Ein- oder Ausgabeparameter.
●Beachtung von Wechselwirkungen und Abhängigkeiten von
Bedingungen sehr aufwändig.

Empfehlung:
●Zur Auswahl wirkungsvoller Testdaten: Kombination der ÄK-Bildung mit fehlerorientierten Verfahren, z.B. Grenzwertanalyse.

●Idee: Grenzbereiche in Verzweigungs- und Schleifenbedingungen,
für die die Bedingung gerade noch zutrifft.
–Testdaten, die solche Grenzwerte prüfen, decken Fehlerwirkungen mit höherer Wahrscheinlichkeit.
●Beste Erfolge bei Kombination mit anderen Verfahren.
●Bei Kombination mit Äquivalenzklassenbildung:
– Grenzen der ÄKtesten.
–Vorkommen jeder »Rand« einer ÄK in einer Testdatenkombination.

Bei vielen Systemen: Einflussdes bisherigen Ablaufs des Systems auf
Berechnung der Ausgaben.

●Endlicher Automat besteht aus endlicher Anzahl von internen
Konfigurationen – Zustände.
●Zustand eines Systems beinhaltet implizit Informationen.
  Ergibt sich aus bisherigen Eingaben.
Nötig um Reaktion des Systems auf folgende Eingaben zu bestimmen.

System: Annahme von unterschiedlichen Zuständen beginnend vom Startzustand.
●Auslösung von Zustandsänderungenoder –übergänge durch
Ereignisse, z.B. Funktionsaufrufe.
●Bei Zustandsänderungen Aktionen durchführbar.
●Spezieller Zustand:Startzustand und Endzustand


Ziele

Nachweis der Konformität des Testobjekts zum Zustandsdiagramm
(Zustands-Konformanztest).

Zusätzlich Test unter nicht-konformanten Benutzungen
(Zustands-Robustheitstest).

Bei Grenzwertanalyse unberücksichtigt:Test von Kombinationen von
Eingabe- bzw. Ausgabewerten.
●Beispiel: Drucken von 20 Seiten, 45 Zeilen auf letzter Seite
●10 Eingabebedingungen mit jeweils 4 zu testenden Werten: 410 = 1.048.576 zu testende Kombinationen!
Beschränkungzu testender Kombinationen durch Ursache- oder Wirkungsgraphen.
Vorgehen beim Ursache-/Wirkungsgraphen:


●Schritt 1:Spezifikation in bearbeitbare Teile zerlegen.

●Schritt 2:Ursachen und Wirkungen des Programms anhand Spezifikation
identifizieren.
●Ursache:Eingabebedingung, denen Boolesche Wahrheitswerte zugeordnet werden können.
●Wirkung:Ausgabebedingung oder Systemtransformation.



● Schritt 4 ff.

• Einschränkung R (requires):Erfüllung von Bedingung a erfordert Erfüllung von Bedingung b.
• Einschränkung M (maskiert):Erfüllung von Bedingung a impliziert Nichterfüllung von Bedingung b.
• Einschränkung IR (irrelevant):Erfüllung von Bedingung a impliziert: Bedingung b irrelevant.

●Schritt 5:
Aus UWG Wertetabelle ableiten mit Ursachen und Wirkungen als Zeilen und Kombinationen von Ursachen als Spalten.

●Schritt 6:
Kombinationen von Ursachen und im fehlerfreien Fall zu erwartende Wirkungen in Wertetabelle eintragen.
Kombinationen für nicht widersprechende verschiedene Ursachen zusammenfassen.

●Schritt 7 :
Für jede Spalte der Wertetabelle Eingabedatum ermitteln.

●Anwendbar bei Systemanforderungen mit
– logischen Bedingungen und
–komplexen, vom System umzusetzende Regeln in
Geschäftsprozessen.
●Spezifikation untersuchen und Eingabebedingungen und Aktionen des Systems ermitteln und festsetzen (»wahr« oder »falsch«).
●Entscheidungstabellee nthält Kombinationen von »wahr« und »falsch« für alle Eingabebedingungen und daraus resultierende Aktionen.
●Jede Spalte der Tabelle: Regel im Geschäftsprozess.
Definiert eindeutige Kombination der Bedingungen.
Zieht Ausführung mit dieser Regel verbundene Aktionen mit sich.
●Bei Entscheidungstabellentest verwendeter Standardüberdeckungsgrad:
Wenigstens ein Testfall pro Spalte.


ET vollständig, wenn bei n Bedingungen alle
Kombinationen enthalten
(Spalten im oberen Teil).
●ET redundanzfrei, wenn verschiedene Bedingungen zu anderen
Aktionen führen.
●ET widerspruchsfrei, wenn logische Beziehungen zwischen
Bedingungen zu konsistenten Aktionen führen

LINKS


RECHTS

(Komponenten Spezifikation <->)Komponententest:
–Erstellte Softwarebausteine nach der Programmierphase einem
systematischen Test unterziehen.
●Unterschiedliche Bezeichnung der Softwareeinheiten:
–Zum Beispiel als Module, Units oder Klassen (objektorientierte
Programmierung).
–Tests werden Modul-, Unit- bzw. Klassentest genannt.
●Von der verwendeten Programmiersprache abstrahiert: Komponente oder Softwarebaustein.
●Test eines einzelnen Softwarebausteins:
Komponententest.

●Isolierte Überprüfung einzelner Softwarebausteine.
  Komponenten externe Einflüsse beim Test ausschließen.
●Deckt der Test eine Fehlerwirkung auf ?
  Zuordnung der Ursache der getesteten Komponente.
●Zu testende Komponente: Aus mehreren Bausteinen
zusammengesetzte Einheit.
●Prüfung von komponenteninternen Aspekten.
●Testbasis:
–Spezifikation der Komponente
– Programmcode
–Alle anderen Dokumentteile, die sich auf die zu testende
Komponente beziehen.

(technischer Systementwurf <-> Integrationstest:
Voraussetzung:
●Übergebene Testobjekte getestet.
●Aufgezeigte Fehlerzustände möglichst korrigiert.
Integration:
●Verbinden von Gruppen dieser Komponenten zu größeren
Teilsystemen durch Tester.
Integrationstest:
●Testen der Funktionalität des Zusammenspiels aller Einzelteile
miteinander.
Ziel:
●Fehlerzustände in Schnittstellen und im Zusammenspiel
zwischen integrierten Komponenten finden




In welcher Reihenfolgesind Einzelkomponente zu integrieren, um
notwendige Testarbeiten einfach und schnell durchzuführen ?
●Softwarekomponenten: Zu unterschiedlichen Zeitpunkten fertig.
Entstehen in verschiedenen Projekten.
●Kein Projektmanager oder Testmanager toleriert, dass seine Tester untätig warten.
Bis Komponenten fertig sind und gemeinsam integriert werden können.



Ad-hoc-Integration:
●Integration der Bausteine in der Reihenfolge ihrer Fertigstellung.
●Nach dem Komponententest wird geprüft, ob die Komponente
–zu einer anderen vorhandenen und getesteten Komponente oder
–zu einem teilintegrierten Subsystem passt.
●Wenn ja: Beide Teile integrieren und Integrationstest
durchführen.
Vorteil:
●Frühe Integration jedes Bausteines in seine passende
Umgebung.  Zeitgewinn
Nachteil:
●Notwendigkeit von Platzhalter und Treiber.

Nicht inkrementelle Integration – big-bang-Integration:
●Nachdem alle Softwarebauteile entwickelt und getestet sind, wird alles auf einmal zusammengeworfen.
● Im schlimmsten Fall: Verzicht auf vorgelagerte Komponententests.
Nachteile:
●Wartezeitbis zum big-bang: Verlorene Testdurchführungszeit.
●Testen leidet unteZeitmangel.
Kein Testtag verschenken.
●Fehlerwirkungentreten geballt auf.
System zum Laufen zu bringen wird schwierig oder unmöglich.
●Lokalisierung und Behebungvon Fehlerzuständen:
Schwierig und zeitraubend.

(funktionaler Systementwurf <-> Systemtest)

Überprüft die Erfüllung der spezifizierten Anforderungen vom Produkt:
●Systemtest betrachtet das System aus der Perspektive des Kunden.
Testobjekte:
●Mit abgeschlossenem Integrationstest liegt das komplett
zusammengebaute Softwaresystem vor.
●Im Systemtest wird dieses System als Ganzes betrachtet.
Testumgebung:
●Der späteren Produktivumgebung nahe kommen.
●Installation der zum Einsatz kommenden Hard- oder
Softwareprodukten in der Testumgebung auf allen
Ebenen (kein Treiber und Platzhalter)

Systemtest-Teststrategie
Nicht-funktionale Anforderung


Probleme
Unklare Kundenanforderungen:
●Keine Anforderungen.
Jedes Systemverhalten zulässig bzw. nicht bewertbar.
●Anwender oder Kunde hat Erwartungvon »seinem« Softwaresystem.
Existenz von Anforderungen!
●Nur »in den Köpfen« einiger am Projekt beteiligten Personen
vorhanden.
Nicht nachlesbar!
●Tester muss alle diese Informationen über das gewünschte
Soll-Verhaltennachträglich zusammentragen.

(Anforderungsdefinition <-> Abnahmetest)

●Bis jetzt:Durchführung der Testarbeiten in Verantwortung des
Herstellers.
●Vor Inbetriebnahme der Software: Abnahmetest.
●Sicht und Urteil des Kunden im Vordergrund.
●Abnahmetest zielt nicht auf das Finden von Fehlerzuständen ab.
Vertrauen in das Produkt gewinnen.
●Abnahmetest:
●Einziger Test an dem der Kunde direktbeteiligt ist.
●Spezielle Form des Systemtests.
●Beim Kunden durchgeführt.

Software-Evolution
beschreibt den Prozess, der folgt, nachdem ein Softwaresystem entwickelt und ausgeliefert wurde. Nach Auslieferung und Benutzung kommen neue Anforderungen dazu und alte Anforderungen verändern sich. Teile des Softwaresystems müssen möglicherweise korrigiert werden, da Fehler auftreten, die zuvor nicht bemerkt wurden. Das System muss an eine neue Plattform adaptiert werden. Die Performance muss verbessert werden und andere nicht-funktionale Anforderungen.