Politique de test

POURQUOI DES TESTS ?

Les tests constituent une condition indispensable au développement et à l'implémentation réussies de systèmes d'informations. La complexité des logiciels modernes est telle qu'il est presque impossible de les implémenter correctement dès la première fois sans aucune vérification. Les tests sont nécessaires pour détecter le plus rapidement possible les problèmes logiciels de manière à pouvoir les corriger à moindres coûts. Les tests sont également réalisés pour développer la confiance et la connaissance du produit livré. Les défauts d'un logiciel peuvent avoir de lourdes conséquences pour les « affaires » et pour les utilisateurs. Outre le fait de pouvoir éviter le plus de fautes possibles, les tests permettent également de montrer à la direction et aux utilisateurs que le produit livré répond à leurs exigences (« fit-for-purpose »).

À noter ici que tant les fonctionnalités que les caractéristiques non fonctionnelles du logiciel sont ici importantes pour pouvoir affirmer qu'un produit est conforme aux exigences posées et utilisable dans son contexte opérationnel.

LES TESTS

Tester un logiciel est le processus utilisé pour vérifier et valider qu'un programme, une application ou un produit:

• • répond aux exigences techniques et professionnelles telles que décrites dans le cahier des charges, les exigences (requirements), les documents d'analyse et de conception.

  • fonctionne comme prévu et est utilisable dans son environnement opérationnel. • est implémenté avec les caractéristiques logicielles non-fonctionnelles présupposées. La vérification et la validation doivent ici être interprétées au sens de la norme NF525 :

  • vérification : confirmation par le biais de preuves objectives que les exigences fixées sont satisfaites.

  • validation : confirmation par le biais de la livraison de preuves objectives que les exigences posées sont remplies pour un usage ou une application spécifique. On peut interpréter cela en indiquant que la vérification implique que l'on a développé le logiciel alors que la validation implique que l'on a créé le logiciel.

PRINCIPES DE BASE

Plusieurs principes s'appliquent à tous les tests :

• • Principe 1 : Les tests permettent de déceler les défauts. Les tests montrent les défauts présents mais ne peuvent pas prouver qu'il n'y a pas de défauts. Les tests réduisent les risques de présence de défauts non décelés dans le logiciel mais le fait qu'aucun défaut n'ait été trouvé ne doit pas être considéré comme une preuve qu'il n'y a pas de défauts.

  • Principe 2 : Il est impossible de réaliser des tests exhaustifs. Tout tester (toutes les combinaisons d'entrées/sorties et de pré-conditions) n'est pas réalisable sauf dans les cas banals. Au lieu d'effectuer des tests poussés, il convient d'utiliser une analyse des risques et des priorités pour limiter les efforts de test aux tests pertinents.

  • Principe 3 : Tester rapidement. Les activités de test doivent démarrer le plus rapidement possible dans le cycle de développement du logiciel. Cela permet de détecter les défauts rapidement et de les résoudre à moindres coûts.

  • Principe 4 : Regroupement des défauts. Quelques-uns des modules contiennent la plupart des défauts qui sont décelés pendant les tests avant sortie et/ou sont responsables de la plupart des erreurs opérationnelles.

  • Principe 5 : Paradoxe des pesticides. Si le même ensemble de cas de tests est réalisé à plusieurs reprises, ces tests ne présenteront plus au final de nouveaux défauts. Les ensembles de tests doivent donc être régulièrement réévalués. Des nouveaux tests doivent être écrits pour vérifier d'autres parties du logiciel pour trouver d'éventuels nouveaux défauts.

  • Principe 6 : Les tests dépendent du contexte. La manière d'effectuer les tests dépend du contexte dans lequel le produit sera utilisé. Par exemple, un logiciel de protection est testé différemment qu'un site Internet d'e-commerce.

  • Principe 7 : Absence d'erreurs. Trouver et résoudre des défauts n'est pas intéressant si le système n'est pas utilisable et/ou ne correspond pas aux besoins et attentes des utilisateurs finaux.

Le processus de test

LE MODELE V

Le modèle V de CRISALID illustre les niveaux de test utilisés et les responsabilités générales

NIVEAUX DE TEST

Les niveaux de test sont des groupes d'activités de test qui sont gérés ensemble et qui sont en rapport direct avec les responsabilités telles que définies dans un projet. CRISALID utilise les niveaux de test tels que décrits dans le reste de cette section

Notez qu'un niveau de test n'est pas la même chose qu'une phase de test. Dans un modèle de développement incrémentiel ou itératif, on pourra par exemple développer à différentes phases d'un projet chaque fois de nouvelles tâches qui appartiennent à un certain niveau de test. Le modèle V est utilisé dans cette politique pour indiquer qui effectue quelles activités et non pour imposer un cycle de développement logiciel spécifique.

Niveau test unitaire

Les tests unitaires (également appelés tests des composants) recherchent la présence de défauts, vérifient le fonctionnement des modules, programmes, objets, classes de logiciel testables séparément.

Les tests unitaires peuvent vérifier tant les fonctionnalités que les caractéristiques non fonctionnelles spécifiques. Les exemples de test sont basés sur des produits de travail comme les spécifications d'un composant, la conception du logiciel ou le modèle de données.Les tests unitaires sont utilisés pour s'assurer que les composants individuels fonctionnent correctement.

Les tests unitaires utilisent surtout la technique de test de la boîte blanche et sont donc réalisés en connaissance du code qui est testé et éventuellement avec le soutien de l'environnement de développement (cadre test unitaire, outil de débogage, etc.). Ces tests sont dès lors souvent exécutés par le développeur qui a écrit le code ou qui possède un profil similaire. Les défauts trouvés sont résolus dès qu'ils sont détectés.

Pour CRISALID, les tests unitaires constituent une bonne alternative aux commentaires dans le code pour autant qu'ils soient bien structurés et lisibles. Un test unitaire donne généralement davantage de détails que le texte en style commentaire. Les tests unitaires sont donc entretenus avec le code où le commentaire est souvent oublié et où le commentaire peut donc rapidement être dépassé.

Les tests unitaires possèdent également certaines caractéristiques qui ont une influence sur “l'entretenabilité” de l'application. Les tests devraient avoir une structure simple et doivent pouvoir être implémentés facilement. Les dépendances doivent être limitées, l'utilisation de cadres principaux et de remplacement doit permettre de simplifier une configuration test. Si l'écriture d'un test est complexe, on doit réfléchir, en tant que développeur, à implémenter la fonctionnalité différemment. Le code difficile à tester est souvent trop complexe, ce qui augmente le risque d'erreur. La recommandation est de conserver autant que possible en-dessous de 15 la complexité cyclomatique des fonctions et des méthodes individuelles.

Les tests disposent d'une dénomination claire. Nous décrivons ce que fait le test dans la méthode ou le nom du test. Les noms tels que test1, test2 sont interdits.

Les tests unitaires sont donc indépendants et doivent donc pouvoir être exécutés de manière autonome.

Niveau d'intégration

Dans les tests d'intégration, les interfaces entre les différents composants et les interactions avec les différentes parties du système sont testées (comme le système d'exploitation, le système de fichiers, le matériel, etc.). Il peut y avoir plusieurs niveaux de test d'intégration et ils peuvent être réalisés sur des objets de test de taille différente. Nous faisons une distinction entre 2 niveaux de test d'intégration distincts :

