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

Intégration de l'analyse statique dans les flux de travail quotidiens

Intégration de l'analyse statique dans les flux de travail quotidiens Temps de lecture : 4 minutes
Pour réussir à adopter l'analyse statique dans votre projet, il est important de vous assurer que votre outil d'analyse statique est facile à utiliser et facilement accessible par les développeurs, en fournissant des informations utiles et exploitables dès le départ. Alors quoi? Dans cet article, découvrez comment maximiser l'adoption de votre analyse statique avec un flux de travail quotidien efficace.

Si vous n'avez pas lu le blog de la semaine dernière sur démarrer avec l'analyse statique, Je vous recommande de le faire, pour comprendre comment interpréter vos premiers rapports à partir d'outils d'analyse statique et gérer les analyses initiales sans surcharger l'équipe.

La deuxième partie de cette petite série de mise en route porte sur la façon d'intégrer des outils d'analyse statique dans vos flux de travail quotidiens. Comment intégrez-vous l'analyse statique au quotidien?

En fait, c'est la clé. S'assurer que votre adoption de l'analyse statique est un succès dans votre projet consiste à s'assurer que les outils sont faciles à utiliser et facilement accessibles par les développeurs, en fournissant des informations utiles et exploitables dès le départ. Ceci est mieux réalisé dans l'environnement dans lequel le développeur travaille (IDE), comme Eclipse ou Visual Studio. Les avertissements d'analyse statique sont fournis de la même manière que les erreurs du compilateur dans l'EDI, et ces avertissements sont mis en évidence dans le code pour faciliter l'analyse et la correction. Par exemple, voir cette capture d'écran des avertissements d'analyse statique de Parasoft Jtest intégrés dans Eclipse:

Comme vous pouvez le voir dans l'exemple ci-dessus d'une application Java dans Eclipse, l'analyse statique résulte de Jtest Parasoft sont livrés dans une vue d'avertissements / d'erreur (1) et peuvent être interagis avec n'importe quel autre message d'erreur. La sélection d'une erreur amène le volet de l'éditeur (2) à la ligne de code en question, ce qui fait également apparaître la trace du flux de contrôle dans le code qui peut être utilisé pour rechercher les causes profondes de l'avertissement. Si une correction est nécessaire, le code peut être soumis, comme d'habitude, via la vue de navigation du projet (3).

Alors, que fait un développeur lors de l'analyse de chaque avertissement? Ceci est mieux décrit dans un diagramme de processus, illustré ci-dessous:

Étape 1: Agréger et filtrer les avertissements

Cela commence par l'agrégation et le filtrage des résultats de l'analyse statique, une première étape essentielle pour hiérarchiser et se concentrer sur les avertissements clés. Habituellement, l'AQ et les chefs d'équipe décident de l'objectif de qualité à l'esprit et structurent la configuration de l'analyse autour de cet objectif. Pour améliorer la sécurité, par exemple, les vérificateurs liés à la sécurité seraient activés avec une norme de codage sécurisé telle que CERT C.

Étapes 2 à 4: rechercher, hiérarchiser et corriger les avertissements

Les développeurs enquêtent ensuite et corrigent les avertissements qu'ils trouvent, en fonction des politiques mises en place par l'équipe et de la maturité du produit. Comme expliqué dans mon dernier post, dans un nouveau projet, la plupart des avertissements seraient examinés et classés par ordre de priorité car la quantité de code serait relativement faible, tandis qu'à des stades ultérieurs de maturité, le filtrage et la hiérarchisation seraient plus stricts, de sorte que les développeurs ne traiteraient que les avertissements vraiment critiques. Dans les deux cas, le processus est le même.

Étape 5: enregistrement à la source

Une fois les modifications apportées en réponse à un avertissement d'analyse statique, le code est archivé dans le contrôle de version et analysé à nouveau lors de la prochaine génération. Cette boucle de rétroaction courte et serrée améliore considérablement la qualité et la sécurité du code au moment où il est écrit et modifié.

Intégration dans les systèmes de construction et les pipelines d'intégration continue

Le principal point d'intégration des outils d'analyse statique et des systèmes de construction se fait via une interface de ligne de commande. L'analyse statique utilisée de cette manière agit un peu comme le ferait un compilateur dans la structure de construction. Les fichiers sont traités de la même manière, bien que la sortie ne soit pas un exécutable, mais plutôt des résultats stockés dans un référentiel, indexés par fichier et numéro de build.

Avec Parasoft C / C ++test , par exemple, cela est géré par le système de reporting et d'analyse de Parasoft (Parasoft DTP), qui est à la fois un référentiel et un moteur de renseignement qui analyse les résultats. Cette analyse et les informations qui l'accompagnent sont renvoyées à chaque développeur dans son IDE et mises à disposition via le portail Web de Parasoft pour les gestionnaires et les chefs d'équipe.

Dans le diagramme ci-dessus, vous voyez comment nous intégrons les outils d'analyse statique de Parasoft dans un pipeline d'intégration continue. Parasoft DTP est le référentiel central et le moteur d'analyse des avertissements.

Résumé

L'intégration de l'analyse statique dans les flux de travail quotidiens nécessite à la fois que le développeur accède à l'analyse statique directement dans l'EDI, ainsi que la capacité d'effectuer une analyse, des rapports et une gestion à l'échelle du projet. Il est essentiel d'assister les développeurs directement là où ils travaillent avec du code, ainsi que les chefs d'équipe et les responsables ayant accès aux mêmes informations avec leurs propres informations et rapports sur les tendances, pour tirer pleinement parti de l'analyse statique d'un projet.

Envie de plus? Revenez bientôt pour la prochaine partie de cette petite série. Je vais vous expliquer comment gérer les arriérés d'alerte et les dettes techniques.

Premiers pas avec l'analyse statique

Écrit par

Billy McMullin

En tant qu'architecte de solutions chez Parasoft, Billy aide les équipes à élaborer des stratégies et à établir des priorités à mesure qu'elles adoptent des pratiques de développement et de test de logiciels modernes dans leur organisation.

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