Ich habe vor über 25 Jahren einen Großteil von Testing Computer Software geschrieben. Ich habe seitdem auf einige Teile des Buches hingewiesen, die ich für veraltet oder einfach falsch halte. Siehe http://www.kaner.com/pdfs/TheOngoingRevolution.pdf
Weitere Informationen (aktuelle Ansichten, jedoch ohne ausdrücklichen Hinweis auf TCS) finden Sie auf meiner Website für den Black Box-Softwaretestkurs (Videos und Folien kostenlos verfügbar) unter www.testingeducation.org/BBST
Die damalige Testkultur war weitgehend bestätigend.
In modernen Tests ist der Ansatz für Komponententests weitgehend bestätigend - wir schreiben große Sammlungen automatisierter Tests, die lediglich überprüfen, ob die Software weiterhin die beabsichtigte Leistung erbringt. Die Tests dienen als Änderungsmelder - wenn etwas in anderen Teilen des Codes und in diesem Teil jetzt Probleme hat oder wenn Datenwerte, die früher in der realen Welt unmöglich waren, jetzt die Anwendung erreichen, werden die Änderungsmelder ausgelöst und alarmiert Programmierer auf ein Wartungsproblem.
Ich denke, die bestätigende Denkweise ist für Unit-Tests geeignet, aber stellen Sie sich eine Welt vor, in der alle Systemtests bestätigend waren (für Leute, die eine Unterscheidung treffen, interpretieren Sie bitte "Systemintegrationstests" und "Akzeptanztests", wie in meinen Kommentaren zum System enthalten Testen.) Der Zweck des Testens bestand darin, zu bestätigen, dass das Programm seinen Spezifikationen entsprach, und der vorherrschende Ansatz bestand darin, zig (oder zumindest einige hundert) Regressionstests auf Systemebene zu erstellen, mit denen Teile der Spezifikation Verhaltensweisen des Programms zugeordnet wurden. (Ich denke, die Bestätigung der Verhaltensspezifikation ist nützlich, aber ich denke, es ist ein kleiner Teil eines größeren Ziels.)
Es gibt immer noch Testgruppen, die so vorgehen, aber es ist nicht mehr die vorherrschende Ansicht. Damals war es. Ich schrieb nachdrücklich und zeichnete scharfe Kontraste, um auf Menschen hinzuweisen, die konsequent in dieser Denkweise geschult wurden. Einige der scharfen Kontraste (einschließlich des hier zitierten) sind heute veraltet. Sie werden als Angriffe auf die falschen Ansichten missverstanden.
Aus meiner Sicht ist das Testen von Software ein empirischer Prozess zum Erlernen qualitätsbezogener Informationen über ein Softwareprodukt oder eine Dienstleistung.
Ein Test sollte nützliche Informationen enthalten.
Damals sprach übrigens niemand davon, Tests als Methode zur Offenlegung von "Informationen" zu verwenden. Damals bestand das Testen entweder darin, (eine Version von ...) Fehler zu finden oder (eine Version von ...) das Programm anhand von Spezifikationen zu überprüfen (zu überprüfen). Ich glaube nicht, dass die Behauptung, Tests dienten dazu, nützliche Informationen preiszugeben, erst in diesem Jahrhundert in das Testvokabular aufgenommen wurde.
Stellen Sie sich Bewertungstests anhand ihres Informationswertes vor. Ein Test, der uns mit großer Wahrscheinlichkeit etwas beibringt, was wir nicht über die Software wissen, hätte einen sehr hohen Informationswert. Ein Test, der sehr wahrscheinlich etwas bestätigt, was wir bereits erwartet haben und der bereits viele Male zuvor demonstriert wurde, hätte einen geringen Informationswert. Eine Möglichkeit, Tests zu priorisieren, besteht darin, Tests mit höherem Informationswert vor Tests mit niedrigerem Informationswert durchzuführen.
Wenn ich diese Priorisierung zu stark vereinfachen würde, um die Aufmerksamkeit eines Programmierers, Projektmanagers oder Prozessmanagers auf sich zu ziehen, der keine Ahnung von Softwaretests hat, würde ich sagen: "EIN TEST, DER NICHT FÜR DIE ENTWICKLUNG EINES BUGS BESTIMMT IST, IST EINE ZEITVERLUST . " Es ist keine perfekte Übersetzung, aber für Leser, die keine Feinheiten oder Qualifikationen verstehen können oder wollen, ist das so nah wie möglich.
Damals, und ich sehe es hier wieder, haben einige Leute, die das Testen nicht verstehen, geantwortet, dass ein Test zum Auffinden von Eckfällen eine Zeitverschwendung ist, verglichen mit einem Test der Hauptnutzung einer Hauptfunktion. Sie verstehen zwei Dinge nicht. Erstens, bis die Zeittester Zeit finden, um Grenzwerte zu prüfen, wurden die Hauptverwendungen der Hauptfunktionen bereits mehrmals ausgeführt. (Ja, es gibt Ausnahmen, und die meisten Testgruppen werden diese Ausnahmen sorgfältig berücksichtigen.) Zweitens besteht der Grund für das Testen mit Extremwerten darin, dass das Programm mit größerer Wahrscheinlichkeit bei Extremwerten fehlschlägt. Wenn es nicht im Extremfall versagt, testen Sie etwas anderes. Dies ist eine effiziente Regel. Wenn es andererseits bei einem extremen Wert fehlschlägt, stoppt der Tester möglicherweise und meldet einen Fehler, oder der Tester führt eine weitere Fehlerbehebung durch. um zu sehen, ob das Programm bei normaleren Werten auf die gleiche Weise fehlschlägt. Wer diese Fehlerbehebung durchführt (Tester oder Programmierer), ist eine Frage der Unternehmenskultur. Einige Unternehmen planen die Zeit des Testers dafür ein, einige planen die Programmierer ein, und einige erwarten, dass Programmierer Eckfehler beheben, unabhängig davon, ob sie verallgemeinerbar sind oder nicht, sodass die Fehlerbehebung nicht relevant ist. Das verbreitete Missverständnis, dass Tester Zeit verschwenden (anstatt die Effizienz zu maximieren), indem sie Extremwerte testen, ist ein weiterer Grund dafür, dass "ein Test, der keinen Fehler aufdeckt, eine Zeitverschwendung ist", eine angemessene Botschaft für Tester ist. Dies ist ein Kontrapunkt zu der Aufforderung einiger Programmierer, (im Endeffekt) niemals Tests durchzuführen, die das Programm herausfordern könnten. Die Nachricht ist zu stark vereinfacht, aber die gesamte Diskussion ist zu stark vereinfacht.
Übrigens kann "Informationswert" nicht das einzige Priorisierungssystem sein. Es ist nicht meine Regel, wenn ich Komponententestsuiten entwerfe. Es ist nicht meine Regel, wenn ich Build-Verifikationstests entwerfe (auch bekannt als Sanity Checks). In beiden Fällen interessiert mich eher die Art der Berichterstattung als die Stärke der einzelnen Tests. Es gibt andere Fälle (z. B. hochvolumige automatisierte Tests, die kostengünstig einzurichten, auszuführen und zu überwachen sind), in denen die Leistung einzelner Tests für mein Design einfach irrelevant ist. Ich bin sicher, Sie können sich weitere Beispiele vorstellen.
Wenn ich jedoch nur eine Regel aufstellen könnte (z. B. mit einer Führungskraft sprechen, deren Kopf explodiert, wenn sie versucht, mehr als einen Satz zu verarbeiten), wäre ein Test mit niedrigem Informationswert in der Regel Zeitverschwendung.