White-Box-Test Verständnisproblem

[PrincE]

Hallo Leute,

ich bin ein bisschen am verzweifeln.
Ich muss bald ein Referat über das White-Box-Test Verfahren halten und ich laufe immer wieder in Sackgassen. In Aussagen die ich nicht nachvollziehen kann...

z.B.
Kontrollflussorientierte Testverfahren ? Wikipedia

[...]
Mit den Anweisungsüberdeckungstests wird sichergestellt, dass kein “toter Code“, Anweisungen die niemals durchlaufen werden, im Programm existiert. Dies ist ein notwendiges Kriterium um sicherzugehen, dass jede Anweisung auf Fehler untersucht wird. Der Sinn des Anweisungsüberdeckungstests ist die mindestens einmalige Ausführung aller Anweisungen in einem Programm. Ist dies gewährleistet, spricht man von einer völligen Anweisungsüberdeckung.[...] Unser Testpfad enthält zwar alle Knoten, aber nicht alle Kanten. Die Kante (n3,n5) wird im optionalen Else-Teil nicht ausgeführt.
[...]

Warum zur Hölle werden denn angeblich alle Anweisungen ausgeführt, wenn doch der
Anweisungsüberdeckungsgrad =

Anzahl der ausgefuehrten primitiven Zweige
__________________________________________
Anzahl aller primitiven Zweige


Was schon darauf schließt das meistens doch nicht alle Anweisungen ausgeführt werden?!

 

[Gregorrr]

Und was ist jetzt dein Problem?

Im Falle einer völligen Anweisungsüberdeckung ist sichergestellt, dass keine toter Code existent ist.

Diese Tatsache ist aber bei einem nicht-ausgeführten else-Zweig nicht gegeben. Also kann man daraus schließen, dass es toten Code gibt.

Ein kontrollflussorientiertes Testverfahren gibt den Grad an, wie hoch deine Anweisungsüberdeckung ist.

Im Gegensatz zum Black-Box-Testing kann man diese Aussagen treffen, denn beim Black-Box-Testing hat man i.d.R. keine Ahnung über die Grundgesamtheit des möglich ausführbaren Codes.

 

[nillehammer]

In dem genannten Beispiel:

 int z = x;
 if (y > x)
    z = y;
 z *= 2;

Wird mit einem einzigen Testfall, bei dem (y > x) jede Zeile des Codes durchlaufen. Deshalb ist die Anweisungsüberdeckung 100%. Das steht bei wikipedia auch so. Was mit dem Testfall aber nich beantwortet wird, ist die Frage: "Was passiert, wenn !(y > x)? Das ist die Kritik an der Metrik "Anweisungsüberdeckung" und die Erklärung für die Einführung der nächsten Metrik "Zweigüberdeckung". Auch, wenn im Code nicht ersichtlich, gibt es nämlich implizit einen else-Zweig. Um den zu testen, bedarf es eines zweiten Testfalls. Damit wäre dann auch die Zweigüberdeckung 100%.

Anzahl der ausgefuehrten primitiven Zweige
__________________________________________
Anzahl aller primitiven Zweige


Was schon darauf schließt das meistens doch nicht alle Anweisungen ausgeführt werden?!

Das ist nicht die Formel für die Berechung der Anweisungsüberdeckung, sondern für die Berechnung der Zweigüberdeckung. Wenn Du diese beiden geistig klar von einander trennst, lösen sich die von Dir vermuteten Widersprüche auf.

 

[PrincE]

nein ich meinte natürlich

Anzahl der ausgefuehrten Anweisungen
__________________________________________
Gesamtanzahl der Anweisungen




habe beim zurück-tabben wohl die Orientierung verloren.

 

[nillehammer]

Ok, ist denn jetzt noch was unklar? Oder reichen die Erklärungen?

 

[PrincE]

Ich habe eure Antworten gelesen, aber das Problem habe ich immer noch nicht gelöst.

Nochmal von vorne:


