Grenzen der statischen Analyse

In diesem Kontext stoßen statische Analyseverfahren vollends an ihre Grenzen, denn virtuelle Applikationen lassen sich mit statischen Methoden nur teilweise analysieren, nie aber vollständig. Besondere Aufmerksamkeit verdienen geschäftskritische Applikationen, die häufig als Fachanwendungen mit unternehmensspezifischen Erweiterungen im Einsatz sind. Gerade hier sind die Installationsvorgänge und Abhängigkeiten von hoher Bedeutung.

Die logische Konsequenz ist ein physikalischer Test, der auch mögliche Konflikte wie Probleme mit Benutzerberechtigungen oder Konflikte beim Zugriff auf Ressourcen aufdecken kann. Hier greift die dynamische Analyse; treffender wäre eigentlich die Bezeichnung "dynamischer Test".

Bei einer dynamischen Analyse wird die Applikation real in einer definierten Umgebung installiert. Damit ist der Test vollkommen unabhängig vom eingesetzten Installer, die Ergebnisse bei MSI-Installern sind ebenso zuverlässig wie die bei Non-MSI-Installern. Der grundsätzliche Unterschied zur statischen Analyse besteht darin, dass hier das tatsächliche Ergebnis einer Aktion betrachtet wird und nicht die Installer-Komponente, die eine Aktion anstößt. Das Ergebnis ist eine 100-prozentige Testabdeckung.

Den Veränderungen auf der Spur

Für die weitere Untersuchung gibt es nun zwei Möglichkeiten. Die erste besteht darin, einen Base-Snapshot des "jungfräulichen" Systems aufzunehmen, die Applikation zu installieren und zu starten, dann einen zweiten Snapshot zu erstellen und beide miteinander zu vergleichen, also eine Differenzmenge zu ermitteln. Diese Vorgehensweise hat jedoch einen gravierenden Nachteil: Aufgrund der großen Datenmengen muss man mit erheblichen Laufzeiten rechnen.

Die zweite, zeitsparende Alternative besteht darin, die Applikation durch einen so genannten Agent während der Installation auf die vorgenommenen Änderungen hin beobachten zu lassen. Der Agent protokolliert, welche Dateien tatsächlich in das Sys-tem geschrieben, welche Registry-Einträge vorgenommen werden und was generell am Betriebssystem verändert wird. Damit erhält man ein exaktes Abbild der Modifikationen, die die Applikation während der Installation und beim ersten Start vorgenommen hat. Hier versagen natürlich die rein analytischen Methoden, da sie an dieser Stelle technikbedingt "blind" sind.

Der erwähnte Agent, der die Änderungen am System aufzeichnet, muss selbstverständlich möglichst portabel konzipiert sein, so dass er selbst keine Modifikationen am System vornimmt, die dann eventuell dem Fingerprint der Applikation zugerechnet werden.

Bei dieser Methode wird jede in Frage kommende Applikation einmal gegen das Betriebssystem getestet und so ein spezifischer Application Fingerprint erzeugt, der dann in ein Repository geladen werden kann. Durch das Vergleichen dieser Fingerprints lassen sich nun potenzielle Konflikte ermitteln.

Um nichtrelevante Konfliktmeldungen zu unterdrücken, wird der Test durch ein lernfähiges Expertensystem unterstützt. Es enthält einen vorkonfigurierten Regelsatz, kann aber ebenso bestimmte Ausnahmen lernen, die nicht relevant für die Funktion des Betriebssystems oder der Applikation sind. Ebenso lassen sich Include-Filter definieren, die dem Testsystem mitteilen, nur bestimmte Teile der Registry, des Dateisys-tems oder auch nur bestimmte Dateien zu betrachten. Damit lässt sich das Datenvolumen des OS-Snapshots reduzieren, schließlich nimmt der Snapshot einer aktuellen Windows-7-Version mit allen Patches rund 500 MB in Anspruch. Der Fingerprint eines SAP-GUI ist rund 200 MB groß, immerhin werden hier rund 750.000 Änderungen gespeichert.