In der komplexen Welt der Softwareentwicklung, insbesondere bei Großprojekten wie SAP HANA, ist die Qualitätssicherung von entscheidender Bedeutung. Unternehmen wie SAP verlassen sich auf robuste Teststrategien, um die Stabilität, Leistung und Sicherheit ihrer Produkte zu gewährleisten. Anders als bei einmaligen Tests vor oder nach einer Veröffentlichung existieren Testaktivitäten, die kontinuierlich und unabhängig von spezifischen Änderungen oder Releases durchgeführt werden. Diese umfassenden und fortlaufenden Bemühungen sind darauf ausgelegt, die Qualität des SAP HANA Quellcodes stetig zu verbessern und zu optimieren.
Die Herausforderung bei der Entwicklung und Pflege eines komplexen Datenbanksystems wie SAP HANA besteht darin, eine hohe Codequalität über Tausende von Entwicklern und Millionen von Codezeilen hinweg zu sichern. Dies erfordert einen Ansatz, der über traditionelle manuelle Tests hinausgeht und eine tiefgreifende Automatisierung sowie eine integrierte Testinfrastruktur umfasst. Solche kontinuierlichen Testprozesse sind zwar potenziell für jede noch so kleine Änderung denkbar, jedoch übersteigen der zeitliche und finanzielle Aufwand oft den erwarteten Nutzen. Daher konzentriert sich der Umfang dieser kontinuierlichen Testaktivitäten typischerweise auf den gesamten Quellcode des Projekts, was einen fortwährenden Einsatz für die Erprobung und Verbesserung der Softwarequalität darstellt.
Ein zentraler Bestandteil dieser Strategie ist eine ausgefeilte Continuous Integration (CI)-Infrastruktur, die Build- und Testprozesse automatisiert. Diese Infrastruktur ist das Rückgrat, das es ermöglicht, verschiedene Qualitätssicherungsmaßnahmen effizient und skalierbar umzusetzen. Dazu gehören detaillierte Code-Abdeckungsanalysen, Tests auf Basis realer Kundenszenarien, umfassende Protokollierungs- und Debugging-Mechanismen, sowie spezialisierte Tests für Fehlfunktionen und Speichermanagement. Die fortlaufende Qualifizierung interner Systeme, strenge Leistungstests, die Unterstützung multimodaler Datenmodelle, randomisierte Tests zur Fehlererkennung und nicht zuletzt umfassende Sicherheitstests runden das Bild ab. Für die Implementierung solcher fortlaufenden und automatisierten Testprozessen ist die Wahl der richtigen Tools und Frameworks entscheidend. [google chromedriver](https://shocknaue.com/google-chromedriver/) Diese Aspekte stellen sicher, dass SAP HANA den hohen Qualitätsansprüchen gerecht wird und sowohl in der Cloud als auch On-Premise eine herausragende Leistung erbringt.
CI-Tooling und Infrastruktur
Das gestufte Testkonzept von SAP HANA und die immense Größe des Projekts erfordern eine automatisierte, widerstandsfähige, skalierbare, zuverlässige und leistungsfähige Continuous Integration (CI)-Infrastruktur. Die Hauptkomponenten dieser Build- und Testinfrastruktur umfassen ein CI-Tool, eine Cloud-native Ausführungsplattform und domänenspezifische Dienste für Datenanalyse und -interpretation.
Das zentrale CI-Tool konfiguriert Testaktivitäten für jeden Code-Branch. Änderungen werden in einem zentralen Repository versioniert. Die Konfiguration ist flexibel und unterstützt alle in dieser Arbeit beschriebenen Qualitätsmaßnahmen. Die Benutzeroberfläche der Anwendung zeigt für jeden CI-Lauf den Fortschritt, aggregierte Ergebnisse und eine weitgehend automatisierte Ergebnisbewertung, die auf einer zugrunde liegenden Regel-Engine basiert.
Die Ausführungsplattform übersetzt die Arbeitslast eines CI-Laufs in eine domänenspezifische Graphensprache. Jeder Knoten im Graphen repräsentiert einen automatisierten Job mit definierten Ressourcenanforderungen. Ein Integrationstest kann beispielsweise mehrere Terabytes RAM und über 100 CPU-Kerne verbrauchen, während ein Job zur statischen Code-Analyse weniger Ressourcen benötigt. Die Plattform verwaltet einen Hardware-Cluster, der sowohl On-Premise als auch in öffentlichen Clouds gehostet wird. Ein benutzerdefinierter Scheduler dedupliziert den Ausführungs-Graph und delegiert die Arbeitslast an Cluster-Knoten, die freie Ressourcenkapazität bieten. Containerisierung gewährleistet die Leistungsisolation an den Cluster-Knoten. Die Ausführungsplattform umfasst auch ein Datenmanagementsystem, das Eingabe- und Ausgabedaten transparent zwischen Graph-Knoten transportiert und sich um das Daten-Lebenszyklusmanagement kümmert.
Interne SAP HANA Instanzen persistieren die Ergebnisse von CI-Jobs zusammen mit den entsprechenden Metadaten. Die Informationen können über SQL und APIs abgerufen werden. Mittels statistischer Analyse und maschinellem Lernen werden Erkenntnisse gewonnen und Informationen über CI-Läufe, Codezeilen und Branches korreliert.
Der CI-Stack wird durch Tools ergänzt, die den Entwicklungsprozess unterstützen, wie beispielsweise angepasste Erweiterungen für C++-IDEs (Qt Creator, Visual Studio Code), Bug-Tracker und Tools, die Qualitätsmetriken pro Komponente anzeigen, wie Code-Abdeckung, Compiler-Warnungen oder offene Fehler.
Code-Abdeckung als Qualitätsindikator
Die Code-Abdeckung liefert Informationen darüber, welcher Teil des Quellcodes getestet wird. Das Sammeln dieser Informationen ist mit einem Overhead an Zeit und Ressourcen verbunden, da eine Zuordnung zwischen der Ausführung eines Tests und dem zugrunde liegenden Quellcode für den ausgeführten Teil einer Binärdatei identifiziert werden muss. Für ein sehr großes Softwareprojekt wie SAP HANA führt dieser Overhead zu erheblichen Kosten. Zusätzlich zu diesen erwarteten Kosten zeigte sich, dass die meisten Tools zur Erfassung der Code-Abdeckung nicht mit der Größe und Komplexität von SAP HANA kompatibel sind und daher zusätzliche technische Herausforderungen gelöst werden müssen, die die Kosten weiter erhöhen. Aus diesem Grund wird die Code-Abdeckung ähnlich wie bei anderen großen Projekten nicht für jede Änderung, sondern nur 2-3 Mal pro Woche erhoben.
Obwohl in der Literatur Diskussionen über die Nützlichkeit der Code-Abdeckung als Indikator für die Qualität einer Testsuite bestehen, wird die Code-Abdeckung bei SAP HANA als Informationsquelle und nicht als spezifisches Qualitätsziel betrachtet. Komponenten müssen einen bestimmten Schwellenwert für das Abdeckungsverhältnis erreichen. Die zugrunde liegende Motivation ist jedoch nicht, dass dieser Schwellenwert einen spezifischen Qualitätsgrad definiert, sondern dass er die Zeit reguliert, die für die Erstellung von Tests aufgewendet wird. Tatsächlich ist der Wert des Schwellenwerts nicht relevant, da er lediglich eine Beziehung zwischen dem Abdeckungsverhältnis und der in die Testerstellung investierten Zeit darstellt. Die aus der Code-Abdeckung gewonnenen Informationen steuern weitere Aktivitäten und helfen, gezielt Verbesserungen vorzunehmen.
Technisch ermöglicht die Code-Abdeckung die Anwendung von Forschungstechniken zur Reduzierung von Testcode oder zur Verbesserung der Qualität. Es wurde jedoch festgestellt, dass die Nützlichkeit solcher Techniken sorgfältig geprüft werden muss. Die Abdeckung von SAP HANA weist die möglicherweise unerwartete Eigenschaft auf, dass es einen großen Teil der sogenannten “Common Coverage” gibt, d.h., einige Teile der Software werden von allen Tests ausgeführt. Da ein Großteil der Tests auf SQL-Anweisungen basiert, führt jeder dieser Tests den gesamten Datenbank-Stack aus. Dies bedeutet, dass jeder Test, der eine SQL-Anweisung ausführt, dieselben Millionen von Quellcodezeilen wie jeder andere Test ausführen kann und sich möglicherweise nur um einige hundert ausgeführte Zeilen von einem anderen Test unterscheidet. Dies ist beispielsweise eine Herausforderung für spektrumbasierte Techniken oder Techniken, die davon ausgehen, dass jede in den Abdeckungsdaten enthaltene Zeile gleich wichtig ist.
Zusätzlich zu dieser technischen Einschränkung wurde festgestellt, dass einige Techniken für große Projekte nicht relevant sind. Es gibt beispielsweise eine breite Palette von Arbeiten zur Testfall-Priorisierung, die für ein großes Projekt aufgrund von Flakiness und langen Testausführungszeiten keine Vorteile bieten, da Entwickler nicht häufig Zwischenergebnisse überprüfen, sondern zu anderen Aufgaben wechseln und später die Testergebnisse überprüfen.
Kundenszenario-Tests für reale Nutzungsmuster
Wie bereits beschrieben, pflegt SAP einen umfangreichen Satz von Regressionstests für SAP HANA. Doch selbst mit einer solch umfangreichen Testsuite können Benutzer die Software auf eine Weise nutzen, die nicht explizit getestet wurde. Benutzer können beispielsweise eine andere Tabellen- und Datenverteilung, Workload-Management, Systemauslastung, Größe oder Konfiguration verwenden. Es ist daher wichtig, eine neue Softwareversion mit Workloads zu testen, die reale Nutzungsszenarien replizieren.
Ein Ansatz bei SAP besteht darin, den gesamten Workload eines Benutzersystems über einen bestimmten Zeitraum hinweg auf DSGVO-konforme Weise aufzuzeichnen. Dieser Workload kann dann jederzeit für jede neue Version wiedergegeben werden. Im Großen und Ganzen besteht das implizite Testorakel, d.h. die Überprüfung, ob der Test bestanden wurde oder nicht, darin, ob die Wiedergabe erfolgreich ausgeführt wird oder ob während der Ausführung Fehler auftreten. Darüber hinaus ermöglicht die Aufzeichnung auch eine feingranulare Analyse einzelner Abfragen und der Performance.
Die aufgezeichneten Wiedergaben repräsentieren dann einen typischen Workload eines bestimmten Kunden. Je nach Kunde kann ein solcher Workload von Updates, analytischen Abfragen oder einer spezifischen Sonderfunktionalität wie graphbezogenen Abfragen oder maschinellem Lernen dominiert werden.
Kundenszenario-Tests zielen darauf ab, diese Workloads im Rahmen des CI-Prozesses wiederzugeben. Obwohl die Idee der Workload-Wiedergabe theoretisch einfach klingt, birgt sie in der Praxis erhebliche Herausforderungen bei der Implementierung eines vollautomatischen Prozesses. Diese reichen von der Identifizierung der hilfreichsten Workload-Muster für die Aufzeichnung, dem Risiko operativer Fehler während der Wiedergabe, Fehlalarmen in Testergebnissen, der Unterscheidung verschiedener Grundursachen, der Deduplizierung redundanter Ergebnisse bis hin zur zuverlässigen Reproduktion neuer Fehler mit einem minimalen Reproduktions-Setup.
Mehrere Herausforderungen erfordern die Zuordnung einer großen Datenmenge zu korrekten Aktionen, d.h. typische Klassifizierungsaufgaben. Daher wird maschinelles Lernen eingesetzt, um beispielsweise Fehlalarme in Testergebnissen zu analysieren und Grundursachen von Fehlern zu identifizieren.
Insgesamt stellen Kundenszenario-Tests sicher, dass Benutzer ohne Regressionen auf neuere Versionen aktualisieren können und dass die erforderlichen Tests automatisiert und sinnvoll sind, obwohl der Input der Benutzer-Workloads vielfältig und nur in gewissem Maße strukturiert ist. Die Vermeidung von Regressionen für Benutzer-Workloads ist besonders wichtig für SAP HANA Cloud, wo SAP Software-Upgrades und deren Auswirkungen kontrolliert.
Protokolle, Spuren und Debugging
Für große Projekte wie SAP HANA ist es unerlässlich, umfangreiche Informationen für das Debugging bereitzustellen. Diese Informationen müssen auf mehreren Detailebenen für verschiedene Zielgruppen, von Benutzern bis hin zu Entwicklern, verfügbar sein. Da Stabilität von großer Bedeutung ist, sammelt SAP HANA eine breite Palette von Informationen im Falle eines Absturzes (unerwartetes Ende eines Prozesses), wie z.B. Stack-Traces, CPU-Register- und Speicherinhalte oder den Zustand von Programmvariablen und Threads. Darüber hinaus nutzt SAP Reverse Debugging, um Abstürze deterministisch zu reproduzieren und die Ausführung zeitlich rückwärts zu verfolgen, um die Ursachen für Probleme zu finden.
Neben der Unterstützung beim Debugging werden Protokolle und Spuren von SAP HANA Cloud-Instanzen automatisch gesammelt, um entweder Probleme vorherzusagen und zu mindern, bevor sie auftreten, oder um sie zu melden und bekannten Fehlern zuzuordnen oder neue Fehlerberichte zu erstellen. Daher können Protokolle und Spuren als Testwerkzeug in dem Sinne betrachtet werden, dass sie Informationen über den Zustand der Software liefern.
Fehlfunktionstests
Selbst bei der Verfügbarkeit mehrerer Terabytes an Speicher für einzelne Systeme können Out-of-Memory (OOM)-Probleme für eine laufende SAP HANA Instanz weiterhin relevant sein. Grundsätzlich ist entweder der Datenbestand größer als erwartet, oder die Anweisung erreicht ein Speicherlimit und der Speicher-Manager wirft eine Ausnahme. Solche Ausnahmen können an jeder Stelle auftreten, die Speicher allokiert, d.h. fast überall im Code. Da Out-of-Memory-Situationen die Verfügbarkeit beeinträchtigen können und aufgrund der großen Anzahl von Stellen, an denen Probleme auftreten können, ist es wichtig, ein spezialisiertes Konzept zum ordnungsgemäßen Testen solcher Situationen zu haben.
Da SAP HANA ein maßgeschneidertes Speichermanagement-Framework verwendet, kann das Speichermanagement zu Testzwecken in einen speziellen “Fehlfunktionsmodus” versetzt werden, in dem der Speicher-Manager freiwillig und zufällig entscheidet, keinen Speicher bereitzustellen, sondern stattdessen eine Ausnahme zu werfen. Eine Heuristik verringert zusätzlich die Lokalität solcher Ausnahmen, um zu vermeiden, dass Ausnahmen wiederholt an derselben Code-Stelle geworfen werden. Der Fehlfunktionsmodus kann für C++-basierte Tests oder für eine ganze SAP HANA Instanz verwendet werden. Insgesamt trugen und tragen die Fehlfunktionstests maßgeblich zur Stabilität von SAP HANA auch in OOM-Situationen bei.
Neben erwarteten OOM-Situationen kann es auch zu einer fehlerhaften Speicherbehandlung kommen, die zu Speicherlecks, Use-after-Free-Situationen oder anderen Speicher-Sicherheitsverletzungen führt. Ein Speicherleck tritt auf, wenn Speicher allokiert, aber nicht freigegeben wird, obwohl er nicht mehr benötigt wird. Dies beeinträchtigt nicht nur die Verfügbarkeit von SAP HANA, da sich selbst kleine Speicherlecks über die langen Ausführungszeiten von DBMS ansammeln können, sondern hat auch negative Auswirkungen auf die Gesamtbetriebskosten, die teilweise vom benötigten Speicher abhängen. Darüber hinaus können Probleme mit der Speichersicherheit zu Abstürzen oder Sicherheitslücken führen.
Daher sind Tests zur Erkennung und Behebung fehlerhafter Speicherbehandlung wichtige Aufgaben für SAP HANA. SAP erreicht dies mit mehreren Ansätzen. Erstens wissen wir aufgrund des maßgeschneiderten Speichermanagement-Frameworks typischerweise zur Laufzeit, wo