Software-Engineering 2. Software-Engineering 2. Softwarequalität und Softwaretest. IT works. Klaus Mairon
|
|
- Anke Kirchner
- vor 8 Jahren
- Abrufe
Transkript
1 Software-Engineering 2 Softwarequalität und Softwaretest IT works. Klaus Mairon
2 Agenda Grundlagen des Softwaretestens Motivation Wichtige Begriffe Psychologie und Prinzipien des Testens Testprozess Testen im Software-Lebenszyklus Allgemeines V-Modell Teststufen Testarten Dynamischer Softwaretest Blackbox-Verfahren Whitebox-Verfahren Klaus Mairon
3 Folgen von Programmierfehlern 1962 führte ein fehlender Bindestrich in einem Fortran-Programm zum Verlust der Venus-Sonde Mariner verpasste die NASA-Sonde Mars Climate Orbiter den Landeanflug auf den Mars, weil die Programmierer das falsche Maßsystem verwendeten Pfund x Sekunde statt Newton x Sekunde. Die NASA verlor dadurch die Sonde. Zum Jahreswechsel 1999 / 2000 kam es in vielen Programmen zum Jahr-2000 Problem. (Jahreszahl zweistellig: 1900 oder 2000 nicht mehr eindeutig) Auch in unserer Software gibt es Fehler: Teamtrack-Meldungen bei der Metris: 3319 im Projekt SKS, 2483 im Projekt MPSS... Klaus Mairon
4 Wozu überhaupt Softwaretests durchführen? Wäre es nicht viel einfacher und billiger, bei der Softwareentwicklung Fehler zu vermeiden? Es gibt doch eine gründliche Analyse- und Designphase im Projekt. Man muss sauber und nach Spezifikation entwickeln, dann macht man kaum Fehler. Und wenn es doch Fehler gibt, findet die der Entwickler doch selber viel schneller. Klaus Mairon
5 Wichtige Begriffe Testen = Der Prozess, bestehend aus allen Aktivitäten des Lebenszyklus, der sich sowohl statisch als auch dynamisch, mit der Planung, Vorbereitung und Bewertung eines Software-Produkts und in Beziehung stehender Arbeitsergebnisse befasst, um sicherzustellen, dass sie die festgelegten Anforderungen erfüllt, zu zeigen, dass sie ihren Zweck erfüllt, um Fehler zu finden. Klaus Mairon
6 Wichtige Begriffe Debuggen oder Testen? Debugging ist konstruktiv Fehlerursache lokalisieren Fehlerursache analysieren Fehlerursache entfernen Funktion im Laufversuch überprüfen Testen ist destruktiv Fehlverhalten provozieren Fehlverhalten reproduzieren Fehler lokalisieren Fehler dokumentieren Testen ist aber konstruktiv für das Management von Produktrisiken! Klaus Mairon
7 Wichtige Begriffe Fehler (engl. Bug) = die Nichterfüllung einer festgelegten Anforderung. Eine Abweichung zwischen dem Istverhalten und dem Sollverhalten laut Spezifikation oder Anforderung. Oberbegriff für: Fehlhandlung, (engl. error, mistake) Fehlerzustand (engl. Fault, bug) Fehlerwirkung (engl. failure) Klaus Mairon
8 Wichtige Begriffe Mangel (engl. defect) = die Nichterfüllung einer festgelegten Anforderung in Bezug auf einen beabsichtigten oder festgelegten Gebrauch. Ein Mangel liegt vor, wenn eine gestellte Anforderung oder berechtigte Erwartung nicht angemessen erfüllt wird. Klaus Mairon
9 Wichtige Begriffe Fehlermaskierung (engl. defect masking) = Ein Umstand bei der ein Fehlerzustand die Aufdeckung eines anderen Fehlzustands verhindert. Ein vorhandener Fehlerzustand wird durch einen oder mehrere andere Fehlerzustände in anderen Teilen des Testobjekts kompensiert, sodass dieser Fehlerzustand keine Fehlerwirkung hervorruft. Klaus Mairon
10 Wichtige Begriffe Softwarequalität = Die Gesamtheit der Merkmale und Merkmalswerte eines Softwareprodukts, die sich auf dessen Eignung beziehen, festgelegte oder vorausgesetzte Erfordernisse zu erfüllen. Merkmale sind: Funktionalität, aber auch Zuverlässigkeit Benutzbarkeit Effizienz Änderbarkeit (auch Wartbarkeit) Übertragbarkeit (auch Portabilität) Klaus Mairon
11 Psychologie des Testens Menschen machen Fehler, aber sie geben es nur ungern zu. Der Bote schlechter Nachrichten sollte... Entwicklertest? Kontruktives + destruktives Denken ist fast unmöglich. Blindheit gegenüber eigenen Fehlern. Vorteil: keine Einarbeitung Unabhängiges Testteam Schärfere Tests, anderes Hintergrundwissen und Unvoreingenommenheit findet andere Fehler. Beurteilung der Qualität kann zu Vertrauen in die Software führen. Liefert Informationen für Entscheidungen, z.b. die Empfehlung für oder gegen eine Auslieferung der Software. Klaus Mairon
12 Prinzipien des Softwaretestens 1) Testen zeigt die Anwesenheit von Fehlern. 2) Vollständiges Testen ist nicht möglich. 3) Mit dem Testen frühzeitig beginnen. 4) Häufung von Fehlern. 5) Zunehmende Testresistenz. 6) Testen ist abhängig vom Umfeld. 7) Trugschluss: Keine Fehler zu finden bedeutet ein brauchbares System zu haben. Klaus Mairon
13 Fundamentaler Testprozess Beginn Planung und Steuerung Analyse und Design Realisierung & Durchführung Auswertung und Bericht Abschluss Testkonzept, Teststrategie, Testziele, Überwachen der Testergebnisse, Risiken Logische Testfälle, Infrastruktur, Werkzeuge Konkrete Testfälle, Szenarien, Testdaten, Orakel für Sollwerte, Fehlermeldungen und Nachtest Testende, Bericht an Entscheidungsträger Reflektion, Archivieren von Testmitteln und Testumgebung Ende Klaus Mairon
14 Agenda Grundlagen des Softwaretestens Motivation Wichtige Begriffe Psychologie und Prinzipien des Testens Testprozess Testen im Software-Lebenszyklus Allgemeines V-Modell Teststufen Testarten Dynamischer Softwaretest Blackbox-Verfahren Whitebox-Verfahren Klaus Mairon
15 Allgemeines V-Modell Abnahmetest Funktionaler Systementwurf Systemtest Technischer Systementwurf Integrationstest Anforderungsdefinition Komponentenspezifikation Komponententest Implementierung Klaus Mairon
16 Komponententest Schwerpunkt: Funktionaler Test, Robustheit (ungültige Werte), Performanz Vorbedingungen Fertig übersetztes Testobjekt Testbett/Testumgebung (Testtreiber, Stubs,...), Entwicklungswerkzeuge Spezifikation zum Testobjekt Typische Techniken Whitebox (Code-Abdeckung) Blackbox (Äquivalenzklassen, Grenzwertanalyse...) Gefundene Fehler Funktionale Fehler innerhalb der Komponente Laufzeitfehler, (lokale) Performanz-Probleme, Robustheit Nicht gefundene Fehler Schnittstellenprobleme Probleme im Gesamtbild, viele nicht-funktionale Fehler Klaus Mairon
17 Integrationstest Schwerpunkt: Schnittstellen, Funktionalität über mehrere Module Vorbedingungen Erfolgreich integriertes SUT (System Under Test) Testbett/Testumgebung Dokumentation über Zusammenspiel der Komponenten Typische Techniken Whitebox (interne Schnittstellen) Blackbox (z.b. Äquivalenzklassen) Gefundene Fehler Fehler in Schnittstellen, fehlerhafte Interaktionen zwischen Komponenten Nicht gefundene Fehler Probleme außerhalb der betroffenen Komponenten Anforderungen an das Gesamtsystem ggf. nicht erfüllt, Schnittstellen externer Systeme werden oft nicht berücksichtigt Klaus Mairon
18 Systemtest Schwerpunkt: Systemanforderungen, Funktionalität des Gesamtsystems, nicht-funktionale Anforderungen Vorbedingungen Vorangegangene Teststufen erfolgreich abgeschlossen vollständig integriertes System, Dokumentation bezüglich Systemanforderungen Typische Techniken Funktionaler und nicht-funktionaler Test Blackbox-Techniken Gefundene Fehler Funktionale und nicht-funktionale Fehler, konzeptionelle Fehler Probleme des Gesamtsystems Nicht gefundene Fehler Missverständnisse bezüglich der User-Anforderungen, unzureichende oder fehlende Umsetzung impliziter Anforderungen Klaus Mairon
19 Abnahmetest Test unter Beteiligung der Anwender des Systems und auch ggf. anderer Stakeholder Test gegen die expliziten Anforderungen und impliziten Erwartungen des Auftraggebers, die dem allgemeinen Stand der Technik entsprechen Systemtest aus Sicht des Auftraggebers Ziel: Vertrauen in das System, Teilsystem oder z.b. in nicht-funktionale Eigenschaften des Systems gewinnen. Das Finden von Fehlern ist nicht Hauptziel des Abnahmetests. Nicht notwendigerweise die letzte Teststufe: Wenn System Teil eines größeren Gesamtsystems ist, kann ein umfangreicher Systemintegrationstest folgen Auch die Durchführung von Teil-Abnahmetests in niedrigeren Teststufen kann sinnvoll sein Klaus Mairon
20 Teststufen und Testfokus: Idealbild und Realität Idealbild Realität Abnahmetest Systemtest Integrationstest Komponententest Implementierung Interne Funktionalität Sicherheit Externe Funktionalität Robustheit Effizienz Debugging Benutzerakzeptanz Klaus Mairon
21 Testarten Definition: Eine Testart ist eine Gruppe von Testaktivitäten, die gemeinsam ausgeführt und verwaltet werden, mit dem Ziel der Überprüfung einer Komponente und eines Systems auf einige zusammenhängende Qualitätsmerkmale. Eine Testart kann sich auf bestimmte Testziele beziehen, wie z.b. Zuverlässigkeitstest, Regressionstest, Benutzbarkeitstest Die Testart kann sich auch auf eine oder mehrere Teststufen beziehen. Die vier Testarten (Synonym: Testtypen) Funktionaler Software-Test (z.b. Selbstbehaltberechnung bei einer Versicherung) Nicht-funktionaler Software-Test (z.b. Lasttest) Struktureller Software-Test (z.b. Zweigüberdeckung) Änderungsbezogener Software-Test (z.b. Regressionstest) Klaus Mairon
22 Empfehlungen Teststufen müssen je nach Projekt oder Systemarchitektur unterschiedlich gebildet, miteinander kombiniert oder neu organisiert werden. Testaktivitäten sollten nicht am Ende sondern parallel zum Software-Entwicklungsprozess durchgeführt werden. Testentwurf (Analyse & Design) für eine Teststufe sollte bereits während der korrespondierenden Entwicklungsstufe beginnen. Tipp Tester sollten frühzeitig an Reviews von Entwicklungsdokumenten beteiligt werden, sobald Entwürfe vorhanden sind. Entwickler sollten bei Reviews von Testfällen beteiligt sein, um Hinweise für weitere Tests geben zu können. Klaus Mairon
23 Zusammenfassung Tests müssen destruktiv sein und systematisch durchgeführt werden, um wirksam und effizient zu sein Frühes Testen senkt Kosten Tests können helfen, die Qualität von Software zu beurteilen sowie Vertrauen in eine Software zu gewinnen Design for Testability : Berücksichtigung der Testbarkeit bei Design & Architektur der Anwendung Testen ist eine zentrale, wiederkehrende Aktivität über die gesamte Projektdauer Tests werden nach dem allgemeinen V-Modell auf 4 Teststufen durchgeführt, die sich auf spezifische Testziele/Testthemen konzentrieren. Teststufen sind dabei korrespondierenden Entwicklungsstufen zugeordnet Klaus Mairon
24 Agenda Grundlagen des Softwaretestens Motivation Wichtige Begriffe Psychologie und Prinzipien des Testens Testprozess Testen im Software-Lebenszyklus Allgemeines V-Modell Teststufen Testarten Dynamischer Softwaretest Blackbox-Verfahren Whitebox-Verfahren Klaus Mairon
25 Statischer Test vs. Dynamischer Test Statischer Test = Test ohne Ausführung Die Ergebnisse des Softwareentwicklungsprozesses werden ge review ed (Quellcode, Konzepte, Spezifikationen,...) statisch analysiert (Quellcode, ausführbare Modelle,...) Einhaltung von Programmierrichtlinien und Standards Kontrollflussanalyse (z.b. Aufrufhierarchie, toter Code) Datenflussanalyse (z.b. Referenzierung uninitialisierter Variablen) Komplexitätsanalyse (z.b. Zyklomatische Komplexität nach McCabe) Finden von Fehlerzuständen (Innerer Fehler, z.b. Radmutter sitzt locker) Grundidee: Prävention, d.h. Fehler so früh wie möglich finden, bevor es im weiteren Entwicklungsverlauf zu aufwändigen Nach- und Verbesserungen kommt! Klaus Mairon
26 Statischer Test vs. Dynamischer Test Dynamischer Test = Test mit Ausführung Die Ergebnisse des Softwareentwicklungsprozesses werden ausgeführt und ihre Funktionalitäten gegen ihre Spezifikationen geprüft. Finden von Fehlerwirkungen (Äußerer Fehler, z.b. Rad geht ab) Ziel: Nachweis der Erfüllung der festgelegten Anforderungen und Aufdeckung von eventuellen Abweichungen und Fehlerwirkungen. Systematische Erstellung von Testfällen durch: Blackbox-Verfahren Whitebox-Verfahren Klaus Mairon
27 Statischer Test vs. Dynamischer Test Statischer Test Dynamischer Test Dokumente und Code Keine Ausführung Syntax, Semantik, Logik Sollte vor dem dynamischen Test durchgeführt werden Nur Code Ausführung nötig Struktur, Funktion Benötigt ausführbaren Code Prüfung von Aspekten, die nur zur Laufzeit prüfbar sind (z.b. Performanz) Klaus Mairon
28 Blackbox-Verfahren Was sind Blackbox-Tests? Auf Anforderungen basierende Tests. Vollständiger Test prüft alle Kombinationen von gültigen und ungültigen Eingabewerten. Benötigte Dokumente: Anforderungsspezifikation, Benutzerdokumentation, Schnittstellenbeschreibung. Point of Control (PoC) und Point of Observation (PoO) sind außerhalb des Testobjekts. Klaus Mairon
29 Blackbox-Verfahren oder spezifikationsorientierte Verfahren Äquivalenzklassenbildung Grenzwertanalyse Entscheidungstabelle Zustandsbasierter Test Anwendungsfallbasierter Test (Use-Case) Weitere Verfahren... (Syntaxtest, Zufallstest, Smoke-Test...) Klaus Mairon
30 Äquivalenzklassenbildung Mit der Äquivalenzklassenmethode erfolgt die strukturierte Herleitung von Testfällen. Die Äquivalenzklassenbildung kann in allen Teststufen angewandt werden. Sie kann als Verfahren eingesetzt werden, um hohe Überdeckungsgrade im Bezug auf Eingabe- oder Ausgabewerte zu erreichen. Ziel ist es, eine hohe Fehlerentdeckungsrate mit einer möglichst geringen Anzahl von benötigten Testfällen zu erreichen. Eine Äquivalenzklasse entspricht einer bestimmten Wirkung. (-> logischer Testfall). Klaus Mairon
31 Äquivalenzklassenbildung Schritte zur Äquivalenzklassenbildung Basisklassen ermitteln, für Eingabe und Ausgabe Klassen verfeinern Repräsentanten auswählen Beispiel: Numerische Darstellung eines Monats (Wertebereich) Äquivalenzklassen Eingabe Gültig Ungültig Monat >= 1 und <1 oder <= 12 >12 Testeingabedaten G U U U (G = Gültig, U = Ungültig) Klaus Mairon
32 Grenzwertanalyse Ergänzt die Äquivalenzklassenbildung Baut auf der Tatsache auf, dass Fehler oft an den Grenzen von Wertebereichen auftreten (ug= untere Grenze, og = obere Grenze) Testet, zusätzlich zu den normalen Werten, auch Werte auf oder nahe den Grenzen von Äquivalenzklassen. Beachtet implizit gültige und ungültige Werte. Unterstützt bei der Findung von Werten für konkrete Testfälle. Kann auf allen Teststufen angewandt werden. Klaus Mairon
33 Grenzwertanalyse Die Grenzwerte zweier benachbarter sortierter Bereiche sind: Der größte Wert des unteren Bereichs. Der kleinste Wert des oberen Bereichs. Als Testeingabedaten werden gewählt. Die Grenzwerte einer Äquivalenzklasse Jeweils die 2 benachbarten Werte jedes Grenzwertes, sofern die Werte nicht bereits von anderen Testfällen abgedeckt sind. Grenzwertanalyse ist nur sinnvoll auf sortierten Mengen Klaus Mairon
34 Grenzwertanalyse - Beispiel Numerische Darstellung eines Monats (Wertebereich) Äquivalenzklassen Eingabe Ungültig1 Gültig Ungültig2 Monat <1 >= 1 und <= 12 >12 Grenzwerte <ug-1><ug><ug+1> <og-1><og><og+1> -I I---I---I---I I----I----I I- Min Max Grenzwert-Testeingabedaten U1 U1 G G U2 U2 Min, Min+1-1, 0 1, 2 11, 12 13, 14 Max-1, Max Klaus Mairon
35 Entscheidungstabellentest Entscheidungstabellen können zur Erfassung komplexer von einem System umzusetzenden Regeln verwendet werden. (DIN-Norm 66241) Entscheidungstabellen eignen sich zur Spezifikation von komplexen logischen Regeln. Eine vollständige Abdeckung von Bedingungen wird erreicht. Entscheidungstabellen sind geeignet, um Testfälle zu entwerfen. Üblicherweise mindestens 1 Testfall pro Spalte bzw. Bedingungskombination. Klaus Mairon
36 Entscheidungstabellentest Die vier Quadranten einer Entscheidungstabelle Bedingungen Mögliche Zustände von Objekten Bedingungen Regeln (J/N) Regeln Kombinationen von Bedingungswerten. Aktionen Aktionsanzeiger (x) Aktionen Aktivitäten, die abhängig von den Regeln auszuführen sind. Aktionszeiger Belegung der Bedingungen mit Aktionen. Klaus Mairon
37 Entscheidungstabellentest - Beispiel Beispiel Krankenbesuch Besuchsmöglichkeiten Bedingungen Regeln R 1 R 2 R 3 R 4 R 5 R 6 R 7 R 8 B 1 Ansteckende Krankheiten (J/N) B 2 Besuch innerhalb Besuchszeit (J/N) J J J J J N J N N J N J N N N N B 3 Patient hat Fieber (J/N) J N J N J N J N Aktionen Aktionszeiger Z 1 Z 2 Z 3 Z 4 Z 5 Z 6 Z 7 Z 8 A 1 Besuch max. 30 Minuten X X A 2 Besuch ablehnen X X X X A 3 Besuch nur mit Schwester X X A 4 Normalbesuch X Zu Beginn: 8 Testfälle, B n 2 n Klaus Mairon
38 Entscheidungstabellentest - Beispiel Beispiel Krankenbesuch Besuchsmöglichkeiten Bedingungen Regeln R 1 R 5 R 6 R 7 R 8 B 1 Ansteckende Krankheiten (J/N) J N N N N B 2 Besuch innerhalb Besuchszeit (J/N) -- J J N N B 3 Patient hat Fieber (J/N) -- J N J N Aktionen Aktionszeiger Z 1 Z 5 Z 6 Z 7 Z 8 A 1 Besuch max. 30 Minuten A 2 Besuch ablehnen X X X A 3 Besuch nur mit Schwester X X A 4 Normalbesuch X Nach Konsolidierung: 5 Testfälle Klaus Mairon
39 Blackbox-Verfahren Wann wendet man Blackbox-Verfahren an? Blackbox-Testverfahren Im ganzen Lebenszyklus, aber verstärkt in späten Phasen, d.h. im System- und Abnahmetest, wo der Fokus auf Spezifikationen und Anforderungen liegt. Klaus Mairon
40 Grenzen der Blackbox-Verfahren Testfälle basieren auf Spezifikationen (Verifikation) Spezifikationsfehler werden durch Testen nicht gefunden (aber evtl. bei der Testfallerstellung) Blackbox-Testfälle können keine zusätzlichen Funktionalitäten testen, die in der Spezifikation nicht beschrieben sind. Wechselwirkungen zwischen Eingabe, Ausgabe und dem internen Zustand des Testobjekts werden nur implizit bedacht. Tipp Die Kenntnis der Programmstrukturen sowie die Verfügbarkeit geeigneter Testschnittstellen kann helfen, solche Wechselwirkungen und Abhängigkeiten besser zu erfassen und dadurch intensiver prüfen zu können. Klaus Mairon
41 Blackbox-Verfahren: Zusammenfassung Blackbox-Verfahren definieren Testfälle, insbesondere für funktionale Tests. Testfälle und Testdaten werden aus der (nicht-) funktionalen Spezifikation abgeleitet, ohne die (Programm-) Struktur auszuwerten. Da nachgewiesen werden muss, dass die Software korrekt funktioniert, müssen Blackbox-Tests immer durchgeführt werden. Blackbox-Verfahren können auf allen Teststufen eingesetzt werden, vorzugsweise auf den höheren Teststufen (Systemtest, Abnahmetest) Spezifikationsfehler werden nicht gefunden, aber eventuell bei der Testfallerstellung Benutzersicht (-> Entwicklersicht ) Klaus Mairon
42 Whitebox-Verfahren Was sind Whitebox-Tests? Strukturelle oder Design-orientierte Tests Nutzen der Kenntnis der Programmstruktur: Programm = white box Nutzen des Kontrollflussgraphen Entwicklersicht Welcher bzw. wie viel Code einer Software-Komponente wurde bereits getestet? Ein kompletter Test besteht aus allen möglichen Pfaden durch das Programm (100% Pfadüberdeckung) Aufgabe des Testers besteht nun darin, Testfälle zu ermitteln, welche die angestrebte Überdeckung erreichen Benötigte Dokumente: Quellcode, Designdokumentation Point of Control (PoC) und Point of Observation (PoO) sind innerhalb des Testobjekts. Klaus Mairon
43 Whitebox-Verfahren Whitebox-Verfahren auf verschiedenen Teststufen Komponententest: Die Struktur ist die des Codes selbst, also Anweisungen, Entscheidungen oder Zweige. Integrationstest: Die Struktur kann z.b. ein Aufruf-Baum sein (ein Diagramm, das zeigt, welche Module ein anderes Modul aufrufen), dokumentiert in der Designspezifikation Systemtest: Die Struktur kann z.b. die Menüstruktur sein, Geschäftsprozesse oder die Struktur einer Website, dokumentiert in der Anforderungspezifikation Klaus Mairon
44 Whitebox-Verfahren Abdeckungsmaße: Anweisungsüberdeckung Zweigüberdeckung (Entscheidungsüberdeckung) Bedingungsüberdeckung Einfache Bedingungsüberdeckung Mehrfachbedingungsüberdeckung Pfadüberdeckung Weitere Whitebox-Verfahren Das Konzept der Überdeckungsgrade kann auch auf andere Teststufen übertragen werden (z.b. Integrationstest), wobei der durch eine Testsuite ausgeführte prozentuale Anteil einer Einheit jeweils entsprechend bezeichnet wird: Komponenten-Überdeckung Klassen-Überdeckung... Klaus Mairon
45 Whitebox-Verfahren: Anweisungsüberdeckung Anweisungsüberdeckung (C 0 ) Ziel: Alle Anweisungen im Testobjekt werden mindestens einmal ausgeführt. Vorteil: Einfach zu messendes Kriterium Nachteile: Leere Zweige müssen nicht betreten werden Kontrollfluss wird nicht berücksichtigt Abhängigkeiten zwischen Daten werden nicht berücksichtigt Fazit: Zu schwaches Kriterium! Klaus Mairon
46 Whitebox-Verfahren: Zweigüberdeckung Zweigüberdeckung (C 1 ) Alle Zweige in der Komponente werden mindestens einmal ausgeführt, d.h. alle Entscheidungen müssen mindestens einmal mit Wahr und einmal mit Falsch ausgewertet werden. Ist die Messung des prozentualen Ausgangs eines Entscheidungsausgangs (z.b. wahr und falsch bei einer if-anweisung), welche durch die Testfälle ausgeführt wurden. Um eine hohe Zweigüberdeckung zu erreichen, leitet man Testfälle so ab, dass bestimmte Zweige (Entscheidungsausgang) durchlaufen werden. Klaus Mairon
47 Whitebox-Verfahren: Zweigüberdeckung Zweigüberdeckung (C 1 ) Der Zweigüberdeckungstest ist eine Form des kontrollflussbasierten Tests, da er einen speziellen Kontrollfluss durch die Entscheidungspunkte erzeugt. Die Zweigüberdeckung wird oft auch als Entscheidungsüberdeckung bezeichnet. Vorteil: Einfach zu messendes Kriterium Nachteile: Schleifen müssen nur einmal durchlaufen werden Komplexe Bedingungen werden nicht berücksichtigt Subsumiert Anweisungsüberdeckung: 100% C1 = 100% C0 Fazit: Minimales Kriterium! Klaus Mairon
48 Whitebox-Verfahren: Beispiel für C 0 und C 1 Beispiel: Berechnung der Schaltjahre (Anzahl der Schaltjahre) Klaus Mairon
49 Whitebox-Verfahren: Einfache Bedingungsüberdeckung Einfache Bedingungsüberdeckung (C 2 ) Alle atomaren (Teil-)Bedingungen müssen jeweils mindestens einmal true und einmal false sein. Beispiel: if ( kundennr 5000 prodnr 1000 ) -> 2 Testfälle reichen aus: 1) kundennr = 5000, prodnr = ) kundennr = 4999, prodnr = 1001 Nachteil: Kombinationen von Wahrheitswerten atomarer Teilbedingungen werden nicht berücksichtigt -> schwaches Kriterium! Fazit: C2 ist nicht unbedingt ein umfassenderes Kriterium als C1 Klaus Mairon
50 Whitebox-Verfahren: Mehrfachbedingungsüberdeckung Mehrfachbedingungsüberdeckung (C 3 ) Alle Kombinationen von Wahrheitswerten atomarer (Teil-)Bedingungen müssen berücksichtigt werden. Alle möglichen Kombinationen müssen durchlaufen werden. Beispiel: if ( kundennr 5000 prodnr 1000 ) -> 2 x 2 Testfälle sind notwendig: 1) kundennr = 5000, prodnr = ) kundennr = 4999, prodnr = ) kundennr = 5000, prodnr = ) kundennr = 4999, prodnr = 1000 Klaus Mairon
51 Whitebox-Verfahren: Mehrfachbedingungsüberdeckung Mehrfachbedingungsüberdeckung (C 3 ) Nachteile: Anzahl der möglichen Kombinationen steigt exponentiell mit der Anzahl der atomaren Bedingungen -> sehr aufwendig Oft können nicht alle möglichen Kombinationen mit Testdaten erreicht werden. Subsumiert die vorherigen Überdeckungen: 100% C3 = 100% C2 = 100% C1 = 100% C0 Fazit: C3 ist ein umfassenderes Kriterium als C2 Klaus Mairon
52 Whitebox-Verfahren: Pfadüberdeckung Pfadüberdeckung (C 4 ) Alle möglichen disjunkten Pfade durch ein Programm müssen mindestens einmal durchlaufen werden. Vorteil: Abhängigkeiten zwischen Zweigen und Schleifen werden berücksichtigt Nachteile: Für nichttriviale Programme ist es unmöglich, 100% Pfadüberdeckung zu erreichen! Bei Code mit Schleifen ist die Pfadlänge generell nicht beschränkt! In objektorientierten Sprachen gibt es eine theoretisch unendlich große Zahl von Subtypen durch Vererbung. Subsumiert Anweisungs- und Zweigüberdeckung: 100% C4 = 100% C1 = 100% C0 Fazit: Unpraktikabel wegen potentiell unendlich langen Pfaden Klaus Mairon
53 Instrumentierung und Werkzeugunterstützung Whitebox-Tests erfordern eine Auswertung: Welche Teile des Programms wurden ausgeführt? Welche wurden (noch) nicht ausgeführt? Instrumentieren: Der Quellcode wird um Zähler erweitert, die mit 0 initialisiert und dann beim Durchlauf an den entsprechenden Stellen inkrementiert werden. Die manuelle Instrumentierung und manuelle Berechnung der Abdeckung sind zeitaufwändig und fehleranfällig Klaus Mairon
54 Instrumentierung und Werkzeugunterstützung Somit ist eine Werkzeugunterstützung obligatorisch: Werkzeuge sparen langfristig Geld, steigern die Effizienz und Produktivität und damit auch indirekt die Qualität des Testobjekts. Bekannte Open-Source Werkzeuge im Java-Umfeld: EMMA Cobertura Klaus Mairon
55 Wann wendet man Whitebox-Verfahren an? Hauptsächlich in Entwicklungsphasen, in denen das Hauptaugenmerk auf der internen Struktur eines Programms bzw. einer Komponente liegt. Hauptsächlich beim Komponenten-/Modultest Integrationstest Hier betrachtet man im Allgemeinen die Abdeckung des Aufrufgraphen statt der Abdeckung bzgl. einer der oben aufgeführten Abdeckungskriterien Tipp Prinzipiell für alle Teststufen möglich (Definition eines geeigneten Abdeckungskriteriums entscheidend) Klaus Mairon
56 Wie wendet man Whitebox-Verfahren an? Durchführung des Whitebox-Tests Instrumentiere zu untersuchenden Code Führe die ermittelten (funktionalen) Blackbox-Testfälle aus Ermittle die erreichte Überdeckung Ggf. neue Testfälle entwerfen, wenn erwartete Abdeckung nicht erreicht wird Tipp Prinzipiell ist es auch möglich, für den Whitebox- Test rein strukturelle Testfälle zu erzeugen (d.h. ohne Berücksichtigung der Funktionalität, von Anwendungsfällen, etc.) Dies wird jedoch in der Fachwelt als weniger wirkungsvoll angesehen Es ist sinnvoller, erst bei der Ergänzung der bereits existierenden Blackbox-Testfälle strukturelle Aspekte zu berücksichtigen Klaus Mairon
57 Grenzen der Whitebox-Verfahren Anforderungen, die übersehen und damit nicht implementiert wurden, können mit Whitebox-Tests nicht gefunden werden (ggf. indirekt ). Falsche und fehlende Anforderungen können mit Whitebox-Tests nicht gefunden werden. Whitebox-Tests decken nur implementierte Anforderungen ab! Tipp Klaus Mairon
58 Zusammenfassung Whitebox-Verfahren überprüfen die Programmstruktur. Basierend auf Quellcode. Nicht realisierte Anforderungen können nicht aufgedeckt werden. Eine Werkzeugunterstützung ist obligatorisch. Whitebox-Verfahren werden hauptsächlich auf den niedrigeren Teststufen (Komponententest, Integrationstest) angewendet. Entwicklersicht (vs. Benutzersicht ) Klaus Mairon
59 Vielen Dank für Ihre Aufmerksamkeit. Haben Sie noch Fragen? Kontakt Klaus Mairon Executive IT-Consultant Claims Management Metris GmbH Tel Industriestraße 5 Fax St. Georgen Deutschland IT works. Klaus Mairon
Testen - Konzepte und Techniken
Testen - Konzepte und Techniken Magdalena Luniak 21.11.2007 Magdalena Luniak () Testen - Konzepte und Techniken 21.11.2007 1 / 42 Übersicht 1 Motivation 2 Grundbegrie 3 Testen im Softwareentwicklungsprozess
MehrQualitätsmanagement im Projekt
Software-Engineering Qualitätsmanagement im Projekt Vorlesung im Wintersemester 2008/2009 Fakultät Wirtschaftsinformatik Klaus Mairon, M.Sc. Inhalte Messen und Bewerten: Metriken in der Qualitätssicherung
MehrTesten. SEPR Referat: Testen - Oliver Herbst
Testen Inhalt 1. Grundlagen des Testens 2. Testen im Softwarelebenszyklus 3. Statischer Test 4. Dynamischer Test 5. Besondere Tests 2 1. Grundlagen des Testens 3 Grundlagen des Testens Motivation erfüllt
MehrSystemen - Dynamischer Test
P r a k t I s c h e Testen von Software-Systemen Systemen - Dynamischer Test 2007 Dr. Klaudia Dussa-Zieger Testen von Software-Systemen SS 2007 (1) Inhalt Testfallentwurfsverfahren Festlegen von Testkriterien
MehrHauptseminar Automotive Software Engineering Testen, Rapid Prototyping und x in the loop
Hauptseminar Automotive Software Engineering Testen, Rapid Prototyping und x in the loop Christoph Niedermayr 20.01.2005 Überblick 1 2 X in the loop Rapid Prototyping Begriffe Was versteht man unter statischem
MehrT1 - Fundamentaler Testprozess
AK 2 am Armin Beer, Support Center Test der Software- Entwicklung 1 für einen erfolgreichen Test? Projektteam strebt nach Qualität Aufwände sind eingeplant (Richtwerte) 20 bis 30% des Gesamtaufwandes In
MehrSoftwaretechnik 1 Tutorium
Universität Karlsruhe (TH) Forschungsuniversität gegründet 1825 Softwaretechnik 1 Tutorium 06. Juli 2009 Matthias Thoma (s_thoma@ira.uka.de) Heute Übungsblatt Nr. 4 + Übungsblatt Nr. 5 Softwarequalität
MehrWhitebox-Tests: Allgemeines
-Tests: Allgemeines Andere Bezeichnungen Logic driven, Strukturelles Der Tester entwickelt Testfälle aus einer Betrachtung der Ablauflogik des Programms unter Berücksichtigung der Spezifikation Intuitiv
MehrBasiswissen Softwaretest
Andreas Spillner Tilo Linz Basiswissen Softwaretest Aus- und Weiterbildung zum Certified Tester Foundation Level nach ISTQB-Standard 3., überarbeitete und aktualisierte Auflage I Technische l'^vrau«! D~w.-iE*arit
MehrT2 Fundamentaler Testprozess
T2 Fundamentaler Siemens AG Österreich 2005 All Rights Reserved Institut f. Software Technology, TU-Graz Armin Beer, PSE Support-Center Test Overview der Software- Entwicklung 2 1 Wasserfall-Modell Analyse
MehrDiplomarbeit. Konzeption und Implementierung einer automatisierten Testumgebung. Thomas Wehrspann. 10. Dezember 2008
Konzeption und Implementierung einer automatisierten Testumgebung, 10. Dezember 2008 1 Gliederung Einleitung Softwaretests Beispiel Konzeption Zusammenfassung 2 Einleitung Komplexität von Softwaresystemen
MehrPRÜFUNG FÜR ELEKTROINGENIEURE. Softwaretechnik I. Musterlösung SS 12. - Ohne Gewähr -
PRÜFUNG FÜR ELEKTROINGENIEURE Softwaretechnik I Musterlösung SS 12 - Ohne Gewähr - LfdNr. Thema Punkte Zeitbedarf in min 1 Analyse und Entwurf 15 30 2 Basistechniken und Test 15 30 3 Projektmanagement
MehrSoftwaretechnik. Vertretung von Prof. Dr. Blume Fomuso Ekellem WS 2011/12
Vertretung von Prof. Dr. Blume WS 2011/12 Inhalt Test, Abnahme und Einführung Wartung- und Pflegephase gp Vorlesung Zusammenfassung Produkte und Recht (Folien von Prof. Blume) 2 , Abnahme und Einführung
MehrSEP 114. Design by Contract
Design by Contract SEP 114 Design by Contract Teile das zu entwickelnde Programm in kleine Einheiten (Klassen, Methoden), die unabhängig voneinander entwickelt und überprüft werden können. Einheiten mit
Mehr,$ -. "+0 *+*+ ! / -#$%$. #$%'' $ () 1 2$ #$%$! 1 2$3 )!
*+*+ *,$ -.! / -#$%$. #$%'' $ () "+0 *+*+ 4 *+*+ 1 2$ #$%$! 1 2$3 )! 1 *+*+ $& #$%'!' '!' 5 1! 1 4$5%! 1 63$ 1 $7$! 1 3! 1 77 8'7 1 /!$' 1 83% *+*+ 0 #$%'' '' #$%'' ''$' )%! $' #$% 5 87 $ 8$! 7$+ 1 #$%9$
MehrProjektmanagement. Vorlesung von Thomas Patzelt 9. Vorlesung
Projektmanagement Vorlesung von Thomas Patzelt 9. Vorlesung 1 Pläne Kein Plan überlebt die erste Feindberührung - Feldmarschall Helmuth von Moltke Prognosen sind schwierig, besonders wenn sie die Zukunft
MehrProbeklausur. Lenz Belzner. January 26, 2015. Lenz Belzner Probeklausur January 26, 2015 1 / 16
Probeklausur Lenz Belzner January 26, 2015 Lenz Belzner Probeklausur January 26, 2015 1 / 16 Definieren Sie Software Engineering in Abgrenzung zu Individual Programming. Ingenieursdisziplin professionelle
MehrSoftware- Qualitätsmanagement
Software- Qualitätsmanagement Thomas Kugel Brandenburg, den 10.12.2002 Agenda Einleitung Was heißt Softwarequalitätssicherung und Test Die Rolle von Test und QS in Softwareprojekten Wie wird getestet Statische
MehrTesten Prinzipien und Methoden
Testen Prinzipien und Methoden ALP 2 SS2002 4.7.2002 Natalie Ardet Definition Im folgenden gilt: Software = Programm + Daten + Dokumentation Motivation Software wird immer mehr in Bereichen eingesetzt,
MehrRequirements Engineering für IT Systeme
Requirements Engineering für IT Systeme Warum Systemanforderungen mit Unternehmenszielen anfangen Holger Dexel Webinar, 24.06.2013 Agenda Anforderungsdefinitionen Von der Herausforderung zur Lösung - ein
MehrInformationssystemanalyse Problemstellung 2 1. Trotz aller Methoden, Techniken usw. zeigen Untersuchungen sehr negative Ergebnisse:
Informationssystemanalyse Problemstellung 2 1 Problemstellung Trotz aller Methoden, Techniken usw. zeigen Untersuchungen sehr negative Ergebnisse: große Software-Systeme werden im Schnitt ein Jahr zu spät
MehrQualitätssicherung. Was ist Qualität?
Ein Überblick Methoden und Werkzeuge zur Softwareproduktion Was ist Qualität? "Als Qualität eines Gegenstandes bezeichnen wir die Gesamtheit seiner charakteristischen Eigenschaften" Hesse et al. 2 Was
MehrDie Softwareentwicklungsphasen!
Softwareentwicklung Die Softwareentwicklungsphasen! Die Bezeichnungen der Phasen sind keine speziellen Begriffe der Informatik, sondern den allgemeinen Prinzipien zur Produktion integrierter Systeme entliehen.
MehrKomponententest. Testen von Software Systemen. Übung 02 SS 2009 Version: 1.0 09.06.2009
Testen von Software Systemen Übung 02 SS 2009 Version: 1.0 09.06.2009 Komponententest Kunde: Dr. Reinhold Plösch Dr. Johannes Sametinger Kundenreferenz: 259.019 Team 19 Mitarbeiter: Christian Märzinger
MehrSoftware - Testung ETIS SS05
Software - Testung ETIS SS05 Gliederung Motivation Was ist gute Software? Vorurteile gegenüber Testen Testen (Guidelines + Prinzipien) Testarten Unit Tests Automatisierte Tests Anforderungen an Testframeworks
MehrSenior Consulting. Senior Consulting Strategical, Conceptual and Technical Consulting. 30.01.2011 Seite 1
30.01.2011 Seite 1 This flyer is exclusively for the use of client personnel. No part of it may be distributed, quoted or reproduced outside the client organisation without the prior written approval of
MehrTestphase. Das Testen
Testphase VIS Projekt Freie Universität Berlin N.Ardet - 17.4.2001 Das Testen Testen ist das Ausführen eines Software- (Teil)systems in einer definierten Umgebung und das Vergleichen der erzielten mit
MehrWas versteht man unter Softwaredokumentation?
Was versteht man unter? Mit bezeichnet man die Dokumentation von Computer-Software. Sie erklärt für Anwender, Benutzer und Entwickler in unterschiedlichen Rollen, wie die Software funktioniert, was sie
MehrAgile Software-Entwicklung im Kontext der EN50128 Wege zum Erfolg
Herzlich willkommen Agile Software-Entwicklung im Kontext der EN50128 Wege zum Erfolg Heike Bickert Software-/Systemingenieurin, Bereich Quality Management Braunschweig // 17.11.2015 1 Agenda ICS AG Fragestellungen
MehrCode wiederverwenden: Objektorientierte Programmierung (OOP) sinnvoll nutzen Roland Wagner Automatisierungstreff IT & Automation 2015
Code wiederverwenden: Objektorientierte Programmierung (OOP) sinnvoll nutzen Roland Wagner Automatisierungstreff IT & Automation 2015 CODESYS a trademark of 3S-Smart Software Solutions GmbH Agenda 1 Warum
MehrSoftwaretechnikpraktikum SS 2004. Qualitätsmanagement I. 1. Überblick. Qualität. Qualitätsmerkmal
Softwaretechnikpraktikum SS 2004 Qualitätsmanagement I 5. Vorlesung 1. Überblick Planungsphase Definitionsphase Entwurfsphase Implem.- phase Fragen Was ist Qualität? Wie kann man Qualität messen? Wie kann
MehrStuPro-Seminar Dokumentation in der Software-Wartung. StuPro-Seminar Probleme und Schwierigkeiten in der Software-Wartung.
StuPro-Seminar Dokumentation in der Software-Wartung StuPro-Seminar Probleme und Schwierigkeiten in der Software-Wartung Folie 1/xx Software-Wartung: theoretisch Ausgangslage eigentlich simpel: fertige
MehrHandbuch ECDL 2003 Basic Modul 5: Datenbank Grundlagen von relationalen Datenbanken
Handbuch ECDL 2003 Basic Modul 5: Datenbank Grundlagen von relationalen Datenbanken Dateiname: ecdl5_01_00_documentation_standard.doc Speicherdatum: 14.02.2005 ECDL 2003 Basic Modul 5 Datenbank - Grundlagen
MehrDie vorliegende Arbeitshilfe befasst sich mit den Anforderungen an qualitätsrelevante
ISO 9001:2015 Die vorliegende Arbeitshilfe befasst sich mit den Anforderungen an qualitätsrelevante Prozesse. Die ISO 9001 wurde grundlegend überarbeitet und modernisiert. Die neue Fassung ist seit dem
MehrValidierung und Verifikation!
Martin Glinz Thomas Fritz Software Engineering Kapitel 7 Validierung und Verifikation 2005-2013 Martin Glinz. Alle Rechte vorbehalten. Speicherung und Wiedergabe für den persönlichen, nicht kommerziellen
MehrSystematisches Testen von Software
Programmierung Systematisches Testen von Software Markus Eckstein Systematika Information Systems GmbH Kurfürsten-Anlage 36 69115 Heidelberg markus.eckstein@systematika.com Zusammenfassung Die wichtigsten
MehrTestautomatisierung. Lessons Learned. qme Software. Gustav-Meyer-Allee 25 13355 Berlin. Telefon 030/46307-230 Telefax 030/46307-649
Testautomatisierung Lessons Learned qme Software GmbH Gustav-Meyer-Allee 25 13355 Berlin Telefon 030/46307-230 Telefax 030/46307-649 E-Mail qme Software info@qme-software.de GmbH Testautomatisierung Lessons
MehrStandard Inhaltsverzeichnis für Testvorschrift
Standard Inhaltsverzeichnis für Testvorschrift Inhaltsverzeichnis 1. Zweck, Veranlassung... 1 2. Allgemeines... 1 2.1 Zweck der Testvorschrift... 1 2.2 Freigabe und Änderungen... 1 2.3 Prinzipien... 2
MehrSoftwaretests in Visual Studio 2010 Ultimate Vergleich mit Java-Testwerkzeugen. Alexander Schunk Marcel Teuber Henry Trobisch
Softwaretests in Visual Studio 2010 Ultimate Vergleich mit Java-Testwerkzeugen Alexander Schunk Henry Trobisch Inhalt 1. Vergleich der Unit-Tests... 2 2. Vergleich der Codeabdeckungs-Tests... 2 3. Vergleich
MehrT3 Testen im Software- Lebenszyklus
T3 Testen im Siemens AG Österreich 2005 All Rights Reserved Institut f. Software Technology, TU-Graz Armin Beer, PSE Support-Center Test AK- 2 1 AK- Definition Test der einzelnen implementierten Komponenten
MehrISTQB Certified Tester Foundation Level Exam Übungsprüfung
BEMERKUG: Bitte nur eine Antwort auf jede Frage 1. Die statische Analyse kann höchstwahrscheinlich ICHT finden: (A) Die Verwendung einer Variablen bevor diese definiert wurde. (B) Unerreichbaren ( toten
MehrLeitfaden API. Testing und Debugging. Erstellt am 4.9.2014 Autor FG API, Rinaldo Lanza. Dokumentenstatus Freigegeben at work Version 1.
Leitfaden API Erstellt am 4.9.2014 Autor FG API, Rinaldo Lanza Dokumentenstatus Freigegeben at work Version 1.0 Verteiler Fachgruppe API Änderungen Datum Version Autor Inhaltsverzeichnis 1 Beschreibung
MehrProgrammiertechnik II
Modultests Ziele Überprüfung der Korrektheit eines Moduls Korrektheit: Übereinstimmung mit (informaler) Spezifikation Modul: kleine testbare Einheit (Funktion, Klasse) Engl.: unit test White box testing
MehrIst Excel das richtige Tool für FMEA? Steve Murphy, Marc Schaeffers
Ist Excel das richtige Tool für FMEA? Steve Murphy, Marc Schaeffers Ist Excel das richtige Tool für FMEA? Einleitung Wenn in einem Unternehmen FMEA eingeführt wird, fangen die meisten sofort damit an,
MehrWann ist eine Software in Medizinprodukte- Aufbereitungsabteilungen ein Medizinprodukt?
DGSV-Kongress 2009 Wann ist eine Software in Medizinprodukte- Aufbereitungsabteilungen ein Medizinprodukt? Sybille Andrée Betriebswirtin für und Sozialmanagement (FH-SRH) Prokuristin HSD Händschke Software
MehrTestmanagement in IT-Projekten
Teil 1: Projektmagazin 05/20009 Teil 2: Projektmagazin 06/2009 1 Test: Prozess, bei dem ein Programm oder ein Software-System ausgeführt wird, um Fehler zu finden Teil 1: Projektmagazin 05/20009 Teil 2:
MehrInformatik I Debugging
Der erste Computer-Bug Informatik I G. Zachmann Clausthal University, Germany zach@in.tu-clausthal.de Grace Hopper Admiral, US Navy 2 4 Folgen von Programmfehlern 1962 führte ein fehlender Bindestrich
MehrTest-Strategien. Grundsätzliches Blackbox-Testen Whitebox-Testen Graybox-Testen Ablauf von Tests Zusammenfassung. HS Mannheim
Test- Grundsätzliches - - - Ablauf von Tests Grundsätzliche Test- -Tests Äquivalenzklassenbildung Randwertanalyse -Tests Man unterscheidet verschiedene Überdeckungsgrade: Statement Coverage Decision Coverage,
MehrEinführung und Motivation
Einführung und Motivation iks-thementag: Requirements Engineering 16.11.2010 Autor Carsten Schädel Motto Definiere oder Du wirst definiert. Seite 3 / 51 These Im Privatleben definiert jeder (seine) Anforderungen.
MehrErfolgreiche Webseiten: Zur Notwendigkeit die eigene(n) Zielgruppe(n) zu kennen und zu verstehen!
Erfolgreiche Webseiten: Zur Notwendigkeit die eigene(n) Zielgruppe(n) zu kennen und zu verstehen! www.wee24.de. info@wee24.de. 08382 / 6040561 1 Experten sprechen Ihre Sprache. 2 Unternehmenswebseiten
MehrContent Management System mit INTREXX 2002.
Content Management System mit INTREXX 2002. Welche Vorteile hat ein CM-System mit INTREXX? Sie haben bereits INTREXX im Einsatz? Dann liegt es auf der Hand, dass Sie ein CM-System zur Pflege Ihrer Webseite,
MehrTesten im Software- Entwicklungsprozess
Technologie-Event 2006 Testen im Software- Entwicklungsprozess W.Lukas, INGTES AG Was nicht getestet wurde, funktioniert nicht. -- R.Güdel (ca. 1998) Seite 2 Was sollen wir tun? Anomalien & Defekte von
MehrFassade. Objektbasiertes Strukturmuster. C. Restorff & M. Rohlfing
Fassade Objektbasiertes Strukturmuster C. Restorff & M. Rohlfing Übersicht Motivation Anwendbarkeit Struktur Teilnehmer Interaktion Konsequenz Implementierung Beispiel Bekannte Verwendung Verwandte Muster
MehrVgl. Kapitel 4 aus Systematisches Requirements Engineering, Christoph Ebert https://www.sws.bfh.ch/studium/cas/swe-fs13/protected/re/re_buch.
Vgl. Kapitel 4 aus Systematisches Requirements Engineering, Christoph Ebert https://www.sws.bfh.ch/studium/cas/swe-fs13/protected/re/re_buch.pdf Nachdem die Projekt-Vision und die Stakeholder bekannt sind,
MehrSEPA Lastschriften. Ergänzung zur Dokumentation vom 27.01.2014. Workshop Software GmbH Siemensstr. 21 47533 Kleve 02821 / 731 20 02821 / 731 299
SEPA Lastschriften Ergänzung zur Dokumentation vom 27.01.2014 Workshop Software GmbH Siemensstr. 21 47533 Kleve 02821 / 731 20 02821 / 731 299 www.workshop-software.de Verfasser: SK info@workshop-software.de
MehrProjektmanagement. Vorlesung von Thomas Patzelt 10. Vorlesung
Projektmanagement Vorlesung von Thomas Patzelt 10. Vorlesung 1 Test...(4) Oberflächentests testen die Benutzerschnittstelle des Systems, nicht nur auf Fehlerfreiheit sondern z.b. auch auf Konformität mit
MehrSoftware Engineering II (IB) Testen von Software / Modultests
Testen von Software / Modultests Prof. Dr. Oliver Braun Fakultät für Informatik und Mathematik Hochschule München SS 2015 Programm-Tests Tests sollen zeigen, dass ein Programm das tut was es tun soll sowie
MehrProjektmanagement in der Spieleentwicklung
Projektmanagement in der Spieleentwicklung Inhalt 1. Warum brauche ich ein Projekt-Management? 2. Die Charaktere des Projektmanagement - Mastermind - Producer - Projektleiter 3. Schnittstellen definieren
MehrINFOnline SZM-Checker Ergänzung zum Manual
INFOnline SZM-Checker Ergänzung zum Manual Aktivierung mobiler Geräte für Tests zur InApp- Befragungsfunktionalität INFOnline GmbH Forum Bonn Nord Brühler Str. 9 53119 Bonn Tel.: +49 (0) 228 / 410 29-0
MehrDas System sollte den Benutzer immer auf dem Laufenden halten, indem es angemessenes Feedback in einer angemessenen Zeit liefert.
Usability Heuristiken Karima Tefifha Proseminar: "Software Engineering Kernkonzepte: Usability" 28.06.2012 Prof. Dr. Kurt Schneider Leibniz Universität Hannover Die ProSeminar-Ausarbeitung beschäftigt
MehrSoftwareentwicklung Schrittweise Verfeinerung, Programmieren üben: Tic-Tac-Toe in Raten
Mag. iur. Dr. techn. Michael Sonntag Softwareentwicklung Schrittweise Verfeinerung, Programmieren üben: Tic-Tac-Toe in Raten E-Mail: sonntag@fim.uni-linz.ac.at http://www.fim.uni-linz.ac.at/staff/sonntag.htm
MehrInternet Explorer Version 6
Internet Explorer Version 6 Java Runtime Ist Java Runtime nicht installiert, öffnet sich ein PopUp-Fenster, welches auf das benötigte Plugin aufmerksam macht. Nach Klicken auf die OK-Taste im PopUp-Fenster
MehrSoftwareentwicklungsprozess im Praktikum. 23. April 2015
Softwareentwicklungsprozess im Praktikum 23. April 2015 Agile Softwareentwicklung Eine agile Methodik stellt die beteiligten Menschen in den Mittelpunkt und versucht die Kommunikation und Zusammenarbeit
MehrAgile Software Development
Dipl. Wirtsch. Ing. Alexander Werth Methoden der Softwareentwicklung 6-1 Agile Manifest Individuen und Interaktion statt Prozessen und Tools. Funktionierende Software statt umfangreicher Dokumentation.
MehrTypisierung des Replikationsplan Wirries, Denis Datenbankspezialist
Typisierung des Replikationsplan Wirries, Denis Datenbankspezialist Feintypisierung - Überblick Ergebnisse Ergebnisse aus aus anderen anderen Arbeitsergebnissen Arbeitsergebnissen Replikationsplan Replikationsplan
MehrQualitätsmanagement. Grundlagen
Grundlagen Historie: Mit industriellen Massenproduktion erforderlich geworden (Automobilindustrie, Anfang des letzten Jahrhunderts); Qualitätsmanagement zunächst nur in der Fertigung Mitte des letzten
MehrImpulsvortrag auf der 22. TAV; 18. Februar 2005, Bremen Zuordnung von Anforderungen und Tests (Tracing)
Impulsvortrag auf der 22. TAV; 18. Februar 2005, Bremen Zuordnung von und Tests (Tracing) Dr. Matthias Grochtmann Labor Software-Technologie, Methoden und Tools (REI/SM) DaimlerChrysler AG, Forschung und
MehrAgile Vorgehensmodelle in der Softwareentwicklung: Scrum
C A R L V O N O S S I E T Z K Y Agile Vorgehensmodelle in der Softwareentwicklung: Scrum Johannes Diemke Vortrag im Rahmen der Projektgruppe Oldenburger Robot Soccer Team im Wintersemester 2009/2010 Was
Mehrgeben. Die Wahrscheinlichkeit von 100% ist hier demnach nur der Gehen wir einmal davon aus, dass die von uns angenommenen
geben. Die Wahrscheinlichkeit von 100% ist hier demnach nur der Vollständigkeit halber aufgeführt. Gehen wir einmal davon aus, dass die von uns angenommenen 70% im Beispiel exakt berechnet sind. Was würde
MehrGPP Projekte gemeinsam zum Erfolg führen
GPP Projekte gemeinsam zum Erfolg führen IT-Sicherheit Schaffen Sie dauerhaft wirksame IT-Sicherheit nach zivilen oder militärischen Standards wie der ISO 27001, dem BSI Grundschutz oder der ZDv 54/100.
MehrSoftwaretechnik 3. Klausurnachbesprechung. 09.05.2008, Phillip Ghadir
Softwaretechnik 3 Klausurnachbesprechung 09.05.2008, Phillip Ghadir Benotungsschema Fest vorgegeben Volle Punktzahl und Negativliste Positivliste Bestehen ab 40 Punkte Aufgabenarten Abfrage von auswendig
MehrEinsatz von xalerator. bei den. Ergo Direkt Versicherungen. Bereich Versicherungstechnik/Leben
Einsatz von xalerator bei den Ergo Direkt Versicherungen Bereich Versicherungstechnik/Leben Einführung Die Ergo Direkt Versicherungen wurden 1984 als Finanzdienstleistungs-Segment des Quelle Versandhandels
MehrWelche Unterschiede gibt es zwischen einem CAPAund einem Audiometrie- Test?
Welche Unterschiede gibt es zwischen einem CAPAund einem Audiometrie- Test? Auch wenn die Messungsmethoden ähnlich sind, ist das Ziel beider Systeme jedoch ein anderes. Gwenolé NEXER g.nexer@hearin gp
MehrLineare Gleichungssysteme
Lineare Gleichungssysteme 1 Zwei Gleichungen mit zwei Unbekannten Es kommt häufig vor, dass man nicht mit einer Variablen alleine auskommt, um ein Problem zu lösen. Das folgende Beispiel soll dies verdeutlichen
MehrFragebogen zur Anforderungsanalyse
Fragebogen zur Anforderungsanalyse Geschäftsprozess Datum Mitarbeiter www.seikumu.de Fragebogen zur Anforderungsanalyse Seite 6 Hinweise zur Durchführung der Anforderungsanalyse Bevor Sie beginnen, hier
MehrUse Cases. Use Cases
Use Cases Eigenschaften: Ein Use Case beschreibt einen Teil des Verhaltens eines Systems aus externer Sicht (Formuliert in der der Fachsprache der Anwendung) Dies geschieht, indem ein Systemdialog beschrieben
MehrÜbungsklausur vom 7. Dez. 2007
Übungsklausur vom 7. Dez. 2007 Ein Lösungsmuster Teilbereiche der Softwaretechnik Software Anforderungen Software Entwurf Software Konstruktion Software Test Software Wartung Software Konfigurationsmanagement
MehrDie integrierte Zeiterfassung. Das innovative Softwarekonzept
Die integrierte Zeiterfassung Das innovative Softwarekonzept projekt - ein komplexes Programm mit Zusatzmodulen, die einzeln oder in ihrer individuellen Zusammenstellung, die gesamte Abwicklung in Ihrem
MehrLineargleichungssysteme: Additions-/ Subtraktionsverfahren
Lineargleichungssysteme: Additions-/ Subtraktionsverfahren W. Kippels 22. Februar 2014 Inhaltsverzeichnis 1 Einleitung 2 2 Lineargleichungssysteme zweiten Grades 2 3 Lineargleichungssysteme höheren als
Mehr1 Einleitung...1. Teil I Handwerkszeug...11. 2 Definitionen zur Qualität...13
Inhaltverzeichnis 1 Einleitung...1 1.1 Wieso dieses Buch?...1 1.2 Wem nutzt dieses Buch wie?...2 1.3 Wie ist dieses Buch zu lesen?...3 1.4 Welche Testwerkzeuge werden genannt?...5 1.5 Was liefert dieses
MehrIKP Uni Bonn Medienpraxis EDV II Internet Projekt
IKP Uni Bonn Medienpraxis EDV II Internet Projekt WS 2001/2002 Dozentin: Lucie Prinz Grundlagen der Projektarbeit Was ist ein Projekt? Die Phasen eines Software Projektes Die Projektunterlagen Die Projektplanung
MehrPsychologie im Arbeitsschutz
Fachvortrag zur Arbeitsschutztagung 2014 zum Thema: Psychologie im Arbeitsschutz von Dipl. Ing. Mirco Pretzel 23. Januar 2014 Quelle: Dt. Kaltwalzmuseum Hagen-Hohenlimburg 1. Einleitung Was hat mit moderner
MehrProfessionelle Seminare im Bereich MS-Office
Der Name BEREICH.VERSCHIEBEN() ist etwas unglücklich gewählt. Man kann mit der Funktion Bereiche zwar verschieben, man kann Bereiche aber auch verkleinern oder vergrößern. Besser wäre es, die Funktion
MehrAnwenderdokumentation Prüfung nach dem Heilmittelkatalog
Ausgabe August 2008 Anwenderdokumentation Prüfung nach dem Heilmittelkatalog 1 Einleitung... 2 2 Stammdateneinstellungen... 3 2.1 Zuordnung der Heilmittel... 3 3 Prüfung einer Verordnung... 7 3.1 Vorgehensweise
MehrIst Fernsehen schädlich für die eigene Meinung oder fördert es unabhängig zu denken?
UErörterung zu dem Thema Ist Fernsehen schädlich für die eigene Meinung oder fördert es unabhängig zu denken? 2000 by christoph hoffmann Seite I Gliederung 1. In zu großen Mengen ist alles schädlich. 2.
Mehr1. Man schreibe die folgenden Aussagen jeweils in einen normalen Satz um. Zum Beispiel kann man die Aussage:
Zählen und Zahlbereiche Übungsblatt 1 1. Man schreibe die folgenden Aussagen jeweils in einen normalen Satz um. Zum Beispiel kann man die Aussage: Für alle m, n N gilt m + n = n + m. in den Satz umschreiben:
MehrVector Software. Test Automation mit VectorCAST während der gesamten Softwareentwicklung W H I T E P A P E R
Vector Software W H I T E P A P E R Test Automation mit VectorCAST während der gesamten Softwareentwicklung VectorCAST Produktfamilie Die VectorCAST Produktfamilie automatisiert Testaktivitäten über den
MehrSome Software Engineering Principles
David L. Parnas: Some Software Engineering Principles Marco Oppel 30.06.2004 Seminar Software-Architektur Institut für Informatik Humboldt Universität zu Berlin 1 Problemstellung Software Engineering Multi-Personen
MehrProjektmanagement Vorlesung 14/ 15: Wiederholung ausgewählter Themen zur Klausurvorbereitung. Prof. Adrian Müller, PMP, PSM-1, CSM FH Kaiserslautern
Projektmanagement Vorlesung 14/ 15: Wiederholung ausgewählter Themen zur Klausurvorbereitung Prof. Adrian Müller, PMP, PSM-1, CSM FH Kaiserslautern phone: +49 631/3724-5329 http://www.hs-kl.de/~amueller
MehrOhne Fehler geht es nicht Doch wie viele Fehler sind erlaubt?
Ohne Fehler geht es nicht Doch wie viele Fehler sind erlaubt? Behandelte Fragestellungen Was besagt eine Fehlerquote? Welche Bezugsgröße ist geeignet? Welche Fehlerquote ist gerade noch zulässig? Wie stellt
MehrSoftwaretechnik. Fomuso Ekellem WS 2011/12
WS 2011/12 Inhalt Projektvorstellung Übung 1 Wiederholung zusammengefasst Planungsphase Lernziele Ziele und Inhalt der Planungsphase Anlass und Aufgabestellung(Was ist dabei erförderlich) Requirement Engineering
MehrManagementbewertung Managementbewertung
Managementbewertung Grundlagen für die Erarbeitung eines Verfahrens nach DIN EN ISO 9001:2000 Inhalte des Workshops 1. Die Anforderungen der ISO 9001:2000 und ihre Interpretation 2. Die Umsetzung der Normanforderungen
Mehr«PERFEKTION IST NICHT DANN ERREICHT, WENN ES NICHTS MEHR HINZUZUFÜGEN GIBT, SONDERN DANN, WENN MAN NICHTS MEHR WEGLASSEN KANN.»
«PERFEKTION IST NICHT DANN ERREICHT, WENN ES NICHTS MEHR HINZUZUFÜGEN GIBT, SONDERN DANN, WENN MAN NICHTS MEHR WEGLASSEN KANN.» www.pse-solutions.ch ANTOINE DE SAINT-EXUPÉRY 1 PROJECT SYSTEM ENGINEERING
MehrProzessoptimierung. und. Prozessmanagement
Prozessoptimierung und Prozessmanagement Prozessmanagement & Prozessoptimierung Die Prozesslandschaft eines Unternehmens orientiert sich genau wie die Aufbauorganisation an den vorhandenen Aufgaben. Mit
MehrBasiswissen Softwaretest
Basiswissen Softwaretest Vergleich der Vorlesung Software-Engineering Wartung und Qualitätssicherung (Stand WS13/14) mit der 4. überarbeiteten und aktualisierten Auflage von Spillner&Linz: Basiswissen
MehrGEVITAS Farben-Reaktionstest
GEVITAS Farben-Reaktionstest GEVITAS Farben-Reaktionstest Inhalt 1. Allgemeines... 1 2. Funktionsweise der Tests... 2 3. Die Ruhetaste und die Auslösetaste... 2 4. Starten der App Hauptmenü... 3 5. Auswahl
Mehr16 Architekturentwurf Einführung und Überblick
Teil III: Software-Architekturentwurf 16 Architekturentwurf Einführung und Überblick 16.1 Software entwerfen Warum? Beim Arbeiten im Kleinen nicht oder nur ansatzweise (Detailentwurf) Größere Software
MehrSoftwarequalität: Zusammenfassung und Ausblick. 17. Juli 2013
Softwarequalität: Zusammenfassung und Ausblick 17. Juli 2013 Überblick Rückblick: Qualitätskriterien Qualitätsmanagement Qualitätssicherungsmaßnahmen Thesen zur Softwarequalität Ausblick: Lehrveranstaltungen
MehrFachbericht zum Thema: Anforderungen an ein Datenbanksystem
Fachbericht zum Thema: Anforderungen an ein Datenbanksystem von André Franken 1 Inhaltsverzeichnis 1 Inhaltsverzeichnis 1 2 Einführung 2 2.1 Gründe für den Einsatz von DB-Systemen 2 2.2 Definition: Datenbank
MehrSuche schlecht beschriftete Bilder mit Eigenen Abfragen
Suche schlecht beschriftete Bilder mit Eigenen Abfragen Ist die Bilderdatenbank über einen längeren Zeitraum in Benutzung, so steigt die Wahrscheinlichkeit für schlecht beschriftete Bilder 1. Insbesondere
Mehr