Découvrez comment la solution Parasoft Continuous Quality permet de contrôler et de gérer les environnements de test pour fournir des logiciels de haute qualité en toute confiance. Inscrivez-vous pour la démo >>

BLOG

10 conseils pour le nettoyage de l'analyse statique

10 conseils pour le nettoyage de l'analyse statique Temps de lecture : 8 minutes
Vous voulez nettoyer votre pratique d'analyse statique? Commencez par éliminer le désordre qui rend difficile de vous concentrer sur les problèmes qui vous tiennent vraiment à cœur. Ensuite, revigorez votre initiative en élargissant sa portée de manière à accroître sa valeur pour votre organisation.

Votre équipe de développement est-elle submergée par le nombre croissant de violations de votre outil d'analyse statique? Le niveau élevé de bruit généré par votre configuration d'analyse statique actuelle a-t-il désensibilisé l'équipe à toutes les alertes, y compris celles relatives à des problèmes que vous considérez comme critiques?

Voici 10 façons de rafraîchir votre implémentation d'analyse statique existante, quoi qu'il arrive outil d'analyse statique vous utilisez.

Astuce 1: Désactivez les règles d'analyse statique pour les violations que vous n'êtes pas résolu à corriger pour le moment

Vérifier un grand nombre de règles n'est pas le secret pour obtenir le meilleur retour sur investissement avec une analyse statique. En fait, dans de nombreux cas, l'inverse est vrai. L'analyse statique donne en fait de meilleurs résultats si vous vous concentrez sur un ensemble de règles minimal mais significatif.

Lorsque vous effectuez une analyse statique, c'est comme si vous demandiez à un développeur expérimenté de se tenir au-dessus de l'épaule d'un développeur inexpérimenté et de lui donner des conseils pendant qu'il écrit du code. Si le développeur expérimenté insiste constamment sur des problèmes épineux dans toutes les quelques lignes de code, le développeur le moins expérimenté sera bientôt submergé et commencera à filtrer tous les conseils, bons et mauvais. Cependant, si le développeur expérimenté se concentre sur un ou deux problèmes dont il sait qu'ils sont susceptibles de causer de graves problèmes, le développeur le moins expérimenté est beaucoup plus susceptible de se souvenir des conseils qui ont été donnés, de commencer à écrire un meilleur code et d'apprécier réellement recevoir ce genre de commentaires. .

C'est la même chose pour l'analyse statique. Si vous le gardez gérable et significatif, vous finirez par en apprendre davantage à vos développeurs et en leur faisant beaucoup moins ressentir le processus. Préférez-vous avoir un petit ensemble de règles qui sont suivies ou un grand ensemble qui ne le sont pas? Si vous ne vous attendez pas vraiment à ce que les développeurs nettoient les violations d'une règle dès qu'elles sont signalées, vous pouvez envisager sérieusement de désactiver cette règle.

Astuce 2: Désactiver les règles d'analyse statique générant trop de bruit

Si une règle particulière est violée à plusieurs reprises, c'est maintenant une bonne occasion de réévaluer si vous voulez vraiment continuer à vérifier cette règle. Un nombre excessif de violations indique que les développeurs n'écrivent pas de code comme l'exige la règle. Les convaincre de changer leurs habitudes de codage pourrait rencontrer une certaine résistance.

Comment pouvez-vous déterminer si le fait d'appuyer sur le problème en vaudra la peine? Tout d'abord, essayez de vous rappeler pourquoi vous avez commencé à rechercher ce problème. L'avez-vous sélectionné parce qu'il semblait être un bon moyen de résoudre les problèmes que vous rencontrez sur le terrain? Dans le cadre de vos efforts de conformité réglementaire? Ou simplement parce qu'il a été activé par défaut par le fournisseur? Les fournisseurs fournissent généralement la référence pour chaque règle dans leurs descriptions de règles. La lecture de ces descriptions peut vous aider à déterminer si la règle correspond vraiment à vos projets et objectifs.

