Les différents types de test

Ci-dessous la liste des types de tests pouvant être mis en œuvre par une équipe de recette. J’aborderai cet article par le biais des fameuses « boites blanches et noires ».

1.1- Boite blanche

Test de type « boîte blanche » ou test structurel : visibilité du composant sous test, les jeux de test sont produits en analysant le code source. Les tests de type « boites blanches » sont qualifiés ainsi car on doit lire / entrer dans le code pour concevoir et exécuter les tests (ou autrement désigné comme « mettre les mains dans le cambouis »).

Quelques exemples de tests « boite blanche » : tous les chemins ont été parcourus au moins une fois, les conditions vrai / faux ont été validées, les boucles sont exécutées correctement. Mais aussi les valeurs limites sont correctement définies, les structures de données internes sont valides et s’il n’y a pas de fuite de mémoire, etc.

1.1.1- Revue de code

La revue de code est un examen systématique du code source d’un logiciel, l’objectif est de trouver des anomalies pour faire corriger les erreurs de conception afin d’améliorer la qualité et la sécurité du logiciel.

Il s’agit donc de relire le code, ce qui implique de passer en revue des milliers de lignes en Java ou en C par exemple. Pour ce faire il existe de nombreux outils permettant de le faire de manière quasi automatisée.

Ainsi, on insère dans l’outil les normes de codages et leurs gestions. Puis, l’outil parse, (langage métiers décrivant l’activité de passer en revue des lignes de code par exemple), les applications pour afficher un rapport mettant en évidence les anomalies.

La revue de code devient de plus en plus une étape à part entière dans tout processus de développement logiciel et y compris dans les méthodes dites agiles comme l’Extreme programming.

Des exemples type d’activités lors d’une revue de code peuvent être la vérification des règles de programmation ou bien la vérification de la conformité du code par rapport au document de conception technique détaillée.

1.1.2- Tests Unitaires

Ils testent indépendamment les différents éléments qui composent le système ou une portion d’un programme.

Ils sont mis en œuvre pour démontrer que chaque module (classe, boucle, etc.) effectue toute la fonction prévue et seulement cette fonction. On peut distinguer dans ces tests unitaires les tests de logique (recherche d’erreur, vérification de l’enchaînement correct des branches parcourues). Ainsi que les tests de calcul (vérification des résultats des calculs, des performances, de l’exactitude des algorithmes).

L’outil le plus répandu pour exécuter les tests unitaires est Junit (en contexte Java).

1.1.3- Tests d’intégration – avec “vision développeur”

Ils testent les différents éléments qui composent le système et leurs interactions entre eux.
Ils sont mis en œuvre pour démontrer que chaque module (classe, boucle, etc.) effectue toute la fonction prévue et seulement cette fonction.

Figure : Tests d’intégration

1.1.4- Tests de charges

Pour commencer il faut savoir qu’il y a toujours plusieurs significations dans « tests de charges » pour les clients ou les consultants. Selon les personnes la définition change. C’est pourquoi ils sont listés afin d’apporter des éclaircissements.

Lors des tests de performance (temps de réponse, durée de traitement) il faut vérifier que les performances du logiciel sont conformes aux exigences dans différentes conditions (mode normal ou dégradé) :
Exemple : s’il est prévu qu’un site Web soit consulté simultanément par 500 utilisateurs, les pages doivent s’afficher en moins de 2 secondes.

Lors des tests de charge il s’agit de mesurer le comportement du système et de ses limites face à un environnement d’exploitation limite en simulant plusieurs sessions simultanées et / ou une volumétrie de données pour contrôler le maintien des performances.

Les tests de surcharge on pour but d’appréhender le fonctionnement et les défaillances du système en cas de surcharge (au-delà des limites de charge).

Les tests avec un système en mode dégradé vérifie la stabilité du système : réaction en dehors des cas normaux d’utilisation (doublons, fichier vide, sélection vide, format de saisie erronée…).

Mes retours d’expériences montrent que 100% du temps les tests de charge sont assimilés à des tests de performances. Ceux-ci sont décrits ci-dessous.

D’une façon générale les tests de performances et de charges permettent de répondre à un certain nombre de questions comme « quels sont les risques de problèmes de performances en production ? », « est-ce que les applications et l’infrastructure supportent le nombre d’utilisateurs attendus ? », « comment mesurer la charge/qualité de service rendu en rapport avec les moyens et les objectifs ? », ou bien « les temps de réponse de l’application pour les n utilisateurs simultanés sont-ils conformes au cahier des charges ? ».

