Pratique des tests logiciels - 2e éd.

On le voit, les objectifs des tests peuvent être multiples ; cependant, en aucun cas, et même si cela est choquant, il faut être conscient que leur but n'est pas d'éliminer tous les défauts. L'objet principal est d'analyser le comportement d'un logiciel dans un environnement donné :
ainsi, il ne sert a priori à rien de tester le bon fonctionnement de la gestion du système de freinage d'une automobile pour une vitesse de 1000 km/h.

Le rôle des tests est multiple. En effet, aujourd'hui de très nombreuses activités ne peuvent être réalisées sans l'aide de logiciels et ceci dans des domaines très variés : gestion de la paye, gestion de la carrière des personnels, suivi des clients, contrôle des centrales nucléaires, aide au pilotage des avions civils et militaires, amélioration du fonctionnement des appareils ménagers, services offerts sur les mobiles ou les tablettes, etc. (...)

Or, on ne sait pas, par construction, fabriquer des logiciels sans défaut : l'homme commet des erreurs et aucun programme ne peut générer de façon sûre un autre programme ou vérifier qu'un programme fait exactement ce pour quoi il est fait. En effet, les limites théoriques montrent qu'il est impossible dans le cas général, de construire un algorithme permettant de dire si deux programmes réalisent les mêmes fonctions (il s'agit d'un problème insoluble).

Une suite de défaillances peut entraîner une panne du logiciel ou du système, mais il ne faut pas confondre une défaillance et une panne.

Une défaillance se caractérise par des résultats inattendus (calculs erronés, fenêtre mal placée, message non affiché, etc.) ou un service non rendu (données non stockées dans une base, fenêtre non ouverte, etc.) ; cependant, le logiciel peut continuer bon gré mal gré son fonctionnement normal.

Une panne a un caractère plus franc et se révélera par un arrêt total ou partiel du logiciel qui conduit à un fonctionnement en mode (très) dégradé.
La seule manière de sortir de ce mode est de redémarrer le logiciel ou le système avec toutes les conséquences que cela peut avoir.

Une défaillance provient d'un défaut de réalisation ou de conception du logiciel, qui suite à une exécution du code impliqué engendre un comportement fautif. Il faut noter que tout défaut ne conduit pas systématiquement à une défaillance et que, au contraire, il est fréquent qu'un logiciel se comporte correctement alors qu'il contient un grand nombre de défauts mais qui ne sont jamais exercés en fonctionnement ;
cette constatation implique donc d'adopter une stratégie de grande prudence lorsque l'on réutilise une partie d'un logiciel fonctionnant parfaitement.

Tester un logiciel est un challenge aussi excitant que de le programmer, et qui, tout comme la programmation, ne peut se faire sans une bonne assise technique ; tester c'est mener une expérimentation scientifique
et il faut pour cela enthousiasme mais aussi rigueur et méthode.

Les tests doivent donc rechercher des erreurs : des erreurs dites fonctionnelles, le logiciel ne fait pas ce qu'il devrait faire ;
mais aussi des erreurs non fonctionnelles : le logiciel fait ce qu'il faut mais pas dans des temps acceptables ou en devant être relancé fréquemment ou ne supportant pas la montée en puissance.

Le nombre de cas d'utilisation possibles d'un logiciel étant en général très grand, il est tout à la fois illusoire de penser mener cette recherche d'erreur de manière empirique, mais également de vouloir prétendre à l'exhaustivité ; la bonne approche sera de nature statistique, avec des stratégies basées sur les contextes d'emploi.

Il faudra savoir construire efficacement les cas de tests pertinents, c'est-à-dire ceux permettant de mettre en évidence rapidement les erreurs.
Il faudra également savoir déterminer à quel moment on peut arrêter les tests sans crainte de ne pas avoir assez testé

Une erreur découverte en bout de chaîne peut entraîner la refonte totale et le re-développement de tout ou de presque tout.
Il faut donc tester en amont lors des phases d'assemblages des composants du logiciel (il s'agit des tests dits d'intégration), mais également lors du développement des composants (il s'agit des tests dits unitaires) car assembler des composants truffés d'erreurs ne peut que compliquer le diagnostic et réduire à néant le rendement de l'effort des tests suivants.