Softwareüberprüfung. Test der BKU und ihrer Software an nichtkommerziellen Organisationen. Bei der Verifizierung handelt es sich um den Prozess der Überprüfung eines Softwareprodukts

Der Zweck dieses Kurses besteht darin, einen umfassenden Überblick über den Softwareverifizierungsprozess zu vermitteln. Gegenstand der Diskussion sind verschiedene Ansätze und Methoden im Bereich der Verifikation und insbesondere des Softwaretests. Es wird davon ausgegangen, dass die zu entwickelnde Software Teil eines allgemeineren Systems ist. Ein solches System umfasst Hardware-, Informations- und Organisationskomponenten (menschlicher Benutzer, menschlicher Bediener usw.), die möglicherweise von verschiedenen Teams entwickelt wurden. Daher sind Entwicklungsdokumente erforderlich, die die Anforderungen an die verschiedenen Komponenten des Systems und die Regeln für deren Zusammenspiel definieren. Darüber hinaus wird davon ausgegangen, dass Systemausfälle zu Folgen unterschiedlicher Schwere führen können. Daher sind bei der Softwareentwicklung Anstrengungen zur Identifizierung versteckter Mängel notwendig und gerechtfertigt. Dies betrifft zunächst Tools und Verfahren zur Softwareverifizierung. Der Kurs umfasst eine Reihe praktischer Übungen, die am Beispiel eines einfachen Systems die Techniken und Methoden der Softwareverifizierung in der Umgebung von Microsoft Visual Studio 2005 Team Edition für Softwaretester veranschaulichen. Diese Veröffentlichung ist Teil der Kursbibliothek, die im Rahmen des akademischen Kooperationsprogramms der MSDN Academic Alliance (MSDN AA) entwickelt wird.

Der folgende Text wird durch automatische Extraktion aus dem Original-PDF-Dokument gewonnen und dient als Vorschau.
Es sind keine Bilder (Bilder, Formeln, Grafiken) vorhanden.