Les tests de charges peuvent s’effectuer à plusieurs moments du cycle de vie des projets comme :
au début du projet pour analyser le comportement d’une solution envisagée : progiciel à intégrer, prototype, afin d’identifier les limites de la solution, les problèmes potentiels de charge et de dimensionner les architectures matérielles en fonction de la charge évaluée dans le temps (capacity planning), en cours de projet pour tester le comportement dynamique de la solution en fabrication sur les problèmes d’inter-blocage, de consommation de ressources et de gestion mémoire, en fin de projet pour valider la solution définitive, pour vérifier ses caractéristiques de performance et identifier la capacité réelle et les comportements face à la montée en charge et aux pics d’utilisation. Ces tests permettent aussi d’optimiser l’architecture finale en ajustant les paramètres systèmes, en enfin en phase de maintenance, pour vérifier la non-régression des caractéristiques de performance de la solution et identifier sa capacité et ses comportements face à l’évolution des montées en charge et des pics d’utilisation.

Un processus typique de tests de charge comporte quatre à cinq phases avec des pré-requis à vérifier.

Les pré-requis à vérifier concerne la campagne de test de charge, qui n’est réalisable que sur la base d’une application stable et validée lors d’une phase de recette fonctionnelle et technique préliminaire.

Avant d’effectuer les tests de performance de l’application, les opérations suivantes doivent être effectuées et validées : la machine doit être disponible avec fourniture d’un accès (utilisateur / mot de passe), générique ou pas, sur l’environnement applicatif et logiciels (NT, Oracle, autorisations réseaux, etc.), l’application installée et disponible (techniquement, fonctionnellement et sur le plan de l’intégration et recette) avec fourniture d’un accès (utilisateur / mot de passe) et de jeu de données. Mais il faut également avoir une application en état de marche et stable, dans une configuration iso-production de préférence et/ou proche de la réalité et les liens avec les autres applications en état de marche et disponibles.

La nature et le volume de données présentes en base doivent être identiques et/ou proche de la production. De plus l’application doit être accessible depuis la plate-forme de test de charge.

Les quatre phases classiques lors des tests sont :

1- Pré-étude et lancement :

La première étape avant toute utilisation d’un outil (LoadRunner de HP Mercury par exemple) consiste à réaliser une phase de préparation. Cette phase est découpée en plusieurs étapes qui sont une réunion d’Initialisation / Cadrage et la livraison du cahier de test de la campagne.

2- Préparation des tests et développement des Scénarios :

Cette étape porte sur les éléments à installer afin de constituer l’environnement de test.

La phase de développement concerne la construction des scripts de tests et des scénarios spécifiés lors de la phase précédente. Cette phase se décompose de la façon suivante :

• enregistrement des scripts,
• paramétrage des scripts,
• validation des scripts par les MOE / MOA (parfois),
• rodage des scripts,
• étalonnage des scripts.

3- Campagne de tests : Exécution – Analyse, Rapport – Synthèse, Correction, Test de confirmation :

Cette phase est un processus itératif qui permet d’exécuter des scénarios et d’analyser les résultats. Elle se décompose comme suit : Création du scénario de test, Tir et collecte de métriques et analyse des résultats.

4- Bilan :

Au final, les résultats décrivent les tests, l’analyse, les améliorations de l’application et le statut des objectifs. Ce rapport est généré après l’exécution de l’ensemble des tests.

Le cycle de test peut être itéré plusieurs fois pour prendre en compte les évolutions du système.

1.1.5- Tests de sécurité

Avec l’arrivée des applications de type Web se sont développé des tests de sécurité. Il s‘agit de vérifier la sécurité des systèmes : cryptage des données, tests d’authentification, habilitations, intégrité des données, accessibilité, accès concurrents…

1.1.6- Tests d’exploitabilité

Les tests d’exploitabilité ou Vérification A la Bonne Exploitabilité (VABE) sont des tests qui contrôlent les exigences d’architecture technique. Ci-après un exemple avec l’illustration dans le monde des telecom français :

On comprend dans le schéma ci-dessous que les scénarios de test d’exploitabilité débutent au téléphone mobile d’un client pour finir à l’entrée du S.I. du fournisseur d’accès. En passant par toutes les couches réseaux, supervisions, etc.

Il y a également parfois des tests de performance qui sont exécutés.

1- Types de test
Figure : Périmètre des tests d’exploitabilité chez un opérateur telecom français

