La rédaction de cas de test est la compétence de base des tests de logiciels; de nombreuses personnes pensent que les cas de test sont au cœur des tests de logiciels; la chose la plus importante dans les tests de logiciels est de concevoir et de générer des cas de test efficaces; les cas de test sont des conseils pour le travail de test et sont nécessaires pour les tests de logiciels Directives à suivre.
Ici, nous ne discuterons pas des différents points de vue ci-dessus, mais en résumé, vous pouvez voir que la compétence douce de la rédaction de cas de test est très importante et une compétence nécessaire pour les testeurs.Je pense que beaucoup de gens n'ont aucun doute.
Ci-dessous, nous présentons l'écriture de cas de test.
Nous divisons l'écriture de cas d'utilisation en deux catégories: l'écriture de cas d'utilisation en boîte noire et l'écriture de cas d'utilisation en boîte blanche.
L'idée générale d'écrire le titre:
Cas de test boîte noire (priorité) + cas de test boîte blanche (supplémentaire) = scénario de test complet
Stratégie globale de rédaction:
Pour l'écriture de cas de test, les quatre méthodes couramment utilisées sont fondamentalement suffisantes, classe d'équivalence, valeur limite, méthode d'expérience orthogonale, méthode d'inférence d'erreur, complétées par une méthode de test de scénario, une méthode de conversion demande / conception et des idées de test exploratoire , Peut gérer le test de la plupart des produits. Les produits individuels doivent également être raffinés et développés à un moment donné, et doivent être discutés à ce sujet.
Stratégie de conception complète utilisant diverses méthodes d'écriture;
1) La méthode d'analyse des valeurs limites doit être utilisée dans toutes les situations L'expérience montre que l'utilisation de cette méthode pour concevoir des cas de test a la plus grande capacité à détecter les erreurs de programme.
2) Utiliser des méthodes de division de classe d'équivalence pour compléter certains cas de test si nécessaire, en accordant une attention particulière aux classes d'équivalence invalides.
3) Si la description de fonction du programme contient une combinaison de conditions d'entrée, la méthode du diagramme de causalité (ou méthode de table de jugement, méthode de test orthogonal) peut être sélectionnée depuis le début.
4) Utilisez la spéculation d'erreur pour ajouter des cas de test, principalement en utilisant l'expérience de test.
5) Vérifiez la couverture logique des cas de test conçus par rapport à la logique du programme. Si les normes de couverture requises ne sont pas respectées, des cas de test suffisants doivent être ajoutés; reportez-vous à la préparation des cas d'utilisation de la boîte blanche.
6) Recherchez et réfléchissez aux scénarios d'application du programme, et ajoutez des cas de test dans différents scénarios; les tests de scénario utilisateur doivent être pris en compte. Une grande partie des erreurs du programme sont causées par la différence entre le scénario de test et le scénario réel de l'utilisateur.
7) Après avoir une compréhension plus approfondie des activités et des procédures, vous pouvez jouer pleinement sur la pensée divergente et la pensée exploratoire; ne pas confondre les tests exploratoires comme des tests sans but. En fait, les tests exploratoires ont des idées de conseils de test très détaillées.
Partie 1: Écriture de cas d'utilisation de boîte noire
Les méthodes courantes sont les suivantes:
(1) Classe d'équivalence
(2) Valeur limite
(3) Diagramme de cause à effet
(4) Méthode basée sur la table de décision
(5) Méthode d'expérimentation orthogonale
(6) Méthode de la carte des fonctions
(7) Méthode d'expérience de scène
(8) Méthode d'inférence d'erreur
(9) Transformation de la demande
(10) Documents de conception
(11) Essais exploratoires
1. Équivalent boîte noire
Classe d'équivalence: sélectionnez quelques données représentatives, ce type de données est équivalent à d'autres valeurs de ce type, trouvez le plus petit sous-ensemble, vous pouvez trouver le plus d'erreurs;
Deux caractéristiques majeures: les cas d'utilisation qui doivent être conçus, couvrent la plupart des cas;
Deux types de situations: classe d'équivalence effective, classe d'équivalence invalide;
Converti en cas de test
1. Établir une liste des classes d'équivalence en fonction des conditions d'entrée, des classes d'équivalence valides et des classes d'équivalence invalides, et lister toutes les classes d'équivalence;
2. Fixez un numéro pour chaque classe d'équivalence;
3. Concevoir un scénario de test pour couvrir une ou plusieurs classes d'équivalence effectives;
4. Concevoir un ou plusieurs cas de test pour couvrir les classes d'équivalence effectives restantes;
Scénario d'utilisation: conditions d'entrée (plage de valeurs / nombre de valeurs; valeur doit être définie; valeur booléenne; un ensemble de valeurs de traitement; règles à suivre; subdiviser les classes d'équivalence plus petites;)
Exemples de classes d'équivalence:
Prenez le test du triangle comme exemple: entrez 3 entiers comme les trois côtés du triangle et déterminez le type du triangle à travers le programme.
2. Valeur limite de la boîte noire
Valeur limite: la condition dite aux limites fait référence aux états des classes d'équivalence d'entrée et de sortie qui sont exactement à la limite, dépassent la limite ou en dessous de la limite;
Deux caractéristiques: sélectionnez un ou plusieurs éléments pour que chaque limite de la classe d'équivalence ait été testée; au lieu de vous concentrer uniquement sur les conditions d'entrée, vous devez également prendre en compte l'espace de résultat (classe d'équivalence en sortie) pour concevoir des cas de test;
Les conditions aux limites peuvent être très délicates, il faut donc beaucoup d'efforts pour les déterminer;
Scénario d'utilisation: les entrées + sorties doivent être prises en compte (plage de valeurs; nombre de valeurs; ensemble ordonné; structure de données interne; spécifications d'analyse;)
Exemples de valeurs limites:
Prenez le test du triangle comme exemple: entrez 3 entiers comme les trois côtés du triangle, 1 <a, b, c <10, et déterminez le type de triangle à travers le programme;
3. Diagramme de cause à effet boîte noire
Diagramme de cause à effet: saisissez une combinaison de conditions pour l'analyse. Utiliser une méthode systématique pour sélectionner un ensemble efficace de cas de test;
analyse d'idée:
1. Analyser la description de la spécification, déterminer la cause et le résultat, et attribuer un identifiant;
2. Analyser la sémantique de la spécification, découvrir la relation entre cause et cause, et entre cause et effet, et dessiner un diagramme de cause à effet;
3. La combinaison de certaines causes et causes, ou entre les causes et les résultats n'apparaîtra pas. Utilisez des signes pour indiquer des contraintes ou des conditions restrictives;
4. Le diagramme de cause à effet est converti en un tableau de jugement;
5. Concevoir des cas de test basés sur chaque colonne du tableau de jugement;
Scénario d'utilisation: diverses combinaisons de conditions d'entrée doivent être envisagées (une forme appropriée pour décrire une combinaison de conditions multiples et générer en conséquence plusieurs actions pour la conception);
4. Tableau de jugement de la boîte noire
Tableau de jugement: un outil pour analyser et exprimer la situation de l'exécution de différentes opérations dans des conditions logiques multiples; sauter le dessin du diagramme de cause à effet, et lister directement toutes les combinaisons pour le dépistage;
Idée d'analyse: la table de décision se compose généralement de quatre parties: pile de conditions, pile d'actions, élément de condition et élément d'action;
Étapes pour établir la table de jugement: (selon la spécification du logiciel)
Déterminer le nombre de règles; lister toutes les conditions et les enjeux d'action; remplir les éléments de condition; remplir les éléments d'action pour obtenir le tableau de jugement initial; simplifier et fusionner les règles similaires;
== Utilisez le scénario: contrôlez les classes et les jeux. L'avantage est que les problèmes complexes peuvent être répertoriés un par un selon diverses situations possibles, concis et faciles à comprendre, et les omissions peuvent également être évitées. L'inconvénient est qu'il ne peut pas exprimer des actions répétées, telles que des structures de boucle.
5. Méthode d'essai orthogonale en boîte noire
Méthode d'expérimentation orthogonale: lorsque vous utilisez des diagrammes de causalité pour concevoir des cas de test, la relation causale entre les raisons d'entrée et les résultats de sortie est parfois difficile à obtenir à partir de la spécification des exigences logicielles; souvent la relation de causalité est si énorme que le nombre de cas de test est énorme. Pour réduire efficacement et raisonnablement les heures de travail et les coûts de test, des méthodes de conception expérimentale orthogonale peuvent être utilisées pour concevoir des cas de test.
analyse d'idée:
(1) Extraire la description de la fonction, le tableau des états des facteurs de structure;
(2) dépistage pondéré, générant un tableau d'analyse factorielle;
(3) Utilisez la table orthogonale pour construire l'ensemble de données de test;
Scénario d'utilisation: diverses combinaisons de conditions d'entrée doivent être envisagées (choisir des points appropriés et représentatifs à partir d'une grande quantité de données, tests raisonnables et efficaces);
6. Méthode d’expérimentation en boîte noire
Méthode d'expérimentation de scène: le logiciel est presque toujours déclenché par un événement pour contrôler le processus. La scène au moment où l'événement est déclenché forme une scène, et différentes séquences de déclenchement et résultats de traitement du même événement forment un flux d'événements; dépeignez de manière vivante la scène lorsque l'événement est déclenché. Propice à la conception de cas d'utilisation, et les cas de test sont plus faciles à comprendre et à exécuter.
analyse d'idée:
Chaque chemin reflète le flux de base et le flux alternatif; le flux de base est le chemin le plus simple; le flux alternatif part du flux de base et sera ajouté et exécuté dans certaines conditions. Il peut y avoir de nombreuses situations;
Scénario d'utilisation (0 signifie débit de base): 0; 0 + 1; 0 + 1 + 2; 0 + 3; 0 + 3 + 1; 0 + 3 + 1 + 2; 0 + 4; 0 + 3 + 4; ...
7. Méthode d'inférence d'erreur
Méthode d'inférence d'erreur: basée sur l'expérience et l'intuition pour inférer toutes les erreurs possibles dans le programme, afin de concevoir des cas de test de manière ciblée; elle est principalement basée sur les habitudes de l'utilisateur et les problèmes courants dans le programme de test.
analyse d'idée:
(1) Énumérez toutes les erreurs possibles dans le programme et les situations spéciales qui sont sujettes à des erreurs, et sélectionnez des cas de test en fonction de ces situations;
(2) Faites attention à l'accumulation et au partage;
Scénario d'utilisation: une méthode qui sera utilisée dans n'importe quel test et dans n'importe quel scénario.
Il existe un ensemble de cas de test couramment utilisés pour référence.
Exemple: vérification d'entrée numérique, nombres d'entrée (nombre positif, nombre négatif, valeur zéro, simple précision, double précision), chaîne, valeur vide, valeur nulle, valeur critique respectivement; pour une entrée illégale, le système donnera les informations d'invite de jugement nécessaires ；
8. Méthode de conversion boîte noire-demande
Méthode de transformation des exigences: selon les exigences, effectuer une analyse des exigences et rédiger des cas de test.
analyse d'idée:
(1) Convertir la demande en carte mentale;
(2) Examinez attentivement le sens de chaque mot;
(3) Combiner avec les scénarios d'utilisation et les objectifs de l'utilisateur;
(4) Concevoir strictement chaque cas d'utilisation;
(5) Un modèle peut être établi pour la conversion de la demande;
Scénario d'utilisation: une méthode qui sera utilisée dans n'importe quel test et dans n'importe quel scénario.
Remarque: l'impact des changements dans les exigences, l'impact des écarts dans la compréhension des exigences, l'impact des ambiguïtés dans les exigences, etc.
9. Document de conception de boîte noire
Document de conception: se référer au document de conception, peut comprendre le processus de conception interne et le mécanisme de traitement du système logiciel, comparer les cas de test écrits et ajouter les fonctions et modules correspondants;
analyse d'idée:
(1) Lisez attentivement les documents de conception;
(2) Communiquer avec le personnel concerné pour réaliser le mécanisme;
(3) Combinez la méthode d'écriture de cas de test et comparez les cas d'utilisation précédemment écrits;
Scénario d'utilisation: une méthode qui sera utilisée dans n'importe quel test et dans n'importe quel scénario.
Remarque: l'exactitude de la documentation de conception, la déviation de la compréhension de la documentation de conception;
10. Méthode d'essai exploratoire de la boîte noire
Méthode de test exploratoire: points de test avec une créativité infinie, des tests exploratoires sans fin; nous devons utiliser des mesures de perspicacité, de technologie et de contingence à la pointe des tests pour trouver les défauts du produit;
analyse d'idée:
Essais exploratoires locaux, essais exploratoires mondiaux, essais exploratoires mixtes;
Scénario d'utilisation: une méthode qui sera utilisée dans n'importe quel test et dans n'importe quel scénario. Tout comme l'itinérance, la recherche libre de défauts dans les logiciels, l'avenir des tests logiciels doit passer par des tests exploratoires.
Partie 2: Rédaction de cas d'utilisation de boîte blanche
L'idée de base:
La première étape consiste à dessiner un organigramme;
La deuxième étape consiste à déterminer le cas de test selon la méthode d'analyse de chemin;
La troisième étape utilise la méthode de classe d'équivalence / valeur limite pour déterminer les données du cas de test
La quatrième étape est complétée en fonction de la situation réelle (comme le processus par défaut, le processus spécial, etc.)
Stratégie de base:
1. Le critère de couverture de déclaration est fondamentalement inutile. Le critère de couverture logique le plus fort est la couverture de jugement ou la couverture de condition, généralement la couverture de jugement peut satisfaire la couverture de déclaration, la couverture de déclaration <couverture de jugement <couverture de condition;
2. En termes de couverture de boucle, le test de chemin complet n'est pas conforme à la réalité;