Gartner Research: API-Tests, Service-Virtualisierung und kontinuierliche Tests

Wenn agile Entwicklungspraktiken ausgereift sind und DevOps-Prinzipien unsere Unternehmenskulturen zu infiltrieren beginnen, erkennen Unternehmen die eindeutige Möglichkeit, die Softwarebereitstellung zu beschleunigen. Wenn Sie jedoch einen Prozess beschleunigen, werden unreife Übungsbereiche und Straßensperren viel ausgeprägter. Es ist der Unterschied zwischen dem Fahren über eine Geschwindigkeitsbegrenzung bei 5 MPH und 50 MPH… bei 50 MPH wird diese Geschwindigkeitsbegrenzung ziemlich erschütternd sein.

Die Beschleunigung eines Geschäftsprozesses wird systemische Einschränkungen aufdecken, die das gesamte Unternehmen an seine am langsamsten bewegliche Komponente fesseln. Im Fall des beschleunigten SDLC ist das Testen zum größten Hindernis geworden, um die Vorteile iterativer Ansätze in der Softwareentwicklung voll auszuschöpfen. Damit Organisationen diese transformativen Entwicklungsstrategien nutzen können, müssen sie sich von Testautomatisierung bis hin zu Continuous Testing. Die Unterscheidung zwischen Testautomatisierung und kontinuierlichem Testen mag wie eine semantische Übung erscheinen, aber die Lücke zwischen der Automatisierung funktionaler Tests und der Ausführung eines kontinuierlichen Testprozesses ist beträchtlich.

Mit der Umwandlung von automatisierten Tests in kontinuierliche Tests sind viele Nuancen verbunden. In diesem Beitrag konzentrieren wir uns auf drei Hauptunterschiede:

• „Test“ auf das Geschäftsrisiko ausrichten
• Allgegenwärtiger Zugriff auf vollständige Testumgebungen
• Extreme Testautomatisierung auf API- / Nachrichtenebene

Test- und Geschäftsrisiko ausrichten

Die grundlegendste Verschiebung beim Übergang von automatisiert zu kontinuierlich ist die Ausrichtung des „Tests“ auf das Geschäftsrisiko. Insbesondere bei DevOps und Continuous Delivery erfordert die schnelle und zuverlässige Veröffentlichung ein sofortiges Feedback zu den Geschäftsrisiken, die mit einem Software-Release-Kandidaten verbunden sind. Angesichts der steigenden Kosten und Auswirkungen von Softwarefehlern können Sie es sich nicht leisten, eine Version zu veröffentlichen, die die vorhandene Benutzererfahrung stören oder neue Funktionen einführen kann, die das Unternehmen neuen Sicherheits-, Zuverlässigkeits- oder Compliance-Risiken aussetzen. Um dies zu verhindern, muss das Unternehmen von der Validierung von Bottom-up-Anforderungen bis zur Bewertung der Systemanforderungen, die mit übergeordneten Geschäftszielen verbunden sind, übergehen.

Allgegenwärtiger Zugriff auf vollständige Testumgebungen

Eine der größten Einschränkungen bei der Durchführung aussagekräftiger Tests ist der Zugriff auf eine vollständige Testumgebung - einschließlich der unzähligen abhängigen Systeme, mit denen die zu testende Anwendung (AUT) interagiert. Angesichts des zusammengesetzten Charakters heutiger Anwendungen ist es nahezu unmöglich, eine vollständige Testumgebung bereitzustellen. Hier kommt die Service-Virtualisierung ins Spiel. Mit der Service-Virtualisierung können Sie das Verhalten bestimmter Komponenten in heterogenen komponentenbasierten Anwendungen wie API-gesteuerten Anwendungen, Cloud-basierten Anwendungen und serviceorientierten Architekturen emulieren. Durch die Simulation der Interaktionen des AUT mit den fehlenden oder nicht verfügbaren Abhängigkeiten können Sie mithilfe der Service-Virtualisierung sicherstellen, dass Daten, Leistung und Verhalten über die verschiedenen Testläufe hinweg konsistent sind. Darüber hinaus hilft es Ihnen auch, Tests nach links zu verschieben, sodass sie bei jeder Iteration viel früher beginnen und Fehler aufdecken können, wenn sie am schnellsten und am einfachsten zu beheben sind.

Als allgemeine Regel sollten Sie in der produktionsähnlichsten Umgebung testen, auf die Sie zugreifen können … wenn nicht in der Produktion. Dies stellt jedoch in der Regel eine beträchtliche Herausforderung in Bezug auf Kosten, Sicherheit und Datenschutz dar. Verwenden Simulationstechnologien wie Service Virtualization ermöglicht es Ihnen, die Einschränkungen zu umgehen, die mit den abhängigen Systemen außerhalb Ihrer Kontrolle verbunden sind, um aussagekräftige End-to-End-Tests durchzuführen.

Extreme Testautomatisierung auf der API / Message-Ebene

Testen auf der API-/Nachrichtenebene (Dienste, Nachrichtenwarteschlangen, Datenbankabstraktionsschichten usw.) bietet mehrere deutliche Vorteile, um Continuous Testing mit der Geschwindigkeit von DevOps zu ermöglichen:

• Stabilität: Während GUI-Tests häufig aufgrund unwichtiger Anwendungsänderungen fehlschlagen, weist ein Fehler auf API- / Nachrichtenebene in der Regel auf einen grundlegenden Fehler in der Anwendungslogik hin, der sich wahrscheinlich auf die Benutzererfahrung auswirkt. Wenn Sie einen Test Suite-Fehler so konfigurieren, dass er als „Gate“ entlang der automatisierten Bereitstellungspipeline dient, ist es wichtig sicherzustellen, dass jeder Fehler auf ein wirklich auffälliges Problem hinweist.
• Geschwindigkeit: Herkömmliche Testmethoden, die stark auf manuellen Tests und automatisierten GUI-Tests beruhen, die häufig aktualisiert werden müssen, können nicht mit der für DevOps erforderlichen Geschwindigkeit Schritt halten. Das Testen wird verzögert, bis die GUI verfügbar ist, was normalerweise zu spät erfolgt. Darüber hinaus sind GUI-Tests notorisch spröde und müssen bei jeder Anwendungsänderung erheblich aktualisiert werden. API-Tests können definiert werden, sobald die Servicebeschreibung (z. B. Swagger oder RAML) verfügbar ist, können viel früher im Implementierungsprozess ausgeführt werden als GUI-Tests und erfordern nur minimale Wartung.
• Genaue Risikobewertung: In modernen Anwendungen ist die auf der GUI-Ebene verfügbare Funktionalität nur die Spitze des Eisbergs. Der Kern der Anwendungslogik wird von der API / Nachrichtenschicht gesteuert. Ohne umfassende Tests kritischer Benutzertransaktionen auf der API- / Nachrichtenebene kann man sich kaum darauf verlassen, dass die hochverteilten Systeme von heute wirklich wie erwartet funktionieren.