Comment tester les points de terminaison d’une API
Une interface de programmation d’applications (API) permet à deux systèmes de communiquer entre eux. En essence, une API propose le contrat et le langage qui régissent la communication entre deux systèmes.
Les tests d’API consistent à évaluer ces interfaces afin de s'assurer qu'elles répondent aux normes de fonctionnalité, de fiabilité, de performance et de sécurité, généralement en envoyant différentes requêtes à l’API et en évaluant les réponses. Les tests d’API sont une priorité absolue pour presque tous les développeurs, plus de 90 % des développeurs déclarant tester ou prévoir de tester leurs API, selon l’enquête mondiale sur les API réalisée par Rapid en 2022.
Les points de terminaison (endpoints) d’une API sont des chemins spécifiques ou des URLs que l’API fournit, permettant l’accès à différentes fonctionnalités de l’application logicielle. Chaque point de terminaison correspond à une fonction spécifique, comme récupérer des données, mettre à jour un enregistrement ou effectuer un calcul, et est conçu pour traiter des types particuliers de requêtes et de réponses au sein de la structure globale de l’API.
Tester régulièrement les points de terminaison de l’API tout au long du processus de développement permet de détecter précocement les problèmes, ce qui fait gagner du temps et des ressources sur le long terme.
Alors, comment effectuer efficacement des tests d’API tout au long du cycle de vie du développement de l’API ? Plongeons dans le sujet !
Qu’est-ce qu’un point de terminaison (endpoint) d’API ?
Une API est un ensemble de règles et de protocoles servant à concevoir et à exploiter des applications logicielles, autorisant la communication entre différents systèmes logiciels. La documentation et les spécifications de chaque API déterminent comment les données peuvent être échangées.
Les API peuvent utiliser des requêtes HTTP pour récupérer des données depuis une application web ou un serveur, un peu comme lorsqu’une page web est rendue.
services, URLs, exactement comme celles que vous utilisez pour visiter un site web. Au sein d’une API, un point de terminaison est un emplacement particulier qui reçoit les requêtes et y répond. Par la transmission et la réception de données et de commandes via ce point de terminaison, il facilite la communication entre diverses applications et systèmes.
Cela permet aux développeurs d’accéder rapidement aux données ainsi qu’aux fonctionnalités d’autres systèmes, leur évitant d’avoir à tout construire depuis zéro dans de nouvelles applications.
Exemple de point de terminaison d’API
Voyons à quoi ressemble un point de terminaison d’API. Je vais prendre comme exemple The Cat API et leur documentation Postman :
Dans ce cas, les points de terminaison sont « images », « favorites », « breeds », etc. Chacun permet diverses actions, réalisées par différentes méthodes HTTP. Par exemple, les méthodes les plus couramment utilisées sont celles qui accomplissent des actions CRUD : POST pour la création, GET pour la lecture, PUT pour la mise à jour et DELETE pour la suppression.
La documentation de l’API doit détailler les points de terminaison disponibles, la méthode de requête autorisée pour chaque point de terminaison, ainsi que les modèles de requête et de réponse. Avec ces informations, nous devrions pouvoir commencer à tester les points de terminaison, ce que nous aborderons dans l’une des prochaines sections.
Pourquoi tester les points de terminaison d’API ?
Chaque API est conçue pour accomplir des fonctions précises, et le fonctionnement de l’application dépend des transactions de l’API pour obtenir des réponses. Une transaction de base peut effectuer de nombreux appels internes à l’API ; si l’un de ces appels échoue, l’ensemble du système peut être arrêté et cesser de fonctionner. De plus, plusieurs applications peuvent utiliser la même API : lorsqu'une API rencontre un dysfonctionnement, cela peut impacter de nombreuses applications. Tester les points de terminaison d’API permet de prévenir les problèmes avant que le client ne les rencontre.
Comment tester les points de terminaison d’API
Les tests d’API peuvent être réalisés manuellement ou de façon automatisée. Les deux types de tests peuvent être effectués à l’aide d’outils de test d’API.
Contrairement aux tests d’interface utilisateur (UI), les tests d’API ne dépendent pas d’un navigateur. Toutefois, un outil de test d’API jouant le rôle de client peut être utilisé.
En nous basant sur la documentation, nous pouvons extraire le point de terminaison auquel la requête HTTP doit être envoyée, la méthode HTTP, les paramètres de requête, le corps de la requête (si nécessaire), les codes de statut HTTP possibles en réponse, ainsi que le corps de la réponse HTTP. Grâce à ces informations, nous pouvons identifier les cas de test d’API à exécuter.
Selon les besoins, nous pouvons décider des tests à réaliser — des tests fonctionnels aux tests non fonctionnels, tels que les tests de performance, de charge et de sécurité.
Le test d’API le plus basique consiste à envoyer la requête et à valider la réponse. Selon le type de requête et le point de terminaison concerné, des informations supplémentaires peuvent être nécessaires pour envoyer la requête. Voici ce dont nous avons besoin pour envoyer une requête :
- Endpoint/URL : il s'agit de l'adresse à laquelle la requête est envoyée
- Le corps de la requête : pour les méthodes telles que POST et PUT, un corps est nécessaire, contenant les données à envoyer au serveur
- Paramètres de requête : des paramètres de recherche supplémentaires peuvent être utilisés pour limiter les résultats renvoyés dans la réponse
- En-têtes : ce sont des méta-données qui peuvent être envoyées avec la requête. Dans l’exemple du chat cité précédemment, une clé API peut être utilisée comme en-tête, ce qui permet de récupérer plus d’informations qu’en l’absence de clé :
Après l’envoi réussi de la requête, le test doit vérifier la réponse. Les éléments à vérifier dans la réponse sont :
- Le code d’état HTTP : chaque réponse possède un code d’état. Ceux-ci peuvent être regroupés en 5 grandes classes : les codes commençant par 1 (100-199) représentent une réponse d’information, les codes débutant par 2 (200-299) indiquent un message de succès, les codes compris entre 300 et 399 sont des redirections, les codes commençant par 4 (400-499) sont des erreurs côté client et les codes de la série 500 correspondent à des erreurs serveur.
- Le corps de la réponse HTTP : les informations qui sont renvoyées par le serveur. La documentation doit préciser le type d’information que la réponse devrait contenir, par exemple :
- En-têtes de réponse : méta-données renvoyées par les serveurs
- Temps de réponse : si nous nous intéressons aussi aux performances de l’API.
Pour un exemple rapide, j’utiliserai Postman pour montrer à quoi ressemble une requête GET avec l’API Cat. J’enverrai une requête GET vers l’endpoint images. Pour cela, il suffit d’utiliser l’adresse de l’endpoint, la méthode GET, puis d’envoyer la requête :
Après l’envoi de la requête, nous pouvons voir le code de réponse HTTP, le corps, ainsi que le temps requis pour obtenir une réponse :
Le contenu du corps de la réponse correspond à ce qu’une API renvoie selon les entrées fournies, tandis que le code de statut de la réponse indique l’état actuel de la requête.
Il existe des différences dans les types et tailles des données d’une réponse d’API. Un texte brut, un document XML, une structure de données JSON, et d’autres formats sont tous possibles pour les réponses. Il peut s’agir d’un fichier JSON/XML de cent pages ou d’une simple chaîne de quelques mots, voire vide. Il est donc crucial de sélectionner une technique de vérification appropriée pour une API donnée.
Créer des cas de test pour une API
Les cas de test fonctionnels peuvent être extraits à l’aide des techniques de test boîte noire. La documentation précise les types de données acceptés par chaque paramètre, ainsi il est possible de créer des partitions et des bornes à partir de ces informations.
Puis, nous pouvons créer des scénarios plus complexes en combinant plusieurs requêtes dans un test. Par exemple, un test qui crée une ressource, la modifie, la lit, puis la supprime, enverra 4 requêtes différentes.
Il est nécessaire de réaliser à la fois des tests positifs et négatifs pour vérifier que l’API fonctionne comme attendu. Étant donné que le test d’API est un sous-ensemble du test boîte noire, les données d’entrée et de sortie sont centrales pour les deux types de tests. Voici quelques idées pour créer des scénarios de test :
Scénarios positifs :
- Vérifier que l’API accepte l’entrée et produit le résultat attendu selon les exigences.
- Vérifier que le code de statut de la réponse — qu’il s’agisse d’un code d’erreur ou d’un code 2xx — est renvoyé selon ce qui est indiqué dans les exigences.
- Indiquer le nombre minimum et maximum de champs qui doivent être renseignés.
Scénarios négatifs :
- S’assurer que dans les cas où la sortie attendue est absente, l’API renvoie une réponse appropriée.
- Effectuer un test de validation des entrées.
- Examiner le comportement de l’API à différents niveaux d’autorisation.
Tests API non fonctionnels
En dehors des tests fonctionnels, nous pouvons réaliser différents tests non fonctionnels pour les API. Voici quelques-uns des plus importants :
Test de performance
Le test de performance consiste à mesurer les performances du logiciel sous différentes charges de travail, scénarios et conditions. Cela peut vous aider à identifier les goulets d’étranglement des ressources, à garantir la stabilité et l’évolutivité, ainsi qu’à assurer la montée en charge. Les sous-catégories du test de performance incluent le test de charge, le test de stress, le test d’endurance et le test de pointe. Le test de performance le plus populaire, appelé test de charge, simule un trafic utilisateur moyen ou élevé sur votre logiciel. Cela permet d’évaluer le débit, le temps de réponse et l’utilisation des ressources de votre logiciel. Apache JMeter, un outil Java open-source capable de générer et d’envoyer différentes requêtes à votre API tout en mesurant les résultats, est l’un des meilleurs outils pour réaliser un test de charge de votre API.
Test de sécurité
Le processus permettant de s'assurer que votre logiciel est protégé contre les attaques malveillantes, les accès non autorisés et les failles de données est appelé test de sécurité. Cela peut vous aider à garantir la confidentialité, l'intégrité et la disponibilité des données de votre programme. Différents niveaux de tests de sécurité peuvent être réalisés, notamment au niveau de la base de données, de l’application et du réseau. Les revues de code, les tests de pénétration, les analyses de vulnérabilités et le hacking éthique sont quelques méthodes courantes de test de sécurité. Postman est un outil multiplateforme populaire qui permet d’envoyer et de recevoir des requêtes à votre API et de tester des fonctionnalités liées à la sécurité comme l’authentification, l’autorisation, le chiffrement et la gestion des erreurs. C’est l’un des meilleurs outils pour tester la sécurité de votre API.
Test de fiabilité
Le test de fiabilité consiste à évaluer la constance et la robustesse de votre logiciel dans le temps et dans différentes situations. Cela vous permet de garantir la récupération, la tolérance aux pannes et la disponibilité de votre logiciel. Vous pouvez réaliser des tests de fiabilité en introduisant volontairement des bugs, des erreurs ou des défaillances dans votre logiciel et en observant comment il réagit et se rétablit. Le temps moyen entre deux pannes (MTBF), le temps moyen avant défaillance (MTTF), le temps moyen de réparation (MTTR) et le taux d’échec font partie des indicateurs fréquemment utilisés pour ce type de test. Chaos Monkey, un outil qui arrête de façon aléatoire des instances dans votre environnement cloud pour tester la résistance de votre logiciel aux perturbations, est l’un des meilleurs outils pour tester la fiabilité de votre API.
Réflexion finale
Les tests d’API sont une compétence de plus en plus importante pour les professionnels de l’assurance qualité (QA). Il est essentiel de tester minutieusement les points de terminaison d’API afin de s’assurer qu’ils fonctionnent comme prévu et répondent aux normes requises. Tester les points de terminaison d’API permet d’identifier et de résoudre d’éventuels problèmes ou bugs et de valider la fonctionnalité globale de l’application.
Pour tester efficacement les points de terminaison d’API, il est important de suivre les meilleures pratiques, telles que la conception de cas de test complets, la prise en compte de diverses entrées et sorties, et l’utilisation d’outils d’automatisation pour un test efficace et fiable. De plus, l’utilisation d’environnements de test simulant au mieux des scénarios réels peut améliorer l’exactitude des tests d’API.
Des tests exhaustifs et efficaces des points de terminaison d’API sont essentiels pour garantir la fiabilité, la performance et la fonctionnalité des applications modernes. En comprenant ce que sont les points de terminaison d’API et comment les tester, les développeurs peuvent assurer l’intégration réussie de leurs applications avec d’autres systèmes tout en offrant une expérience utilisateur exceptionnelle.
Merci de vous abonner à la newsletter QA Lead pour recevoir des mises à jour sur les nouveaux contenus de test.
