Suggestions de scénarios BDD pour une API générique?

Question

Je prépare des tests unitaires inspirés de BDD pour la partie API de mon application. (Oui, je sais, BDD est censé être sur le domaine et parler aux costumes, mais je préfère essayer BDD sur quelque chose de moins visible d'abord)

• utilisation ordinaire. Le développeur utilise les méthodes API avec des valeurs de paramètre ordinaires.

• Utilisation extrême. Le développeur appelle l'API avec des paramètres inhabituellement grands/petits . Par exemple. la méthode zip() reçoit un fichier de 2 Go.

• Utilisation abusive de l'API. Le développeur appelle l'API avec des paramètres fous - ce fou programmeur passerait à une date à un paramètre entier , droit - les paramètres sont oubliés, etc.

• hacking Malicious. Le développeur ne se soucie pas de ce que l'API est destinée à faire, mais cherche plutôt façons d'exécuter du code arbitraire. Les tests incluent JavaScript, SQL juste pour voir si nous pouvons les obtenir à exécuter n'importe où.

Y a-t-il d'autres scénarios que je devrais envisager?

Answer 1

Bien sûr, il y a toujours plus de scénarios à considérer. Franchement, il existe un ensemble de scénarios sans limites. C'est vraiment une question extrêmement ouverte. En ce qui concerne les scénarios de piratage malveillant, vous ne devriez vraiment vous préoccuper des emplacements évidents pour le débordement de tampon, puis s'en tenir à tester les failles de sécurité confirmées, de sorte que vous ne les rouvrez pas accidentellement. Et chaque fois que vous obtenez une vulnérabilité confirmée, traquez chaque endroit du code qui utilise des techniques et des schémas de programmation similaires, et testez/corrigez ceux-ci de manière préemptive. Cependant, dans de nombreux cas, le fuzzing vous donnera de meilleurs résultats. Le test automatisé est un élément important de la gestion des problèmes de sécurité, mais il ne devrait en aucun cas être l'outil principal de la boîte à outils.

D'autres éléments à considérer sont susceptibles d'être spécifiques aux données. Par exemple, lors de l'analyse des dates, veillez à gérer des éléments tels que 2/29/2009 ou 31/09/2009. Si vous le pouvez, essayez de gérer 1/1/1900 et 31/12/2038 (votre bibliothèque peut ne pas vous laisser). Une chose que vous pouvez faire est de vérifier la documentation pour tous les appels de bibliothèque que vous faites, de déterminer quelles exceptions sont levées dans quelles conditions, et d'essayer délibérément de trouver les entrées qui déclencheront ces exceptions, puis assurez-vous Il existe des tests qui vérifient que ces exceptions sont traitées ou, dans le cas du code de la bibliothèque, documentées.

Les outils de couverture de code et la mutation de code peuvent également vous aider à identifier des scénarios qui n'étaient pas couverts auparavant.