Ensuite, voyez s'il existe une autre façon d'obtenir le résultat souhaité. Existe-t-il une règle alternative plus précise? Existe-t-il un moyen d'affiner les paramètres de la règle afin qu'elle ne se déclenche pas si souvent? (Plus d'informations à ce sujet dans le conseil n ° 6). Vous pouvez même envisager de rédiger votre propre règle qui conviendra mieux - ou demander au fournisseur de créer une règle personnalisée pour vous.

Si vous souhaitez toujours vérifier cette règle après avoir réexaminé ses avantages et exploré ses alternatives, obtenez des commentaires de développement sur ce qui serait impliqué dans le respect de cette règle. Vous pouvez ensuite utiliser ces commentaires pour déterminer s'il vaut vraiment la peine d'exiger des développeurs qu'ils suivent cette règle. Si cela ressemble à beaucoup de travail pour peu d'avantages, allez-y et désactivez la règle.

Astuce 3: Utilisez des suppressions pour autoriser les violations dans des situations spécifiques

Dans certains cas, vous pouvez être déterminé à suivre une règle, mais souhaitez autoriser des exemptions dans certaines circonstances. Par exemple, vous avez peut-être une règle qui nécessite un niveau supplémentaire de validation dans le code. Supposons que vous ayez une certaine méthode avec un code critique pour les performances qui est appelé des centaines de fois par minute et que vous avez déjà vérifié qu'un niveau de validation approprié est effectué avant que cette méthode particulière ne soit appelée. Ou supposons que l'analyse basée sur les flux vous avertisse d'un problème grave dans un chemin dont vous êtes certain à 100% qu'il ne peut pas être pris dans l'application intégrée. C'est là que les suppressions sont utiles.

Les suppressions sont idéales pour les situations où vous souhaitez vérifier quelque chose, mais que vous ne vous souciez pas des problèmes signalés dans des situations exceptionnelles. Grâce aux suppressions, vous pouvez continuer à rechercher un problème critique sans recevoir de messages répétés concernant vos violations intentionnelles de règles. Si vous ne souhaitez pas recevoir de messages d'erreur pour des violations d'une règle spécifique, nous vous recommandons de désactiver complètement la règle (voir le point 1).

Vous pouvez généralement définir des suppressions à partir de l'interface graphique de l'outil d'analyse statique, d'un fichier de configuration ou du code source lui-même. Lorsque les suppressions sont définies dans le code source:

  • Vous vous assurez que les mêmes suppressions sont appliquées chaque fois que vous ou un membre de l'équipe analysez ce code.
  • Vous pouvez ajouter des commentaires de code expliquant chaque suppression afin que la raison de chaque suppression soit toujours claire lorsque vous ou les membres de l'équipe révisez ou modifiez le code.
  • Vous bénéficiez d'un contrôle précis sur les règles appliquées au niveau du fichier, de la classe ou de la ligne.

Vous pouvez généralement supprimer les violations d'une règle spécifique, d'un certain nombre de règles ou de toutes les violations d'une catégorie spécifique. Vous pouvez également exempter certaines sections de code de toute analyse statique (plus d'informations à ce sujet dans le point suivant).

Astuce 4: Arrêtez d'analyser les fichiers problématiques ou les morceaux de code

Parfois, il n'est tout simplement pas logique d'exécuter une analyse statique sur certains fichiers, par exemple, des fichiers générés automatiquement ou des fichiers hérités que vous n'avez pas l'intention de toucher. Dans ces cas, vous devez empêcher l'analyse de ces fichiers. C'est encore un autre moyen de vous assurer que vos résultats ne sont pas encombrés d'un tas de violations que vous ne prévoyez pas de corriger.
Il y a quelques façons de le faire. Vous pouvez configurer des filtres de chemin pour exclure les fichiers que vous ne souhaitez pas vérifier ou inclure uniquement ceux que vous souhaitez vérifier. Vous pouvez également configurer votre outil pour ignorer les fichiers contenant un certain commentaire, tel qu'un commentaire indiquant un code généré automatiquement.

D'autres moyens de cibler votre vérification incluent:

  • Ajout de marqueurs pour indiquer des blocs de code spécifiques que vous souhaitez vérifier dans des fichiers autrement exemptés.
  • Excluant certaines méthodes dans des fichiers qui sont par ailleurs analysés.
  • Vérifier uniquement les fichiers qui n'ont pas été ajoutés ou modifiés depuis une certaine date limite.
  • Vérifier uniquement les fichiers qui ont été ajoutés ou modifiés après une «date limite» ou dans un certain nombre de jours.

