Instructions: Cas de test
Ces instructions expliquent comment identifier et concevoir un logiciel test.
Relations
Description principale

Explication

Rien n'est plus déterminant pour la capacité des équipes projet à garantir la satisfaction de la partie prenante envers le logiciel que la disponibilité d'une spécification claire des attentes de ladite partie prenante. Avec ou sans une série acceptable de spécifications d'exigences, les jeux d'essai permettent de refléter les attentes des parties prenantes, et donc de les vérifier et de les valider.

Lorsqu'une série utile d'exigences est disponible, l'équipe de test doit planifier les tests servant à valider de façon appropriée ces exigences. La validation d'un logiciel par rapport aux exigences peut être effectuée de plusieurs façons, en fonction du type d'exigence. Par exemple, l'exécution du logiciel pour valider ses exigences fonctionnelles et de performances peut être faite par un testeur via des techniques de test automatisées ; pour sa part, la vérification d'une exigence de configuration comme l'arrêt du système hôte peut être menée à l'aide de techniques de test manuelles.

Comme vous n'êtes pas forcément capable (ou responsable) de vérifier toutes les exigences, il est important de vous concentrer sur celles les plus déterminantes et appropriées pour la portée du travail en cours. Les exigences choisies seront un compromis entre le coût, le risque et le besoin de vérification. Elles seront en général limitées par la portée de l'itération en cours.

Même si les exigences sont une importante source de laquelle des tests sont issus, elles ne forment pas l'unique source d'informations. En fait, elles s'avèrent bien souvent insuffisantes pour offrir un base complète de développement pour les tests. Il ne faut pas oublier que les jeux d'essai s'inspirent également de sources d'informations comme les risques, les contraintes, les technologies, les demandes de changement (incidents), les erreurs, etc.
Voir Concept : Idées de test pour en savoir plus sur les idées à partir desquelles des tests peuvent être développés.

L'identification de jeux d'essai est utile pour plusieurs raisons.

  • Les jeux d'essai peuvent servir de base à la conception et à l'implémentation de tests. Le temps consacré à l'analyse du jeu d'essai permet de mieux comprendre les exigences de conception et d'implémentation, sans compter le temps gagné pour ces tâches.
  • Certains tests sont particulièrement complexes ou détaillés. Dans ce cas, vous avez tout intérêt à bien réfléchir avant d'entamer leur implémentation. Les artefacts de jeux d'essai et de conception de tests sont de bons outils pour mener cette réflexion préalable.
  • La "profondeur" de test est généralement considérée proportionnelle au nombre de tests. La confiance dans le processus de test est souvent supérieure si la profondeur potentielle peut être évaluée en fonction du nombre de jeux d'essai identifiés.
  • L'une des façons d'évaluer si l'effort de test est suffisant repose sur la couverture de contrôle par rapport à un ensemble d'éléments pertinents. Les rapports sur cette couverture peuvent partir de mesures comme le nombre de jeux d'essai identifiés et le nombre de tests implémentés et/ou exécutés pour chaque jeu d'essai, ou encore la quantité d'efforts déployés pour chaque jeu d'essai.
  • L'échelle et la complexité de l'effort de test sont dans une certaine mesure proportionnelles au nombre de jeux d'essai. En décomposant les jeux d'essai, l'effort de test peut être estimé à un niveau plus précis de granularité.
  • Les types de conception et de développement de tests, tout comme les ressources nécessaires, dépendent en partie du nombre et de la complexité des jeux d'essai.

Cependant, certains aspects méritent d'être pris en compte en matière de jeux d'essai :

  • Tous les tests ne sont pas complexes au point de justifier la surcharge que suppose la création d'un artefact de jeu d'essai devant être révisé et géré : le test est suffisamment simple pour qu'une brève description textuelle expose les exigences. En fait, la majorité des jeux d'essai appartiennent à cette catégorie. Le temps passé à rédiger un grand nombre de jeux d'essai n'est pas productif, et est pris aux dépends des tâches plus importantes de test.
  • Certaines idées de départ pour les tests sont dans une certaine mesure erronées. Aussi, certains jeux d'essai identifiés à l'origine par rapport à ces idées seront abandonnés. Par conséquent, tout travail de rédaction détaillée de jeux d'essai peut par la suite s'avérer inutile : tous les rapports sur la couverture en fonction de ces jeux d'essai doivent prendre cette situation en compte. C'est pourquoi il est préférable de fonder les rapports sur la couverture des tests sur des aspects de niveau supérieur aux jeux d'essai et de considérer ces derniers comme des artefacts internes utilisés comme il se doit.