Figure (illustration à venir) : Activités de test de type exploitabilité chez un opérateur telecom français.

Quelques autres exemples de test faisant partie de ceux d’exploitabilité :

• analyse du dossier d’exploitation,
• mise en place de la configuration plate forme, configuration ordonnancement JCL,
• vérifier le respect des normes d’exploitation,
• la mise en place de l’ordonnancement des Job et flux de données,
• la supervision (Unix Tivoli, MVS Autosys),
• scénario de chronologie,
• jeu de donnée batch, cas d’alerte,
• simulation des dossiers d’exploitation, message d’alerte, log,
• vérification des logs,
• tests de sauvegarde, restauration, chaud, froid, incrémentale, hebdo, etc.

Ce type de test aborde de très nombreuses particularités et sera le sujet d’un prochain article.

1.2- Boite noires

Les tests de type « boîte noire » ou test fonctionnel ne demande pas de visibilité du composant. Les entrées et les résultats attendus sont exprimés en termes de comportement du composant logiciel d’un point de vue externe, sans se soucier de la structure interne du composant.

Les tests boîte noire sont liés aux spécifications fonctionnelles. Indépendamment de la structure interne de l’application (contrairement aux tests boîte blanche), ils valident les fonctionnalités de l’application. Comme le fonctionnement interne de l’application n’est pas connu, le concepteur de jeux de test doit définir le comportement attendu (Résultat Attendu – RA) et vérifier si l’application est conforme à ce comportement (Résultat Obtenu – RO).

Les tests de type boîte noire sont des tests fonctionnels mis en œuvre dans la phase de recette, ils ont pour objectifs de rechercher ou de valider le respect des exigences, les fonctions incorrectes ou manquantes. Mais aussi les incohérences au niveau de l’interface, les erreurs d’accès aux données et enfin les conditions initiales ou finales d’une fonction.

1.2.1- Tests fonctionnels

La recette fonctionnelle (plus simplement appelée recette) consiste à réceptionner un logiciel développé et à en vérifier le bon fonctionnement avant sa mise en service ainsi que sa conformité par rapport à ce qui a été demandé dans le cahier des charges.

Les tests de recette fonctionnelle vérifient que le logiciel fonctionne de manière adéquate dans le cadre des activités-métier des utilisateurs pendant la recette fonctionnelle, on n’examine pas la programmation du logiciel, mais son comportement fonctionnel et son ergonomie (IHM et navigation) ainsi que le ou les cahiers des charges (et le cas échéant d’autres supports tels que manuels utilisateur, modélisation des données…).

Les tests conduisent à simuler le fonctionnement du logiciel au travers de cas d’utilisation. Il est nécessaire de disposer de cas concrets du domaine d’application et de données pour simuler un contexte réel d’utilisation (jeux de données, environnement de test).
Les tests vérifient les aspects du métier (fonction métier) avec les fonctionnalités non conformes ou manquantes et le fonctionnement des règles de gestion.

Les tests fonctionnels prennent aussi en compte l’ergonomie. Il s’agit des comportements utilisateurs (valeurs limites, valeurs non autorisées…), de la réalisation et la présentation des écrans ou des règles de navigation, etc.

1.2.2- Tests de non régression

Après une correction ou une évolution, que faut-il re-tester pour s’assurer que la modification n’a pas dégradé (fait régresser) le fonctionnement du logiciel et provoqué des anomalies sur d’autres modules non testé ?
Tout re-tester serait trop coûteux et ne tester que les modifications du composant impliquerai de nombreux risques.

Il faut donc trouver un compromis et définir une stratégie de non régression (ou TNR). Ces tests de non régressions doivent être prévus après toute modification d’un logiciel afin de vérifier que les fonctionnalités existantes n’ont pas été altérées par les modifications apportées. Il est en effet indispensable que l’existant continue à fonctionner avec le même niveau de qualité que sur la version précédente.

Pratiquer un test de non régression signifie que le reste de l’application n’a pas perdu en fonctionnalité ou en fiabilité du fait de l’ajout de nouvelles fonctions ou de modification des fonctions existantes. Ils consistent à déterminer si des défauts ont été introduits dans l’application lors de l’implémentation de la nouvelle fonctionnalité. Ils peuvent également être employés lors de changements survenus dans l’environnement de l’application.

Les tests de non régression sont applicables à toutes les phases de test. En effet, la prédiction des erreurs permet de déterminer la portée et l’étendue des tests et de s’assurer de l’état du système modifié.

