Parasoft C/C++test 2022.2 unterstützt MISRA C:2012 Amendment 3 und eine Entwurfsversion von MISRA C++ 202x. Erfahren Sie mehr >>

Test intelligenter und nicht härter: Schichttest links und rechts mit Test Impact Analysis

Von Markus Lambert

28. August 2019

6  min lesen

Bei der Analyse der Testauswirkungen müssen die Tests speziell auf Änderungen konzentriert werden, die während jeder Iteration vorgenommen wurden, und es wird automatisch getestet, was genau getestet werden muss. Teams, die diese Technologie nutzen, können ihren Testaufwand in der Entwicklung mit sofortigem Feedback darüber optimieren, was zu tun ist.

Software-Tests, die häufig durch Branchenumfragen und -berichte bestätigt werden, sind auch nach der Implementierung moderner Entwicklungsprozesse wie Agile, DevOps und Continuous Integration / Deployment immer noch ein Engpass. In einigen Fällen testen Softwareteams nicht annähernd genug und müssen sich in späteren Phasen des Entwicklungszyklus mit Fehlern und Sicherheitslücken befassen, was zu der falschen Annahme führt, dass diese neuen Prozesse ihr Versprechen nicht einhalten können. Eine Lösung für bestimmte Problemklassen ist das Shift-Right-Testen, bei dem die Anwendung in einer Produktionsumgebung überwacht wird. Für den Fall, dass ein kritischer Fehler auftritt, ist jedoch eine solide Infrastruktur erforderlich, um neue Änderungen rückgängig zu machen.

Infolgedessen verpassen Unternehmen immer noch Fristen, und Qualität und Sicherheit leiden darunter. Aber es gibt einen besseren Weg! Um intelligenter zu testen, verwenden Unternehmen die sogenannte Technologie Test Impact Analysis um genau zu verstehen, was zu testen ist. Dieser datengesteuerte Ansatz unterstützt beide Linksverschiebungstest und Shift-Right-Tests.

Agile und DevOps und der Testengpass

Das Testen in einem beliebigen iterativen Prozess ist ein Kompromiss darüber, wie viel Testen in einer begrenzten Zykluszeit durchgeführt werden kann. In den meisten Projekten ist es unmöglich, bei jeder Iteration eine vollständige Regression durchzuführen. Stattdessen wird eine begrenzte Anzahl von Tests durchgeführt, und genau das, was getestet werden soll, basiert auf den besten Vermutungen. Das Testen wird auch im Zyklus zurückgeladen, da normalerweise nicht genügend abgeschlossene neue Funktionen zum Testen vorhanden sind. Das resultierende Diagramm von Aufwand und Zeit endet wie ein Sägezahn, wie unten in Abbildung 1 gezeigt. In jedem Zyklus wird nur eine begrenzte Anzahl von Tests ausgeführt, bis der letzte Zyklus voll ist Regressionstests ist durchgeführt.

Abbildung 1: Agile Prozesse führen zu einem „Sägezahn“ der Testaktivität. Nur der vollständige Regressionszyklus kann einen „vollständigen“ Test durchführen.

Leider erreicht kein Projekt den letzten Zyklus ohne Fehler und ohne Sicherheitslücken. Das Auffinden von Fehlern in dieser Phase führt zu Verzögerungen, da Fehler behoben und erneut getestet werden. Und selbst mit Diese Verzögerungen und all diese Fehler finden immer noch Eingang in das bereitgestellte Produkt, wie unten dargestellt.

Abbildung 2: Integration und vollständige Regressionstests sind niemals fehlerfrei. Spätphasenfehler führen zu Zeitplan- und Kostenüberschreitungen.

Diese Situation hat dazu geführt, dass sogenannte „Shift-Right-Tests“ eingeführt wurden, bei denen Unternehmen ihre Anwendung in der Bereitstellungsphase weiter testen. Mit Shift-Right-Tests sollen die Testbemühungen erweitert und erweitert werden, wobei Tests in der Bereitstellungsphase am besten geeignet sind, z. B. API-Überwachung, Umschalten von Funktionen in der Produktion und Abrufen von Rückmeldungen aus dem realen Betrieb.

Was ist Shift-Right-Testen?