Astuce 5: Avertir le fournisseur de l'outil d'analyse statique des règles non respectées provoquant des faux positifs

Avec l'analyse statique basée sur des modèles, les faux positifs sont des violations de règle qui sont signalées par erreur lorsque le code suit réellement la règle. Par exemple, si la règle indique que vous avez une ressource non fermée (telle qu'une connexion JDBC), alors qu'en réalité la connexion est fermée, il s'agit d'un faux positif. Si vous rencontrez un problème comme celui-ci sur une règle que vous voulez vraiment suivre, le nettoyage de printemps est le moment idéal pour enfin le signaler à votre fournisseur.

Notez que si vous empruntez cette voie, vous devez être certain que vous regardez un faux positif réel, plutôt qu'une simple règle que vous n'aimez pas. Les développeurs qualifient fréquemment un message de «faux positif» parce qu'ils n'aiment pas la règle ou ne pensent pas qu'elle s'applique dans ce cas. De tels messages ne sont pas des faux positifs et votre fournisseur ne pourra pas vous aider dans ces cas.

Cependant, si vous pouvez réduire un cas de test simple qui montre comment une règle particulière reçoit réellement un faux message, vous devriez trouver que la plupart des fournisseurs sont très utiles pour résoudre le problème.

Astuce 6: Personnalisez les paramètres des règles d'analyse statique en fonction de vos besoins

Une autre façon de réduire le facteur de bruit consiste à personnaliser les paramètres de règle. Par exemple, supposons que votre équipe travaille sur le développement Android et que vous vérifiez une règle Android qui dit "Assurez-vous que les widgets ne sont pas mis à jour trop souvent".

Avec les paramètres par défaut, cette règle identifie le code qui définit un widget pour qu'il se mette à jour plus de 4 fois par jour. Pour ce faire, il marque le code qui définit l'élément [android: updatePeriodMillis] dans la balise [appwidget-provider] sur un nombre inférieur à 216,00,000 XNUMX.

Supposons que la mise à jour des informations soit essentielle pour votre application, vous êtes donc prêt à sacrifier une partie de la consommation de la batterie pour des mises à jour plus fréquentes. Dans ce cas, vous souhaiterez peut-être être averti uniquement si les mises à jour se produisent plus de 8 fois par jour. Pour ce faire, vous pouvez simplement mettre à jour le paramètre de règle «Durée maximale de mise à jour en millisecondes» de 21,600,000 6 10,800,000 ms (3 heures) à XNUMX XNUMX XNUMX ms (XNUMX heures).

Comme le mentionne le conseil n ° 2, si la règle ne contient pas les paramètres dont vous avez besoin, vous pouvez en écrire une nouvelle qui le fait ou demander à votre fournisseur (ou à un consultant) d'écrire une règle personnalisée pour vous.

Astuce 7: Mappez les règles d'analyse statique à vos propres termes

Êtes-vous fatigué de vous rappeler que Security 123 est équivalent à votre directive ACME 3.1? Que les performances 987 et 567 sont liées à votre directive ACME 5.6? Même si votre outil indique que Threads 123 est de gravité 4, votre organisation considère que les violations de cette règle sont un défaut très grave?

Si tel est le cas, le nettoyage de printemps est le moment idéal pour mapper l'ensemble de règles d'analyse statique de votre fournisseur pour correspondre aux politiques distinctes définies par votre équipe et / ou organisation. La plupart des outils d'analyse statique vous permettent de personnaliser la gravité, les ID et les noms des règles, ainsi que de créer de nouvelles catégories de règles, afin que les règles déployées correspondent précisément au contenu de votre propre document de politique de codage.

Si votre organisation effectue une analyse statique dans le cadre d'un effort de conformité, cela rendra votre reporting beaucoup plus facile.

Astuce 8: Réexaminez et clarifiez votre politique d'analyse statique

Chaque équipe a une politique, qu'elle soit formellement définie ou non. Vous pourriez aussi bien codifier le processus et le rendre officiel. Après tout, il est beaucoup plus facile d'identifier et de diagnostiquer les problèmes avec une politique formalisée qu'avec une politique non écrite.

Idéalement, vous voulez que votre politique ait une corrélation directe avec les problèmes que vous rencontrez actuellement (et / ou que vous vous engagez à prévenir). De cette façon, il y a une bonne justification à la fois de la politique générale et des moyens spécifiques dont elle est mise en œuvre.

