Ein Angebot von

Automatisierte Softwaretests in einer Continuous-Delivery-Pipeline

| Autor / Redakteur: Neil Langmead * / Sebastian Gerstl

Je früher im Entwicklungsprozess Fehler erkannt und behoben werden, desto besser. Mit DevOps lässt sich ein hohes Maß an Software-Qualität erreichen: Bugs und Fehler können früher beseitigt, die Phasen des Unit- und Integrationstests schneller abgeschlossen und der gesamte Lieferzyklus verkürzt werden. Aber was sind geeignete Werkzeuge für eine sicherheitskritische DevOps-Pipeline?
Je früher im Entwicklungsprozess Fehler erkannt und behoben werden, desto besser. Mit DevOps lässt sich ein hohes Maß an Software-Qualität erreichen: Bugs und Fehler können früher beseitigt, die Phasen des Unit- und Integrationstests schneller abgeschlossen und der gesamte Lieferzyklus verkürzt werden. Aber was sind geeignete Werkzeuge für eine sicherheitskritische DevOps-Pipeline? (Bild: ©aleeri - stock.adobe.com)

Wie kommt man zu einer sicheren, agilen Entwicklungs-Pipeline? Wir stellen fünf Schritte vor, die beim Entwerfen einer DevOps-Strategie für ein kritisches Softwareprojekt zu berücksichtigen sind.

Der Heilige Gral, bei einem Softwareprojekt gleichzeitig niedrige Kosten, hohe Qualität und hohe Geschwindigkeit zu erzielen, ist durch den optimalen Einsatz von DevOps-Methoden,Tools und erfahrenen Mitarbeitern in greifbare Nähe gerückt. Der Einbau von Qualität in Softwaresysteme war in der Vergangenheit ein kostspieliges Unterfangen. Keine andere Branche toleriert die Fehlerraten, die häufig in Softwareanwendungen zu finden sind.

Typische Fehler können von Funktionsfehlern, Robustheitsproblemen bis hin zu Abstürzen, Sicherheitslücken und Speicherverlusten variieren. Da das Testen bis zu 50% des SDLC-Aufwands beansprucht und das Auffinden von Fehlern extrem teuer ist, sobald Software auf dem Markt ist, wird das frühe Backen in Qualität immer wichtiger.

Mit DevOps-Pipelines können wir den arbeitsintensiven Prozess des Komponententests, der Integration und des Systemtests sowie die Code-Analyse automatisieren, um strukturelle und architektonische Mängel zu finden. Wir können sicherstellen, dass bei jedem Code-Check-In von Entwicklern die vorhandenen Tests nicht beschädigt, ein neues Software-Problem eingeführt oder die Architektur beschädigt wird. Wir tun dies bei „Time Zero“ - der frühesten Gelegenheit, Softwarefehler zu finden und zu beheben. Darüber hinaus können wir andere Überprüfungen zu höheren Zeitpunkten automatisieren, z. B. wenn Feature-Zweige wieder in der Entwicklung zusammengeführt werden - T (1). Oder beispielsweise auch, wenn mehrere Feature-Zweige zusammengeführt werden und wir im Begriff sind, einen Release-Kandidaten aufzustellen – T (2) und T (3).

Schritt 1: Untersuchen, wie lange die NULL-Release dauert

Wenn eine Codezeile in einem Softwaresystem geändert wird, welche Aktivitäten müssen ausgeführt werden, bevor die Software mit dieser Codeänderung freigegeben werden kann? Dies wird als NULL-Release-Problem bezeichnet. Die Herausforderung besteht darin, die Zeit zu minimieren, die erforderlich ist, um die Software erneut auszustellen, wenn sich der Code ändert. Dies ist eine NULL-Beispielversion, die die Softwareerstellung, statische Analyse, Unit-, Integrations- und Systemtests umfasst, bevor eine NULL-Release-Pipeline bereitgestellt wird (siehe Bild 2).

Im Idealfall möchten wir jeden Schritt des NULL-Freigabeprozesses automatisieren, und selbst die neue Versionierung und Bereitstellung der neuen Software kann automatisiert werden, wenn moderne Repository-Manager (z. B. Conan.io ) verwendet werden. Die Tests von Cantata können mit Conan-Artefakten kombiniert und zusammen mit den Binärdateien an Kunden geliefert werden, um zu zeigen, dass die gelieferte Software den höchstmöglichen Standard erreicht hat:

Schritt 2: Software-Architektur analysieren und verwalten

Architektur spielt im Softwareentwicklungsprozess eine zentrale Rolle. Wenn Abhängigkeiten nicht richtig definiert und verwaltet werden, hat dies Auswirkungen auf die Geschwindigkeit und Zuverlässigkeit des Builds sowie auf die Auswirkungen einer Änderung auf die Tests. Wenn das System ein hohes Maß an Zyklizität und Kopplung aufweist, werden auch Tests gekoppelt und die Kosten für Änderungen im System werden unannehmbar hoch. Mit Cantata Test Architect können Architekten den Code in einer Abhängigkeitsstrukturmatrix (DSM) visualisieren und die Codestruktur auf Layer- und API-Regelverletzungen, instabilen Code und Code, der möglicherweise geändert werden kann, untersuchen (siehe Bild 4).

Mit dem DSM können wir die Auswirkung einer Änderung an einer beliebigen Komponente auf das transitive Schließen berechnen. Skripte können ausgeführt werden, um automatisch Unit- und Integrationstestprojekte zu erstellen. Unabhängige Subsysteme können auch automatisch identifiziert werden, und der Aufbau wie auch das Testen dieser Komponenten können in unserer DevOps-Pipeline parallelisiert werden.

