DER SYSTEMTEST VON DEN ANFORDERUNGEN ZUM QUALITÄTSNACHWEIS

Transkript

1 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

2 Inhalt Vorwort XIII Die Autoren....XV 1 Einführung in den Systemtest Das Wesen eines Systemtests Von Entwicklern und Anwendern zu Testern Warum wir testen müssen Ziele des Systemtests Der Systemtestprozess Systemtestnormen Systemtestwerkzeuge Systemtester Zur Systemtestbarkeit Testbarkeit der Anwendungsfälle Testbarkeit der Benutzeroberflächen Testbarkeit der Systemschnittstellen Testbarkeit der Datenbanken Testen ohne Benutzeroberfläche Testanforderungsanalyse Ansätze zur Formulierung der Anforderungen Formale Spezifikation Semiformale Spezifikation Strukturierte Spezifikation Informale Spezifikation Ansätze zur Normierung der Anforderungen Die Praxis der Anforderungsdokumentation Das V-Modell-XT Lastenheft Die Analyse natursprachlicher Anforderungen Anforderungsbasierte Testfallermittlung Ein Beispiel der Testfallermittlung Zur Automatisierung der Testfallermittlung Erfahrung mit der automatisierten Anforderungsanalyse...47

3 VI Inhalt 3 Modellbasierte Testspezifikation Woher kommt das Modell? Übernahme des Entwicklermodells Erstellung eines eigenen Testmodells Gewinnung eines Modells aus der Anforderungsdokumentation Gewinnung eines Modells aus dem Code Ableitung der Testfälle aus einem UML Modell Testfälle aus den UseCase-Diagrammen Testfälle aus den Sequenzdiagrammen Testfälle aus den Aktivitätsdiagrammen Testfälle aus den Zustandsdiagrammen Vereinigung der Testfälle Vom Testmodell zur Testausführung Alternative zum modellbasierten Test Testen gegen die Vorstellungen des Testers Testen gegen das Benutzerhandbuch Testen gegen die Anforderungsdokumentation Testen gegen das bestehende System Beurteilung des modellbasierten Testens Modellbasiertes Testen im Vergleich mit Testen gegen die Testervorstellungen Modellbasiertes Testen im Vergleich zum Testen gegen das Benutzerhandbuch Modellbasiertes Testen im Vergleich zum Testen gegen ein bestehendes System Testen gegen ein Modell im Vergleich zum Testen gegen die Anforderungsspezifikation Der optimale Testansatz ist situationsbedingt Systemtestplanung Zweck der Testplanung Voraussetzungen zur Testplanung Schätzung der Testaufwände Test-Points Testproduktivität Komplexität und Qualität Die COCOMO-II Gleichung Schätzung der Testdauer Testprojektorganisation Organisation der Testressourcen Organisation des Testpersonals Testrisikoanalyse Festlegung der Testendekriterien Gestaltung des Testplans nach ANSI/IEEE Testkonzept-ID Einführung...86

4 Inhalt VII Zu testende Objekte Zu testende Funktionen Nicht zu testende Funktionen Testvorgehensweise Testendekriterien Testabbruchkriterien Testergebnisse Testaufgaben Testumgebung Testverantwortlichkeiten Testpersonalbedarf Testzeitplan Testrisiken und Risikomanagement Genehmigungen Die Prüfspezifikation nach V-Modell-XT Einleitung Prüfziele Prüfobjekte Prüffälle Prüfstrategie Prüfkriterien Prüfergebnisse Prüfaufgaben Prüfumgebung Prüffallzuordnung Prüfaufwand Risikovorkehrungen Spezifikation der Testfälle Aufbau der Testfälle Das Testfallkennzeichen Der Testfallzweck Die Testfallquelle Die Testanforderung Der Testvorgang Die Testobjekte Die Testfallvorzustände Die Testfallnachzustände Die Vorgängertestfälle Die Nachfolgetestfälle Die Testumgebung Die Testfallargumente Die Testfallergebnisse Der Testfallstatus Darstellung der Testfälle Testfälle im Textformat...106

5 VIII Inhalt Testfälle im Tabellenformat Testfälle im XML-Format Testfälle in einer formalen Sprache TTCN Erstellung der Testfälle Generierung der Grunddaten aus dem Anforderungstext Ergänzungen der Testfälle Speicherung der Testfälle Testfälle als Texte Testfälle als Tabellen Testfälle als XML-Format Qualitätssicherung der Testfälle Testfallquantität Messung der Testfallkomplexität Messung der Testfallqualität Überführung der Testfälle in einen Testentwurf Wartung und Weiterentwicklung der Testfälle Bereitstellung der Testdaten Testdatenquellen Die Anforderungsdokumentation als Quelle von Testdaten Das Entwurfsmodell als Quelle von Testdaten Der Source-Code als Quelle von Testdaten Die alten Testdaten als Quelle von Testdaten Die Produktionsdaten als Quelle von Testdaten Die fachlogischen Testfälle als Quelle von Testdaten Testdatenobjekte Testdatenerstellungsansätze Der blinde Ansatz zur Testdatenerstellung Der gezielte Ansatz zur Testdatenerstellung Der kombinierte Ansatz Der Mutationsansatz Testdatentypen Datenbanken Systemschnittstellen Benutzeroberflächen Testdatengenerierung Datengenerierung aus den Testfällen Datengenerierung aus Testprozeduren Datengenerierung aus dem Source-Code Datengenerierung aus vorhandenen Daten Werkzeuge für die Testdatengenerierung Datenbankgeneratoren Schnittstellengeneratoren Oberflächengeneratoren