Les jeux d'essai sont souvent classés par type de test ou exigence de test auxquels ils sont associés et varient en conséquence. Une approche heuristique pour identifier les jeux d'essai commence de la manière suivante :

  • démonstration que l'exigence a été respectée (jeu d'essai positif),
  • démonstration que l'exigence est uniquement respectée dans les conditions souhaitées (jeu d'essai négatif). Ce jeu d'essai signale des données ou conditions inacceptables, anormales ou imprévues auxquelles le logiciel peut très bien être confronté.

Jeux d'essai issus de cas d'utilisation

Les jeux d'essai pour les tests fonctionnels sont dérivés de cas d'utilisation de la cible de test (voir Produit : Cas d'utilisation). Les jeux d'essai doivent être développés pour chaque scénario de cas d'utilisation. Ceux-ci sont identifiés en décrivant les chemins au sein du cas d'utilisation et parcourant le flux de base et des Flux de remplacement.

Dans le diagramme ci-après par exemple, chaque chemin au sein d'un cas d'utilisation reflétant le flux de base et ceux de remplacement est symbolisé par une flèche. Le flux de base, représenté par la ligne droite noire est le chemin le plus simple au sein du cas d'utilisation. Chaque flux de remplacement commence par le flux de base avant d'être exécuté, en fonction d'une condition spécifique. Les Flux de remplacement rejoignent le flux de base (Flux de remplacement 1 et 3), peuvent commencer à partir d'un autre flux de remplacement (2) ou terminer le cas d'utilisation avant de rejoindre un flux (flux de remplacement 2 et 4).

Diagramme décrit dans la légende.

Exemple de flux d'événements pour un cas d'utilisation

En suivant chaque chemin possible dans le cas d'utilisation du diagramme ci-dessus, il est possible d'identifier les différents scénarios de cas d'utilisation. En commençant par le flux de base et en combinant ensuite celui-ci à des flux de remplacement, les scénarios de cas d'utilisation suivants peuvent être identifiés : 

Scénario 1 Flux de base      
Scénario 2 Flux de base Flux de remplacement 1    
Scénario 3 Flux de base Flux de remplacement 1 Flux de remplacement 2  
Scénario 4 Flux de base Flux de remplacement 3    
Scénario 5 Flux de base Flux de remplacement 3 Flux de remplacement 1  
Scénario 6 Flux de base Flux de remplacement 3 Flux de remplacement 1 Flux de remplacement 2
Scénario 7 Flux de base Flux de remplacement 4    
Scénario 8 Flux de base Flux de remplacement 3 Flux de remplacement 4  

Remarque : à des fins de simplification, les scénarios 5, 6 et 8 décrivent uniquement une exécution de la boucle indiquée par le flux de remplacement 3.    

Les jeux d'essai sont créés pour chaque scénario en identifiant la condition spécifique qui entraînera l'exécution de ce scénario de cas d'utilisation déterminé.

Imaginez par exemple que le cas d'utilisation décrit dans le diagramme ci-dessus mentionne le flux de remplacement 3 suivant :

"Ce flux d'événements se produit si la quantité en euros indiquée à l'étape 2 ci-dessus ("Entrer la quantité de retrait") est supérieure au solde actuel du compte. Le système affiche un message d'avertissement et rejoint le flux de base à l'étape "Entrer la quantité de retrait" ci-dessus, à laquelle le client peut indiquer une nouvelle quantité de retrait."

Avec ces informations, vous pouvez identifier les jeux d'essai nécessaires pour l'exécution du flux de remplacement 3 :

ID jeu d'essai Scénario Condition Résultat attendu
TC x Scénario 4 Etape 2 - Quantité de retrait > Solde du compte Rejoindre le flux de base à l'étape 2
TC y Scénario 4 Etape 2 - Quantité de retrait < Solde du compte Ne pas exécuter le flux de remplacement 3, prendre flux de base
TC z Scénario 4 Etape 2 - Quantité de retrait = Solde du compte Ne pas exécuter le flux de remplacement 3, prendre flux de base

Remarque : les jeux d'essai ci-dessus sont très simples car aucune information n'est fournie. Dans la réalité, ils sont généralement plus compliqués.

Ci-après un exemple plus réaliste de jeux d'essai créés à partir de cas d'utilisation :

Exemple :

Diagramme décrit dans la légende.

Acteurs et cas d'utilisation dans un guichet automatique.

Le tableau suivant présente le flux de base et des flux de remplacement pour le cas d'utilisation de retrait d'espèces dans le diagramme ci-dessus :

Flux de base Ce cas d'utilisation débute avec le guichet automatique prêt à l'emploi.
  1. Commencer le retrait - Le client insère sa carte bancaire dans la fente du guichet automatique.
  2. Vérifier la carte bancaire - Le guichet automatique lit le code du compte sur la bande magnétique de la carte et vérifie que celle-ci est en règle.
  3. Entrer le code confidentiel - Le guichet automatique demande au client d'entrer son code secret (4 chiffres).
  4. Vérifier le code du compte et le confidentiel - Le code du compte et le code secret sont contrôlés pour déterminer si le compte est valide et si le code entré correspond à ce compte. Pour ce flux, le compte est valide et le code est bien celui qui lui est associé.
  5. Options du guichet automatique - Le guichet automatique affiche les options disponibles.Dans ce flux, le client choisit toujours le retrait d'espèces.
  6. Entrer le montant - Le guichet automatique demande le montant à retirer. Pour ce flux, le client choisit un montant prédéfini (10 €, 20 €, 50 € ou 100 €).
  7. Autorisation - Le guichet automatique lance le processus de vérification auprès du système bancaire en envoyant l'ID de carte, le code, le montant et les informations du compte sous forme de transaction.Pour ce flux, le système bancaire est en ligne : il autorise le retrait d'espèces et met à jour le solde du compte en conséquence.
  8. Remise des billets - Les billets sont remis.
  9. Ejection de la carte - La carte bancaire est éjectée.
  10. Ticket - Le reçu est imprimé et émis.Le guichet automatique met aussi à jour le journal interne. 

Au terme du cas d'utilisation, le guichet automatique est de nouveau prêt à l'emploi.

Flux de remplacement 1 - Carte non valide Dans l'étape 2 du flux de base (Vérifier la carte bancaire), la carte identifiée comme non valide est éjectée avec le message correspondant.
Flux de remplacement 2 - Guichet automatique vide A l'étape 5 du flux de base (Options du guichet automatique), si le guichet automatique est vide, l'option de retrait d'espèces n'est pas disponible.
Flux de remplacement 3 - Fonds insuffisants dans le guichet automatique A l'étape 6 du flux de base (Entrer le montant), si le guichet automatique ne contient pas des fonds suffisants pour remettre le montant demandé, un message correspondant s'affiche et rejoint le flux de base à l'étape 6.
Flux de remplacement 4 - Code confidentiel incorrect A l'étape 4 du flux de base (Vérifier le code du compte et le code confidentiel), le client dispose de trois essais pour saisir le code correct.  

S'il entre un code incorrect, le guichet automatique affiche le message correspondant. S'il reste des tentatives, ce flux rejoint le flux de base à l'étape 3 (Entrer le code confidentiel). 

Si le code est toujours erroné à la dernière tentative, la carte est avalée, le guichet automatique est de nouveau prêt à l'emploi et ce cas d'utilisation s'achève.
Flux de remplacement 5 - Compte inexistant A l'étape 4 du flux de base (Vérifier le code du compte et le code confidentiel), si le système bancaire renvoie un code indiquant que le compte est introuvable ou ne permet pas des retraits, le guichet automatique affiche le message correspondant et rejoint le flux de base à l'étape 9 (Ejection de la carte).
Flux de remplacement 6 - Fonds insuffisants sur le compte A l'étape 7 du flux de base (Autorisation), si le système bancaire renvoie un code indiquant que le solde du compte est inférieur au montant entrée à l'étape 6 du flux de base (Entrer le montant), le guichet automatique affiche le message correspondant et rejoint le flux de base à l'étape 6.
Flux de remplacement 7 - Maximum de retrait par jour atteint A l'étape 6 du flux de base (Autorisation), si le système bancaire renvoie un code indiquant que, en prenant en compte cette demande de retrait, le client a dépassé ou dépassera le montant maximum autorisé par tranche de 24 heures, le guichet automatique affiche le message correspondant et rejoint le flux de base à l'étape 6 (Entrer le montant).
Flux de remplacement x - Erreur du journal Si à l'étape 10 du flux de base le journal ne peut pas être mis à jour, le guichet automatique passe en mode sécurisé et toutes les fonctions sont suspendues. Une alerte correspondant est envoyée au système bancaire pour signaler que le guichet automatique a interrompu son activité.
Flux de remplacement y - Quitter Le client peut à tout moment décider de mettre fin à la transaction (quitter). La transaction est arrêtée et la carte éjectée.
Flux de remplacement z - Signal Le guichet automatique renferme plusieurs capteurs contrôlant différentes fonctions, telles que l'alimentation électrique, la pression exercée sur les portes, ainsi que des détecteurs de mouvement.Si un capteur est à tout moment activé, un signal d'alarme est envoyé à la police et le guichet automatique passe en mode sécurisé : toutes les fonctions sont suspendues tant que les actions appropriées de redémarrage/réinitialisation ne sont pas prises.


Dans la première itération, en fonction du plan d'itération, il est nécessaire de vérifier que le cas d'utilisation de retrait d'espèces a été correctement implémenté. Tout le cas d'utilisation n'a pas encore été implémenté, mais uniquement les flux suivants :

  • Flux de base - Retrait d'un montant prédéfini (10 €, 20 €, 50 €, 100 €)
  • Flux de remplacement 2 - Guichet automatique vide
  • Flux de remplacement 3 - Fonds insuffisants dans le guichet automatique
  • Flux de remplacement 4 - Code confidentiel incorrect
  • Flux de remplacement 5 - Compte inexistant/type de compte incorrect
  • Flux de remplacement 6 - Fonds insuffisants sur le compte

Les scénarios suivants peuvent être créés à partir de ce cas d'utilisation :

Scénario 1 - Retrait d'espèces réussi Flux de base  
Scénario 2 - Guichet automatique vide Flux de base Flux de remplacement 2
Scénario 3 - Fonds insuffisants dans le guichet automatique Flux de base Flux de remplacement 3
Scénario 4 - Code confidentiel incorrect (avec essais restants) Flux de base Flux de remplacement 4
Scénario 5 - Code confidentiel incorrect (sans essai restant) Flux de base Flux de remplacement 4
Scénario 6 - Compte inexistant/type de compte incorrect Flux de base Flux de remplacement 5
Scénario 7 - Fonds insuffisants sur le compte Flux de base Flux de remplacement 6

Remarque : à des fins de simplification, les boucles dans les flux de remplacement 3 et 6 (scénarios 3 et 7) et les combinaisons de boucles n'ont pas été intégrées dans le tableau ci-dessus.

Pour chacun des sept scénarios, des jeux d'essai doivent être identifiés. Il est possible d'identifier et de gérer des jeux d'essai à l'aide de matrices ou de tables de décision. Vous trouverez ci-dessous un format courant, chaque ligne représentant un jeu d'essai individuel et les colonnes répertoriant les informations sur le jeu d'essai.Dans cet exemple se trouvent pour chaque jeu d'essai une condition (ou description), toutes les données impliquées (comme entrées ou déjà dans la base de données) et le résultat attendu.

Pour développer la matrice, commencez par identifier les données requises en vue d'exécuter les scénarios de cas d'utilisation. Pour chaque scénario, identifiez ensuite au moins un jeu d'essai contenant la condition appropriée pour l'exécuter. Par exemple, dans la matrice ci-après, V (valide) sert à indiquer que cette condition doit être VALIDE pour le flux de base à exécuter et I (invalide) à signaler la condition qui appellera le flux de remplacement souhaité.Dans le tableau suivant, n/a indique que cette condition ne s'applique pas au jeu d'essai.

N° d'identificateur TC Scénario / Condition Code personnel Numéro de compte Montant saisi

(montant choisi)

Montant sur le compte Montant dans le guichet automatique Résultat attendu
CW1. Scénario 1 - Retrait d'espèces réussi V V V V V Retrait d'espèces réussi.
CW2. Scénario 2 - Guichet automatique vide V V V V I Option de retrait non disponible, fin du cas d'utilisation
CW3. Scénario 3 - Fonds insuffisants dans le guichet automatique V V V V I Message d'avertissement, retour à l'étape 6 du flux de base (Entrer le montant)
CW4. Scénario 4 - Code confidentiel incorrect (> 1 essai restant) I V n/a V V Message d'avertissement, retour à l'étape 4 du flux de base (Entrer le code confidentiel)
CW5. Scénario 4 - Code confidentiel incorrect (= 1 essai restant) I V n/a V V Message d'avertissement, retour à l'étape 4 du flux de base (Entrer le code confidentiel)
CW6. Scénario 4 - Code confidentiel incorrect (= 0  essai restant) I V n/a V V Message d'avertissement, carte avalée, fin du cas d'utilisation

Dans la matrice ci-dessus, les six jeux d'essai exécutent les quatre scénarios. Pour le flux de base, le jeu d'essai CW1 correspond à un jeu d'essai positif. Il suit le parcours du flux de base selon le cas d'utilisation sans déviations. Le test complet du flux de base doit cependant inclure des jeux d'essai négatifs pour que ce flux soit uniquement appliqué lorsque les conditions sont correctes. Ces jeux d'essai négatifs correspondent à CW2 - 6 (la cellule grisée indique la condition requise pour exécuter les flux de remplacement).Alors que les jeux d'essai CW2 - 6 sont négatifs pour le flux de base, ils sont positifs pour les flux de remplacement 2 - 4. Il existe par ailleurs au moins un jeu d'essai négatif pour chacun de ces flux de remplacement (CW1 - le flux de base).

Le scénario 4 illustre parfaitement qu'il est insuffisant d'avoir un seul jeu d'essai positif et un autre négatif par scénario. Pour tester en profondeur le scénario 4 - Code confidentiel incorrect, au moins trois jeux d'essai positifs (pour appeler le scénario 4) s'avèrent nécessaires :

  • le code confidentiel incorrect est entré, il reste des tentatives et ce flux de remplacement rejoint l'étape 3 du flux de base (Entrer le code confidentiel) ;
  • le code confidentiel incorrect est entré et il ne reste plus de tentatives : ce flux de remplacement avale la carte et termine le cas d'utilisation ;
  • le code confidentiel CORRECT est entré quand il ne reste plus de tentatives.Ce flux de remplacement rejoint l'étape 5 du flux de base (Entrer le montant). 

Dans la matrice ci-dessus, vous remarquez qu'aucune valeur n'a été saisie pour les conditions (données). L'avantage de créer la matrice de jeu d'essai de cette façon est qu'il est facile d'observer les conditions testées. Il est également très simple de déterminer si suffisamment de jeux d'essai ont été identifiés, sachant que vous devez uniquement prêter attention aux lettres V et I (ou, comme ici, aux cellules grisées). Dans le tableau ci-dessus, il n'existe aucune cellule grisée pour plusieurs conditions, ce qui prouve qu'il manque des jeux d'essai, par exemple pour les scénarios 6 (Compte inexistant/type de compte incorrect) et 7 (Fonds insuffisants sur le compte).

Une fois les jeux d'essai efficaces identifiés, ils doivent être révisés et validés afin de garantir leur précision et leur pertinence, ainsi que pour supprimer les jeux d'essai en double, équivalents ou redondants. Voir Concept : Liste d'idées de test pour en savoir plus. Voir aussi la section Définition de données de test pour les jeux d'essai pour un complément d'information.

N° d'identificateur TC Scénario / Condition Code personnel Numéro de compte Montant entré

(montant choisi)

Montant sur le compte Montant dans le guichet automatique Résultat attendu
CW1. Scénario 1 - Retrait d'espèces réussi 4987 809 - 498 50,00 500,00 2 000 Retrait d'espèces réussi. Solde du compte actualisé à 450,00.
CW2. Scénario 2 - Guichet automatique vide 4987 809 - 498 100,00 500,00 0,00 Option de retrait non disponible, fin du cas d'utilisation
CW3. Scénario 3 - Fonds insuffisants dans le guichet automatique 4987 809 - 498 100,00 500,00 70,00 Message d'avertissement, retour à l'étape 6 du flux de base (Entrer le montant)
CW4. Scénario 4 - Code confidentiel incorrect (> 1 essai restant) 4978  809 - 498 n/a 500,00 2 000 Message d'avertissement, retour à l'étape 4 du flux de base (Entrer le code confidentiel)
CW5. Scénario 4 - Code confidentiel incorrect (= 1 essai restant) 4978 809 - 498 n/a 500,00 2 000 Message d'avertissement, retour à l'étape 4 du flux de base (Entrer le code confidentiel)
CW6. Scénario 4 - Code confidentiel incorrect (= 0  essai restant) 4978  809 - 498 n/a 500,00 2 000 Message d'avertissement, carte avalée, fin du cas d'utilisation

Les jeux d'essai ci-dessus ne sont qu'une partie de ceux nécessaires pour vérifier le cas d'utilisation de retrait d'espèces pour cette itération. Les autres jeux d'essai requis incluent :

  • scénario 6 - Compte inexistant/type de compte incorrect : le compte est introuvable ou n'est pas disponible ;
  • scénario 6 - Compte inexistant/type de compte incorrect : le compte n'autorise pas les retraits ;
  • scénario 7 - Fonds insuffisants sur le compte : le montant demandé est supérieur au solde du compte.

Dans les itérations ultérieures lorsque d'autres flux sont implémentés, des jeux d'essai sont nécessaires pour :

  • des cartes non valides (la carte est déclarée perdue, volée, n'est pas d'une banque acceptée, sa bande est endommagée, etc.) ;
  • l'impossibilité de lire la carte (le lecteur de cartes est bloqué, hors ligne ou défaillant) ;
  • un compte fermé, bloqué ou non disponible ;
  • des fonds insuffisants dans le guichet automatique ou si celui-ci ne peut pas rassembler la somme demandée (différent de CW3, ici la dénomination est externe) ;
  • l'impossibilité de contacter le système bancaire pour approbation ;
  • le réseau bancaire qui passe hors ligne ou si une coupure de courant se produit au milieu d'une transaction.

Lors de l'identification de jeux d'essai, assurez-vous de ce qui suit :

  • suffisamment de jeux d'essai tant positifs que négatifs ont été identifiés pour chaque scénario de cas d'utilisation,
  • les jeux d'essai portent sur des règles métier implémentées par les cas d'utilisation, garantissant l'existence de jeux d'essai dans, en dehors et à la condition/valeur frontière des règles métier,
  • les jeux d'essai portent sur toute séquence d'événements ou d'actions, telles que celles identifiées dans les diagrammes de séquences du modèle de conception ou les conditions ou états d'objets de l'interface utilisateur,
  • les jeux d'essai portent sur des exigences spéciales définies pour le cas d'utilisation, comme les performances minimum/maximum, parfois combinées à des charges minimum/maximum ou des volumes de données lors de l'exécution des cas d'utilisation.

Voir la section Définition de données de test pour les jeux d'essai pour en savoir plus.

Création de jeux d'essai à partir de spécifications supplémentaires

Toutes les exigences pour une cible de test seront reflétées dans les exigences fonctionnelles, comme les spécifications du cas d'utilisation. Les exigences non fonctionnelles, comme celles de performances, de sécurité, d'accès et de configuration, désignent des comportements ou des caractéristiques supplémentaires de la cible de test et sont souvent mentionnées séparément à partir des exigences fonctionnelles. La spécification supplémentaire est l'une des sources primaires à partir de laquelle créer des jeux d'essai pour ces exigences supplémentaires.

Ci-après les instructions pour créer ces jeux d'essai supplémentaires :

Création de jeux d'essai pour des tests de performances

Les spécifications supplémentaires sont l'aspect principal pour les jeux d'essai de performances et contiennent des exigences non fonctionnelles (voir Produit : Spécifications supplémentaires). Suivez les instructions ci-après pour créer des jeux d'essai pour des tests des performances :

  • Vérifiez qu'au moins un jeu d'essai est identifié pour chaque instruction dans la spécification supplémentaire mentionnant les critères de performances. Ces critères sont généralement exprimés comme durée par transaction, nombre de transactions / utilisateur ou pourcentages.
  • Vérifiez qu'au moins un jeu d'essai est identifié pour chaque cas d'utilisation important. Ces cas d'utilisation sont identifiés dans les instructions ci-dessus et/ou dans le document d'analyse de la charge de travail à évaluer avec les mesures de performances (voir Produit : Document d'analyse de la charge de travail).

