Recette, tests et intégration continue

Département Informatique, IUT Lyon 1

Creative Commons License

Ce travail est sous licence Creative Commons Attribution-ShareAlike 3.0 France.

Introduction

Objectifs du cours

  • Faire le bilan de ce que vous avez appris par la pratique
  • Préciser le vocabulaire lié aux tests et à l’intégration continue
  • Être un peu curieux

Mise en garde

  • Ce cours introduit simplement du vocabulaire et ne prétend pas être exhaustif.
  • Les méthodologies de tests dépendent de nombreux paramètres, il n’existe pas de méthodologie unique.
  • Ce cours n’est qu’une introduction, il ne vous rendra pas testeur professionnel... à vous d’approfondir les concepts qui vous semblent importants.

Quelques ressources importantes et connaissances à avoir

Mais aussi :

La recette ?

3 développeurs, 150g de code...

La recette (en informatique) est une phase de production d’un logiciel ou d’une application.

La recette n’est ni un document, ni un produit, c’est une étape, une opération, un processus, et ce processus a pour objectif de tester le produit i.e. de vérifier qu’il est conforme aux spécifications et qu’il fonctionne correctement.

Le terme recette est souvent employé à mauvais escient, ou bien sa définition est mal comprise.

Le site “Test et recettes en informatique” (http://www.test-recette.fr/recette/definitions.html) propose d’excellents éléments de compréhension du concept de recette logicielle.

En résumé, la recette logicielle implique des tests, et nous allons donc nous intéresser aux différents types de tests.

Pourquoi mettre en place des tests ?

  • La démarche de test vise à garantir la qualité du produit livré.
  • Les tests servent également à fournir des indicateurs permettant de maîtriser les risques (par exemple, si des bugs surviennent après la livraison).

Mais tester, c’est nul...

La phase de test est une phase qui n’a pas nécessairement bonne presse.

  • Perte de temps.
  • Beaucoup d’acteurs mobilisés (facteur multipliant la perte de temps).
  • Sentiment d’en faire trop (pour rien).
  • Mauvais timing (on est souvent pressé de livrer le produit).

Tester coûte cher !

Certes, mais...

  • On observe que les coûts de réparation des anomalies croissent à mesure que le développement avance...
  • Une bonne démarche de tests permet de diminuer les coûts de maintenance.
  • Un produit de qualité améliore la satisfaction du client et donc sa probable fidélisation.
  • En interne, avoir la garantie de fournir un produit de qualité contribue à la satisfaction du travail bien fait, et à la motivation des équipes.

Quand tester ?

  • Les tests interviennent durant le développement, la maintenance et l’exploitation du produit.
  • Les tests doivent être appliqués de façon progressive, et non “juste au dernier moment”.

Pourquoi est-il difficile de tester ?

  • La fabrication d’un bon plan de tests est une expertise à part entière.
  • De nombreux acteurs sont impliqués dans la création d’un bon plan de test.
  • Il est impossible de prouver qu’un logiciel ne comporte aucune erreur, il faut donc faire des choix sur les choses à tester, ce qui demande beaucoup d’expérience et de connaissance.

Que faire quand le test se passe mal ?

Trouver des bugs, surtout au début d’un développement logiciel, c’est tout à fait normal.

Ce qui est important c’est :
  • De les corriger vite.
  • De ne pas faire augmenter le nombre d’anomalies en les corrigeant.

Les tests, généralités

Qu’est-ce qu’un test ?

Un test est une procédure qui vise à vérifier un fragment d’un système.

Un test permet donc une vérification partielle.

Un plan de tests (voir plus loin) permet de vérifier de manière organisée un ensemble d’éléments, potentiellement très complexe (une grosse application).

Quels sont les objectifs des tests ?

Identifier les parties problématiques d’un logiciel pour :

  • soit corriger les problèmes.
  • soit mesurer les risques si l’on prend la décision de ne pas corriger les problèmes.

Les deux principaux types de tests

  • Test de vérification : le logiciel se comporte bien du point de vue des développeurs.
  • Tests de validation : le logiciel répond aux attentes du client.

Avertissement

Classification des tests : il existe maintes et maintes classifications de tests, selon les référentiels que l’on considère !

Caractérisation d’un test

Un test doit être vu comme un protocole expérimental dans lequel on précise :
  • Les données en entrée
  • L’objet à tester
  • Les résultats attendus

Un test doit être reproductible.

Le test est un processus ingrat : son objectif est de détecter les bugs !

Avertissement

Attention, le test peut prouver que ça ne marche pas, mais ne prouve pas nécessairement que ça marche !

Mais au fait, c’est quoi un bug ?

Un bug (ou une anomalie) est un comportement inattendu d’un système, que l’on ne souhaite pas voir se reproduire.

  • Certains bugs se voient tout de suite : le produit ne fonctionne pas.
  • Certains bugs se voient à l’usage : le produit ne remplit pas certaines fonctionnalités attendues.
  • Certains bugs s’observent aux limites : le produit ne monte pas en charge (fuites mémoire par exemple).

La recette

Préparation de la recette : éviter les mauvaises surprises

Une recette doit être préparée, et plusieurs aspects doivent être pris en compte :

  • Préparer une recette prend du temps, avant même de commencer à l’appliquer.
  • Plusieurs acteurs sont concernés : il faut les mobiliser, et s’assurer qu’ils trouveront le temps.
  • Des ressources devront être utilisées : il faut s’assurer qu’elles seront disponibles.
  • Les attentes ne sont pas les mêmes pour tous.
  • Il ne faut pas céder à la tentation de négliger la recette !

Préparation de la recette : les phases

Préparer les tests :
  • Bâtir la stratégie de la recette.
  • Préparer le planning et les conditions matérielles pour exécuter la recette.
Réaliser les tests :
  • Passer les tests.
  • Remonter les bugs.
  • Rédiger le document de reporting.
  • Effectuer un bilan.
Phase de bouclage :
  • Suite au reporting, améliorer la série de tests.

Comment bien préparer et effectuer une recette ?

  • Définir les objectifs.
  • Prendre en compte l’ensemble des spécificités du projet.
  • Identifier les moyens disponibles.
  • Etablir un planning de mise en oeuvre (et un planning de mobilisation des ressources).
  • Organiser la traçabilité.
  • Suivre l’avancement.
  • Etre préparé à gérer les écarts.
  • Prévoir la forme des documents de reporting.
  • Déterminer comment effectuer le bilan et évaluer les tests.

Vocabulaire lié à la recette

  • Campagne de tests : organisation des tests, description des scénarios et de leur enchaînement.
  • Scénario de test : concept qui précise la fonction à tester. Un scénario est lié à un jeu de donnés et se compose d’un ou plusieurs cas.
  • Cas de test : composant d’un scénario, ou variante d’un scénario.
  • Jeux de tests : jeux de données et résultats attendus pour les tests.
  • Plan ou protocole de test : description de ce qui va se passer dans le test.
  • Qualification fonctionnelle : ensemble des actions qui permettent de s’assurer que les développements effectués répondent bien aux besoins exprimés et fonctionnent correctement dans l’environnement cible.

La recette, étapes par étapes

Les étapes usuelles de la recette

  • La recette usine.
  • La recette utilisateur.

Il existe différents types de tests pour examiner différents défauts.

La recette usine

  • Tests unitaires.
  • Tests de validation.
  • Tests d’intégration : vérifier le bon fonctionnement de l’assemblage logiciel-logiciel ou logiciel-matériel.
  • Tests de non-régression : vérifier que la correction d’une anomalie n’a pas provoqué l’arrêt du fonctionnement d’une autre fonctionnalité.

La recette utilisateur

  • Tests techniques :
    • Tests d’architecture (respect des contraintes techniques).
    • Tests de performances (temps de réponse).
    • Tests de robustesse (stabilité, fiabilité dans le temps).
    • Tests de charge (nombre d’utilisateurs).
    • Tests de passage à l’échelle (scalabilité).
  • Tests fonctionnels (ou tests de validation) :
    • Vérification que le produit répond aux spécifications.
    • Vérification de service régulier.
    • Vérification en conditions réelles (post-déploiement).
  • Pour aller plus loin, une liste de tests techniques : https://fr.wikipedia.org/wiki/Test_de_performance

Les documents liés au processus de test

Le protocole de recettes

  • Description de la procédure.
  • Responsabilités des acteurs (client, fournisseur).
  • Liste des documents à communiquer à chaque étape.
  • Planning.
  • Conditions d’acceptation (très important !).

Attention : la correction d’un problème identifié par un test n’incombe pas au testeur !

Le cahier de recettes

C’est la liste des tests effectués chez le fournisseur avant la livraison.

Le cahier de recettes permet au client de savoir quels tests ont été effectués et donc de ne pas les refaire.

Attention : le cahier de recettes est souvent difficile à obtenir (négligé).

Les fiches de faits techniques

L’objectif des fiches de faits techniques est de recenser les écarts constatés en recette. Ces écarts peuvent être de deux types :
  • Les anomalies, ou bugs : à corriger (ou pas).
  • Les évolutions : amélioration (ou modification) du comportement attendu.

Les procès-verbaux

Le procès-verbal vient clore une étape de la recette :
  • Validation de ce qui est “validé” par les différents tests (au regard des critères d’acceptation).
  • Réserves sur ce qui n’est pas validé.

Effet de bord de la mise en place d’une bonne procédure de test

La mise en place d’une bonne démarche de tests a des effets bénéfiques sur l’ensemble du processus.

Pour faire des tests de validation, il faut que les spécifications soient claires quant aux comportements attendus.

Ceci encourage donc à faire de meilleures spécifications.

De meilleures spécifications améliorent la maintenabilité du produit...

C’est un cercle vertueux.

Établir un plan de tests

Rappel

Il est impossible de garantir qu’un protocole de test est exhaustif, quelque soit le soin que l’on apporte aux tests.

Cela étant dit, il ne faut pas que cela nous empêche de faire de notre mieux dans le temps imparti et avec les ressources disponibles.

Tester, c’est choisir !

Le plan de tests

  • Bâtir un plan de test et constituer les jeux d’essais.
  • Définir une méthodologie pour vérifier la conformité au cahier des charges.
  • Identifier les rôles des acteurs : utilisateurs et informaticiens.
  • Organiser des campagnes de tests.
  • Mettre en place le suivi et la correction des anomalies.
  • Suivre la progression et dresser des bilans.
  • Evaluer les résultats.
  • Décider de l’arrêt des tests.
  • Evaluer les risques et décider du niveau de qualité requis en fonction des besoins.

Les bonnes questions à se poser

  • Qui fait quoi ?
  • Quelles données avons-nous à disposition ? Quelles données auront nous ?
  • Quels documents devrons-nous produire ?
  • Avons-nous bien défini les seuils d’acceptation du produit, et sont-ils validés par le client ?

Pour réussir de bons tests

  • Faire les tests à froid, et si possible, ne pas les confier aux personnes qui ont effectué les développements.
  • Utiliser des vraies données et non des données préparées, dont la qualité serait parfaite.

Les jeux de tests

Qu’est-ce qu’un jeu de tests ?

Un jeu de tests est un ensemble de tests regroupés.

L’intérêt de construire (et conserver) un jeu de tests est de pouvoir le réutiliser aussi souvent qu’on le souhaite, pour tester un maximum de code rapidement et automatiquement.

Deux stratégies de tests : boîte noire et boîte blanche

Le test en boîte noire est une technique qui s’appuie uniquement sur les spécifications :
  • On se base sur les spécifications et la base de tests.
  • On ne fait aucune hypothèse sur la structure interne du composant à tester.
Le test en boîte blanche est une technique structurelle :
  • Analyse de la structure interne du composant.
  • Nécessite une bonne connaissance du code.

La couverture des tests

  • Couverture en points de programme : chaque partie du programme doit avoir été testée au moins une fois.
  • Couverture en chemin de programme : chaque chemin doit avoir été testé au moins une fois (presque impossible).
  • Couverture fonctionnelle : chaque fonctionnalité métier de l’application doit être couverte par un cas de test
  • Le cas extrême : validation par des méthodes formelles.

Quand arrêter les tests ?

Critères d’arrêt : * Taux de couverture des fonctions ou des procédures métier. * Taux de couverture des règles de gestion. * Taux de réussite des tests. * Nombres de défauts et qualification : majeurs, mineurs, bloquants.

Les différents types d’environnements

L’environnement de développement

Comme son nom l’indique, c’est l’environnement dans lequel les développeurs travaillent.

L’environnement de recette

C’est dans cet environnement que l’on applique les recettes usine.

On travaille sur des données réduites... en général, toujours les mêmes, et bien souvent non représentatives de la réalité (données propres).

L’environnement d’intégration

C’est dans cet environnement que l’on met en relation le code développé avec d’autres logiciels.

En général, on travaille avec des snapshots de données proches de celles que l’on trouvera dans l’environnement réel.

L’environnement de production

C’est l’environnement final, tel qu’utilisé par les utilisateurs finaux.

TDD : Test Driven Development

Programmation dirigée par les tests

C’est une approche à la base de la méthode XP (eXtreme Programming).

Philosophie surprenante : écrire les tests en premier.

Voir en vidéo : https://www.youtube.com/watch?v=uGaNkTahrIw

Démarche TDD

  1. Ecrire un test.
  2. Le test échoue, ce qui est normal.
  3. Ecrire la fonctionnalité la plus simple possible pour passer le test.
  4. Faire passer le test à la fonctionnalité.
  5. Boucler jusqu’à ce que le test passe.
  6. Faire le refactoring nécessaire dans le code.
  7. S’assurer que le test passe toujours.

Outils pour le test

Quelques exemples d’outils pour le test

  • Outils de type xUnit pour les tests unitaires
  • JMeter
  • Calabash pour les applications mobiles
  • Selenium pour les applications PHP

Outils de suivi de projet et de gestion de bugs

  • Bugtracker
  • Redmine
  • Trac

Organismes de référence

Quelques normes et quelques organismes

  • Norme britannique BS 7925-2
  • IEEE 829-1998 (IEEE Standard for Software Test Documentation)
  • Méthodologie “Software Testing Techniques” de Boris Bezier
  • Le comité français du test logiciel (CFTL) :organisme français qui représente le métier du test logiciel et travaille sur les normes de ce métier
  • ISTQB (International Software Testing Qualifications Board) anglais, qui édite des normes et propose des certifications.

Vocabulaire

Éléments de vocabulaire

  • Maîtrise d’oeuvre (MOE) : ceux qui exécutent le travail
  • Maîtrise d’ouvrage (MOA) : les donneurs d’ordres (clients ou leur représentants)
  • VA : vérification d’aptitude
  • VABF : vérification d’aptitude au bon fonctionnement : répond aux demandes exprimées dans le cahier des charges
  • VSR : la VSR est prononcée une fois que le logiciel a passé suffisamment de temps en production
  • PV : procès-verbal

Références

Bibliographie et Webographie