Reis. 7 Testen, Verifizieren und Validieren Software-Verifizierung ist ein allgemeineres Konzept als Testen. Der Zweck der Verifizierung besteht darin, sicherzustellen, dass das zu verifizierende Element (Anforderungen oder Programmcode) die Anforderungen erfüllt, ohne unbeabsichtigte Funktionen implementiert wird und Designspezifikationen und -standards erfüllt. Der Verifizierungsprozess umfasst Inspektionen, Codetests, Analyse der Testergebnisse sowie die Erstellung und Analyse von Problemberichten. Daher ist es allgemein anerkannt, dass der Testprozess ein integraler Bestandteil des Verifizierungsprozesses ist, und in diesem Schulungskurs wird von derselben Annahme ausgegangen. Die Validierung eines Softwaresystems ist ein Prozess, dessen Zweck darin besteht, nachzuweisen, dass wir durch die Entwicklung des Systems die Ziele erreicht haben, die wir durch seine Verwendung erreichen wollten. Mit anderen Worten: Bei der Validierung wird überprüft, ob das System den Erwartungen des Kunden entspricht. Fragen im Zusammenhang mit der Validierung gehen über den Rahmen dieser Schulung hinaus und stellen ein separates interessantes Studienthema dar. Betrachtet man diese drei Prozesse im Hinblick auf die Frage, die sie beantworten, beantwortet das Testen die Frage „Wie wird es durchgeführt?“ oder „Entspricht das Verhalten des entwickelten Programms den Anforderungen?“, Überprüfung – „Was wurde getan?“ oder „Erfüllt das entwickelte System die Anforderungen?“ und die Validierung lautet „Hat es getan, was es tun musste?“ oder „Entspricht das entwickelte System den Erwartungen des Kunden?“ 1.7. Dokumentation, die in verschiedenen Phasen des Lebenszyklus erstellt wird. Die Synchronisierung aller Entwicklungsstadien erfolgt mithilfe von Dokumenten, die in jeder Phase erstellt werden. Dabei erfolgt die Dokumentation sowohl für den direkten Abschnitt des Lebenszyklus – während der Entwicklung eines Softwaresystems, als auch umgekehrt – während seiner Verifizierung. Versuchen wir am Beispiel eines V-förmigen Lebenszyklus nachzuzeichnen, welche Arten von Dokumenten in den einzelnen Segmenten erstellt werden und welche Beziehungen zwischen ihnen bestehen (Abb. 8). Das Ergebnis der Phase der Entwicklung von Systemanforderungen sind die formulierten Anforderungen an das System – ein Dokument, das die allgemeinen Funktionsprinzipien des Systems, seine Interaktion mit der „Umgebung“ – den Benutzern des Systems – sowie die darin enthaltene Software und Hardware beschreibt den Betrieb sicherstellen. Typischerweise wird parallel zu den Systemanforderungen ein Verifizierungsplan erstellt und eine Verifizierungsstrategie definiert. Diese Dokumente definieren den allgemeinen Ansatz, wie Tests durchgeführt werden, welche Techniken verwendet werden und welche Aspekte des zukünftigen Systems gründlich getestet werden müssen. Eine weitere Aufgabe, die durch die Definition einer Verifizierungsstrategie gelöst wird, besteht darin, den Standort verschiedener Verifizierungsprozesse und ihre Verbindungen zu Entwicklungsprozessen zu bestimmen. 20 Der Verifizierungsprozess mit Systemanforderungen ist der Prozess, bei dem Anforderungen validiert und mit den tatsächlichen Erwartungen des Kunden verglichen werden. Nehmen wir für die Zukunft an, dass sich der Validierungsprozess von den Abnahmetests unterscheidet, die bei der Übergabe des fertigen Systems an den Kunden durchgeführt werden, obwohl er als Teil solcher Tests betrachtet werden kann. Die Validierung ist ein Mittel, um nicht nur die Korrektheit der Systemimplementierung aus Sicht des Kunden nachzuweisen, sondern auch die Korrektheit der seiner Entwicklung zugrunde liegenden Prinzipien. Reis. 8 Prozesse und Dokumente bei der Entwicklung von Softwaresystemen Systemanforderungen sind die Grundlage für den Prozess der Entwicklung funktionaler Anforderungen und der Projektarchitektur. Dabei werden allgemeine Anforderungen an die Systemsoftware und die von ihr auszuführenden Funktionen entwickelt. Zu den funktionalen Anforderungen gehören häufig die Definition von Systemverhaltensmustern in normalen und abnormalen Situationen, Regeln für die Datenverarbeitung und Definitionen der Benutzeroberfläche. Der Anforderungstext enthält in der Regel die Worte „müssen, müssen“ und hat den Aufbau der Form „Erreicht der Temperaturwert am ABC-Sensor 30 Grad Celsius oder mehr, muss das System die Ausgabe eines Audiosignals einstellen.“ ” Funktionale Anforderungen sind die Grundlage für die Entwicklung der Systemarchitektur – sie beschreiben ihre Struktur in Form von Subsystemen und Struktureinheiten der Sprache, in der die Implementierung durchgeführt wird – Bereiche, Klassen, Module, Funktionen usw. Basierend auf den funktionalen Anforderungen werden Testanforderungen geschrieben – Dokumente, die die Definition zentraler Punkte enthalten, die überprüft werden müssen, um die korrekte Umsetzung der funktionalen Anforderungen sicherzustellen. Testanforderungen beginnen oft mit den Worten „Test That“ und enthalten Verweise auf die entsprechenden funktionalen Anforderungen. Ein Beispiel für Testanforderungen für die oben genannte Funktionsanforderung wäre „Überprüfen Sie, ob das System einen Warnton ausgibt, wenn die Temperatur am ABC-Sensor unter 30 Grad Celsius fällt“ und „Überprüfen Sie, ob der Temperaturwert am ABC-Sensor über 30 Grad Celsius liegt.“ Grad Celsius“ erzeugt das System kein akustisches Signal. 21 Eines der Probleme, die beim Schreiben von Testanforderungen auftreten, ist die grundsätzliche Untestbarkeit einiger Anforderungen. Beispielsweise kann die Anforderung „Die Benutzeroberfläche muss intuitiv sein“ nicht überprüft werden, ohne eine klare Definition dessen, was eine intuitive Benutzeroberfläche ausmacht. Solche unspezifischen Funktionsanforderungen werden in der Regel nachträglich geändert. Die Architekturmerkmale des Systems können auch als Quelle für die Erstellung von Testanforderungen dienen, die die Merkmale der Softwareimplementierung des Systems berücksichtigen. Ein Beispiel für eine solche Anforderung ist beispielsweise: „Überprüfen Sie, dass der Temperaturwert am ABC-Sensor 255 nicht überschreitet.“ Basierend auf den funktionalen Anforderungen und der Architektur wird der Systemcode geschrieben und zu seiner Verifizierung ein Testplan auf Basis der Testanforderungen erstellt – eine Beschreibung der Abfolge von Testfällen, die die Übereinstimmung der Systemimplementierung mit den Anforderungen überprüfen. Jeder Testfall enthält eine spezifische Beschreibung der am Systemeingang bereitgestellten Werte, der am Ausgang erwarteten Werte und eine Beschreibung des Testausführungsszenarios. Abhängig vom Testobjekt kann der Testplan entweder in Form eines Programms in einer Programmiersprache oder in Form einer Eingabedatendatei für das Toolkit erstellt werden, das das zu testende System ausführt und ihm die Werte überträgt im Testplan festgelegt oder in Form von Anweisungen für das Benutzersystem, die die notwendigen Aktionen beschreiben, die zum Testen der verschiedenen Funktionen des Systems durchgeführt werden müssen. Als Ergebnis der Ausführung aller Testfälle werden Statistiken über den Testerfolg gesammelt – der Prozentsatz der Testfälle, bei denen die tatsächlichen Ausgabewerte mit den erwarteten übereinstimmten, die sogenannten bestandenen Tests. Fehlgeschlagene Tests sind Ausgangsdaten zur Analyse der Fehlerursachen und deren anschließender Behebung. In der Integrationsphase werden einzelne Systemmodule zu einem Ganzen zusammengefügt und Testfälle ausgeführt, die die gesamte Funktionalität des Systems überprüfen. Im letzten Schritt wird das fertige System an den Kunden geliefert. Vor der Implementierung führen Kundenspezialisten gemeinsam mit Entwicklern Abnahmetests durch – sie überprüfen für den Benutzer kritische Funktionen gemäß einem vorab genehmigten Testprogramm. Bei erfolgreichem Abschluss der Tests wird das System an den Kunden übergeben, andernfalls wird es zur Überarbeitung geschickt. 1.8. Arten von Test- und Verifizierungsprozessen und ihre Stellung in verschiedenen Lebenszyklusmodellen 1.8.1. Unit-Tests Kleine Module (Prozeduren, Klassen usw.) unterliegen Unit-Tests. Beim Testen eines relativ kleinen Moduls mit einer Größe von 100–1000 Zeilen ist es möglich, wenn nicht alle, dann zumindest viele logische Zweige in der Implementierung, unterschiedliche Pfade im Datenabhängigkeitsdiagramm und Grenzwerte von Parametern zu überprüfen. Dementsprechend werden Testabdeckungskriterien konstruiert (alle Operatoren, alle logischen Zweige, alle Grenzpunkte usw. werden abgedeckt). . Unit-Tests werden normalerweise für jedes unabhängige Softwaremodul durchgeführt und sind möglicherweise die häufigste Testart, insbesondere für kleine bis mittelgroße Systeme. 1.8.2. Integrationstests Die Überprüfung der Korrektheit aller Module garantiert leider nicht die korrekte Funktion des Modulsystems. In der Literatur wird manchmal das „klassische“ Modell der unsachgemäßen Organisation des Testens eines Modulsystems diskutiert, das oft als „Methode des großen Sprungs“ bezeichnet wird. Der Kern der Methode besteht darin, zunächst jedes Modul einzeln zu testen, sie dann zu einem System zu kombinieren und das gesamte System zu testen. Für große Systeme ist dies unrealistisch. Bei diesem Ansatz wird viel Zeit für die Fehlerlokalisierung aufgewendet und die Testqualität bleibt gering. Eine Alternative zum „großen Sprung“ sind Integrationstests, bei denen das System schrittweise aufgebaut wird und nach und nach Gruppen von Modulen hinzugefügt werden. 1.8.3. Systemtest Ein vollständig implementiertes Softwareprodukt unterliegt einem Systemtest. In diesem Stadium geht es für den Tester nicht um die korrekte Umsetzung einzelner Verfahren und Methoden, sondern um das gesamte Programm als Ganzes, wie es der Endanwender sieht. Die Tests basieren auf allgemeinen Anforderungen an das Programm, darunter nicht nur die korrekte Implementierung von Funktionen, sondern auch Leistung, Reaktionszeit, Widerstandsfähigkeit gegen Ausfälle, Angriffe, Benutzerfehler usw. Für System- und Komponententests werden bestimmte Arten von Testabdeckungskriterien verwendet (z. B. werden alle typischen Arbeitsszenarien abgedeckt, alle Szenarien mit Ausnahmesituationen, paarweise Zusammenstellungen von Szenarien usw.). 1.8.4. Lasttests liefern nicht nur prädiktive Daten zur Systemleistung unter Last, die als Grundlage für Architekturentscheidungen dienen, sondern liefern auch Betriebsinformationen für technische Supportteams sowie Projekt- und Konfigurationsmanager, die für die Erstellung der produktivsten Hardware- und Softwarekonfigurationen verantwortlich sind. Durch Lasttests kann das Entwicklungsteam fundiertere Entscheidungen treffen, die auf die Entwicklung optimaler Architekturkompositionen abzielen. Der Kunde erhält seinerseits die Möglichkeit, Abnahmetests unter realitätsnahen Bedingungen durchzuführen. 1.8.5. Formale Inspektionen Die formale Inspektion ist eine der Möglichkeiten, Dokumente und Programmcode zu überprüfen, die während des Softwareentwicklungsprozesses erstellt werden. Bei einer formellen Prüfung überprüft ein Team von Spezialisten selbstständig die Übereinstimmung der geprüften Dokumente mit den Originaldokumenten. Die Unabhängigkeit der Prüfung wird dadurch gewährleistet, dass sie von Prüfern durchgeführt wird, die nicht an der Entwicklung des zu prüfenden Dokuments beteiligt waren. 1.9. Verifizierung zertifizierter Software Lassen Sie uns einige Definitionen geben, die die allgemeine Struktur des Software-Zertifizierungsprozesses definieren: Bei der Software-Zertifizierung handelt es sich um den Prozess der Feststellung und offiziellen Anerkennung, dass die Softwareentwicklung in Übereinstimmung mit bestimmten Anforderungen durchgeführt wurde. Während des Zertifizierungsprozesses findet eine Interaktion zwischen dem Antragsteller, der Zertifizierungsstelle und der Aufsichtsstelle statt. Der Antragsteller ist eine Organisation, die bei der zuständigen Zertifizierungsstelle einen Antrag auf Erhalt eines Zertifikats (über Konformität, Qualität, Eignung usw.) stellt Produkt. Die Zertifizierungsstelle ist eine Organisation, die den Antrag des Antragstellers auf Softwarezertifizierung prüft und entweder unabhängig oder durch Bildung einer Sonderkommission eine Reihe von Verfahren durchführt, die auf die Durchführung des Softwarezertifizierungsprozesses des Antragstellers abzielen. 23 Aufsichtsbehörde – eine Kommission von Spezialisten, die die Entwicklungsprozesse des zertifizierten Informationssystems des Antragstellers überwacht und eine Stellungnahme zur Übereinstimmung dieses Prozesses mit bestimmten Anforderungen abgibt, die der Zertifizierungsstelle zur Prüfung vorgelegt wird. Die Zertifizierung kann auf den Erhalt eines Konformitätszertifikats oder eines Qualitätszertifikats abzielen. Im ersten Fall ist das Ergebnis der Zertifizierung die Anerkennung der Übereinstimmung von Entwicklungsprozessen mit bestimmten Kriterien und der Funktionalität des Systems mit bestimmten Anforderungen. Ein Beispiel für solche Anforderungen sind die Leitliniendokumente des Föderalen Dienstes für technische Kontrolle und Exportkontrolle im Bereich der Sicherheit von Softwaresystemen. Im zweiten Fall ist das Ergebnis die Anerkennung der Übereinstimmung von Entwicklungsprozessen mit bestimmten Kriterien, die ein angemessenes Qualitätsniveau des hergestellten Produkts und seine Eignung für den Einsatz unter bestimmten Bedingungen gewährleisten. Ein Beispiel für solche Standards ist die Reihe der internationalen Qualitätsstandards ISO 9000:2000 (GOST R ISO 9000-2001) oder die Luftfahrtstandards DO-178B, AS9100, AS9006. Das Testen zertifizierbarer Software dient zwei komplementären Zwecken: Der erste Zweck besteht darin, nachzuweisen, dass die Software die dafür geltenden Anforderungen erfüllt. Das zweite Ziel besteht darin, mit einem hohen Maß an Sicherheit nachzuweisen, dass während des Testprozesses Fehler identifiziert werden, die zu inakzeptablen Fehlersituationen führen könnten, wie sie im Systemfedefiniert sind. DO-178B erfordert beispielsweise Folgendes, um die Ziele von Softwaretests zu erfüllen: Tests müssen in erster Linie auf Softwareanforderungen basieren; Tests sollten so konzipiert sein, dass sie die korrekte Funktion überprüfen und potenzielle Fehler aufdecken. Durch die Analyse der Vollständigkeit von Tests auf Basis der Softwareanforderungen soll ermittelt werden, welche Anforderungen nicht getestet werden. Durch die Analyse der Vollständigkeit von Tests anhand der Struktur des Programmcodes soll ermittelt werden, welche Strukturen beim Testen nicht ausgeführt wurden. In dieser Norm geht es auch um anforderungsbasiertes Testen. Diese Strategie hat sich bei der Fehlererkennung als am effektivsten erwiesen. Richtlinien für die Auswahl von Testfällen auf der Grundlage von Anforderungen umfassen Folgendes: Um die Ziele des Softwaretests zu erreichen, müssen zwei Kategorien von Tests durchgeführt werden: Tests für normale Situationen und Tests für abnormale (nicht erforderliche, robuste) Situationen. Für Softwareanforderungen und Fehlerquellen, die dem Softwareentwicklungsprozess innewohnen, sollten spezifische Testfälle entwickelt werden. Der Zweck von Tests für normale Situationen besteht darin, die Fähigkeit der Software zu demonstrieren, bei Bedarf auf normale Eingaben und Bedingungen zu reagieren. 24 Der Zweck von Tests für abnormale Situationen besteht darin, die Fähigkeit der Software zu demonstrieren, angemessen auf abnormale Eingaben und Bedingungen zu reagieren, mit anderen Worten, sie sollten nicht zum Ausfall des Systems führen. Fehlerkategorien für ein System werden festgelegt, indem die Schwere der Fehlersituation für das Flugzeug und seine Insassen bestimmt wird. Jeder Fehler in der Software kann einen Fehler verursachen, der zu einer Fehlersituation führt. Daher hängt der Grad der Softwareintegrität, der für einen sicheren Betrieb erforderlich ist, mit Fehlersituationen des Systems zusammen. Es gibt 5 Stufen von Fehlersituationen, von unbedeutend bis kritisch gefährlich. Entsprechend dieser Ebenen wird das Konzept der Softwarekritikalitätsebene eingeführt. Der Grad der Kritikalität bestimmt die Zusammensetzung der der Zertifizierungsstelle zur Verfügung gestellten Dokumentation und damit die Tiefe der Systementwicklungs- und Verifizierungsprozesse. Beispielsweise können die Anzahl der Dokumenttypen und der Umfang der Systementwicklungsarbeit, die für die Zertifizierung auf die niedrigste Stufe der DO-178B-Kritikalität erforderlich sind, um ein bis zwei Größenordnungen von der Anzahl und dem Umfang abweichen, die für die Zertifizierung auf die höchste Stufe erforderlich sind. Die konkreten Anforderungen ergeben sich aus der Norm, nach der die Zertifizierung geplant ist. 25 THEMA 2. Programmcode testen (Vorlesungen 2-5) 2.1. Aufgaben und Ziele des Programmcode-Tests Beim Programmcode-Testen handelt es sich um den Prozess der Ausführung von Programmcode mit dem Ziel, darin vorhandene Fehler zu identifizieren. Unter einem Fehler wird hier ein Abschnitt des Programmcodes verstanden, dessen Ausführung unter bestimmten Voraussetzungen zu unerwartetem (d. h. nicht den Anforderungen entsprechendem) Systemverhalten führt. Unerwartetes Verhalten des Systems kann zu Fehlfunktionen und Ausfällen führen; in diesem Fall spricht man von erheblichen Fehlern im Programmcode. Einige Defekte verursachen kleinere Probleme, die die Funktion des Systems nicht beeinträchtigen, die Arbeit damit jedoch etwas erschweren. In diesem Fall spricht man von mittleren oder geringfügigen Mängeln. Die Aufgabe des Testens mit diesem Ansatz besteht darin, die Bedingungen zu ermitteln, unter denen Systemfehler auftreten, und diese Bedingungen aufzuzeichnen. Zu den Testaufgaben gehört in der Regel nicht die Identifizierung bestimmter fehlerhafter Abschnitte des Programmcodes und niemals die Korrektur von Fehlern – es handelt sich um eine Debugging-Aufgabe, die auf der Grundlage der Ergebnisse von Systemtests durchgeführt wird. Der Zweck der Verwendung eines Programmcode-Testverfahrens besteht darin, die Anzahl der Fehler, insbesondere der schwerwiegenden, im Endprodukt zu minimieren. Das Testen allein kann nicht garantieren, dass der Systemcode vollständig fehlerfrei ist. In Kombination mit Verifizierungs- und Validierungsprozessen, die darauf abzielen, Inkonsistenzen und Unvollständigkeiten der Entwurfsdokumentation (insbesondere der Systemanforderungen) zu beseitigen, bieten gut organisierte Tests jedoch die Garantie dafür, dass das System die Anforderungen erfüllt und sich in allen vorgesehenen Situationen entsprechend verhält. Bei der Entwicklung von Systemen mit erhöhter Zuverlässigkeit, beispielsweise in der Luftfahrt, werden Zuverlässigkeitsgarantien durch eine klare Organisation des Testprozesses, die Bestimmung seines Zusammenhangs mit anderen Lebenszyklusprozessen und die Einführung quantitativer Merkmale erreicht, die eine Beurteilung des Testerfolgs ermöglichen. Darüber hinaus werden die Anforderungen umso strenger, je höher die Anforderungen an die Zuverlässigkeit des Systems (seine Kritikalität) sind. Daher betrachten wir zunächst nicht die spezifischen Ergebnisse des Testens eines bestimmten Systems, sondern die Gesamtorganisation des Testprozesses nach dem Ansatz „Ein gut organisierter Prozess führt zu einem qualitativ hochwertigen Ergebnis.“ Dieser Ansatz ist in vielen internationalen und industriellen Qualitätsstandards üblich und wird am Ende dieses Kurses ausführlicher besprochen. Die Qualität des entwickelten Systems ist bei diesem Ansatz eine Folge des organisierten Entwicklungs- und Testprozesses und kein unabhängiges unkontrollierbares Ergebnis. Da moderne Softwaresysteme recht groß sind, wird beim Testen ihres Programmcodes die Methode der funktionalen Zerlegung verwendet. Das System ist in separate Module (Klassen, Namespaces usw.) unterteilt, deren Funktionalität und Schnittstellen durch die Anforderungen definiert werden. Danach wird jedes Modul separat getestet – es wird ein Unit-Test durchgeführt. Anschließend werden die einzelnen Module zu größeren Konfigurationen zusammengesetzt – Integrationstests durchgeführt, und schließlich wird das System als Ganzes getestet – Systemtests durchgeführt. Aus Code-Sicht haben Unit-, Integrations- und Systemtests viele Gemeinsamkeiten, daher konzentriert sich dieses Thema auf Unit-Tests, wobei die Funktionen von Integration und Systemtests später besprochen werden. 26 Beim Unit-Testing wird jedes Modul sowohl auf die Einhaltung der Anforderungen als auch auf das Fehlen problematischer Bereiche im Programmcode getestet, die zu Ausfällen und Fehlfunktionen im System führen könnten. Module arbeiten in der Regel nicht außerhalb des Systems – sie empfangen Daten von anderen Modulen, verarbeiten diese und übermitteln sie weiter. Um einerseits das Modul vom System zu isolieren und den Einfluss möglicher Systemfehler auszuschließen und andererseits das Modul mit allen notwendigen Daten zu versorgen, wird eine Testumgebung eingesetzt. Die Aufgabe der Testumgebung besteht darin, eine Laufzeitumgebung für das Modul zu erstellen und alle externen Schnittstellen zu emulieren, auf die das Modul zugreift. In diesem Thema werden die Merkmale der Organisation einer Testumgebung erläutert. Ein typisches Testverfahren besteht aus der Vorbereitung und Ausführung von Testfällen (auch einfach Tests genannt). Jedes Testbeispiel überprüft eine „Situation“ im Verhalten des Moduls und besteht aus einer Liste von Werten, die an den Eingang des Moduls übergeben werden, einer Beschreibung des Starts und der Ausführung der Datenverarbeitung – einem Testskript und einer Liste von Werte, die am Ausgang des Moduls erwartet werden, wenn es sich korrekt verhält. Testskripte werden so kompiliert, dass der Zugriff auf die internen Daten des Moduls ausgeschlossen ist; jegliche Interaktion sollte nur über seine externen Schnittstellen erfolgen. Die Ausführung eines Testfalls wird durch eine Testumgebung unterstützt, die eine Softwareimplementierung des Testskripts umfasst. Die Ausführung beginnt mit der Übergabe von Eingabedaten an das Modul und der Ausführung des Skripts. Die tatsächlich vom Modul als Ergebnis der Ausführung des Skripts empfangenen Ausgabedaten werden gespeichert und mit den erwarteten verglichen. Bei Übereinstimmung gilt die Prüfung als bestanden, andernfalls als nicht bestanden. Jeder fehlgeschlagene Test weist entweder auf einen Fehler im zu testenden Modul, in der Testumgebung oder in der Testbeschreibung hin. Die Beschreibungen der Testfälle bilden einen Testplan – das Hauptdokument, das das Testverfahren für ein Softwaremodul definiert. Der Testplan legt nicht nur die Testfälle selbst fest, sondern auch die Reihenfolge, in der sie erscheinen, was ebenfalls wichtig sein kann. Die Struktur und Merkmale von Testplänen werden in diesem Thema besprochen; Probleme im Zusammenhang mit der Reihenfolge von Testfällen werden im Thema „Wiederholbarkeit testen“ besprochen. Beim Testen ist es oft notwendig, nicht nur die Systemanforderungen, sondern auch die Struktur des Programmcodes des zu testenden Moduls zu berücksichtigen. In diesem Fall sind Tests so konzipiert, dass sie typische Programmierfehler erkennen, die durch eine falsche Interpretation von Anforderungen verursacht werden. Dabei kommen Randbedingungsprüfungen und Äquivalenzklassenprüfungen zum Einsatz. Das Fehlen von Fähigkeiten im System, die nicht durch die Anforderungen spezifiziert sind, wird durch unterschiedliche Schätzungen der Programmcodeabdeckung durch Tests gewährleistet, d. h. Schätzen, wie viel Prozent bestimmter Sprachkonstrukte als Ergebnis der Ausführung aller Testbeispiele abgeschlossen sind. All dies wird am Ende dieses Themas besprochen. 2.2. Prüfmethoden 2.2.1. Black Box Der Grundgedanke beim Testen eines Systems als Black Box besteht darin, dass alle Materialien, die dem Tester zur Verfügung stehen, Anforderungen an das System sind, die sein Verhalten und das System selbst beschreiben und mit denen er nur durch die Anwendung einiger äußerer Einflüsse arbeiten kann Seine Eingaben und die Beobachtung der Ausgaben ergeben ein Ergebnis. Alle internen Merkmale der Systemimplementierung bleiben dem Tester verborgen, das System stellt somit eine „Black Box“ dar, deren korrektes Verhalten in Bezug auf die Anforderungen überprüft werden muss. 27 Aus Sicht des Softwarecodes kann eine Black Box eine Reihe von Klassen (oder Modulen) mit bekannten externen Schnittstellen, aber unzugänglichen Quellcodes sein. Die Hauptaufgabe des Testers bei dieser Testmethode besteht darin, kontinuierlich zu überprüfen, ob das Systemverhalten den Anforderungen entspricht. Darüber hinaus muss der Tester in kritischen Situationen die Funktion des Systems überprüfen – was passiert, wenn falsche Eingabewerte geliefert werden. Im Idealfall sollten alle Varianten kritischer Situationen in den Systemanforderungen beschrieben sein und der Tester kann nur spezifische Tests dieser Anforderungen vorlegen. In der Realität werden jedoch als Ergebnis von Tests normalerweise zwei Arten von Systemproblemen identifiziert: 1. Inkonsistenz des Systemverhaltens mit den Anforderungen 2. Unangemessenes Verhalten des Systems in Situationen, die nicht in den Anforderungen vorgesehen sind. Beide Arten von Problemen werden gemeldet und den Entwicklern gemeldet. Gleichzeitig führen Probleme der ersten Art in der Regel zu Änderungen im Programmcode, viel seltener zu Änderungen der Anforderungen. Eine Änderung der Anforderungen kann in diesem Fall aufgrund ihrer Inkonsistenz (mehrere unterschiedliche Anforderungen beschreiben unterschiedliche Modelle des Systemverhaltens in derselben Situation) oder Unrichtigkeit (die Anforderungen entsprechen nicht der Realität) erforderlich sein. Probleme der zweiten Art erfordern aufgrund ihrer Unvollständigkeit eindeutig eine Änderung der Anforderungen – die Anforderungen lassen eindeutig eine Situation aus, die zu unangemessenem Verhalten des Systems führt. Unter unangemessenem Verhalten kann in diesem Fall ein vollständiger Zusammenbruch des Systems oder allgemein jedes Verhalten verstanden werden, das nicht in den Anforderungen beschrieben ist. Black-Box-Tests werden auch Anforderungstests genannt, weil... Dies ist die einzige Informationsquelle für die Erstellung eines Testplans. 2.2.2. Glaskasten (weiß) Beim Testen eines Systems als Glaskasten hat der Tester nicht nur Zugriff auf die Anforderungen an das System, seine Ein- und Ausgänge, sondern auch auf seine interne Struktur – er sieht seinen Programmcode. Die Verfügbarkeit von Programmcode erweitert die Möglichkeiten des Testers, indem er die Übereinstimmung von Anforderungen mit Abschnitten des Programmcodes erkennen und dadurch erkennen kann, ob Anforderungen für den gesamten Programmcode bestehen. Programmcode, für den keine Anforderungen bestehen, wird als Code bezeichnet, der nicht durch Anforderungen abgedeckt ist. Ein solcher Code ist eine potenzielle Quelle für unangemessenes Systemverhalten. Darüber hinaus ermöglicht die Transparenz des Systems eine vertiefte Analyse seiner problematischen Bereiche – oft neutralisiert ein Problem ein anderes und sie treten nie gleichzeitig auf. 2.2.3. Modelltests Modelltests unterscheiden sich etwas von den klassischen Methoden der Softwareverifizierung. Dies liegt zum einen daran, dass der Prüfgegenstand nicht das System selbst, sondern sein mit formalen Mitteln entworfenes Modell ist. Wenn wir die Fragen der Überprüfung der Richtigkeit und Anwendbarkeit des Modells selbst außer Acht lassen (man geht davon aus, dass seine Richtigkeit und Übereinstimmung mit dem ursprünglichen System mit formalen Mitteln nachgewiesen werden kann), steht dem Tester ein ziemlich leistungsfähiges Analysewerkzeug zur Verfügung die Gesamtintegrität des Systems. Durch die Arbeit mit dem Modell können Situationen geschaffen werden, die in einem Testlabor für ein reales System nicht erzeugt werden können. Mithilfe eines Modells des Programmcodes eines Systems können Sie dessen Eigenschaften und Systemparameter wie die Optimalität von Algorithmen oder seine Stabilität analysieren. 28 Modelltests haben sich jedoch gerade aufgrund der Schwierigkeiten bei der Entwicklung einer formalen Beschreibung des Systemverhaltens nicht weit verbreitet. Eine der wenigen Ausnahmen bilden Kommunikationssysteme, deren algorithmischer und mathematischer Apparat recht gut entwickelt ist. 2.2.4. Programmcode-Analyse (Inspektionen) In vielen Situationen ist es unmöglich, das Verhalten des Systems als Ganzes zu testen – einzelne Abschnitte des Programmcodes werden möglicherweise nie ausgeführt, werden aber von den Anforderungen abgedeckt. Ein Beispiel für solche Codeabschnitte sind Ausnahmehandler. Wenn sich beispielsweise zwei Module gegenseitig numerische Werte übergeben und die Werteprüffunktionen in beiden Modulen funktionieren, wird die Prüffunktion des empfangenden Moduls niemals aktiviert, weil alle fehlerhaften Werte werden im Sender abgeschnitten. Dabei erfolgt eine manuelle Analyse des Programmcodes auf Korrektheit, auch Code Reviews oder Inspektionen genannt. Werden bei der Inspektion Problembereiche identifiziert, werden diese Informationen zusammen mit den Ergebnissen regelmäßiger Tests an die Entwickler zur Behebung übermittelt. 2.3. Testumgebung Der Großteil der Tests fast aller komplexen Systeme wird normalerweise im automatischen Modus durchgeführt. Darüber hinaus ist das zu testende System in der Regel in einzelne Module unterteilt, die jeweils zunächst einzeln und dann als Ganzes getestet werden. Das bedeutet, dass es zur Durchführung von Tests notwendig ist, eine Umgebung zu schaffen, die den Start und die Ausführung des zu testenden Moduls sicherstellt, ihm Eingabedaten überträgt und echte Ausgabedaten sammelt, die als Ergebnis des Betriebs des Systems auf dem gegebenen System erhalten werden Eingabedaten. Danach muss die Umgebung die tatsächlichen Ausgabedaten mit den erwarteten vergleichen und auf der Grundlage dieses Vergleichs eine Schlussfolgerung über die Übereinstimmung des Verhaltens des Moduls mit dem spezifizierten ziehen (Abb. 9). Testtreiber Erwartete Ausgabe Getestete Verarbeitung Eingabedaten-Ergebnismodul Echte Ausgabedaten Stubs Abb. 9 Verallgemeinertes Diagramm der Testumgebung Die Testumgebung kann auch dazu verwendet werden, einzelne Systemmodule vom Gesamtsystem zu entfremden. Durch die Trennung von Systemmodulen in den frühen Testphasen können Sie Probleme, die in ihrem Programmcode auftreten, genauer lokalisieren. Um den Betrieb eines Moduls isoliert vom System zu unterstützen, muss die Testumgebung das Verhalten aller Module simulieren, auf deren Funktionen oder Daten das zu testende Modul zugreift. 29