• • Tests d'intégration des composants : test de l'interaction entre les composants logiciels. Ils sont réalisés après les tests unitaires.

  • Tests d'intégration système : test de l'interaction entre les différents systèmes. Ils sont réalisés après les tests système.

Plus l'étendue de l'intégration est importante, plus il est difficile d'isoler les défauts dans un composant ou un

système spécifique.

À chaque instant de l'intégration, les testeurs se concentrent uniquement sur l'intégration même. Par exemple, un nouveau module A est intégré avec un module B. Lors des tests d'intégration l'on est principalement intéressé par la communication entre les modules et non par la fonctionnalité des modules même.

Niveau de test système

Dans les tests système, nous souhaitons tester le comportement de tout un système, comme défini dans le projet. Pour les tests système, aucune connaissance de la conception interne ou de la logique du système n'est a priori nécessaire, l'on utilise en effet surtout des techniques de test de boîte noire. Dans les tests système, l'environnement doit autant que possible correspondre à l'environnement de production final afin de minimiser le risque de défauts spécifiques à l'environnement. Les tests système sont déduits des spécifications des risques, des spécifications des exigences, des processus professionnels, des utilisations ou des autres descriptions de haut niveau. Ils sont réalisés dans le contexte des exigences fonctionnelles. Les tests système examinent ensuite également les exigences non fonctionnelles (attributs de qualité).

Les tests système contiennent typiquement les types de test suivants : tests d'interface graphique utilisateur, tests de convivialité, tests de régression, tests de performances, tests de gestion des erreurs, tests de maintenance, tests de compatibilité, tests de charge, tests de sécurité, tests d'extensibilité, etc.

Le but est qu'à la fin de l'exécution du test système CRISALID soit convaincu que le système répond à toutes les exigences fixées et qu'il est prêt à être transféré au client (éventuellement à l'exception de l'interaction avec les systèmes homologues).

Niveau de test d'acceptation

Les tests d'acceptation sont souvent la responsabilité des clients ou des utilisateurs (finaux) d'un système. D'autres intervenants peuvent aussi y être impliqués. Le but des tests d'acceptation est de gagner la confiance dans le système, dans des parties du système ou dans des propriétés non fonctionnelles. Trouver des défauts n'est pas l'objectif principal des tests d'acceptation.

