Rubriques

Explication Haut de la page

Rien n'a plus d'influence sur la capacité de l'équipe du projet à garantir la satisfaction des parties prenantes par rapport au logiciel, que la disponibilité d'une spécification claire des attentes des parties prenantes. Avec ou sans un ensemble suffisant de spécifications d'exigences, les jeux d'essai sont un artefact aidant à exprimer les attentes des parties prenantes, et permettant à ces attentes d'être vérifiées et validées.

Lorsqu'un ensemble utile d'exigences est disponible, l'équipe de test doit programmer des tests qui valideront ces exigences de façon appropriée. Notez que la validation du logiciel par rapport aux exigences peut être effectuée différemment selon le type d'exigence. Par exemple, un testeur utilisant des techniques de test automatisées peut exécuter le logiciel pour valider ses exigences fonctionnelles et de performance ; alors que pour vérifier une exigence de configuration comme l'arrêt du système de l'ordinateur hôte il peut être nécessaire d'utiliser des techniques de test manuelles.

Dans la mesure où vous ne pourrez peut-être pas (ou qu'il ne sera pas de votre responsabilité) vérifier toutes les exigences, il est important de se focaliser sur les exigences les plus appropriées ou les plus cruciales pour la portée de l'effort de travail actuel. Les exigences que vous décidez de vérifier seront un juste milieu entre le coût, le risque et la nécessité de vérification de l'exigence, et seront généralement limités par la portée de l'itération actuelle.

Les exigences sont une source importante à partir de laquelle les tests peuvent être obtenus, mais elles ne sont pas la seule source d'information. En fait, dans bien des cas elles ne suffiront pas à fournir une base complète à partir de laquelle les tests sont développés. Vous devrez également envisager des jeux d'essai basés sur des sources d'informations comme les risques, les contraintes, les technologies, les demandes de changement (défauts), les fautes, etc.
Voir Concepts : Idées de test pour plus d'informations sur la façon de trouver des idées à partir desquelles des tests peuvent être obtenus.

L'identification des jeux d'essai est utile pour un certain nombre de raisons.

  • Les jeux d'essai peuvent être utilisés comme la base à partir de laquelle les véritables tests sont conçus et implémentés. Le temps passé à examiner le jeu d'essai aide à mieux comprendre les exigences de conception et d'implémentation, et peut éventuellement gagner du temps dans les activités de conception et d'implémentation.
  • Certains tests sont particulièrement complexes ou détaillés. Les tests de ce type peuvent gagner à être examinés avec précaution en avance avant de commencer l'implémentation du test, et les artefacts de jeu d'essai et de conception de test sont de bons outils pour effectuer cet examen.
  • La "profondeur" du test est généralement considérée comme proportionnelle au nombre de tests. On obtient souvent une plus grande confiance dans le processus de test lui-même lorsque la "profondeur" potentielle du test peut être calculée selon le nombre de jeux d'essai identifiés.
  • Une mesure de l'intégralité de l'effort de test est basée sur le suivi de la couverture par rapport à un ensemble d'éléments motivants. Le compte-rendu de couverture peut se baser sur des mesures telles que 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 bien la quantité d'effort déployé pour chaque jeu d'essai.
  • L'échelle et la complexité de l'effort de test est dans une certaine mesure proportionnelle au nombre de jeux d'essai. A l'aide d'une ventilation des jeux d'essai, l'effort de test peut être calculé approximativement à un niveau de granularité plus fin.
  • Les types de conception et de développement de test et les ressources nécessaires sont régies en partie par le nombre et la complexité des jeux d'essai.

Cependant, il faut prendre en compte un certain nombre de problèmes au sujet des jeux d'essai :

  • Tous les tests ne sont pas assez complexes pour justifier le surdébit dû à la création d'un artefact de jeu d'essai devant être revu et maintenu : le test est assez simple pour qu'une courte description textuelle suffise pour exprimer les éléments requis. En fait, la majorité des jeux d'essai peut tomber dans cette catégorie. Le temps passé à documenter un grand nombre de simples jeux d'essai peut entraîner du temps perdu pour des activités de test plus importantes.
  • Certaines des idées initiales que vous avez pour les tests révèlent ensuite des défauts à certains égards. Cela signifie qu'une partie des jeux d'essai que vous avez identifié initialement en vous basant sur ces idées seront abandonnés. Cela implique que tout travail effectué pour documenter les jeux d'essai en détails sera ensuite abandonné, et tous les comptes-rendus de couverture basés sur ces jeux d'essai doivent prendre en compte cette situation. Ainsi, il peut être préférable de baser les compte-rendu de couverture de test sur des problèmes plus globaux que les jeux d'essai, et de traiter les jeux d'essai comme des artefacts d'équipe de test utilisés selon les besoins.

Les jeux d'essai sont souvent catégorisés ou classés par le type de test ou d'exigence de test auquel ils sont associés, et varieront donc en fonction de ces éléments. Une heuristique de l'identification des jeux d'essai consiste à commencer par prendre en compte les deux perspectives suivantes :

  • prouver que l'exigence a été atteinte, ce qu'on appelle souvent un jeu d'essai positif,
  • prouver que l'exigence est uniquement atteinte sous les conditions souhaitées, ce qu'on appelle un jeu d'essai négatif. Ce jeu d'essai exprime des conditions ou des données inacceptables, anormales ou inattendues auxquelles le logiciel peut raisonnablement se trouver confronté.

Obtenir des jeux d'essai à partir de cas d'utilisation Haut de la page

Les jeux d'essai pour le test fonctionnel sont obtenus à partir des cas d'utilisation de la cible du test (voir Artefact : Cas d'utilisation). Des tests d'essai doivent être développés pour chaque scénario de cas d'utilisation. Les scénarios de cas d'utilisation sont identifiés en décrivant les chemins qui traversent le flot de base et les flots alternatifs du début à la fin du cas d'utilisation.

Dans le diagramme ci-dessous, par exemple, chaque chemin différent dans un cas d'utilisation reflétant les flots de base et alternatifs est représenté avec les flèches. Le flot de base, représenté par la ligne noire droite est le chemin le plus simple à travers le cas d'utilisation. Chaque flot alternatif commence avec le flot de base puis, en dépendant d'une condition spécifique, le flot alternatif est exécuté. Les flots alternatifs peuvent rejoindre le flot de base (flots alternatifs 1 et 3), peuvent provenir d'un autre flot alternatif (flot alternatif 2), ou peuvent mettre fin au cas d'utilisation sans rejoindre un flot (flot alternatifs 2 et 4)..

Diagramme décrit dans le libellé.

Exemples de flots d'événements pour un cas d'utilisation.

En suivant chaque chemin potentiel traversant le cas d'utilisation dans le diagramme ci-dessus, les différents scénarios de cas d'utilisation peuvent être identifiés. En commençant par le flot de base puis en associant le flot de base aux flots alternatifs, les scénarios de cas d'utilisation suivants peuvent être identifiés : 

Scénario 1 Flot de base      
Scénario 2 Flot de base Flot alternatif 1    
Scénario 3 Flot de base Flot alternatif 1 Flot alternatif 2  
Scénario 4 Flot de base Flot alternatif 3    
Scénario 5 Flot de base Flot alternatif 3 Flot alternatif 1  
Scénario 6 Flot de base Flot alternatif 3 Flot alternatif 1 Flot alternatif 2
Scénario 7 Flot de base Flot alternatif 4    
Scénario 8 Flot de base Flot alternatif 3 Flot alternatif 4  

Commentaire: Pour plus de simplicité, les scénarios 5, 6 et 8 ne décrivent qu'une seule exécution de la boucle indiquée par le flot alternatif 3.    

On obtient les jeux d'essai pour chaque scénario en identifiant la condition spécifique qui entraînera l'exécution de ce scénario spécifique de cas d'utilisation.

Par exemple, supposons que le cas d'utilisation décrit dans le diagramme ci-dessus exprime les conditions suivantes pour le flot alternatif 3 :

"Ce flot d'événements a lieu si le montant en dollars saisi dans l'étape 2 ci-dessus "Saisir le montant de retrait" est supérieur au solde actuel du compte. Le système affiche un message d'alerte puis rejoint le flot de base à l'étape 2 "Saisir le montant du retrait" ci-dessus, où le client de la banque peut saisir un nouveau montant de retrait."

Avec ces informations, vous pouvez commencer à identifier les jeux d'essai nécessaires pour exécuter le flot alternatif 3:

Code jeu d'essai Scénario Condition Résultat prévu
Jeu d'essai x Scénario 4 Etape 2 - Retirer montant > Solde de compte Rejoindre flot de base à Etape 2
Jeu d'essai y Scénario 4 Etape 2 - Retirer montant < Solde de compte N'exécute pas le flot alternatif 3, prend le flot de base
Jeu d'essai z Scénario 4 Etape 2 - Retirer montant = Solde de compte N'exécute pas le flot alternatif 3, prend le flot de base

Commentaire: les jeux d'essai montrés ci-dessus sont très schématiques car aucune autre information n'a été fournie. Les jeux d'essai sont rarement aussi simples.

Vous trouverez ci-dessous un exemple plus réaliste de l'obtention de jeux d'essai à partir de cas d'utilisation :

Exemple :

Diagramme décrit dans le libellé.

Les acteurs et les cas d'utilisation dans un distributeur de billets.

Le tableau suivant contient le flot de base et quelques flots alternatifs pour le cas d'utilisation Retrait de liquide dans le diagramme ci-dessus :

Flot de base Ce cas d'utilisation commence avec le distributeur de billets dans l'état Prêt.
  1. Débuter le retrait - Le client insère la carte bancaire dans le lecteur de carte du distributeur de billets
  2. Vérifier la carte bancaire - Le distributeur lie le code compte à partir de la bande magnétique de la carte bancaire   et vérifie que la carte bancaire est acceptable.
  3. Saisir le code PIN - Le distributeur demande au client son code PIN (4 chiffres)
  4. Vérifier le code compte et le PIN - Le code compte et le PIN sont vérifiés pour déterminer si le compte est valide et si le PIN saisi est le PIN correct pour le compte. Pour ce flot, le compte est un compte valide et le PIN est le PIN correct associé à ce compte.
  5. Options distributeur - Le distributeur affiche les différentes alternatives disponibles pour ce distributeur.  Dans ce flot, le client de la banque sélectionne toujours "Retrait de liquide."
  6. Saisir le montant - Informer le distributeur du montant à retirer. Pour ce flot le client sélectionne un montant prédéfini ($10, $20, $50, ou $100).
  7. Autorisation - Le distributeur débute le processus de vérification avec le système bancaire en envoyant le code de la carte, le PIN, le montant, et les informations sur le compte en tant que transaction.  Pour ce flot, le système bancaire est en ligne et répond par l'autorisation d'effectuer le retrait de liquide et met à jour le solde du compte en conséquence.
  8. Distribution - L'argent est attribué.
  9. Retour carte - La carte bancaire est rendue.
  10. Justificatif - Le justificatif est imprimé et attribué.  Le distributeur met également à jour le journal interne en conséquence. 

Le cas d'utilisation se termine avec le distributeur de billets dans l'état Prêt.

Flot alternatif 1 - Carte non valide Dans le flot de base Etape 2 - Vérifier carte bancaire, si la carte n'est pas valide, elle est éjectée avec un message approprié.
Flot alternatif 2 - Distributeur vide  Dans le flot de base Etape 5 - Options distributeur de billets, si le distributeur de billets est vide, l'option "Retrait de liquide" ne sera pas disponible.
Flot alternatif 3 - Le distributeur ne possède pas assez de fonds  Dans le flot de base Etape 6 - Saisir le montant, si le distributeur ne possède pas assez de fonds pour fournir le montant demandé, un message approprié sera affiché, avant de rejoindre le flot de base à l'Etape 6 - Saisir montant.
Flot alternatif 4 - PIN incorrect  Dans le flot de base Etape 4 - Vérifier le compte et le PIN, le client a trois essais pour saisir le PIN correct.  

Si un PIN incorrect est saisi, le distributeur affiche le message approprié et s'il reste des essais à effectuer, ce flot rejoint le flot de base à Etape 3 - Saisir le PIN. 

Si lors de l'essai final le numéro de PIN saisi est incorrect, la carte est conservée, le distributeur retourne à l'Etat Prêt, et ce cas d'utilisation prend fin.
Flot alternatif 5 - Pas de compte  Dans le flot de base Etape 4 - Vérifier le compte et le PIN, si le système bancaire renvoie un code indiquant que le compte n'existe pas ou qu'il ne permet pas les retraits, le distributeur affiche le message approprié et rejoint le flot de base à l'étape 9 - Retour carte.
Flot alternatif 6 - Fonds insuffisants dans le compte Dans  le flot de base Etape 7 - Autorisation, le système bancaire renvoie un code indiquant que le solde du compte est inférieur au montant saisi dans le flot de base Etape 6 - Saisir montant, le distributeur affiche le message approprié et rejoint le flot de base à Etape 6 - Saisir montant.
Flot alternatif 7 - Montant maximum de retrait quotidien atteint  Dans le flot de base Etape 6 - Autorisation, le système bancaire renvoie un code indiquant que, en incluant cette demande de retrait, le client a dépassé ou va dépasser le montant maximum autorisé en 24 heures, le distributeur de billets affiche le message approprié et rejoint le flot de base à Etape 6 - Saisir le montant.
Flot alternatif x - Enregistrer l'erreur Si dans le flot de base Etape 10 - Justificatif, le journal ne peut être mis à jour, le distributeur entre dans un "mode confidentiel" dans lequel toutes les fonctions sont suspendues. Une alerte appropriée est envoyée au système bancaire pour indiquer que le distributeur a interrompu l'opération.
Flot alternatif y - Quitter Le client peut, à tout moment, décide de mettre fin à la transaction (quitter). La transaction est arrêtée et la carte est éjectée.
Flot alternatif z - "Tilt" Le distributeur contient de nombreux capteurs qui suivent différentes fonctions, comme la puissance, la pression exercée sur les différentes portes et les détecteurs de mouvements.  Chaque fois qu'un capteur est activé, un signal d'alerte est envoyé à la Police et le distributeur entre dans un "mode confidentiel" dans lequel toutes les fonctions sont arrêtées jusqu'à ce que les actions de redémarrage/ réinitialisation soient exécutées.


Dans la première itération, selon le plan d'itération, vous devez vérifier que le cas d'utilisation Retrait de liquide a été correctement implémenté. L'intégralité du cas d'utilisation n'a pas encore été implémentée, seuls les flots suivants l'ont été :

  • Flot de base - Retrait d'un montant prédéfini ($10, $20, $50, $100)
  • Flot alternatif 2 - Distributeur vide
  • Flot alternatif 3 - Fonds insuffisants dans le distributeur
  • Flot alternatif 4 - PIN incorrect
  • Flot alternatif 5 - Pas de compte / Type de compte incorrect
  • Flot alternatif 6 - Fonds insuffisants dans le compte

Les scénarios suivants peuvent être extraits de ce cas d'utilisation :

Scénario 1 - Retrait de liquide réussi Flot de base   
Scénario 2 - Distributeur vide Flot de base Flot alternatif 2
Scénario 3 - Le distributeur ne possède pas assez de fonds Flot de base Flot alternatif 3
Scénario 4 - PIN incorrect (essais restant) Flot de base Flot alternatif 4 
Scénario 5 - PIN incorrect (pas d'essai restant) Flot de base Flot alternatif 4 
Scénario 6 - Pas de compte/ type de compte incorrect Flot de base Flot alternatif 5
Scénario 7 - Solde de compte insuffisant  Flot de base Flot alternatif 6

Commentaire: Pour plus de simplicité les boucles des flots alternatifs 3 et 6 (scénarios 3 et 7) et les combinaisons de boucles n'ont pas été inclues dans le tableau ci-dessus.

Pour chacun de ces sept scénarios, des jeux d'essai doivent être identifiés. Les jeux d'essai peuvent être identifiés et gérés en utilisant des matrices ou des tables de décision. Vous trouverez ci-dessous un format commun, où chaque ligne représente un jeu d'essai individuel, et où les colonnes identifient les informations des jeux d'essai.  Dans cet exemple, pour chaque jeu d'essai, il y a un code de jeu d'essai, une condition (ou description) et tous les éléments de données participant au jeu d'essai (en tant que données d'entrée ou déjà dans la base de données), et un résultat prévu.

Pour débuter le développement de la matrice, commencez par identifier les éléments de données requises pour exécuter les scénarios de cas d'utilisation. Ensuite, pour chaque scénario, identifiez au moins un jeu d'essai qui contient la condition appropriée pour exécuter le scénario. Par exemple, dans la matrice ci-dessous, V (valide) est utilisé pour indiquer que cette condition doit être VALIDE pour que le flot de base s'exécute et I (invalide) est utilisé pour indiquer la condition qui appellera le flot alternatif souhaité. Dans le tableau ci-dessous, "n/a" indique que cette condition n'est pas applicable au jeu d'essai.

Code# jeu d'essai Scénario / Condition PIN

 

Compte #

 

Montant saisi

(ou choisi)

 

Montant dans le compte

 

Montant dans le distributeur

 

Résultat prévu
CW1. Scénario 1 - Retrait de liquide réussi V V V V V Retrait de liquide réussi.
CW2. Scénario 2 - Distributeur vide V V V V I Option retrait de liquide indisponible, fin du cas d'utilisation
CW3. Scénario 3 - Le distributeur ne possède pas assez de fonds V V V V I Message d'avertissement, retour à flot de base Etape 6 - Saisir montant
CW4. Scénario 4 - PIN incorrect (> 1 restant)

V n/a V V Message d'avertissement, retour à flot de base Etape 4 , Saisir PIN
CW5. Scénario 4 - PIN incorrect (= 1 essai restant)

V n/a V V Message d'avertissement, retour à flot de base Etape 4 , Saisir PIN
CW6. Scénario 4 - PIN incorrect (= 0  essai restant)

V n/a V V Message d'avertissement, carte conservée, fin du cas d'utilisation

Dans la matrice ci-dessus, les six jeux d'essai exécutent les quatre scénarios. Pour le flot de base, le jeu d'essai CW1 ci-dessus est appelé jeu d'essai positif. Il exécute le chemin du flot de base dans le cas d'utilisation sans déviation. Un test détaillé du flot de base doit inclure des jeux d'essai négatifs pour s'assurer que le flot de base n'est pris que lorsque les conditions sont correctes. Ces jeux d'essai négatifs sont représentés par les jeux d'essai CW2 - 6 (la cellule grise indique la condition requise pour exécuter les flots alternatifs). Si CW2 - 6 sont des jeux d'essai négatifs pour le flot de base, ils sont des flots d'essai positifs pour les flots alternatifs 2 - 4, et il y a au moins un test négatif pour chacun de ces flots alternatifs (CW1 - le flot de base).

Le scénario 4 est un exemple dans lequel il n'est pas suffisant de posséder uniquement un jeu d'essai positif et un jeu d'essai négatif par scénario. Pour tester en profondeur le Scénario 4 - PIN incorrect, il est nécessaire de posséder au moins trois jeux d'essai positifs (pour appeler le Scénario 4) :

  • le PIN incorrect est saisi, il reste des essais et ce flot alternatif rejoint le flot de base Etape 3 - Saisir PIN)
  • le PIN incorrect est saisi, il ne reste aucun essai et ce flot alternatif conserve la carte et met fin au cas d'utilisation.
  • le PIN CORRECT est saisi alors qu'il ne reste pas d'essai. Ce flot alternatif rejoint le flot de base à l'Etape 5 - Saisir le montant. 

Vous remarquerez que dans la matrice ci-dessus, aucune valeur véritable n'a été saisie pour les conditions (données). Un avantage de la création d'une matrice de jeu d'essai de cette manière est qu'il est facile de voir quelles conditions sont testées. Il est aussi très facile de déterminer si suffisamment de jeux d'essai ont été identifiés car il vous suffit de regarder les V et les I (ou, comme dans le cas présent - les cellules grises). En regardant le tableau ci-dessus, il existe plusieurs conditions pour lesquelles il n'y a pas de cellule grise, nous avons donc besoin de plus de jeux d'essai, comme pour le Scénario 6 - Pas de compte ou Type de compte incorrect et le Scénario 7 - Solde du compte insuffisant.

Une fois que suffisamment de jeux d'essai ont été identifiés, ils doivent être revus et validés pour s'assurer de l'exactitude, de la pertinence, et éliminer les doublons, les équivalents ou les jeux d'essai redondants. Voir Concepts : Liste des idées de test pour plus de détails. Voir également la section Définir les données de test pour les jeux d'essai pour plus de détails.

Code# jeu d'essai Scénario / Condition PIN

 

Compte #

 

Montant saisi

(ou choisi)

 

Montant dans le compte

 

Montant dans le distributeur

 

Résultat prévu
CW1. Scénario 1 - Retrait de liquide réussi 4987 809 - 498 50,00 500,00 2 000 Retrait de liquide réussi. Solde du compte mise à jour à 450,00
CW2. Scénario 2 - Distributeur vide 4987 809 - 498 100,00 500,00 0,00 Option retrait de liquide indisponible, fin du cas d'utilisation
CW3. Scénario 3 - Le distributeur ne possède pas assez de fonds 4987 809 - 498 100,00 500,00 70,00 Message d'avertissement, retour à flot de base Etape 6 - Saisir montant
CW4. Scénario 4 - PIN incorrect (> 1 restant) 4978 

809 - 498 n/a 500,00 2 000 Message d'avertissement, retour à flot de base Etape 4 , Saisir PIN
CW5. Scénario 4 - PIN incorrect (= 1 essai restant) 4978

809 - 498 n/a 500,00 2 000 Message d'avertissement, retour à flot de base Etape 4 , Saisir PIN
CW6. Scénario 4 - PIN incorrect (= 0  essai restant) 4978 

809 - 498 n/a 500,00 2 000 Message d'avertissement, carte conservée, fin du cas d'utilisation

Les jeux d'essai ci-dessus sont quelques uns des jeux d'essai nécessaires pour vérifier le cas d'utilisation Retrait de liquide pour cette itération. D'autres jeux d'essai nécessaires incluent :

  • Scénario 6 - Pas de compte ou type de compte incorrect : Compte non trouvé ou non disponible
  • Scénario 6 - Pas de compte ou type de compte incorrect : Le compte n'autorise pas les retraits
  • Scénario 7 - Solde de compte insuffisant : Montant demandé supérieur au montant du compte.

Dans les itérations futures, lorsque d'autres flots sont implémentés, des jeux d'essai seront nécessaires pour :

  • Cartes non-valides (carte déclarée perdue, volée, ne vient pas d'une banque acceptée, une de ses pistes est abîmée, etc.)
  • Lecture de la carte impossible (le lecteur de carte est bloqué, déconnecté ou ne fonctionne pas bien)
  • Le compte est fermé, gelé ou indisponible
  • Le montant contenu dans le distributeur n'est pas suffisant ou il est impossible de créer le montant demandé (différent de CW3 dans le sens où une dénomination est indisponible, mais pas l'intégralité)
  • Impossible de contacter le système bancaire pour approbation
  • Le réseau bancaire se déconnecte, ou une coupure de courant a lieu pendant la transaction

Lors de l'identification des jeux d'essai fonctionnels, assurez-vous des points suivants :

  • suffisamment de jeux d'essai, positifs et négatifs, ont été identifiés pour chaque scénario de cas d'utilisation 
  • les jeux d'essai traitent de toutes les règles métier implémentées par le cas d'utilisation en s'assurant qu'il y a des jeux d'essai à l'intérieur, à l'extérieur et à la condition/ valeur frontière pour la règle métier
  • les jeux d'essai traitent de tout séquencement d'événements ou d'actions, comme ceux identifiés dans le diagramme de fonctionnement du modèle de conception, ou les états ou conditions d'objet d'interface.
  • les jeux d'essai traitent de toutes les exigences spécifiques définies pour le cas d'utilisation, comme la performance minimum/ maximum, parfois combinée à des chargements ou à des volumes de données minimum/ maximum pendant l'exécution des cas d'utilisation.

Voir la section Définir les données de test pour les jeux d'essai pour plus de conseils.

Obtenir des jeux d'essai à partir de spécifications supplémentaires Haut de la page

Toutes les exigences pour une cible de test ne seront pas décrites dans les artefacts d'exigences fonctionnelles comme les spécifications de cas d'utilisation. Les exigences non fonctionnelles, comme la performance, la sécurité et l'accès, et les exigences de configuration spécifient les comportements ou les caractéristiques supplémentaires de la cible du test, et sont souvent documentées indépendamment des exigences fonctionnelles. La spécification supplémentaire est l'une des sources principales permettant d'obtenir des jeux d'essai à partir de ces exigences supplémentaires.

Vous trouverez ci-dessous des recommandations pour obtenir ces jeux d'essai supplémentaires :

Obtenir des jeux d'essai pour des tests de performance Haut de la page

Les principales données d'entrée pour les jeux d'essai de performance sont les spécifications supplémentaires qui contiennent les exigences non-fonctionnelles (voir Artefact : Spécifications supplémentaires). Utilisez les recommandations suivantes lorsque vous obtenez des jeux d'essai pour les tests de performance :

  • assurez-vous qu'au moins un jeu d'essai est identifié pour chaque déclaration de la spécification supplémentaire évoquant un critère de performance. Les critères de performance sont généralement exprimés comme durée par transaction, nombre de transactions/ utilisateurs, ou centiles.
  • assurez-vous qu'au moins un jeu d'essai est identifié pour chaque cas d'utilisation crucial. Les cas d'utilisation cruciaux sont ceux qui sont identifiés dans les déclarations ci-dessus et/ou dans le document d'analyse de la charge de travail qui doit être évalué en utilisant des mesures de performance.

Comme pour les jeux d'essai pour les tests fonctionnels, il y aura généralement plus d'un jeu d'essai par scénario ou exigence utilisé. Il est courant de définir de multiples jeux d'essai - par exemple, un se trouvant sous la valeur du seuil de performance (taux de transaction moyen), un autre au niveau du seuil (taux de transaction élevé), et un troisième jeu d'essai au-dessus de la valeur seuil (taux de transaction record).

Outre les critères de performance ci-dessus, assurez-vous que vous identifiez les conditions spécifiques qui influencent les temps de réponse, y compris :

  • Taille de la base de données - comment y a-t-il d'enregistrements ?
  • Charge de travail - patterns de transaction :
    • type, nombre et fréquence d'actions simultanées des utilisateurs finaux,
    • type, nombre, fréquence et durée des transactions simultanées effectuées
  • Caractéristiques de l'environnement (configuration matériel, netware, logiciel

Une pratique commune consiste à consigner des jeux d'essai pour les tests de performances dans des matrices tabulaires similaires à celles utilisées pour le test de fonction.

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

Voici quelques exemples des différents types de tests de performance :

Pour le test de chargement :

Code# jeu d'essai Charge de travail Condition Résultat prévu
PCW1.

1

(un seul distributeur)

Transaction de retrait complète

Transaction complète (calendrier ne dépendant pas de l'acteur) a lieu < 20 secondes
PCW2.

2

(1 000 distributeurs simultanément)

Transaction de retrait complète

Transaction complète (calendrier ne dépendant pas de l'acteur) a lieu < 30 secondes
PCW3.

3

(10 000 distributeurs simultanément)

Transaction de retrait complète

Transaction complète (calendrier ne dépendant pas de l'acteur) a lieu < 50 secondes

Pour le test de stress :

Code# jeu d'essai Charge de travail Condition Résultat prévu
SCW1.

2

(1 000 distributeurs simultanément)

Verrouillage base de données - 2 distributeurs demandant le même compte

Demandes distributeur mises en attente
SCW2.

2

(1 000 distributeurs simultanément)

Communication système bancaire non disponible

Transaction est mise en attente ou devient inactive
SCW3.

2

(1 000 distributeurs simultanément)

Communication système bancaire est interrompue pendant la transaction

Message d'alerte affiché

Obtenir des jeux d'essai pour des tests de sécurité/ accès Haut de la page

Les acteurs et les cas d'utilisation décrivent l'interaction entre les utilisateurs externes du système et les actions effectuées par le système pour fournir une valeur à un acteur spécifique. Les systèmes complexes comportent de nombreux acteurs et il est crucial que nous développions des jeux d'essai pour nous assurer que seuls les acteurs devant exécuter les cas d'utilisation peuvent le faire. C'est particulièrement vrai s'il y a des différences dans le flot d'événements du cas d'utilisation selon le type d'acteur.

Par exemple, dans les cas d'utilisation du distributeur, divers flots d'événements de cas d'utilisation peuvent être exécutés pour l'acteur "client de la banque" si leur carte et leur compte viennent de la banque propriétaire du distributeur par rapport à un "client de la banque" qui utilise une carte bancaire (et un compte) d'une banque concurrente, ou tente d'utiliser une carte bancaire non-participante.

Suivez les mêmes conseils que pour les jeux d'essai fonctionnels.

Voir la section Définir les données de test pour les jeux d'essai pour plus de conseils.

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

Code# jeu d'essai Condition Carte

(V indique que la carte est valide)

Lecteur de carte

(V indique que le lecteur de carte fonctionne correctement)

Réseau de la banque Résultat prévu
ACW1. Dans le réseau bancaire V V V Tous les cas d'utilisation disponibles
ACW2. En dehors du réseau bancaire V V I Cas d'utilisation retrait de liquide seulement
ACW3. Impossible de lire la carte I V V Message d'alerte, carte éjectée
ACW4. Carte déclarée volée I V V Message d'alerte, carte conservée
ACW5. Carte à expiration I V V Message d'alerte, carte conservée

Obtenir des jeux d'essai pour les tests de configuration Haut de la page

Généralement, dans les systèmes répartis de nombreuses combinaisons autorisées de matériel et de logiciel peuvent être prises en charge. Un test doit être effectué pour vérifier que la cible du test fonctionne ou s'effectue de façon acceptable dans diverses configurations, comme différents systèmes d'exploitations, navigateurs ou vitesse d'unité centrale. De plus, le test doit également couvrir des combinaisons de composants pour découvrir des défauts venant de l'interaction entre différents composants, par exemple, en s'assurant que la version de la bibliothèque de liens dynamiques installée par une application n'entre pas en conflit avec les versions des mêmes bibliothèques de liens dynamiques prévues par une autre application.

Pour obtenir des jeux d'essai pour le test de configuration, utilisez les recommandations suivantes :

  • Assurez-vous qu'il y ait au moins un jeu d'essai identifiant chaque configuration cruciale. Cette action est effectuée en identifiant les configurations matériel et logiciel requises pour l'environnement de la cible de test et en hiérarchisant les configurations, en s'assurant que les plus répandues sont testées en premier :
    • Support imprimante
    • Connections réseau - réseaux local et étendu
    • Configurations serveur - pilotes serveur, matériel serveur
    • Autres logiciels installés sur le bureau et/ou sur les serveurs
    • Versions logicielles pour tous les logiciels installés
  • Assurez-vous qu'il y ait au moins un jeu d'essai pour chaque configuration pouvant poser problème. Cela peut comprendre ce qui suit :
    • Matériel avec une performance très faible.
    • Logiciel co-résident ayant un passé de problèmes de compatibilité.
    • Clients accédant au serveur avec la connexion LAN/VAN la plus basse.
    • Ressources insuffisantes (unité centrale très lente, résolution ou mémoire minimum, espace disque, etc.)

Obtenir des jeux d'essai pour les tests d'installation Haut de la page

Le test d'installation doit vérifier que la cible de test peut être installée sous tous les scénarios d'installation possibles. Les scénarios d'installation peuvent comporter l'installation de la cible de test pour la première fois, ou l'installation d'une version ou d'une construction plus récente de la cible de test (dans un ordinateur contenant la version plus ancienne). Le test d'installation doit également s'assurer que la cible de test fonctionne de façon acceptable dans des conditions anormales, comme un espace disque insuffisant.

Les jeux d'essai doivent couvrir les scénarios d'installation pour le logiciel y compris :

  • Moyen de distribution, par exemple, disquettes, CD-ROM ou serveur de fichiers.
  • Nouvelle installation.
  • Installation complète.
  • Installation personnalisée.
  • Installations de mise à jour.

Les programmes d'installation pour les logiciels client-serveur possèdent un ensemble spécialisé de jeux d'essai. Contrairement aux systèmes gérés par l'ordinateur central, le programme d'installation est généralement divisé entre le serveur et le client. Pour cette raison, il est important que le test d'installation effectue l'installation de tous les composants de la cible de test, y compris le client, les éléments intermédiaires, et les serveurs.

Obtenir des jeux d'essai pour d'autres tests non-fonctionnels Haut de la page

Idéalement, vous devez trouver toutes les données nécessaires pour obtenir des jeux d'essai dans le modèle de cas d'utilisation, le modèle de conception, et les artefacts de spécification supplémentaires. Assez souvent, cependant, vous devrez compléter ce qui est disponible.

Voici quelques exemples :

  • Jeux d'essai pour les tests opérationnels (pour vérifier que le logiciel fonctionne lorsqu'il est utilisé pendant une "longue période" entre deux échecs).
  • Jeux d'essai qui examinent les goulots d'étranglement de performance, les capacités du système en terme de volume, ou mettent la cible de test en condition d'échec.

Dans la majorité des cas, vous pouvez trouver ces jeux d'essai en créant des variantes ou des agrégats des jeux d'essai que vous avez obtenus à partir de ceux que vous avez identifiés précédemment.

Obtenir des jeux d'essai pour les tests d'acceptation des produits Haut de la page

Le test d'acceptation du produit est la dernière action de test avant le déploiement du logiciel. L'objectif du test d'acceptation est de vérifier que le logiciel est prêt et peut être utilisé par les utilisateurs finaux pour effectuer les fonctions et les tâches pour lesquels le logiciel a été créé. Le test d'acceptation du produit implique souvent plus que l'exécution du logiciel pour s'assurer qu'il est prêt, il s'agit également de livrer tous les artefacts de produit au(x) client(s), comme la formation, la documentation et l'emballage.  

On obtient les jeux d'essai pour le(s) artefact(s) logiciel comme nous le décrivons dans les sections ci-dessus. Selon le degré et la formalité du test d'acceptation du produit, les jeux d'essai seront soit identiques soit similaires à ceux identifiés ci-dessus (formel) ou un sous-ensemble (informel). Indépendamment de la profondeur des jeux d'essai, un accord au sujet des jeux d'essai et des critères d'acceptation du produit doit être trouvé avant l'implémentation et l'exécution du test de produit.

L'évaluation du ou des artefact(s) non-logiciel(s) varie énormément selon l'artefact évalué. Consultez les recommandations et les listes de contrôle pour chaque artefact non-logiciel spécifique pour obtenir des informations au sujet de ce qui doit être évalué et comment.

Construire les jeux d'essai de vérification pour les tests de régression. Haut de la page

Le test de régression compare deux constructions ou versions de la même cible de test et identifie les différences comme des défauts potentiels. Il suppose ainsi qu'une nouvelle version doit se comporter comme une ancienne et s'assure qu'aucun défaut n'a été introduit à la suite des changements.

Idéalement, tous les jeux d'essai d'une itération doivent être utilisés en tant que jeu d'essai dans les itérations ultérieures. Les recommandations suivantes doivent être utilisées pour identifier, concevoir, et implémenter les jeux d'essai qui maximisent la valeur du test de régression et de la réutilisation, tout en minimisant la maintenance :

  • Assurez-vous que le jeu d'essai n'identifie que les éléments de données cruciaux (nécessaires pour créer/ prendre en charge la condition testée
  • Assurez-vous que chaque jeu d'essai décrit ou représente un ensemble unique de données ou de séquence d'événements qui entraîne un comportement unique de la cible de test
  • Eliminez les jeux d'essai redondants ou équivalents
  • Regroupez les jeux d'essai qui possèdent le même état initial de la cible de test et le même état des données de test

Définir les données de test pour les jeux d'essai Haut de la page

Une fois que les jeux d'essai ont été examinés et qu'une approbation/ un accord général a été obtenu à leur propos, les véritables valeurs de données peuvent être identifiées avec plus de détails (par exemple dans la matrice d'implémentation du jeu d'essai) et les artefacts de données de test peuvent être créés.



RUP (Rational Unified Process)   2003.06.15