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

Verwenden Sie die Codeabdeckung intelligent, um den Testaufwand zu maximieren

Von Markus Lambert

30. März 2018

4  min lesen

Verwenden Sie die Codeabdeckungsmetriken auf intelligente Weise, um die Testbemühungen dort zu konzentrieren, wo sie am dringendsten benötigt werden, indem Sie verstehen, wo neue Tests erforderlich sind, und wartbare Testsuiten erstellen.

Einer der wichtigsten Grundsätze von Agile ist die Sicherstellung der Versandqualität inkrementeller Ergebnisse bei gleichzeitiger Reaktion auf sich ändernde Anforderungen. Die Herausforderung, das Testen neuer Funktionen in Einklang zu bringen und gleichzeitig den korrekten Betrieb vorhandener Funktionen zu überprüfen, führt dazu, dass viele agile Entwicklungsteams bei der Erstellung, Verwaltung und Wartung einer wachsenden Reihe von Tests ins Stocken geraten. Am Ende kann es sehr schwierig werden, die Agilität zu beschleunigen und sich sowohl der Produktqualität als auch der Sicherheit ohne den richtigen Informationsreichtum sicher zu sein.

Die Betrachtung der während des Tests ausgeübten Codemenge ist eine nützliche Messgröße, um den Grad der durchgeführten Risikominderung zu verstehen. Sie wird jedoch häufig missbraucht und ist auf Makroebene kein guter Indikator dafür qualitativ hochwertiges. In diesem Beitrag werde ich Ihnen zeigen, wie Sie die Codeabdeckungsmetriken intelligent verwenden, um die Testbemühungen dort zu konzentrieren, wo sie am dringendsten benötigt werden, indem Sie verstehen, wo neue Tests erforderlich sind. Wir werden auch einige der Best Practices für die Erstellung wartbarer Testsuiten erläutern.

Wie man über eine nützliche Codeabdeckung nachdenkt

Die Codeabdeckung ist nicht die Nummer, um zu bestimmen, wann Sie genügend Tests haben, aber es ist eine Nummer, die sehr nützlich sein kann, um Teams darauf hinzuweisen, wo sie sich konzentrieren sollen.

Leider wird es häufig falsch verwendet, um Teams zu verwalten, indem man sich auf die Nummer selbst konzentriert und für einen bestimmten Prozentsatz gegen die Codebasis schießt, beispielsweise mit Richtlinien wie "Wir müssen 80% Deckung haben, bevor wir veröffentlichen können" oder "Die Deckungsnummer" sollte gleich oder höher sein als die vorherige Version. “

Das Problem bei diesem Ansatz ist, dass das Erhalten und Aufrechterhalten einer Zielabdeckungsnummer an sich schwierig und zeitaufwändig ist. Daher arbeiten wir blind auf die Nummer hin und niemand nimmt sich die Zeit, um wichtige Fragen zu stellen, wie z.

  • Welche 80% decken wir ab?
  • Wird der Testaufwand die Qualität validieren und das Risiko der Lieferung der Anwendung verringern?
  • Wie werde ich die Tests beibehalten, wenn sich der Code weiterentwickelt?

Wie ich in a letzten BlogJede Änderung in der Codebasis stellt eine Einführung des Risikos dar. Das Verständnis der spezifischen Auswirkungen jeder Änderung auf den vorhandenen Code ist wichtig, ebenso wie das Verständnis, wie dieses Risiko gemindert werden kann.

Indem Sie Änderungen in der Codebasis identifizieren und die Codeabdeckung verwenden, um Tests mit diesen Änderungen zu korrelieren, kann ein optimaler Testplan erstellt werden, der darauf basiert, wo ein erneuter Test erforderlich ist (lesen Sie mehr über Änderungsbasiertes Testen hier ).

Dies deckt jedoch nicht das gesamte Risiko ab. Natürlich müssen wir noch Tests für die neue Funktionalität erstellen, aber was ist mit dem vorhandenen / Legacy-Code? Viele Organisationen, mit denen wir sprechen, haben eine Tor von 60-80% Codeabdeckung, aber in Wirklichkeit kämpfen, um über 50% zu bekommen. Es besteht also eine gute Chance, dass eine Änderung des vorhandenen Codes nicht durch einen vorhandenen Testfall abgedeckt wird. Das Ziel der Makroabdeckung, das sich ausschließlich darauf konzentriert, das Makroabdeckungsziel zu erhalten oder schrittweise zu erweitern, schützt nicht vor der Einführung von Regressionen in Legacy-Funktionen, die „seit Jahren funktionieren“.