Les tests d'acceptation nous permettent de vérifier l'adéquation d'un système pour une utilisation.

Par exemple :

• • les tests d'acceptation d'utilisabilité d'un composant peuvent être réalisés pendant les tests unitaires.

  • Les tests d'acceptation d'une nouvelle amélioration fonctionnelle peuvent être réalisés pour les tests système.

Les tests d'acceptation contiennent généralement les éléments suivants qui peuvent être considérés comme un niveau de test distinct :

• • Tests d'acceptation des utilisateurs : vérification par des utilisateurs professionnels qu'un système est prêt à l'emploi.

  • Tests d'acceptation opérationnels : l'acceptation du système par les administrateurs système, contient des tests de sauvegarde/restauration, de récupération après sinistre, de gestion des utilisateurs, des tâches de maintenance, etc.

  • Tests contractuels et de directives (test de conformité) : les critères d'acceptation doivent être convenus pendant les négociations relatives au contrat. L'acceptation s'effectue alors vis- à-vis de ces critères pour la production du logiciel. Cela comprend aussi les normes (gouvernement, juridique, sécurité, etc.).

  • Sans accord spécifique, le système doit également satisfaire aux exigences fixées telles que décrites dans le cahier des charges et dans les documents correspondants ainsi qu'aux exigences décrites dans tous les documents plus techniques.

  • Tests alpha et béta : retour des clients potentiels ou existants avant la commercialisation du produit. Les tests alpha sont réalisés au sein de l'organisation du développeur. Les tests béta (tests de terrain) sont réalisés sur le site.

TYPES DE TEST

Tests fonctionnels

Les tests fonctionnels vérifient les fonctions qu'un système, un sous-système ou un composant doivent réaliser. Ceux-ci peuvent être décrits dans les produits de travail tels que les spécifications des exigences, les utilisations, les spécifications fonctionnelles, etc.

Ils décrivent « ce que » fait le système. Les tests fonctionnels sont basés sur les fonctionnalités et leur interopérabilité avec des systèmes spécifiques. Les tests fonctionnels peuvent être réalisés à chaque niveau de test. Par exemple, les tests pour les composants peuvent être basés sur des spécifications des composants. Les tests fonctionnels considèrent le comportement externe des logiciels et sont donc principalement développés à l'aide des techniques de test de la boîte noire.

Tests non fonctionnels

Les tests non fonctionnels comportent (liste non exhaustive) des tests de performances, des tests de charge, des tests de stress, des tests d'utilisation, des tests de fiabilité, etc.

Ils testent « comment » fonctionne le système.

Les tests non fonctionnels peuvent être réalisés à chaque niveau de test. Les tests non fonctionnels vérifient les caractéristiques non fonctionnelles des systèmes. Souvent, ils fonctionnent en mesurant des informations quantifiables qui peuvent être comparées avec des limites pré-établies. Par exemple, les temps de réponse pour les tests de performance.

Tests liés à des modifications (tests de confirmation et tests de régression)

Lorsqu'un défaut est trouvé et résolu, le logiciel doit à nouveau être testé pour s'assurer que le défaut original a été parfaitement résolu. C'est ce que l'on appelle les tests de confirmation. On parle dans ce cas de « nouveaux tests ».

Remarque : Le débogage du code est une activité de développement, pas une activité de test.

Les tests de régression sont de nouveaux tests d'un code de programme déjà testé après modifications, afin de découvrir des défauts (dans les aspects non modifiés du logiciel) causés par des modifications au logiciel ou à l'environnement.

Ces tests sont réalisés chaque fois que l'environnement ou le logiciel change.

Des tests de régression peuvent également être réalisés à chaque niveau de test et peuvent être réalisés tant pour les tests fonctionnels que non fonctionnels et structurels.

Des tests de régression sont souvent réalisés et concernent les fonctionnalités les plus critiques pour être un candidat idéal pour l'automatisation.

CLASSIFICATION DES TECHNIQUES DE TEST

Les techniques de test sont des méthodes de travail formelles pour déduire les cas de test des documents, des modèles de logiciel ou de code.

Nous pouvons scinder les différentes sortes de techniques de test en deux groupes. Les tests de boîte blanche et les tests de boîte noire.

Les tests de boîte blanche sont basés sur le code de programme, les descriptions des programmes ou le projet technique. L'on utilise explicitement les connaissances sur la structure interne du système. Ces tests sont généralement réalisés par les développeurs et il s'agit d'un test réalisé par le développeur pour démontrer qu'un programme (ou un module) ou une série de programmes (ou de modules) satisfait aux exigences posées dans les spécifications techniques.

