Funktionen (beschreiben)
Einschränkungen (meist zeitlich) - Performance
Enviroment (Umgebung)
nicht sollte drinnen stehen:
l Platitüde (Leersatz- Sätze, die nichts aussagen)
z.B: System sollte benutzerfreundlich sein;
z.B: System sollte schnell sein.
l Mehrdeutigkeiten (Ambiguity)
z.B: "Ausgeben" - Drucker oder am Bildschirm angezeigt.
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.
Die besten Programmierer sollten Testen
Teste wie dein eigenes Programm
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
Aquivalenzkritä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.
Haupt | Fügen Sie Referat | Kontakt | Impressum | Nutzungsbedingungen
