Qualitätssicherung für Embedded-Linux-Projekte Unit-Tests mit Open-Source-Werkzeugen

In der Open-Source-Welt existieren viele Tool-Suiten, die für übliche Build-Umgebungen genutzt werden. Bekannte Vertreter sind make und autotools, die zunehmend auch für qualitätssichernde Maßnahmen eingesetzt werden. Das Ziel ist die Integration von Unit-Tests und generellen Testverfahren mit auf den Einsatzzweck abgestimmten Eigenschaften.

Qualitätssicherung für Embedded-Linux-Projekte

In der Open-Source-Welt existieren viele Tool-Suiten, die für übliche Build-Umgebungen genutzt werden. Bekannte Vertreter sind make und autotools, die zunehmend auch für qualitätssichernde Maßnahmen eingesetzt werden. Das Ziel ist die Integration von Unit-Tests und generellen Testverfahren mit auf den Einsatzzweck abgestimmten Eigenschaften.

INHALT:
Besser vorhersagbarer Projektverlauf durch Qualitätssicherung
JUnit – Mutter aller Unit-Test-Suiten
Standard-Tools der Open-Source-Welt
Integration der Testfälle in die Code-Basis
Test-Setup am Beispiel
Verbindung mit dem Target-System
Test-Code häufig umfangreicher als Produktiv-Code
Autor

Tests sollten so weit automatisiert werden wie nur möglich. Andernfalls werden Entwickler diese in ihrer alltäglichen Arbeit nicht nutzen. Der Aufwand für das Schreiben von Testroutinen sollte nicht als unnötiger Overhead angesehen werden. Die Durchführung der Tests muss für den Entwickler einfach genug zu bewerkstelligen sein, dass sie/er den Prozess als eine Erleichterung versteht und weniger als Zeitverlust. Deshalb sind schnelle und bequem durchzuführende Läufe von „make test“ auch in immer mehr Open-Source-Paketen zu finden. Die Implementierung von Test-Code sollte als integraler Bestandteil eines Projekts oder Pakets angesehen werden. Das ist der Fall, wenn während einer Projektentwicklung parallel am Test-Code gearbeitet wird. Idealerweise wird dieser im selben Code-Repository vorgehalten und gepflegt, so dass jeder Entwickler und andere mit dem Projekt befasste Personen Zugriff darauf haben und ihn nutzen können.

So wird es sogar möglich, Test-Suites vollautomatisch ablaufen zu lassen, etwa in Form eines „nightly test“, wie man es sonst von den „nightly builds“ her kennt. Für praktisch jede Programmiersprache gibt es wenigstens ein etabliertes und frei erhältliches Unit- Test-Framework. Vertreter sind u.a. JUnit für Java, CUnit und autounit für C und PyUnit für Python. Die allen gemeinsame Funktionalität liegt in der Sammlung von Testfällen mit dem dazugehörigen Test-Code, der vom jeweiligen Entwickler bereitgestellt wird, und in einem standardisierten Verfahren für den Auf- und Abbau einer Testumgebung (Harness).

Die Anwendung von Tests ist nicht beschränkt auf Funktionen und Methoden. Sie können auch auf höhere Ebenen ausgedehnt werden, indem z.B. Tests mit Skript-Sprachen wie Shell, Perl und Python implementiert werden, die direkt die Features der Entwicklungsumgebung mitbenutzen können. Auf diese Weise kann eine automatisierte Test-Suite verschiedene Ebenen abdecken von Funktionen und Methoden über Bibliotheken bis hin zu Benutzeroberflächen.

Bei der Entwicklung von Embedded- Software, besonders unter Linux, muss besondere Aufmerksamkeit bei der erfolgreichen Anwendung der vorgenannten Methoden verwendet werden. Diese können – verallgemeinernd gesprochen – in der Embedded-Entwicklung in der gleichen Art und Weise verwendet werden wie in der allgemeinen Software-Entwicklung, allerdings mit ein paar zusätzlichen Eigenschaften wie z.B. Cross-Compilierung und mit Ausführen von Test-Code auf einem Remote-System.

Das generelle Ziel von Unit-Test ist die (voll)automatische Erkennung von Fehlern und Problemen in der Embedded- Software. Es geht also um die Maximierung der Qualität bei gleichzeitiger Minimierung der Testaufwendungen. Durch die Integration von Software- Tests in einem hohen Maße zu einem frühen Zeitpunkt des Entwicklungsprozesses können umfangreiche manuelle Tests zu späterer Zeit deutlich verringert werden.