Les tests de boîte noire sont basés sur les spécifications fonctionnelles et les exigences de qualité. Dans ces tests, le système est considéré dans la forme tel qu'il fonctionnera lors de son utilisation finale. Le logiciel est considéré comme une « boîte noire » sans connaissance de l'implémentation interne ni de la structure interne. Généralement, plusieurs tests sont implémentés, basés sur les spécifications et exigences fonctionnelles.

Même si les deux groupes des techniques de test peuvent être utilisés sur tous les niveaux, l'on applique principalement des techniques de test de boîte blanche sur les niveaux de test inférieurs et des techniques de test de boîte noire sur les niveaux supérieurs.

Les tests d'acceptation réalisés par CRISALID sont principalement utilisés dans les techniques de test de boîte noire.

TESTS BASÉS SUR LES RISQUES

Dans le cadre des tests basés sur les risques, sur la base d'une analyse des risques (du produit), les efforts de tests sont ciblés sur les parties ou aspects d'une application qui comportent le plus gros risque. Cela est considéré comme une bonne pratique pour déterminer la stratégie de test au moins partiellement sur la base d'une analyse des risques.

GRAVITÉ

La gravité (severity) d'un défaut est souvent une source de discussion lors de l'acceptation d'un système.

CRISALID utilise les définitions suivantes pour les degrés de gravité.

Rapport des tests

Le rapport des tests est la phase où l'exécution des tests est comparée aux objectifs. Cela peut comprendre les tâches suivantes :

- Le contrôle des journaux des tests et de la liste des défauts par rapport aux critères spécifiés dans le plan de test.

- Vérifier si des tests supplémentaires sont nécessaires.

- Rédaction d'un rapport de résumé.

DOCUMENTATION DES TESTS

Différents documents doivent être créés pendant le déroulement du processus de test. Nous décrivons ces documents ci-dessous. Il existe pour chacun de ces documents un modèle qui peut servir de fil conducteur.

Plan de test

Le plan de test contient une description de la manière dont les tests sont gérés, planifiés et exécutés. Un plan de test est un document qui est adapté tout au long du cycle de test complet et qui décrit ce qui doit se passer, selon quelle norme de qualité, avec quelles ressources, selon quelle échelle de temps, et indique quels sont les risques et comment ceux-ci peuvent être résolus.

Il est possible de définir un plan de test principal valable pour tout le processus de test. Mais on peut également choisir de définir un plan de test par niveau de test. Par exemple un plan de test pour les tests unitaires, les tests système, etc. Le choix est libre.

En effet, indépendamment du choix ci-dessus, on doit savoir avec certitude ce qui doit être testé précisément à quel niveau de test.

Spécifications de la conception des tests

Le document de spécification de la conception des tests décrit à un niveau logique ce qui doit être testé à l'aide des exigences. Ces exigences sont transformées en conditions de test concrètes. Ce document ne contient pas de données de test ou une description de la manière dont les conditions de test peuvent être testées. Il décrit les exigences pour ces données de test et constitue simplement un lien entre les exigences et les tests.

Spécifications des tests

Les spécifications des tests sont les conditions de test à joindre aux tests concrets en y ajoutant des données de test, des pré-conditions et les résultats attendus. Les tests peuvent être réalisés lorsque la conception des tests est terminée. Un test peut comprendre une ou plusieurs conditions de test.

Un test doit contenir :

- Les données de test nécessaires pour exécuter le test. Ceci est une combinaison des données d'entrée, des données d'application et des données système.

- Le résultat attendu et le résultat.

- Les pré-conditions qui déterminent le point de départ de chaque test.

- Le plan par étapes qui doit être suivi pour exécuter le test.

Journal des tests

Le journal des tests conserve les détails des tests réalisés et des résultats de ceux-ci. Cela peut d'une part signifier qu'un test est réussi, ce qui signifie que le résultat attendu est identique au résultat réel obtenu. D'autre part, cela peut signifier qu'un test a échoué. Cela a pour conséquence qu'un rapport d'incident de test doit être créé et que les détails du problème doivent y être décrits. Un journal de test suit l'évolution de l'exécution du test et donne également des informations sur la cause des incidents.

Rapport d'incident de test

Le rapport d'incident de test documente tout incident qui doit être analysé. Les incidents apparaissent dans le journal de test. Le rapport d'incident de test doit contenir tous les détails de l'incident tels que le résultat attendu et le véritable résultat, lorsqu'il a échoué, et toutes les informations qui peuvent aider à résoudre l'incident. Ce rapport peut éventuellement également avoir un impact sur le test de l'incident.

Rapport du résumé du test

Le rapport du résumé du test contient les résultats des activités de test et l'évaluation des résultats. Cela donne une image globale des activités de test et de la qualité du logiciel. Politique de test 35 5. Annexes 5.1.