Tests sind in der Softwareentwicklung unerl\u00e4sslich, um die Lieferung qualitativ hochwertiger und fehlerfreier Softwareprodukte zu gew\u00e4hrleisten. Tester verwenden verschiedene Softwaretesttechniken, um verschiedene Probleme, Bugs und Fehler in Softwareprodukten zu identifizieren. Eine davon ist das White-Box-Testing. Sie befasst sich mit der Bewertung der internen Struktur der Software und der Implementierungsdetails. <\/p>\n\n
In diesem Artikel werden wir die grundlegenden Aspekte von White-Box-Tests behandeln.<\/p>\n
White-Box-Tests sind eine Software-Testtechnik, die das interne Design des Systems, die Struktur des Quellcodes, die verwendeten Datenstrukturen und die Arbeitsdetails testet. Ihr Hauptziel ist die Verbesserung von Softwaredesign, E\/A-Fluss, Benutzerfreundlichkeit und Sicherheit. Sie wird auch als Transparenzpr\u00fcfung, Strukturpr\u00fcfung und Glaskastenpr\u00fcfung bezeichnet. <\/p>\n\n
Die Umsetzung dieser Testtechnik erfordert, dass die Tester mit dem Systemcode, seiner Architektur und den Implementierungsdetails vertraut sind. Auf der Grundlage dieses Wissens erstellen sie Testf\u00e4lle und f\u00fchren sie aus, um die Korrektheit des Systems auf Code-Ebene zu \u00fcberpr\u00fcfen. Daher werden diese Tests auch als codebasierte Tests bezeichnet. <\/p>\n\n
Im Allgemeinen f\u00fchren die Entwickler White-Box-Tests durch. Sie m\u00fcssen den Quellcode und die Funktionsweise der Software vollst\u00e4ndig verstehen. In einigen F\u00e4llen kann sie jedoch auch von Qualit\u00e4tssicherungsexperten (QA) und Testern durchgef\u00fchrt werden, die komplexen Code verstehen. <\/p>\n\n
Diese Testtechnik wird „White Box“ genannt, weil die Entwickler oder Tester das Innenleben des Systems von au\u00dfen betrachten. <\/p>\n\n
Es wird auf den ersten beiden Ebenen des Softwaretests angewandt – dem Unit-Test und dem Integrationstest. Beim Unit-Testing wird jedes Softwaremodul einzeln gepr\u00fcft. Beim Integrationstest werden die zu testenden Module logisch miteinander verbunden und ihre Interaktion oder Kommunikation getestet.<\/p>\n\n
Beim White-Box-Testing wird der Software-Quellcode ausgewertet, um die folgenden Parameter zu \u00fcberpr\u00fcfen: <\/p>\n\n
Kurz gesagt, diese Testtechnik verifiziert den Software-Workflow. Dabei werden eine Reihe von Eingaben gemacht und die erwarteten mit den tats\u00e4chlichen Ergebnissen verglichen. Wenn die tats\u00e4chliche Ausgabe nicht mit der erwarteten Ausgabe \u00fcbereinstimmt, f\u00fchrt dies zu einem Fehler oder einer St\u00f6rung.<\/p>\n\n
Im Allgemeinen verifizieren Entwickler oder Tester Anwendungen mit dieser Softwaretesttechnik in zwei Schritten: <\/p>\n\n
Dies wird ihnen helfen, effektive Testf\u00e4lle zu erstellen, um potenzielle Sicherheitsl\u00fccken aufzudecken und einen maximalen Prozentsatz an Testabdeckung zu gew\u00e4hrleisten.<\/p>\n\n
Wir wissen jetzt, dass der Zweck von White-Box-Tests darin besteht, die Struktur des Codes zu \u00fcberpr\u00fcfen, z. B. Schleifenanweisungen, bedingte Anweisungen, Entscheidungszweige usw. Wir werden es anhand eines einfachen Beispiels verstehen:<\/p>\n\n
Test (a, b)\n{\nint n;\nwenn (n % 2 ==0)\n{\nprint(\"Ungerade Zahl\")\n}\nsonst\n{\nprint(\"Ungerade Zahl\")\n}\n}<\/pre>\n\nUm diesen Code zu \u00fcberpr\u00fcfen, haben wir die folgenden zwei Testf\u00e4lle: <\/p>\n\n
F\u00fcr den ersten Testfall, n = 25, gilt die „wenn“-Bedingung nicht. Der Programmablauf bewegt sich daher zum ‚else‘-Block und gibt die darin enthaltene Anweisung aus. Im zweiten Testfall, n = 50, ist die „if“-Bedingung wahr und die darin enthaltene Anweisung wird ausgef\u00fchrt. <\/p>\n\n
Auf diese Weise durchlief das White-Box-Testing jede Zeile des Quellcodes der Anwendung und deckte m\u00f6gliche Fehler auf Code-Ebene auf. <\/p>\n\n
Die verschiedenen Arten von White-Box-Testing-Techniken sind wie folgt: <\/p>\n\n
1. Abdeckung der Erkl\u00e4rung<\/strong><\/p>\n\n Bei dieser Technik m\u00fcssen Sie jede Anweisung im Quellcode mindestens einmal durchgehen und testen. Infolgedessen wird der gesamte Quellcode ge\u00fcbt. <\/p>\n\n Die Anweisungsabdeckung bestimmt den Prozentsatz des Quellcodes, der von einer bestimmten Gruppe von Testf\u00e4llen bearbeitet wird. Die Formel zur Deckung der Aussagen lautet: <\/p>\n\n Erfassungsgrad = (Anzahl der abgegebenen Erkl\u00e4rungen \/ Gesamtzahl der Erkl\u00e4rungen) * 100<\/strong><\/p>\n\n 2. Erfassungsbereich der Entscheidung\/Filiale<\/strong><\/p>\n\n Das beste Beispiel f\u00fcr eine Verzweigung (Entscheidungspunkt) in der Programmierung ist die „if“-Anweisung. Sie hat zwei Zweige – Wahr und Falsch. Die Technik der Verzweigungsabdeckung stellt sicher, dass jede Verzweigung im Quelltext mindestens einmal ausgef\u00fchrt wird.<\/p>\n\n Die Verzweigungsabdeckung ist der Prozentsatz der Verzweigungen oder Entscheidungspunkte, die w\u00e4hrend des Tests ausgef\u00fchrt werden.<\/p>\n\n Zweigabdeckung = (Anzahl der implementierten Zweige \/ Gesamtzahl der Zweige) * 100%<\/strong><\/p>\n\n 3. Bedingung Abdeckung<\/strong><\/p>\n\n Beim Bedingungstest wird jede Bedingung sowohl auf TRUE als auch auf FALSE getestet. Um eine 100%ige Zustandsabdeckung zu erreichen, muss also jede Bedingung sowohl f\u00fcr TRUE als auch f\u00fcr FALSE Ergebnisse angewendet werden. F\u00fcr n Bedingungen gibt es 2n Testskripte.<\/p>\n\n Das prim\u00e4re Ziel der Bedingungsabdeckung ist es, die Ausgabe jeder Bedingung im Quellcode zu bestimmen. Es werden jedoch nur die Bedingungen mit logischen Operanden getestet, deren Ergebnis entweder wahr oder falsch ist.<\/p>\n\n 4. Pr\u00fcfung unter mehreren Bedingungen<\/strong><\/p>\n\n Ihr Ziel ist es, alle m\u00f6glichen Kombinationen der einzelnen Zust\u00e4nde in der Verzweigung zu testen. Lassen Sie uns dies anhand eines Beispiels erl\u00e4utern.<\/p>\n\n Die Testf\u00e4lle f\u00fcr den obigen Code werden sein:<\/p>\n\n A=TRUE, B=TRUE<\/p>\n\n A=TRUE, B=FALSE<\/p>\n\n A=FALSE, B=TRUE<\/p>\n\n A=FALSCH, B=FALSCH<\/p>\n\n Unser Beispiel hat 2 Bedingungen – A und B und 4 Testf\u00e4lle. Wenn es 3 Ausdr\u00fccke g\u00e4be, w\u00e4re die Anzahl der Testf\u00e4lle 8.<\/p>\n\n F\u00fcr eine 100%ige Abdeckung ben\u00f6tigen wir also 2n Testskripte. Das ist sehr anstrengend und es ist sehr schwierig, eine 100%ige Abdeckung zu erreichen.<\/p>\n\n 5. Pfadpr\u00fcfung<\/strong><\/p>\n\n Pfad-Tests stellen sicher, dass alle m\u00f6glichen Pfade im Quellcode mindestens einmal ausgef\u00fchrt werden. Dabei wird ein Kontrollflussdiagramm mit Hilfe von Quellcode oder einem Flussdiagramm erstellt. Sp\u00e4ter wird die zyklomatische Komplexit\u00e4t bestimmt, die sich auf unabh\u00e4ngige Pfade bezieht. Daher erstellen die Tester minimale Testf\u00e4lle f\u00fcr solche unabh\u00e4ngigen Pfade. <\/p>\n\n Abdeckung der Fahrten = (Anzahl der durchgef\u00fchrten Fahrten \/ Gesamtzahl der Fahrten im Programm) x 100 %<\/strong><\/p>\n\n 6. Pr\u00fcfung von Schleifenzyklen<\/strong><\/p>\n\n Zyklen sind g\u00e4ngige Programmkonstrukte und werden in den meisten gro\u00dfen Programmen verwendet. Zyklustests sind unerl\u00e4sslich, da die Wahrscheinlichkeit von Fehlern am Anfang oder Ende eines Zyklus hoch ist. Daher werden bei der Durchf\u00fchrung von Tests Fehler oder Bugs in einem bestimmten Zyklus aufgedeckt. Der Hauptfehler, der bei den Zyklen auftritt, sind falsche Indizes.<\/p>\n\n Hier sind die verschiedenen Arten von White-Box-Tests: <\/p>\n\n Unit-Testing:<\/strong> Dies ist die erste Stufe des Softwaretests. Es testet jedes Anwendungsmodul, eine sogenannte Unit, einzeln auf seine Korrektheit. Stellt sicher, dass jede Komponente die erwartete Leistung erbringt.<\/p>\n\n Integrationstests:<\/strong> Diese kommen nach den Einheitstests. Sie kombiniert die einzelnen getesteten Komponenten logisch und best\u00e4tigt das Zusammenspiel zwischen ihnen. Ihr Ziel ist es, Fehler im Zusammenspiel der Komponenten zu erkennen. <\/p>\n\n White-Box-Penetrationstests: <\/strong>Die Tester haben vollen Zugriff auf den Quellcode der Anwendung sowie auf Netzwerk-, IP- und Serverdaten, einschlie\u00dflich Passw\u00f6rtern und Karten. Das Hauptziel von Penetrationstests ist das Aufsp\u00fcren von Bereichen des Quellcodes mit Sicherheitsschw\u00e4chen. <\/p>\n\n White-Box-Mutationstests:<\/strong> Wie der Name schon sagt, h\u00e4ngen die Mutationstests von \u00c4nderungen ab. Die Tester nehmen geringf\u00fcgige \u00c4nderungen am Quellcode vor, um sicherzustellen, dass bei der Ausf\u00fchrung der Testf\u00e4lle keine Fehler gefunden werden. Wenn die Testf\u00e4lle erfolgreich sind, deutet dies auf einen Fehler im Quellcode hin. Wenn die Testf\u00e4lle jedoch fehlschlagen, ist der Quellcode fehlerfrei.<\/p>\n\n Lassen Sie uns nun die Vor- und Nachteile von White-Box-Tests kl\u00e4ren. <\/p>\n\n Hier finden Sie eine Liste einiger h\u00e4ufig verwendeter White-Box-Tools: <\/p>\n\n Die folgende Tabelle verdeutlicht die wichtigsten Unterschiede zwischen der Pr\u00fcfung von schwarzen und wei\u00dfen Schr\u00e4nken:<\/p>\n\n White-Box-Tests sind eine Softwaretesttechnik, die von den Testern ein umfassendes Verst\u00e4ndnis der inneren Funktionsweise und der Codestruktur einer Anwendung erfordert. Sie zeigt daher strukturelle und sicherheitstechnische L\u00fccken auf. Das Hauptziel besteht darin, die Funktionalit\u00e4t und Korrektheit der Anwendung auf der Code-Ebene zu \u00fcberpr\u00fcfen. <\/p>\n\n Diese Testtechnik ist zwar zeit- und arbeitsaufwendig, aber die einzige M\u00f6glichkeit, um sicherzustellen, dass Sie jede Zeile Ihres Quellcodes testen. Wenn sie richtig durchgef\u00fchrt werden, k\u00f6nnen White-Box-Tests die Qualit\u00e4t der Software erheblich verbessern.<\/p>\n","protected":false},"excerpt":{"rendered":" Bei White-Box-Tests werden das interne Design des Systems, die Struktur des Quellcodes, die verwendeten Datenstrukturen und die Arbeitsdetails getestet. <\/p>\n","protected":false},"author":8,"featured_media":1425,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[18],"tags":[],"class_list":["post-415","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-manuelles-testen"],"acf":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/ittester.sk\/de\/wp-json\/wp\/v2\/posts\/415","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/ittester.sk\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/ittester.sk\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/ittester.sk\/de\/wp-json\/wp\/v2\/users\/8"}],"replies":[{"embeddable":true,"href":"https:\/\/ittester.sk\/de\/wp-json\/wp\/v2\/comments?post=415"}],"version-history":[{"count":9,"href":"https:\/\/ittester.sk\/de\/wp-json\/wp\/v2\/posts\/415\/revisions"}],"predecessor-version":[{"id":1427,"href":"https:\/\/ittester.sk\/de\/wp-json\/wp\/v2\/posts\/415\/revisions\/1427"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/ittester.sk\/de\/wp-json\/wp\/v2\/media\/1425"}],"wp:attachment":[{"href":"https:\/\/ittester.sk\/de\/wp-json\/wp\/v2\/media?parent=415"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/ittester.sk\/de\/wp-json\/wp\/v2\/categories?post=415"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/ittester.sk\/de\/wp-json\/wp\/v2\/tags?post=415"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}wenn (A||B) \ndrucken C<\/pre>\n\n
Arten von White-Box-Tests<\/h2>\n\n
Vor- und Nachteile von White-Box-Tests <\/h2>\n\n
Vorteile <\/h2>\n\n
\n
Benachteiligungen <\/h2>\n\n
\n
White Box Testing Tools <\/h2>\n\n
\n
Der Unterschied zwischen White- und Blackbox-Tests<\/h2>\n\n
White Box-Tests<\/strong><\/td> Black-Box-Tests<\/strong><\/td><\/tr> Erfordert Kenntnisse \u00fcber die interne Struktur und Funktionsweise der Anwendung.<\/td> Es sind keine internen Kenntnisse der Anwendung erforderlich.<\/td><\/tr> Wir k\u00f6nnen viele detaillierte Aspekte der Anwendung testen.<\/td> Wir testen die End-to-End-Funktionalit\u00e4t der Anwendung.<\/td><\/tr> Diese Tests werden von Entwicklern oder QA-Fachleuten mit guten Kenntnissen der Programmierung und Anwendungsarchitektur durchgef\u00fchrt.<\/td> Die Blackbox-Tests werden von einem unabh\u00e4ngigen Qualit\u00e4tskontrollteam durchgef\u00fchrt.<\/td><\/tr> Gilt f\u00fcr niedrigere Testebenen – Einheitstests und Integrationstests.<\/td> Sie gilt f\u00fcr h\u00f6here Testebenen – Systemtests und Akzeptanztests, bei denen wir die Anwendung als Ganzes testen m\u00fcssen.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n Schlussfolgerung<\/h2>\n\n