En gardant ces objectifs à l'esprit, la politique devrait clarifier:

  • Ce dont les équipes ont besoin pour effectuer une analyse statique
  • Quels projets nécessitent une analyse statique
  • Quelles règles sont requises
  • Quel degré de conformité est requis
  • Quand les suppressions sont autorisées
  • Quand les violations du code hérité doivent être corrigées
  • Si vous expédiez du code avec des violations d'analyse statique

Astuce 9: Augmenter la portée de l'analyse

Une fois que vous avez nettoyé le désordre et que vous êtes au point où l'équipe est habituée à effectuer une analyse statique, peu de problèmes sont signalés et ces problèmes signalés sont nettoyés rapidement, vous pouvez passer à l'étape suivante et développer le étendue de la vérification.

Une façon d'élargir la portée de la vérification consiste à ajouter d'autres règles essentielles à vos projets et à vos objectifs. Pour vous concentrer sur les règles à ajouter, considérez:

  • Quelles règles semblent susceptibles d'éviter les problèmes signalés sur le terrain qui consomment une grande partie des ressources de votre équipe?
  • Si vous devez bientôt commencer à vous conformer à des initiatives de conformité spécifiques à votre secteur ou à votre organisation, quelles règles vous aideraient à relancer vos efforts?
  • Lorsque vous avez créé ou optimisé pour la dernière fois votre ensemble de règles, quelles règles étiez-vous le plus réticent à supprimer?

Une autre façon d'augmenter la portée de la vérification consiste à vérifier du code supplémentaire. Si vous avez initialement configuré votre outil d'analyse statique pour ignorer les fichiers hérités (par exemple, ignorer tous les fichiers qui n'ont pas été ajoutés ou modifiés après la date «limite» lorsque vous avez commencé l'analyse statique), vous pouvez envisager de reculer cette date limite - ou d'éliminer tout à fait.

Astuce 10: Automatisez, automatisez, automatisez

Plus vous pouvez automatiser le processus d'analyse statique, moins cela va alourdir les développeurs et les distraire des tâches les plus difficiles qu'ils apprécient vraiment. De plus, l'automatisation supplémentaire vous aidera à obtenir des résultats cohérents au sein de l'équipe et de l'organisation.

De nombreuses organisations suivent un processus automatisé à plusieurs niveaux. Chaque jour, lorsque le développeur travaille sur du code dans l'EDI, il peut exécuter une analyse à la demande - ou configurer une analyse automatisée pour qu'elle s'exécute en continu en arrière-plan (comme le fait la vérification orthographique). Les développeurs nettoient ces violations avant d'ajouter du code nouveau ou modifié au contrôle de code source.

Ensuite, un processus serveur vérifie à nouveau que la base de code archivée est propre. Cette analyse peut s'exécuter dans le cadre d'une intégration continue, tous les soirs, etc. pour s'assurer que rien n'a glissé entre les mailles du filet. Avec un tel processus basé sur un serveur, il est important d'éviter l'ancien paradigme d'envoi d'e-mails aux développeurs. Une partie d'un flux de travail efficace consiste à distribuer les messages d'erreur à la même interface utilisateur où le développeur écrit le code. Le courrier électronique force des étapes supplémentaires, ce qui entraîne des violations manquées, du temps perdu à trouver la bonne ligne dans le fichier et plus de ressentiment de la part des codeurs qui ont l'impression de faire quelque chose de plus en dehors de leur processus habituel.

Pour optimiser davantage le flux de travail grâce à l'automatisation, envisagez:

  • Acheminer automatiquement chaque problème signalé directement au développeur responsable, ainsi que personnaliser la hiérarchisation des problèmes en fonction des priorités de votre politique, pour vous assurer que vos problèmes les plus critiques sont résolus en temps opportun.
  • Centralisation de la gestion de la configuration pour garantir que les ensembles de règles sont appliqués de manière cohérente et peuvent être mis à jour sans effort à mesure que les priorités et les processus évoluent.
  • Tirer parti de la refactorisation automatisée «Quick Fix» chaque fois que possible pour aider l'équipe à corriger les violations de règles aussi rapidement que possible.
Écrit 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.