|
Funktionen (beschreiben)
Einschränkungen (meist zeitlich) - Performance
Enviroment (Umgebung)
nicht sollte drinnen stehen:
Platitüde (Leersatz- Sätze, die nichts aussagen)
z.B: System sollte benutzerfreundlich sein;
z.B: System sollte schnell sein.
Mehrdeutigkeiten (Ambiguity)
z.B: "Ausgeben" - Drucker oder am Bildschirm angezeigt.
z.B: "Meistens", "oft", "im Normalfall", "in Ausnahmefällen"
Auslastungen (Omission)
Wichtige Fälle, die eintreten können, müssen auch behandelt werden.
z.B: Reaktion auf Fehlereingaben &- eingabeformat.
Implemention Directive
Welche Programmiersprache verwendet wird, sollte so ausverhandelt werden, daß man selbst die Sprache bestimmen kann.
Benutzersprache
Spezifikation soll so formuliert werden, daß der Kunde auch versteht worum es geht.
2 Testen
1. Die besten Programmierer sollten Testen
2. Teste wie dein eigenes Programm
2.1 Typische Fehler
OFF- ONE ERROR
Schleife die 30x durchlaufen werden soll, aber nur 29x durchlaufen wird
DANGLING POINTER
DIVISION DURCH 0
FALSCHER UP- AUFRUF
Parameter werden falsch übergeben.
WERTEBEREICHSVERLETZUNG
IN FILES SCHREIBEN, DIE GARNICHT GEÖFFNET WERDEN.
2.2 Testarten
2.2.1 Blackboxtests
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
2.2.2 Whitebox
Der Tester betrachtet den Programmcode.
Test wird so aufgebaut, daß möglichst viele Programmteile getestet werden.
Bsp.:
A B C
Rechteck
2.2.3 Strategie (keine ähnlichen Testfälle sind zu verwenden !)
Äquivalenzkritärien
2.2.4 Seeding
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
2.2.5 Zwei Tester
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.
|