Verifizierung und Validierung ( Verifizierung und Validierung-V& V) dienen der Analyse, Überprüfung der korrekten Ausführung und Übereinstimmung der Software mit Spezifikationen und Kundenanforderungen. Diese Methoden zur Überprüfung der Korrektheit von Programmen bzw. Systemen bedeuten:

Bei der Verifizierung wird überprüft, ob das System gemäß seiner Spezifikation korrekt aufgebaut ist.
Bei der Validierung handelt es sich um eine Überprüfung der korrekten Erfüllung spezifizierter Systemanforderungen.

Die Verifizierung hilft, nach Abschluss des Entwurfs und der Entwicklung eine Schlussfolgerung über die Korrektheit des erstellten Systems zu ziehen. Die Validierung ermöglicht es Ihnen, die Machbarkeit spezifizierter Anforderungen zu bestimmen und umfasst eine Reihe von Maßnahmen, um korrekte Programme und Systeme zu erhalten, nämlich:

Planungsverfahren zur Überprüfung und Überwachung von Entwurfsentscheidungen und -anforderungen;
Sicherstellung des Automatisierungsgrads des Programmdesigns mit CASE-Tools;
Überprüfung der korrekten Funktion von Programmen mithilfe von Testmethoden anhand von Zieltestsätzen;
Anpassung des Produkts an die Betriebsumgebung usw.

