Les tests

Objectif —> éviter les bugs

Mais comment faire ? Maîtriser les processus d’ingénierie du logiciel :

• analyser et concevoir correctement le projet en amont

• mettre en place de bonnes méthodes de travail et d’organisation

• coder dans de bonnes conditions

• tester

La règle 40-20-40 identifie qu’en moyenne, 40% de l’effort est requis pour spécifier et concevoir, 20% va à la programmation et 40% va aux tests de vérification (”le système fait-il correctement son travail ?”) et de validation (”le système réalisé correspond-il aux besoins du client ?”).

Définition

Un test est un ensemble de cas à tester (état de l'objet à tester avant exécution du test, actions ou données en entrée, valeurs ou observations attendues, et état de l'objet après exécution), éventuellement accompagné d'une procédure d'exécution (séquence d'actions à exécuter). Il est lié à un objectif.

On distingue deux scénarios : positif (ça marche) et négatif (ça ne marche pas mais ce n’est pas un bug).

Grands principes de test

1. Indépendance ~ un développeur ne teste pas ses propres programmes

2. Paranoïa ~ ne pas faire de tests avec l’hypothèse qu’il n’y a pas d’erreur

3. Prédiction ~ définir les résultats attendus avant l’exécution des tests (plan de test)

4. Vérification ~ séparer l’exécution et l’analyse : inspecter minutieusement les résultats de chaque test

5. Robustesse ~ écrire les jeux de tests pour des entrées invalides/incohérentes mais aussi pour des entrées valides

6. Complétude ~ vérifier qu’un logiciel réalise ce qu’il est supposé faire mais aussi ce qu’il fait en dehors de ce qu’il est supposé faire

Classification des tests

Selon le cycle de vie

• test unitaire ~ test à l’échelle d’un composant, indépendamment du reste

• test d’intégration ~ test à l’échelle de modules ou parties de code qui coopèrent

• test système (vérification) ~ test à l’échelle du système entier, en inspectant sa fonctionnalité

• test d’acception ou recette utilisateur (validation) ~ test à l’échelle du système entier, en inspectant sa cohérence avec les spécifications

• (test de non-régression) ~ test d’un système préalablement testés lorsqu’il y a mise à jour ou évolution pour vérifier qu’il n’y a pas de régression (on ne veut pas que ça casse tout) —> intérêt notamment de l’intégration continue puisqu’il faut refaire les tests unitaires > d’intégration > système > recette

Selon la nature de la connaissance

• test structurel ou en “boîte blanche” ~ vérifie qu’il n’y a pas des erreurs dans le code, l’implémentation,… dont test unitaire, test d’intégration, test de non-régression

• test fonctionnel ou en “boîte noire” ~ vérifie que le logiciel respecte les attentes du client (on ne regarde pas le code mais simplement le logiciel) dont test système, test d’acceptation

Selon la qualité

• test de conformité (validation) dont test d’acceptation

• test de robustesse ~ vérifie la stabilité et la fiabilité du logiciel

• test de performance ~ vérifie que les performances annoncées sont atteintes (test des temps de réponse, de la durée des traitements, de la consommation de ressources) et souvent cas de montée en charge avec des tests de charge (hausse importance du nombre d’utilisateurs par exemple)

• test de sécurité ~ vérifie les attaques, la gestion des connexions, l’authentification, la validation des données…

Autres classifications

• test statique (par l’humain) ou dynamique (par la machine, notion de fiabilité)

• test manuel (par le développeur) ou automatisé (outils de tests)

Intégration continue

L'intégration continue est un ensemble de pratiques utilisées en génie logiciel consistant à vérifier à chaque modification de code source que le résultat des modifications ne produit pas de régression dans l'application développée.

Elle nécessite une automatisation de la compilation et des tests ainsi que certains prérequis :

• utiliser un logiciel de gestion de version

• faire des commit réguliers

• utiliser un framework de test, qui permet de standardiser des résultats interprétables

• utiliser une application d’intégration continue pour compiler, exécuter les tests, automatiser le déploiement et présenter les résultats

Avantages : test immédiat des modifications, notification rapide en cas de code incompatible ou manquant, détection des problèmes d’intégration pour une réparation rapide (et pas de problèmes de dernière minute), une version est toujours disponible pour un test, une démonstration ou une distribution.

Développement piloté par les tests (TDD)

Le Test Driven Development est une technique de développement de logiciel qui préconise d’écrire les tests unitaires avant d’écrire le code source d’un logiciel.

La logiques des tests poussée à l’extrême.