nicht angemeldet
Hallo!
Weiterhelfen groß kann ich nicht, aber Du scheinst ein wichtiges Gebiet bei der Fehlersuche vergessen zu haben: Mutwilligkeit und Sabotage. Also nicht nur die Funktionen mit realitätnahen Daten testen, sondern ebenso mit höchst unsinnigen. Etwa Datenfelder "überfüllen" oder mit Hexdaten und mit Steuersequenzen, oder 80x hintereinander vor und zurück klicken (gibts ein Überlauf in irgeneinem pointer etc?); was passiert, wenn man der Aufruf von Funktionen/Modulen von außen kommt, wenn Parameter per Hand verbogen werden; sind Zugriffe auf die DB von außen geschützt? auch mit alten Hexeditoren a la Norton? usw usf!
Vergessen habe ich das nicht. Das Web-Projekt ist nur über den Webserver erreichnbar, DB-Server ist nur intern erreichbar. Ich prüfe also immer wenn ich Parameter erwarte, ob diese den "Erwartungen" entsprechen. Nur das passiert so oft - wie soll ich die alle Testen? Und was soll ich dann testen? Was kann passieren?
Entweder erwarte ich einen von x verschiedenen Werten die genau definiert sind, das kann ich prüfen. Oder ich erwarte z.B. eine Zahl oder einen String mit max. x Stellen, oder einen Array mit entsprechenden Elementen.
Vor- und Zurück, auch ein interessanter Punkt, normalerweise schicke ich Formulare immer an "sich selbst", und überegebe am Ende die "alten" Parameter als GET-Parameter, so dass man normal hin- und zurück klicken kann. Nur ist das ja auch Broweser-spezifisch, die Reagieren ja nicht unbedingt alle gleich... ein interesanter Punkt den ich mir nochmal genauer ansehen werde.
Mit einem Hexeditor kann man wohl nicht wirklich viel ausrichten, da die Kommunikation eh nur über HTTP läuft und die Clients nur HTML-Ausgaben zu sehen bekommen.
Noch eine Sache - was macht man bei auftretenden Fehlern mit dem User? Gut, wenn es Eingabe-Fehler sind muss er halt korrigieren. Bei DB-Fehlern sieht es schon anders aus, vielleicht sollte man hier noch nach INSERTS/UPDATES und SELECTS unterscheiden?
Viele Grüße
Andreas