Bei der Validierung werden diese Aktivitäten durchgeführt, indem die Spezifikationen und Entwurfsergebnisse der Lebenszyklusphasen überprüft und untersucht werden, um zu bestätigen, dass die anfänglichen Anforderungen korrekt umgesetzt wurden und dass festgelegte Bedingungen und Einschränkungen erfüllt sind. Zu den Aufgaben der Verifizierung und Validierung gehört die Überprüfung der Vollständigkeit, Konsistenz und Eindeutigkeit der Anforderungsspezifikation sowie der korrekten Ausführung von Systemfunktionen.

Die Überprüfung und Validierung unterliegt:

Hauptkomponenten des Systems;
Schnittstellen von Komponenten (Software, Technik und Information) und Interaktionen von Objekten (Protokolle und Nachrichten), die die Ausführung des Systems in verteilten Umgebungen gewährleisten;
Mittel zum Zugriff auf die Datenbank und Dateien (Transaktionen und Nachrichten) und Überprüfung der Mittel zum Schutz vor unbefugtem Zugriff auf Daten verschiedener Benutzer;
Dokumentation für die Software und das System als Ganzes;
Tests, Testverfahren und Eingabedaten.

Mit anderen Worten, die wichtigsten systematischen Methoden zur Programmkorrektheit sind:

