Découvrez comment intégrer facilement l'analyse statique, les tests unitaires et d'autres méthodes de test de logiciels C et C++ dans votre pipeline CI/CD. Inscrivez-vous pour la démo >>

Adoptez l'analyse statique à petits pas

Par Arthur Hicken

23 juillet 2020

5  min lire

Jusqu'à présent, 2020 a été une année difficile. Comme nous sommes de plus en plus nombreux à travailler à distance de chez eux, il est plus important que jamais que le code que nous produisons soit aussi bon que possible. L'analyse statique est un point de focalisation parfait pour les développeurs de logiciels et les professionnels de la sécurité et de la sécurité fonctionnelle.

Nous savons tous que l'analyse de code statique est quelque chose que nous devrions faire. Certains d'entre nous savent que nous devrions le faire parce que cela nous aidera. D'autres peuvent avoir l'impression que l'analyse statique leur est imposée et que c'est une perte de temps, fastidieuse ou que cela crée du travail avec peu d'avantages. Même si je voudrais dire que ces gens ont tort, malheureusement, ils ont probablement raison!

Mordre plus que vous ne pouvez mâcher

Si l'analyse statique est lente, bruyante (faux positifs), pénible à utiliser, crée du travail ou n'apporte pas de valeur, c'est généralement parce que vous mordez plus que vous ne pouvez mâcher. Une bonne configuration des outils d'analyse statique est également un facteur important, mais c'est un problème distinct en soi, et je le couvrirai dans un autre article.

Pour cet article, je veux me concentrer sur une erreur commise par de nombreux utilisateurs novices de l'analyse statique: essayer d'en faire trop trop tôt. Dans l'ensemble, obtenir un flux de travail et une configuration d'analyse statique corrects dès le début est essentiel au succès - moins de douleur, plus de gain. La première étape consiste à vous assurer que vous disposez du bon outil pour votre organisation. Récemment, nous avons produit un webinaire un whitepaper couvrant les bases de la façon de choisir le bon outil d'analyse statique pour répondre à vos besoins, alors vérifiez-les.

Commencez petit avec l'analyse statique

Une fois que vous avez sélectionné l'outil d'analyse de code statique, vous devez le configurer. Quels contrôleurs voulez-vous exécuter? Je commencerais par une directive simple: il est préférable de commencer avec un petit ensemble de vérificateurs, même un seul vérificateur si nécessaire, et assurez-vous que vous et votre équipe perfectionnez vos compétences en analyse statique et votre flux de travail tout en bénéficiant de l'effort démontrable. L'alternative courante consiste à activer une centaine de vérificateurs ou plus qui produisent des rapports volumineux que vous suivez sporadiquement.

Les outils d'analyse statique peuvent produire beaucoup de bruit jusqu'à ce qu'ils soient redressés. Quand je dis «mordre plus que vous ne pouvez mâcher», le bruit (parfois appelé faux positifs) l'emporte sur les avertissements importants. L'adoption précoce commence parfois par une recherche académique dans le but d'une enquête précoce pour avoir une idée du nombre d'erreurs dans la base de code. Cette méthode ne prend pas en compte le flux de travail des développeurs et leur utilisation quotidienne des outils. Cela ne correspond pas non plus au besoin pragmatique de faire écrire, tester et sortir des logiciels.

La meilleure approche est de commencer petit dans le but d'améliorer constamment et progressivement la qualité du code. Éliminez vos problèmes de code critiques les plus gênants, puis développez-le pour rechercher d'autres problèmes qui sont toujours importants mais peut-être pas aussi dangereux. Voyons comment cela fonctionne dans un sens pratique.

Commencez par s'attaquer aux gros problèmes

Nous voyons parfois des organisations essayer d'assembler une liste de configuration de vérificateurs par consensus sur la base d'une grande liste de tous les vérificateurs possibles fournis par un outil d'analyse statique. Bien que plausible, si vous considérez que les outils Parasoft ont plus d'un millier de vérificateurs, l'approche est imparfaite car elle se concentre sur ce que l'outil peut faire, et non sur la résolution des problèmes réels auxquels votre application est confrontée en fonction du support client, de l'environnement attendu, etc. sur.

Les équipes peuvent passer beaucoup de temps à rechercher les violations des vérificateurs qui ne fournissent pas beaucoup de valeur, même si le type d'erreur semble important dans l'abstrait. Il est essentiel de relier l'analyse statique aux vrais problèmes que l'équipe résout ou s'attend à affronter. Réduire la liste des vérificateurs est important, mais peut encore produire trop de violations pour une équipe ou un projet qui ne fait que commencer. Vous devez regarder la taille de la «morsure» que vous prenez.

