Holen Sie sich die UMFANGREICHSTE Abdeckung für die Einhaltung von MISRA C! Erfahren Sie mehr >>

10 Tipps zur Bereinigung der statischen Analyse

Von Arthur Hicken

18. April 2018

8  min lesen

Möchten Sie Ihre statische Analysepraxis bereinigen? Beseitigen Sie zunächst die Unordnung, die es schwierig macht, sich auf die Themen zu konzentrieren, die Ihnen wirklich wichtig sind. Beleben Sie als Nächstes Ihre Initiative, indem Sie den Umfang so erweitern, dass der Wert für Ihr Unternehmen steigt.

Ist Ihr Entwicklungsteam von der zunehmenden Anzahl von Verstößen Ihres statischen Analysetools überwältigt? Hat der hohe Geräuschpegel, der durch Ihre aktuelle statische Analysekonfiguration erzeugt wird, das Team für alle Warnungen desensibilisiert - auch für Probleme, die Sie als kritisch erachten?

Hier sind 10 Möglichkeiten, um Ihre vorhandene Implementierung der statischen Analyse aufzufrischen - egal was passiert statisches Analysewerkzeug du benutzt.

Tipp 1: Deaktivieren Sie statische Analyseregeln für Verstöße, die Sie derzeit nicht beheben möchten

Das Überprüfen vieler Regeln ist nicht das Geheimnis, um mit statischer Analyse den besten ROI zu erzielen. In vielen Fällen ist das Gegenteil der Fall. Die statische Analyse liefert tatsächlich bessere Ergebnisse, wenn Sie sich auf ein minimales, aber aussagekräftiges Regelwerk konzentrieren.

Wenn Sie eine statische Analyse durchführen, ist es so, als würde ein erfahrener Entwickler einem unerfahrenen Entwickler über die Schulter stehen und ihm Tipps geben, während er Code schreibt. Wenn der erfahrene Entwickler in allen paar Codezeilen ständig auf pingelige Probleme reagiert, wird der weniger erfahrene Entwickler bald überfordert sein und alle guten und schlechten Ratschläge herausfiltern. Wenn sich der erfahrene Entwickler jedoch auf ein oder zwei Probleme konzentriert, von denen er weiß, dass sie schwerwiegende Probleme verursachen, kann sich der weniger erfahrene Entwickler viel eher daran erinnern, welche Ratschläge gegeben wurden, besseren Code schreiben und diese Art von Feedback tatsächlich zu schätzen wissen .

Dies gilt auch für die statische Analyse. Wenn Sie es überschaubar und aussagekräftig halten, werden Sie Ihren Entwicklern am Ende mehr beibringen und sie den Prozess viel weniger übel nehmen lassen. Möchten Sie lieber einen kleinen Satz von Regeln haben, die befolgt werden, oder einen großen Satz, der nicht befolgt wird? Wenn Sie nicht wirklich erwarten, dass die Entwickler Verstöße gegen eine Regel bereinigen, sobald sie gemeldet werden, sollten Sie ernsthaft in Betracht ziehen, diese Regel zu deaktivieren.

Tipp 2: Deaktivieren Sie statische Analyseregeln, die zu viel Rauschen verursachen

Wenn eine bestimmte Regel wiederholt verletzt wird, ist jetzt eine gute Gelegenheit, neu zu bewerten, ob Sie diese Regel wirklich weiter überprüfen möchten. Eine übermäßige Anzahl von Verstößen weist darauf hin, dass die Entwickler den Code nicht so schreiben, wie es die Regel erfordert. Sie davon zu überzeugen, ihre Kodierungsgewohnheiten zu ändern, könnte auf einiges an Widerstand stoßen.

Wie können Sie feststellen, ob sich das Drücken der Ausgabe lohnt? Versuchen Sie zunächst, sich daran zu erinnern, warum Sie überhaupt nach diesem Problem gesucht haben. Haben Sie es ausgewählt, weil es eine gute Möglichkeit zu sein schien, Probleme zu lösen, die auf diesem Gebiet auftreten? Im Rahmen Ihrer Bemühungen zur Einhaltung gesetzlicher Vorschriften? Oder einfach, weil es vom Anbieter standardmäßig aktiviert wurde? Anbieter geben normalerweise die Referenz für jede Regel in ihren Regelbeschreibungen an. Durch Lesen dieser Beschreibungen können Sie feststellen, ob die Regel wirklich gut zu Ihren Projekten und Zielen passt.