Überprüfung Validierung von Softwarekomponenten und Anforderungsspezifikationen;
PS-Inspektion um die Übereinstimmung des Programms mit den vorgegebenen Spezifikationen festzustellen;
testen Ausgabecode der Software auf Testdaten in einer bestimmten Betriebsumgebung, um Fehler und Defekte zu identifizieren, die durch verschiedene Defekte, anormale Situationen, Geräteausfälle oder Notbeendigung des Systems verursacht werden (siehe Kapitel 9).

Die Standards ISO/IEC 3918-99 und 12207 umfassen Verifizierungs- und Validierungsprozesse. Für sie werden Ziele, Zielsetzungen und Maßnahmen definiert, um die Richtigkeit des erstellten Produkts (einschließlich Arbeits- und Zwischenprodukten) in den Phasen des Lebenszyklus und die Einhaltung seiner Anforderungen zu überprüfen.

Das Hauptziel der Verifizierungs- und Validierungsprozesse besteht darin prüfen und bestätigen dass die endgültige Software zweckmäßig ist und den Anforderungen des Kunden entspricht. Diese Prozesse ermöglichen es, Fehler in den Arbeitsprodukten von Lebenszyklusphasen zu identifizieren, ohne die Gründe für ihr Auftreten zu ermitteln, und auch die Korrektheit der Software in Bezug auf ihre Spezifikation festzustellen.