Limitez la «morsure» de l'analyse statique

Un excellent moyen de minimiser la taille de la morsure que vous prenez (ce n'est pas seulement le nombre de vérificateurs) est d'évaluer le code sur lequel vous l'exécutez. La plupart des projets de nos jours consistent en des bases de code existantes, héritées ou héritées. Si ceux-ci sont suffisamment volumineux, il n'est pas pratique d'exécuter une analyse statique sur ce code et de dédier des ressources pour résoudre les problèmes. Vous devez limiter la «morsure» en termes de quantité de code analysé.

Une approche courante consiste à limiter l'action sur les avertissements signalés au code nouvellement développé ou récemment modifié. Par exemple, le chef d'équipe décide qu'au prochain sprint, tout nouveau code sera analysé avec un ensemble de départ de vérificateurs prioritaires. Le premier ensemble de rapports d'analyse est utilisé pour évaluer la quantité de travail nécessaire. Si c'est trop pour un sprint, l'analyse peut être encore limitée. D'un autre côté, si cette approche ne produit pas suffisamment d'avertissements ou si des objectifs de qualité sont manqués, augmentez la portée.

Tout cela pour dire: prenez une petite bouchée, une bouchée de grande valeur. Réparez-le, accomplissez quelque chose, intégrez-le à votre processus quotidien et à votre culture. Ajoutez-y lentement. Définissez quelques pions supplémentaires, et finalement, vous atteindrez votre objectif ambitieux de tous les pions voulus au début.

Observez et augmentez la valeur de l'analyse statique au fil du temps

Commencer petit, c'est plus que contrôler un flux de travail gérable. Cela aide également les développeurs, qui sont nouveaux dans la technique et novices dans l'outil, à voir rapidement la valeur. En leur donnant d'abord des résultats critiques, ils voient les bogues qu'il est important de corriger et comprennent comment les tests ou les révisions de code ont pu les manquer. Au fur et à mesure que vous accélérez l'analyse, les développeurs obtiennent toujours les résultats les plus exploitables. Le but est de ne jamais arriver là où vous donnez aux développeurs des avertissements de faible valeur. C'est une perte de temps et d'outils, et vous devez tirer parti de vos processus pour les filtrer.

Évitez le triage

Il n'est pas rare que le triage apparaisse lors de la discussion des résultats de l'analyse de code statique. Le triage n'est utilisé dans la vraie vie que lorsqu'un processus est dépassé. Les équipes logicielles qui prennent trop de place exécutent des outils d'analyse statique sur une grande base de code avec des vérificateurs par défaut activés et se retrouvent inévitablement avec de nombreux avertissements. Ils essaient ensuite de les parcourir et de dire lesquels dois-je corriger? Lesquels sont les plus importants? C'est fastidieux, trop subjectif, sujet aux erreurs et surtout inutile.

Les outils doivent trier pour vous. Si ce n'est pas le cas, vous avez probablement le mauvais outil, la mauvaise configuration ou la mauvaise approche. Un outil d'analyse statique moderne doit être capable de filtrer les avertissements en fonction de la gravité, de la priorité et du risque inhérent. Ne laissez pas l'outil lui-même vous forcer à prendre une trop grosse morsure.

Résumé

J'espère que vous trouverez ces conseils utiles. L'adoption réussie de l'analyse statique nécessite de petits pas avant de progresser dans l'amélioration de la qualité, de la sûreté et de la sécurité. Limiter combien votre équipe «mord» en limitant la portée de l'analyse à la fois en termes de vérificateurs et de quantité de code - tout le monde peut voir la valeur. Éviter «une morsure trop grosse» évite de nombreuses plaintes courantes concernant les outils d'analyse statique. Des améliorations continues et progressives aident tout le monde à apprendre à travailler avec l'analyse statique et à obtenir une meilleure valeur pour l'investissement.

Bonne chance pour votre voyage d'analyse statique dans le reste de 2020!

Regardez Parasoft en action

Par Arthur Hicken

Arthur est impliqué dans la sécurité logicielle et l'automatisation des tests chez Parasoft depuis plus de 25 ans, aidant à la recherche de nouvelles méthodes et techniques (dont 5 brevets) tout en aidant les clients à améliorer leurs pratiques logicielles.

Recevez les dernières nouvelles et ressources sur les tests de logiciels dans votre boîte de réception.