Software Engineering 2 - Klausur HANNA NUR DIESES LERNEN BITTE Flashcards
Was ist ein Milestone?
- Ereignis besonderer Bedeutung (Abnahmen/Zwischenabnahmen/Prüfungen)
- Vorliegen von Zwischenergebnissen
- Entscheidungen weiteren Projektverlauf
Wann ist ein Milestone genau erreicht?
- Definition der Ergebnisse müssen vorliegen
- Ergebnisse erreichen Qualität
- Eine Instanz entscheidet ob Milestone erreicht ist
- Vorgegebene Deadline
Was ist die Idee hinter Git?
-Dezentralisierter Ansatz zur Bearbeitung an gleichen Daten
Wie war gemeinsames Arbeiten an Datensätzen vor Git und SVN nur möglich?
- Lineares Arbeiten an Daten
- Eine Datei wird gesperrt, sobald eine Person daran arbeitet
- Datei wurde verändert und auf den Server comitted
Wie geschieht gemeinsames Arbeiten auf Dateien mit SVN?
- Nicht linear
- Zentralisiert
- Beide holen sich eine Working Version
- Beide editieren gleichzeitig
- Beide commiten
- Merge Conflict muss gelöst werden und richtiges Ergebnis comitted werden
Wie geschieht ein zentralisierter Zugriff/Workflow auf Daten?
- Es gibt ein Repository
- Auf dieses können alle Mitglieder Commiten, mergen, checkouten
- Es gibt Tags, welche Versionsstände kennzeichnen
Wie geschieht ein dezentralisierter Zugriff/Workflow auf Daten?
-Durch Branches auf einem Repository
Wer erfand Git und mit welchen Zielen?
- Von Linus Torvalds entwickelt
- Ziele: Schnelligkeit, Massiv verteilt, einfaches Design und schnelles Branching
- Dezentral!
Welche lokalen Operationen gibt es in Git?
Working Directory | Staging Area | Git Directory(Repo)
|—–commit————
Welche Remote Operationen gibt es in Git?
- push (commits hochladen in Remote Repo)
- clone(herunterladen in lokales Repo)
- pull (bringt die lokalen branches auf den stand der remote branches=
- fetch (updated die remote tracking branches, ohne die lokalen branches zu verändern)
Erkläre folgende Git Commands:
- git init
- git add name.txt
- git commit -m “first hallo”
- git status
- git log
- git tag v1 -edit hallo.txt git checkout master
- git checkout “hallo.txt” -git remote add origin https://gitlab.com
- git push -u origin master
- git pull origin master
- git branch iss53 git checkout iss53 -edit Hallo.txt git commit -a -m “Änderung”
- git checkout master git checkout -b hotfix
- git checkout master git merge hotfix
- git branch -d hotfix
- git checkout iss53 edit Hallot.txt git commit -a -m “feature done”
- git checkout master git merge iss53
- git branch -d iss53 -git clone -edit Hallo.txt
- git fetch origin
- git pull
Erkläre folgende Git Commands:
- git init (Lokale Git Repo erstellen)
- git add name.txt (Datei Stagen)
- git commit -m “first hallo” (Datei auf das lokale Repo schreiben)
- git status (status des Staging Bereiches angeben)
- git log (Log Dateien ausgeben)
- git tag v1 (Letzte Version mit Tags versehen)
- edit hallo.txt git checkout master (Datei verändern und Veränderungen rückgängig machen)
- git checkout “hallo.txt”
- git remote add origin https://gitlab.com (Remote Repo angeben)
- git push -u origin master (Aufs entfernte Repo schreiben)
- git pull origin master (Vom entfernten Repo holen)
- git branch iss53 git checkout iss53 (Developer Branch erzeugen und wechseln)
- edit Hallo.txt git commit -a -m “Änderung” (Datei editieren und comitten)
- git checkout master git checkout -b hotfix (Weiteren Branch eröffnen)
- git checkout master git merge hotfix (Hotfix in master mergen)
- git branch -d hotfix (Hotfix Branch löschen)
- git checkout iss53 edit Hallot.txt git commit -a -m “feature done” (Weiter arbeiten auf issue53)
- git checkout master git merge iss53 (issue 53 mergen)
- git branch -d iss53 (Nach dem mergen den Branch löschen und Issue im Issuesystem)
- git clone -edit Hallo.txt (Lokal auf dem Master arbeiten)
- git fetch origin (Mit anderen Entwicklungen auf dem Remote Master abgleichen)
- git pull (Mit anderen Entwicklungen auf dem Remote Master abgleichen und lokal mergen gitpull = git fetch + git merge)
Erklären Sie Driessens Branching Modell(Git-flow)!
- Master Branch enthält eine stabile Version
- Entwickelt wird auf Developer Branch
- Nur stabile und auslieferbare Entwicklungen werden auf den Master gemerged
- Masterbranch enhält Auslieferungsversionen die mit Tags/Labels versehen worden sind
- Feature Branch wird auf lauffähigen Versionen erzeugt und dort entwickelt
- Nach dem Entwickeln werden die Änderungen der anderen Entwickler gemerged
- Stabile Versionen werden einmal wöchentlich auf den Developer Branch gemerged, gelabelt und ein Regressionstest gemacht
- Qualitätssicherung in der Folgewoche möglich
- Jedes Feature bekommt einen eigenen Feature Branch Ziel: Versionieren einzelner Features und Fehler früh finden durch wöchtenliches integrieren
- Hot fix Branch beinhaltet dringende Fehler zum sofortigen fixxen (Branch geht von Master ab)
- Merge auf Developer und Master (1.2 auf 1.2.1)
- Release Branch wird sehr lange getestet -Entwicklungen gehen für zukünftige Releases parallel im Develope weiter -Fehler im Releasebranch wrden auf den Developerbranch gemerged, damit sie nicht in Zukunft im Release Branch sind
Was ist ein Git-Flow?
- Ein Modell mit Konventionen zum Branchen.
- Git wird an sich nicht erweitert, sondern nur das Vorgehen beim Branchen.
Welche Git-Flows gibt es noch?
- Integration Manager Workflow (Projektbetreiber push alleine in ein blessed Repository)
- Diktator and Leutnant Workflow (Alle Synchronisieren mit dem blessed Repository und pushen zu Leutnants, Leutnants pushen zu Diktator)
Wofür gibt es Git?
- Zum Vermeiden von Chaos bei Zusammenarbeiten in Projekten
- Verfolgen von Änderungen
- Markieren von wichtigen Versionen
- Dezentraler Ansatz
- Driessens Branching Modell (git-flow) als Strategie für Branches
- Workflow für die verteilte Arbeit mit mehreren Repos
Was ist ein Issue-Tracking System?
- Datenbank Software zum Verwalten von Tickets (Fehlerfällen, Änderungen an einem Produkt)
- Erfassung der Fehler
- Zuordnen eines Bearbeiters
- Überwachung der Bearbeitung(Dauer und Stand)
- Statistische Auswertung
Welche Arten von Workflows unterstützt Git?
- Zentralisierten Workflow
- Integration Manager Workflow(distributiert)
- Diktator und Leutnant Workflow(distributiert)
Was ist Continuous Integration?
- Eine der 12 Praktiken des Extreme Programming(Agile)
- Steht für regelmäßige Integration von Code in die Mainline(Master/Developer/Releasebranch)
- Die Mainline sollte fehlerfrei gehalten werden
Was sind die Ziele bei Continuous Integration?
- Fehler schnell finden
- Fehler schnell beheben
- Insgesamt weniger Fehler im System (Denn je mehr Fehler im System, desto schwerer ist das beheben einzelner und Broken-Windows-Theorie)
Was sind die Vorraussetzungen für Continuous Integration an die Technik?
- Ein Versionierungssystem (Git, SVN)
- Automatisierte Builds
- Automatisierte Testdurchführung(Junit)
- Schnelle Builds
Was sind die Vorraussetzungen für Continuous Integration an den Entwicklungsprozess?
- Mainline immer fehlerfrei halten
- Selbsttestenden Code schreiben
- Aufteilung großer Aufgaben (Regelmäßiges Committen, ein mal am Tag)
- Kommunikationsbereitschaft der Entwickler
Wie funktioniert Continuous Integration?
- Laden einer lokalen Kopie des Codes
- Programmieren eines kleinen Features
- Lokales Bauen des Systems und Durchführen der Testfälle für das System
- Update auf die aktuellste Version mit Pull (Zwischenzeitliche Änderungen könnten eingecheckt sein)
- Beheben aller Konflikte und erneutes Durchführen der Testfälle
- Einchecken des integrierten Codes (stage, commit, push)
- Integrationsserver baut Mainline und führt Testfälle durch
- Integrationsserver macht gebautes System zugänglich
- Integrationsserver benachrichtigt Comitter über Erfolg des Builds
Was sind gängige CI-Produkte?
- Gitlab CI (.yml datei enthält die task pipeline)
- Jenkins
- Atlassian Bamboo
- JetBrains TeamCity
Was sind denkbare Probleme bei der Nutzung von Continuous Integration?
- Fehlerfreiheit der Mainline nicht sichergestellt:
- >Lösung: Nicht direkt auf die Mainline comitten, sondern Git-Flow/Branch-Strategien nutzen
- Dezentrale Ansätze wie Git nutzen
- Fehlerhafte Builds zwischencomitten und CI-Server prüft bevor es final comitted wird Build dauert zu lange:
- >Lösung: -Staged Buids (Build Pipeline)
- Projekt sinvoll gliedern (Komponenten)
- Nicht alle Tests immer durchführen
- Performancetests nur ab und zu machen
Wie kann eine BuildPipeline bei Continuous Integration aufgebaut sein?
(Stage 1)
- Inspection (Runs Tools, Complexity, Static code)
- Commit Build (Unit Test Cases, other basic tests)
(Stage 2)
- SecondaryBuild1 (Component Tests, System Test, Functional Tests)
- SecondaryBuild2
(Stage 3)
- Non-Functional Build1 (Long running Perfomance Tests, Non Functional Tests)
- Non-Functional Build2
Was erhält man durch das Nutzen von Continuous Integration?
- Der Integrationsaufwand wird kontrollierbar
- Probleme werden sofort sichtbar und können sofort behoben werden
- Erfordert neben viel Technik auf viel Disziplin
- Auch Deployments/Installations und Aufbau ganzer Testumgebungen automatisiertbar (Continuous Deployment)
Was ist der Zweck von Kanban?
- Entwicklungsflüsse optimieren
- Flaschenhälse im Prozess erkennen und verringern
Prinzipien von Kanban?
- Workflow visualisieren (Auch in Scrum)
- Pull-Prinzip (Aufgaben werden durch Bearbeiter geholt nicht zugeordnet)
- Work in Progress (WIP Limit) beschränkt Anzahl der Dinge im Zustand und lässt Flaschenhälse erkennen
- Cycle time (einer Durchlaufzeit) messen und maximieren, Prozess optimieren, so dass die Durchlaufzeit niedrig und vorhersagbar ist
- Unnötige Lagerzeit in einem Zustand minimieren
- Funktioniert gut bei ähnlich dimensionierten Aufgaben und eingespielten Team
Wodurch definiert man ein gemeinsames Verständnis von Qualität und deren Erreichung?
- Durch Normen
- Durch Best-Practices
Was bedeutet Qualität?
- Liegt im eigenen Ermessen
- Ansprüche ändern sich (persönlich und unternehmerisch)
- Das gemeinsame Verständnis über Qualität legt fest was man erreichen möchte
Beispiel für Kostenentstehung durch das Fehlen von Qualität?
In Analyse(5€):
Bei Adressverwaltung fehlt Adresszusatz Kosten in Analyse
einfügen, beschreiben, neue Version
In Entwurf (50€):
Komponenten, Klassen, Methoden, Persistenz, Prozessschrite Kosten in Implementierung
In Implementierung(500€):
Getestete Module ändern, neu testen, Testspezifikation erweitern, Designidee überdenken, Dokumentation Kosten
In Betrieb(5000€):
Daten neu importien, System entwickeln und parallel weiter betreiben, Temporäre Ersatzlösung(Excel?), Migration
Welche Kostenarten gibt es bei Qualitätsmängeln?
Direkte Kosten:
-Diskussion über Mängel)
Verstecke Kosten:
- Schwer zu erkennen
- Fehlende Nachvollziehbarkeit
- Fehlende Dokumentation
- Schlechte Dateinamen
- Können fast nie einem Verursacher zugeordnet werden, machen aber den Großteil der Gesamtkosten aus
Was sind Indizien für das Fehlen von Qualität?
Stress:
- Keine Zeit
- Überstunden
Unzufriedenheit:
- unrentable Projekte
- unzufriedene Kunden
- Kein Spaß
Unbrauchbarkeit:
- Programm kann etwas nicht
- Messer schneidet nicht Qualität ist ein tiefes menschliches Bedürfnis
Wie lautet ein bekanntes Zitat von Aristoteles über Qualität?
-Qualität kann nicht verordnet werden, sie muss gelebt werden
Wie lautet die Softwarequalität nach DIN ISO 9126?
-Softwarequalität ist DIE GESAMTHEIT DER MERKMALE eines Softwareproduktes, die sich auf dessen Eignung beziehen, festgelegte und vorausgesetzte Erfordernisse zu erfüllen
Wonach können Qualitätsmerkmale bewertet werden?
Nach Boehm:
Produktqualität
- Wartbarkeit (Prüfbarkeit, Änderbarkeit, Portabilität)
- Brauchbarkeit (Zuverlässigkeit, Nützlichkeit, Bedienbarkeit)
Prozessqualität
- außere Prozessqualität
- Planungssicherheit (Termin Einhaltung, Aufwand Einhaltung)
- innere Prozessqualität (Baustein Gewinn, Know-How Gewinn)
Nach ISO/IEC 25010:
- Brauchbarkeit
- Kompatibilität
- Performance
- Zuverlässigkeit
- Sicherheit
- Wartbarkeit
- Portabilität
Wie kann Qualität gemessen werden?
-Durch Qualitäts-Metriken
Was sind Software-Attribute zur Bewertung von Qualität?
- Anzahl der Parameter
- Zyklomatische Komplexität
- Kohäsion und Kopplung
- GUI-Styleguide
- Testabdeckung(Coverage)
Ist die Messung von Zuverlässigkeit bei der Qualität von Software einfach?
- Nein, sehr schwierig
- Merkmale:
1. Korrektheit messen:
- Ist die Korrektheit entscheidbar?
- Formal beweisbar?
- Tests nur Stichproben, vollständige Testabdeckung nicht möglich
2. Ausfallsicherheit messen:
- Hardware Mean Time Between Failures
- Software bei systematischen Fehlern oft eine Katastrophe und kaum Absehbar
Was ist das Softwaremaß Metrik? (Zu messen ist zu wissen)
- Die Metrik ist eine Funktion, um Elemente der Software
- Entwicklung in eine (geordnete) Basismenge abbildet
- Es gibt hunderte verschiedene Metriken für verschiedene Aspekte
Was ist der Schaden und der Nutzen von Metriken? Sollte man sie nutzen?
Was ist der Nutzen?
- Bewerten Qualität von Produkten und Prozessen
- Prognosen zu Kosten, Termin, Qualität machen
Was ist der Schaden?
-Gefahr der Fehlinterpretation/falsche Aussagen
- *Daher?**
- Wenige, aber wichtige Metriken nutzen und abwägen
Was ist bei Nutzung von Metriken wichtig?
-Die konsequente Erhebung und Anwendung
Was sind Anforderungen an Metriken? Was sollen sie an Eigenschaften besitzen?
- Liefern keine Ja/Nein Antwort
- Sondern Informationen
- Entwicklung und Auswahl von Metriken soll Entwicklung möglichst einfach helfen
Wie sieht die ideale Metrik aus?
- Liefert ein exaktes Bild eines Systems, Projektes, Prozesses
- reduziert auf die wichtigen Aspekte
Was sind Beispiele für Metriken?
- Größen (Line of Code)
- Komplexität (McCape-Metrik, Halstead-Metrik, Kopplung der Klasse, beispielsweise Anzahl der verbundenen Klassen oder Anzahl der Operationen)
- Stil (Länge von Bezeichnern, Anteil Kommentar oder Leerzeilen, Jumps)
Was sind Metriken im Controlling?
- Story Points
- Function Points
- Use-Case-Points
Was für Arten von Metriken gibt es?
Objektive Metrik (Einfache Metrik)
- Wie?: Durch das Messen und Zählen
- Pro: exakt, automatisierbar
- Con: Nicht sicher, keine Interpretation
- Beispiel: Körpergröße, Luftdruck, Lines of Code
subjektive Metrik (Qualitätsbewertung)
- Wie?: Beurteilen durch Gutachten
- Pro: Für komplexe Merkmale, plausible Ergebnisse
- Con: Aufwändig, Qualität liegt am Gutachter
- Beispiel: Gesundheitszustand, Wetterlage, Benutzerfreundlichkeit
Pseudometrik (Prognosen, Kostenschätzung)
- Wie?: Berechnen durch Messungen/Beurteilung
- Pro: Aussage über nicht sichtbare Merkmale
- Con: schwer nachvollziehbar -Beispiel: BMI, Produktivität
Was steht hinter der Zyklomatische Komplexität (McCape-Metrik)?
- Die Komplexität der Wartbarkeit eines Programmes sollte gering sein
- Komplexität ist gering wenn es leicht verständlich und prüfbar ist (Wenige If-Else Verzweigungen)
- Aus dem Kontrollflussgraphen eines Moduls ableitbar
Wie lautet die Berechnung der zyklomatischen Komplexität (McCape-Metrik)?
v(G) = e - n + p
für einen Kontrollflussgraphen G mit n Knoten und e Kanten;
p ist die Anzahl der Außenverbindungen
Beispiel: Programm mit einem Ein-Ausgang->p=2
Komplexität ist dann minimal v(G)= 0-1+2 =1
- Lineare Verkettung (Sequenz) hat Komplexität 1
- Jede Verzweigung oder Schleife erhöht die Komplexität um 1
Was ist die WTF-Metrik?
Wie oft beim Code-Review WTF gesagt wird ;)
Was ist das Ziel hinter Maßnahmen zur Qualitätserhebung (Qualitätssicherung QS)?
-Beinhaltetet Tätigkeiten, um Vertrauen zu schaffen, dass eine Dienstleistung/Produkt die Qualität erfüllt
Was ist das Ziel hinter den Maßnahmen der Qualitätsmanagement QM?
-Gesamtführende Aufgabe, welche die Qualitätspolitik, Ziele und Verantwortlichkeiten festlegen
Welche Arten der Qualitätssicherung gibt es?
Konstruktiv (Grade, CI, GIT)
Organisatorisch (Software-Projekt-Management)
Analytisch (Software Prüfung)
- nicht mechanisch (Inspektion, Review)
- mechanisch (Prüfung mit Rechner)
- ausführen (dynamische Prüfung)
- analysieren (Statische Prüfung)
- Regeln prüfen
- Konsistenzprüfung
- quantitative Untersuchung
Was sind Mittel der Organisatorischen und Konstruktiven Qualitätssicherung?
- Verfahren zur Anforderungsanalyse/Dokumentation/Freigabe
- Dokumentenstandard (Lasten- und Pflichtenheft, Architekturbeschreibung, Testfallspezifikation, Protokolle)
- Entwurfsmuster für die Softwarearchitektur
- Codierungsrichtlinien
- Continous Integration
- Vorgehensmodelle
- Schulungen
- Meistensteine und Freigabewesen
- Festlegen von Verantwortlichkeiten
Was kann analysiert werden?
- Coding Style (Einrückung)
- Dumme Fehler (If Logik falsch)
- Antipatterns nutzen (equals nicht auf null checken)
- Schlechte Fehlerbehandlung (Stream nicht schließen)
- Metriken (McCabe)
- Technische Schulden (Leichen im Keller, Legacy, Notlösungen)
Was sind technische Schulden?
-Aufwand für Änderungen an Code/Erweiterungen die schlecht geschrieben sind
Was ist das Tool CheckStyle in der Statische Codeanalyse?
-CheckStyle ist ein Programm das für Java Style prüft und auch MacCabe-Metrik
Was ist das Tool FindBugs und SonarQube der Statische Codeanalyse?
Findbugs
-kann Bugs finden
SonarQube
- Mächtiges Tool für Analysen
- Kann verschiedene Metriken berechnen und Analysen durchführen und Ergebnisse darstellen
- Auch für Gradle als Plugin und viele Sprachen
Was sind Metriken in OpenSource-Projekten?
-Mockito zum Testen mit Mockup Objekten
Was ist beim Testen auf Komplexität bei der Anzahl der Paramater zu beachten?
- Einfaches Programm, welches drei ganzzahlige Parameter bekommt besitzt 2^48 Kombinationen
- Testen würde an die 100 Jahre dauern
->Daher wenig Testfälle, die unterschiedliche Fälle abdecken
Was ist beim Testen auf Komplexität Orientiert an Struktur zu beachten?
- Einfaches Programm, welches aus vier Verzweigungen einer einer umfassenden Schleife besteht.
- 100 Billionen unterschiedliche Abläufe
->Daher möglichst wenig Testfällle, die viel abdecken
Was ist die Motivation hinter dem Testen?
- Testen ist ein wichtiges Werkzeug der Qualitätssicherung QS (Andere Ansätze der QS: Reviews, Statische Analysen, Formale Verifikation)
- Vollständige Testabdeckung ist nicht möglich wg. State Space Explosion Problem (Ziel mit wenig Tests viel abdecken)
- Systematik beim Testen ist wichtig (Prozess, Heuristik, Methodik, Erfahrung)
Was sind Grundsätze des Testens?
- Testen zeigt die ANWESENHEIT von Fehlern (Keine Abwesenheit!)
- Vollständige Tests sind nicht möglich -Mit dem Testen früh beginnen (Spät ist teuer)
- Häufung von Fehlern (Oft nicht gleichmäßig verteilt)
- Zunehmende Testresistenz (Testfälle prüfen, erweitern, modifizieren)
- Testen ist abhängig vom Umfeld (Tests an Einsatzumgebung anpassen und Randbedingungen)
- Kein Fehler weist nicht auf ein brauchbares System hin
Unterschied Statischer vs. Dynamischer Test?
Als Certified Tester spricht man von:
Statischen Tests(Testobjekt wird nicht ausgeführt)
- Untersuchung von Dokumenten
- Code Ausdruck analysieren
Dynamischen Tests (Testobjekt wird ausgeführt)
- Fehler-orientiert (Ziel sie zu finden)
- Komformitäts-orientiert (Testgegenstand verhält sich konform zu seiner Spezifikation; Abnahmetest)
- Auch von Hand
Dynamischer Test Vor/Nachteile?
Vorteile
- Testen ist ein natürliches Prüfverfahren
- Tests sind reproduzierbar
- Investierter Aufwand mehrfach nutzbar
- Zielumgebung wird mitgeprüft
- Systemverhalten wird sichtbar
Nachteile:
- Ergebnisse werden überschätzt (Tests sind Stichproben!)
- Nicht alle Eigenschaften testbar
- Nicht alle Anwendungssituationen nachbildbar
- Test zeigt die Fehlerursache nicht
Was gilt beim Testen allgemein?
-Ein Test muss systematisch sein!
Was ist ein systematischer Test?
- Randbedingungen sind präzise definiert(Programm, Übersetzer, Betriebssystem,Wer,Geräte)
- Eingaben systematisch gewählt (Tastatur, Dateien, DB, Zustände)
- Ergebnisse werden dokumentiert und nach vorher definierten Kriterien beurteilt
Welche Software-Einheiten müssen getestet werden?
- Komponententest/Unit Tests (Testen einer Komponente/Moduls z.B. Klasse)
- Integrationstest (Testen des Zusammenspiels mehrerer Komponenten)
- Systemtest (Testen des Gesamtsystems ohne reale Nachbarsysteme)
- Verbundtest (Testen der Software im Zusammenspiel mit den Nachbarsystemen)
- Abnahmetest (Testen in der realen Einsatzumgebung beim Kunden mit dem Ziel das Projekt abzuschließen)
Was besagt Brian Maricks Testing Quadrant?
- Guide Development (Fehler vor und während Codens verhindern)
- Qritique the Product (Fehler und Fehlende Features schnell finden)
- Business Facing (Für die Anwender)
- Technology Facing (Mehr Team-intern)
TODO ?????
Was für Testfallbestimmungen bzw. Arten davon gibt es?
Black-Box-Test(Funktionstest)
- Betrachtung des Systems ohne Interna zu kennen
- Testfälle auf Basis der Spezifikation der geforderten Eigenschaften
Glass-Box-Test(Strukturtest)
- Betrachtung des Systems mit Wissen über Interna Unterscheidungen
- Anweisungsüberdeckung (Alle Anweisungen wurden ausgeführt)
- Zweigüberdeckung (Alle Vezweigungen wurden durchlaufen)
- Termüberdeckung (Alle Terme die eine Verzweigung steuern wurden (z.B. true/false) ausgeführt
Black-Box-Test
- Auswahl der Testfälle richtet sich nach Eingaben, Ausgaben und funktionellen Verknüpfung
- Kein Wissen über intere Struktur des Testobjektes
- Ziel: Bringt Eingabe X das erwartete Ergebnis Y?
Kriterien für die Auswahl von Testfällen
- Anweisungsüberdeckung(Alle Anweisungen wurden ausgeführt)
- Zweigüberdeckung (Alle Vezweigungen wurden durchlaufen)
- Termüberdeckung (Alle Terme die eine Verzweigung steuern wurden (z.B. true/false) ausgeführt
Black-Box-Test Äquivalenzklassen
- Festlegung von Äquivalenzklassen (Teilbereiche des Wertebereiches die sich bei Fehlern gleich verhalten)
- Auswahl eines Repräsentanten einer Klasse
- Überprüfung auf Vollständigkeit Beispiel:
Ganzzahliger Bereich a<= W <= n
Enumeration {A,B,C}
Wort W: 1. Zeichen = Buchstabe?
Gültiger Wert:
Ganzzahliger Bereich a<= W <= n
W in {A,B,C}
W.1 = Buchstabe
Ungültiger Wert:
W< a W > n
W nicht in {A,B,C}
W.1 ist kein Buchstabe
Herleitung von Testfällen mit Äquivalenzklassen
-Schritte:
1. Ermittel für jede Eingabevariable den zulässigen Wertebereich
2. Verfeinere die Äquivalenzklassen auf Basis der Spezifikation (Gültige Äquivalenzklasse, Ungültige, Vorbedingungen der Funktion)
3. Auswahl von Repräsentanten der Äquivalenzklasse
4. Testfälle definieren für Äquivalenzklassen
5. Bei mehreren Parametern: Kombination aus Äquivalenzklassen
Was ist die Grenzwertanalyse und was sind Grenzwerte?
- >Idee: In Verzweigungs/Schleifenbedingungen gibt es oft Grenzbereiche ab wann eine Bedingung noch zu trifft oder nicht mehr
- >Kombination mit Äquivalenzklassenbildung
- Grenzen der Äquivalenzklassen testen
- Jeder Rand einer Äquivalenzklasse muss in Testdaten vorkommen
Was sind Grenzwerte?
- Werte auf den Grenzen
- Werte links und rechts neben den Grenzen
- Kleinste und größte un/gültige Anzahl
Vorgehensweisen bei Grenzwertanalysen
- >Testdaten identifizieren
- Testdaten direkt auf oder neben den Äquivalenzklassen
- Wertebereich:
- Kleinste und größte un/gültige Werte und die daneben Beispiele: Natürliche Zahlen 1..255 -> 0,1,255,266
Reelle Zahlen -1.0 .. 1.0 (3 Stellen) -> -1.001, -1000, 1000, 1.001 Zeichenkette mit Länge < 10 -> Ketten der Länge 0, 1, 10, 11
Liste mit max. 100 Elementen -> Listen der Länge 0, 1, 100, 101
Was ist die Definition Fehler und Mangel?
Fehler ist die Nichterfüllung einer festgelegten Anforderung
- Abweichung zwischen Ist/Soll Verhalten
- Vorraussetzungen Soll muss in einer Art Spezifikation beschrieben sein
Mangel liegt vor, wenn eine Anforderung nicht angemessen erfüllt wurde
-Programm funktioniert, aber Dialog oder Speicher dauern zu lange, GUI unvollständig
Was ist die Definition von Error, Fault, Failure?
Fehler oder Mangel wird erst bei der Ausführung bzw. beim Test der Software bemerkt
Error: Fehlbehandlung
-Handlung die zu einem Fehlerzustand/Verhalten führt wie Programmierfehler oder fehlerhafte Eingabe
Fault(bug): Fehlerzustand
-Fehlerhafte Zeile, die eine Fehlfunktion auslöst
Failure: Fehlerwirkung
-Ausfall einer Software, Dienste funktionieren nicht mehr
Erkläre Validation und Verifikation
Validation
- Haben wir das RICHTIGE SYSTEM gebaut?
- Prüfung ob die Ergebnisse den Anforderungen einer Nutzung des Systemes entsprechen
Verifikation
- Haben wir das SYSTEM RICHTIG gebaut?
- Prüfung ob die Ergebnisse einer Entwicklungsphase den Vorgaben der Dokumente entspricht
Wie kann sich ein Fehler einer Fehlerart in verschiedene Fehler fortpflanzen?
Grobe Anforderung: ->Beispiel fehlerhafte Anforderung Anforderungsanalyse: Spezifikationsfehler(Fehler aus Anforderung) Entwurf: Entwurfsfehler
Codierung: Fehler aus Codierung
Test und Integration: unbekannter Fehler
Wann ist man mit dem Testen fertig?
- >Frage sollte am Beginn des Projektes durch Teststrategie geklärt sein
- >Die Zeit ist nie um!
- >Metriken helfen, aber gezielt wählen!
- Requirements-Coverage und Requirements -Tracking (Wieviele Anforderungen werden durch die Tests abgedeckt?)
Code-Coverage
- Statement-Coverage (Anteil der Anweisungen die ausgeführt werden)
- Banch-Coverage (Anteil der Verweigungen die durchlaufen werden)
Was ist das Ziel von Black-Box-Tests?
- Möglichst umfassende Prüfung der spezifizierten Funktionalität auf Basis der Anforderung erfassen
- Nur relevante Testfälle testen
- Die Soll-Ergebnisse der Spezifikation sollen gefunden werden
Was für Testfall-Auswahlkriterien gibt es?
- Funktionsüberdeckung (Jede spezifierte Funktion mindestens einmal ausgeführt)
- Eingabeüberdeckung (Jedes Eingabedatum in mindestens einem Testfall verwendet)
- Ausgabeüberdeckung (Jede Ausgabesituation mindestens einmal erzeugt (Masken, Fehlermeldungen)
Was sind Techniken zur Testfallauswahl(Myers)?
Äquivalenzklassenbildung (Äk, Ä-Klassen)
- Repräsentative Menge von Eingabedaten
- Eingaben in Äquivalenzklassen eingeteilt
- Aus jeder Äquiklasse mind. ein Repräsentant getestet
Grenzwertüberprüfung
- Fehler an Grenzen zulässiger Datenbereiche
- Testfälle für Grenzfälle definieren
Äquivalenzklassenbildung
Alle Werte einer Äqzuivalenzklasse zeigen identisches Verhalten
- Alle Funktionen können getestet werden
- Anzahl der Testfälle reduziert sich
Aber Äquivalenz ist hypothetisch
-Klassen werden nach Erfahrung und Intuition gebildet
Zerlegung mit Hilfe von:
- spezifierten Gültigkeitsbereichen
- spezifizierten Sonderbehandlungen
1.-2. Schritte der Testfallableitung mit Äkquivalenzklassenbildung
1. Schritt: Aufstellung von Eingabebedingungen
-Analysieren der Eingabebendingungen anhand Spezifikation mit Vor/Nachbedingung
2. Schritt: Bildung von Äquivalenzklassen
- Zu jeder Eingabebedingung
- Gültige Äquivalenzklassen (Normalfälle)
- ungültige Äquivalenzklassen (Sonderfälle)
2. Schritt weiter: Wertebereich, linear
- Spezifiziert eine Eingabebedingung einen Wertebereich(Bsp: 1 gültige ÄK – 2 ungültige ÄK)
- Bereich 1<= Wert <= 49
gültige ÄK: 1<= Wert <= 49
ungültige ÄK: Wert <1, Wert >49
- Hilfsmittel: Zahlenstrahl
- Schrittweises Vorgehen: Äquivalenzklassen zu einer Bedingung
Die Klassen mit jeder weiteren Bedingung weiter zerlegen
2. Schritt weiter: Datenstruktur (Mengengerüst)
- Wenn untere und obere Schranken angegeben (Bsp: 1 gültige ÄK – 2 ungültige ÄK)
- Beispiel: Eine Liste enthält 1 bis 155 Elemente gültige ÄK: 1 bis 155 Elemente ungültige ÄK 0, > 155 Elemente 2. Schritt weiter: Aufzählung
Werte der Aufzählung gleich behandelt (Bsp: 1 gültige ÄK – 2 ungültige ÄK)
-Beispiel: Aufzählung (rot, gelb, grün)
gültige ÄK: (rot, gelb, grün)
ungültige ÄK: Wert nicht in {rot, gelb, grün}
Werte der Aufzählung nicht gleich behandelt (Bsp: 1 gültige ÄK – 2 ungültige ÄK)
-Beispiel: Aufzählung (rot, gelb, grün)
gültige ÄK: Wert = rot, Wert = gelb, Wert = grün
ungültige ÄK: Wert nicht in {rot, gelb, grün}
-Man sollte die Äquivalenzklasse weite runterteilen bei nicht gleich behandelt
Äquivalenzklassen allgemeiner (Mehrere Parameter und Vorbedingung)
- Äquivalenzklassen bei mehreren Parametern int f (int x, int y)
- wenn x < 0 und y < 0 dann f(x,y) = y
- wenn x = 0 und y > 10 dann f(x,y) = 42
- wenn 0 < x < 10 und y > 100 dann f(x,y) = y * y
- Äquivalenzklassen bei Vorbedingung int f (int x, int y) Vorbedingung: x und y sollen positiv sein
- wenn 0 < x < 10 und y < 100 dann f(x,y) = y * y
- wenn x >= 10 dann f(x,y) = 1
2.-3. Schritte der Testfallableitung mit Äkquivalenzklassenbildung
3. Schritt: Repräsentanten wählen
-Einen Wert aus jeder gültigen und jeder ungültigen Äquivalenzklasse auswählen (Bei mehreren das Kreuzprodukt)
4. Schritt: Testfälle definieren
-Für jede Äquivalenzklasse besteht ein Testfall aus einem Repräsentanten und dem zugehörigen Sollwert nach Spezifikation
Was ist Heuristik zur Minimierung der Tests?
- >Testfälle aus allen Repräsentanten kombinieren und nach Häufigkeit sortieren
- Testfälle Reihenfolge nach Häufigkeiten priorisieren
- Benutzungsrelevante Testfälle testen
- Testfälle mit Grenzwerte oder Grenzwertkombination bevorzugen
- >Paarweise Kombination von Äquivalenzklasse-Repräsentation statt vollständiger Kombination
- >Minimalkriterium: Mindestens ein Repräsentant jeder Äquivalenzklasse in mindestens einem Testfall
- >Repräsentanten ungültiger Äquivalenzklassen nicht mit Repräsentanten anderer ungültiger Äquivalenzklassen kombinieren
Was ist das Test-Ende-Kriterium?
- Test-Ende-Kriterium abhängig von durchgeführten Test der Repräsentanten der jeweiligen Äquivalenzklasse und Gesamtzahl aller Äquivalenzklassen
- Äquivalenzklassen-Überdeckung = (Anzahl getestete Äquivalenzklasse / Gesamtzahl Äquivalenzklassen) * 100% Beispiel: 18 ÄK davon 15 getestet; ÄK-Überdeckung = (15 / 18) * 100% = 83,33%
- Güte der Testfälle abhängig von der Aussagekraft der Spezifikation
- Definition der Testfälle hängt nicht nur von den Eingabebedingungen ab, sondern auch Werte einer Äquivalenzklasse und Kombination ein Eingabebedingungen
Grenzwertanalyse
Idee:
In Verweigungs-/Schleifenbedingung gibt es Grenzbereiche für die eine Bedingung gerade noch zutrifft oder nicht mehr
- >Kombination mit Äquivalenzklassenbildung
- Grenzen der Äquivalenzklasse testen
- Jeder rand einer Äquivalenzklasse muss in Testdatenkombination vorkommen
Grenzwerte
- Werte auf den Grenzen
- Werte rechts und links neben den Grenzen
- Mengenwertige Bereiche (Datenstrukturen)
- Kleinste und größte un/gültige Zahl -Zweitkleinse und Zweitgrößte gültige Zahl
Schritte der Vorgehensweise der Grenzwertanalyse?
1. Schritt: Repräsentanten identifizieren
- Testendaten direkt auf oder neben den Grenzen der Äquivalenzklasse
- Wertebereich:
- gültige Testwerte: gültiger kleinster und größter Wert
- ungültige Testwerte: direkt neben und außerhalb
- Bsp: Natürliche Zahlen 1..255 (0,1,255,256)
- Bsp: Listen maximal 100 Elemente (0,1,100,101)
2. Schritt: Sollwerte identifizieren
-Analog zu Äquivalenzklassentests
Grenzwertanalyse
- >Test-Ende-Kriterium
- Grenzwert-Überdeckung = (Anzahl getestete Grenzwerte / Gesamzahl Grenzwerte) * 100%
- Ist bei richtiger Anwendung mit am effektivsten
- Findet am häufig Fehler
- Kreativität bei Erstellung der Testdaten nötig
Beispiel Grenzwertanalyse
Im Unternehmen Mitarbeiter erhalten ab einer Zugehörigkeit zur Firma von mehr als drei Jahren 50 % des Monatsgehalts als Weihnachtsgratifikation. Mitarbeiter, die länger als fünf Jahre in der Firma tätig sind, erhalten 75 %. Bei einer Firmenzugehörigkeit von mehr als acht Jahren wird eine Gratifikation von 100 % gewährt.
Logischer Testfall 1 2 3 4 5
Firmenzugehörigkeit x 0<=x<=3 38 x<0
Gratifikation in % 0 50 75 100
Gültige Grenzwerte 3 4,5 6,8 9 -1
Ungültige Grenzwerte 4 3,6 5,9 8
Grenzwertanalyse - Tipps
Grenzen des Eingabebereiches
- Bereich [-1.0; +1.0] (Testdaten -1.001; -1.0; +1.0; +1.001)
- Bereich }-1.0;+1.0[ (Testdaten -1.0; -0.999; +0.999; +1.0)
Grenzen der erlaubten Anzahl von Eingabewerten
-Eingabedatei mit 1 bis 365 Sätzen (Testfälle 0,1,365,366)
Grenzen des Ausgabebereiches
-Programm errechnet Beitrag der zwischen 0.00 und 600 EUR liegt (Testdaten 0, 600, <0, >600)
Grenzen der erlaubten Anzahl von Ausgabewerten
-Ausgabe von 1 bis 4 Daten (Testdaten 0, 1, 4, 5)
Geordnete Mengen -Lineare Liste, Tabelle (Testdaten Erstes und letztes Element)
Komplexe Datenstrukturen
-Leere Liste, Null-Matrix (Testdaten leere Menge)
Bei numerischen Berechnungen
-Testdaten eng zusammen und weit auseinander liegende Werte
Testfälle aus Zustandsmodellen
- >Erstellen der Sequenzen für die zu durchlaufenden Pfade durch Breitensuche im Automaten (Konformanztest)
- >Unerlaubte Pfade durch Erweitern jeder Sequenz um jeden zu empfangenden Event (Keine Rückweisung ist unerlaubter Pfad
- Robustheitstests Ziel jeder Zustand mindestens einmal
- jeder Übergang mindestens einmal
- Attribute einer Klasse spannen ebenfalls einen Zustandsraum auf. Testen auf un/erlaubte Übergänge
- Alle Aktionen in einem Automaten mind. einmal ausführen
Testfälle aus Automaten: Zustandsübergangsbaum
- >Zustandsübergangsbaum erstellen:
- Wurzelknoten ist Anfangszustand
- Berechne Knoten als Folgezustände
- Kanten markieren mit Übergangsfunktion/event
- Zweig terminiert wenn Knoten auf dem Weg von der Wurzel schon vorhanden oder zugehöriger Zustand ist Endzustand
- Fehlerzustände sind auch Endzustände
Traversieren von Automaten (Testfälle)
- Überführen eines Automaten in einen Übergangsbaum;
- Alle Zustände müssen erreicht werden und alle Transitionen müssen berücksichtigt werden
- Jeder zusätzliche Zustand lässt die Anzahl der Tests überproportional wachsen
Testfälle aus Übergangsbaum
- Ein Testfall ist definiert durch Anfangszustand, Eingabefolge, erwartete Ausgaben, Endzustand
- Für jeden Zustandsübergang: Vorzustand, auslösendes Ereignis, Reaktion, Folgezustand (Zustandsbestimmung nicht immer offensichtlich!)
- Bei Spezifikation schon Testbarkeit prüfen: -Hohe Anzahl von Zuständen ist problematisch
Tests aus Entscheidungstabelle
- Nicht alles ist Ein/Ausgabe oder Zustandsautomat
- Geschäftsprozesse basieren auf Bedingung und Aktion
- Beim Testen alle Kombination von Bedingungen und Aktionen austesten (jede true/false Bedingung einmal)
Entscheidungstabelle
TF1 TF2 TF3 TF4 TF5
Bedingungen Bankkarte gültig? Nein Ja Ja Ja Ja
PIN korrekt? – Nein Nein Ja Ja
Dritte PIN-Eingabe? – Nein Ja – –
Geld verfügbar? – – – Nein Ja
Aktionen Karte abweisen Ja Nein Nein Nein Nein
PIN erneut anfordern Nein Ja Nein Nein Nein
Karte einbehalten Nein Nein Ja Nein Nein
Geldbetrag erneut anfordern Nein Nein Nein Ja Nein
Geld auszahlen Nein Nein Nein Nein Ja
Was ist das Ziel von White-Box-Test/Glass-Box-Test/Strukturorientierter-Test?
Ziel
- Möglichst umfassende Prüfung der vorhanden Strukturen
- Nur relevante Testfälle
Strukturen als Ausgangssituation
- Strukturen und Abdeckung zur Definition von Testende
- Soll-Ergebnisse in der Spezifikation aber evtl nicht direkt ableitbar
Was ist die White-Box Anweisungsüberdeckung?
- >Testfälle so wählen, dass alle oder eine festgelegte Quote der Anweisung mindestens einmal ausgeführt werden (C0-Maß)
- >Basiert auf Kontrollflussgraph
- Darstellung der Kontrollstruktur einer Komponente als Graph
- gerichtete Kanten als Beschreibung der Reihenfolge
- Knoten sind Anweisungen -Elemente: Sequenz, Verzweigung, Schleifen, Zuweisung
- Testdurchlauf beinhaltet: Nachweis über ausgeführte Anweisungen
- Manchmal reicht ein Testfall
- Test-Ende-Kriterium: Quote 100% empfohlen
Wie kann man die White-Box Anweisungsüberdeckung bewerten?
Ist eher ein schwaches Kriterium muss nicht alle Fälle abdecken
- identifiziert potentiell unerreichbaren Code
- erkennt leere If-Zweige nicht
White-Box- Zweigüberdeckung
- Testfälle so wählen, dass alle Zweige mindestens einmal ausgeführt werden (C1 - Maß)
- Basiert auf Kontrollflussgraphen (s.o): Zweig entspricht Kante
- Bei Bedingungen die Auswertung zu false/true
- alle Case-Fälle
- Schleifen ohne Durchlauf, Durchlauf und Wiederholung
- Unzureichend für Objektorientierung
- Nachweis welche Bedingungen und Anweisungen ausgeführt wurden
- Berücksichtigung von leeren If-Zweigen
- Test-Ende-Kritierium über Quote; empfohlen 100%
Aufgabe: Anweisungsüberdeckung am Beispiel Konkretes Beispiel: Primfaktorberechnung Abstraktes Beispiel 1 IF B1 { B1: x > 0 S11;} S11: x = x -1 ELSE IF B2 { B2: x > -100 S21;} S21: x = 0 ELSE { S31;}; S31: x = 42 S4; S4: println (x) Abstraktes Beispiel 2 IF B1 { B1: x > 0 S11;}; S11: x = x -1 IF B2 { B2: x > -100 S21;} S21: x = 0 ELSE { S31;}; S31: x = 42 S4; S4: println (x) Wieviele Testfälle für 100% Anweisungsüberdeckung
TODO
White-Box: Pfadüberdeckung
- Testfälle so wählen, dass alle Pfade inkl. Schleifen/Wiederholungen ausgeführt werden
- Beinhaltet die Kombination aller Pfade durch jeweilige Basisblöcke des Programms (Abhängigkeiten zwischen Pfaden berücksichtigen)
White-Box: Pfadüberdeckung
- Testfälle so wählen, dass alle Pfade inkl. Schleifen/Wiederholungen ausgeführt werden
- Beinhaltet die Kombination aller Pfade durch jeweilige Basisblöcke des Programms (Abhängigkeiten zwischen Pfaden berücksichtigen)
Aufgabe: Zweigüberdeckung am Beispiel Konkretes Beispiel: Primfaktorberechnung Abstraktes Beispiel 1 IF B1 { B1: x > 0 S11;} S11: x = x -1 ELSE IF B2 { B2: x > -100 S21;} S21: x = 0 ELSE { S31;}; S31: x = 42 S4; S4: println (x) Abstraktes Beispiel 2 IF B1 { B1: x > 0 S11;}; S11: x = x -1 IF B2 { B2: x > -100 S21;} S21: x = 0 ELSE { S31;}; S31: x = 42 S4; S4: println (x) Wieviele Testfälle für 100% Zweigüberdeckung?
TODO
White-Box konkrete Testfälle
- >Frage: Wenn man weiß welche Zweige, Pfade man abdecken will woher kommen die Testfälle?
- Wie legt man Eingabedaten fest?
- Wie legt man Sollverhalten fest?
- >Auswahl von Eingabedaten
- Repräsentation und ihre Kombinationen
- Analog zu Äquivalenzklassen
- Basierend auf Bedingungen und ihren Abhängigkeiten
- >Solltewerte
- Abgeleitet aus übergeordneter Spezifikation
- Auf Basis von Standardanforderungen
White-Box Allgemeine Bewertung(Pro/Con)
- Grundprinzip: Basis ist der Programmtext (Komplexität bestimmt Aufwand) Vorteile:
- Geeignet für untere Testebenen (Komponententest)
- Guter Support durch Werkzeuge für Testfallgenerierung und Testreporting Nachteile:
- Nicht umgesetzte Anteile der Spezifikation werden nicht erkannt
- Instrumentierter Code (um Überdeckung zu messen) verhält sich anders als Code alleine (Zeitmessung)
- >Empfehlung: Minimum Zweigüberdeckung!
Welche anderen Verfahren gibt es neben dem White-/Black-Box-Testing noch?
Blackbox:
- Anwendungsfallbasiertes Testen
- Syntaxtesten -Zufalltesten
Whitebox:
- Bedingungsüberdeckung (If/While konkret analysieren)
- Datenflussbasierte Verfahren Intuitives und erfahrungsbasiertes Testen:
- Error-Guessing
Beispielaufgabe eines Glass-Box-Test procedure BerechneBonus (saldo, sparRate, integer, bonus: in out Integer) is begin if (saldo > 1000) and (sparRate > 100) then bonus := bonus *5; end; if (saldo >5000) or (bonus > 50) then bonus := bonus * 2; end if; end BerechneBonus; Definieren Sie Testfälle für a) Anweisungsüberdeckung b) Zweigüberdeckung
a) Saldo 5001; SparRate 101; Bonus 51
(Jedes If ueber 1 Tests) (1 Testfall!)
b) Saldo 500; SparRate 50; Bonus 9 (If 1)
Saldo 4000; SparRate 150; Bonus 20
Testdurchführung wo im Kanban? Wer führt Komponenten, Integrationstest durch?
- Architektur spezifiziert die Komponententests
- Komponententest wird durch den Entwickler der Komponente durchgeführt (Done nur bei Erfolg)
- Integrationstest bei Abnahme durch Entwickler/Test-Team
Was sind Test-Doubles/Mocks?
- Werden genutzt beim isolierten Testen von Systemteilen (Klassen, Komponenten)
- Abhängige Teile sind oft noch nicht entwickelt
- Erspart parallele Entwicklung
- Trotzdem kann sichergestellt werden, dass ein Teil funktioniert, da man Test Doubles nutzt
Welche Arten von Doubles gibt es?
- Dummys: (Werden nie benutzt, füllen nur Parameterlisten)
- Fake Objects: (Läuffähige implementierung, sehr schlicht gehalten, nie für Produktion)
- Stubs: (Liefern vorgefertigte Ergebnisse für Testaufrufe. Können Infos über Aufruf speichern
- Mocks: (Vorkonfigurierte Objekte mit Spezifikation der erwarteten Aufrufe und deren Ergebnisse
Lässt sich eine stark gekoppelte Architektur einfach mocken?
-Nein, da sie stark gekoppelt ist
Was ist ein Framework zur einfachen Erstellung von Java-Mockup Objekten?
-Mockito
Wie kann man sehen, ob eine Testüberdeckung erreicht ist?
-Durch die Test-Suite Eclemma, als Tool für Testüberdeckungen
Was sind typische Überdeckungswerte beim Testen?
- Gut sind 80-90%
- Unrealistisch 100%
Was ist ein Regressionstest
-Eine selektive Wiederholung bestehender Tests, um zu prüfen, dass Code-Modifikationen keine Effekte auf das System hatte.
Wie können Testfällen beschrieben werden?
Strukturierte Beschreibung von Testfällen (Hier Abnahmetest aus SpezifikationsDokument)
Name TF-31: Änderung der Telefonnummer eines Kunden
Beschreibung Die Telefonnummer eines bestehenden Kunden soll geändert werden.
Voraussetzungen Die Stammdaten für den Kunden „testuser“ existieren. Die bisherige Telefonnummer lautet „0000-0000“.
Eingabe Der Benutzer ändert im Dialog „Profildaten ändern“ die Telefonnummer auf den neuen Wert „1234-5678“.
Ausgabe Das System meldet, dass die Änderung erfolgreich war.
Verifizierung Nach der Änderung werden die Kundendaten erneut ausgelesen und die gelesene Telefonnummer mit dem erwarteten Wert verglichen.
Was ist lautet die Test-Pyramide?
- Unten als breite Basis automatisierte Unit-Tests
- Darüber automatisierte Komponenten, Integrationstests
- Darüber automatisierte GUI Tests
- An der Spitze der Pyramide wenige Tests per Hand
(Viele Dinge sind aber nicht automatisiertbar testbar, wie Benutzerfreundlichkeit oder Funktionen mit Nachbarsystemen)
Was ist das Eistüte Antipattern?
- Eine Darstellung über das Vorgehen im Testing, in der erst viel per Hand getestet wird und danach automatisiert getestet wird
- Dieses Verfahren ist ineffektiv und schlecht
Was sind Begriffe von Nichtmechanischer Prüfung und was bedeuten sie?
Review
- Prüfung eines Dokuments, Zeichnung, Programmes durch Gutachter unter Vorgaben
- Ziel Fehler und Schwächen zeigen
- Positive Merkmale hervorheben
Inspektion
-Systematisches Review Punkt für Punkt auf Stärken und Schwächen
Walktrough
-Ein Review bei dem ein Autor Schritt für Schritt die Funktionsweise beschreibt und Zuhörer nur bei Mängeln einhaken
Was sind Begriffe die bei einem Review genutzt werden?
Prüfling ist ein in sich abgeschlossener für Menschen lesbarer Teil von Software (Dokument, Code, Datenmodul)
Referenzunterlagen (Subjektivität herausnehmen)
-Spezifikation, Richtlinien, Fragenkataloge
Was sind die Rollen bei einem Review?
Manager/PL = (Nimmt nicht am Review teil) ist verantwortlich für Prüfung und Freigabe
Autor = (passive Rolle für Rückfragen) Urheber des Prüflings
Moderator = Leiter des Reviews
Gutachter = Kann Prüfling beurteilen
Protokollant = Protokolliert -Review-Team = Alle Teilnehmer
Wie ist der Ablauf bei einem Review?
- Planung
- 2 Wochen Vorbereitung (Initiierung)
- 2 Stunden Sitzung (Keine Diskussion nur Aufnahme der Mängel)
- 1 Stunde “Dritte Stunde”
- 2 Wochen Nacharbeitung (Danach Freigabe)
- Analyse
Was geschieht beim Review in der Phase Planung?
- Festlegung des Review
- Teams
- Einplanung entsprechender Zeit für Reviews
Was geschieht beim Review in der Phase Initiierung?
- Moderator versorgt Gutachter mit erforderlichen Informationen (Schriftliche Einladung/Einführungssitzung)
- Wichtig (Unabhängige Beurteilung, Jeder Gutachter kann mehr als ein Aspekt haben, jeder Aspekt muss von mind. zwei Gutachtern bearbeitet werden)
Was geschieht beim Review in der Phase Initiierung?
- Moderator versorgt Gutachter mit erforderlichen Informationen (Schriftliche Einladung/Einführungssitzung)
- Wichtig (Unabhängige Beurteilung, Jeder Gutachter kann mehr als ein Aspekt haben, jeder Aspekt muss von mind. zwei Gutachtern bearbeitet werden)
Was geschieht beim Review in der Phase Vorbereitung?
-Gutachter betrachten den Prüfling um Mängelliste zu erstellen(anhandFragenkatalog/Checkliste)
Was geschieht beim Review in der Phase Vorbereitung?
- Gutachter betrachten den Prüfling um Mängelliste zu erstellen(anhandFragenkatalog/Checkliste)
- Moderator muss sicherstellen, dass Gutachter alle Rahmenbedingungen (Zeit, Unterlagen) hat um Aufgabe zu erledigen
- Fragenkataloge (Ja/Nein Fragen auf Grundlage von Erfahrung mit präziser Fragenstellung)
- Verschiedene Typen von Fragenkatalogen für Dokumente/Code (Projekt- und Dokumentenspezifischer Fragenkatalog)
Wie sieht eine Checkliste/Fragenkatalog für ein Review beispielweise aus?
“Sind alle wesentlichen Begriffe in den Anforderungen klar definiert?”
“Kann man für jede Anforderungen zweifelsfrei festellen ob sie im fertigen System erfüllt ist oder nicht?”
Was geschieht beim Review in der Phase Sitzung?
- Nach Regeln geleitet durch Moderator
- Abschnittsweise behandeln des Prüflings durch jeden Gutachter, die über Mängel präzise berichten
- Protokollant protokolliert Befunde
- Autor hat passive Rolle (soll sich nicht verteidigen müssen)
- Moderator will Konsens erreichen
Was geschieht beim Review in der Phase Sitzung?
- Nach Regeln geleitet durch Moderator
- Abschnittsweise behandeln des Prüflings durch jeden Gutachter, die über Mängel präzise berichten
- Protokollant protokolliert Befunde
- Autor hat passive Rolle (soll sich nicht verteidigen müssen)
- Moderator will Konsens erreichen
Was geschieht beim Review in der Phase “Dritte Stunde”?
- Optionale Sitzung mit Kaffee und Kuchen
- Man kann noch über Lösungen diskutieren
- Nacharbeit für Moderator -> Entscheidungen anhand Review-Bericht treffen
- Autor muss evt. Prüfling bearbeiten
- Überarbeiteter Prüfling muss geprüft werden bei kleinen Mängel Kontrolle durch Moderator, ansonsten erneutes Review
Was geschieht beim Review in der Phase “Analyse”?
- Kurzfristiger Nutzen durch Schulung der Mitglieder des Teams
- Langfristiger Nutzen durch systematische Auswertung der Resultate
- Welchen Einfluss haben Parameter?
- Einfluss von früher erkannten Problemen?
- Analyse der Wirksamkeit von Änderungen
Wie sieht ein Timedrift-Diagramm aus bei zögerlicher Prognose?
Wie sieht ein Timedrift-Diagramm aus bei sorgloser Planung oder falscher Prognose?
Intepretiere folgende MTA-Diagramme
Was ist das magische Dreieck des Projektmanagements
- Man kann nicht auf alle Ziele gleich priorisiert eingehen
- Zeit begrenzt, Kosten begrenzt, Qualität nicht umsetzbar
-
Messen der Führungsstille eines Projektleiters und Scoring
Was geschieht in der Angebotsphase der Projektphasen?
- Abstimmung der Zielsetzung des Lastenhefts (Anforderungen, Ausgrenzung, Annahme) /Zentrale User Stories
- Kostenschätzung
- Erstellung eines Angebotes
- Unterteilung in Start, Workshop, Konsolidierung, Ende
- Angebotspräsentation, Fragen, Verhandlung
Projektplanung 3 - Terminplanung
Balkendiagramm (Gantt-Chart):
Was macht es? (1 Punkt)
Was sind die Vor- und Nachteile? (6 Punkte)
Erweiterungsmöglichkeiten des Gantt-Diagramms? (3 Punkte)
Was mach es?:
- Darstellung der Aufgaben und Termine in graphischer Form
Vorteile
- weit verbreitet
- übersichtlich
- einfach
- zeigt Parallelität auf
Nachteile
- Änderungsaufwand groß
- Übersichtlichkeit nur bei grober Granularitärt
Erweiterungmöglichkeiten:
- Zuordnung zu Ressourcen
- Graphische Darstellung des jeweiligen Bearbeitungszustandes
- Aktionen ohne Dauer (Ereignisse: Meilensteine)
Projektplanung 3 - Terminplanung
Nenne eine weitere Darstellungsmöglichkeit für den Terminplan. (Punkt 1)
- Netzplan
Projektplanung 3 - Terminplanung
Kritischer Pfad - Was ist das? (1 Punkt)
Was passiert, wenn sich eine Aktivität auf einem kritischen Pfad verzögert? (2 Punkte)
Kritischer Pfad?
- = Folge von Aktivitäten, zwischen denen kein zeitlicher Puffer existiert
Was passiert, wenn sich eine Aktivität auf einem kritischen Pfad verzögert?
- Hat Auswirkungen auf Gesamtdauer des Projekts
- Kritischer Pfad braucht daher besondere Aufmerksamkeit
Projektplanung 3 - Terminplanung
Wir unterscheiden zwischen internen und externen Meilensteinen. (Definiere beide kurz)
(2 & 1 Punkt)
Externe Meilensteine
- Ergebnisse die aus Auftraggebersicht bedeutend sind
- (Z.B. Vorliegen, Spezifikation, Implementierung, Tests,… ,Fertigstellung einer Iteration in Agilen Projekten)
Interne Meilensteine
- Zwischenkontrollpunkte ohne Kundenbeteiligung
- Und ohne Wissen des Kunden
Projektplanung 3 - Terminplanung
Kriterien für das Erreichen eines Meilensteins (1 Punkt)
Welche Punkte gehören zur Definition eines Meilensteins? (4 Punkte)
Durch was sind Meilensteine meistens festgelegt? (1 Punkt)
Kriterien:
- Kein Raum für Subjektivität und Willkür!
Definition eines Meilensteins:
- Definition der Ergebnisse, die vorliegen müssen
- Die geforderten Qualitätseigenschaften dieser Ergebnisse
- Die Instanz, die entscheidet, ob ein MS erreicht ist
- Der Vorgegebene Zeitpunkt für das Erreichen
MS festgelegt durch Prozessmodelle (Bsp. siehe Bild)
Projektplanung 3 - Terminplanung
Was ist noch bei der Planung zu berücksichtigen?
(2 Punkte)
(Hier wird einer von 3 zu berücksichtigenden Punkten angesprochen das Bild gibt dir einen Tipp welcher)
Was ist noch bei der Planung zu berücksichtigen?
- Logische Abhängigkeiten zwischen Arbeitspaketen
- Arten von Anhängigkeiten
- Ende-Anfang-Beziehung
- Anfang-Anfang-Beziehung
- Ende-Ende-Beziehung
Projektplanung 3 - Terminplanung
Was ist noch bei der Planung zu berücksichtigen?
(1 Punkt)
(Hier wird einer von 3 zu berücksichtigenden Punkten angesprochen das Bild gibt dir einen Tipp welcher)
Was ist noch bei der Planung zu berücksichtigen?:
- Aufwand für die Arbeitspakete
- Automatisiert durch
- “Tool” oder
- “von Hand”
- Automatisiert durch
Projektplanung 4 - Ressourcen
Bei der Terminplanung (1 Punkt)
Bei der Terminplanung:
- Auslastung und Verfügbarkeit von Mitarbeitern und Betriebsmitteln
Projektplanung 4 - Ressourcen
Konfliktfaktoren bei der Ressourceneinteilung
(Du kannst bis zu 16 Punkte nennen, es reichen aber vielleicht 4)
Kategorien im Überblick
“Adressaten der Dokumente”
Wie du weißt, werden Dokumente für verschiedene Adressaten erstellt, die sehr unterschiedliche Information benötigen.
Nenne die 4 vers. Adressaten.
Welchen Zweck hat die Dokumentation für den Kunden? Und Welche Dokumente bekommt er?
Welchen Zweck hat die Dokumentation für den Admin? Und Welche Dokumente bekommt er?
Welchen Zweck hat die Dokumentation für den unerfahrenen Anwender? Und Welche Dokumente bekommt er?
Welchen Zweck hat die Dokumentation für den erfahrenen Anwender? Und Welche Dokumente bekommt er?
Das Wasserfallmodell
Die Probleme des Wasserfallmodells
- Unklare Zielvorstellungen/Anforderungen des Kunden
- Häufige Änderungen Während des Projekts (Change Requests)
- Arbeitsprozesse außerhalb des kurzfristigen Planungshorizontes bergen zu viele Unsicherheiten
- Zu viele abgegrenzte Aktivitäten/Teams (“Teilprodukte über die Mauer werfen”)
- Tests des Produktes am Ende ist viel zu spät
Agiler Ansatz
- Geisteshaltung durch agiles Manifest populär geworden
- Umgesetz durch “agile Methoden”
Beschreibe den Scrumprozess
Nenne die Stationen des Scrumprozess
Beschreibe den Scrum Prozess an dem Folgenden Bild
Weiter gehts, ich hab dich lieb!
Sprint, was ist das?
(Gibt es während eines Sprints Kundeninteraktion)
Ist Iteration in SRCRUM
Hat fixe Längen (2 Wochen, 4 Wochen)
Ergebnis von Sprint soll lauffähige Software sein
Wird Kunden am Sprintende zur Evaluation präsentiert
Während eines Sprints ist keine Kundeninteraktion (Product Owner) erlaubt
- Konsequenz: Features/Anforderungen währen Sprint fixiert
- Keine Störung von “außen”
Artefakt - Sprint Backlog
(Was beinhaltet Sprint Backlog)
Enthält (technischen) Aufgaben die notwendig sind um das Sprint Ziels zu erfüllen
Charakterisierung: “Aufgabe”
- eine nicht länger als 16 Std dauern
- längere in Teilaufgaben zerlegen
- bei Planung Arbeitsgeschwindigkeit (Team) bdenken
- Teams aktualisieren Aufwände während Sprint
- Jedes Teammitglied kann Pakete:
- ergänzen, ändern, löschen
Rollen im Scrum: “Product Owner”
Representiert Endkundenbedürfnisse
- (traditionell machte dies der Prokejt manager)
Für erreichung der wirtschaftl. Ziele verantwortlich
- Steuert diese durch priorisierte Produckt Backlog und den Release Plan
Erstellt Produktkonzept und das Product Backlog
- Dies wird kontinuierlich bearbeitet
- Neue Anforderungen kommen hinzu, werden neu priorisiert
- hochpriorisierte Anforderungen werden in neue verfeinert
- enge Kommunikation mit Kunden
Erstellt/Aktualisiert Releaseplan
⇒ Wichtige Projektmanagementaufgaben führt er also selbst durch!
Rollen im Scrum: “Team”
- Was macht das Team?
Das Team führt die Arbeiten zur Produkterweiterung aus
Team entscheidet selbst, wie viele Anforderungen es im nächsten Sprint in Producktinkrekremente umwandeln kann.
- 5-9 Mitarbeiter
- Team entscheidet über Arbeitschritte/Organisation
- (Entgegen trationellen Management)
Rollen im Scrum: “Scrum Master”
- Was macht der Scrum Master? (4 Punkte)
Ist Coach → hilft Team Scrum richtig einzusetzen
Überwacht einhaltung der Scrum Regeln
Moderiert Meetings
Sollte versuchen sich schnell überflüssig zu machen
Scrum - Aufwandsschätzung mit Product Backlog
- Aufwand ist relativ zu anderen Aufwenden abschätzbar
- Beginn mit klarer u. kleiner Anforderung
- Anhand kleiner Anforderungen große abschätzen
- Gleichgroße Anforderungen gruppieren
- Product Backlog bei Disskursion benutzen
- Schätzungen möglichst realistisch
- genau - ist unmöglich
Scrum - Projektfortschrittverfolgung
- Berichterstattung
- Burndown-Bericht
- Aufwandsschätzung
Berichterstattung in Scrum schafft Transparenz
- Verzögerungen/Fortschritt schnell einsehbar
Burndown-Bericht
- beschreibt aktuellen Projektfortschritt
- führt Summe aller Aufwände im Spring-Backlog auf
- Zeigt Änderungen der Aufwände an
- Führt Summe aller Aufwände im Product Backlog am Ende jedes Sprints auf (zeigt Änderungen über Sprint-Grenzen hinweg auf)
Burndownchart
- Verfolgung der Restaufwände für Gesamtprojekt
Aufwandsschätzung (Product Backlog) in Jira
- Mittels Comulative Flow Diagramm
Scrum - Velocity - Entwicklungsgeschwindigkeit berechnen
- Wie berechnet man die Entwicklungsgeschwindigkeit?
- Punkte verrechnen
Scrum - Daily Scrum / Statusrunde
- “Daily Scrum/Statusrunde/Daily stand up meeting” was ist das?
Statusmeeting des Teams (max. 15 min im Stehen)
Dient Informationsaustausch der Teammitglieder
Jedes Teammitglied beantwortet:
- Welche Arbeitspakete hab ich seit letztem Meetig fertiggestellt
- Welche Arbeitspakete wirst du bis zum nächsten Meetig bearbeiten
- Gibt es behindernde Probleme bei deinen Aufgaben
Hindernisse nimmt der Scrum Master ins Impediment Backlog auf und beseitigt sie
Scrum - Sprint Review
- Sprint Review, was ist das und wer führt es durch?
Sprint Ergebnis wird einem Review unterzogen
- Durch Team und Kunden
- Z.B. Präsentation der laufenden Software
Was wird gemacht?:
- Kunde prüft ob seine Anforderung erfüllt sind
- Eventuelle Änderungen werden im Product Backlog dokumentiert
Scrum - Velocity im Verlauf
“Häuprigkeiten”
Scrum - Sprint Retrospective
- Was wird hiert gemacht?
- Betrachtung der zurückliegenden Sprintphase
- “Was war gut”/ “was hat Verbesserungspotential”?
- Eventuelle Anpassung des Impediment Backlogs
- Eventuelle Anpassung des Product Backlogs
- 15-30 Min
Gib einen Überblick über das Scrum verfahren.
Empfehlung für Scrum-Ablauf
Scrum und XP (- Extreme Programming)
Lean, Agile, Scrum, XP, Kanban,…
Bewertung Agiler Softwareentwicklung (Nach Meyer)
“The Brilliant”
Bewertung Agiler Softwareentwicklung (Nach Meyer)
“The Good”
Anmerkung: Immer auch die anderen “alten” Tests durchführen
Bewertung Agiler Softwareentwicklung (Nach Meyer)
“The Ugly”
- Ablehnung traditioneller Projektleitungsaufgaben
- Geht für meisten Teams nicht
- Niemand will “Hilfs- Projektleiter sein”
- Ablehnung von Hilfs-/Zwischenprodukten/ nicht auslieferbaren Produktteilen
- Ablehnunf von Softwarearchitekturen
- Ablehnung von Wiederverwendbarkeit als Entwicklungsziel
- Kunde im Team
- (In Praxis Kunde schwierig) (Product-Owner gut)
