harry m. SNEED manfred BAUMGARTNER richard SEIDL DER SYSTEMTEST VON DEN ANFORDERUNGEN ZUM QUALITÄTSNACHWEIS 3. Auflage EXTRA: Mit kostenlosem E-Book Onlinebonus: Nützliche Systemtest-Tools zum (teils) kostenlosen Download
Inhalt Vorwort....................................................... XIII Die Autoren....XV 1 Einführung in den Systemtest...1 1.1 Das Wesen eines Systemtests................................................ 1 1.2 Von Entwicklern und Anwendern zu Testern...4 1.3 Warum wir testen müssen....6 1.4 Ziele des Systemtests...9 1.5 Der Systemtestprozess....10 1.6 Systemtestnormen...13 1.7 Systemtestwerkzeuge....14 1.8 Systemtester...15 1.9 Zur Systemtestbarkeit...16 1.9.1 Testbarkeit der Anwendungsfälle...16 1.9.2 Testbarkeit der Benutzeroberflächen...17 1.9.3 Testbarkeit der Systemschnittstellen...17 1.9.4 Testbarkeit der Datenbanken....18 1.9.5 Testen ohne Benutzeroberfläche...18 2 Testanforderungsanalyse...21 2.1 Ansätze zur Formulierung der Anforderungen....22 2.1.1 Formale Spezifikation...22 2.1.2 Semiformale Spezifikation....22 2.1.3 Strukturierte Spezifikation...23 2.1.4 Informale Spezifikation...25 2.2 Ansätze zur Normierung der Anforderungen...25 2.3 Die Praxis der Anforderungsdokumentation...28 2.4 Das V-Modell-XT Lastenheft...29 2.5 Die Analyse natursprachlicher Anforderungen...32 2.6 Anforderungsbasierte Testfallermittlung...34 2.7 Ein Beispiel der Testfallermittlung....37 2.8 Zur Automatisierung der Testfallermittlung...44 2.9 Erfahrung mit der automatisierten Anforderungsanalyse...47
VI Inhalt 3 Modellbasierte Testspezifikation...49 3.1 Woher kommt das Modell?...49 3.1.1 Übernahme des Entwicklermodells...50 3.1.2 Erstellung eines eigenen Testmodells...51 3.1.3 Gewinnung eines Modells aus der Anforderungsdokumentation...52 3.1.4 Gewinnung eines Modells aus dem Code....53 3.2 Ableitung der Testfälle aus einem UML Modell...55 3.2.1 Testfälle aus den UseCase-Diagrammen...56 3.2.2 Testfälle aus den Sequenzdiagrammen...56 3.2.3 Testfälle aus den Aktivitätsdiagrammen...56 3.2.4 Testfälle aus den Zustandsdiagrammen....57 3.2.5 Vereinigung der Testfälle....57 3.3 Vom Testmodell zur Testausführung...58 3.4 Alternative zum modellbasierten Test...60 3.4.1 Testen gegen die Vorstellungen des Testers....61 3.4.2 Testen gegen das Benutzerhandbuch...61 3.4.3 Testen gegen die Anforderungsdokumentation....62 3.4.4 Testen gegen das bestehende System....62 3.5 Beurteilung des modellbasierten Testens...62 3.5.1 Modellbasiertes Testen im Vergleich mit Testen gegen die Testervorstellungen....62 3.5.2 Modellbasiertes Testen im Vergleich zum Testen gegen das Benutzerhandbuch....63 3.5.3 Modellbasiertes Testen im Vergleich zum Testen gegen ein bestehendes System...63 3.5.4 Testen gegen ein Modell im Vergleich zum Testen gegen die Anforderungsspezifikation....63 3.5.5 Der optimale Testansatz ist situationsbedingt....64 4 Systemtestplanung...65 4.1 Zweck der Testplanung...65 4.2 Voraussetzungen zur Testplanung...70 4.3 Schätzung der Testaufwände....73 4.3.1 Test-Points...74 4.3.2 Testproduktivität....74 4.3.3 Komplexität und Qualität....75 4.3.4 Die COCOMO-II Gleichung....77 4.4 Schätzung der Testdauer...78 4.5 Testprojektorganisation...79 4.5.1 Organisation der Testressourcen...79 4.5.2 Organisation des Testpersonals....81 4.6 Testrisikoanalyse...82 4.7 Festlegung der Testendekriterien....83 4.8 Gestaltung des Testplans nach ANSI/IEEE-829...85 4.8.1 Testkonzept-ID....86 4.8.2 Einführung...86
Inhalt VII 4.8.3 Zu testende Objekte...87 4.8.4 Zu testende Funktionen...87 4.8.5 Nicht zu testende Funktionen...87 4.8.6 Testvorgehensweise...87 4.8.7 Testendekriterien...87 4.8.8 Testabbruchkriterien...88 4.8.9 Testergebnisse....88 4.8.10 Testaufgaben...88 4.8.11 Testumgebung....89 4.8.12 Testverantwortlichkeiten...89 4.8.13 Testpersonalbedarf...89 4.8.14 Testzeitplan...90 4.8.15 Testrisiken und Risikomanagement...90 4.8.16 Genehmigungen...90 4.9 Die Prüfspezifikation nach V-Modell-XT...91 4.9.1 Einleitung...92 4.9.2 Prüfziele....92 4.9.3 Prüfobjekte...92 4.9.4 Prüffälle...93 4.9.5 Prüfstrategie...93 4.9.6 Prüfkriterien...93 4.9.7 Prüfergebnisse...94 4.9.8 Prüfaufgaben....94 4.9.9 Prüfumgebung...94 4.9.10 Prüffallzuordnung....95 4.9.11 Prüfaufwand...95 4.9.12 Risikovorkehrungen...96 5 Spezifikation der Testfälle....97 5.1 Aufbau der Testfälle...97 5.1.1 Das Testfallkennzeichen....99 5.1.2 Der Testfallzweck...99 5.1.3 Die Testfallquelle...99 5.1.4 Die Testanforderung....100 5.1.5 Der Testvorgang...100 5.1.6 Die Testobjekte...100 5.1.7 Die Testfallvorzustände...101 5.1.8 Die Testfallnachzustände...101 5.1.9 Die Vorgängertestfälle...101 5.1.10 Die Nachfolgetestfälle....102 5.1.11 Die Testumgebung...102 5.1.12 Die Testfallargumente...102 5.1.13 Die Testfallergebnisse...103 5.1.14 Der Testfallstatus...103 5.2 Darstellung der Testfälle...105 5.2.1 Testfälle im Textformat...106
VIII Inhalt 5.2.2 Testfälle im Tabellenformat...108 5.2.3 Testfälle im XML-Format...109 5.2.4 Testfälle in einer formalen Sprache TTCN...110 5.3 Erstellung der Testfälle...113 5.3.1 Generierung der Grunddaten aus dem Anforderungstext...113 5.3.2 Ergänzungen der Testfälle...114 5.4 Speicherung der Testfälle...115 5.4.1 Testfälle als Texte................................................. 115 5.4.2 Testfälle als Tabellen...115 5.4.3 Testfälle als XML-Format...116 5.5 Qualitätssicherung der Testfälle....117 5.5.1 Testfallquantität...118 5.5.2 Messung der Testfallkomplexität...120 5.5.3 Messung der Testfallqualität...121 5.6 Überführung der Testfälle in einen Testentwurf...123 5.7 Wartung und Weiterentwicklung der Testfälle...124 6 Bereitstellung der Testdaten...127 6.1 Testdatenquellen...128 6.1.1 Die Anforderungsdokumentation als Quelle von Testdaten....128 6.1.2 Das Entwurfsmodell als Quelle von Testdaten....129 6.1.3 Der Source-Code als Quelle von Testdaten....129 6.1.4 Die alten Testdaten als Quelle von Testdaten....129 6.1.5 Die Produktionsdaten als Quelle von Testdaten...130 6.1.6 Die fachlogischen Testfälle als Quelle von Testdaten...130 6.2 Testdatenobjekte....130 6.3 Testdatenerstellungsansätze...132 6.3.1 Der blinde Ansatz zur Testdatenerstellung...133 6.3.2 Der gezielte Ansatz zur Testdatenerstellung...133 6.3.3 Der kombinierte Ansatz...134 6.3.4 Der Mutationsansatz...134 6.4 Testdatentypen...135 6.4.1 Datenbanken...136 6.4.2 Systemschnittstellen...137 6.4.3 Benutzeroberflächen...139 6.5 Testdatengenerierung...140 6.5.1 Datengenerierung aus den Testfällen....141 6.5.2 Datengenerierung aus Testprozeduren...142 6.5.3 Datengenerierung aus dem Source-Code...143 6.5.4 Datengenerierung aus vorhandenen Daten...143 6.6 Werkzeuge für die Testdatengenerierung...144 6.6.1 Datenbankgeneratoren....146 6.6.2 Schnittstellengeneratoren...146 6.6.3 Oberflächengeneratoren....147
Inhalt IX 7 Systemtestausführung...149 7.1 Systemtypen............................................................ 150 7.1.1 Alleinstehende Systeme....150 7.1.2 Integrierte Systeme...150 7.1.3 Verteilte Systeme...151 7.1.4 Web-basierte Systeme...152 7.1.5 Service-orientierte Systeme....152 7.1.6 Vollautomatische Systeme...154 7.1.7 Eingebettete Echtzeitsysteme...155 7.2 Test alleinstehender Systeme...156 7.3 Test integrierter Systeme....158 7.3.1 Funktionstest...158 7.3.2 Belastungstest...160 7.3.3 Benutzbarkeitstest...161 7.4 Test verteilter Systeme....162 7.4.1 Interaktionstest....162 7.4.2 Testverfolgung im Netz...162 7.4.3 Sicherheitstest....163 7.5 Test Web-basierter Systeme....164 7.5.1 Test der Web-Architektur....165 7.5.2 Test der Web-Anwendung...165 7.6 Test Service-orientierter Systeme....166 7.6.1 Vorbereitung des Servicetests...167 7.6.2 Ausführung des Web Service-Tests....168 7.6.3 Simulierter Test der Geschäftsprozesse...169 7.6.4 Integration der Services mit den Geschäftsprozessen...169 7.7 Test vollautomatisierter Systeme...170 7.7.1 Werkzeuge für den automatisierten Test...170 7.7.2 Tester für den automatisierten Test...171 7.8 Test eingebetteter Systeme...172 7.9 Kein System ist wie das andere...173 8 Auswertung des Systemtests...175 8.1 Zweck der Testauswertung...175 8.2 Auswertung der Testergebnisse...177 8.2.1 Sichtbare und unsichtbare Ergebnisse....177 8.2.2 Möglichkeiten der Ergebniskontrolle...177 8.2.3 Begründung der Ergebniskontrolle....178 8.2.4 Automatisierte Ergebniskontrolle...179 8.3 Messung der Testüberdeckung...181 8.3.1 Testüberdeckungsmaße...181 8.3.2 Function-Point-Überdeckung....182 8.3.3 Anforderungsüberdeckung...183 8.3.4 Überdeckung bisheriger Funktionalität....184 8.3.5 Fehlerüberdeckung....184
X Inhalt 8.4 Fehleranalyse...185 8.4.1 Fehlerlokalisierung...185 8.4.2 Fehlermeldung...186 8.5 Systemtestmetrik...188 8.5.1 Testüberdeckungsmaße...189 8.5.2 Fehleranalysemaße....192 8.5.3 Messung der Testeffektivität...193 8.6 Systemtestmessung in der Praxis....195 9 Testpflege und fortschreibung...199 9.1 Analyse der Änderungsanträge (CRs)...200 9.2 Fortschreibung und Optimierung des Testplans....201 9.2.1 Fortschreibung der Testziele...201 9.2.2 Fortschreibung der Testobjekte....202 9.2.3 Fortschreibung der zu testenden Funktionen.......................... 202 9.2.4 Fortschreibung der Teststrategie und Testendekriterien...202 9.2.5 Fortschreibung der Testergebnisse....202 9.2.6 Fortschreibung der Testaufgaben...203 9.2.7 Fortschreibung des Personalplanes...203 9.2.8 Fortschreibung der Testrisiken...203 9.2.9 Rekalkulation der Testkosten...204 9.3 Impaktanalyse der Software...205 9.3.1 Statische Impaktanalyse...205 9.3.2 Dynamische Impaktanalyse....206 9.4 Fortschreibung der Testfälle...207 9.4.1 Spezifikation neuer Testfälle...207 9.4.2 Anpassung bestehender Testfälle...207 9.5 Anreicherung der Testdaten...208 9.5.1 Direkte Anreicherung der Daten....208 9.5.2 Indirekte Anreicherung der Daten...208 9.6 Ausführen des Regressionstests...209 9.6.1 Eigenarten eines Regressionstests...209 9.6.2 Der Test im Dialogmodus....210 9.6.3 Der Test im Batch-Modus...210 9.6.4 Testautomatisierung beim Regressionstest...210 9.7 Auswertung des Regressionstests...211 9.7.1 Kontrolle der Regressionstestüberdeckung...211 9.7.2 Kontrolle der Regressionstestergebnisse...212 9.7.3 Protokollierung der Regressionstestergebnisse....214 9.8 Automatisierung des Regressionstests...214 9.9 Der Regressionstest in Migrationsprojekten...216 9.9.1 Voller Regressionstest...217 9.9.2 Selektiver Regressionstest....218
Inhalt XI 10 Systemtestautomation...221 10.1 Ein Modell für die Testautomatisierung....222 10.1.1 Testeingaben...222 10.1.2 Testausgaben....223 10.1.3 Testobjektbeziehungen....223 10.2 Testereignisse...224 10.2.1 Planende Testereignisse....225 10.2.2 Vorbereitende Testereignisse....225 10.2.3 Ausführende Testereignisse...226 10.2.4 Abschließende Testereignisse...226 10.2.5 Zusammenfassung der Testereignisse................................ 227 10.3 Zur Automation der Testereignisse...227 10.3.1 Automatische Ableitung der logischen Testfälle aus der Anforderungsdokumentation...228 10.3.2 Automatisierte Erzeugung eines Testplans...228 10.3.3 Automatische Erstellung eines Testentwurfs....229 10.3.4 Automatische Generierung der Testdaten...229 10.3.5 Automatisierte Erzeugung physikalischer Testfälle...230 10.3.6 Automatische Generierung der Testprozeduren...230 10.3.7 Automatische Instrumentierung des Codes....230 10.3.8 Die automatische Testausführung...231 10.3.9 Die automatische Ergebnisprüfung...231 10.3.10 Automatische Kontrolle der Testüberdeckung....231 10.3.11 Automatisch generierte Testmetrik...231 10.4 Voraussetzungen der Testautomation...232 10.4.1 Formalisierung der Anforderungsspezifikation...233 10.4.2 Standardisierung der Testdokumente...234 10.4.3 Definition der Datenwertebereiche...234 10.4.4 Qualifizierung der Tester...235 10.5 Systemtestautomation als eigenständiges Projekt...236 10.5.1 Erste Automatisierungsstufe...237 10.5.2 Zweite Automatisierungsstufe....237 10.5.3 Dritte Automatisierungsstufe...238 10.5.4 Vierte Automatisierungsstufe...238 10.5.5 Fünfte Automatisierungsstufe....238 10.6 Alternative zum automatisierten Test...238 10.6.1 Erste Alternative = weniger Testen....239 10.6.2 Zweite Alternative = massiver Personaleinsatz....239 10.7 Vergangenheit und Zukunft der Testautomation...240 11 Werkzeuge für den Systemtest...243 11.1 Werkzeugkategorien Einsatzgebiete...243 11.2 Funktionalität und Auswahlkriterien...244 11.3 Werkzeuge aus Projekten: Der Testarbeitsplatz...247
XII Inhalt 12 Testmanagement...253 12.1 Notwendigkeit des Systemtestmanagements....253 12.2 Hauptaufgaben des Systemtestmanagements...254 12.2.1 Testplanung und Umsetzung des Testkonzeptes....255 12.2.2 Laufendes Controlling aller Testaktivitäten....258 12.2.2.1 Inhaltscontrolling...259 12.2.2.2 Controlling der Planungsgrößen...261 12.2.2.3 Controlling der Testendekriterien...263 12.2.3 Sicherstellung der Qualität der Testergebnisse...265 12.2.3.1 Qualität des Testdesigns und der Testfälle...266 12.2.3.2 Qualität der Protokollierung der Testdurchführung....267 12.2.3.3 Qualität des Fehlermanagements....267 12.3 Testprozessmanagement...268 12.3.1 Testprozessgestaltung...268 12.3.2 Testprozessreife...270 12.4 Testteamführung...271 13 Anhang...275 13.1 Anhang A: Testplan nach ANSI/IEEE-829....275 13.2 Anhang B1: Schema für die Testfallspezifikation....281 13.3 Anhang B2: Beispiel einer Testfallspezifikation für den Test der Auftragsbearbeitung...283 13.4 Anhang C1: Testdatengenerierungsskript...286 13.5 Anhang C2: Testergebnisvalidierungsskript....288 Literatur...289 Register...305
2 Testanforderungsanalyse Der erste Schritt in jedem Projekt ist die Analyse der Anforderungen. Bei Testprojekten ist dies nicht anders. Die Anforderungen sind der Ausgangspunkt für den Systemtest. Der Unter schied zu Softwareentwicklungsprojekten besteht darin, dass die Testanforderungen eine Untermenge der allgemeinen Anforderungen sind und dass sie aus den anderen Anforderungen herausgefiltert werden müssen. Wie schwierig dies ist, hängt davon ab, wie die Anforderungen strukturiert und formuliert sind. Ein fachlicher Test ist ein anforderungsbasierter Test, d. h., er geht von den Anforderungen aus, auch wenn sie nicht explizit definiert sind. Was ist aber wenn die Anforderungen nicht stimmen? Nach Glass ist die Qualität bzw. die Richtigkeit, der Anforderungen eine unbedingte Voraussetzung für den Projekterfolg [GLAS98]. Er zitiert mehrere Großprojekte, u. a. das Gepäckbeförderungssystem des Flughafens von Denver, das Wohlfahrtszahlungssystem des Staates Florida, den Rettungsdienst der Londoner Krankenhäuser und das amerikanische FAA-Flugsicherungssystem. All diese Projekte sind wegen unzulänglicher Anforderungen gescheitert oder haben sich zumindest verzögert. Barry Boehm stellte schon 1974 fest, dass 64 % aller Fehler, die beim Abnahmetest auftreten, auf die Anforderungen zurückzuführen sind [BOEH75]. In Deutschland kam eine ähnliche Studie von Endres zum Ergebnis, dass 60 70 % aller Fehler in Großprojekten Folgen falscher oder fehlender Anforderungen sind [ENDR75]. Endres und Rombach formulierten aufgrund dieser und anderer Beobachtungen ein Gesetz, wonach ein System nicht korrekt werden kann, wenn die Anforderungen nicht korrekt sind [ENRO03]. Es sollte also selbstverständlich sein, dass ein Systemtest mit einem Test der Anforderungen beginnt.
22 2 Testanforderungsanalyse 2.1 Ansätze zur Formulierung der Anforderungen Grundsätzlich gibt es nach Ebert vier Möglichkeiten zur Formulierung der Systemanforderungen [EBER05]: formal semiformal strukturiert informal Die formale Formulierung verwendet eine künstliche Sprache, zum Beispiel eine algorithmische wie Z oder eine mengenorientierte wie OCL. Die semiformale Formulierung verwendet genormte Tabellen und Diagramme bzw. eine strukturierte, natürliche Sprache. Die informale Formulierung verwendet die natürliche Sprache Englisch, Deutsch, Französisch usw., ergänzt durch freiformatierte Tabellen und Diagramme. 2.1.1 Formale Spezifikation Seit Beginn der automatisierten Datenverarbeitung bzw. der Informationstechnologie wird eine Formalisierung der Anforderungsdokumentation angestrebt. Es hat auch jede Menge Ansätze von formalen Sprachen, wie VDM und Z, bis hin zu diversen tabellenorientierten Ansätzen wie Entscheidungstabellen und Zustandstabellen gegeben. Die Object Constraint Language (OCL) ist die letzte Sprache in einer langen Reihe von Spezifikationssprachen. Diese neue deklarative und mengenorientierte Sprache wird von der OMG propagiert. [WARM03] 2.1.2 Semiformale Spezifikation Bis auf wenige technisch-wissenschaftliche Anwendungen haben sich formale Spezifika tionssprachen aber nie durchgesetzt. Sie waren bisher zu restriktiv, um die volle Breite an informatorischen Anwendungen abzudecken. Anders die semiformalen Ansätze. Bereits in den 70er-Jahren stellten David Parnas und sein Team im amerikanischen Naval Research Lab eine umfangreiche, tabellenorientierte Anforderungsdokumentation für die Software der A7-Jagdbomber her. Diese Dokumentation, die noch heute als Vorbild für eine Anforderungsdokumentation gilt, kombiniert Tabellen mit Texten und Zeichnungen. Die Funktionstabellen vereinigen Aktionen mit Ergebnissen und Zuständen. Die Datentabellen ordnen die Attribute den Objekten und Geräten zu. Datenflusstabellen zeigen die Beziehungen zwischen Aktionen und Attributen. Sogar die nichtfunktionalen Anforderungen sind in Tabellen dargestellt zusammen mit Maßzahlen, an denen sie gemessen werden sollten [PARN78] (siehe Abbildung 2.1).
2.1 Ansätze zur Formulierung der Anforderungen 23 Abbildung 2.1 Beispiel einer semiformalen Funktionsbeschreibung 2.1.3 Strukturierte Spezifikation Die A7-Anforderungsdokumentation ist also ein Beispiel dafür, wie Anforderungen verfasst werden könnten. Leider fand sie in der kommerziellen Welt wenige Nachahmer. Die Fachkonzepte blieben in der Regel unstrukturierte Prosatexte. In den 80er-Jahren erschienen zahlreiche Bücher über die Strukturierung von Anforderungsdokumenten. Besonders erwähnenswert sind die von Ed Yourdon und Tom DeMarco, die eine funktionsorientierte Darstellung propagieren [DEMA78], sowie die Methoden von Michael Jackson [JACK83] und Jean-Dominique Warnier [WARN81], die eine datenorientierte Darstellung bevorzugen. Structured Analysis wurde als Methode zur Erfassung und Beschreibung der Anforderungen in den 80er-Jahren etabliert. Diese Methode sah eine Kombination von Strukturprogrammen, Datenbäumen, Datenflussdiagrammen und Entscheidungsbäumen bzw. Tabellen vor, um Texte zu ergänzen [GANE79]. In manchen Ländern, wie zum Beispiel Großbritannien, wurde diese Methode für die Ausschreibung aller öffentlichen Software-Entwicklungsprojekte zur Pflicht erklärt.
24 2 Testanforderungsanalyse Abbildung 2.2 SOFTSPEC-Entscheidungsbaum Für die Ableitung funktionaler Testanforderungen waren nach der strukturierten Analyse erstellte Dokumente gut geeignet, und es fehlte nicht an Ansätzen, um die funktionalen Testfälle daraus abzuleiten. Der SOFTSPEC-Ansatz des ungarischen SZKI Instituts sah vor, die Ausgänge der Entscheidungsbäume bzw. die Regeln der Entscheidungstabellen zu verwenden. Das Anforderungserfassungswerkzeug SOFTSPEC erreichte eine hohe Akzeptanz bei den Systemanalytikern in Deutschland und wurde in zahlreichen deutschen Großbetrieben zu diesem Zweck eingesetzt. Auch heute noch dient SOFTSPEC als Vorbild für eine betriebswirtschaftliche Anforderungssprache. Demnach entsprach ein funktionaler Testfall einem Pfad durch einen Entscheidungsbaum bzw. einer Regel in einer Entscheidungstabelle [SNEE86] (siehe Abbildung 2.2). Als Folge des Aufstiegs der Objekttechnologie in den 90er-Jahren ist die strukturierte Analyse in den Hintergrund getreten. Eine neue Sprache zur Erfassung der Anforderungen ist entstanden die objektorientierte Analyse. An die Stelle der Funktion rückte das Objekt in den Mittelpunkt der Betrachtung. Nach der OO-Analyse erstellte Anforderungsdokumente gehen vom Datenmodell aus (Modeling the World in Data [SHLA88]), erreichen über die Datenobjekte die Zustände (Modeling the World in States [SHLA92]) und von dort aus schließlich die Zustandswechsel bzw. die zu testenden Aktionen. Die Dokumentationen der Anforderungen nach der neuen Lehre der OO-Technologie erwiesen sich für die meisten kommerziellen Nutzer als zu schwierig. Bis zu den Zustandsübergängen der Objekte sind sie selten gelangt. Also blieben die Klassendiagramme zur Abbildung des Datenmodells. Diese Lücke zwischen den
2.2 Ansätze zur Normierung der Anforderungen 25 passiven Objekten und den aktiven Funktionen gab Anlass zur Erfindung des Use-Case bzw. Anwendungsfalls. In seinem klassischen Werk Object-oriented Software Engineering schlug Jacobson vor, die Objektorientierung durch einen ganz und gar nicht-objektorientierten Rückgriff auf die Methode der strukturierten Analyse zu ergänzen [JACO92]. Der Anwendungsfall entspricht einem Geschäftsvorfall bzw. einem Vorgang. Um die Anforderungen einer bestimmten Anwendung dingfest zu machen, benötigt man einen Bezugspunkt, der eine Funktion sein sollte, die zu einer Zeit an einem Ort stattfindet. Der Anwendungsfall bzw. Geschäftsvorfall oder Vorgang verkörpert diese Funktionalität. Darum wurde er zum unerlässlichen Bestandteil einer Anforderungsbeschreibung neben den Geschäftsobjekten, den Geschäftszielen und den Geschäftsregeln [ERIK00]. Die heute propagierte modellgetriebene Entwicklung setzt voraus, dass die Anforderungen in Form von Modellen formuliert sind. Neben den Anwendungsfällen bieten sich auch Prozessbäume, Aktivitätsdiagramme, Entscheidungsbäume und Entity/Relationship-Diagramme an. Laut Prof. Klaus Pohl kann prinzipiell jede Anforderung durch ein Modell dokumentiert werden. Die Frage ist nur, wie die Anforderung am besten zu formulieren ist, in Worten oder mit Bildern [POHL07]. 2.1.4 Informale Spezifikation Leider sind allzu viele Anforderungsdokumente Lastenhefte, Fachkonzepte oder wie sie sonst heißen mögen in Prosaschrift verfasst, und zwar ohne erkennbare Anforderungen. Die Verfasser der Anforderungsdokumente schreiben sie wie Schulaufsätze und erläutern darin ihre Wünsche. Die Texte sind zwar durch Bilder und Tabellen ergänzt, aber es gibt keinerlei genormte Struktur, mit deren Hilfe man die Anforderungen erkennen kann. Der Mensch bzw. der Textanalysator kann allenfalls aus einzelnen Sätzen gewünschte Aktionen und Zustände ableiten und in Anforderungen umsetzen. Die Interpretation solcher Dokumente stellt eine wahre Herausforderung für Mensch und Maschine dar. 2.2 Ansätze zur Normierung der Anforderungen Mittlerweile gibt es einzelne Normen, die vorgeben, was die Anforderungsdokumentation bzw. das Fachkonzept beinhalten soll. Eine Reihe von Büchern, voran das Buch des Ehepaars Robertson, haben zur Verabschiedung einer OMG-Norm geführt. Diese sieht folgende Inhalte vor: die angestrebten Ziele (Business Goals) die betroffenen Objekte (Business Objects) die Vorgänge bzw. Anwendungsfälle (Business Processes) die Verarbeitungsregeln (Business Rules) die verwendeten Betriebsmittel (Business Resources) [ROBE99]
Register A Ablaufdiagramm 54 Ablaufpfad 162 Abnahmekriterium 26, 233 Aktivitätsdiagramm 56 Änderungsantrag 200 Anforderung 100 Formulierung 22 Anforderungsanalyse 13, 21, 32, 66, 228, 231 Szenario-basiert 32 Anforderungsdokument 22, 34, 223 datenorientiert 23 funktionsorientiert 23 Normierung 25 objektorientiert 24 tabellenorientiert 22 Anforderungsdokumentation 62 Anforderungsmetrik 231 Anforderungsspezifikation 221, 233 Anforderungstext 99 Anforderungsüberdeckung 183, 191 Anwendungsfall 16, 25, 233 Komplexität 76 Testbarkeit 16 API 137 Äquivalenz-Klassen 234 Architekturüberdeckung 189 ARTSCENE 33 Auswertung 11, 268 Automatisierung 4, 14, 177 Anforderungsanalyse 14 Testausführung 15 Testauswertung 15 Testfallermittlung 44, 47 B Batch-Lauf 170 Batch-Modus 210 Batch-Verarbeitung 158 Belastungstest 160 Benutzbarkeitstest 161, 166 Benutzerhandbuch 61 Benutzeroberfläche 17, 66 Komplexität 76 Testbarkeit 17 Umgehung 18 Black-Box 222 Black-Box-Test 66 C Change-Management 259 Change-Request 200, 248 COBOL 129 CobRetest 129 COCOMO-I 78 COCOMO-II 74, 78, 149 codebasiert 222 Codeüberdeckung 84, 189 Controlling 258 D Data-Warehouse 127, 154, 249 Datenbank 18 Testbarkeit 18 Datenbankgenerator 146 datenbasiert 222 Datenflussdiagramm 54 Datenschutz 130 Datenüberdeckung 84, 190 DDP 265 Durchführung 11, 268, 269, 270 E EDI 179 Effizienzsteigerung 221 E-Government 5 Elisa 32 End-to-End-Integration 4 Entity/Relationship-Diagramm 39, 222 Entscheidungsbaum 24, 118 Entwurfsmodell 50, 223 Erfahrungsdatenbank 72 Ergebniskontrolle 177 ETSI 113
306 Register F Fehleranalyse 185, 188, 192 Fehlerbehebungskosten 7 Fehlerdichte 72, 84 Fehlerlokalisierung 185 Fehlermanagement 69, 176, 245, 267 Fehlermeldung 186 Fehlerquote 262 Fehlerrate 6, 7, 65, 72 Fehlerüberdeckung 83, 184 Fehlerverfolgung 176 Fehlerzahl 84 Freigabekriterium 264 Function-Point 71, 83, 182 Funktionskombinationen 87 Funktionstest 158, 166 Funktionsüberdeckung 84, 190 G Gantt-Diagramm 67 GEOS 221 Geschäftsprozesse 233 Geschäftsvorfall 35 Grammar Patterns 32 I IEEE Standard 829 11, 85 IEEE Standard 830 26 IEEE Standard 1044 192 Impaktanalyse 203, 205 Informationsquelle 35 Inhaltscontrolling 259 Instrumentierung 162, 186, 189, 206, 226, 230, 248 Integrationsprojekt 127 Integrationstest 70, 165 Integrierbarkeit 26 Interaktionstest 162 Internetsystem 164 ISO 9126 26 ISTQB 3, 10 K Komponententest 70 Konfigurations-Management 259 L logische Testfälle 223 M Metrik, Testbarkeit 16 Migrationsprojekt 127, 178, 221, 251 Model Driven Testing 245 modellbasiert 222 modellbasierte Entwicklung 49 modellbasierte Testspezifikation 49 Monkey-Test 68 Multi-User-System 150 Mustererkennung 32 N Natural Language Processing 32, 34 Normen 13 O Oberflächengenerator 147 Oberflächentest 17 Object-Point 71 Objekttechnologie 24 OCL 22, 28, 129 OMG 22, 25, 37 Ontologie 225 Open Source 244 Outsourcing 3 P PCDA-Zyklus 258 Performanz 26 Personaleinsatz 238 Planung 11, 268, 269, 270 Produktionsdaten 130, 143 Produktionsreife 65 Programmiersprache 105 Protokollierung 11, 268 Q Qualitätsfaktor 123 Qualitätsmanagement 253 Qualitätsmerkmal 26 R Regressionstest 184, 200, 209 Reifegrad 244 Reifezeit 199 Restrisiko 260 Reverse Engineering 53 Risikoanalyse 82 Risikomanagement 90 RMI 137 ROI 243 RPC 137 RUP 7 Rupp-Regel 33
Register 307 S SAP 6 Schedule-Compression-Faktor 79 Schnittstelle 17, 66, 137 Generator 146 Komplexität 76 Testbarkeit 17 Schulung 89 Scrambling-Algorithmus 143 Sequenzdiagramm 56 Sicherheit 26 Sicherheitstest 163 Skalierungsexponent 75 SOAP 138, 179 SOFTSPEC 24 Softwareevolution 199 Spezifikation 11, 268, 269, 270 Stand-Alone-System 149, 150 Standardisierung 234 Standardprodukte 3 Systemakteur 37 Systemarchitektur 225 Systemdokumentation 70 Systemkomplexität 83 Systemtest 1 Informationsquelle 35 Komplexität 76 Metrik 188, 195 Planung 65, 255 Testbarkeit 16 Tester 15 Testprozess 10 Testzyklus 10 Werkzeuge 14 Wiederholung 10 Ziele 9, 66 Systemtestautomation 221, 236 T Testabbruchkriterien 88 Testanforderung 12, 13, 21 Testansatz 12 Testaufgabe 88, 203 Testaufwand 261 Testaufwandsschätzung 228 Testausführung 11, 58 Testausführungsmonitor 248 Testausgaben 223 Testauswertung 11, 175, 221 Testautomation 221 Testautomatisierung 210, 241, 246 Testbarkeit 16, 76 Testbasis 50 Testbus 19 Testdaten 80, 127, 208, 225, 229 Bereitstellung 12 Dichte 120 Generator 15, 133, 144, 170, 249, 251 Generierung 141 Komplexität 120 Mutation 134 Quelle 128 Volumen 120 Test-Design 11 TestDoc 248 Testeffektivität 193 Testeingaben 222 Testendekriterium 12, 67, 83, 87, 202, 229, 263 Testentwurf 229 Tester 15, 69 Testerarbeitsplatz 247 Testereignisse 224 Testergebnis 88, 177, 190, 202, 212 Testfall aktionsbasiert 37 Analysator 250 Argument 102 Auditor 117 Auswirkung 121 automatisierte Ermittlung 44, 47 Datenbank 14 Dichte 120 Ergebnis 103 Ermittlung 34, 37 Evolution 125 Generierung 34 Kennzeichen 99 Komplexität 120 Modularität 121 Nachzustand 101 Qualität 121, 123 Qualitätssicherung 117 Quantität 118 Quelle 99 regelbasiert 37 Speicherung 115 Spezifikation 97 Status 103 Tabellenformat 108, 115 Textformat 106, 115 Verwaltung 14 Vollständigkeit 122 Vorzustand 101 Wiederverwendbarkeit 122 XML-Format 109, 116 zustandsbasiert 37
308 Register Zweck 99 Testfeinkonzept 11 Testfortschreibung 199, 201, 207 Testfortschritt 65, 188 Testgrobkonzept 12 Testing Board 3 Testkalkulation 65 Testkonzept 11, 22, 23, 25, 86 Testkosten 204 Testmanagement 244, 253 Testmethode 68, 71 Testmetrik 176, 227, 231 Testmodell 51 Testmonitor 170 Testobjekt 100, 202 Testobjektbeziehung 223 Testorganisation 81 Testörtlichkeit 71 Testpflege 199 Testplan 11, 65, 200, 228 Testplanung 11, 65, 70, 255, 268, 270 Test-Point 71 Testproduktivität 72 Testprojektplan 228 Testprotokollierung 11 Testprozedur 226, 230 Testprozess 10, 12 Testressourcen 79 Testrisiko 82, 90, 203 Testroboter 231 Testskript 226 Testspezifikation 11 Teststrategie 87, 202 Testszenario 12 Testteam 81 Testtermin 71 Testüberdeckung 72, 181, 195, 211, 226, 231 Testumgebung 79, 89, 102, 235 Testvalidator 171 Testverantwortlichkeit 203 Testvorgang 100 Testware 200 Testwerkzeug 68, 71, 235 Testziele 71 Testzyklus 223 Textanalyse 33, 44, 119, 201, 228, 250 Text Mining 33 Transformationsregel 127 TTCN 110 TTCN-3 111 U Überdeckungsmaße 67 Übertragbarkeit 26 UML 28, 118, 129 UML-Modell 55 Use-Case 25 UseCase Diagramm 56 V VDM 22 Vertrauensgrad 194 V-Modell 7, 10 V-Modell XT 255 W Wartbarkeit 26 Web-Service 4 Werkzeug 14, 243 Widgets 17 Wiederverwendbarkeit 26 WSDL 141 Z Z 22 Zertifizierung 3 Zustandsdiagramm 57 Zuverlässigkeit 26