Die Schwierigkeiten bei der Reproduktion realistischer Testumgebungen und der Verwendung realer Daten und Datenverkehr beim Testen führten dazu, dass Teams Produktionsumgebungen zur Überwachung und zum Testen ihrer Anwendungen verwendeten. Es gibt Vorteile Dazu können beispielsweise Anwendungen mit Live-Produktionsdatenverkehr getestet werden, um Fehlertoleranz und Leistungsverbesserungen zu unterstützen. Ein häufiger Anwendungsfall ist der sogenannte kanarische Freilassung, in dem eine neue Version der Software zuerst für eine kleine Gruppe von Kunden freigegeben und dann für eine immer größere Gruppe bereitgestellt wird, wenn Fehler gemeldet und behoben werden. Roku führt dies beispielsweise aus, um die Gerätefirmware zu aktualisieren.

Shift-Right-Tests basieren auf einer Entwicklungsinfrastruktur, die bei kritischen Fehlern eine Freigabe rückgängig machen kann. Zum Beispiel bedeutet eine schwerwiegende Sicherheitslücke in einer kanarischen Version, dass die Version zurückgesetzt wird, bis eine neue aktualisierte Version fertig ist, wie Sie in der Abbildung hier sehen können:

Abbildung 3: Shift-Right-Tests basieren auf einer soliden Infrastruktur für Entwicklungsvorgänge, um Releases angesichts kritischer Fehler zurückzusetzen.

Es besteht jedoch das Risiko, Produktionsumgebungen zum Überwachen und Testen von Software zu verwenden, und natürlich auch Die Absicht des Shift-Right-Tests war niemals, die Testpraktiken für Einheiten, APIs und Benutzeroberflächen vor der Bereitstellung zu ersetzen! Shift-Right-Test ist a komplementär Praxis, die die Philosophie des kontinuierlichen Testens auf die Produktion erweitert. Trotzdem können Unternehmen das Konzept leicht missbrauchen, um zu rechtfertigen, dass während der Entwicklung noch weniger Unit- und API-Tests durchgeführt werden. Um dies zu verhindern, müssen wir das Testen während der Entwicklungsphasen einfacher, produktiver und qualitativ hochwertiger gestalten.

Testen Sie intelligenter und nicht härter, indem Sie Ihre Tests fokussieren

Die meisten Softwareprogramme sind nicht vollständig getestet, und die Entscheidung, was getestet werden soll, basiert im Wesentlichen auf den besten Vermutungen der Entwickler über die kritischen Funktionen. Während eines SCRUM-Sprints oder einer Iteration in anderen Prozessen ist es schwierig zu bestimmen, was getestet werden soll, da „Alles testen“ natürlich keine Option ist. Da die Zeitpläne kurz sind, können nur Teile der Software getestet werden, die mit der neuesten Funktionalität aktualisiert wurden. Wie genau der Code betroffen ist, ist jedoch normalerweise nicht bekannt. Testautomatisierung hilft, aber ohne genau zu wissen, wo und was getestet werden soll, ist die Testabdeckung unzureichend.

Testwirkungsanalyse

Diese Mängel können durch Verwendung überwunden werden Test Impact AnalysisHierbei handelt es sich um eine multivariate Analyse der Testabdeckung, Codeänderungen und Abhängigkeiten, die genau festlegt, welcher Code getestet werden muss. Darüber hinaus können diese genauen Tests geplant und automatisch ausgeführt werden.

Die Testauswirkungsanalyse funktioniert auf Entwicklerebene innerhalb der IDE, sammelt Informationen darüber, welcher Code von welchen Tests ausgeführt wird, und wendet diese Informationen in der IDE des Entwicklers an, wenn der Entwickler den Code ändert, sodass der Entwickler die spezifischen Tests, die dies tun, leicht identifizieren und ausführen kann müssen ausgeführt werden, um sicherzustellen, dass der geänderte Code keine Tests unterbricht. Wenn Sie nachverfolgen, welche betroffenen Tests ausgeführt wurden, welche bestanden wurden und welche fehlgeschlagen sind, kann der Entwickler auf einfache Weise feststellen, welche Tests noch ausgeführt werden müssen oder welche Tests fehlgeschlagen sind und behoben werden müssen. Sobald alle Tests ausgeführt wurden und bestanden wurden, weiß der Entwickler, dass es sicher ist, seinen Code festzuschreiben und fortzufahren.

