LES TESTS

Un test permet grâce à un procédé de vérification de s'assurer d'une certaine qualité pour un produit, service. Cette activité doit permettre de déceler les problèmes, défaut encore présent.

Tel que montré dans l'article sur le cycle de développement logiciel et les méthodes de développement, les tests devraient représenter une bonne partie d'un projet informatique. Nous savions tous quand réalité que c'est beaucoup moins, sinon il y aurait beaucoup de problèmes avec les logiciels. Il est préférable de détecter une erreur lors des tests que de la détecter chez le client. Les coûts de réparations ne sont pas les mêmes.

Les tests ne sont pas faits pour montrer qu'il n'y a pas d'erreur, mais bien pour montrer qu'il en existe.

Étant donné la complexité des applications d'aujourd'hui, il est peu réaliste de vouloir tester toutes les possibilités qu'un logiciel peut offrir. Une telle situation serait quand même l'idéale.

Le test unitaire

Ce test est fait directement par le programmeur. C'est le test le plus efficace pour déceler des erreurs. C'est le test qui permet d'en trouver le plus et c'est à cette étape du codage que le coût d'une erreur est le plus bas à résoudre. Il consiste à vérifier si la classe, fichier, unité comporte des erreurs. On les teste séparément. Lorsque les tests voulus ont été effectués, ils peuvent être testés ensemble.

Nous pourrions avoir 3 fichiers : validation.c, encryption.c. Les tests seraient faits séparément sur les deux premiers fichiers en premier lieu. Lorsqu'on crée une méthode ou une fonction, on peut avoir des paramètres et une valeur de retour. On doit tester ces éléments avec différentes valeurs et regarder si le résultat est celui désiré. Le compilateur et débugeur est d'une aide précieuse à ce niveau des tests. Des logiciels permettent d'automatiser ces tests tels que JUnit. Cette solution permet d'économiser temps et argent.

Le test d'intégration

Ce test valide tous les tests unitaires qui ont été faits indépendamment. Le fichier formulaire.c utilise les deux autres fichiers cités précédemment. On tente alors de déceler les problèmes qui peuvent survenir lorsqu'on combine les fichiers ensemble : les appels de fonctions, problème de droit dans les classes. Il est possible de créer des composants à partir de plusieurs fichiers.

Ce composant peut très bien fonctionner seul. Une fois mis en place avec d'autres, son fonctionnement peut être altéré. Ce test a pour mission de déceler ce genre de problème.

Le test de régression

Lorsque des modifications sont fait au programme, ajout de fonctionnalité, modification de fonctionnalité... des tests de régression devrait être fait. Les tests déjà faits sur le système doivent être refaits afin de savoir si le système fonctionne toujours comme il devrait.

Refaire à chaque fois de nouveau test est coûteux en temps, argent et ressource. Il est possible de cibler les tests devant être nécessaires afin d'évaluer certaines parties du système. Par exemple, un problème pourrait avoir été corrigé, mais sa correction pourrait entraîner d'autres problèmes.

Test d'acceptation

Ce test vérifie le système tel que le désire le client, dans les conditions de fonctionnement établi par lui. Ce test est donc basé sur les exigences et spécification de l'utilisateur. Le système est vérifié dans son ensemble. Ce test n'est pas fait par les développeurs. Des personnes n'ayant eu aucun contact avec le système peuvent être employées pour le tester. Ils peuvent ainsi déceler des anomalies qui auraient passé inaperçues par l'équipe du projet. Le client approuve ou non le système après avoir effectué ce test.

Des critères doivent être définis afin de savoir ce qui permet de spécifier si le système peut être livré ou non. L'implication du client doit absolument se faire à ce niveau du test. Chaque élément testé doit inclure l'exigence testée, les résultats attendus, le résultat obtenu. Ces données sont mises dans un document. Ce document permet de savoir ce qui fonctionne et ce qui ne fonctionne pas.