Überprüfen Sie als Nächstes, ob es einen alternativen Weg gibt, um das gewünschte Ergebnis zu erzielen. Gibt es eine spezifischere alternative Regel? Gibt es eine Möglichkeit, die Regelparameter so zu optimieren, dass sie nicht so oft ausgelöst werden? (Mehr dazu in Tipp 6). Sie könnten sogar in Betracht ziehen, eine eigene Regel zu schreiben, die besser zu Ihnen passt - oder den Anbieter eine benutzerdefinierte Regel für Sie erstellen lassen.

Wenn Sie immer noch daran interessiert sind, diese Regel zu überprüfen, nachdem Sie ihre Vorteile überprüft und ihre Alternativen untersucht haben, erhalten Sie ein Feedback zur Entwicklung, was mit der Einhaltung dieser Regel verbunden wäre. Sie können dieses Feedback dann verwenden, um festzustellen, ob es sich wirklich lohnt, von Entwicklern die Einhaltung dieser Regel zu verlangen. Wenn es nach viel Arbeit für wenig Nutzen aussieht, deaktivieren Sie die Regel.

Tipp 3: Verwenden Sie Unterdrückungen, um Verstöße in bestimmten Situationen zuzulassen

In einigen Fällen sind Sie möglicherweise verpflichtet, eine Regel zu befolgen, möchten jedoch unter bestimmten Umständen Ausnahmen zulassen. Möglicherweise haben Sie eine Regel, für die eine zusätzliche Validierungsstufe im Code erforderlich ist. Angenommen, Sie haben eine bestimmte Methode mit leistungskritischem Code, die hunderte Male pro Minute aufgerufen wird - und Sie haben bereits überprüft, ob eine angemessene Validierungsstufe durchgeführt wurde, bevor diese bestimmte Methode aufgerufen wird. Oder nehmen Sie an, dass die flussbasierte Analyse Sie vor einem schwerwiegenden Problem auf einem Pfad warnt, von dem Sie zu 100% sicher sind, dass er nicht in der integrierten Anwendung verwendet werden kann. Hier bieten sich Unterdrückungen an.

Unterdrückungen sind ideal für Situationen, in denen Sie nach etwas suchen möchten, sich jedoch nicht um gemeldete Probleme in Ausnahmesituationen kümmern. Mit Unterdrückungen können Sie weiterhin nach einem kritischen Problem suchen, ohne wiederholt Nachrichten über Ihre absichtlichen Regelverstöße zu erhalten. Wenn Sie keine Fehlermeldungen für Verstöße gegen eine bestimmte Regel erhalten möchten, empfehlen wir, die Regel vollständig zu deaktivieren (siehe Punkt 1).

Sie können Unterdrückungen normalerweise über die grafische Benutzeroberfläche des statischen Analysetools, eine Konfigurationsdatei oder den Quellcode selbst definieren. Wenn im Quellcode Unterdrückungen definiert sind:

  • Sie stellen sicher, dass dieselben Unterdrückungen angewendet werden, wenn Sie oder ein Teammitglied diesen Code analysieren.
  • Sie können Codekommentare hinzufügen, die jede Unterdrückung erläutern, sodass der Grund für jede Unterdrückung immer klar ist, wenn Sie oder Teammitglieder den Code überprüfen oder ändern.
  • Sie erhalten eine genaue Kontrolle darüber, welche Regeln auf Datei-, Klassen- oder Zeilenebene durchgesetzt werden.

Sie können normalerweise Verstöße gegen eine bestimmte Regel, eine Reihe von Regeln oder alle Verstöße gegen eine bestimmte Kategorie unterdrücken. Sie können auch bestimmte Codeabschnitte von allen statischen Analysen ausnehmen (mehr dazu im folgenden Punkt).

