Einführung Obwohl in den letzten Jahren eine Reihe von Datenflusstestmethoden entwickelt und untersucht wurden [8, 11, 14, 15, 18 und 19], war ihre Verwendung auf das Testen von Datenabhängigkeiten beschränkt, die innerhalb einer Prozedur existieren. Das Testen der Datenabhängigkeiten, die zwischen den Prozeduren vorhanden sind, erfordert Informationen über den Datenfluss über die Prozedurgrenzen hinweg, einschließlich der Aufrufe und Rückgaben. Die Datenabhängigkeiten, die zwischen Prozeduren sowohl direkt über einzelne Aufrufe und Rückgaben als auch indirekt über mehrere Aufrufe und Rückgaben bestehen, werden benötigt. Die aktuellen Datenflusstestwerkzeuge verwenden entweder die interprozedurale Datenflussanalyse, die typischerweise bei der Compileroptimierung verwendet wird, um die Datenabhängigkeiten zu bestimmen Die Definition verwendet Paare aus dem Quellcode, indem sie das Diagramm zur Verwendung des Programms erstellt und dann durchsucht. Obwohl interprozedurale Datenflussanalysealgorithmen existieren, [2-7, 9, 17] liefern sie keine detaillierten Informationen (dh die Orte von Definitionen und Verwendungen, die über Prozeduraufrufe und -rückmeldungen reichen), die für die Inter- Prozeduraler Datenflusstest. Auch die Methoden zur Steuerung des eigentlichen Datenflusstests behandeln derzeit nicht das Umbenennen von Variablen, das bei interprozessualen Tests erforderlich ist.Interprozeduraler Datenflusstest Nach dem prozessübergreifenden Datenfluss werden Informationen berechnet und die erforderliche Definition verwendet Paare werden bestimmt, der Tester führt die Auswahl und Ausführung des Moduls mit Testfällen als Eingabe. Dies umfasst das Auswählen der erforderlichen Definition-Nutzen-Paare gemäß dem gewünschten Testkriterium und das Verarbeiten der Testfälle, bis die erforderlichen Paare erfüllt sind. Die benötigten Definition-Use-Paare hängen vom gewünschten Testkriterium ab. Wenn das Kriterium beispielsweise "all-p-uses / some-c-uses" lautet, führt der Tester den Akzeptor mit allen Definition-P-Use-Paaren aus. Wenn für eine bestimmte Definition kein p-use existiert, müssen einige Definition-c-use-Paare akzeptiert werden. Die Verarbeitung eines Testfalls besteht aus (1) Ausführen des Moduls mit den Testdaten als Eingabe zum Abrufen des Testpfads und (2) Ausführen des Testfallakzeptors mit dem Testpfad und einem Definitions-Verwendungspaar als Eingabe. Unser Tester instrumentiert das Modul auf der Zwischencodeebene. Es werden Zwischencodeanweisungen eingefügt, die in einer Datei die Nummer jedes Basisblocks ausgeben, der während der Modulausführung durchlaufen wird. Der Ausführungspfad muss jedoch auch Informationen enthalten, die Prozeduraufrufe signalisieren und zurückgeben, so dass die Umbenennung von formalen und tatsächlichen Referenzparametern gehandhabt werden kann. Wir erreichen dies durch den Intermediate-Code, um Prozeduraufrufe und -rückgaben anzuzeigen. Sie gibt die Datei mit den Blocknummern des Ausführungspfads (TRACEFILE) zusammen mit den Informationen über das zu testende Definitions-Verwendungspaar ein (VAR, DBLK, UBLK1, UBLK2, TY) .VAR steht für die betrachtete Variable und DBLK stellt die Blocknummer dar, die die gewünschte Definition enthält. TY ist entweder C-Use oder Puls. Wenn TY C-Use ist, enthält UBLK1 die Blocknummer der gewünschten Verwendung und UBLK2 wird nicht verwendet; Wenn TY p-use ist, repräsentiert (UBLKl, UBLK2) die gewünschte Kante. Da wir auch Zugriff auf die Datenflussinformation haben, die in der ersten Phase berechnet wurde, wird sie verwendet, um die Menge der Blöcke zu bestimmen, die die Definitionen DEFSET des tatsächlichen Parameters bei Rückgaben von Prozeduren und den formalen Parameter bei den Einträgen bei Prozeduren enthalten. Der Eintrag in eine Prozedur bewirkt, dass das DEFSET geändert wird, um die Umbenennung des formalen Parameters widerzuspiegeln, der an die zu testende Definition gebunden ist. Der Exit einer Prozedur bewirkt, dass DEFSET in der aufrufenden Prozedur wieder auf seinen Wert zurückkehrt. Zur Veranschaulichung betrachten Sie den Testfall mit der Eingabe 4,8,9,2, wobei das zu verarbeitende Definition-Use-Paar die Definition von K in B12 ist des Verfahrens Pair-Max und die Verwendung ist die Kante (BlO, Bll). Diese Definition von K erreicht die Verwendung von anderen an der Kante (B 10, B 11), da sie über die Rückkehr zu der aufrufenden Prozedur Get-Max über die Rückkehr zu Get-Max durch den rekursiven Aufruf über den Aufruf von Get-Max hinausreicht wieder und schließlich über den Aufruf von Pair-Max, wo die Variable an andere gebunden ist. Die Schritte zur Verarbeitung des Testpfades sind unten aufgeführt. Das DEFSET wird mit der Definitionsmenge der Variablen initialisiert, die der zu testenden Definition entspricht. Bei jedem Aufruf von und Rückkehr von einer Prozedur wird das DEFSET geändert, um den neuen Namen des tatsächlichen oder formalen Parameters wiederzugeben. Da in Get-Max keine interprozeduralen Definitionen der entsprechenden Variablen MX vorhanden sind, ist DEFSET während der Verarbeitung der Blöcke in dieser Prozedur leer. SchlussfolgerungenIn diesem Whitepaper haben wir den Datenflusstest erweitert, um das Testen von Definitionen zu erfassen, die über Prozeduraufrufe und -rückmeldungen hinweg erreicht werden können und verwendet werden können. Zu diesem Zweck musste eine interprozedurale Datenflussanalyse entwickelt werden, die die Positionen interprozedialer Definitionen und die Verwendung von Paarungen sowie die Entwicklung einer Testmethodik berechnet, die tatsächliche und formale Parameter in Calls und Returns verknüpft. Der Vorteil des daraus resultierenden Testsystems besteht darin, dass der Datenflusstest einheitlich auf einzelne Prozeduren zur Integration von Prozeduren in einem Modul und auf die Schnittstellen von Prozeduren angewendet werden kann Ich bin K Fasil Ahamed habe meinen UG Abschluss gemacht, jetzt arbeite ich in Bangalore. Der obige Artikel wurde von mir geschrieben, basierend auf meinem eigenen Interesse.

Published on  June 28th, 2018