Testabdeckung zu messen ist ein Muss
Warum (und wie) Testabdeckung messbar sein sollte
Testabdeckung (
Test Coverage) zu messen wird meist unterlassen, da
- geeignetes Werkzeug selten zur Verfügung steht oder
- vorhandenes Werkzeug nicht hilft, die Testqualität gezielt zu verbessern (typisches Problem: zu theoretisch angelegt Metriken).
Erreichte Testabdeckung zu kennen –
und gezielt verbessern zu können – ist dennoch wichtig, da man sonst als Auftraggeber oder Projektleiter ja niemals weiß
- was denn nun bislang wie ausführlich tatsächlich getestet wurde
- und welche Art von Test (oder welcher Tester) sich am ehesten bezahlt macht.
Dass man hier sehr viel Geld falsch ausgeben kann, folgt allein schon aus der Tatsache, dass
bis zu 40% aller Entwicklungskosten Ausgaben für Test sind.
Erster und wichtigster Schritt, vorhandenes Testbudget möglichst sinnvoll einzusetzen, ist die Wahl eines geeignetes Weges, die Wirksamkeit von Test
- einfach messen und
- gezielt verbessern zu können.
Es gibt nur einen Weg, auf dem das gelingt: Man muss sich eine Möglichkeit schaffen, zu protokollieren, welche Funktionen der zu testenden Software unser Test den nun wirklich aufgerufen hat.
Unter eine
Funktion in diesem Sinne sollte man verstehen
- beim Testen über eine API jedes Paar (aufrufbare Schnittstelle, möglicher Returncode)
- beim Testen über ein GUI zudem noch jede Möglichkeit, Eingaben zu tätigen.
Mindestanforderung für
Black Box Test muss sein, jede solche Funktion
- mindestens einmal aufgerufen,
- das Ergebnis auf Richtigkeit geprüft,
- und all das auch protokolliert zu haben.
Für
White Box Test reicht das nicht. Es macht hier keinen Sinn, 100-prozentige Testabdeckung zu fordern (oder auch nur einen ganz bestimmten Prozentsatz).
Man sollte aber auf jeden Fall versuchen, erreichte Testabdeckung
gezielt und stetig zu verbessern.
Dies auf kostengünstige Weise tun zu können, reicht es, an jedem Ausgang jeder einzelnen Methode der implementierten Klassen einen Zähler zu haben, der hochgezählt wird,
wenn die Methode im Test über diesen Ausgang verlassen wird.
Wer es dann noch schafft, all diese Funktionen ihrer Wichtigkeit nach klassifiziert zu haben, wird stets genau sagen können,
- welche Teile der Anwendung gut bzw. weniger gut getestet wurden,
- und für welchen Teil genau es sich am ehesten lohnt, weitere Testtreiber zu schreiben.
Da moderne Programmiersprachen so übersichtliche Struktur haben, dass es problemlos möglich ist, allen Sourcecode automatisch so zu instrumentieren, dass jeder Methodenausgang
protokolliert werden kann, steht alles bereit, diesen Weg wirklich zu gehen (siehe
[G] und
[M]).
Warum er heute dennoch nur selten gegangen wird liegt einfach nur daran, dass
- die Projektleiter dies (aus reiner Unkenntnis?) nicht erzwingen und
- den Systemarchitekten zu wenig bewusst ist, dass sie sich auch für bestmögliche Testbarkeit der entstehenden Software verantwortlich fühlen sollten.
Nach allem, was ich erlebt habe, hilft hier nur
ein Machtwort der für Qualität und Budget verantwortlichen Personen.
stw5937TWP —
Testabdeckung .
Werkzeug .
Praktisches —
News?
Mehr +
B
G
E +
S
H
A +
More