Tipp 4: Stoppen Sie die Analyse problematischer Dateien oder Codestücke

Manchmal ist es einfach nicht sinnvoll, statische Analysen für bestimmte Dateien durchzuführen, z. B. automatisch generierte Dateien oder Legacy-Dateien, die Sie nicht berühren möchten. In diesen Fällen sollten Sie verhindern, dass diese Dateien analysiert werden. Dies ist eine weitere Möglichkeit, um sicherzustellen, dass Ihre Ergebnisse nicht mit einer Reihe von Verstößen überfüllt sind, die Sie nicht beheben möchten.
Es gibt einige Möglichkeiten, dies zu tun. Sie können Pfadfilter einrichten, um Dateien auszuschließen, die Sie nicht überprüfen möchten, oder nur diejenigen einschließen, die Sie überprüfen möchten. Sie können Ihr Tool auch so konfigurieren, dass Dateien mit einem bestimmten Kommentar übersprungen werden, z. B. ein Kommentar, der automatisch generierten Code angibt.

Andere Möglichkeiten, Ihre Prüfung zu fokussieren, sind:

  • Hinzufügen von Markierungen, um bestimmte Codeblöcke anzuzeigen, die in ansonsten ausgenommenen Dateien überprüft werden sollen.
  • Ausschluss bestimmter Methoden in Dateien, die anderweitig analysiert werden.
  • Überprüfen Sie nur Dateien, die seit einem bestimmten Stichtag nicht mehr hinzugefügt oder geändert wurden.
  • Überprüfen Sie nur Dateien, die nach einem „Stichtag“ oder innerhalb einer bestimmten Anzahl von Tagen hinzugefügt oder geändert wurden.

Tipp 5: Benachrichtigen Sie den Hersteller des statischen Analysetools über fehlerhafte Regeln, die zu Fehlalarmen führen

Bei der musterbasierten statischen Analyse sind Fehlalarme Regelverstöße, die fälschlicherweise gemeldet werden, wenn der Code tatsächlich der Regel folgt. Wenn die Regel beispielsweise besagt, dass Sie über eine nicht geschlossene Ressource (z. B. eine JDBC-Verbindung) verfügen und die Verbindung in Wirklichkeit geschlossen ist, ist dies falsch positiv. Wenn Sie auf ein Problem wie dieses aufgrund einer Regel stoßen, die Sie wirklich befolgen möchten, ist der Frühjahrsputz ein guter Zeitpunkt, um es Ihrem Lieferanten endgültig zu melden.

Beachten Sie, dass Sie, wenn Sie diesen Weg gehen, sicher sein müssen, dass Sie ein tatsächlich falsches Positiv betrachten und nicht nur eine Regel, die Sie nicht mögen. Entwickler bezeichnen eine Nachricht häufig als "falsch positiv", weil sie die Regel nicht mögen oder nicht der Meinung sind, dass sie in diesem Fall gilt. Solche Nachrichten sind keine Fehlalarme, und Ihr Anbieter kann Ihnen in diesen Fällen nicht weiterhelfen.

Wenn Sie jedoch einen einfachen Testfall reduzieren können, der zeigt, wie eine bestimmte Regel tatsächlich eine falsche Nachricht erhält, sollten Sie feststellen, dass die meisten Anbieter bei der Behebung des Problems sehr hilfreich sind.

Tipp 6: Passen Sie die Parameter der statischen Analyseregeln an Ihre Anforderungen an

Eine andere Möglichkeit, den Rauschfaktor zu reduzieren, besteht darin, Regelparameter anzupassen. Angenommen, Ihr Team führt eine Android-Entwicklung durch und Sie überprüfen eine Android-Regel, die besagt: "Stellen Sie sicher, dass Widgets nicht zu oft aktualisiert werden."

Mit den Standardeinstellungen identifiziert diese Regel Code, der ein Widget so festlegt, dass es mehr als viermal pro Tag aktualisiert wird. Dazu wird Code markiert, der das Element [android: updatePeriodMillis] im Tag [Appwidget-Provider] auf eine Zahl kleiner als 4 setzt.

