TestmanagementChanging the world one bug after amother…
Component Test
Der Komponententest (Unittest) ist der entwicklungsnahe Test von Komponenten, den kleinsten Softwareeinheiten für die eine Spezifikation vorhanden ist oder die separat getestet werden können.
Dieser Test wird meist nach der White-Box-Methode von den Entwicklern durchgeführt.
Für den Komponententest gelten grundsätzlich keine anderen Regeln als für die nachgelagerten Teststufen. Tests werden bestenfalls verwaltet in einem Testmanagementtool. Dann lassen sich jederzeit Informationen beispielsweise über den Status, die Testabdeckung und Traceability abrufen. Für nachfolgende Teststufen fällt dann weniger Testaufwand an.
Bei der objektorientierten Programmierung sind Klassen und Methoden testbar. Bekanntermaßen besteht eine Klasse aus Variablen, den Attributen, und Methoden. Getestet wird, ob eine Klasse unter Berücksichtigung der unterschiedlichen Objektzustände richtig arbeitet. Ziel ist es, jede Methode zu testen. Ist eine Klasse abhängig von anderen Komponenten, so sind diese für den Test bereitzustellen bzw. durch Platzhalter, wie beispielsweise Subs, Mocks oder Dummies, zu ergänzen.
Für den Komponententest ist möglichst ein gemeinsames Test-Framework einzusetzen, welches auch für das Debugging verwendet werden kann.
Beim Test sind Coverage-Messungen durchzuführen, also die Abdeckung der Klassen, die Abdeckung der Methode je Klasse und die Anweisungsabdeckung innerhalb der Methoden.
Eine statische Codeanalyse ergänzt die dynamischen Tests. Bei der statischen Codeanalyse sind sind die Programmierrichtlinien zu überprüfen.
Auch sind Code-Reviews möglichst durchzuführen, um die Softwarequalität zu verbessern.
Beim Komponententest werden auch bereits nicht funktionale Tests durchgeführt, um beispielsweise die Performanzeigenschaften auf Klassenebene zu testen.
Für den Komponententest gelten grundsätzlich keine anderen Regeln als für die nachgelagerten Teststufen. Tests werden bestenfalls verwaltet in einem Testmanagementtool. Dann lassen sich jederzeit Informationen beispielsweise über den Status, die Testabdeckung und Traceability abrufen. Für nachfolgende Teststufen fällt dann weniger Testaufwand an.
Bei der objektorientierten Programmierung sind Klassen und Methoden testbar. Bekanntermaßen besteht eine Klasse aus Variablen, den Attributen, und Methoden. Getestet wird, ob eine Klasse unter Berücksichtigung der unterschiedlichen Objektzustände richtig arbeitet. Ziel ist es, jede Methode zu testen. Ist eine Klasse abhängig von anderen Komponenten, so sind diese für den Test bereitzustellen bzw. durch Platzhalter, wie beispielsweise Subs, Mocks oder Dummies, zu ergänzen.
Für den Komponententest ist möglichst ein gemeinsames Test-Framework einzusetzen, welches auch für das Debugging verwendet werden kann.
Beim Test sind Coverage-Messungen durchzuführen, also die Abdeckung der Klassen, die Abdeckung der Methode je Klasse und die Anweisungsabdeckung innerhalb der Methoden.
Eine statische Codeanalyse ergänzt die dynamischen Tests. Bei der statischen Codeanalyse sind sind die Programmierrichtlinien zu überprüfen.
Auch sind Code-Reviews möglichst durchzuführen, um die Softwarequalität zu verbessern.
Beim Komponententest werden auch bereits nicht funktionale Tests durchgeführt, um beispielsweise die Performanzeigenschaften auf Klassenebene zu testen.
Ist der Komponententest bereits automatisiert, so bietet es sich an, ihn in das Continousintegrationsystem einzubinden.
Im Zuge der Anwendung von agilen Techniken (Test first, Test-Driven-Development) werden Praktiken eingesetzt, die mit dem Test beginnen bevor programmiert wird. Das führt letztlich zu schnelleren und besseren Ergebnissen. In Scrum wird der Einsatz dieser agilen Techniken übrigens nicht verlangt. Die dazu erstellten Testfälle werden auch für den Grey-Box-Test verwendet.
Bei professionell durchgeführten Komponententests wird die Testbarkeit und die Qualität von Software wesentlich verbessert!
This test step should be performant in agreement with the Test Manager and Development:
- the amount
- the kind of tests
- the documentation
U
© 2018 Holger Mayer Consulting HMC2