Wenn Sie sich die Abdeckungsdetails genauer ansehen, können bestimmte modifizierte Linien, die NICHT abgedeckt wurden, schnell identifiziert werden, sodass Sie das Team darauf konzentrieren können, wo neue Tests erstellt werden müssen. Mithilfe der Rückverfolgbarkeit zwischen Testfällen und dem spezifischen Code, den sie ausführen, können Sie außerdem potenzielle Testfälle identifizieren, die dupliziert oder erweitert werden können, um die Änderungen abzudecken.

Durch die Fokussierung auf eine 100% ige Abdeckung des geänderten Codes im Vergleich zu einem willkürlichen Teamziel von „80% Gesamtabdeckung“ kann das Team das Risiko eines neuen Codes wesentlich effizienter verringern und gleichzeitig Faktoren eliminieren, die die allgemeine Projektstabilität beeinflussen (z. B. Änderungen an Legacy-Code.)

Geänderte Code-Abdeckung in Aktion

Das Messen dieser intelligenten Codeabdeckung ist mithilfe des Modified Code Coverage-Widgets von Parasoft DTP (ein analytisches „Slice“ der Process Intelligence Engine (PIE) von Parasoft DTP) möglich. Hier können Sie leicht die Abdeckung des Codes sehen, der zwischen zwei Builds hinzugefügt oder geändert wurde (z. B. dem aktuellen Build und einem Ziel-Build Ihrer Wahl). Zum Beispiel zeigt Abbildung 1 ein solches Widget. In diesem Beispiel wurden 177 Codezeilen zwischen den beiden Builds hinzugefügt oder geändert, und 109 dieser Zeilen wurden getestet, dh 61.6%. Dies bedeutet, dass 68 Zeilen neuen oder geänderten Codes von keinem Test abgedeckt werden und daher nicht validiert wurden und ein Risiko in der Codebasis darstellen.

Kundencenter-Bild 1.png

Hinter diesem Widget befindet sich ein geänderter Bericht zur Berichterstattung. Der Bericht enthält genaue Angaben dazu, in welchem ​​Code geeignete Tests fehlen. Dies sind wichtige Informationen, die Entwickler und Tester benötigen, um ihre Bemühungen zu konzentrieren. Abbildung 2 zeigt einen solchen Bericht, in dem geänderte Dateien nach Anzahl der Änderungen oder fehlenden Codetests sortiert werden können, wobei nicht abgedeckte geänderte Zeilen rot markiert sind.

Kundencenter-Bild 2.png

Dieser Bericht beantwortet die Frage "Welche Tests fehlen mir?" Basierend auf den Informationen hier für jeden Build kann ein Testplan erstellt werden.

Welche Art von Test soll erstellt werden?

Sobald Sie den Code identifiziert haben, in dem Tests fehlen, müssen Sie sich tatsächlich an die Arbeit machen und die Tests erstellen, um die Lücke zu schließen - aber welche Art von Tests erstellen Sie? Die Testpyramide (wie von evangelisiert) Martin Fowler und  Mike Cohn) beschreibt, wie Sie ein effizientes, überschaubares und wartbares Testportfolio erstellen. Durch die Minimierung spröder UI-Level-Tests und Konzentration auf eine solide Grundlage von Unit-Tests (unterstützt durch umfassende Tests auf Service-/API-Ebene) sind Sie in der Lage, eine Teststrategie aufzubauen, die skalierbar, wartbar und kontinuierlich ausgeführt werden kann.

Wir werden in diesem Blog nicht auf die Details der Erstellung von Unit- oder API-Tests eingehen, aber Sie können meinen vorherigen Blog über Unit-Tests lesen und auf einen kommenden Blog darüber achten, wie Parasoft SOAtest kann verwendet werden, um die Erstellung von API- / Service-Level-Tests zu vereinfachen.

Fazit

Die Codeabdeckung ist eine wichtige Messgröße, wird jedoch häufig überbeansprucht und missbraucht, insbesondere wenn sie zur Messung der Qualität verwendet wird. Nutzen Sie die analytische Intelligenz von Parasoft DTP, um zu erkennen, wo neue Tests erforderlich sind, um Risiken zu minimieren, Ihre Tests zu fokussieren und Ihre Qualitätsziele optimal zu erreichen, um mehr Wert aus der Codeabdeckung zu ziehen.

Neuer Call-to-Action

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.