• Messad Ould Rabah

Les principes des tests logiciels


Cet article a pour finalité de définir les tests logiciels et de mettre en avant les principes des tests logiciels.


Tout d’abord, Qu’est-ce qu’un Test logiciel ?


Contrairement aux idées reçues, le test logiciel ne se limite pas à « l’exécution ou l’évaluation d’un système ou d’un composant, par des moyens manuels ou automatiques, pour vérifier qu’il répond à des spécifications ou pour identifier les différences entre les résultats attendus et les résultats obtenus », mais il couvre tout un ensemble d’activités de tests nommé également « processus de test », comme :

  • La planification et le contrôle des tests,

  • L’analyse et la conception des tests,

  • L’implémentation et l’exécution des tests,

  • L’évaluation des critères de sortie et information sur le processus de test,

  • La réalisation et la finalisation des activités de clôture définitive à la fin d’une phase de test.

En outre, les tests incluent des activités de revue de documents tels que le plan projet, les spécifications, le code, le plan de test, les rapports de synthèse de tests et tant d’autres.


Ensuite, pourquoi s’intéresser aux principes des tests logiciels ?


L’enquête régie par le Comité Français des Tests Logiciels (CFTL) de 2019, sur les pratiques des tests logiciels en France, réalisée du 1er décembre 2018 au 21 janvier 2019, avec 843 réponses de professionnels du test, révèle que 81,78% des professionnels ont été confrontés à l’obsolescence des principes de tests. Les raisons dominantes de cette obsolescence sont les cas de test n’ayant pas été mis à jour par rapport à l’évolution de l’application avec 90.37% de réponses, des cas de tests incomplets avec 56.25% et des cas de tests redondants avec 48.53% de réponses. Pour les autres raisons de l’obsolescence, se référer à la figure ci-dessous :


C’est de cette fraiche analyse sur l’obsolescence des principes de tests qu’est né cet article. Il nous est judicieux de communiquer sur les principes des tests logiciels dont le rappel n’est suffisamment pas redondant !


L’International Software Testing Qualifications Board (ISTQB) dénombre ces principes généraux des tests comme suit :


Principe 1 – Les tests montrent la présence de défauts : Les tests peuvent prouver la présence de défauts, mais ne peuvent pas en prouver l’absence.


La conception et l’exécution d’une campagne de test avec méthode peuvent ne détecter aucun défaut. Ce n’est pas une preuve d’exactitude mais de possible jeux de test non pertinents.


Principe 2 – Les tests exhaustifs sont impossibles : Tester toutes les combinaisons de données d’un programme n’est pas faisable sauf pour des cas triviaux. Plutôt de faire des tests exhaustifs, il est préférable de cibler les efforts de tests par une analyse des risques et des priorités.


Principe 3 – Tester tôt : Les activités de test devraient commencer le plus tôt possible dans le cycle de développement du système pour faciliter la localisation des anomalies trouvées, et ainsi faciliter leur correction afin de minimiser les coûts et les efforts associés.


Principe 4 – Regroupement des défauts : L’effort de test devrait être fixé proportionnellement à la densité des défauts prévus et constatés dans les différents modules du logiciel. Généralement, une grande partie des défauts est concentrée dans un petit nombre de modules. C’est le principe de Pareto ou « règle des 80/20 », qui est un principe de probabilité appliqué au travail, datant de 1896, et qui se résume, dans le cas du « regroupement des défauts », par : 80% des défauts sont identifiés dans 20 % du logiciel. Autrement dit, 80% d’efforts de test devraient être portés sur les modules du logiciel qui contiennent la majorité de défauts et 20 % d’efforts sur le reste des modules.


Principe 5 – Paradoxe du pesticide : Si un même test est répété de nombreuses fois, aucun nouveau défaut ne sera détecté, d’où le principe du « paradoxe du pesticide » : à trop appliquer le même produit, il devient inefficace, ou un système tend à développer de la résistance aux techniques de tests utilisés.


Pour cela, les cas de tests doivent être régulièrement revus et révisés, et de nouveaux tests, différents, doivent être écrits pour couvrir d’autres chemins dans le logiciel ou le système de façon à permettre la découverte de nouveaux défauts.


