--Erreurs courantes
C'est un type qui crée beaucoup de cas de test sans signification car il me fait penser que "toutes les combinaisons doivent être couvertes". Comme le montre l'exemple précédent, le nombre de combinaisons devient rapidement astronomique.
C'est un type qui n'a pas assez de tests pour les modèles anormaux tels que "lorsque vous entrez katakana dans l'élément numérique" et "lorsque vous ne pouvez pas vous connecter à la base de données". Dans le fonctionnement réel du système, des situations inattendues se produisent souvent. Des tests anormaux insuffisants peuvent conduire à des applications vulnérables qui se cassent rapidement à de tels moments.
Système normal et système anormal Le système normal est l'idée de "si oui ou non la sortie est comme prévu pour l'entrée que la cible attend". D'autre part, le système anormal est l'idée de "si la cible peut correctement traiter l'entrée qui n'est pas attendue".
Répartition égale La division équivalente est une méthode de division de l'entrée en groupes significatifs (classe de valeur égale) et de sélection d'une valeur représentative de chaque groupe. L'avantage est que vous pouvez éviter de tester avec des valeurs d'entrée similaires et vous ne manquerez pas un test avec des valeurs d'entrée significatives. À titre d'exemple, supposons que vous ayez une application avec les spécifications suivantes.
-Entrez l'âge de l'utilisateur dans la zone de texte. ・ Vous pouvez entrer une valeur de 0 à 200 pour l'âge. ・ Après la saisie, appuyez sur le bouton "Vérifier". -Une boîte de message différente s'affiche à l'écran selon la valeur saisie.
Si 0-19 est entré: Boîte de message "Mineur"
Si 20-99 est entré: Boîte de message "Adulte"
Si 100-200 est entré: boîte de message disant "Vous vivez très longtemps"
Dans cette application, il existe de nombreux types de nombres qui peuvent être saisis, mais vous pouvez voir qu'il n'y a en fait que trois groupes. Dans la division d'équivalence, des valeurs représentatives telles que 10, 80 et 150 sont sélectionnées dans chacun de ces groupes et testées.
Analyse de la valeur limite L'analyse de la valeur limite est une "méthode de saisie de la valeur de la limite entre des classes de valeur égale". Les erreurs de mise en œuvre de la méthode sont généralement plus susceptibles de se produire aux valeurs limites, de sorte que l'analyse des valeurs limites peut éviter les erreurs. Dans l'application précédente, 19 et 20, 99 et 100 sont les valeurs limites. Les bogues qui sont mélangés par erreur "inférieur ou égal à" et "inférieur à" dans les spécifications ou par des nombres d'inégalité erronés "<" et "≦" dans l'instruction if du programme peuvent être détectés en utilisant cette méthode.
Devinez l'erreur L'estimation des erreurs est une technique permettant de deviner des modèles de données susceptibles de provoquer des erreurs et de créer des cas de test. Ces modèles de données sont formalisés dans une certaine mesure. Plus précisément, les éléments suivants sont souvent utilisés.
Valeur maximale / minimale, valeur supérieure à la valeur maximale / valeur inférieure à la valeur minimale Les valeurs maximum et minimum pouvant être saisies et la longueur des caractères sont déterminées par la langue et les spécifications de l'application. Vérifiez ce qui se passe lorsque cette valeur est dépassée.
Fraction Nous testerons les éléments qui provoquent des erreurs d'arrondi lors du traitement de données comportant un grand nombre de chiffres, comme les nombres à virgule flottante.
Caractères vides, espaces, zéros, NULL Les programmes sont sujets à des dysfonctionnements lorsque "les données n'existent pas" ou "lorsque NULL est référencé".
Types de caractères non destinés à être saisis Vérifiez que la validation fonctionne pour les types de caractères qui ne doivent pas être saisis, comme la saisie de kanji dans le champ numérique ou la saisie de symboles dans le champ de nom.
Uru année, date / heure inexistante Entrez l'année de la tiède dans le champ de date et vérifiez qu'elle peut être manipulée correctement. Vous pouvez également essayer d'entrer une date / heure qui n'existe pas, telle que "2015/14/12" ou "26:00:00".
Sur la base des points de vue ci-dessus, les cas de test sont identifiés par la procédure suivante.
Quels types de cas peuvent être considérés dans le système normal?
Quels types de cas peuvent être envisagés pour des systèmes anormaux?
Quel type de valeur d'entrée peut être pris en compte lors de la division par la même valeur pour 1-2?
Quel type de valeur d'entrée peut être considéré par l'analyse des valeurs limites pour 1-2?
Sur la base de 1 à 4, considérez la qualité et la main-d'œuvre requises par le service comme un cas de test. Lors de l'identification des cas de test, il est possible de construire une application stable en considérant le système anormal plutôt que le système normal.
Granularité du scénario de test Dans le chapitre précédent, nous avons montré "Compte tenu de la qualité et de la main-d'œuvre requise par le service ...".
Par exemple, si le service en cours de développement est un produit coûteux pour le client, les cas de test doivent être couverts autant que possible. Surtout lorsqu'il s'agit de parties critiques telles que les fonctions de paiement.
Dans ce cas, vous voudrez peut-être envisager de tester minutieusement non seulement la couche domaine / application, mais également la couche d'interface (vue, etc.).
D'un autre côté, pour les services toC qui se composent uniquement de publicités et ne traitent pas d'informations sensibles, il peut être préférable de dépenser plus pour développer des fonctionnalités pour l'utilisateur que de passer du temps à mettre en œuvre des tests. Vous pouvez écrire autant de tests que vous le souhaitez, mais la granularité est flexible en fonction de la nature du service.
Recommended Posts