Angeblich kann der Anweisungsüberdeckungstest sicherstellen das es kein sogenannten "toten Code" gibt.
Das kann meines Erachtens aber nicht sein, weil der Anweisungsüberdeckungstest ja sowieso nicht alle Bedingungen abklappert und daher kann dieser auch nie wirklich herausfinden, ob es Code gibt der NIE ausgeführt wird?!

Das kann nach meinem Verständnis nur der "Zweigüberdeckungstest" ...

 

[PrincE]

Und was ist jetzt dein Problem?

Im Falle einer völligen Anweisungsüberdeckung ist sichergestellt, dass keine toter Code existent ist.

Diese Tatsache ist aber bei einem nicht-ausgeführten else-Zweig nicht gegeben. Also kann man daraus schließen, dass es toten Code gibt.

Ein kontrollflussorientiertes Testverfahren gibt den Grad an, wie hoch deine Anweisungsüberdeckung ist.

Im Gegensatz zum Black-Box-Testing kann man diese Aussagen treffen, denn beim Black-Box-Testing hat man i.d.R. keine Ahnung über die Grundgesamtheit des möglich ausführbaren Codes.

So steht es aber nicht in der Definition ....

"Mit den Anweisungsüberdeckungstests wird sichergestellt, dass kein “toter Code“, Anweisungen die niemals durchlaufen werden, im Programm existiert"

und nicht

"bei einem völligen Anweisungsüberdeckung ist garantiert das kein toter Code existiert"


Bin ich dumm oder was ist los. Verstehe nicht wieso für euch das alles so kla ist.

 

[nillehammer]

Wenn Du mit Deinen Tests 100% Anweisungsüberdeckung erreicht hast, hast Du wirklich jede Zeile Code mindestens einmal durchlaufen. Das ist nur möglich, wenn auch jede Zeile erreichbar ist, es also keinen toten Code gibt. Insofern stellt die Metrik Anweisungsüberdeckung tatsächlich sicher, dass es keinen toten Code gibt.

 

[PrincE]

würde der Anweisungsüberdeckungstest diesen toten Code aufklären?

int i = 4;
		
if(i > 3 && i < 5)
{
    
      if(i == 3)
      {
	    deleteMenu();
      }

      System.exit(0);
}

oder ist es eher ein gutes Beispiel für

"Mit Hilfe des Zweigüberdeckungstests lassen sich nicht ausführbare Programmzweige aufspüren"

 

[nillehammer]

Bei diesem Code wirst du nie 100% Anweisungsüberdeckung erreichen. Du schreibst also Tests und merkst, dass Du keine 100% erreichst. Wenn Du dann schaust, wieso nicht, findest Du die Ursache.

Wenn Du aber (bei welchem Code auch immer) die 100% erreicht hast, weißt Du, dass Du nicht nach totem Code suchen musst. 100% Anweisungsüberdeckung ist der Beweis, dass es keinen toten Code gibt. Weniger als 100% ist der Beweis, das es evtl. toten Code geben kann oder, dass nicht genug Tests geschrieben wurden.

 

[PrincE]

Bei diesem Code wirst du nie 100% Anweisungsüberdeckung erreichen. Du schreibst also Tests und merkst, dass Du keine 100% erreichst. Wenn Du dann schaust, wieso nicht, findest Du die Ursache.

Wenn Du aber (bei welchem Code auch immer) die 100% erreicht hast, weißt Du, dass Du nicht nach totem Code suchen musst. 100% Anweisungsüberdeckung ist der Beweis, dass es keinen toten Code gibt. Weniger als 100% ist der Beweis, das es evtl. toten Code geben kann oder, dass nicht genug Tests geschrieben wurden.

oder das lediglich noch nicht das richtige Kontrollflussorientierte Testverfahren angewandt wurde -.-

naja

jedenfalls wollte ich nur wissen, ob es geeignet ist als Beispiel, zum Darstellen dieses Testverfahrens.
Das es diesen toten Code aufgeklärt hätte?! Oder ob es eben eher zum Zweigüberdeckungstest gepasst hätte

 

[PrincE]

nillehammer !!!

hilf mir

du warst so hilfsbereit bisher