Diese Prozesse sind miteinander verbunden und werden durch einen Begriff definiert – „Verifizierung und Validierung“ (V&V 7).

Bei der Verifizierung wird Folgendes durchgeführt:

Überprüfung der Korrektheit der Übersetzung einzelner Komponenten in den Ausgabecode sowie Schnittstellenbeschreibungen durch Nachverfolgung der Verbindungen der Komponenten gemäß den spezifizierten Kundenanforderungen;
Analyse der Richtigkeit des Zugriffs auf Dateien oder Datenbanken unter Berücksichtigung der in den verwendeten Systemtools übernommenen Verfahren zur Datenmanipulation und Ergebnisübertragung;
Überprüfung der Komponentenschutzausrüstung auf Übereinstimmung mit den Kundenanforderungen und Durchführung der Rückverfolgung.

Nach der Prüfung der einzelnen Komponenten des Systems erfolgt deren Integration sowie die Verifizierung und Validierung des integrierten Systems. Das System wird anhand verschiedener Testsuiten getestet, um die Eignung und Eignung dieser Suiten für den Abschluss der Tests und die Feststellung der Korrektheit des Systems zu ermitteln.

Die Idee, ein internationales Projekt zur formalen Verifizierung zu schaffen, wurde von T. Hoar vorgeschlagen und auf einem Symposium über verifizierte Software im Februar 2005 in Kalifornien diskutiert. Im Oktober desselben Jahres wurde dann auf der IFIP-Konferenz in Zürich ein internationales Projekt mit einer Laufzeit von 15 Jahren beschlossen, um „einen umfassenden automatisierten Satz von Werkzeugen zur Überprüfung der Korrektheit von Software“ zu entwickeln.

Es formuliert folgende Hauptaufgaben:

Entwicklung einer einheitlichen Theorie der Programmkonstruktion und -analyse;
Aufbau eines umfassenden, integrierten Satzes von Verifizierungstools für alle Produktionsphasen, einschließlich Spezifikationsentwicklung und -verifizierung, Testfallgenerierung, Programmverfeinerung, Analyse und Verifizierung;
Erstellung eines Repositorys formaler Spezifikationen und verifizierter Softwareobjekte verschiedener Typen und Typen.

Dieses Projekt geht davon aus, dass die Verifizierung alle Aspekte der Erstellung und Überprüfung der Korrektheit von Software abdeckt und zum Allheilmittel für alle Übel wird, die mit dem ständigen Auftreten von Fehlern in erstellten Programmen verbunden sind.

Viele formale Methoden zum Nachweis und zur Verifizierung spezifizierter Programme wurden in der Praxis getestet. Das internationale Komitee ISO/IEC hat im Rahmen der Norm ISO/IEC 12207:2002 viel Arbeit geleistet, um Software-Verifizierungs- und Validierungsprozesse zu standardisieren. Die Überprüfung der Korrektheit verschiedener Programmierobjekte mithilfe formaler Methoden ist vielversprechend.

Das Repository ist eine Sammlung von Programmen, Spezifikationen und Werkzeugen, die bei der Entwicklung und Prüfung, der Bewertung fertiger Komponenten, Werkzeugen und Methodenvorbereitungen verwendet werden. Ihm werden folgende allgemeine Aufgaben übertragen:

Ansammlung verifizierter Spezifikationen, Beweismethoden, Softwareobjekte und Code-Implementierungen für komplexe Anwendungen;
Ansammlung verschiedener Verifizierungsmethoden, deren Gestaltung in einer für die Suche und Auswahl einer umgesetzten theoretischen Idee zur weiteren Anwendung geeigneten Form;
Entwicklung von Standardformularen zur Spezifikation und zum Austausch formaler Spezifikationen verschiedener Programmierobjekte sowie von Tools und vorgefertigten Systemen;
Entwicklung von Interoperabilitäts- und Interaktionsmechanismen für die Übertragung fertiger verifizierter Produkte aus dem Repository in neue verteilte und Netzwerkumgebungen zur Erstellung neuer Software.

Es wird erwartet, dass dieses Projekt über einen Zeitraum von 50 Jahren entwickelt wird. Frühere Projekte verfolgten ähnliche Ziele: Verbesserung der Softwarequalität, Formalisierung von Servicemodellen, Reduzierung der Komplexität durch den Einsatz von PIC, Erstellung von Debugging-Tools zur visuellen Fehlerdiagnose und -beseitigung usw. Allerdings gab es auch in der Programmierung keine grundlegende Änderung im Hinblick auf das visuelle Debugging oder eine hohe Softwarequalität zu erreichen. Der Entwicklungsprozess geht weiter.

Ein neues internationales Software-Verifikationsprojekt erfordert von seinen Teilnehmern nicht nur Kenntnisse über die theoretischen Aspekte von Programmspezifikationen, sondern auch hochqualifizierte Programmierer für die Umsetzung in den kommenden Jahren.

Lassen Sie uns mehrere Definitionen geben, die die allgemeine Struktur des Software-Zertifizierungsprozesses definieren:

Softwarezertifizierung– der Prozess der Feststellung und formellen Anerkennung, dass die Softwareentwicklung in Übereinstimmung mit den festgelegten Anforderungen durchgeführt wurde. Während des Zertifizierungsprozesses findet Interaktion statt Antragsteller, Zertifizierungsstelle und Aufsichtsstelle

Antragsteller- Organisation, die einen Antrag bei der zuständigen Stelle einreicht Zertifizierungsstelle ein Zertifikat (Konformität, Qualität, Eignung etc.) des Produktes zu erhalten.

Zertifizierungsstelle– Organisation, die den Antrag prüft Der Bewerberüber das Halten Softwarezertifizierungen und entweder unabhängig oder durch Bildung einer Sonderkommission, die eine Reihe von Verfahren zur Durchführung des Prozesses erstellt Software-Zertifizierung des Bewerbers.

Aufsichtsorgan– eine Expertenkommission, die die Entwicklungsprozesse überwacht Der Bewerber Informationssystem, das zertifiziert wird, und gibt eine Stellungnahme zur Übereinstimmung dieses Prozesses mit bestimmten Anforderungen ab, die ihm zur Prüfung vorgelegt wird Zertifizierungsstelle.

Die Zertifizierung kann auf den Erhalt eines Konformitätszertifikats oder eines Qualitätszertifikats abzielen.

Im ersten Fall ist das Ergebnis der Zertifizierung die Anerkennung der Übereinstimmung von Entwicklungsprozessen mit bestimmten Kriterien und der Funktionalität des Systems mit bestimmten Anforderungen. Ein Beispiel für solche Anforderungen sind die Leitliniendokumente des Föderalen Dienstes für technische Kontrolle und Exportkontrolle im Bereich der Sicherheit von Softwaresystemen.

Im zweiten Fall ist das Ergebnis die Anerkennung der Übereinstimmung von Entwicklungsprozessen mit bestimmten Kriterien, die ein angemessenes Qualitätsniveau des hergestellten Produkts und seine Eignung für den Einsatz unter bestimmten Bedingungen gewährleisten. Ein Beispiel für solche Standards ist die Reihe der internationalen Qualitätsstandards ISO 9000:2000 (GOST R ISO 9000-2001) oder die Luftfahrtstandards DO-178B, AS9100, AS9006.

Das Testen zertifizierbarer Software dient zwei komplementären Zwecken:

· Das erste Ziel besteht darin, nachzuweisen, dass die Software die dafür erforderlichen Anforderungen erfüllt.

· Das zweite Ziel besteht darin, mit einem hohen Maß an Sicherheit nachzuweisen, dass während des Testprozesses Fehler identifiziert werden, die zu inakzeptablen Fehlersituationen führen könnten, wie sie im Systemfedefiniert sind.

DO-178B erfordert beispielsweise Folgendes, um die Ziele von Softwaretests zu erfüllen:

· Tests sollten zunächst einmal auf den Softwareanforderungen basieren;

