Réponse.

Les tests manuels d'API sont le processus de vérification du fonctionnement de l'interface de programmation d'applications sans l'utilisation de l'automatisation, à l'aide d'outils spécialisés tels que Postman, Swagger ou curl.

Historique de la question

Les premières API étaient testées manuellement en raison de l'absence d'automatisation et de la relative simplicité des interfaces. Aujourd'hui, malgré l'automatisation, les tests manuels conservent leur importance, surtout pour la vérification de base des méthodes nouvelles ou instables.

Problème

Les principales difficultés sont liées à :

la nécessité de comprendre précisément la structure des données d'entrée et de sortie (JSON, XML, etc.)
la complexité de la reproduction de scénarios compliqués (authentification, dépendance à l'état du système)
le risque de manquer des bugs cachés, non évidents via l'UI.

Solution

Tests réussis nécessitent :

un travail attentif avec la documentation API
la création de jeux de requêtes manuelles, couvrant différents paramètres et scénarios d'erreurs
le test tant de scénarios positifs que négatifs (validation des données, vérification des autorisations)

Caractéristiques clés :

La possibilité de vérifier rapidement un nouvel ou un point de terminaison modifié sans attendre des tests automatisés
La flexibilité dans l'analyse des anomalies et des erreurs, lorsque le résultat n'est pas évident
Le contrôle visuel de toutes les étapes de la demande et de la réponse

Questions pièges.

Peut-on utiliser uniquement l'UI pour les tests manuels d'API, sans outils comme Postman ?

Non, car de nombreuses erreurs ne se manifestent qu'au niveau de la transmission des données et ne s'affichent pas via l'UI, pour une vérification complète, des outils spécialisés sont nécessaires.

Est-il suffisant d'envoyer une seule requête valide pour tester le fonctionnement d'un point de terminaison API ?

Non, il est important de tester non seulement des requêtes valides, mais aussi tous les cas limites, invalides et rares, sinon les bugs ne seront pas trouvés.

Faut-il tester les scénarios négatifs séparément ou est-ce un travail inutile ?

Il est essentiel de le faire. Il est important de s'assurer que le système gère correctement les erreurs et rejette les requêtes invalides, sinon la sécurité et la stabilité seront mises en péril.

Erreurs typiques et anti-modèles

Tester uniquement des scénarios "idéaux" (absence de vérification des valeurs incorrectes)
Ignorer l'état du système — tests sur des données déjà existantes ou une base non préparée
Absence de validation des en-têtes, des statuts d'erreur, des cas atypiques.

Exemple de la vie

Cas négatif

Le testeur vérifie uniquement une requête POST réussie à l'API "créer un utilisateur" — envoie un JSON valide, reçoit 200 OK, pense que le test est terminé.

Avantages :

Vérification rapide du scénario principal.

Inconvénients :

Des erreurs liées à l'absence de champs, un format email incorrect, la création répétée du même utilisateur ont été manquées.
Pas de certitude que l'API renverra le bon code d'erreur.

Cas positif

Le testeur vérifie systématiquement l'API "créer un utilisateur" :

succès pour une requête valide
erreurs lors de l'absence de paramètres obligatoires
erreur en cas de création répétée
vérifie différents codes HTTP, messages d'erreur, validation de l'email.