Coverage Analyzer: Performance

Vor Release NetWeaver 7.0 EHP2 wirkte sich Coverage Analyzer nur minimal auf die Performance aus, sofern folgende Voraussetzungen gegeben waren:

Sie verwenden weniger als fünf Testgruppen - je weniger, desto besser. Für jede Benutzergruppe werden jeweils eigene Statistiken zur Quelltextabdeckung angelegt.
Sie sammeln keine Historien und verwenden nicht die Globalanzeige. Die Globalanzeige ist ein hilfreiches Werkzeug für das Beobachten von Entwicklungen in der Quelltextabdeckung. Sie wirkt sich jedoch auf die Systemlast auf dem ABAP-Anwendungsserver aus.

Durch die neu hinzugekommene Anweisungs- und Zweigabdeckung ab EHP2 ändert sich dieses günstige Szenario. Durch das Sammeln von Anweisungs- und Zweigabdeckungsdaten wird eine erhebliche Arbeitslast erzeugt, und das Zusammenstellen dieser Statistiken kann nicht separat ein- oder ausgeschaltet werden.

Empfehlungen für die Aktivierung von Coverage Analyzer:

In Produktivsystemen: Nur nach Bedarf zum Anlegen von Abdeckungsprofilen von realen Benutzer für folgende Zwecke:
- Validierung der Modul- und Integrationstests durch Vergleich der Quelltextabdeckung von Test- und Produktivbenutzern
- Auffinden von nicht verwendetem Quelltext
In Entwicklungsystemen: Nur nach Bedarf zur Unterstützung testgesteuerter Entwicklung auf Basis von ABAP-Unit-Tests.
Das Aktivieren von Coverage Analyzer kann in Entwicklungssystemen sinnvoll sein, wenn Sie Entwicklung für Testzwecke betreiben, Tests für ABAP Unit oder andere Tests durchführen. Beachten Sie, dass Entwickler die Quelltextabdeckung von ABAP-Modultests mit dem ABAP Unit Browser überprüfen können, selbst wenn Coverage Analyzer nicht aktiviert ist.
In Qualitätssicherungssystemen: Coverage Analyzer sollte in solchen Systemen eingeschaltet werden.
Da die Performance in der Regel nicht allzu sehr beeinträchtigt wird, können Sie Coverage Analyzer in Qualitätssicherungstestsystemen generell aktivieren. Coverage Analyzer sollte jedoch nur in Systemen aktiviert werden, in denen Tests durchgeführt werden und Sie die Testabdeckung analysieren wollen. Andernfalls sammeln Sie Daten, die nicht verwendet werden.

Die Phasen, in denen sich Coverage Analyzer auf Systemlast und Performance auswirkt, sind wie folgt:

Messung: Wenn Coverage Analyzer arbeitet, zeichnet er die Ausführung von Verarbeitungsblöcken mit der Instrumentierung im Kernel auf.
Da zur Verarbeitungsblockabdeckung jetzt die Anweisungs- und Zweigabdeckung hinzukommt, sind die Kosten für die Messung zu beträchtlich und können daher nicht mehr wie früher außer Acht gelassen werden.
Übertragung von Daten aus dem Shared Memory in die Datenbank: Die von Coverage Analyzer gesammelten Daten werden regelmäßig von Hintergrundjobs aus dem Shared Memory abgeholt. Die Daten werden dann in die Datenbank geschrieben.

Die hierfür benötigte Zeit ist von der Menge der anfallenden Daten abhängig. Messungen der Performance auf repräsentativen Systemen weisen eine Verarbeitungsgeschwindigkeit von ungefähr 10 Programmen oder 100 Verarbeitungblöcken pro Sekunde auf. Die Anzahl der anfallenden Verarbeitungsblöcke ist in etwa linear proportional zur Anzahl der Testgruppen. Aus diesem Grund sollte die Anzahl der Testgruppen so klein wie möglich gehalten werden. Sie sollte auf keinen Fall 5 Testgruppen überschreiten.
Erstellung von Historien: Mit einem optionalen Hintergrundjob können Sie aggregierte Historien von Quelltextabdeckungen erstellen.

Sie wählen die Pakete, die von einer Historie berücksichtigt werden sollen, über den Menüpfad Administration Einstellungen Pakete, die beim Erstellen der Historie berücksichtigt werden aus. Sie sollten die in Historien aggregierten Daten auf die Pakete beschränken, die zu Ihren Entwicklungsprojekten gehören.

Jeder Lauf des Historienhintergrundjobs erstellt eine Datenmenge für die Historie. Die für diese Datenmengen ausgewählte Granularität sollte nicht zu fein sein. Eine Messung der Quelltextabdeckung pro Tag sollte genügen.
Erstellung einer kombinierten Statistik mit Daten aus dem lokalen System und aus einem oder mehreren entfernten Systemen. Mit einem optionalen Hintergrundjob können Sie kombinierte, gesamte Quelltextabdeckungsstatistiken über Systeme hinweg erstellen.

Da dieser Job üblicherweise Daten nur aus wenigen Systemen sammelt und auch nur unregelmäßig läuft, ist seine Auswirkung auf die Performance vernachlässigbar.