Tests d'API REST avec Postman expliqués

Le développement logiciel connaît une croissance considérable : les applications sont de plus en plus demandées, les versions sont plus fréquentes et leur qualité doit être maintenue à un niveau acceptable. Par conséquent, l'équipe d'assurance qualité doit veiller à ce que l'application fonctionne comme prévu.

Les tests unitaires et les tests d'intégration sont très utiles, mais ils ne suffisent pas à tester tous les aspects de l'application. De plus, ils relèvent de la responsabilité d'un développeur, et non d'un testeur QA.

Une fois les tests réalisés par un développeur, il est temps pour l'équipe QA de tester le fonctionnement des interfaces d'une application. Il existe de nombreuses combinaisons différentes avec diverses technologies et outils. Dans l'article d'aujourd'hui, nous nous concentrerons sur les tests d'API en mettant l'accent sur l'API REST et Postman.

Qu'est-ce qu'une API et pourquoi en avons-nous besoin ?

Imaginez que vous avez un talkie-walkie et que votre ami est à l'autre bout. Vous appuyez sur le bouton, votre voix l'atteint et vous lui demandez s'il pleut dehors. Il entend votre voix et vérifie s'il pleut. Une fois qu'il connaît la réponse, il appuie sur un bouton et vous renvoie l'information météo. L'API peut être comparée au talkie-walkie qui permet une communication bidirectionnelle. Bien sûr, le concept est bien plus complexe, mais j'espère que vous avez compris l'idée.