Comme pour les jeux d'essai pour les tests fonctionnels, il existe en général plusieurs jeux d'essai pour chaque scénario ou exigence. Il est fréquent de définir plusieurs jeux d'essai : par exemple, un sous la valeur du seuil de performances (taux de transaction moyen), un autre à la valeur de seuil (taux de transaction élevée) et un troisième au-dessus de cette valeur de seuil (taux de transaction maximum).

Outre les critères de performances ci-dessus, veillez à identifier les conditions affectant les temps de réponse, dont :

  • Taille de la base de données - combien d'enregistrements existants ?
  • Charge de travail - patterns de transaction :
    • type, nombre et fréquence des actions simultanées de l'utilisateur,
    • type, nombre, fréquence et durée des transactions simultanées effectuées.
  • Caractéristiques de l'environnement (matériel, réseau, configuration logicielle)

Il est courant d'organiser des jeux d'essai pour des tests de performances dans des matrices tabulaires semblables à celles employées pour les tests fonctionnels.

Voir la section Définition des données de test pour les jeux d'essai pour plus de détails.

Voici quelques exemples de types différents de tests de performances :

Pour un test de charge :

N° d'identificateur TC Charge de travail Condition Résultat attendu
PCW1.

1

(un seul guichet automatique)

Transaction de retrait complète

