The API Testing Checklist I Use for Every Endpoint

Il y a trois ans, j'ai vu une API de production échouer spectaculairement à 2 heures du matin parce que personne n'avait testé ce qui se passe lorsque vous envoyez un champ de date formaté comme "32/13/2021". La cascade était belle de la pire manière possible : 47 000 transactions échouées, des clients en colère inondant les canaux de support, et un PDG qui voulait des réponses que je n'avais pas. Cette nuit-là a changé ma façon d'aborder le test d'API pour toujours.

Je suis Sarah Chen, et je suis ingénieure en automatisation QA depuis huit ans, dont les cinq dernières se concentrant exclusivement sur les tests d'API pour des plateformes fintech et de santé. J'ai testé tout, des points de terminaison CRUD simples aux API de traitement de paiements complexes gérant des millions de dollars quotidiennement. Ce que j'ai appris est ceci : la plupart des échecs d'API ne sont pas des cas extrêmes exotiques—ce sont des problèmes prévisibles qu'une liste de contrôle systématique aurait pu détecter.

La liste de contrôle que je partage aujourd'hui est exactement celle que j'utilise pour chaque point de terminaison que je teste. Elle a sauvé mon équipe d'au moins une douzaine d'incidents de production au cours de la dernière année seulement, et elle est suffisamment complète pour que les ingénieurs juniors puissent la suivre tout en étant assez détaillée pour qu'elle détecte les problèmes que les développeurs seniors manquent. Ce n'est pas de la théorie—c'est un processus éprouvé affiné grâce à des centaines d'implémentations d'API.

Authentification et Autorisation : La Couche Fondamentale

Avant de tester quoi que ce soit d'autre, je vérifie le périmètre de sécurité. Il ne s'agit pas seulement de vérifier si l'authentification fonctionne—il s'agit de sonder systématiquement chaque scénario d'authentification et chaque limite d'autorisation. J'ai vu trop d'APIs qui fonctionnent parfaitement avec des identifiants valides mais échouent catastrophiquement ou fuient des données lorsque des identifiants manquent, sont malformés ou appartiennent au mauvais utilisateur.

Tout d'abord, je teste sans aucun token d'authentification. Le point de terminaison doit retourner un statut 401 Non Autorisé, pas d'erreur 500 du serveur interne, et certainement pas de données réelles. J'ai rencontré des APIs de production qui retournaient des enregistrements utilisateurs complets lorsque aucun token d'authentification n'était fourni parce que le développeur a supposé que le middleware d'authentification s'exécuterait toujours. Ce n'était pas le cas.

Ensuite, je teste avec un token expiré. Cela permet de déceler un nombre surprenant de problèmes car la logique d'expiration du token vit souvent dans une partie différente du code que l'authentification initiale. La réponse doit être un clair 401 avec un message indiquant que le token a expiré, pas un générique "non autorisé" qui laisse le client deviner s'il doit rafraîchir ou se réauthentifier.

Ensuite, je teste avec un token malformé—des chaînes aléatoires, des tokens avec des caractères supprimés, des tokens d'autres systèmes. L'API doit gérer cela gracieusement sans exposer de traces de pile ou de détails d'erreur internes. Une fois, j'ai trouvé une API qui faisait planter tout le service lorsqu'on lui donnait un token contenant certains caractères Unicode parce que la bibliothèque de parsing JWT ne gérait pas correctement l'encodage.

Les tests d'autorisation sont là où les choses deviennent intéressantes. Je teste avec des tokens valides appartenant à des utilisateurs qui ne devraient pas avoir accès à la ressource. Pour un point de terminaison GET /users/123, je vais m'authentifier en tant qu'utilisateur 456 et essayer d'accéder aux données de 123. La réponse devrait être 403 Interdit, pas 404 Non Trouvé (ce qui divulgue des informations sur l'existence de la ressource) et définitivement pas 200 avec les données.

Je teste également systématiquement le contrôle d'accès basé sur les rôles. Si votre API a des rôles admin, manager et utilisateur, je teste chaque point de terminaison avec chaque rôle. Je maintiens un tableau matriciel : les lignes sont des points de terminaison, les colonnes sont des rôles, les cellules contiennent les codes de statut attendus. Cela permet de détecter les bogues de permission avant qu'ils n'atteignent la production, où ils deviennent des vulnérabilités de sécurité.

Validation des Requêtes : Tests de Limites d'Entrée

La validation des entrées est là où la plupart des APIs montrent leur véritable qualité. Une API bien conçue valide chaque champ d'entrée minutieusement et renvoie des messages d'erreur clairs et exploitables. Une mal conçue accepte soit des données non valides soit plante de manière mystérieuse.

"La plupart des échecs d'API ne sont pas des cas extrêmes exotiques—ce sont des problèmes prévisibles qu'une liste de contrôle systématique aurait pu détecter."

Je commence par le test des champs requis. Pour chaque champ requis, j'envoie une requête sans lui. L'API doit retourner un 400 Requête Incorrecte avec un message identifiant clairement quel champ est manquant. J'ai vu des APIs qui retournent "erreur de validation" sans spécifier ce qui a échoué, forçant les développeurs à deviner lequel des 15 champs a causé le problème.

Ensuite, je teste la validation des types de données. Si un champ attend un entier, j'envoie des chaînes, des flottants, des booléens, des nuls, des tableaux et des objets. Chacun devrait retourner un 400 avec un message clair comme "l'âge doit être un entier" et non "format de demande invalide." Une fois, j'ai testé une API de commerce électronique où l'envoi d'une chaîne pour la quantité a causé la création de commandes pour zéro article, ce qui a rompu tout le pipeline de traitement des commandes.

La validation de la longueur des chaînes est critique et souvent négligée. Je teste avec des chaînes vides, des caractères uniques, des chaînes à la longueur maximale, des chaînes un caractère au-delà de la maximale, et des chaînes incroyablement longues (plus de 10 000 caractères). J'ai planté des bases de données de production en envoyant des chaînes de plusieurs mégaoctets à des champs qui n'étaient pas correctement validés, causant une exhaustion de la mémoire.

Pour les champs numériques, je teste les valeurs limites systématiquement : zéro, nombres négatifs, décimales lorsque des entiers sont attendus, nombres supérieurs à la valeur maximale d'un entier, et des valeurs spéciales comme Infinity ou NaN. Une API de paiement que j'ai testée une fois a accepté des montants de paiement négatifs, ce qui aurait permis aux utilisateurs de créditer leurs comptes de manière arbitraire.

La validation de date et heure mérite une attention particulière car elle pose systématiquement problème. Je teste avec des dates invalides (30 février, mois 13), divers formats (ISO 8601, timestamps Unix, chaînes lisibles par l'homme), des dates loin dans le passé ou dans le futur, et des cas extrêmes de fuseaux horaires. L'incident de 2 heures du matin que j'ai mentionné au début ? C'était un échec de validation de date.

Pour les champs d'énumération, je teste avec des valeurs valides, des valeurs invalides, des variations de casse, et des valeurs nulles. Si l'API accepte "actif" et "inactif" comme valeurs de statut, j'essaierai "ACTIF", "Actif", "en attente", chaîne vide, et nul. Chacun devrait soit être accepté (s'il est insensible à la casse) soit rejeté avec un message clair énumérant les options valides.

Validation des Réponses : Assurer l'Intégrité des Données

Tester ce qui revient est tout aussi important que tester ce qui entre. J'ai vu des APIs qui acceptent des requêtes parfaitement mais retournent des données incohérentes, incomplètes ou mal formatées qui cassent les applications clientes.