Principes et conseils :
|
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 :
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.
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) | I
|
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) | I
|
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) | I
|
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) :
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 :
Dans les itérations futures, lorsque d'autres flots sont implémentés, des jeux d'essai seront nécessaires pour :
Lors de l'identification des jeux d'essai fonctionnels, assurez-vous des points suivants :
Voir la section Définir les données de test pour les jeux d'essai pour plus de conseils.
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 :
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 :
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 :
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é |
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 |
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 :
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 :
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.
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 :
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.
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.
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 :
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)
|