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.

Accelerating any business process will expose systemic constraints that shackle the entire organization to its slowest moving component.  In the case of the accelerated SDLC, testing has become the most significant barrier to taking full advantage of iterative approaches to software development. For organizations to leverage these transformative development strategies, they must shift from test automation to Continuous Testing. Drawing a distinction between test automation and Continuous Testing may seem like an exercise in semantics, but the gap between automating functional tests and executing a Continuous Testing process is substantial.

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.

In der Regel sollten Sie Tests in der produktionsähnlichsten Umgebung durchführen, auf die Sie zugreifen können - wenn nicht in der Produktion. Dies ist jedoch in der Regel eine erhebliche Herausforderung in Bezug auf Kosten, Sicherheit und Datenschutz. Durch die Verwendung von Simulationstechnologien wie Service Virtualization können Sie die Einschränkungen 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

Das Testen auf der API- / Nachrichtenschicht (Dienste, Nachrichtenwarteschlangen, Datenbankabstraktionsschichten usw.) bietet verschiedene Vorteile, um das kontinuierliche Testen 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.