Angenommen, das Abrufen aktualisierter Informationen ist für Ihre Anwendung von entscheidender Bedeutung, sodass Sie bereit sind, den Batterieverbrauch für häufigere Updates zu opfern. In diesem Fall möchten Sie möglicherweise nur gewarnt werden, wenn Aktualisierungen mehr als 8 Mal pro Tag erfolgen. Um dies zu erreichen, können Sie einfach den Regelparameter „Maximale Aktualisierungszeit maximal in Millisekunden“ von 21,600,000 ms (6 Stunden) auf 10,800,000 ms (3 Stunden) aktualisieren.

Wie in Tipp 2 erwähnt, können Sie, wenn die Regel nicht die von Ihnen benötigten Parameter enthält, eine neue schreiben, die dies tut - oder Ihren Lieferanten (oder einen Berater) eine benutzerdefinierte Regel für Sie schreiben lassen.

Tipp 7: Ordnen Sie statische Analyseregeln Ihren eigenen Begriffen zu

Haben Sie es satt, sich daran zu erinnern, dass Security 123 Ihrer ACME 3.1-Richtlinie entspricht? Dass sowohl Performance 987 als auch Performance 567 mit Ihrer ACME 5.6-Richtlinie zusammenhängen? Obwohl Ihr Tool angibt, dass Threads 123 den Schweregrad 4 hat, betrachtet Ihre Organisation Verstöße gegen diese Regel als einen sehr schwerwiegenden Fehler?

In diesem Fall ist der Frühjahrsputz ein guter Zeitpunkt, um den statischen Analyseregelsatz Ihres Anbieters so abzubilden, dass er den von Ihrem Team und / oder Ihrer Organisation definierten Richtlinien entspricht. Mit den meisten statischen Analysetools können Sie Regelschweregrade, IDs und Namen anpassen sowie neue Regelkategorien erstellen, sodass die bereitgestellten Regeln genau mit dem Inhalt Ihres eigenen Codierungsrichtliniendokuments übereinstimmen.

Wenn Ihre Organisation im Rahmen von Compliance-Bemühungen statische Analysen durchführt, wird Ihre Berichterstellung erheblich vereinfacht.

Tipp 8: Überprüfen und klären Sie Ihre Richtlinien zur statischen Analyse erneut

Jedes Team hat eine Richtlinie, unabhängig davon, ob sie formal definiert ist oder nicht. Sie können den Prozess genauso gut kodifizieren und offiziell machen. Schließlich ist es viel einfacher, Probleme mit einer formalisierten Richtlinie zu identifizieren und zu diagnostizieren als mit einer ungeschriebenen.

Idealerweise möchten Sie, dass Ihre Richtlinie in direktem Zusammenhang mit den Problemen steht, auf die Sie derzeit stoßen (und / oder die Sie verhindern möchten). Auf diese Weise gibt es eine gute Begründung sowohl für die allgemeine Politik als auch für die spezifische Art und Weise, wie sie umgesetzt wird.

In Anbetracht dieser Ziele sollte in der Richtlinie Folgendes klargestellt werden:

  • Welche Teams benötigen statische Analysen?
  • Welche Projekte erfordern eine statische Analyse
  • Welche Regeln sind erforderlich?
  • Welcher Grad an Compliance ist erforderlich?
  • Wenn Unterdrückungen erlaubt sind
  • Wenn Verstöße im Legacy-Code behoben werden müssen
  • Gibt an, ob Sie Code mit Verstößen gegen die statische Analyse versenden

Tipp 9: Erhöhen Sie den Analyseumfang

Sobald Sie die Unordnung beseitigt haben und an dem Punkt angelangt sind, an dem das Team an die Durchführung statischer Analysen gewöhnt ist, werden nur wenige Probleme gemeldet, und diese gemeldeten Probleme werden umgehend behoben. Sie können den nächsten Schritt ausführen und die erweitern Prüfungsumfang.