Die Analyse der Testauswirkungen funktioniert innerhalb eines CI / CD-Prozesses, indem sie nahtlos in das Build-System eines Projekts wie Maven oder Gradle integriert wird, um sofortiges Feedback zu Änderungen zu erhalten. Die Testauswirkungsanalyse ermittelt, welcher Code sich seit dem Baseline-Build (dh dem letzten nächtlichen Build) geändert hat, bestimmt, welche Tests ausgeführt werden müssen, um diesen Code auszuführen, und führt dann nur diese Teilmenge von Tests aus. Mit diesem Workflow können Teams CI-Jobs einrichten, die nur Tests basierend auf den letzten Codeänderungen ausführen. Dadurch wird die Zeit, die zum Ausführen eines CI-Jobs benötigt wird, von Stunden auf Minuten verkürzt.

Die Testauswirkungsanalyse bietet die folgenden Hauptvorteile:

  • Verstehen Sie, was jeder Test abdeckt: Durch die automatische Korrelation von Testausführungsdaten mit Testabdeckungsdaten bietet die Testauswirkungsanalyse einen Mechanismus, mit dem anhand des derzeit entwickelten Codes ermittelt werden kann, welche Tests ausgeführt werden müssen. Benutzer sparen Zeit, ohne unnötige Tests durchführen zu müssen, und Teams profitieren von sofortigem Feedback während der Entwicklung und nach dem Einchecken des Codes.
  • Verstehe, was sich geändert hat: Entwickler wissen oft nicht, welche Tests ausgeführt werden sollen, um Codeänderungen zu validieren. Daher checken sie entweder (a) ihren Code ein, ohne Tests auszuführen (eine sehr schlechte Praxis), (b) führen nur einen oder zwei Tests aus, über die sie Bescheid wissen ( die leicht einige übersehen) oder (c) alle ihre Tests ausführen (was Zeit verschwendet). Die Testauswirkungsanalyse löst dieses Problem, indem sofort ermittelt wird, welche Tests mit welchen Codeänderungen zusammenhängen, und geht einen Schritt weiter, indem sie automatisch ausgeführt wird. Der eingecheckte Code wird stabiler, da er vor dem Einchecken gründlich getestet wurde.
  • Konzentrieren Sie sich auf Tests, die Änderungen und betroffene Abhängigkeiten validieren: Durch das Identifizieren und Ausführen nur der Tests, die zum Überprüfen aller Codeänderungen und der betroffenen Abhängigkeiten erforderlich sind, die seit dem letzten Baseline-Build (normalerweise dem nächtlichen Build) festgeschrieben wurden, wird die zum Ausführen von CI erforderliche Zeit erheblich verkürzt. Dies ermöglicht es Teams, von einem echten CI-Prozess zu profitieren.
  • Sofortiges und laufendes Feedback: Die Analyse der Testauswirkungen identifiziert nicht nur direkte Abhängigkeiten zwischen Tests und Code, sondern auch indirekte Abhängigkeiten und hilft den Teams, so schnell wie möglich zu verstehen, nachdem der Code überprüft hat, ob der Code Tests gebrochen hat.

Zusammenfassung

Um den Testengpass in der Entwicklung erheblich zu verringern und die Effizienz der Sägezahnbemühungen zu verbessern, die Tester in jede Iteration investieren, können Entwicklungsteams von der Testauswirkungsanalysetechnologie profitieren. Testautomatisierung mit Testauswirkungsanalyse bedeutet, den Test speziell auf Änderungen zu konzentrieren, die während jeder Iteration vorgenommen wurden, und genau zu testen, was automatisch getestet werden muss. Diese Teams optimieren ihren Testaufwand in der Entwicklung mit sofortigem Feedback darüber, was zu tun ist, welcher Code nicht getestet werden kann und welcher andere Code von neuen Änderungen betroffen ist.

Aktivieren Sie die Analyse der Testauswirkungen, um sofortiges Feedback zu neuen Codeänderungen zu erhalten

Von Markus Lambert

Mark, Vice President of Products bei Parasoft, ist dafür verantwortlich, dass Parasoft-Lösungen den Unternehmen, die sie einsetzen, einen echten Mehrwert bieten. Mark ist seit 2004 bei Parasoft und arbeitet mit einem breiten Querschnitt von Global 2000-Kunden zusammen, von spezifischen Technologieimplementierungen bis hin zu umfassenderen Initiativen zur Verbesserung von SDLC-Prozessen.

Erhalten Sie die neuesten Nachrichten und Ressourcen zum Testen von Software sofort.