Techniques de test de logiciels avec des exemples de conception de cas de test
Thomas Hamilton
Qu’est-ce que la technique de test logiciel ?
Les techniques de test de logiciels vous aident à concevoir de meilleurs cas de test. Puisque des tests exhaustifs ne sont pas possibles ; Les techniques de tests manuels aident à réduire le nombre de cas de test à exécuter tout en augmentant la couverture des tests. Ils aident à identifier les conditions de test qui seraient autrement difficiles à reconnaître.
Analyse des valeurs limites (BVA)
L'analyse des valeurs limites est basée sur des tests aux limites entre les partitions. Il comprend les limites maximales, minimales, intérieures ou extérieures, les valeurs typiques et les valeurs d'erreur.
On constate généralement qu'un grand nombre d'erreurs se produisent aux limites des valeurs d'entrée définies plutôt qu'au centre. Il est également connu sous le nom de BVA et propose une sélection de cas de test qui exercent des valeurs limites.
Cette technique de test en boîte noire complète le partitionnement d’équivalence. Cette technique de test logiciel repose sur le principe selon lequel, si un système fonctionne bien pour ces valeurs particulières, il fonctionnera parfaitement bien pour toutes les valeurs comprises entre les deux valeurs limites.
Lignes directrices pour l’analyse des valeurs limites
- Si une condition d'entrée est limitée entre les valeurs x et y, alors les cas de test doivent être conçus avec des valeurs x et y ainsi que des valeurs supérieures et inférieures à x et y.
- Si une condition d'entrée est un grand nombre de valeurs, le scénario de test doit être développé qui doit utiliser les nombres minimum et maximum. Ici, les valeurs supérieures et inférieures aux valeurs minimales et maximales sont également testées.
- Appliquez les directives 1 et 2 aux conditions de sortie. Il donne une sortie qui reflète les valeurs minimales et maximales attendues. Il teste également les valeurs inférieures ou supérieures.
Mise en situation :
Input condition is valid between 1 to 10 Boundary values 0,1,2 and 9,10,11
Partitionnement de classe d'équivalence
Le partitionnement de classe équivalente vous permet de diviser un ensemble de conditions de test en une partition qui doit être considérée comme identique. Cette méthode de test logiciel divise le domaine d'entrée d'un programme en classes de données à partir desquelles les cas de test doivent être conçus.
Le concept derrière cette technique de conception de cas de test est que le cas de test d'une valeur représentative de chaque classe est égal à un test de toute autre valeur de la même classe. Il vous permet d'identifier les classes d'équivalence valides et invalides.
Mise en situation :
Les conditions de saisie sont valables entre
1 to 10 and 20 to 30
Il existe donc cinq classes d'équivalence
--- to 0 (invalid) 1 to 10 (valid) 11 to 19 (invalid) 20 to 30 (valid) 31 to --- (invalid)
Vous sélectionnez des valeurs dans chaque classe, c'est-à-dire
-2, 3, 15, 25, 45
En savoir plus également sur – Analyse des valeurs limites et tests de partitionnement d'équivalence
Tests basés sur des tables de décision
Une table de décision est également connue sous le nom de table cause-effet. Cette technique de test logiciel est utilisée pour les fonctions qui répondent à une combinaison d'entrées ou d'événements. Par exemple, un bouton de soumission doit être activé si l'utilisateur a renseigné tous les champs obligatoires.
La première tâche consiste à identifier les fonctionnalités dont le résultat dépend d’une combinaison d’entrées. S'il existe un grand ensemble de combinaisons d'entrée, divisez-le en sous-ensembles plus petits qui sont utiles pour gérer une table de décision.
Pour chaque fonction, vous devez créer un tableau et répertorier tous les types de combinaisons d'entrées et leurs sorties respectives. Cela permet d'identifier une condition négligée par le testeur.
Voici les étapes pour créer une table de décision :- Répertorier les entrées dans les lignes
- Entrez toutes les règles dans la colonne
- Remplissez le tableau avec les différentes combinaisons d'entrées
- Dans la dernière ligne, notez la sortie par rapport à la combinaison d'entrée.
Exemple: Un bouton de soumission dans un formulaire de contact est activé uniquement lorsque toutes les entrées sont saisies par l'utilisateur final.
Transition d'état
Dans la technique de transition d'état, les modifications des conditions d'entrée modifient l'état de l'application sous test (AUT). Cette technique de test permet au testeur de tester le comportement d'un AUT. Le testeur peut effectuer cette action en saisissant diverses conditions d’entrée dans une séquence. Dans la technique de transition d'état, l'équipe de test fournit des valeurs de test d'entrée positives et négatives pour évaluer le comportement du système.
Ligne directrice pour la transition de l'État :
- La transition d'état doit être utilisée lorsqu'une équipe de test teste l'application pour un ensemble limité de valeurs d'entrée.
- La technique de conception de cas de test doit être utilisée lorsque l'équipe de test souhaite tester une séquence d'événements qui se produisent dans l'application testée.
Mise en situation :
Dans l'exemple suivant, si l'utilisateur saisit un mot de passe valide lors de l'une des trois premières tentatives, il pourra se connecter avec succès. Si l'utilisateur saisit un mot de passe invalide lors du premier ou du deuxième essai, il sera invité à saisir à nouveau le mot de passe. Lorsque l'utilisateur saisit un mot de passe incorrect 3rd temps, l'action a été entreprise et le compte sera bloqué.
Diagramme de transition d'état
Dans ce diagramme, lorsque l'utilisateur donne le code PIN correct, il passe à l'état Accès accordé. Le tableau suivant est créé sur la base du diagramme ci-dessus.
Tableau de transition d'état
| Corriger le code PIN | NIP incorrect | |
|---|---|---|
| S1) Démarrer | S5 | S2 |
| S2)1st tentative | S5 | S3 |
| S3)2nd tentative | S5 | S4 |
| S4)3rd tentative | S5 | S6 |
| S5) Accès accordé | - | - |
| S6) Compte bloqué | - | - |
Dans le tableau ci-dessus, lorsque l'utilisateur saisit le code PIN correct, l'état passe à Accès accordé. Et si l'utilisateur saisit un mot de passe incorrect, il passe à l'état suivant. S'il fait la même chose 3rd temps, il atteindra l’état de compte bloqué.
Erreur de devinette
Erreur de devinette est une technique de test de logiciels basée sur la prédiction de l'erreur qui peut prévaloir dans le code. La technique est fortement basée sur l'expérience dans laquelle les analystes de tests utilisent leur expérience pour deviner la partie problématique de l'application de test. Par conséquent, les analystes de test doivent être compétents et expérimentés pour mieux deviner les erreurs.
La technique compte une liste d'erreurs possibles ou de situations sujettes aux erreurs. Ensuite, le testeur écrit un cas de test pour exposer ces erreurs. Pour concevoir des cas de test basés sur cette technique de test logiciel, l'analyste peut utiliser les expériences passées pour identifier les conditions.
Lignes directrices pour deviner les erreurs :
- Le test doit utiliser l'expérience antérieure de test d'applications similaires
- Compréhension du système testé
- Connaissance des erreurs typiques de mise en œuvre
- Rappelez-vous les zones précédemment en difficulté
- Évaluer les données historiques et les résultats des tests
Pour aller plus loin
- La technique de conception de cas de test vous permet de concevoir de meilleurs cas. Il existe cinq techniques principalement utilisées.
- L'analyse des valeurs limites consiste à tester les limites entre les partitions.
- Le partitionnement de classe équivalente vous permet de diviser un ensemble de conditions de test en une partition qui doit être considérée comme identique.
- La technique de test du logiciel Decision Table est utilisée pour les fonctions qui répondent à une combinaison d’entrées ou d’événements.
- Dans la technique de transition d'état, les changements dans les conditions d'entrée modifient l'état de l'application sous test (AUT)
- La recherche d'erreurs est une technique de test de logiciels qui consiste à deviner l'erreur qui peut prévaloir dans le code.
