Quels scénarios de test sont nécessaires et suffisants pour tester de manière exhaustive un modèle de nomination récurrent sur la boîte noire?

Question

J'ai un modèle Django pour un rendez-vous dans un calendrier pour lequel je tente d'écrire un pilote de test très complet. Le rendez-vous périodique se produit à un moment donné et peut s'exécuter à l'infini ou se reproduire un nombre de fois déterminé. Le rendez-vous reflète la fonctionnalité disponible pour un rendez-vous Google Agenda (peut être récurrent tous les mois / tous les ans / toutes les semaines, toutes les deux semaines, tous les trois ans.)

J'essaie de créer un test unitaire qui testera de manière exhaustive les bases de cette implémentation. Je recherche les cas extrêmes qui définiront les tests les plus élémentaires.

J'en ai beaucoup de bases, mais je cherche des suggestions pour aider à identifier les cas les plus importants: 1) Créer un rendez-vous unique 2) Créer un rendez-vous qui se répète chaque semaine 3) ... se répète tous les mois 4) se reproduit toutes les 2 semaines 5) se répète tous les 2 mois 6) se répète chaque année

Answer 1

Testez les derniers jours des mois, les années bissextiles et déterminez si cela deviendra fou quand l'année aura une seconde supplémentaire (celle-ci frappe un pilote dans le lecteur zune).

Testez-le et il se comporte bien lorsque vous traversez des années.

Cela dit, demandez-vous si vous retestez quelque chose qui fait partie du cadre. Les tests de logique de date peuvent devenir très rapidement très laids, vous voulez donc tracer une ligne sur ce qui fait partie de votre application et ce qui fait partie du cadre.

Answer 2

N'oubliez pas de tester la récurrence annuelle du 29 février pour une année bissextile;)

Answer 3

Avant de vous lancer dans des scénarios, vous devez vraiment élaborer un plan de test basé sur votre compréhension des exigences.

Considérez votre base d’utilisateurs et toute autre base d’utilisateurs possible / future (avec une priorité inférieure). A quoi vont-ils principalement l'utiliser et combien valent-ils pour ces cas d'utilisation dans leur entreprise?

Idéalement, créez un modèle de l'application et commencez à partir de là.

Proposez une analyse des risques de vos projets. Ensuite, prévoyez de faire des tests fonctionnels, de sécurité, de localisation, etc.

Ensuite, vous pouvez commencer à réfléchir à des scénarios basés sur la manière dont "risqué". ils sont (de l'analyse de risque). Concentrez-vous sur l'écriture et l'exécution du programme "plus risqué". les premiers.

Obtenez l’entrée des entreprises (signez si possible) sur votre analyse de risque et sur la façon dont vous envisagez de l’utiliser.

Le simple fait de lancer des scénarios aléatoires n’est pas une bonne pratique de test et mérite tout le ridicule que les développeurs peuvent obtenir. Les tests devraient être un exercice mieux conçu et planifié. Ils peuvent embaucher n'importe qui dans la rue pour organiser des scénarios qui leur viennent à l'esprit.

Cela étant dit, je conviens que les scénarios mentionnés précédemment sont éprouvés. Bonnes idées. Jetez également dans le test de l'heure d'été. Utilisez différents clients de messagerie. Essayez de publier la date de disponibilité. Demandez aux développeurs d’expliquer comment ils publient ces informations. Est-ce via un service web? S'attendent-ils à ce que seuls les utilisateurs Exchange l'utilisent? Quelqu'un dans différents pays où les dates sont formatées différemment? Vous pouvez ensuite trouver des faiblesses et trouver plus de bugs.

Bon test.