Since this post accompanies a talk in German, it is written in German, too.
Mit dem Alter und der Größe eines Softwaresystems steigt typischerweise der Bedarf für ausgiebige und qualitativ hochwertige Software Tests. Zudem werden für mehr Anwendungscode auch mehr Tests benötigt. Damit steigt die Ausführungszeit der Tests.
In der Praxis führt das immer häufiger zu Test Suiten, die Stunden bis Tage brauchen, um einmal zu laufen. Das bringt eine Reihe von Probleme mit sich. Für die Entwickler bedeutet es, dass sie Feedback für den geänderten Code erst eine lange Zeit nachdem sie die Änderungen gemacht haben, bekommen. Das macht es deutlich schwieriger, die Fehler im Code zu finden und beheben. Außerdem werden moderne Verfahren, wie zum Beispiel Continuos Integration dadurch deutlich erschwert. All das mindert den Wert der Tests ausgerechnet für die Systeme, in denen sie absolut essenziell sind, nämlich große komplexe Software Systeme.
Eine naheliegende Lösung für das Problem ist es, einen Teil der Tests häufiger auszuführen als den Rest. Die Herausforderung dabei ist, diese Teilmenge an Tests so zu bestimmen, dass man möglichst viel Zeit einsparen kann, ohne die Fähigkeit der Tests, Fehler zu finden, erheblich zu mindern. Um das zu erreichen, gibt es verschiedene Ansätze, von denen jeder Vor- und Nachteile mit sich bringt.
Ein Ansatz ist die Test Suite Minimierung. Dabei werden verschiedene Kriterien verwendet wie testfallspezifische Coverage und Ausführungszeit, um ein Subset von Tests zu wählen, das in einem Bruchteil der Zeit einen Großteil der Fehler finden soll. Ziel dieses Verfahrens ist es, eine Liste von Tests zu wählen, die jeden Tag oder öfter ausgeführt werden kann, um schnelleres Feedback zu ermöglichen. Die vollständige Test Suite sollte dennoch in regelmäßigen Abständen ausgeführt werden.
Der Zweite Ansatz, den wir betrachten, ist die Test-Impact-Analyse. Dabei werden Testfälle aussortiert, die bei ihrer nächsten Ausführung höchstwahrscheinlich keine Fehler finden. Die Annahme, dass ein Testfall beim nächsten Testlauf keinen Fehler findet, begründen wir durch die Änderungen seit dem letzten Testlauf. Ein Test, der keinen Code abdeckt, der seit dem letzten Mal geändert wurde, wird voraussichtlich auch keinen neuen Fehler finden. Zudem werden die Testfälle so sortiert, dass innerhalb der kürzest möglichen Zeit eine möglichst hohe Code Coverage erreicht wird.
Im Vortrag gehen wir auf die Vor- und Nachteile der beiden Verfahren ein und präsentieren unsere Erfahrungen aus Forschung und Praxis.