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é.
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).
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 :
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.
-
Commencer le retrait - Le client insère sa carte bancaire dans la fente du guichet
automatique.
-
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.
-
Entrer le code confidentiel - Le guichet automatique demande au client d'entrer son code secret
(4 chiffres).
-
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é.
-
Options du guichet automatique - Le guichet automatique affiche les options disponibles.Dans ce
flux, le client choisit toujours le retrait d'espèces.
-
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 €).
-
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.
-
Remise des billets - Les billets sont remis.
-
Ejection de la carte - La carte bancaire est éjectée.
-
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.
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 :
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.
|
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
|
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.)
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.
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.
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.
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.
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.
|