6 Inhalt IX 7 Systemtestausführung Systemtypen Alleinstehende Systeme Integrierte Systeme Verteilte Systeme Web-basierte Systeme Service-orientierte Systeme Vollautomatische Systeme Eingebettete Echtzeitsysteme Test alleinstehender Systeme Test integrierter Systeme Funktionstest Belastungstest Benutzbarkeitstest Test verteilter Systeme Interaktionstest Testverfolgung im Netz Sicherheitstest Test Web-basierter Systeme Test der Web-Architektur Test der Web-Anwendung Test Service-orientierter Systeme Vorbereitung des Servicetests Ausführung des Web Service-Tests Simulierter Test der Geschäftsprozesse Integration der Services mit den Geschäftsprozessen Test vollautomatisierter Systeme Werkzeuge für den automatisierten Test Tester für den automatisierten Test Test eingebetteter Systeme Kein System ist wie das andere Auswertung des Systemtests Zweck der Testauswertung Auswertung der Testergebnisse Sichtbare und unsichtbare Ergebnisse Möglichkeiten der Ergebniskontrolle Begründung der Ergebniskontrolle Automatisierte Ergebniskontrolle Messung der Testüberdeckung Testüberdeckungsmaße Function-Point-Überdeckung Anforderungsüberdeckung Überdeckung bisheriger Funktionalität Fehlerüberdeckung

7 X Inhalt 8.4 Fehleranalyse Fehlerlokalisierung Fehlermeldung Systemtestmetrik Testüberdeckungsmaße Fehleranalysemaße Messung der Testeffektivität Systemtestmessung in der Praxis Testpflege und fortschreibung Analyse der Änderungsanträge (CRs) Fortschreibung und Optimierung des Testplans Fortschreibung der Testziele Fortschreibung der Testobjekte Fortschreibung der zu testenden Funktionen Fortschreibung der Teststrategie und Testendekriterien Fortschreibung der Testergebnisse Fortschreibung der Testaufgaben Fortschreibung des Personalplanes Fortschreibung der Testrisiken Rekalkulation der Testkosten Impaktanalyse der Software Statische Impaktanalyse Dynamische Impaktanalyse Fortschreibung der Testfälle Spezifikation neuer Testfälle Anpassung bestehender Testfälle Anreicherung der Testdaten Direkte Anreicherung der Daten Indirekte Anreicherung der Daten Ausführen des Regressionstests Eigenarten eines Regressionstests Der Test im Dialogmodus Der Test im Batch-Modus Testautomatisierung beim Regressionstest Auswertung des Regressionstests Kontrolle der Regressionstestüberdeckung Kontrolle der Regressionstestergebnisse Protokollierung der Regressionstestergebnisse Automatisierung des Regressionstests Der Regressionstest in Migrationsprojekten Voller Regressionstest Selektiver Regressionstest

8 Inhalt XI 10 Systemtestautomation Ein Modell für die Testautomatisierung Testeingaben Testausgaben Testobjektbeziehungen Testereignisse Planende Testereignisse Vorbereitende Testereignisse Ausführende Testereignisse Abschließende Testereignisse Zusammenfassung der Testereignisse Zur Automation der Testereignisse Automatische Ableitung der logischen Testfälle aus der Anforderungsdokumentation Automatisierte Erzeugung eines Testplans Automatische Erstellung eines Testentwurfs Automatische Generierung der Testdaten Automatisierte Erzeugung physikalischer Testfälle Automatische Generierung der Testprozeduren Automatische Instrumentierung des Codes Die automatische Testausführung Die automatische Ergebnisprüfung Automatische Kontrolle der Testüberdeckung Automatisch generierte Testmetrik Voraussetzungen der Testautomation Formalisierung der Anforderungsspezifikation Standardisierung der Testdokumente Definition der Datenwertebereiche Qualifizierung der Tester Systemtestautomation als eigenständiges Projekt Erste Automatisierungsstufe Zweite Automatisierungsstufe Dritte Automatisierungsstufe Vierte Automatisierungsstufe Fünfte Automatisierungsstufe Alternative zum automatisierten Test Erste Alternative = weniger Testen Zweite Alternative = massiver Personaleinsatz Vergangenheit und Zukunft der Testautomation Werkzeuge für den Systemtest Werkzeugkategorien Einsatzgebiete Funktionalität und Auswahlkriterien Werkzeuge aus Projekten: Der Testarbeitsplatz...247

9 XII Inhalt 12 Testmanagement Notwendigkeit des Systemtestmanagements Hauptaufgaben des Systemtestmanagements Testplanung und Umsetzung des Testkonzeptes Laufendes Controlling aller Testaktivitäten Inhaltscontrolling Controlling der Planungsgrößen Controlling der Testendekriterien Sicherstellung der Qualität der Testergebnisse Qualität des Testdesigns und der Testfälle Qualität der Protokollierung der Testdurchführung Qualität des Fehlermanagements Testprozessmanagement Testprozessgestaltung Testprozessreife Testteamführung Anhang Anhang A: Testplan nach ANSI/IEEE Anhang B1: Schema für die Testfallspezifikation Anhang B2: Beispiel einer Testfallspezifikation für den Test der Auftragsbearbeitung Anhang C1: Testdatengenerierungsskript Anhang C2: Testergebnisvalidierungsskript Literatur Register...305

10 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 % 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.

11 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 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] 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).

12 2.1 Ansätze zur Formulierung der Anforderungen 23 Abbildung 2.1 Beispiel einer semiformalen Funktionsbeschreibung 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.

13 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

14 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] 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]

15 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

16 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 , 85 IEEE Standard IEEE Standard 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 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

17 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

18 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 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