Transaction complète (temps indépendant de l'acteur) < 20 secondes
PCW2.

2

(1 000 guichets automatiques simultanés)

Transaction de retrait complète

Transaction complète (temps indépendant de l'acteur) < 30 secondes
PCW3.

3

(10 000 guichets automatiques simultanés)

Transaction de retrait complète

Transaction complète (temps indépendant de l'acteur) < 50 secondes

Pour un test sous contraintes :

N° d'identificateur TC Charge de travail Condition Résultat attendu
SCW1.

2

(1 000 guichets automatiques simultanés)

Verrouillage de la base de données - 2 guichets automatiques interrogeant le même compte

Demandes des guichets automatiques mises en file d'attente
SCW2.

2

(1 000 guichets automatiques simultanés)

La communication au système bancaire n'est pas disponible

La transaction est mise en file d'attente ou temporisée.
SCW3.

2

(1 000 guichets automatiques simultanés)

La communication au système bancaire s'arrête pendant la transaction.

Un message d'avertissement s'affiche.

Création de jeux d'essai pour des tests de sécurité/d'accès

Les acteurs et les cas d'utilisation décrivent l'interaction entre des utilisateurs externes et les actions réalisées par le système pour renvoyer une valeur à un acteur déterminé. Les systèmes complexes renfermant de nombreux acteurs, il est essentiel de mettre au point des jeux d'essai pour assurer que seuls les acteurs indiqués pour les exécuter peuvent le faire. Ceci se vérifie notamment s'il existe des différences dans le flux d'événements du cas d'utilisation en fonction du type d'acteur.

Par exemple, dans les cas d'utilisation du guichet automatique, plusieurs flux d'événements peuvent être exécutés pour l'acteur client si sa carte et son compte sont de l'entité du guichet, contrairement au client utilisant une carte et un compte d'un concurrent ou d'une banque n'appartenant pas au même réseau.

Suivez les mêmes instructions que celles mentionnées précédemment pour les jeux d'essai fonctionnels.

Voir la section Définition de données de test pour les jeux d'essai pour en savoir plus.

Exemples de jeux d'essai pour la sécurité et l'accès :

N° d'identificateur TC Condition Carte

(V désigne une carte valide)

Lecteur de cartes

(V indique que le lecteur fonctionne correctement)

Réseau de la banque Résultat attendu
ACW1. Dans le réseau bancaire V V V Tous les cas d'utilisation disponibles
ACW2. Hors du réseau bancaire V V I Cas d'utilisation de retrait d'espèces uniquement
ACW3. Impossible de lire la carte I V V Message d'avertissement, la carte est éjectée
ACW4. Carte signalée comme volée I V V Message d'avertissement, la carte est avalée
ACW5. La carte a expiré I V V Message d'avertissement, la carte est avalée

Création de jeux d'essai pour des tests de configuration

Dans des systèmes répartis typiques, de nombreuses combinaisons de matériel et de logiciels peuvent être prises en charge. Les tests doivent donc être réalisés de façon à vérifier que les fonctions de la cible de test s'exécutent correctement dans diverses configurations (par exemple, différents systèmes d'exploitation, navigateurs ou vitesses de l'unité centrale). Par ailleurs, les tests doivent également couvrir des combinaisons de composants pour résoudre les incidents dus aux interactions entre composants : par exemple, il faut vérifier si la version des DLL installées par une application ne crée pas des conflits avec les versions des mêmes DLL attendues par une autre application.

Pour créer des jeux d'essai pour des tests de configuration, suivez les instructions ci-après :

  • Assurez-vous qu'au moins un jeu d'essai identifie chaque configuration importante. Pour ce faire, identifiez les configurations matérielles et logicielles requises pour l'environnement de la cible de test et accordez des priorités à ces configurations, en veillant à ce que les plus courantes soient testées en premier, dont :
    • Prise en charge de l'imprimante
    • Connexions réseau - réseaux locaux et étendus
    • Configurations de serveurs - pilotes et matériel de serveurs
    • Autres logiciels installés sur le bureau et/ou les serveurs
    • Versions de tous les logiciels installés
  • Assurez-vous qu'au moins un jeu d'essai peut créer des incidents pour chaque configuration. Entre autres :
    • Matériel avec les performances minimum
    • Logiciels corésidents possédant un historique de problèmes de compatibilité
    • Clients accédant au serveur avec la connexion LAN/WAN la plus lente possible
    • Ressources insuffisantes (faible vitesse de l'unité centrale, mémoire ou résolution minimum, espace disque, etc.)

Création de jeux d'essai pour des tests d'installation

Les tests d'installation doivent vérifier que la cible de test peut être installée dans tous les scénarios possibles d'installation. Ces scénarios peuvent comprendre l'installation initiale de la cible de test ou d'une nouvelle version (sur une machine possédant la version antérieure). Les tests d'installation doivent aussi contrôler que la cible de test fonctionne correctement lorsque des conditions anormales se présentent, comme un espace disque insuffisant.

Les jeux d'essai doivent couvrir les scénarios d'installation pour les logiciels, dont :

  • Supports de distribution, comme des disquettes, des CD-ROM ou un serveur de fichiers
  • Nouvelle installation
  • Installation complète
  • Installations personnalisées
  • Installations de mise à niveau

Les programmes d'installation pour les logiciels client-serveur possèdent un lot particulier de jeux d'essai. Contrairement aux systèmes basés sur des hôtes, le programme d'installation est généralement divisé entre le serveur et le client. Par conséquent, il est important que le test d'installation passe par l'installation de tous les composants de la cible de test, y compris le client, les niveaux intermédiaires et les serveurs.

Création de jeux d'essai pour d'autres tests non fonctionnels

Vous devez dans l'idéal disposer de toutes les données nécessaires pour créer des jeux d'essai dans les artefacts de modèle de cas d'utilisation, de modèle de conception et de spécification supplémentaire. Il peut toutefois arriver que vous deviez compléter ces informations.

Exemples :

  • des jeux d'essai pour des tests opérationnels (pour vérifier que le logiciel fonctionne lorsqu'il est utilisé pendant longtemps entre deux incidents) ;
  • des jeux d'essai analysant les goulots d'étranglement des performances et les capacités de volume du système ou chargeant la cible de test pour provoquer un incident.

Le plus souvent, vous trouverez ces jeux d'essai en créant des variantes ou des agrégats de jeux d'essai dérivés de ceux identifiés auparavant.

Création de jeux d'essai pour des tests de réception du produit

Les tests de réception du produit arrivent en dernier, avant le déploiement du logiciel. Leur objectif est de vérifier que le logiciel est au point et utilisable pour effectuer les fonctions et tâches pour lesquelles il a été conçu. Ces tests vont souvent au-delà de l'exécution du logiciel et impliquent tous les produits livrés aux clients, tels que formation, documentation et emballage. 

Pour créer des jeux d'essai pour le ou les produits logiciels, procédez comme décrit dans les sections ci-dessus. En fonction du degré de formalité du test de réception du produit, les jeux d'essai sont identiques ou semblables à ceux identifiés précédemment (formels) ou correspondent à un sous-ensemble (informels). Indépendamment de la profondeur des jeux d'essai, il faut parvenir à un accord sur les jeux d'essai et les critères d'acceptation avant d'implémenter et d'exécuter le test du produit.

L'évaluation de produits non logiciels est fort variable selon le produit évalué. Voir les instructions et les listes de contrôle de chaque produit non logiciel pour en savoir plus sur ce qu'il faut évaluer et comment procéder.

Jeux d'essai de vérification de constructions pour des tests de régression

Les tests de régression comparent deux constructions ou versions de la même cible de test et relèvent les différences comme incidents potentiels. Ils supposent par conséquent qu'une nouvelle version doit se comporter comme l'antérieure et assurent qu'aucun incident n'a été provoqué par des changements.

Idéalement, tous les jeux d'essai dans une même itération doivent être utilisés dans les itérations ultérieures. Les instructions ci-après doivent être suivies pour identifier, concevoir et implémenter des jeux d'essai optimisant la valeur de régression des tests et de réutilisation, tout en réduisant la maintenance :

  • Vérifiez que le jeu d'essai identifie uniquement les données essentielles (requises pour créer/prendre en charge la condition testée).
  • Vérifiez que chaque jeu d'essai décrit ou illustre un ensemble unique d'entrées ou une séquence d'événements entraînant un comportement unique de la cible de test.
  • Supprimez les jeux d'essai redondants ou équivalents.
  • Regroupez les jeux d'essai dont l'état initial de la cible de test et l'état des données de test est identique.

Définition de données de test pour les jeux d'essai

Une fois les jeux d'essai commentés et approuvés à l'unanimité, les valeurs des données peuvent être identifiées avec plus de détail (par exemple, dans la matrice d'implémentation des jeux d'essai) et les artefacts de données de test créés.

Voir Instructions : Données de test pour plus d'informations sur la définition et la gestion des données de test.