Principe 6 – Les tests dépendent du contexte : En fonction du contexte de l’utilisation du logiciel, les objectifs et les types de tests seront différents. Par exemple, les logiciels de sécurité critique seront testés différemment d’un site de commerce électronique.


Principe 7 – L’illusion de l’absence d’erreurs : Détecter et corriger des défauts n’aident pas si le système conçu ne répond pas aux besoins et aux attentes des utilisateurs. En d’autres termes, il n’y a pas que la capacité fonctionnelle qui compte. Selon la norme relative à la qualité logicielle « ISO 9126 : Software Engineering – Software Product Quality », la qualité du logiciel informatique s’évalue par 6 grandes caractéristiques :

  • Capacité fonctionnelle : Ensemble d’attributs permettant de vérifier si le logiciel répond aux besoins fonctionnels de ses utilisateurs. Les attributs (ou sous-caractéristiques) de la caractéristique « capacité fonctionnelle » correspondent à l’aptitude, à l’exactitude, à l’interopérabilité, à la conformité et à la sécurité.

  • Fiabilité : Ensemble d’attributs permettant de vérifier si le logiciel est apte à maintenir son niveau de qualité dans des conditions précises et pendant une période déterminée. Les attributs correspondent à la tolérance aux fautes et à la capacité de récupération.

  • Facilité d’utilisation : Ensemble d’attributs permettant de caractériser l’effort nécessaire à un utilisateur à utiliser le logiciel. Les attributs se réfèrent à l’exploitabilité, à la facilité d’apprentissage et à la facilité de compréhension.

  • Maintenabilité : Ensemble d’attributs permettant d’évaluer si un logiciel est facilement évolutif face à de nouveaux besoins ou à de nouvelles contraintes. Les attributs correspondent à l’étude de la stabilité, de la facilité de modification, de la facilité d’analyse et de la facilité à être testé.

  • Rendement ou efficacité : Ensemble d’attributs permettant de qualifier le rapport entre la rentabilité du logiciel et les ressources matérielles nécessaires à l’exécution du logiciel, dans un contexte réaliste. Les attributs sont définis par l’efficacité des ressources matérielles employées et par l’efficacité des temps de réalisation.

  • Portabilité : Ensemble d’attributs permettant de caractériser l’aptitude d’un logiciel de migrer d’un environnement à un autre. Les attributs de la portabilité correspondent à la facilité d’installation, à la facilité de migration, à l’adaptabilité et à la conformité par rapport aux normes de bases de données.

Enfin, pourquoi c’est judicieux de communiquer sur le bon fonctionnement des tests logiciels ?

  • Le coût des bugs informatiques : Nous avons tous à l’esprit de multiples conséquences d’anomalies informatiques telles que, la surexposition mortelle à des radiations lors d’examens médicaux avec l’appareil de radiothérapie « Therac-25 » entre 1985 et 1987, l’explosion de la fusée Ariane 5 en 1996 et tant d’autres rencontrées durant la vie professionnelle et familiale. Ces ratés tragiques aussi bien sur le plan humain que financier sont les conséquences de l’omission des référentiels des tests logiciels.

  • La complexité croissante des systèmes : La taille des systèmes, la quantité et la diversité des applications, des serveurs, des transactions et des utilisateurs sont autant de défis que les entreprises ont fait émerger de nouvelles approches de modèles de développement de logiciel. Parmi ces modèles, nous citerons le modèle de développement itératif, associé à des outils d’automatisation puissants permettant d’accélérer les phases de test, en particulier les tests de non régression, dans le respect de la qualité du logiciel et de la maîtrise des risques à un niveau acceptable. Toutefois, le test manuel n’est pas à bannir car l’œil humain reste efficace pour repérer des anomalies dont un robot ne peut pas les visualiser.

Mais qui maitrise ces principes ?


La société WAPSI intègre ses principes de test et propose des tests et des audits de performance ainsi que des tests fonctionnels automatisés.



38 vues

Posts récents

Voir tout