Automatisierte Softwaretests in einer Continuous-Delivery-Pipeline

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

Anbieter zum Thema

Schneider Electric GmbH

DataCore Software GmbH

Fujitsu Technology Solutions GmbH

QA Systems GmbH

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 Software-Anwendungen 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 Prozernt 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.

Bildergalerie

Bildergalerie mit 10 Bildern

Mit DevOps-Pipelines lässt sich der arbeitsintensive Prozess der Komponententests, der Integration und des Systemtests sowie die Code-Analyse automatisieren, um strukturelle und architektonische Mängel zu finden. Dabei ist sicherzustellen, 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.

Das geschieht bei „Time Zero“ - der frühesten Gelegenheit, Softwarefehler zu finden und zu beheben. Darüber hinaus können andere Überprüfungen zu höheren Zeitpunkten automatisiert werden, zum Beispiel 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: Abbildung 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, zum Beispiel „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 Software-Entwicklungsprozess 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: Abbildung 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.

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: Abbildung 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“ und „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, also 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, etwa 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, beispielsweise 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.

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: Abbildung 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 Software Engineering der Elektronik Praxis (Download PDF) .

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

(ID:46251211)