Aufbau

Bei der Abdeckungsanalyse in ABAP wirken die Instrumentierung auf Kernel-Ebene zur Abdeckungsmessung, Mechanismen auf höherer Ebene zur Verwaltung der Abdeckungsanalyse und die von der Instrumentierung gelieferten Daten zusammen.

In diesem Abschnitt werden wichtige Funktionen dieser Infrastruktur beschrieben:

Coverage Analyzer aktivieren und deaktivieren

Wenn ein Benutzer Coverage Analyzer aktiviert, führt Coverage Analyzer eine Reihe von Vorbereitungsschritten aus, bevor die eigentliche Messung der Quelltextabdeckung beginnen kann. Neben anderen Aufgaben aktiviert Coverage Analyzer die Instrumentierung in der ABAP-Engine und startet den Job RSCVR_INIT_START. Außerdem plant er einen periodischen Hintergrundjob (RSCVR_TRIGGER_COLLECT) ein, um Quelltextabdeckungsdaten persistent in der Datenbank zu hinterlegen.

Wenn Sie Coverage Analyzer deaktivieren, wird der Hintergrundjob RSCVR_DELETE_COVTAB ausgeführt, um die Statistiken in den Abdeckungsanalysetabellen zu löschen. Es gibt keinen Grund, Abdeckungsdaten zu behalten, wenn Coverage Analyzer deaktiviert wurde.

Metadaten generieren und verwalten

Zur Berechnung von Ergebnissen benötigt Coverage Analyzer Metadaten über die Programme im System, z.B. eine Datenbank der Verarbeitungsblöcke in jedem Programm. Vor NetWeaver Release 7.0 EHP3 wurden diese Metadaten während eines ressourcenintensiven Initialisierungschritts erzeugt, der beim Einschalten von Coverage Analyzer lief.

Ab EHP3 baut Coverage Analyzer die Metadaten bedarfsgesteuert auf. Der teure Initialisierungsschritt fällt weg.

Coverage Analyzer erhöht außerdem nicht mehr die Arbeitslast bei der Aktivierung von Programmen. Vor EHP3 nutzte Coverage Analyzer das Ereignis der Aktivierung als Auslöser für die Neugenerierung der Metadaten. Ab EHP3 entfällt dieser zeitaufwändige Schritt bei der Aktivierung.

Abdeckungsanalysedaten in die Datenbank transportieren

Wenn Coverage Analyzer aktivi ist, misst die im ABAP-Kernel eingebettete Instrumentierung die Ausführung der Verarbeitungsblöcke, Zweige und Anweisungen während der Programmausführung.

Initial werden die Statistiken zur Quelltextabdeckung im lokalen Speicher der einzelnen Workprozesse gehalten. Von dort aus werden sie in das Shared Memory des Servers migriert. Zur Persistierung dieser Daten in der Datenbank startet Coverage Analyzer den periodischen Hintergrundjob RSCVR_TRIGGER_COLLECT. Dieser Job wiederum führt den Sammelreport RSCVR_COLLECT auf allen Anwendungsservern eines Systems aus, in denen Coverage Analyzer aktiviert wurde.

Zuerst überträgt RSCVR_COLLECT die Daten in den 'Staging-Bereich' der Tabelle COVRES0. Abschließend werden die neuen Daten mit den Statistiken in den Tabellen COVRES und COVREF etc. aggregiert.

Durch die Instrumentierung auf Kernel-Ebene und den Datentransfer über einen Staging-Bereich vom Workprozess-Speicher zur Datenbank wird sichergestellt, dass sich die Messung der Quelltextabdeckung möglichst wenig auf die Performance auswirkt.

Quelltextabdeckungshistorie generieren

Ein separater optionaler Job - der Historiesammeljob RSCVR_BUILD_GLOBAL_VIEW - kann ebenfalls ausgeführt werden, um die Statistiken zur Quelltextabdeckung für die Globalanzeige zu aggregieren. Sie legen fest, wie oft dieser Job ausgeführt wird. Bei jedem Lauf wird ein Datensatz zur aktuellen Historieversion hinzugefügt. Bei einer Jobperiode von 1 Tag wird also pro Tag ein Datensatz in der aktuellen Historie angelegt.