Bild 6: Ein Beispiel automatisierter Liefer-Pipelines mit abgestuften Qualitätsstufen, die auf Kubernetes basieren.
Bild 6: Ein Beispiel automatisierter Liefer-Pipelines mit abgestuften Qualitätsstufen, die auf Kubernetes basieren. (Bild: QA Systems)

Neben T (0), dem Zeitpunkt Null oder dem frühesten Zeitpunkt in der SDLC, an dem Fehler behoben werden, gibt es auch andere Zeitpunkte, an denen wir unsere Pipelines automatisch anwenden können. Dies umfasst Zusammenführungen von Feature-Zweigen zu Entwicklungszweigen und das Zusammenführen zu Qualitätszweigen, kurz bevor ein Release-Kandidat identifiziert wird (siehe Bild 6).

Schritt 3: T (x) effiziente Tests und Analysen in jeder Phase

Das Erstellen automatisierter Pipelines auf diese Weise bietet Softwareprojekten drei enorme Vorteile:

  • Konsistenz: Die Pipelines können jederzeit von nicht fachkundigen Benutzern erneut ausgeführt werden und liefern jedes Mal die gleichen Ergebnisse.
  • Belastbarkeit: Wenn das System einen Build- oder Testagenten verliert, ist es intelligent genug, um sich selbst zu heilen. Der teure Wartungsprozess für ein Build- und Testsystem wird durch die Konfiguration als Code reduziert.
  • Skalierbarkeit: Wenn wir mehr Rechenleistung für unser Setup benötigen, können wir dies problemlos tun und unsere Software mit so vielen Tests wie nötig auf Millionen von Codezeilen skalieren. Durch änderungsbasiertes Testen, bei dem alle Änderungen sorgfältig überwacht werden, um ihre Auswirkung auf das gesamte System zu berechnen, können wir jeden Teil des Systems effizient erneut testen, wenn Änderungen vorgenommen werden.

Schritt 4: Everything as Code – alles als Code implementieren

Durch neue Tools wie Jenkins, Kubernetes/Helm ist es nun möglich, alles als Code zu konfigurieren. Und zwar die Build-Infrastruktur, virtualisierte Build-Umgebungen, die optimierte Aufgaben parallel ausführen können, und natürlich sind jetzt auch die Tests selbst Teil des Codes. Dies vereinfacht den gesamten Lebenszyklus erheblich. Für Git-Repository-Benutzer wird dieses Konzept als „GitOps“ bezeichnet.

Tests Als Code: Cantata generiert alle Testfälle und Coverage-Schwellenwertprüfungen als Code, d.h. implementiert in nativem C oder C ++. Dies ist wichtig, da der Testcode zuverlässig und deterministisch ausgeführt wird und die Entwickler problemlos neben der zu testenden Software warten können.

Konfiguration Als Code: Mit YAML ist es einfach und effizient, die gesamte Konfiguration von Maschinenclustern zu codieren, die in der Cloud ausgeführt werden können, z. B. in Google, AWS oder Azure. Die Konfiguration kann jederzeit erneut ausgeführt und hinsichtlich Geschwindigkeit und Leistung optimiert werden. Durch die Durchführung unserer Unit-Tests in Software-Containern wird das Risiko falscher Konfigurationen verringert. Wir erhalten die gleichen, garantierten Ergebnisse, wenn unsere Konfiguration, Tests und Infrastruktur als Code geschrieben werden.

Schritt 5: Alles und frühzeitig im Software Lifecycle testen

Testwerkzeuge wie Cantata konzentrieren sich auf die Reduzierung des manuellen Testaufwands im Rahmen eines umfassenderen Entwicklungsprozesses, der normalerweise das Issue-Management (z. B. mit JIRA), die Versionskontrolle, ein System für Continuous Integration (CI) und einen Bereitstellungsmechanismus umfasst. QA Systems hat diesen Workflow für eine Reihe von Kunden im Bereich der funktionalen Sicherheit erfolgreich implementiert und durch Automatisierung von Build und Test dazu beigetragen, Compliance und höhere Sicherheitsstandards zu erreichen.

Bild 9: Live-Systemüberwachung und automatisches Auslösen der Pipeline, wenn Änderungen erkannt werden.
Bild 9: Live-Systemüberwachung und automatisches Auslösen der Pipeline, wenn Änderungen erkannt werden. (Bild: QA Systems)

Unter Verwendung des beliebten Jenkins-Frameworks kann die Pipeline jetzt automatisch ausgeführt werden, und betroffene Unit-Testfälle können erneut ausgeführt werden, wenn Änderungen an der Software festgestellt werden. Dies geschieht durch die veränderungsbasierte Architekturanalyse (siehe auch Bild 9).

Mehr Effizienz mit Abstraktion und Automatisierung

Zusammenfassend ändert DevOps die Art und Weise, wie Software entwickelt, getestet und veröffentlicht wird. Wir befinden uns mitten in einer aufregenden Zeit der Innovation, die dazu führt, dass Software schneller, in höherer Qualität und zu geringeren Kosten entsteht. Dies wird in erster Linie durch Automatisierung und Abstraktion der Infrastruktur als Code erreicht.

Cantata kann vollständig in fortgeschrittenen DevOps-Umgebungen bereitgestellt werden, und Benutzer können durch die Implementierung der in diesem Dokument beschriebenen Fünf-Schritt-Strategie erhebliche Vorteile erzielen.

Dieser Beitrag ist erschienen im Sonderheft Embedded Softwar Engineering der ELEKTRONIKPRAXIS (Download PDF)

* Neil Langmead ist Cantata Technical Consultant bei QA Systems in Boston.

Kommentar zu diesem Artikel abgeben

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de/ (ID: 46171946 / Test & Qualität)