So überprüfen wir die Stabilität der Software

Seit einigen Tagen suchen wir nach einem Problem in der Baustatik, das sich nur dann manifestiert, wenn man eine ganze Weile mit dem Programm arbeitet. In diesem speziellen Fall handelt es sich um einen Fehler der vor ein paar Tagen bei unseren Testcases aufgefallen war. Das bietet mir die Möglichkeit, mal ein paar Informationen über einen Teil unseres Testverhaltens zu veröffentlichen.

Nachdem ja mehrere Personen an mehreren Standorten an der Baustatik arbeiten, müssen wir irgendwie sicherstellen, das die Veränderungen am Programm nicht dazu führen, das plötzlich andere Ergebnisse herauskommen. Um das zu tun haben wir einen speziellen Server, auf dem einmal pro Nacht eine “aktuelle” Version der Baustatik hergestellt wird. Diese “aktuelle” Version (Das ‘nightly Build’) wird aus allen aktuellen Quelltexten hergestellt und enthält also alle Änderungen, die im Laufe des Tages vorgenommen wurden.

Mit dieser Version rechnen wir dann Testdateien durch, und vergleichen die Ergebnisse der Berechnungen mit Referenzergebnissen aus früheren Berechnungen: Die dürfen sich nicht unterscheiden, sonst ist irgendwas falsch gelaufen. Dazu braucht es natürlich eine ganze Reihe an Dateien – zur Zeit sind das bei uns circa 3500 Stück.

Dabei bietet es sich natürlich an, auch den Verlauf zu protokollieren und auszuwerten. Der Verlauf der Testläufe sieht dann beispielsweise so aus:

Wie man schnell sieht, gab es am 18. ein kleines Problem, das dann in den Folgetagen ein großes Problem wurde: Plötzlich wurden nur noch 1000 Dateien berechnet – in allen anderen Fällen gab es einen Programmabsturz. Das ist natürlich nicht tragbar – und Dank unserer Protokolle konnten wir heute auch eine weitere Kurve erstellen: Die enthält den Verlauf der verbrauchten Handles, nach Typ sortiert. (Handles sind eine ‘knappe’ Systemresource, und darum protokollieren wir den Verbrauch an Handles durch die Baustatik auch mit.)

Und diese Kurze sah so aus:

Schnell zu sehen: Irgend eine Änderung am Programm zwischen dem 16. und dem 19. führt dazu, das das Programm riesige Mengen an (in diesem Fall) GDI-Handles verbraucht.

Und das ist auch der Grund für den Absturz: Irgendwann bekommt man keine mehr von Windows, und dann gibt es Programmabstürze, weil zum Beispiel Menüs oder Bitmaps nicht mehr angezeigt werden können.

Nachdem wir von allen Änderungen wissen, wer Sie wann durchgeführt hat, brauchten wir nur nach den Änderungen im nun bekannten Zeitraum zu sehen – und hatten das Problem dann auch schnell eingekreist und gelöst. (Davon gehe ich zumindest aus, ein Kollege führt gerade einen manuellen Test durch um das zu bestätigen – normalerweise geht das natürlich automatisch.)

Lange Rede kurzer Sinn: Praktisch, wenn man nicht nur die Testfälle durchrechnet, sondern dabei auch gleich noch das allgemeine Verhalten der Software protokolliert.