Eine Möglichkeit, den Prüfungsumfang zu erweitern, besteht darin, weitere Regeln hinzuzufügen, die für Ihre Projekte und Ziele von entscheidender Bedeutung sind. Beachten Sie Folgendes, um herauszufinden, welche Regeln hinzugefügt werden sollen:

  • Welche Regeln verhindern wahrscheinlich vor Ort gemeldete Probleme, die einen Großteil der Ressourcen Ihres Teams beanspruchen?
  • Welche Regeln würden Ihnen helfen, Ihre Bemühungen zu beschleunigen, wenn Sie bald damit beginnen müssen, branchenspezifische oder organisatorische Compliance-Initiativen einzuhalten?
  • Welche Regeln haben Sie beim ersten Erstellen oder letzten Optimieren Ihres Regelsatzes am ungernsten gekürzt?

Eine andere Möglichkeit, den Überprüfungsumfang zu erweitern, besteht darin, zusätzlichen Code zu überprüfen. Wenn Sie Ihr statisches Analysetool anfangs so eingestellt haben, dass ältere Dateien übersprungen werden (z. B. Dateien, die nach dem Stichtag zu Beginn der statischen Analyse nicht hinzugefügt oder geändert wurden), sollten Sie dieses Stichtag verschieben oder entfernen es insgesamt.

Tipp 10: Automatisieren, automatisieren, automatisieren

Je mehr Sie den statischen Analyseprozess automatisieren können, desto weniger werden Entwickler belastet und von den anspruchsvolleren Aufgaben abgelenkt, die ihnen wirklich Spaß machen. Darüber hinaus hilft Ihnen die zusätzliche Automatisierung dabei, konsistente Ergebnisse im gesamten Team und in der Organisation zu erzielen.

Viele Unternehmen folgen einem mehrstufigen automatisierten Prozess. Während der Entwickler jeden Tag an Code in der IDE arbeitet, kann er die Analyse bei Bedarf ausführen - oder eine automatisierte Analyse so konfigurieren, dass sie kontinuierlich im Hintergrund ausgeführt wird (wie dies bei der Rechtschreibprüfung der Fall ist). Entwickler bereinigen diese Verstöße, bevor sie der Quellcodeverwaltung neuen oder geänderten Code hinzufügen.

Anschließend überprüft ein serverbasierter Prozess, ob die eingecheckte Codebasis sauber ist. Diese Analyse kann im Rahmen einer kontinuierlichen Integration auf nächtlicher Basis usw. durchgeführt werden, um sicherzustellen, dass nichts durch die Risse rutscht. Bei einem solchen serverbasierten Prozess ist es wichtig, das alte Paradigma des Versendens von E-Mails an Entwickler zu vermeiden. Ein Teil eines effektiven Workflows besteht darin, die Fehlermeldungen an dieselbe Benutzeroberfläche zu verteilen, auf der der Entwickler Code schreibt. E-Mails erzwingen zusätzliche Schritte, was zu verpassten Verstößen, Zeitverschwendung beim Finden der richtigen Zeile in der Datei und mehr Ressentiments von Programmierern führt, die das Gefühl haben, außerhalb ihres regulären Prozesses etwas Besonderes zu tun.

Beachten Sie Folgendes, um den Workflow durch Automatisierung weiter zu optimieren:

  • Automatisches Weiterleiten jedes gemeldeten Problems direkt an den zuständigen Entwickler sowie Anpassen der Problempriorisierung an Ihre Richtlinienprioritäten, um sicherzustellen, dass Ihre kritischsten Probleme rechtzeitig behoben werden.
  • Zentralisierung des Konfigurationsmanagements, um sicherzustellen, dass Regelsätze konsistent angewendet werden und mühelos aktualisiert werden können, wenn sich Prioritäten und Prozesse weiterentwickeln.
  • Nutzen Sie das automatisierte „Quick Fix“ -Refactoring, wann immer dies möglich ist, um das Team dabei zu unterstützen, Regelverstöße so schnell wie möglich zu korrigieren.

Von Arthur Hicken

Arthur ist seit über 25 Jahren bei Parasoft im Bereich Software-Sicherheit und Testautomatisierung tätig. Er hilft bei der Erforschung neuer Methoden und Techniken (einschließlich 5 Patente) und hilft Kunden dabei, ihre Software-Praktiken zu verbessern.

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