structural testing tutorial what is structural testing
In diesem umfassenden Tutorial zu Strukturtests wird erläutert, was Strukturtests sind, welche Typen sie haben, was Kontrollflusstests und Kontrollflussdiagramme sind, Deckungsgrade usw.:
Eine schnelle Google-Suche nach einigen der teuersten Software-Fehler hat mich in den Bann gezogen - 500 Milliarden US-Dollar. Ja, so teuer kann ein Fehler werden. Das Lesen von Informationen zu Todesfällen in der Transport- und Gesundheitsbranche aufgrund eines Softwarefehlers kann ebenfalls schrecklich sein.
Während Fehler im Code nicht immer so extrem sind, wenn sie den Verlust von viel Geld und Leben zur Folge haben, ist der einzige wichtige Aspekt, den wir hier vermitteln möchten, dass man das Testen nicht übersehen kann.
Wenn im gesamten SDLC häufig Tests durchgeführt werden, können wir Fehler erkennen, deren Behebung nach dem Versand des Produkts viel mehr Zeit in Anspruch nehmen würde.
Was von Bedeutung ist, sind die von uns ausgewählten Softwaretesttypen. Es gibt mehrere davon, einschließlich funktionaler, struktureller und veränderungsbasierter Tests.
In diesem Lernprogramm werden auch strukturelle Testtypen erläutert. Erfahren Sie anhand von Beispielen und Erklärungen ausführlich, wie Mutationstests, Slice-basierte Tests und Datenflusstests durchgeführt werden.
Was du lernen wirst:
- Warum ist das Testen von Software wichtig?
- Was ist Strukturprüfung?
- Strukturprüftypen
- Vor- und Nachteile von Strukturprüfungen
- Best Practices für Strukturtests
- Fazit
Warum ist das Testen von Software wichtig?
Neben dem Sparen von Geld und der Vermeidung von Katastrophen wie den oben genannten Fällen gibt es mehrere andere Gründe, um die Bedeutung von Tests zu rechtfertigen.
Nachfolgend sind einige Gründe aufgeführt:
# 1) Um sicherzustellen, dass die festgelegten Anforderungen erfüllt werden bevor Sie mit dem Erstellen eines Projekts beginnen. Stakeholder (z. B. Entwickler und Kunden) müssen sich auf alle Aspekte der Lösung / des Produkts / der Software einigen, die zum Erstellen eines Projekts erforderlich sind.
Beim Testen wird überprüft, ob die Softwareanforderungen erfüllt sind. Der Entwickler oder das Unternehmen, das an der Erstellung der Lösung beteiligt ist, hat auch einen guten Ruf für die Entwicklung einer solch hochwertigen Lösung, die von Eclat-Code ausgeführt wird.
# 2) Es wird überprüft, ob die Codefunktion wie beabsichtigt funktioniert. Zum Testen gehört auch die Überprüfung der Funktionalität der Software. Im Falle einer Fehlfunktion sollte diese in den frühen Phasen von SDLC (Software Development Life Cycle) behoben werden.
# 3) Es prüft auf Leistung: Zum Beispiel um die Gesamtzeit zu ermitteln, die beim Ausführen von Code vergangen ist. Wenn wir mehrere verwenden Für Schleifen In unserem Code dauert es lange, bis die beabsichtigte Ausgabe erreicht ist, und manchmal kann es sogar zu einer Zeitüberschreitung kommen.
# 4) Es hilft, eine bessere Benutzererfahrung zu erreichen. Benutzer werden es nicht genießen, Software zu verwenden, die fehlerhaft, fehlerhaft oder zu langsam ist. Benutzer werden wahrscheinlich ungeduldig und verlassen die Software. Durch Tests können wir besser sicherstellen, dass Benutzer unsere Produkte problemlos verwenden können.
# 5) Es prüft auf Skalierbarkeit. Ein Entwickler sollte darauf abzielen, skalierbare Software zu erstellen.
# 6) Es prüft auf Schwachstellen im Code. Durch Tests haben wir die Möglichkeit, nach Sicherheitslücken Ausschau zu halten. Beispielsweise, Code, der Kompromisse eingehen kann PII (Persönlich identifizierbare Informationen), die für die DSGVO eine hohe Priorität haben.
In diesem Artikel konzentrieren wir uns auf eine Art von Tests, d. H. Strukturprüfung . Wie der Name schon sagt, hat dies mit der Struktur des Codes zu tun. Dies unterscheidet sich von dem, was wir zuvor erwähnt haben. Das Testen hilft dabei, Aspekte wie Codeleistung, Funktionalität und Sicherheit zu bestimmen.
Strukturprüfung gegen andere Prüfarten
Es gibt viele Arten von Softwaretests. Die STOP (International Software Testing Qualifications Board) definiert 4 Haupttypen von Softwaretests, nämlich
Was ist der beste YouTube-Konverter
- Funktionell
- Nicht funktionsfähig
- Strukturell
- Änderungsbasiert
Die Unterschiede können wie folgt erklärt werden:
Funktionsprüfung: Dies beinhaltet die Überprüfung der Funktionalität der Software anhand der festgelegten Anforderungen. Testdaten werden als Eingabe verwendet. Wir überprüfen auch, ob die angegebene Ausgabe wie erwartet ist.
Nichtfunktionale Prüfung : Dies beinhaltet einen Testprozess, um zu analysieren, wie gut die Software funktioniert. zum Beispiel, die Anzahl der Benutzer, die gleichzeitig verarbeitet werden können.
Strukturprüfung: Diese Art des Testens basiert auf der Struktur des Codes. Beispielsweise, Wenn ein Code den Durchschnitt gerader Zahlen in einem Array berechnen soll, wären strukturbasierte Tests eher an den „Schritten interessiert, die zur Berechnung des Durchschnitts führen“, als daran, ob die endgültige Ausgabe ein korrekter numerischer Wert ist.
Angenommen, wir müssen prüfen, ob wir den Code definiert haben, der gerade Zahlen von ungeraden Zahlen unterscheidet. Wir können hier eine bedingte Anweisung haben, wie wenn ein Array-Element ohne Rest durch zwei teilbar ist, if (arr (i)% 2 === 0) dann kann die Zahl als gerade Zahl gesagt werden.
Strukturprüfungen werden von denselben Personen durchgeführt, die den Code so schreiben, wie sie ihn am besten verstehen.
Änderungsbasiertes Testen : Dazu müssen die Auswirkungen von Änderungen am Code getestet und anschließend sichergestellt werden, dass die vorgenommenen Änderungen implementiert wurden. Es stellt auch sicher, dass die Änderungen am Code ihn nicht beschädigen.
Was strukturelle Tests nicht sind
Wir haben bereits erwähnt, dass sich strukturbasiertes Testen auf die Struktur des Codes bezieht. Beachten Sie, dass wir uns hier mit dem eigentlichen Code befassen. Wir prüfen nicht die Anforderungen und testen die Eingaben nicht einmal anhand der erwarteten Ausgaben. An dieser Stelle geht es uns nicht um Funktionalität, Benutzererfahrung oder Leistung.
Was ist Strukturprüfung?
Strukturbasiertes Testen kann daher als eine Art von Softwaretest definiert werden, bei dem die Struktur des Codes und die beabsichtigten Abläufe getestet werden. Beispielsweise, Überprüfen des tatsächlichen Codes auf Aspekte wie die korrekte Implementierung von bedingten Anweisungen und ob jede Anweisung im Code korrekt ausgeführt wird. Es wird auch als strukturbasiertes Testen bezeichnet.
Um diese Art von Tests durchführen zu können, müssen wir den Code gründlich verstehen. Aus diesem Grund werden diese Tests normalerweise von den Entwicklern durchgeführt, die den Code so geschrieben haben, wie sie ihn am besten verstehen.
Durchführung von Strukturprüfungen
Um verschiedene Aspekte des Codes zu testen, müssen wir zuerst die Kontrollabläufe verstehen.
Kontrollflusstest
Dies leitet Tests aus den Kontrollflüssen des Codes ab (die Reihenfolge, in der Anweisungen, Funktionen und verschiedene Aspekte des Codes implementiert werden).
Kontrollfluss-Testprozess:
Kontrollflussdiagramm
Der Kontrollflussprozess beginnt mit der Erstellung einer visuellen Darstellung verschiedener Abschnitte des Codes, mit deren Hilfe wir die Pfade definieren können, denen während der Ausführung gefolgt werden kann.
Diese visuellen Darstellungen werden als Kontrollflussdiagramme (Control Flow Graphs, CFGs) bezeichnet und bestehen aus mehreren Komponenten wie Knoten, Kanten, Pfaden, Kreuzungen und Entscheidungspunkten. Das Diagramm kann manuell oder automatisch erstellt werden, wobei Software zum Extrahieren des Diagramms aus dem Quellcode verwendet wird.
Schauen wir uns die folgenden Komponenten an:
# 1) Prozessblock
Dieser Teil wird verwendet, um einen Codeabschnitt darzustellen, der nacheinander ausgeführt wird. Dies bedeutet, dass es jedes Mal auf die gleiche Weise ausgeführt wird und keine Entscheidungen oder Verzweigungen getroffen werden müssen. Es besteht aus Knoten mit einem Ein- und Ausgangspfad.
Beispiel eines Prozessblocks:
(Bild Quelle ))
Der Prozessblock ist kein wesentlicher Bestandteil des Kontrollflusses und muss daher nur einmal getestet werden.
# 2) Entscheidungspunkte
Dies sind einige Schlüsselkomponenten im Kontrollfluss des Codes. Innerhalb dieser Knoten werden Entscheidungen getroffen. Dies erfolgt normalerweise durch Vergleich und der Kontrollfluss ändert sich je nach Entscheidung. Dieser Teil der CFG besteht aus einem Knoten mit mindestens 2 Ausgängen.
Die hier getroffene Entscheidung könnte bedingte Anweisungen wie if-else-Anweisungen (die zwei mögliche Ausgaben haben) und case-Anweisungen (die mehr als zwei Ausgaben haben können) sein.
(Bild Quelle ))
Im obigen Diagramm gibt es einen Entscheidungspunkt (ab dem bedingten „Alter = 18“), auf den die Optionen „Ja“ oder „Nein“ folgen.
# 3) Verbindungspunkte
Aus dem obigen Diagramm können wir leicht Verbindungspunkte identifizieren, an denen sich die Entscheidungspunkte verbinden. Knotenpunkte können viele Eintrittspfade haben, aber nur einen Ausgangspfad.
Best Practices für Kontrollflussdiagramme:
Beim Erstellen von Kontrollflussdiagrammen sind einige Dinge zu beachten:
- Versuchen Sie so viel wie möglich, um die CFG einfach zu halten. Wir können dies tun, indem wir Teile kombinieren, die als „weniger bedeutsam“ angesehen werden können. zum Beispiel, Prozessblöcke.
- Stellen Sie sicher, dass an Entscheidungspunkten nur eine Entscheidung getroffen wird. Bei komplexeren CFGs gibt es „Konsequenzen“, die sich nach der Entscheidung ergeben. In unserem obigen Beispiel könnten wir auch hinzufügen, dass eine Person, die 18 Jahre oder älter ist, berechtigt ist und ein Ticket bezahlen muss. Ist dies nicht der Fall, ist der Eintritt frei. Bei der Entscheidung 'Sonst' müssen einige Knoten 'übersprungen' werden, und alle diese Schritte müssen in unserer CFG angezeigt werden.
Nachdem wir unsere CFG definiert haben, ist es jetzt an der Zeit, mit dem nächsten Schritt im Kontrollfluss-Testprozess fortzufahren, d. H. Zu definieren, inwieweit wir den Code testen werden.
Definieren, wie viel getestet werden soll:
Wie viel des Quellcodes sollte getestet werden? Sollten wir jeden möglichen Pfad testen? Der Versuch, in unseren Tests alle Pfade abzudecken, ist praktisch unmöglich. Wir müssen einen Mittelweg finden, um zu bestimmen, wie viele Tests wir durchführen können.
Wenn wir sagen, dass wir 50% unseres Codes testen möchten, könnte dies bedeuten, dass wir alle ausführbaren Code-Anweisungen definieren und mindestens die Hälfte davon testen. Hier stellt sich jedoch die Frage: Müssen wir dann alle möglichen ausführbaren Pfade definieren?
Dies kann wiederum praktisch unmöglich sein. Ein besserer Ansatz könnte darin bestehen, 50% der Pfade zu testen, die wir in jedem Abschnitt des Codes identifizieren können.
Es gibt verschiedene Ebenen der Abdeckung, nämlich Anweisung, Zweig und Pfadabdeckung. Wir werden sie später kurz betrachten.
Testfälle erstellen:
Der nächste Schritt ist das Erstellen der Testfälle, die wir verwenden werden. Die Testfälle bei strukturbasierten Tests basieren auf folgenden Faktoren:
- Die ausführbaren Anweisungen.
- Die „Entscheidungen“, die getroffen werden müssen.
- Die möglichen Pfade, denen gefolgt werden kann.
- Die Bedingungen, die erfüllt sein müssen (diese können mehrfach oder boolesch sein).
Die oben genannten Faktoren geben uns eine Vorstellung von den Arten von Testfällen, die wir erstellen müssen. Wir können auch ein Tool zur Generierung von Strukturtests verwenden. Wenn unser Code in der Programmiersprache C vorliegt, können wir mit PathCrawler Testcode generieren. Ein weiteres Tool, das wir verwenden können, ist fMBT.
Ausführen der Testfälle:
Hier können wir die Tests durchführen. Wir können Eingaben oder Daten eingeben, um zu überprüfen, wie der Code sie ausführt, und dann überprüfen, ob wir die erwarteten Ergebnisse erhalten. Beispielsweise, Geben Sie ein Array in einen Funktionsaufruf ein, um festzustellen, welche Ergebnisse wir nach dem Durchlaufen erhalten, oder um zu überprüfen, ob die Entscheidungspunkte die richtigen Entscheidungen treffen.
Analyse der Ergebnisse:
In diesem Teil überprüfen wir lediglich, ob wir nach der Ausführung die richtigen Ergebnisse erhalten. Beispielsweise, Wenn wir ein Array eingeben, in dem alle Werte über 18 liegen, sollten wir alle Entscheidungspunkte haben, die zu 'förderfähig' führen.
Annahmen zum Kontrollfluss
Es ist wichtig zu beachten, dass für die Durchführung von Kontrollflusstests einige Annahmen getroffen werden. Diese schließen ein:
- Die einzigen vorhandenen Fehler sind solche, die den Kontrollfluss beeinflussen können.
- Alle Variablen, Funktionen und Elemente sind genau definiert.
Abdeckungsgrade in Kontrollflüssen
Wie bereits erwähnt, gibt es bei Kontrollflusstests unterschiedliche Abdeckungsgrade.
Schauen wir sie uns kurz an.
# 1) Statement Coverage
Bei strukturellen Tests spielen ausführbare Codeanweisungen eine wichtige Rolle bei der Entscheidung über die Methoden zum Entwerfen der Tests.
Wir streben eine 100% ige Abdeckung an, was bedeutet, dass jede ausführbare Anweisung mindestens einmal getestet wurde. Je höher die Abdeckung, desto geringer ist die Wahrscheinlichkeit, dass Fehler und Fehler übersehen werden.
Hier müssen Testfälle verwendet werden. Die Daten, die wir benötigen, sollen sicherstellen, dass jede ausführbare Anweisung in einem Codeblock mindestens einmal ausgeführt wird.
# 2) Zweigabdeckung
Dieser Abdeckungsgrad umfasst das Testen der Punkte in den CFG-Zweigen (wo Entscheidungen getroffen werden). Die Ergebnisse sind boolesch. Selbst wenn eine switch-Anweisung verwendet wird und es mehrere Ergebnisse gibt, ist jeder Fallblock im Wesentlichen ein Vergleich eines Wertepaars.
Genau wie bei der Kontoauszugsabdeckung sollten wir eine 100% ige Zweigstellenabdeckung anstreben. Um dies zu erreichen, müssen wir jedes Ergebnis auf jeder Entscheidungsebene mindestens einmal testen. Da es sich um boolesche Ergebnisse handelt, sollten wir versuchen, mindestens 2 Tests pro Codeabschnitt durchzuführen.
# 3) Pfadabdeckung
Dieser Abdeckungsgrad ist im Vergleich zur Abdeckung von Entscheidungen und Aussagen gründlicher. Ziel ist es, alle möglichen Pfade zu „entdecken“ und mindestens einmal zu testen. Dies kann sehr zeitaufwändig sein. Es kann jedoch helfen, Fehler oder Fehler in unserem Code oder sogar Aspekte zu entdecken, die wir definieren müssen. zum Beispiel, Benutzereingabe.
Strukturprüftypen
(Bild Quelle ))
Mutationstests
Mutationstests sind fehlerbasierte Testtechniken, bei denen verschiedene Variationen einer Softwareanwendung anhand des Testdatensatzes getestet werden.
>> In diesem Tutorial finden Sie ausführliche Informationen Mutationstests.
Scheibenbasiertes Testen
Slice Based Testing (SBT) kann als eine Software-Testtechnik definiert werden, die auf basiert Scheiben - ausführbare Teile des Programms oder Gruppen von Anweisungen, die einige Werte an bestimmten Punkten des Programms beeinflussen, zum Beispiel, Teile, in denen Variablen definiert sind, oder die Ausgabe einer Gruppe von Anweisungen.
So schneiden Sie
Schnittbeispiel in SBT: Code zum Ausdrucken von geraden und ungeraden Zahlen (Python)
num_list = range(1,12) even_nums = () odd_nums = () for var in num_list: if var%2==0: even_nums.append(var) print(f'Even numbers: {even_nums}') elif var%3==0: odd_nums.append(var) print(f'Odd numbers: {odd_nums}') 
Es gibt zwei Möglichkeiten, eine Scheibe zu betrachten: Folgen Sie dem Pfad einer interessierenden Variablen oder dem Teil des Codes, der die Ausgabe beeinflusst.
Wenn wir in unserem Beispiel die Ausgabe von ungeraden Zahlen betrachten, können wir den Teil des Codes verfolgen, der uns zu dieser Ausgabe führt.
In den von Mark Weiser (der SBT eingeführt hat) angegebenen Schnittkriterien wird ein Schnitt nach folgender Formel definiert: S (v, n) , wo, v bezieht sich auf die betreffende Variable ( zum Beispiel, wo eine Variable definiert ist) und n ist die Interessenerklärung ( zum Beispiel, wo Ausgabe gegeben ist) und S. steht für die Scheibe.
Um das Slice zu erhalten, beginnen wir im obigen Beispiel mit unserer Ausgabe in Zeile 10, die zu unserer wird n . Unsere Variable ist wo .
Unsere Schnittkriterien sind also:
S(v,n) = S(var,10)Unser Anliegen sind die Aussagen, die uns zum Output führen.
Diese sind:
10,9,8,4,3,1
Unser Slice in diesem Code lautet also:
num_list = range(1,12) odd_nums = () for var in num_list: elif var%3==0: odd_nums.append(var) print(f'Odd numbers: {odd_nums}')
Scheibenbasierte Testtypen
Es gibt zwei Arten von SBT: statisch und dynamisch
# 1) Dynamisches Slice-basiertes Testen
Das oben erläuterte SBT-Beispiel, in dem wir uns die Aussagen angesehen haben, die sich auf das Drucken der ungeraden Zahlen auswirken, ist dynamisches SBT. Unser Anliegen ist sehr spezifisch. Wir können uns nur auf das konzentrieren, was sich direkt auf die jeweilige Ausgabe auswirkt.
Wir führen den Code aus und verwenden Testdaten, um sicherzustellen, dass er ordnungsgemäß funktioniert. Wir könnten die Reichweite auf Reichweite erhöhen (1,50), zum Beispiel, um zu sehen, ob es immer noch nur ungerade Zahlen erzeugt. Dynamisches SBT wird auch als Validierungstest bezeichnet.
# 2) StatischScheibenbasiertes Testen
Im Gegensatz zu Dynamic SBT liegt der Fokus der statischen Tests auf einer bestimmten Variablen. Wenn wir über unsere Ausgabe im obigen Beispiel nachdenken als wo können wir das Slice, das es betrifft, als verfolgen 10,9,8,7,6,5,4,3,2,1
Es ist im Grunde der gesamte Codeblock! Hier überprüfen wir, ob der Code in Bezug auf Syntax und Anforderungen korrekt ist, und führen ihn nicht aus. Statisches SBT wird auch als Verifikationstest bezeichnet.
Es ist wichtig zu beachten, dass die dynamische SBT im Vergleich zu ihrer statischen Gegenleistung „kleiner“ ist. Es ist auch spezifischer.
Best Practices / Richtlinien für schnittbasiertes Testen
Die Schnittkriterien sollten bestimmt werden durch:
- Anweisungen, bei denen Werte definiert oder Werte zugewiesen werden, sowie neu zugewiesene Werte.
- Anweisungen, bei denen Werte von außerhalb des Programms empfangen werden, zum Beispiel, über Benutzereingaben.
- Anweisungen, die die Ausgabe drucken / zurückgeben.
- Die letzte Aussage des Programms, zum Beispiel, Ein Funktionsaufruf, der Werte definieren oder Werte für Argumente bereitstellen kann
Zu den Vorteilen von Slice-basierten Tests gehören:
- Da wir in SBT nur mit bestimmten Interessengebieten arbeiten, ist es einfacher, Testsuiten effektiv zu generieren.
- Der Pfad wird durch Abhängigkeiten innerhalb des Codes definiert, was besser ist als die Verwendung Pfadabdeckung.
- Mit SBT ist es einfacher, Fehler im Quellcode zu finden.
Zu den Nachteilen von Slice-basierten Tests gehören:
- Wenn wir beim Testen einer großen Codebasis dynamische Tests verwenden, benötigen wir viele Rechenressourcen.
- Wenn wir statische Tests verwenden, werden wir möglicherweise Fehler verpassen.
Datenflusstest
Datenflusstests können als Softwaretesttechniken definiert werden, die auf Datenwerten und deren Verwendung in einem Programm basieren. Es wird überprüft, ob die Datenwerte ordnungsgemäß verwendet wurden und die richtigen Ergebnisse liefern. Mithilfe von Datenflusstests können Sie die Abhängigkeiten zwischen Datenwerten auf einem bestimmten Ausführungspfad verfolgen.
Datenflussanomalien
Datenflussanomalien sind einfach Fehler in einem Softwareprogramm. Sie werden in die Typen 1, 2 und 3 eingeteilt.
Lassen Sie uns im Folgenden näher darauf eingehen:
Typ 1: Eine Variable wird definiert und ihr zweimal ein Wert zugewiesen.
Beispielcode: Python
lst_1 = (1,2,3,4) lst_1 = (5,6,7,8) for var in lst_1: print(var) 
Lst_1 definiert ist und ihm zwei verschiedene Werte zugewiesen werden. Der erste Wert wird einfach ignoriert. Typ-1-Anomalien führen nicht zum Fehlschlagen des Programms.
Typ 2: Der Wert einer Variablen wird verwendet oder referenziert, bevor sie definiert wird.
Beispielcode: Python
for var in lst_1: print(var) 
Die obige Schleife enthält keine Werte, über die iteriert werden kann. Anomalien vom Typ 2 führen zum Fehlschlagen des Programms.
Typ 3: A. Datenwert wird generiert, aber nie verwendet.
Beispielcode: Python
lst_1 = (1,2,3,4) lst_2 = (5,6,7,8) for var in lst_1: print(var) 
Die Variable lst_2 wurde nicht referenziert. Typ 3-Anomalien können keinen Programmfehler verursachen.
Datenflusstestprozess
Um die Abhängigkeiten zwischen Datenwerten zu definieren, müssen wir die verschiedenen Pfade definieren, denen in einem Programm gefolgt werden kann. Um dies effektiv zu tun, müssen wir uns von einem anderen strukturellen Testtyp ausleihen, der als bekannt ist Kontrollflussprüfung .
Schritt 1) Zeichnen Sie ein Kontrollflussdiagramm
Wir müssen ein Kontrollflussdiagramm zeichnen, das eine grafische Darstellung der Pfade ist, denen wir in unserem Programm folgen könnten.
Beispielcode: Python
cost = 20 y = int(input('How many visitor seats did you reserve? ')) x = int(input('How many member seats did you reserve? ')) if y>x: bill = cost -1 else: bill = cost print(bill) 
Im obigen Codebeispiel sollte ein Mitglied einen Rabatt erhalten, wenn es einen Besucher einlädt.
Kontrollflussdiagramm (CFG):
Schritt 2) Erforschen Sie die Definition und Verwendung von Variablen und Datenwerten.
Eine Variable in einem Programm wird entweder definiert oder verwendet. In CFG haben wir Variablen an jedem Knoten. Jeder Knoten wird nach dem darin enthaltenen Variablentyp benannt. Wenn eine Variable an einem bestimmten Knoten definiert ist, wird ein definierender Knoten erstellt. Wenn eine Variable an einem Knoten verwendet wird, wird ein Verwendungsknoten erstellt.
Wenn wir die variablen Kosten in CFG berücksichtigen, sind dies die Definitions- und Verwendungsknoten:
| Knoten | Art | Code |
|---|---|---|
| ein | Knoten definieren | Kosten = 20 |
| 5 | Verwendungsknoten | Rechnung = Kosten -1 |
| 7 | Verwendungsknoten | Rechnung = Kosten |
Schritt 3) Definieren Sie Definitionsverwendungspfade.
Es gibt zwei Arten von Definitionsverwendungspfaden: du Pfade und Gleichstrompfade. du-Pfade sind Definitionspfade, die mit einem Definitionsknoten beginnen und mit einem Verwendungsknoten enden. Dies ist der Fall für den Pfad in Bezug auf die obigen variablen Kosten.
Ein Beispiel für einen Gleichstrompfad, einen Pfad zum Löschen von Entscheidungen, ist der Pfad in Bezug auf die Rechnungsvariable wie folgt:
| Knoten | Art | Code |
|---|---|---|
| 5 | Knoten definieren | Rechnung = Kosten -1 |
| 7 | Knoten definieren | Rechnung = Kosten |
| 8 | Verwendungsknoten | drucken (Rechnung) |
Der DC-Pfad hat mehr als einen Definitionsknoten, obwohl er immer noch an einem Verwendungsknoten endet.
Schritt 4) Erstellen Sie die Testsuite.
Dies fügt Eingaben hinzu. Beachten Sie, dass wir für jede Variable eine andere Testsuite benötigen. Die Testsuite hilft uns dabei, Datenflussanomalien zu identifizieren.
Arten von Datenflusstests
Es gibt zwei Arten - Statisch und dynamisch .
Statisch bedeutet, dass wir den Code und die CFG durchgehen, um Datenanomalien zu identifizieren, ohne sie auszuführen. Dynamisch bedeutet, dass wir die spezifischen Pfade tatsächlich identifizieren und dann Testsuiten erstellen, um sie zu testen, um Anomalien zu „fangen“, die wir möglicherweise während statischer Tests übersehen haben.
Vor- und Nachteile von Datenflusstests:
- Datenflusstests sind ideal zum Erkennen von Datenflussanomalien, was sie zu einer sehr effektiven strukturellen Testmethode macht.
- Der Nachteil ist, dass Sie sich mit der Sprache auskennen müssen, in der der Code geschrieben wird, um Datenflusstests durchführen zu können. Es ist auch zeitaufwändig.
Vor- und Nachteile von Strukturprüfungen
Lassen Sie uns nun die Gründe finden, warum Strukturtests ein großartiger Ansatz sind, und auch einige seiner Nachteile untersuchen.
Vorteile:
- Ermöglicht gründliche Codetests, die zu minimalen Fehlern führen. Strukturbasierte Tests bieten Raum für gründliche Tests von Software. Die unterschiedlichen Deckungsgrade - Aussage für Aussage, jeder Entscheidungspunkt und Pfad - zielen darauf ab, eine 100% ige Deckung zu erreichen, wodurch die Wahrscheinlichkeit, dass Fehler unentdeckt bleiben, erheblich verringert wird.
- Die Fähigkeit zur Automatisierung . Es gibt verschiedene Tools, mit denen wir das Testen automatisieren können. Dies hilft uns dabei, eine maximale Codeabdeckung zu erreichen und dies in kürzerer Zeit als bei manuellen Tests.
- Dies führt zu einem Code höherer Qualität . Die Entwickler haben die Möglichkeit, die Struktur und Implementierung des Codes zu untersuchen, Fehler zu beheben und diese Aspekte zu verbessern. Dies ermöglicht es uns, die großartige Struktur im Auge zu behalten, wenn wir nachfolgende Teile des Codes schreiben oder verbleibende Funktionen implementieren.
- Dies kann in jeder Phase des SDLC erfolgen - Strukturtests können in jeder Phase des SDLC durchgeführt werden, ohne darauf zu warten, dass die Entwicklung zu 100% abgeschlossen ist. Dies macht es einfach, Fehler in der frühen Phase zu erkennen und spart somit viel Zeit im Vergleich zu Tests nach Abschluss der Entwicklung.
- Es hilft, toten Code loszuwerden . Dies kann als 'zusätzlicher' oder unnötiger Code angesehen werden. zum Beispiel, Code, der ein Ergebnis berechnet, es jedoch in keiner der folgenden Berechnungen verwendet.
- Effizienz - Da die Entwickler, die den Code schreiben, dieselben sind, die ihn testen, müssen keine anderen Personen wie QAs einbezogen werden.
Nachteile:
- Die Entwickler, die strukturbasierte Tests durchführen, müssen die Sprache gründlich verstehen . Andere Entwickler und QAs, die sich mit der Sprache nicht auskennen, können beim Testen nicht helfen.
- Es kann in Bezug auf Zeit und Geld ziemlich teuer werden . Für effizientes Testen sind viel Zeit und Ressourcen erforderlich.
- Dies führt zu Verzögerungen bei der Bereitstellung von Funktionen . Dies liegt daran, dass Entwickler nicht mehr Software erstellen, um Tests durchzuführen.
- Die Skalierung ist ein Problem, insbesondere bei großen Anwendungen . Eine große Anwendung entspricht einer übermäßig hohen Anzahl von Routen, die abgedeckt werden müssen. Eine 100% ige Abdeckung wird unmöglich.
- Es können Fälle und Routen übersehen werden , zum Beispiel, in einem Fall, in dem Funktionen noch nicht vollständig entwickelt sind oder noch entwickelt werden müssen. Dies bedeutet, dass es mit anderen Testtypen wie Anforderungsprüfungen kombiniert werden muss (wobei wir anhand der angegebenen Funktionen prüfen, die erstellt werden mussten).
Best Practices für Strukturtests
Einige der Faktoren, die bei der Durchführung strukturbasierter Tests berücksichtigt werden müssen, sind folgende:
- Beschriften und benennen Sie die Tests eindeutig . Wenn jemand anderes die Tests ausführen muss, muss er sie leicht finden können.
- Stellen Sie vor dem Verbessern von Code, d. H. Durch Umgestalten und Optimieren für die Verwendung in verschiedenen Umgebungen, sicher, dass seine Struktur und sein Ablauf ideal sind.
- Führen Sie die Tests separat aus . Auf diese Weise ist es einfach, Fehler zu identifizieren und zu beheben. Andererseits ist es weniger wahrscheinlich, dass Fehler oder Pfade aufgrund von Überlappungen in Codeabschnitten, Blöcken oder Pfaden übersehen werden.
- Generieren Sie Tests, bevor Sie Änderungen vornehmen . Die Tests müssen wie erwartet ausgeführt werden. Auf diese Weise ist es einfach, das Problem zu verfolgen und zu beheben, wenn etwas kaputt geht.
- Halten Sie die Tests für jeden Abschnitt oder Codeblock getrennt . Auf diese Weise müssen wir nicht viele Tests ändern, wenn sich später Änderungen ergeben.
- Beheben Sie Fehler, bevor Sie mit dem Testen fortfahren . Wenn wir Fehler feststellen, sollten Sie diese beheben, bevor Sie mit dem Testen des nächsten Abschnitts oder Codeblocks fortfahren.
- Überspringen Sie niemals strukturelle Tests mit der Annahme, dass eine Qualitätssicherung „ohnehin noch Tests durchführt“. Selbst wenn die Fehler zunächst kumulativ unbedeutend erscheinen, können sie zu fehlerhaftem Code führen, der niemals den beabsichtigten Zweck erreichen kann.
FAQs zum strukturbasierten Testen
Hier werden wir die häufig gestellten Fragen untersuchen, wenn es um strukturbasierte Tests geht.
F # 1) Was ist der Unterschied zwischen Funktionsprüfung und Strukturprüfung?
Antworten: Funktionstests sind eine Art von Softwaretests, die auf den in der SRS (Software Requirements Specifications) festgelegten Anforderungen basieren. Dies geschieht normalerweise, um Unterschiede zwischen den Spezifikationen im SRS und der Funktionsweise des Codes festzustellen. Strukturtests basieren auf der internen Struktur des Codes und seiner Implementierung. Ein gründliches Verständnis des Codes ist erforderlich.
F # 2) Welche Arten von Strukturprüfungen gibt es?
Beantworte die Typen umfassen:
- Datenflusstest
- Mutationstests
- Kontrollflussprüfung
- Scheibenbasiertes Testen
F # 3) Was ist ein strukturelles Testbeispiel?
Antwort: Hier ist ein Beispiel, das die Berichterstattung über Aussagen zeigt:
const addNums = (num) => { let sum = num.reduce ((a,b) => a+b); if (sum > 0) { alert(sum); } else { alert(‘please enter positive numbers’); } }; addNums(); Der Umfang der Abdeckung, den wir erhalten, hängt von den Testdaten ab, die wir als Eingabe bereitstellen (ob sie die Bedingungen für die Summe> 0 erfüllen).
F # 4) Was ist der Unterschied zwischen Datenflusstests und Kontrollflusstests?
Antworten: Sowohl Datenflusstests als auch Kontrollflusstests verwenden Kontrollflussdiagramme. Der einzige Unterschied besteht darin, dass wir uns beim Testen des Kontrollflusses auf die aus dem Code generierten Pfade konzentrieren, während wir uns beim Testen des Datenflusses auf die Datenwerte, ihre Definition und Verwendung innerhalb der in einem Programm identifizierten Pfade konzentrieren.
F # 5) Wofür werden Datenflusstests verwendet?
Antworten: Das Testen des Datenflusses ist ideal, um Anomalien bei der Verwendung von Datenwerten innerhalb von Pfaden in einem Kontrollflussdiagramm zu identifizieren. zum Beispiel, Eine Variable, der zweimal ein Wert zugewiesen wurde, eine Variable, die definiert und nicht verwendet wurde, oder eine Variable, die verwendet oder referenziert und nicht definiert wurde.
F # 6) Was ist der Unterschied zwischen Schneiden und Würfeln beim Testen von Software?
Antworten: Slicing bedeutet, sich auf bestimmte Interessenbekundungen in einem Programm zu konzentrieren und den Rest zu ignorieren. Beim Würfeln wird ein Slice mit falscher Eingabe identifiziert und anschließend weiter geschnitten, um das korrekte Verhalten zu verfolgen.
F # 7) Was ist der Unterschied zwischen Mutationstests und Codeabdeckung?
Antworten: Bei Mutationstests betrachten wir die Anzahl der getöteten Mutanten als Prozentsatz der Gesamtmutanten. Die Codeabdeckung ist einfach die Menge an Code, die in einem Programm getestet wurde.
Fazit
In diesem Tutorial haben wir uns eingehend mit Strukturtests befasst - was es ist, was es nicht ist, wie es zu tun ist, Abdeckungsarten, Vor- und Nachteile, Best Practices und sogar einige häufig gestellte Fragen zu diesem Softwaretesttyp.
Es gibt noch so viel mehr, dass wir etwas über strukturbasiertes Testen lernen können. In zukünftigen Tutorials werden wir die Codeabdeckung (Anweisung, Entscheidung, Verzweigung und Pfad), strukturelle Testtypen (Mutation, Datenfluss und Slice-basiert) und sogar die Tools untersuchen, mit denen wir diese Testprozesse automatisieren können.
Es ist wichtig zu beachten, dass es keinen zu 100% effizienten Softwaretesttyp oder -ansatz gibt. Es ist immer ratsam, verschiedene Testtypen und -ansätze zu kombinieren.
Beispielsweise, Strukturprüfungen werden in hohem Maße durch Anforderungsprüfungen ergänzt, da es möglicherweise Merkmale gibt, die zum Zeitpunkt der Durchführung strukturbasierter Prüfungen möglicherweise noch nicht entwickelt wurden.
Strukturelle Testtechniken basieren auf den Fehlern, die menschliche Programmierer beim Schreiben von Code machen. Die Annahme ist, dass der Programmierer ein Experte ist und weiß, was er oder sie codiert, aber von Zeit zu Zeit Fehler macht.
Die verschiedenen strukturellen Testtypen, die wir uns angesehen haben - Mutationstests, schichtbasierte Tests und Datenflusstests - können auf Fehler wie die Verwendung des falschen Operators (Mutationstests) oder die Referenzierung einer Variablen vor deren Verwendung (Datenflusstests) zurückgeführt werden. .
Literatur-Empfehlungen
- Tutorial für zerstörende Tests und zerstörungsfreie Tests
- Funktionstests gegen nichtfunktionale Tests
- Was ist eine fehlerbasierte Testtechnik?
- Einweichen-Test-Tutorial - Was ist Einweichen-Testen?
- SOA-Test-Tutorial: Testmethode für ein SOA-Architekturmodell
- Lasttests mit HP LoadRunner-Tutorials
- Was ist Gammatest? Die letzte Testphase
- DevOps-Test-Tutorial: Wie wirkt sich DevOps auf QS-Tests aus?
- Was ist Konformitätstest (Konformitätstest)?