Cas de test pour tester le code… quelles limites?

Question

J'ai donc récemment été embauché en tant que développeur QA / firmware pour une entreprise d'imprimantes, et beaucoup de mon travail consiste à écrire de petits widgets / applications de test à placer sur les imprimantes elles-mêmes pour tester pour s'assurer que tout fonctionne correctement. Avant de déplacer cela vers CareerExchance et les programmeurs, etc. ... Je parle vraiment du code source ici ...

Cependant, depuis que je viens de terminer mes études universitaires avec mon BS en CS, je suis assez nouveau dans le monde professionnel ... et QA en particulier.

Quoi qu'il en soit, j'ai du mal à saisir une très bonne "méthode" pour donner un bon résultat de cas de test.

Comme disons que vos numéros d'entrée d'un clavier (0-9) ..... donc pour tester, vous testez la plage acceptée (comme 1-100), mais je me demande combien devrais-je tester dans cette plage (garder Dans l'esprit, certains d'entre eux sont impossibles à automatiser car nous devons les appuyer à la main de temps en temps)

Ensuite, vous testeriez la plage extérieure évidemment (mais combien de fois?)

Et par exemple, saisir des caractères ASCII qui n'appartiennent pas comme * $%, ou les caractères. Je suis un peu confus de la façon de donner un bon cas de test pour les cas bornés / illimités?

Des idées?

Answer 1

Si cela aide, vous frappez maintenant un problème vraiment difficile - quiconque vous dit qu'il est facile ou trivial de choisir les bons cas de test à partir d'un numéro presque infini est soit ignorant, soit essayer de vous vendre un outil très cher!

Le regroupement de votre contribution dans les familles (alias les partitions d'équivalence) comme le suggère une autre réponse peut être utile. Je suggérerais de lire sur le design des tests - j'aime le livre de Lee Copeland "A Pratier's Guide to Software Test Design", mais vous pourriez également trouver le livre "Essential Test Design" de Tobbe Ryber utile - il est disponible en téléchargement PDF gratuit ici: http://www.ryber.se/?p=213 - Jetez un œil au chapitre 10 pour commencer.

Les suggestions de Glowcoder pour consulter les rapports de bogues pour les indices, et la recherche du code pour d'autres idées vaut tous deux la peine d'être suivi. Soyez également conscient de la possibilité qu'il puisse y avoir des limites "invisibles" - c'est-à-dire que les limites dont vous n'êtes pas au courant ne sont pas évidentes uniquement en regardant le code ou les exigences - par exemple, les nombres d'instance inférieurs à une certaine valeur fonctionnent très bien, et Ensuite, à une valeur apparemment totalement arbitraire, ils commenceront soudainement à échouer. Jetez un œil à ceci pour un exemple:Fonctionnalité de langue la plus étrange (Et oui, j'ai rencontré celui-là dans la nature).

C'est une bonne raison pour laquelle il vaut la peine de saupoudrer dans la valeur élevée de grande valeur, variant autant que possible vos données de test (dans des limites raisonnables) - vous augmentez vos chances de rencontrer quelque chose que vous n'auriez tout simplement pas prévu. (C'est aussi un grand argument contre l'exécution exactement les mêmes cas de test encore et encore - s'ils sont automatisés, alors le coût est plus bas et ils agissent comme des indicateurs de changement. Mais si vous devez saisir manuellement les valeurs - vous pourriez Aussi, changez-les un peu et couvrez un peu plus de l'espace de recherche à chaque fois).

Voici une vidéo sur les tests de limite et quelques conseils pour plus de ressources:http://www.testingreflections.com/node/view/4292

Answer 2

Recherchez les familles d'entrée.

négatif, non négatif, 0, non positif, positif, 0 chiffre, 1 chiffre, 2 chiffres, 3 chiffres ...

Ce sont des exemples de familles d'entrée.

Recherchez des choses dans le code qui vous feraient diviser quelque chose en une nouvelle famille de cas de test.

Recherchez des rapports de bogues pour des opérations similaires mais différentes - ils pourraient vous donner des indices comment pénétrer dans les familles.

Answer 3

Je recommanderais de parcourir le Blog de test Google Pour plus d'informations sur les stratégies de test. James Whittaker a également écrit quelques livres sur les tests. Je n'ai pas lu les livres moi-même, mais j'espère à un moment donné.

Parlez également à d'autres développeurs, testeurs et personnes QA où vous travaillez. Demandez-leur leurs anciennes histoires de guerre, leurs bugs préférés qu'ils ont trouvés, corrigées ou entendues. Beaucoup de bogues entrent dans des catégories communes et apprennent à reconnaître et à anticiper ces erreurs est en grande partie une question d'expérience.