Eine Historie aggregiert die Quelltextabdeckung auf der Ebene der Pakete im System. Die Detailanzeige stellt die Rohdaten der Quelltextabdeckung für einzelne Programme und ihre Komponenten dar.

Was passiert bei Quelltextänderungen mit Abdeckungsdaten?

Wenn sich der Quelltext in einem System ändert, kommt die Rücksetzungsfunktion vom Coverage Analyzer zum Tragen. Mit dieser Funktion wird sichergestellt, dass:

Wenn ein Verarbeitungsblock geändert wird, setzt Coverage Analyzer automatisch die aktuellen Zähler des Verarbeitungsblocks zurück. Außerdem wird der Zurücksetzungszähler erhöht, um anzuzeigen, dass die Statistiken zurückgesetzt wurden. Die aktuellen Zähler zeichnen die Quelltextabdeckung seit dem letzten Zurücksetzen auf.

Die kumulativen Zähler, welche die Quelltextabdeckung seit der letzten Aktivierung von Coverage Analyzer oder seit dem letzten manuellen Zurücksetzen der Statistik in Transaktion SCOV aufzeichnen, sind durch das automatische Zurücksetzen im Falle von Quelltextänderungen nicht betroffen. Die Auswirkungen automatischer Zurücksetzungen werden erst dann sichtbar, wenn das betroffene Programm aktiviert wird.

Wenn ein Verarbeitungsblock gelöscht wird, löscht Coverage Analyzer alle aktuellen und kumulativen Zähler, die sich auf den Verarbeitungsblock beziehen.

Wenn Sie die Statistiken in Transaktion SCOV manuell zurücksetzen, dann setzt Coverage Analyzer sowohl die aktuellen als auch die kumulativen Zähler der betroffenen Programme und ihrer Verarbeitungsblöcke zurück.

Die in Historien abgelegten Abdeckungsstatistiken werden durch Zurücksetzungen, seien sie automatisch oder manuell, nicht berührt.

Aggregierte Daten aus Remote-Systemen

Sie können Coverage Analyzer die Abdeckungsergebnisse aus mehreren Systemen in Ihrem lokalen System konsolidieren lassen. Dabei nutzt Coverage Analyzer einen RFC zur Sammlung der Abdeckungsstatistiken aus dem Remote-System bzw. den Remote-Systemen. Die Sammlung erfolgt im Hintergrundjob RSCVR_FILL_REMOTE.

Coverage Analyzer trägt nur für Verarbeitungsblöcke Statistiken zusammen, die erfolgreich im lokalen System initialisiert wurden.

Die Statistiken des lokalen und des Remote-Systems werden auf Ebene der Verarbeitungsblöcke zusammengeführt, um eine systemübergreifende Statistik für die komplette Prozedurabdeckung zu erstellen. Die zusammengeführten Statistiken sind sowohl auf Paketebene in der Globalanzeige als auch für einzelnen Programmobjekte in der Detailanzeige sichtbar.

In beiden Anzeigen werden die zusammengeführten Statistiken unter der Testgruppe COND (engl. condensed für dt. verdichtet) abgelegt. Der Abdeckungsstatus für die zusammengeführten Statistiken wird im Hinblick auf die Einstellungen im System zur Statistiksammlung berechnet.

Die aggregierten Systeme müssen dasselbe Release und einen Stand höher als Release 4.6C haben.

Das Beispiel in der folgenden Grafik zeigt, wie vier Systeme [S1 - S4] mit insgesamt vier Verarbeitungsblöcken [V1- V4] aggregiert werden. Die Namen der verwendeten Verarbeitungsblöcke werden invers und unterstrichen dargestellt.

Der aggregierte Abdeckungsgrad beträgt in diesem Beispiel 100 Prozent, da jeder Verarbeitungsblock in allen Systemen mindestens einmal aufgerufen wird. In den lokalen Systemen betragen die Abdeckungsgrade dagegen nur 25 Prozent für S1 –S3 und 75 Prozent für S4. Ein Abdeckungsgrad > 0 ergibt sich, wenn die unter Einstellungen definierten Bedingungen erfüllt sind.

Welche Anweisungen zählen?

Coverage Analyzer berücksichtigt alle Anweisungen (zur Berechnung der Anweisungs- und Zweigabdeckung) außer den folgenden ABAP-Anweisungen: