Introduction

Les tests statiques reposent sur un examen manuel (revue) ou sur une évaluation outillée (analyse statique) des produits d’activité par les activités d’un projet sans que du code ne soit exécuté. On pense bien sûr au code informatique, mais les produits d’activité concernent également les spécifications, les cas de tests, les manuels utilisateurs. Si, comme les tests dynamiques, les tests statiques permettent d’assurer l’évaluation des caractéristiques de qualité logicielle [ISO25010], ils concernent TOUS les produits d’activité et non seulement le code informatique. Ils sont donc un très bon moyen pour contribuer à la réussite d’un projet informatique.

Malgré ce constat, il existe peu d’articles dans la littérature pour montrer leurs intérêts, leur mise en œuvre et ainsi favoriser leur utilisation dans les plans de tests. Vous trouverez tout de même le post de Marc Hage Chahine sur le site « latavernedutesteur » [TAVERNE] intitulé « Les tests statiques, rois du ROI ». Pour les autres, ce sont principalement des comparaisons entre les tests statiques et les tests dynamiques qui reprennent le contenu du syllabus CFTL Fondation [FONDATION].

Le plan de test est la documentation décrivant les objectifs de test à atteindre, les moyens mis en œuvre et le calendrier pour atteindre ces objectifs [ISO29119]. Cette documentation est organisée pour coordonner et piloter les activités de test. Il rend compte de toutes les décisions qui ont été prises par l’équipe de tests, en collaboration avec les autres équipes du projet, pour garantir la validation des caractéristiques de qualité logicielle à tester [ISO25010].

Parmi ces décisions, on trouve l’utilisation des techniques de tests statiques.

Les techniques de test statique

La revue

Le syllabus « fondation » [FONDATION] définit le processus de revue comme un examen manuel des produits d’activité.  A chaque type de revue, de la moins formelle (revue informelle) à la plus formelle (inspection), est associé des exigences. L’objectif de la revue est l’amélioration de la qualité du produit d’activité revu. L’effort de revue (i.e. l’effort de test) doit être en adéquation avec le risque associé au produit d’activité identifié lors de l’analyse de risque.

Pour chaque type de revue (revue informelle, relecture technique, revue technique, inspection), les relecteurs recevront des objectifs de revue (des directives) comme l’orthographe, le vocabulaire, l’exploitabilité, la cohérence technique, la complétude fonctionnelle, les règles de codage, la conformité à un standard documentaire. Chaque objectif peut être rapproché d’une caractéristique de qualité logicielle (par exemples : la conformité à une standard documentaire facilité l’utilisabilité, le respect de règles de codage participe à la maintenabilité du produit).

L’analyse statique

Le syllabus « fondation » [FONDATION] définit l’analyse statique comme un examen outillé des produits d’activité. Ces examens sont réalisés à l’aide d’outillage d’analyse statique. Les compilateurs de code en sont un exemple. Sans exécuter le code, le compilateur parcourt le code et vérifie la conformité à la grammaire (lexicale et syntaxique) du langage.. Là encore, l’objectif est de contribuer à la garantie des caractéristiques de qualité logicielle (par exemples : sécurité, confiance)

D’autres outils permettent d’évaluer la qualité du code en lui affectant une note. Là encore, il est question de s’assurer du respect de bonnes pratiques de codage : complexité cyclomatique, contrôle du nombre de paramètre d’une fonction ou du nombre de ligne de code d’une procédure, vérification du nommage des variables, identification de code dupliqué, calcul du pourcentage de lignes de commentaires. Pylint [PYLINT] est par exemple un outil d’analyse statique de code source « Python ».

Mais l’analyse statique ne se limite pas au code. Des solutions logicielles proposent des outils spécialisés de validation de la documentation. Ces outils permettent de définir des règles de rédaction et d’automatiser le contrôle de la bonne implémentation de ces règles (règles syntaxiques et sémantiques de rédaction d’un cahier d’exigences comme l’interdiction d’utiliser des adverbes, l’interdiction des structures passives, la limitation de la taille d’une phrase ou des doubles négations).

Tests statiques et plan de test

Le plan de test décrit, entre autres, les moyens à mettre en œuvre pour assurer la qualité de la livraison.

