Nachdem ich viel über dieses Thema gelesen habe - wie auf dieser Website mit den Grundlagen des Softwaretests zu Verifizierung und Validierung sowie zum Testen und zur Qualitätssicherung von Software: Theorie und Praxis von Naik und Tripathy - verstehe ich es immer noch nicht. Die Überprüfung sollte beweisen, dass Sie das richtige Produkt erstellen, während die Überprüfung nachweist, dass Sie das richtige Produkt erstellt haben. Als Verifizierungsmethoden werden jedoch nur statische Techniken (Codeüberprüfungen, Anforderungsprüfungen ...) genannt. Wie können Sie sagen, ob es korrekt implementiert ist, wenn Sie es nicht testen? Es wird gesagt, dass die Überprüfung sicherstellt, dass das Produkt die festgelegten Anforderungen erfüllt. Auch hier kann ich nur durch Testen sagen, dass die Funktion irgendwie funktioniert.
Könnte mir das bitte jemand erklären?
quelle
Antworten:
Da diese Frage einige Kontroversen hervorrief, möchte ich diese Antwort mit meinem Hintergrund beginnen: Abgesehen davon, dass ich in der täglichen Projektarbeit mit V & V in Berührung gekommen bin, habe ich mehrere Jahre in der Software-Engineering-Abteilung meiner Alma Mater gearbeitet und bin Dozent für Software-Engineering. Dies garantiert zwar nicht, dass alles, was ich sage, richtig ist, aber ich hoffe, es gibt mir zumindest den Vorteil des Zweifels, dass diese Antwort etwas Wahres enthalten könnte.
Lassen Sie mich Ihnen versichern, dass Sie nicht so verwirrt sind, wie Sie vielleicht glauben. Was Sie in Ihrer Frage angegeben haben, ist ebenso wahr wie irreführend. Lassen Sie mich zunächst darauf hinweisen, was Sie richtig angegeben haben:
Lassen Sie mich jetzt die Verwirrung über das Testen beseitigen . Erstens ist, wie in vielen Kommentaren bereits erwähnt, das dynamische Testen von Code über automatisierte Tests (Einheit, Integration, ...) tatsächlich Teil der Überprüfung. Was jedoch die meiste Verwirrung stiftet, ist, dass Personen in der Validierung auch über das Testen sprechen , aber etwas anderes bedeuten: Bei der Validierung bezieht das Testen normalerweise eine Person mit ein, die die Anwendung für den beabsichtigten Zweck verwendet. Im optimalen Fall ist dies der Kunde selbst.
Die "Fehler" [1], die beim Testen bei der Verifizierung und Validierung festgestellt wurden, unterscheiden sich jedoch grundlegend:
Für die meisten Menschen ist es hilfreich, konkrete Beispiele für verschiedene V & V-Fälle zu betrachten. Das Folgende sind extreme Beispiele für Fehler:
Sie haben eine Anforderung auf niedriger Ebene, dass "f (x) x + 1" zurückgeben soll und Ihre Implementierung von "f" immer die Konstante 2 zurückgibt. Sie können diesen Fehler durch verschiedene Überprüfungsansätze finden, aber Ihr Kunde hat wahrscheinlich gewonnen. ' Ich finde es nicht während der Validierung, weil Sie eine E-Shopping-Site erstellen und er "f" weder kennt noch sich darum kümmert.
Sie haben die Anforderung "Das System sollte in der Lage sein, 1000 Anforderungen pro Sekunde bei einer CPU-Auslastung von maximal 80% zu verarbeiten". Auch hier wird die Validierung genauso schwierig sein wie die meisten statischen Techniken. Der einfachste Weg, dies zu überprüfen, besteht darin, Ihre Anwendung dynamisch zu testen, indem Sie sie mit Anforderungen versehen und Ihre CPU-Auslastung während dieser Zeit überwachen.
Betrachten Sie die obige Anforderung für "f" noch einmal, diesmal mit einer "korrekten" Implementierung. Alle Ihre Bewertungen, statischen Analysen und dynamischen Tests werden einen Erfolg melden, aber dann testet Ihr Kunde Ihre Software und teilt Ihnen mit, dass er das Warenkorbsymbol auf der Webseite vermisst. Kein Überprüfungsbetrag kann diesen Fehler finden, wie Sie ihn in der Anforderungsphase gemacht haben.
Wie Sie sehen können, ist "Testen" - sofern nicht genauer definiert - Teil der Verifizierung und Validierung, und tatsächlich sollte "Testen" für beide durchgeführt werden.
[1] "Fehler" wird hier umgangssprachlich verwendet, um die Unterscheidung zwischen Fehler, Fehler, Fehler, Fehler, ... zu vermeiden.
quelle
The code implements proper event sequence, consistent interfaces, correct data and control flow, completeness, appropriate allocation timing and sizing budgets, and error definition, isolation, and recovery.undThe software components and units of each software item have been completely and correctly integrated into the software item--- wie würden Sie eines dieser Dinge tun, ohne es zu testen?In der Tat: Die Überprüfung beweist, dass Sie das richtige Produkt erstellen, während die Validierung das richtige Produkt erstellt.
Deshalb
Normalerweise zitiere ich Wikipedia nicht , aber in diesem Fall ist es hilfreich ...
Eine detailliertere Erläuterung der beiden Prozesse finden Sie in ISO 12207 Software Life Cycle Processes (eine der anderen Antworten enthält einen Link zu einer unkontrollierten Kopie):
7.2.4.3.2 Überprüfungsaufgaben
7.2.5.3.2 Validierungsaufgaben
In der ersten Frage wurde nun gefragt, warum die Überprüfung keine Tests umfasst. Und trotz einiger anderer Antworten von P.SE-Mitgliedern mit hohem Ansehen habe ich Ihnen gesagt, dass dies nicht der Punkt der Verifizierungsaktivität ist, sondern der Validierungsaktivität .
Einige Antworten deuten darauf hin , dass Sie haben Code oder Integration zu testen , um zu überprüfen. Nein - diese Aktivität dient dazu, die Modularität und die Schnittstellen usw. zu beweisen, nicht die Ausführung.
Diese Diskussion zeigt im Wesentlichen, dass es große Verwirrung darüber gibt, was Verifikation und was Validierung ist , und dies wird nicht dadurch unterstützt, dass die Grenze eine Grauzone ist und in verschiedenen Standards leicht unterschiedlich definiert ist.
Wichtig ist, dass beide Teile von V & V abgedeckt werden, und solange dies semantisch der Fall ist, spielt es keine Rolle, ob es sich um V oder V handelt ... nur um V und V.
quelle