Software-Test
Heise Medien (Verlag)
978-3-88229-198-8 (ISBN)
- Titel ist leider vergriffen;
keine Neuauflage - Artikel merken
Der Test der Software bleibt, auch fünfzig Jahre nach den ersten Computern, die
wichtigste Methode zur Sicherstellung der Qualität von Software. Verifikation und
Validation reicht allerdings in vielen Bereichen weit über den Test hinaus. Wer die
Qualität seiner Software verbessern und im Markt langfristig Erfolge erzielen will,
der kommt nicht darum herum, sich intensiv mit dem Test der Software zu
beschäftigen. Dazu bietet dieses Buch die unentbehrlichen Grundlagen.
Aus dem Inhalt:
- Prozessmodelle, Software-Spezifikation, Testplanung und -strategie, Fagan
Inspections und Code Walkthroughs
- Verifikation, Modultest, White Box Test, Testabdeckung, Incremental Testing
- Black Box Test, externe Testgruppe, Instrumentierung, Testabdeckung,
Systemtests, Volume und Stress Test, Recovery Testing, Mutationstest,
Benchmarks, Configuration, Compability und Usability Testing, Software für fremde
Kulturen, Test der Dokumentation; OO-Testing, Test einer Website, Test bei
sicherheitskritischer Software
- Software als Teil eines Systems: Analyse, Redundanz und Diversity
Die Neuauflage des Buches wurde durchgehend aktualisiert. Wesentlich erweitert
wuerde sie insbesondere bei den Themen:
- Test-Automation
- Management und Organisation: Debugging, Regression Testing, Werkzeuge.
Fehlerbewertung, -verfolgung und -beseitigung, objektive Kriterien für das
Testende, Freigabe-Politik
- Test und das CMM
Die Techniken und Methoden beim Test werden an einen durchgehenden Beispiel
in C erläutert, so dass es auch der Leser leicht einarbeiten kann, der vorher nicht
mit dem Test von Software befasst war. Das grundlegende Werk gehört auf den
Schreibtisch jedes Software-Fachmanns.
Softwarehäuser
Autor / Autorin:
Studium der Versorgungstechnik an der TU Berlin. Danach u.a. Aufbau der Abt.
Software-Test bei TRIUMPF ADLER. 1985 Wechsel zu DIEHL, wo er in einem
internationalen Projekt für die Software-Qualitätssicherung verantwortlich
zeichnete. Im Rahmen dieses transatlantischen Joint Ventures der
Hochtechnologie wurde das Qualitätssicherungssystem des Geschäftsbereichs
dokumentiert und später von den zuständigen Gremien anerkannt. Kurz darauf
erfolgte die Zertifizierung nach ISO 9001 durch die LGA Bayern.
Georg Erwin Thaller ist Mitglied in den wichtigsten internationalen Verbänden, die
sich mit Software Engineering und Qualitätssicherung befassen, darunter dem
Institute of Electrical & Electronical Engineers (IEEE) und der Association of
Computing Machinery (ACM). Er wurde in die New York Academy of Science
aufgenommen und ist Mitglied des American Institute of Aeronautics and
Astronautics (AIAA).
Inhaltsverzeichnis
Die Notwendigkeit zur Verifikation der Software 1
1.1 Die stille Revolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Das Risiko . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Der Zwang zu qualitativem Wachstum . . . . . . . . . . . . . . . . . . . . 15
1.4 Die Testverfahren im Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Die Softwareentwicklung als Prozess 21
2.1 Die Prozessmodelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2 Die Spezifikation als Grundlage für den Test . . . . . . . . . . . . . . . 29
2.3 Die Testplanung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.4 Die Notwendigkeit zur frühen Verifikation . . . . . . . . . . . . . . . . . 38
2.5 Die Verifikation ohne Computer . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.5.1 Fagan Inspections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.5.2 Walkthroughs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Die Verifikation der Software 49
3.1 Die Rolle des Tests im Lebenszyklus der Entwicklung . . . . . . . . 49
3.2 Die Abhängigkeit von Entwurf und Implementierung . . . . . . . . . 50
3.3 Top-down- versus Bottom-up-Strategie beim Test . . . . . . . . . . . 52
3.4 Der Modultest als White Box Test . . . . . . . . . . . . . . . . . . . . . . . . 59
3.5 Die Testabdeckung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.6 Incremental Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
3.7 Die Schwächen des White Box Tests . . . . . . . . . . . . . . . . . . . . . . 79
3.8 Die geeigneten Werkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Ein zweiter Ansatz: Black Box Test 81
4.1 Die Motivation der externen Testgruppe . . . . . . . . . . . . . . . . . . . 81
4.2 Bewährte Grundsätze beim Black Box Test . . . . . . . . . . . . . . . . 83
4.2.1 Equivalence Partitioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.2.2 Die Analyse von Grenzwerten . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
4.2.3 Error Guessing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
4.3 Die Instrumentierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
4.4 Vom Modul zum Programm . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
4.5 Die Testabdeckung auf Systemebene . . . . . . . . . . . . . . . . . . . . . 118
4.6 Gray Box Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Die Ausprägungen von Tests 121
5.1 Der Funktionstest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
5.2 Volume Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
5.3 Stress Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
5.4 Speicherverbrauch und Auslastung des Prozessors . . . . . . . . . . 129
5.5 Recovery Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
5.6 Der Mutationstest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
5.7 Benchmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
5.8 Der Test von Prozeduren und Verfahren . . . . . . . . . . . . . . . . . . 134
5.9 Configuration Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
5.10 Compability Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
5.10.1 Der Druckertest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
5.11 Usability Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
5.11.1 Usability Lab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
5.12 Software für fremde Kulturen und Sprachen . . . . . . . . . . . . . . . 156
5.13 Überprüfung von Dokumenten . . . . . . . . . . . . . . . . . . . . . . . . . . 159
5.14 Der Systemtest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Tests bei spezifischen Applikationen 165
6.1 Objektorientierte Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
6.2 Test einer Website . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
6.2.1 Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
6.2.2 Grafiken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
6.2.3 Formulare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
6.2.4 Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
6.2.5 Websites für Menschen mit Behinderungen . . . . . . . . . . . . . . . . 188
6.3 Sicherheitskritische Software . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
6.3.1 Cleanroom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
6.3.2 Independant Verification & Validation . . . . . . . . . . . . . . . . . . . . 193
6.3.3 Formale Methoden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Software und System 199
7.1 Unterschiede zwischen Hardware und Software . . . . . . . . . . . . . 200
7.2 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
7.2.1 Hazard Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
7.2.2 FMEA und FMECA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
7.3 Konstruktive Maßnahmen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
7.3.1 Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
7.3.2 Techniken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
7.4 Prozessmodelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
7.5 Redundanz und Diversity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
7.6 Normen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Test-Automation 225
8.1 Warum automatisieren? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
8.2 Beschaffung eines Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
8.3 Testen mit automatischen Tools . . . . . . . . . . . . . . . . . . . . . . . . . 235
8.4 Erfahrungen mit der Test-Automatisierung . . . . . . . . . . . . . . . . 239
Management und Organisation 245
9.1 Test im betrieblichen Rahmen . . . . . . . . . . . . . . . . . . . . . . . . . . 245
9.1.1 Nicht-technische Aspekte des Testens . . . . . . . . . . . . . . . . . . . . 246
9.1.2 Was macht den guten Tester aus? . . . . . . . . . . . . . . . . . . . . . . . 250
9.1.3 Wie findet man gute Tester? . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
9.1.4 Kunde und Anwender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
9.2 Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
9.2.1 Skalierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
9.3 Testplanung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
9.4 Fremdsoftware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
9.5 Einsatz von Werkzeugen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
9.6 Fehlerberichtigungssystem und Behandlung von Änderungen . 268
9.6.1 Konfigurationsmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
9.7 Debugging und Regression Test . . . . . . . . . . . . . . . . . . . . . . . . 278
9.7.1 Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
9.7.2 Regression Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
9.8 Metriken zum Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
9.8.1 Die zu erwartende Zahl der Fehler . . . . . . . . . . . . . . . . . . . . . . . 285
9.8.2 Kriterien für das Ende des Tests . . . . . . . . . . . . . . . . . . . . . . . . 287
9.9 Die Freigabepolitik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
9.9.1 Beta-Releases und Pilotkunden . . . . . . . . . . . . . . . . . . . . . . . . . 292
9.10 Wirksamkeit und Wirtschaftlichkeit . . . . . . . . . . . . . . . . . . . . . 294
9.11 Qualitätssicherung und Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
9.12 Das Risiko beherrschen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
Test und Capability Maturity Model 303
10.1 Capability Maturity Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
10.2 Test Maturity Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
Ausblick 323
Anhang 325
A.1 Literaturverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
A.2 Spezifikation: Kernfunktionen der Kalenderroutinen . . . . . . . . 329
A.3 Akronyme und Abkürzungen . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
A.4 Glossar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
A.5 Normen und Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
A.6 Produktmuster für den Testplan . . . . . . . . . . . . . . . . . . . . . . . . 349
A.7 Materialien: Fragebögen und Fehlervordruck . . . . . . . . . . . . . . 356
A.8 Grundriss eines Usability Labs . . . . . . . . . . . . . . . . . . . . . . . . . 374
A.9 Ressourcen im Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
A.10 Stichwortverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
Dipl.-Ing. Georg Erwin Thaller war zunächst in der Software-Entwicklung tätig, hat eine Testgruppe aufgebaut und war anschließend im Rahmen eines internationalen Joint Ventures in den USA für die Software-Qualitätssicherung verantwortlich. G. E. Thaller ist Mitglied im Institute of Electrical & Electronical Engineers (IEEE), der Association of Computing Machinery (ACM) und des American Institute of Aeronautics and Astronautics (AIAA). Seine Arbeit wurde 1992 durch Aufnahme seiner Biografie in das "Who s who in the World" gewürdigt. Zu den Themen Software, Qualität und Satellitentechnologie hat er ein Dutzend Fachbücher veröffentlicht. <<
1;Vorwort;6
2;Acknowledgements;9
3;Inhaltsverzeichnis;10
4;1 Die Notwendigkeit zur Verifikation der Software;14
4.1;1.1 Die stille Revolution;16
4.2;1.2 Das Risiko;17
4.3;1.3 Der Zwang zu qualitativem Wachstum;28
4.4;1.4 Die Testverfahren im Überblick;31
5;2 Die Softwareentwicklung als Prozess;34
5.1;2.1 Die Prozessmodelle;34
5.2;2.2 Die Spezifikation als Grundlage für den Test;42
5.3;2.3 Die Testplanung;48
5.4;2.4 Die Notwendigkeit zur frühen Verifikation;51
5.5;2.5 Die Verifikation ohne Computer;52
6;3 Die Verifikation der Software;62
6.1;3.1 Die Rolle des Tests im Lebenszyklus der Entwicklung;62
6.2;3.2 Die Abhängigkeit von Entwurf und Implementierung;63
6.3;3.3 Top-down- versus Bottom-up- Strategie beim Test;65
6.4;3.4 Der Modultest als White Box Test;72
6.5;3.5 Die Testabdeckung;82
6.6;3.6 Incremental Testing;87
6.7;3.7 Die Schwächen des White Box Tests;92
6.8;3.8 Die geeigneten Werkzeuge;93
7;4 Ein zweiter Ansatz: Black Box Test;94
7.1;4.1 Die Motivation der externen Testgruppe;94
7.2;4.2 Bewährte Grundsätze beim Black Box Test;96
7.3;4.3 Die Instrumentierung;111
7.4;4.4 Vom Modul zum Programm;118
7.5;4.5 Die Testabdeckung auf Systemebene;131
7.6;4.6 Gray Box Testing;132
8;5 Die Ausprägungen von Tests;134
8.1;5.1 Der Funktionstest;135
8.2;5.2 Volume Test;137
8.3;5.3 Stress Test;141
8.4;5.4 Speicherverbrauch und Auslastung des Prozessors;142
8.5;5.5 Recovery Testing;142
8.6;5.6 Der Mutationstest;143
8.7;5.7 Benchmarks;144
8.8;5.8 Der Test von Prozeduren und Verfahren;147
8.9;5.9 Configuration Testing;148
8.10;5.10 Compability Testing;152
8.11;5.11 Usability Testing;157
8.12;5.12 Software für fremde Kulturen und Sprachen;169
8.13;5.13 Überprüfung von Dokumenten;172
8.14;5.14 Der Systemtest;175
9;6 Tests bei spezifischen Applikationen;178
9.1;6.1 Objektorientierte Software;178
9.2;6.2 Test einer Website;187
9.3;6.3 Sicherheitskritische Software;203
10;7 Software und System;212
10.1;7.1 Unterschiede zwischen Hardware und Software;213
10.2;7.2 Analyse;217
10.3;7.3 Konstruktive Maßnahmen;222
10.4;7.4 Prozessmodelle;230
10.5;7.5 Redundanz und Diversity;232
10.6;7.6 Normen;234
11;8 Test-Automation;238
11.1;8.1 Warum automatisieren?;238
11.2;8.2 Beschaffung eines Tools;245
11.3;8.3 Testen mit automatischen Tools;248
11.4;8.4 Erfahrungen mit der Test- Automatisierung;252
12;9 Management und Organisation;258
12.1;9.1 Test im betrieblichen Rahmen;258
12.2;9.2 Organisation;267
12.3;9.3 Testplanung;272
12.4;9.4 Fremdsoftware;275
12.5;9.5 Einsatz von Werkzeugen;278
12.6;9.6 Fehlerberichtigungssystem und Behandlung von Änderungen;281
12.7;9.7 Debugging und Regression Test;291
12.8;9.8 Metriken zum Test;298
12.9;9.9 Die Freigabepolitik;304
12.10;9.10 Wirksamkeit und Wirtschaftlichkeit;307
12.11;9.11 Qualitätssicherung und Test;312
12.12;9.12 Das Risiko beherrschen;313
13;10 Test und Capability Maturity Model;316
13.1;10.1 Capability Maturity Model;316
13.2;10.2 Test Maturity Model;331
14;11 Ausblick;336
15;Anhang;338
15.1;A.1 Literaturverzeichnis;338
15.2;A.2 Spezifikation: Kernfunktionen der Kalenderroutinen;342
15.3;A.3 Akronyme und Abkürzungen;348
15.4;A.4 Glossar;351
15.5;A.5 Normen und Standards;358
15.6;A.6 Produktmuster für den Testplan;362
15.7;A.7 Materialien: Fragebögen und Fehlervordruck;369
15.8;A.8 Grundriss eines Usability Labs;387
15.9;A.9 Ressourcen im Internet;388
15.10;A.10 Stichwortregister;390
4 Ein zweiter Ansatz: Black Box Test (S. 81-82) Prüfe die Brücke, die dich tragen soll. Sprichwort Neben dem White Box Test, der seit den Anfangstagen der Programmierung bekannt ist, steht gleichwertig der Black Box Test. Sein Ansatz ist verschieden vom White Box Test, und das bezieht sich vor allem auf die Person des Testers. 4.1 Die Motivation der externen Testgruppe Wir sind bisher wie selbstverständlich immer davon ausgegangen, dass der Entwurf, das Kodieren und der anschließende Test von ein und derselben Person durchgeführt wird. Tatsächlich muss das nicht so sein; es sprechen eine ganze Reihe guter Gründe dafür, die Arbeit anders zu organisieren. Viele Organisationen haben mit wichtigen Projekten Schiffbruch erlitten, weil sie konstruktive und analytische Tätigkeiten nicht sauber voneinander getrennt haben. Lassen Sie mich zu diesem Punkt Tom DeMarco [29] zitieren. Ich könnte es mit meinen eigenen Worten nicht besser sagen. "Ganz zu Beginn des Computerzeitalters gab es einmal im Bundesstaat New York eine Firma, die große blaue Computer baute. Sie lieferte auch gleich die passende Software dazu. Die Kunden dieser Firma waren recht nette Leute, aber sie konnten ganz schön böse werden, wenn fehlerhafte Programme ausgeliefert wurden. Eine Weile konzentrierte sich unser Konzern mit den blauen Computern darauf, die Kunden zu mehr Toleranz gegenüber fehlerhaften Programmen zu erziehen. Als das nichts fruchtete, entschloss man sich schließlich, den Fehlern in der Software auf den Leib zu rücken. Der einfachste und offensichtliche Weg bestand darin, die Programmierer dazu zu bringen, vor der Auslieferung des Codes alle Fehler auszumerzen. Das funktionierte allerdings nicht. Aus irgendwelchen Gründen schienen die Programmierer - zumindest damals - daran zu glauben, dass ihre Programme keine Fehler hätten. Sie gaben ihr Möglichstes, aber den wirklich letzten Fehler zu finden war schwierig. Einige Programmierer schienen der gestellten Aufgabe allerdings besser gewachsen zu sein als andere Kollegen. Die Firma fasste diese Gruppe zusammen und stellte ihr die explizite Aufgabe, die Software vor der Auslieferung an die Kunden zu testen. Das Schwarze Team war geboren. Dieses Team bestand ursprünglich aus Leuten, die im Testen von Software etwas besser waren als andere. Sie waren auch besser motiviert: Da sie den Programmcode nicht selber geschrieben hatten, hatten sie keine Angst vor gründlichen Tests." Das Schwarze Team wurde im Lauf der Zeit immer besser. Sie erwarteten Fehler in der Software und waren entschlossen, sie aufzudecken. Sie standen in Opposition zum Schreiber des Programms. Die von ihnen ausgeheckten Tests waren ausgeklügelt, oft zerstörerisch und schwer zu bestehen. Die Mitglieder der Gruppe begannen, sich ganz in Schwarz zu kleiden. Es galt bald als eine Ehre, zum Schwarzen Team zu gehören. Fast unnötig zu sagen, dass die Firmenleitung begeistert war. Jeder gefundene Fehler war ein Defekt, den die Kunden nicht finden konnten. Das sparte viel Geld, das sonst für Wartung und Kundendienst hätte aufgewendet werden müssen. Manche Mitglieder verließen das Schwarze Team, doch sie wurden immer sofort wieder ersetzt. Die externe Testgruppe hatte sich innerhalb der Firma etabliert. Es ist nicht zu leugnen, dass viele Menschen eine Hemmschwelle haben, wenn es um eigene Fehler geht. Den Balken im eigenen Auge sehen wir eben nicht. Warum sollte das bei Programmierern anders sein? Es ist also durchaus sinnvoll, nach dem Test durch den ursprünglichen Entwickler, etwa in der Form eines White Box Tests, den zweiten Schritt zu tun und das Programm einer externen Testgruppe zu übergeben. Das Wort extern bedeutet dabei außerhalb der Gruppe, die innerhalb der Firma für den Entwurf und dessen Implementierung verantwortlich ist. Black Box Test bedeutet, dass der Tester den Programmcode lediglich nach der Funktion beurteilt.
| Sprache | deutsch |
|---|---|
| Maße | 165 x 240 mm |
| Gewicht | 660 g |
| Einbandart | Paperback |
| Themenwelt | Informatik ► Software Entwicklung ► Qualität / Testen |
| Schlagworte | HC/Informatik, EDV/Informatik • Software-Test |
| ISBN-10 | 3-88229-198-2 / 3882291982 |
| ISBN-13 | 978-3-88229-198-8 / 9783882291988 |
| Zustand | Neuware |
| Haben Sie eine Frage zum Produkt? |
aus dem Bereich
