Tests, typologie & concepts

Plan de séance

Ils contribuent à la qualité logicielle : QA Quality Assurance

• En vérifiant la satisfaction des exigences fonctionnelles ou techniques.
• En évitant la régression.

Certains doivent être manuels, d'autres peuvent être automatisés.

Selon l'ISTQB (International Software Testing Qualifications Board), il existe 4 niveaux de tests, classé selon leur portée (à ne pas confondre avec types de test).

Ils sont qualifiés également de tests de composant et permettent de tester le comportement d'une unité de code :

• Méthode (procédure/fonction)
• Service, composant, module

Ils sont entièrement automatisés.

Ils permettent de vérifier l'assemblage de différents composants, et leur bonne interaction.

Leurs but est de vérifier que le système (le logiciel ou l’application dans son ensemble) répond aux exigences définies dans les spécifications.

Ils sont avant tout fonctionnels (tests de fonctionnalités) et doivent en partie être automatisés, pour contrôler et éviter la régression.

Ce sont les tests métier réalisés par le product Owner et les utilisateurs finaux.

Ils permettent de savoir si le produit livré répond aux exigences métier.

Ce sont des tests manuels.

La régression se produit lorsqu'une évolution du projet :

• ajout de fonctionnalité,
• correction de bug,
• amélioration,

produit des effets négatifs sur une autre partie du code :

• Bug, dysfonctionnement,
• Fonctionnalité non satisfaite,

compte tenu des inter-dépendances.

L'absence de régression constitue la Non-régression.

Les inter-dépendances limitent les possibilités de test :

L'isolation est difficile, voir impossible dans le cadre de tests unitaires et de composants. Les dépendances introduisent une complexité difficile à reproduire dans le cadre des tests. Les dépendances peuvent provoquer des faux-positifs ou des faux-négatifs dans les tests. Le mocking permet de résoudre ces problèmes, en utilisant des objets factices dans le cadre des tests, reproduisant les caractéristiques minimales des objets réels.

Elle définit le degré de couverture du code par les tests (exprimé en %).

Principe et outils permettant d'effectuer en continu (à chaque merge) les opérations de :

• test
• vérification de code
• packaging
• déploiement