Si les tests de non régression accompagnent les différentes étapes du cycle en V, ils conviennent particulièrement aux dernières étapes. Ainsi, ils sont habituellement effectués dans le cadre de tests système de recette ou d’intégration.

Figure : Illustration de ce que sont les Tests de Non Régression

Tout système d’information est en perpétuel évolution. Or si chaque nouvelle modification est validée elle ne l’est pas nécessairement dans l’ensemble de l’application dans laquelle elle intervient. Il en résulte des anomalies, parfois bloquantes (ou effet papillon). Les tests de non régression (souvent outillé) permettent d’augmenter la couverture des tests, d’industrialiser les tests, de diminuer les charges de tests et enfin d’optimiser les temps d’exécution.

Exemple – ARIANE 501

Le 4 juin 1996 lancement d’ARIANE 501 et quelques secondes après le lancement l’auto destruction est prononcée. Fin d’ARIANE 501 (environ 500 M€).

Pourquoi ?
Après analyse il s’avère que des mauvais choix ont été effectués lors de la définition de la stratégie des tests de non régressions. En effet, des composants d’ARIANE 4 ont été réutilisés mais non testés car « Ils fonctionnaient parfaitement avant ! ».

(Source IEEE Computer 01/97)

Exemple – MOE E_F projet xxx

1.2.3- Etude de cas pour illustration :
Enjeux stratégiques : Ouverture du marché en 2007 – assurer la montée en compétence de l’équipe – définir la méthodologie et outil dédié aux activités de recette
Réalisation : Audit des activités de recette de la MOE (fondamentaux projet, processus et moyens de recette sur VABF) > Préconisations > plan d’actions > Formations > Accompagnements chef de projet et analystes.
Gain client : Formation et accompagnement de ses équipes – professionnalisation des activités de recette – maîtrise accrue de la qualité – pilotage dédié à la recette – respect des engagements intégrateurs
Technologies : Portail – Progiciel L_r – Batch – Flux – Business Intelligence (B.O.)

Exposition du cas : Plus près de nous, en 2007, lors d’une mission de conseils chez E_F j’ai mis en place la stratégie de tests de non régression suivante.

Figure : Se situer dans les étapes de tests

Lors de la phase d’audit voici ce que j’ai préconisé : une stratégie en deux phases se situant lors de l’étape de conception des tests. Il s’agissait de former et faire monter en compétence l’équipe en charge des activités de recettes de la MOE sur les tests de non régressions. Pour ce faire il a fallu mettre en place une stratégie en 2 temps (appropriation progressive facilité) : une non régression manuelle et une non régression automatisée.

Non régression manuelle :
Il a fallu recueillir les plans de tests des autres acteurs comme le groupement (intégrateur type TMA) et de la MOA. Puis de rédiger ceux de la MOE collectant les informations :

• des tests de non régression du groupement,
• des tests de non régression de la MOA.

Il a fallu rédiger la synthèse et l’analyse des informations sur les conceptions des tests de non régressions MOE via des :

• tests des fonctionnalités et flux primordiaux,
• tests de l’IHM L_R (menu…),
• tests des courbes de charge, graphiques, rapports.

Non régression automatisée :

Figure : Automatisation des tests de non régression – « Voie royale »

Une fois les tests de non régression manuelle bien avancés, on peut automatiser ces tests. En passant par une étude de 5 jours sur la faisabilité de cette automatisation.

Ensuite, (après choix des automates et validation du client), un projet dit « pilote » utilisant les plans de tests de non régressions rédigés en amont peuvent être défini et joué.

Puis, après la lecture et l’analyse des rapports de test cette phase d’automatisation a été validée.
Etat des lieux :

• cellule MOE : aucun cahier de recette prévu pour les TNR – TNR joué « à la volée »,
• cellule MOA : un cahier de recette avec 3 scénarios mais très incomplet,
• équipe Métiers : aucun d’existant – TNR joué « à la volée ».

Après l’audit la stratégie de Tests de Non Régression (TNR) retenue a été de mettre en place un atelier. Puis, suite à l’atelier organisé avec les pilotes E_F et la cellule MOE la solution retenue a été d’utiliser les cahiers de recette de la MOA, de les enrichir et d’organiser des ateliers avec l’équipe Métiers pour finaliser les cahiers de recette de TNR.

