Programmieren Spezifikation, Testen
Funktionen (beschreiben) Einschränkungen (meist zeitlich) - Performance Enviroment (Umgebung) nicht sollte drinnen stehen: l Platitüde (Leersatz- Sätze, die nichts aussagen) 37793lub33vse9i z.B: System sollte benutzerfreundlich sein; z.B: System sollte schnell sein. l Mehrdeutigkeiten (Ambiguity) z.B: „Ausgeben“ - Drucker oder am Bildschirm angezeigt. us793l7333vsse z.B: „Meistens“, „oft“, „im Normalfall“, „in Ausnahmefällen“ l Auslastungen (Omission) Wichtige Fälle, die eintreten können, müssen auch behandelt werden. z.B: Reaktion auf Fehlereingaben &- eingabeformat. l Implemention Directive Welche Programmiersprache verwendet wird, sollte so ausverhandelt werden, daß man selbst die Sprache bestimmen kann. l Benutzersprache Spezifikation soll so formuliert werden, daß der Kunde auch versteht worum es geht.
l OFF- ONE ERROR Schleife die 30x durchlaufen werden soll, aber nur 29x durchlaufen wird l DANGLING POINTER l DIVISION DURCH 0 l FALSCHER UP- AUFRUF Parameter werden falsch übergeben. l WERTEBEREICHSVERLETZUNG l IN FILES SCHREIBEN, DIE GARNICHT GEÖFFNET WERDEN.
Der Tester betrachtet das Programm als Blackbox ( -> Code ist uninteressant). Es wird überprüft, ob Spezifikation erfüllt wird. Bsp.: A ê B ê C ê ê Rechteck ê Allgemein ê Gleichseitig
Der Tester betrachtet den Programmcode. Test wird so aufgebaut, daß möglichst viele Programmteile getestet werden. Bsp.: A ê B ê C ê if (a<0) if (b>5) ...
ê Rechteck
3, 6, 7 3, 7, 8
è Äquivalenzkritärien
Es werden z.B: 200 Fehler bewußt eingebaut è Dann wird getestet. è Es werden z.B: 100 Fehler gefunden die in den bewußt eingebauten sind è dadurch kann man auf die verbleibenden Fehler schließen
Zwei Tester testen ein und dasselbe Programm. Je mehr sich die Fehler, die gefunden werden überschneiden, desto weniger Fehler sind noch vorhanden, wenn die nicht überschneidenden Fehler einen geringeren Anteil ausmachen. |