· Tests sollten so konzipiert sein, dass sie die korrekte Funktion überprüfen und potenzielle Fehler aufdecken.

· Durch die Analyse der Vollständigkeit von Tests auf der Grundlage von Softwareanforderungen sollte ermittelt werden, welche Anforderungen nicht getestet werden.

· Durch die Analyse der Vollständigkeit von Tests anhand der Struktur des Programmcodes soll ermittelt werden, welche Strukturen während des Tests nicht ausgeführt wurden.

In dieser Norm geht es auch um anforderungsbasiertes Testen. Diese Strategie hat sich bei der Fehlererkennung als am effektivsten erwiesen. Richtlinien für die Auswahl von Testfällen basierend auf Anforderungen umfassen Folgendes:

· Um die Ziele des Softwaretests zu erreichen, müssen zwei Kategorien von Tests durchgeführt werden: Tests für normale Situationen und Tests für abnormale (nicht in den Anforderungen widergespiegelte, robuste) Situationen.

· Für Softwareanforderungen und Fehlerquellen im Softwareentwicklungsprozess sollten spezifische Testfälle entwickelt werden.

Der Zweck von Tests für normale Situationen besteht darin, die Fähigkeit der Software zu demonstrieren, bei Bedarf auf normale Eingaben und Bedingungen zu reagieren.

Der Zweck von Tests für abnormale Situationen besteht darin, die Fähigkeit der Software zu demonstrieren, angemessen auf abnormale Eingaben und Bedingungen zu reagieren. Mit anderen Worten: Sie sollten nicht zum Ausfall des Systems führen.

Fehlerkategorien für ein System werden festgelegt, indem die Schwere der Fehlersituation für das Flugzeug und seine Insassen bestimmt wird. Jeder Fehler in der Software kann einen Fehler verursachen, der zu einer Fehlersituation führt. Daher hängt der Grad der Softwareintegrität, der für einen sicheren Betrieb erforderlich ist, mit Fehlersituationen des Systems zusammen.

Es gibt 5 Stufen von Fehlersituationen, von unbedeutend bis kritisch gefährlich. Entsprechend dieser Ebenen wird das Konzept der Softwarekritikalitätsebene eingeführt. Der Grad der Kritikalität bestimmt die Zusammensetzung der der Zertifizierungsstelle zur Verfügung gestellten Dokumentation und damit die Tiefe der Systementwicklungs- und Verifizierungsprozesse. Beispielsweise können die Anzahl der Dokumenttypen und der Umfang der Systementwicklungsarbeit, die für die Zertifizierung auf die niedrigste Stufe der DO-178B-Kritikalität erforderlich sind, um ein bis zwei Größenordnungen von der Anzahl und dem Umfang abweichen, die für die Zertifizierung auf die höchste Stufe erforderlich sind. Die konkreten Anforderungen ergeben sich aus der Norm, nach der die Zertifizierung geplant ist.

Unter den Begriffen Verifizierung und Validierung versteht man die Überprüfung der Qualität von Software. Wir verwenden diese Begriffe in unseren Artikeln und Berichten. Wir haben wiederholt verschiedene Kommentare und Argumente darüber gehört, ob die statische Analyse des Programmquellcodes als Verifizierung und Validierung klassifiziert werden sollte und was der Unterschied zwischen diesen Konzepten ist. Generell entsteht der Eindruck, dass jeder seine eigenen Vorstellungen in diese Begriffe einbringt, was zu gegenseitigen Missverständnissen führt.

Wir haben uns entschieden, die Terminologie zu verstehen, um an der korrektesten Interpretation dieser Konzepte festzuhalten. Bei der Recherche fanden wir die Arbeit von V.V. Kulyamin „Methoden der Softwareüberprüfung“. Es enthält eine detaillierte Beschreibung dieser Begriffe, und wir haben uns entschieden, uns weiterhin auf die in dieser Arbeit gegebenen Definitionen zu stützen. Hier sind einige Auszüge aus dieser Arbeit zum Thema Verifizierung und Validierung.

Verifizierung und Validierung sind Aktivitäten, die darauf abzielen, die Qualität von Software zu überwachen und Fehler darin zu erkennen. Da sie ein gemeinsames Ziel haben, unterscheiden sie sich in den Quellen der in ihrem Verlauf geprüften Eigenschaften, Regeln und Einschränkungen, deren Verletzung als Fehler gewertet wird.

Zur weiteren Erläuterung müssen wir den Begriff „Software-Lebenszyklus-Artefakt“ einführen. Artefakte im Softwarelebenszyklus sind verschiedene Informationseinheiten, Dokumente und Modelle, die während der Softwareentwicklung und -wartung erstellt oder verwendet werden. Artefakte sind also eine technische Spezifikation, eine Beschreibung der Architektur, ein Modell des Themenbereichs in einer grafischen Sprache, Quellcode, Benutzerdokumentation usw. Verschiedene Modelle, die von einzelnen Entwicklern bei der Erstellung und Analyse von Software verwendet werden, aber nicht in Form von Dokumenten aufgezeichnet werden, die für andere Personen zugänglich sind, können nicht als Artefakte betrachtet werden.

Die Verifizierung überprüft die Übereinstimmung einiger Artefakte, die während der Entwicklung und Wartung von Software erstellt wurden, mit anderen, die zuvor erstellt oder als Eingabedaten verwendet wurden, sowie die Übereinstimmung dieser Artefakte und ihrer Entwicklungsprozesse mit Regeln und Standards. Bei der Verifizierung wird insbesondere die Einhaltung von Standards, Anforderungsbeschreibungen (technischen Spezifikationen) für Software, Designlösungen, Quellcode, Benutzerdokumentation und die Funktionsfähigkeit der Software selbst überprüft. Darüber hinaus wird überprüft, ob die Anforderungen, Designlösungen, Dokumentationen und Codes in Übereinstimmung mit den Normen und Standards erstellt werden, die in einem bestimmten Land, einer bestimmten Branche und einer bestimmten Organisation bei der Entwicklung von Software angewendet werden, und dass während ihrer Erstellung alle in der angegebenen Vorgänge ausgeführt werden Die Standards wurden in den erforderlichen Reihenfolgen durchgeführt. Bei der Überprüfung festgestellte Fehler und Mängel sind Abweichungen oder Widersprüche zwischen mehreren der aufgeführten Dokumente, zwischen den Dokumenten und dem tatsächlichen Betrieb des Programms, zwischen den Standards und den tatsächlichen Prozessen der Softwareentwicklung und -wartung. Gleichzeitig ist die Entscheidung, welches Dokument korrigiert werden soll (vielleicht beides), eine separate Aufgabe.

Bei der Validierung wird die Übereinstimmung aller bei der Entwicklung und Wartung von Software erstellten oder verwendeten Artefakte mit den Bedürfnissen und Anforderungen der Benutzer und Kunden dieser Software unter Berücksichtigung der Gesetze des Fachgebiets und der Einschränkungen des Nutzungskontexts der Software überprüft . Diese Bedürfnisse und Anforderungen werden meist nicht dokumentiert – wenn sie erfasst werden, werden sie zu einer Beschreibung der Anforderungen, einem der Artefakte des Softwareentwicklungsprozesses. Daher ist die Validierung eine weniger formalisierte Aktivität als die Verifizierung. Sie wird immer unter Beteiligung von Vertretern von Kunden, Anwendern, Geschäftsanalysten oder Fachexperten durchgeführt – solchen, deren Meinung als ausreichender Ausdruck der tatsächlichen Bedürfnisse und Anforderungen von Anwendern, Kunden und anderen interessierten Parteien angesehen werden kann. Methoden zu seiner Umsetzung nutzen häufig spezifische Techniken, um das Wissen und die tatsächlichen Bedürfnisse der Teilnehmer zu ermitteln.

Der Unterschied zwischen Verifizierung und Validierung ist in Abbildung 1 dargestellt.