API signifie « Application Programming Interface » (interface de programmation d'application). La connexion d'applications via des API simplifie l'échange de données entre applications, ce qui se traduit par une productivité et des revenus plus élevés.

Les tests d'API sont un type complémentaire à la fois des tests unitaires et des tests de bout en bout (E2E). Les tests d'API permettent d'identifier le problème éventuel dès le début du cycle de vie du développement logiciel (SDLC).

Généralement, les applications web sont composées de trois couches : l'interface utilisateur (UI), la logique métier et la base de données. Les tests unitaires sont effectués au niveau de la logique métier. Les tests E2E ne peuvent être réalisés que lorsque les trois couches existent. Les tests d'API peuvent être effectués plus tôt, car il s'agit d'un type de test qui n'a pas besoin de l'UI et qui peut être contourné.

Les tests d'API peuvent s'exécuter sur une couche service ou métier et peuvent également être réalisés selon la méthode Black Box. Black Box signifie qu'il n'est pas nécessaire de connaître la structure interne du code, les chemins ou tout autre détail. Cette méthode repose purement sur les entrées et les sorties de l'application.

L'API est utilisée pour la communication entre applications et fonctionne de la manière suivante :

Grâce à cette méthode de communication et de transfert de données, la sécurité est assurée. Cela est rendu possible par l'inclusion des identifiants d'autorisation nécessaires à ces requêtes.

L'API utilise les protocoles les plus connus, tels que SOAP, REST et autres. SOAP (Simple Object Access Protocol) est basé sur XML et est orienté fonction. REST (Representational State Transfer) est basé sur HTML. Il structure ses données en XML, YAML et JSON et est orienté données. Il prend également en charge les formats OpenAPI, Swagger et RAML. Les requêtes REST HTTP les plus courantes sont POST, GET, PUT et DELETE.

Lorsque vous décidez quel protocole utiliser pour construire votre API, vous devez prendre en compte les fonctionnalités ou les avantages dont vous avez le plus besoin. Les caractéristiques de SOAP incluent la standardisation et une sécurité renforcée, tandis que les caractéristiques de REST sont la flexibilité et l'efficacité.

Tests d'API REST avec Postman

Les tests d'API sont utilisés pour valider les API, car ils vérifient la fonctionnalité, la fiabilité, les performances et la sécurité. Les tests d'API sont effectués via l'URL, qui appelle le point de terminaison de l'API. Ces appels sont appelés Requests. Après avoir envoyé une Request, nous devons nous attendre à recevoir une Response. La réponse est ensuite comparée aux résultats attendus.

Une requête se présente sous divers types – GET, POST, PUT, PATCH, DELETE, COPY, HEAD, OPTIONS, LINK, UNLINK, PURGE, LOCK, UNLOCK, PROPFIND et VIEW. Les plus utilisés sont GET, POST, PUT, DELETE.

La requête GET est utilisée pour récupérer les données depuis l'URL conjointe (endpoint). Aucune modification n'est apportée à l'endpoint.

La requête POST est utilisée pour envoyer les données au point de terminaison.

La requête PUT crée ou met à jour une ressource existante au niveau du point de terminaison.

La requête DELETE est utilisée pour supprimer des données sur le point de terminaison.

Les données sont envoyées au point de terminaison de l'API via l'URL et le type de requête approprié. Une fois reçue, une réponse doit contenir un code commençant par 2**, ce qui signifie que le statut est OK. La réponse est ensuite vérifiée par un test.

De nombreux outils sont utilisés pour les tests d'API – Katalon Studio, Postman, Apigee, JMeter, Rest-assured, Assertible, Soap UI, Karate DSL, Rest Console, API Fortress, Pyresttest, Hoppscotch, Taurus, Citrus Framework et Airborne, pour n'en citer que quelques-uns. Nous n'expliquerons pas chacun d'entre eux, mais pour illustrer notre propos, nous nous concentrerons sur Postman.

La présentation avec Postman commence par la configuration d'une application sur votre bureau. Vous pouvez également l'utiliser dans le navigateur, selon ce qui vous convient le mieux. Avant toute action dans Postman, il est utile de disposer de Swagger, où vous pouvez consulter tous les endpoints disponibles.

Avec les Requests créées, vous pouvez utiliser les Parameters, Authorization, Headers, Body, Pre-request Script et Tests. Vous n'avez pas besoin de tous ces éléments dans chaque Request, car certaines Requests ne nécessitent pas que tous soient renseignés avec des données.

Notre focus sera sur le domaine des Tests.

Pour commencer, nous utilisons Swagger comme point d'orientation des endpoints disponibles et nous créons des Requests dans Postman. Une fois une Request configurée, nous cliquons sur le bouton « Send ». Nous devrions recevoir la réponse peu après. Une Response devrait contenir « Status: 200 OK » ou un code de statut similaire commençant par « 2 ». Dans la zone Body d'une Response, il devrait y avoir, dans la plupart des cas, des données reçues du serveur. Ces données sont testées dans la zone Tests de Postman.

Il existe de nombreux exemples sur le web que vous pouvez adapter et utiliser dans vos propres tests Postman.

Test de base – vérification du statut d'une réponse :

pm.test(« Statut de la réponse », function () {
 pm.response.to.have.status(200);
 });

Il existe également des tests qui vérifient la zone Body :

pm.test(“La réponse doit contenir”, function () {

pm.response.to.have.jsonBody(“[response_data0:]”);

pm.response.to.have.jsonBody(“[response_data1:]”);

pm.response.to.have.jsonBody(“[response_data2:]”);

});

Dans ces tests, vous pouvez utiliser des variables pour stocker les données acquises et les réutiliser dans un autre test comme entrée dynamique. Les variables ou paramètres sont stockés au format suivant : {{variable}}.

Les tests d'API peuvent être automatisés et doivent couvrir certaines méthodes de test du SDLC, notamment : les tests de découverte, les tests d'utilisabilité, les tests de sécurité, les tests automatisés et la documentation.

Il existe de nombreuses façons diverses d'utiliser les tests. Nous en décrivons quelques-unes dans la section suivante.

Pipeline CI/CD

Une fois préparés, les tests API peuvent être utilisés bien au-delà. L'une des possibilités est de les utiliser dans votre pipeline CI/CD. Qu'est-ce qu'un pipeline CI/CD ?

CI signifie Continuous Integration (intégration continue). Le pipeline CI/CD est une série d'étapes automatisées permettant de livrer la dernière version du logiciel. Il est parfois nécessaire d'effectuer certaines étapes manuellement, ce qui est également possible. La véritable puissance du pipeline CI/CD réside dans son automatisation. Plus de détails sur le pipeline CI/CD sont disponibles dans les supports DevOps.

Si nous souhaitons placer certains tests dans ce pipeline, nous pouvons également utiliser les API Tests que nous avons déjà réalisés dans Postman. Ces tests doivent être organisés dans un ordre logique. Avant de les inclure dans le pipeline, ils doivent être testés dans le Runner de Postman et ne doivent comporter aucune erreur.

Après avoir vérifié que tout fonctionne correctement, nous pouvons exporter les données depuis Postman – nous devrions disposer des fichiers Collections.json et Environment.json.

Pour exécuter les fichiers Postman Collection.json et Environment.json, nous devons installer Newman. Newman nous permet d'utiliser les tests de l'API Postman dans le pipeline CI/CD.

Pour commencer, installez nodejs. Ensuite, dans la ligne de commande, exécutez «npm install -g newman”.

Ces deux fichiers que nous avons exportés précédemment depuis Postman doivent être placés ensemble dans le même chemin.

Ensuite, exécutez cela avec Newman.

Vous pouvez le faire avec le «newman run [nom de la collection] -e [environnement de la collection]» où «-e» désigne le paramètre d'environnement.

Outre Newman, nous pouvons également utiliser des outils de CI/CD comme TeamCity, Jenkins, etc.

Si vous préférez utiliser Jenkins, certaines étapes doivent être suivies. Tout d'abord, Jenkins doit être installé et démarré. La tâche Jenkins doit être configurée comme un projet Freestyle. Ensuite, ajoutez une étape de build qui exécutera une commande shell appelant le script de test.

Pour tous les détails sur la façon de configurer cela, veuillez rechercher les tutoriels spécialisés Newman ou Jenkins.

Codes de réponse serveur courants

Les codes de réponse serveur pour une API REST s'échelonnent de 100 à 500. Ils comportent des « sous-codes » offrant une explication plus précise, mais nous n'entrerons pas dans ce niveau de détail dans cet article. Par exemple, dans la série 400, tout le monde connaît le code « 404 – Not Found ».

Vous trouverez ci-dessous un aperçu général des codes :

1** – Réponses temporaires comme « Continue », « Switching Protocols » et « Processing »

2** – Réponses positives d'un serveur telles que « OK », « Created », « Accepted », etc.

3** – redirection Réponses telles que « Multiple Choices », « Use Proxy », « Temporary Redirect », etc.

4** – cette série de réponses est quelque chose que, dans la plupart des cas positifs, vous ne souhaitez pas voir, car certaines sont « Bad Request », « Not Found », « Forbidden », « Unauthorised », etc.

5** – cette série est spécifiquement liée aux erreurs côté serveur – le genre que vous ne voulez pas voir non plus. Certaines d'entre elles sont « Internal Server Error », « Not Implemented », « Bad Gateway », « Service Unavailable », « Network Authentication Required », etc.

Bonnes pratiques et approches pour les tests d'API

• Commencez par vous renseigner sur l'application que vous allez tester afin de pouvoir répondre aux questions : quels endpoints sont disponibles et que faut-il tester.
• Les spécifications de test doivent être précises et détaillées.
• Définir le périmètre de l'application.
• Définir le périmètre des tests d'API.
• Définissez quelles réponses sont acceptées et lesquelles ne le sont pas, tant dans le corps que dans le code de réponse.
• Définissez des cas de test regroupés par catégories.
• Définissez les utilisateurs dès les premières étapes du développement, si nécessaire.
• Les tests doivent refléter la nomenclature des points de terminaison.
• Les paramètres doivent être écrits dans les cas de test.
• Restez simple – une fonctionnalité, un test.
• Ne connectez pas les Tests entre eux.
• Ne précipitez pas les requêtes qui peuvent endommager le système cible.
• Une couverture de tests élevée est obtenue à la fois avec des scénarios positifs et négatifs.

Conclusion

Avec les tests API, il existe un vaste domaine qui peut être couvert et vérifié. Comme toute autre chose, cette méthode n'est pas non plus une solution « à toute épreuve ». En tant que QA, vous devrez effectuer tous les ensembles et types de tests différents pour garantir la qualité logicielle.

Veillez à ne pas surdimensionner les activités de test. Gardez à l'esprit que tout peut changer dans le processus SDLC et que vous devrez modifier une multitude de données. Vous pourriez vous enliser dans ce processus, ce qui peut nuire au projet lui-même.

Restez simple mais efficace.