Les tests statiques étant un moyen de contribuer à cette qualité, il parait évident d’y faire mention dans le plan de tests. Et pourtant, le document de référence du plan de test, l’ISO 29119, n’a pas de paragraphe spécifique pour les tests statiques et il n’est pas si intuitif de les y intégrer. Une liste importante de produits d’activité documentaire est pourtant identifiée. Qui envisagerait de ne pas valider les spécifications du produit ou le plan de test avant de les exploiter ? Si le syllabus fondation [FONDATION] y consacre un chapitre entier, ce n’est bien sûr pas pour rien.

On a les bons outils mais pas la bonne façon de les utiliser. Les tests statiques sont généralement utilisés mais non documentés. Il ne manque donc pas grand-chose dans la méthode ! Enfin, ce qui compte, c’est qu’il n’y ait pas de validation tacite des produits d’activités. C’est d’ailleurs une des leçons de l’IREB [IREB] : l’indispensable étape de validation après les étapes d’élucidation et de documentation.

Test statique vs test dynamique

Pour s’assurer qu’un produit logiciel est correctement mis en œuvre, il est d’usage d’utilisé des techniques de tests dynamiques. Nous avons vu précédemment que les techniques statiques de revue et d’analyse statique permettaient également d’assurer la qualité du code, en complément des tests dynamiques. Dans certains contextes, les revues peuvent même se substituer aux tests dynamiques et faire gagner beaucoup de temps. C’est le cas notamment des fichiers de configuration. Illustrons par un exemple.

Contexte de l’exemple

Vous avez un logiciel qui possède 10 paramètres de configuration définis dans un fichier. Tous les paramètres sont indépendants et de type booléen. Vous définissez 10 profils utilisateurs qui possèdent tous des combinaisons de paramètres différents. Vous devez tester que les 10 profils utilisateurs sont opérationnels. Comment tester efficacement ?

Objectifs de test

Dans ce contexte, on peut identifier 2 objectifs de test

(1) Tester les fonctionnalités qui dépendent des paramètres sont opérationnelles

(2) Tester les paramétrages des 10 fichiers utilisateurs

Solution

(1) Pour le premier objectif de test, créons un premier profil utilisateur de test où tous les paramètres sont « False » et un second ou tous les paramètres sont « True ». Exécutons le code avec chacun de ces deux profils utilisateurs, par deux tests dynamiques, et constatons que toutes les fonctionnalités sont opérationnelles.

(2) Pour le second objectif de test, maintenant que nous savons que les fonctionnalités logicielles ont correctement implémentées, il nous reste à faire une revue des 10 fichiers de paramétrages vis-à-vis de la spécification fonctionnelle.

Conclusion de l’exemple

Les tests dynamiques permettent ici de couvrir 100% des conditions de tests, les tests statiques de gagner du temps, et d’éviter les redondances. Les tests peuvent être fait à deux niveaux de test différents : système pour le premier et acceptation le second.

Conclusion

Les tests statiques, comme les tests dynamiques, sont utilisés pour assurer tout type de caractéristique de qualité logicielle. Ce sont des tests qui sont primordiaux pour assurer la réussite d’un projet et ils sont malheureusement très peu documentés, même s’ils sont couramment utilisés.

Concevoir un plan de test optimisé est une activité qui nécessite des compétences approfondies dans le métier du test. Ces compétences vont ainsi permettre d’orienter les efforts de test vers les bonnes techniques de test et garantiront d’une part un gain du temps et d’autre part une meilleure couverture des caractéristiques qualités, et donc la confiance dans la solution déployée.

[FONDATION] https://www.cftl.fr/wp-content/uploads/2018/11/CTFL-Syllabus-2018-FR.pdf

[29119] https://www.iso.org/fr/standard/45142.html

[TAVERNE] https://latavernedutesteur.fr/2017/11/03/les-tests-statiques-rois-du-roi/

[PYLINT] https://pypi.org/project/pylint/

[ISO25010] https://iso25000.com/index.php/en/iso-25000-standards/iso-25010

[IREB] https://www.ireb.org/en/downloads/tag:foundation-level