Die angegebenen Definitionen ergeben sich aus einer Erweiterung der Definitionen des IEEE 1012-Standards für Verifizierungs- und Validierungsprozesse. Im IEEE 610.12-Standardwörterbuch für Software-Engineering-Begriffe von 1990 ist die Definition von Verifizierung ungefähr gleich, die Definition von Validierung ist jedoch etwas anders – es heißt, dass bei der Validierung die Übereinstimmung der als Ergebnis der Entwicklung erhaltenen Software mit dem Original überprüft werden soll Voraussetzungen dafür. In diesem Fall wäre die Validierung ein Sonderfall der Verifizierung, der in der Software-Engineering-Literatur nirgendwo erwähnt wird. Daher und auch aufgrund der Korrektur in IEEE 1012 von 2004 sollte diese Definition als ungenau angesehen werden. Häufige Verwendung des Satzes von B. Boehm:

Die Verifizierung beantwortet die Frage „Stellen wir das Produkt richtig her?“ und die Validierung beantwortet die Frage „Stellen wir das richtige Produkt her?“

trägt auch zur Verwirrung bei, da der Aphorismus dieser Aussage leider mit Mehrdeutigkeit verbunden ist. Zahlreiche Arbeiten des Autors legen jedoch nahe, dass er mit Verifizierung und Validierung ungefähr dieselben Konzepte meinte wie oben definiert. Diese Diskrepanzen lassen sich auch im Inhalt der Software-Engineering-Standards nachweisen. Daher betrachtet die Norm ISO 12207 das Testen als eine Art Validierung, nicht jedoch als Verifizierung, was offenbar eine Folge der Verwendung einer ungenauen Definition aus dem Standardwörterbuch ist.

Abschließend möchte ich darauf hinweisen, dass die statische Analyse des Programmquellcodes nach den oben genannten Definitionen einer Softwareverifizierung entspricht, also etwa der Überprüfung der Übereinstimmung des Programmcodes mit verschiedenen Codierungsstandards. Die statische Analyse prüft die Übereinstimmung der Ergebnisse der Entwurfsphase des Softwaresystems mit den zuvor formulierten Anforderungen und Einschränkungen.

Literaturverzeichnis

V.V. Kulyamin „Methoden der Softwareüberprüfung“. Institut für Systemprogrammierung RAS 109004, Moskau, st. B. Kommunisticheskaya, Nr. 25.
http://www.ict.edu.ru/ft/005645/62322e1-st09.pdf
IEEE 1012-2004-Standard für Software-Verifizierung und -Validierung. IEEE, 2005.
IEEE 610.12-1990 Standard-Glossar der Software-Engineering-Terminologie, korrigierte Ausgabe. IEEE, Februar 1991.
B. W. Böhm. Softwareentwicklung; F&E-Trends und Verteidigungsbedarf. In R. Wegner, Hrsg. Forschung. Richtungen in der Softwaretechnologie. Cambridge, MA:MIT Press, 1979.
ISO/IEC 12207 Systeme und Software-Engineering – Software-Lebenszyklusprozesse. Genf, Schweiz: ISO, 2008.

Die beiden Konzepte Validierung und Verifizierung werden oft verwechselt. Darüber hinaus wird die Validierung von Systemanforderungen häufig mit der Validierung des Systems selbst verwechselt. Ich schlage vor, dieses Problem zu untersuchen.

In dem Artikel habe ich zwei Ansätze zur Modellierung eines Objekts betrachtet: als Ganzes und als Struktur. Im aktuellen Artikel werden wir diese Unterteilung benötigen.

Lassen Sie uns ein funktionales Objekt entwerfen. Betrachten wir dieses Objekt als Teil des Entwurfs eines anderen funktionalen Objekts. Es soll eine Beschreibung der Konstruktion eines Objekts geben, sodass diese eine Beschreibung des Objekts enthält. In einer solchen Beschreibung wird das Objekt als Ganzes beschrieben, d. h. seine Schnittstellen zur Interaktion mit anderen Objekten im Rahmen des Objektdesigns werden beschrieben. Es soll eine Beschreibung des Objekts als Struktur gegeben werden. Es soll ein Informationsobjekt vorliegen, das Anforderungen an die Gestaltung einer Beschreibung eines Objekts als Struktur enthält. Es gebe einen Wissensbestand, der Inferenzregeln enthält, auf deren Grundlage aus der Beschreibung eines Objekts als Ganzes eine Beschreibung des Objekts als Struktur gewonnen wird. Der Wissensbestand ist das, was Designern in Instituten vermittelt wird – sehr, sehr viel Wissen. Sie ermöglichen es, basierend auf dem Wissen über ein Objekt, dessen Struktur zu entwerfen.

Also, wir können beginnen. Wir können behaupten, dass die resultierende Beschreibung des Objektdesigns korrekt ist, wenn das Objekt als Ganzes korrekt beschrieben wird, wenn der Wissensbestand korrekt ist und wenn die Regeln der Schlussfolgerung befolgt wurden. Das heißt, basierend auf dieser Beschreibung wird ein funktionsfähiges Objekt gebaut, das den realen Betriebsbedingungen entspricht. Welche Risiken können auftreten:

1. Verwendung falscher Kenntnisse über das Objekt. Das Modell des Objekts in den Köpfen der Menschen entspricht möglicherweise nicht der Realität. Sie kannten zum Beispiel nicht die wirkliche Gefahr von Erdbeben. Dementsprechend können die Anforderungen an das Objekt falsch formuliert sein.

2. Unvollständige Erfassung des Wissens über das Objekt – etwas wurde übersehen, es wurden Fehler gemacht. Sie wussten zum Beispiel von den Winden, vergaßen aber, sie zu erwähnen. Dies kann dazu führen, dass die Anforderungen an das Objekt nicht vollständig beschrieben werden.

3. Falscher Wissensbestand. Uns wurde beigebracht, der Masse Vorrang vor anderen Parametern zu geben, aber es stellte sich heraus, dass wir die Geschwindigkeit erhöhen mussten.

4. Falsche Anwendung von Inferenzregeln auf die Beschreibung eines Objekts. Logische Fehler, es fehlt etwas in den Anforderungen für die Gestaltung des Objekts, die Nachverfolgung der Anforderungen ist unterbrochen.

5. Unvollständige Aufzeichnung der Systemdesign-Ergebnisse. Sie haben alles berücksichtigt, alles berechnet, aber vergessen, es aufzuschreiben.

6. Das erstellte System entspricht nicht der Beschreibung.

Es ist klar, dass alle Projektartefakte in der Regel erst gegen Ende des Projekts und auch dann nicht immer in ihrer fertigen Form erscheinen. Aber wenn wir davon ausgehen, dass die Entwicklung ein Wasserfall ist, dann sind die Risiken so, wie ich sie beschrieben habe. Die Überprüfung jedes Risikos ist ein spezifischer Vorgang, dem ein Name gegeben werden kann. Wenn jemand Interesse hat, kann er versuchen, diese Begriffe auszudenken und auszusprechen.

Was ist eine Verifizierung? Im Russischen ist die Verifizierung eine Überprüfung der Einhaltung der Regeln. Die Regeln werden in Form eines Dokuments erstellt. Das heißt, es muss ein Dokument mit Dokumentationspflichten vorliegen. Wenn die Dokumentation den Anforderungen dieses Dokuments entspricht, hat sie die Prüfung bestanden.

Was ist Validierung? Im Russischen bedeutet Validierung die Überprüfung der Richtigkeit von Schlussfolgerungen. Das heißt, es muss ein Wissensbestand vorhanden sein, der beschreibt, wie man eine Beschreibung eines Entwurfs auf der Grundlage von Daten über das Objekt erhält. Die Überprüfung der korrekten Anwendung dieser Schlussfolgerungen ist eine Validierung. Zur Validierung gehört die Überprüfung der Beschreibung auf Konsistenz, Vollständigkeit und Verständlichkeit.

Die Validierung von Anforderungen wird oft mit der Validierung des aus diesen Anforderungen erstellten Produkts verwechselt. Das solltest du nicht tun.