En collaboration avec la cellule MOE nous avons dressé un tableau listant les avantages à mettre en place cette stratégie de TNR. Avantages pour les 3 équipes. Cette liste nous a aussi servi à communiquer / « vendre » les TNR aux diverses acteurs.

1.2.4- Tests d’intégration avec une logique « recetteurs »

Dans l’hypothèse de modifications apportées à au moins deux applications, il convient non seulement de tester chacune d’entre elles, mais aussi de vérifier que les communications (amont/aval) prévues fonctionnent toujours (ou, s’il s’agit d’une nouvelle relation, que celle-ci est opérationnelle).
Du point de vue de la méthode, la réalisation d’une recette d’intégration appelle des précisions sur chaque application modifiée qui doit faire au préalable l’objet d’une recette fonctionnelle : on parle alors couramment de recette fonctionnelle « unitaire » et les concepts de base exposés dans le guide sont applicables à ce cas particulier.
Puis il faut préciser la relation entre les applications, effectuée dans un second temps, introduit un niveau de complexité supplémentaire qui nécessite une organisation et une stratégie spécifiques (coordination, pilotage le cas échéant, plate-forme adaptée, …), voire la mise en place d’un outil de cadrage dédié, le « dossier de stratégie d’intégration ». Ce dernier permet de partager entre les différents acteurs de la recette les éléments clés du projet : contraintes (planning, ressources, objectifs), description de la plate-forme, cadencement des travaux, etc.
Enfin, le dossier de stratégie d’intégration doit contenir les scénarios et fiches de tests “partagés”, nécessaires à la vérification de l’intégration, ainsi que le calendrier précis de leur passage. Les jeux d’essai communs doivent être constitués pour permettre la vérification de la chaîne.

Ils consistent à assembler plusieurs unités et à tester les erreurs liées aux interactions entre ces unités (et éventuellement à détecter les erreurs rémanentes non détectés au niveau unitaire).

1.2.5- Particularité des tests de progiciel

Les tests de progiciel comme les ERP (ou PGI) sont particuliers car faisant partie des tests les plus complexes à mettre en œuvre. Ceci pour les raisons suivantes comme le besoin d’identification des exigences, des objets métier et des règles de gestion. Comme l’analyse d’impact d’une version à l’autre, les tests récurrents, le besoin de tests de non régression ou l’interfaçage avec le SI existant.
Mais complexe également car il y a de nombreux développement spécifique, des migrations / reprise des données du SI historique vers le progiciel, des problématiques de volumétrie, des plates-formes propriétaire plus ou moins ouverte.
La complexité est également due à la richesse fonctionnelle poussée (processus métier prédéfinis et adaptés au métier), un paramétrage spécifique ou bien des développements complémentaires pour chaque société, un processus de développement hors norme.

Parfois même, la complexité provient des différenciations à faire entre le standard et le spécifique. Ceci au niveau des développements et des tests. En effet, les développements standards font souvent partie d’une enveloppe déjà définie avec le client, alors que les développements et tests spécifiques sont sujets à des avenants au contrat.

Enfin, la complexité des tests de progiciel est due aux problématiques de gestion des flux inter-applicatifs, aux problématiques de gestion de configuration et des difficultés de la maîtrise des jeux de données.

Hormis les problèmes évoqués ci-dessus il y a également ceux liés à la conception des scénarios et de leurs exhaustivités. Ci-dessous un exemple de scénario suivant la logique d’un « utilisateur final ».

Figure : Exemple d’un scénario de test d’un module R/3

Les tests de progiciel sont donc complexes et ils demandent aux équipes une première expérience sur un des modules de l’ERP cible.

Prenons pour illustrer un exemple tiré d’une mission aux chez un assureur sur un module SAP Financier. La démarche mise en place pour spécifier et préparer les tests a été la suivante: il a fallu procéder à l’identification des processus principaux (métier et applicatifs) et des scénarios de tests associés, puis identifier les règles de gestion, étudier les messages impactant et identifier les transactions SAP (ou ordre de transport) par flux et processus (étude des processus et prototypes élaborés lors de la conception de l’application).
Ensuite il a fallu spécifier les scénarios de tests et les fiches de tests, rapprocher les scénarios SAP fournis en standard avec la méthodologie ASAP (méthodologie de test light propre à SAP), définir les scénarios retenus et spécifier les cas de test.
Enfin, il a fallu analyser la couverture des tests via la matrice des cas de test et analyser et spécifier les jeux de données nécessaires.

Je développerai dans un prochain article la stratégie à adopter pour mener à bien des tests sur de l’ERP.