Qu'est-ce que les tests d'API ? Guide des tests d'API

Comprendre les tests d'API de manière significative peut libérer le pouvoir de créer une stratégie de test vraiment efficace. Dans ce guide, découvrez ce qu'est le test d'API, y compris les nombreux types de tests d'API, pour vous assurer que vous savez comment tester efficacement l'API.

Lors d'un déploiement récent, je travaillais avec un client pour élaborer une stratégie de test d'API quand on m'a demandé à l'improviste: «Qu'est-ce que le test d'API?» J'ai alors réalisé que les tests d'API sont étonnamment difficiles à décrire, et même lorsque vous les décrivez, cela a tendance à paraître ennuyeux et compliqué.

Eh bien, je suis ici pour vous dire que les tests d'API ne sont PAS ennuyeux ou compliqués. C'est en fait très amusant et puissant, et le comprendre de manière significative libère le pouvoir de créer une stratégie de test vraiment efficace. Pour vraiment comprendre comment faire des tests d'API, lisez la suite.

Qu'est-ce qu'une API et comment l'utiliser ?

Dans le développement de services, une interface de programme d'application (API) est un moyen pour diverses applications de communiquer entre elles en utilisant un langage commun, souvent défini par un contrat. Des exemples de ceux-ci seraient un document Swagger pour les services RESTful ou un WSDL pour les services SOAP. Même les bases de données ont un langage d'interface, c'est-à-dire SQL.

Tout comme une interface utilisateur permet à un humain d'interagir avec une application, les API permettent aux machines de communiquer efficacement entre elles.

Les API sont excellentes car elles représentent des blocs de construction que les développeurs peuvent utiliser pour assembler facilement toutes sortes d'interactions sans avoir à réécrire une interface à chaque fois qu'ils ont besoin de machines pour communiquer. De plus, étant donné que les API ont des contrats, les applications qui souhaitent communiquer entre elles peuvent être créées de manière complètement différente, à condition qu'elles communiquent conformément au contrat d'API. Cela permet à différents développeurs de différentes organisations dans différentes parties du monde de créer des applications hautement distribuées tout en réutilisant les mêmes API.

Lorsqu'un utilisateur interagit avec le frontend d'une application (c'est-à-dire une application mobile), ce frontend effectue des appels d'API vers les systèmes backend, simplifiant ainsi le processus de développement de deux manières principales :

1. Le développeur n'a pas à se soucier de créer une application personnalisée pour chaque appareil mobile ou navigateur.
2. Différents systèmes backend peuvent être mis à jour ou modifiés sans avoir à redéployer l'application entière à chaque fois.

En conséquence, les développeurs peuvent gagner du temps en se concentrant sur un service individuel pour accomplir une tâche discrète, au lieu de passer du temps à écrire la logique dans leur application.

Un bon exemple d'utilisation d'API standard

Services d'achat Amazon ' API documentées permettent aux développeurs de s'interfacer avec Amazon Shopping lors de la création de leurs applications. Le développeur peut utiliser les API Amazon aux moments appropriés de son expérience utilisateur, pour créer un parcours client fluide.

Par exemple, cela pourrait ressembler à ceci:

L'utilisateur interagit avec l'interface utilisateur tandis que l'application interagit avec les API Amazon backend, telles que définies par le développeur. Tout fonctionne très bien tant que les API sous-jacentes se comportent comme prévu.

… .Mais c'est un très gros si.

Nous arrivons donc à l'importance de tester ces API.

Qu'est-ce que le test API?

Alors, comment effectuez-vous les tests d'API? Qu'est-ce que cela implique? Comment tester l'API? Contrairement à l'utilisateur, qui n'interagit avec l'application qu'au niveau de l'interface utilisateur, le développeur / testeur doit garantir la fiabilité de toutes les API sous-jacentes. Sans tester les API eux-mêmes, les développeurs et les testeurs seraient bloqués dans les tests manuels, tout comme un utilisateur, testant l'application au niveau de l'interface utilisateur, attendant que toute la pile d'applications soit construite avant de pouvoir commencer les tests.

Vous pouvez plutôt effectuer des tests d'API automatisés en testant l'application au niveau de l'API, en concevant des cas de test qui interagissent directement avec les API sous-jacentes et en obtenant de nombreux avantages, notamment la possibilité de tester la logique métier à une couche facile à automatiser dans un manière stable. Contrairement aux tests manuels, qui se limitent à valider une expérience utilisateur spécifique, les tests d'API vous donnent le pouvoir de protéger votre application contre l'inconnu.

Comment effectuer des tests d'API?

Différents types de tests d'API - Où, pourquoi et comment

La meilleure façon d'aborder les tests d'API est de créer une pratique de test solide de bas en haut. À cette fin, un excellent moyen de concevoir une stratégie de test est de suivre test de la pyramide. L'approche pyramidale suggère que vous construisiez un large éventail de tests d'API (par exemple, contrat, scénario, performances, etc.) en plus d'une base solide de tests unitaires avec des tests d'interface utilisateur. Les tests d'API vous permettent de tester la logique d'application à un niveau que les tests unitaires ne peuvent pas.

Ces stratégies de test sont complémentaires. Tester plus tôt, aux niveaux inférieurs de l'application, vous aide à «échouer rapidement et à échouer tôt», en détectant les défauts tôt à leur source, plutôt que plus tard dans le SDLC. Les tests unitaires sont importants, mais pour l'instant, nous nous concentrons sur les tests d'API. Comment testez-vous les API? Quels types de tests peuvent être effectués? Pourquoi sont-ils importants? Comment puis-je do Test d'API?

Voici les différents types de tests d'API, y compris où, pourquoi, comment vous pouvez les utiliser.

Essais contractuels

Une API représente un contrat entre deux ou plusieurs applications. Le contrat décrit comment interagir avec l'interface, quels services sont disponibles et comment les appeler. Ce contrat est important car il sert de base à la communication. S'il y a quelque chose qui ne va pas avec le contrat, rien d'autre n'a vraiment d'importance.

Le premier et le plus basique des types de tests API est le test de contrat, qui teste le contrat de service lui-même (Swagger, PACT, WSDL ou RAML). Ce type de test valide que le contrat est rédigé correctement et peut être consommé par un client. Ce test fonctionne en créant une série de tests qui tirent dans le contrat et valident ce qui suit.

• Le contrat de service est rédigé selon un cahier des charges.
• Une demande de message et une réponse sont sémantiquement correctes (validation de schéma).
• Le point de terminaison est valide (HTTP, sujet/file d'attente MQ/JMS, etc.).
• Le contrat de service n'a pas changé.

Je les considère comme vos premiers « tests de fumée ». Si ces tests échouent, il n'y a vraiment aucune raison de continuer à tester ce service particulier. Si ces tests réussissent, vous pouvez commencer à tester la fonctionnalité réelle de l'API.

Tests de composants

Les tests de composants sont comme des tests unitaires pour l'API. Vous souhaitez utiliser les méthodes individuelles disponibles dans l'API et tester chacune d'entre elles de manière isolée. Vous créez ces tests en effectuant une étape de test pour chaque méthode ou ressource disponible dans le contrat de service.

Le moyen le plus simple de créer des tests de composants consiste à utiliser le contrat de service et à le laisser créer les clients. Vous pouvez ensuite piloter les données de chaque cas de test individuel avec des données positives et négatives pour valider que les réponses qui reviennent ont les caractéristiques suivantes:

• La charge utile de la requête est bien formée (validation de schéma)
• La charge utile de la réponse est bien formée (validation de schéma)
• L'état de la réponse est comme prévu (200 OK, jeu de résultats SQL renvoyé, ou même une erreur si c'est ce que vous recherchez)
• Les charges utiles d'erreur de réponse contiennent les messages d'erreur corrects
• La réponse correspond à la ligne de base attendue. Cela peut prendre deux formes:
  • Régression / diff - la charge utile de la réponse est exactement la même d'un appel à l'autre (une approche descendante où vous prenez essentiellement un instantané de la réponse et la vérifiez à chaque fois). Cela peut également être un excellent catalyseur pour identifier le changement d'API (plus d'informations à ce sujet plus tard).
  • Assertion - les éléments individuels de la réponse correspondent à vos attentes (il s'agit d'une approche ascendante plus chirurgicale ciblée sur une valeur spécifique de la réponse).
• Le service répond dans les délais prévus

Ces tests API individuels sont les tests les plus importants que vous pouvez créer, car ils seront exploités dans toutes les techniques de test ultérieures. Pourquoi reconstruire des cas de test alors que vous pouvez simplement référencer ces appels d'API individuels dans tous les différents types de tests à venir? Cela favorise non seulement la cohérence, mais simplifie également le processus d'approche des tests d'API.

Tests de scénario

Les tests de scénario ont tendance à être ce à quoi la plupart des gens pensent lorsqu'ils pensent aux tests d'API. Dans cette technique de test, vous assemblez les tests de composants individuels dans une séquence, un peu comme l'exemple que j'ai décrit ci-dessus pour le service Amazon.

Il existe deux bonnes techniques pour obtenir la séquence:

1. Passez en revue la user story pour identifier les appels d'API individuels en cours.
2. Exercez l'interface utilisateur et capturez le trafic effectué vers les API sous-jacentes.

Les tests de scénario vous permettent de comprendre si des défauts peuvent être introduits en combinant différents points de données.

J'en ai rencontré un exemple très intéressant en travaillant avec un client. Ils ont utilisé une série de services pour connaître le profil financier d'un client, les comptes disponibles, les cartes de crédit et les transactions récentes. Chacun de ces appels API fonctionnait individuellement, mais quand vous les mettez ensemble dans une séquence, ils ont commencé à échouer. La raison en était un simple horodatage, qui, lorsqu'il était renvoyé d'un appel d'API, était dans un format différent de celui attendu dans une demande ultérieure. Ils ne l'ont pas compris lorsqu'ils faisaient des tests unitaires ou des tests de fumée, car ils avaient affirmé qu'un horodatage avait été renvoyé sans spécifier le format. Ce n'est qu'après avoir testé le scénario global qu'il est devenu clair que le transfert de l'horodatage d'un appel à un autre provoquait la panne.

Un autre avantage des tests de scénario est la possibilité de valider le comportement attendu lorsque vos API sont utilisées d'une manière que vous ne vous attendiez pas. Lorsque vous publiez une API, vous fournissez une série de blocs de construction au monde. Vous avez peut-être prescrit des techniques pour combiner ces blocs, mais les clients peuvent avoir des désirs imprévisibles et combiner de manière inattendue des API ensemble pour exposer un défaut dans votre application. Pour vous protéger contre cela, vous souhaitez créer de nombreux tests de scénario avec différentes combinaisons d'API pour protéger votre application contre une panne critique.

Étant donné que les tests de composants constituent l'épine dorsale des tests de scénario, une organisation dispose généralement d'un plus grand nombre de tests de scénario. Ils sont créés lorsqu'une nouvelle fonctionnalité est introduite pour modéliser le parcours du client pour la nouvelle fonctionnalité. En faisant cela, vous pouvez vraiment réduire le temps consacré aux tests, car vous n'avez qu'à créer des tests pour la nouvelle fonctionnalité et vous savez que vous disposez d'une bibliothèque fiable de tests sous-jacents pour détecter tout ce qui est inattendu.

Des tests de performance

Les tests de performance sont généralement relégués à la fin du processus de test, dans un environnement de test spécifique aux performances. En effet, les solutions de test de performances ont tendance à être coûteuses, nécessitent des compétences spécialisées et nécessitent du matériel et des environnements spécifiques. C'est un gros problème car les API ont des accords de niveau de service (SLA) qui doivent être respectés pour pouvoir publier une application. Si vous attendez le tout dernier moment pour effectuer vos tests de performances, le non-respect des SLA peut entraîner d'énormes retards de publication.

Effectuer des tests de performances plus tôt dans le processus vous permet de découvrir les problèmes liés aux performances avant d'exécuter votre cycle de régression complet. Si vous avez suivi le processus de test jusqu'à présent, cela sera en fait assez facile car vous disposez de tous les cas de test sous-jacents dont vous avez besoin pour effectuer des tests de performances. Vous pouvez simplement passer vos tests de scénario, les charger dans votre outil de test de performance, et exécutez-les avec un plus grand nombre d'utilisateurs. Si ces tests échouent, vous pouvez retracer l'échec jusqu'à la user story individuelle et avoir un meilleur niveau de compréhension de ce qui sera affecté. Les gestionnaires peuvent ensuite utiliser cette compréhension pour prendre une décision ou non sur la publication de l'application.

Tests de sécurité

Les tests de sécurité sont importants pour toutes les parties prenantes de votre organisation. Si une vulnérabilité de sécurité est exposée et exploitée, cela peut entraîner une perte de réputation importante et des pénalités financières. Tout comme un utilisateur peut accidentellement utiliser vos API d'une manière inattendue, un utilisateur peut également essayer intentionnellement d'exploiter vos API. Un pirate informatique peut mettre la main sur votre API, découvrir des vulnérabilités et en tirer parti.

Pour vous protéger contre ce type de comportement, vous devez créer des scénarios de test qui tentent d'effectuer ces types d'attaques malveillantes. Vous pouvez tirer parti de vos cas de test existants pour ce faire, car un test de scénario peut fournir le vecteur d'attaque dans l'application. Vous pouvez ensuite réutiliser ce vecteur d'attaque pour lancer vos attaques de pénétration. Un bon exemple de cela consiste à combiner différents types d'attaques de fuzzing de paramètres ou d'injection SQL avec vos tests de scénarios. De cette façon, toutes les modifications qui se propagent dans l'application seront détectées par vos tests de sécurité. Visitez notre page de solutions pour en savoir plus sur Meilleures pratiques de sécurité des API.

Tests omnicanaux

En raison des multiples interfaces avec lesquelles les applications interagissent (mobile, Web, API, bases de données…), vous rencontrerez des lacunes dans la couverture des tests si vous testez l'une d'entre elles de manière isolée, sans les subtilités des interactions complexes entre ces interfaces.

Les tests omnicanaux couvrent de manière exhaustive les nombreuses interfaces de l'application pour assurer une couverture de test complète, en entrelaçant les tests d'API et de base de données dans la validation de mobile et interactions avec l'interface utilisateur Web. Cela signifie passer un test qui exerce l'une des interfaces et la coordonner avec une autre - exécuter vos tests d'interface utilisateur tels que Web (Selenium) ou Mobile (Appium) et les entrelacer avec l'un de vos tests d'API ou de base de données, échanger des points de données à partir du système à travers l'exécution du test. Avec des tests omnicanaux efficaces, vous pouvez créer des cas de test stables et réutilisables qui peuvent être facilement automatisés.

La gestion du changement

Le changement est l'un des indicateurs de risque les plus importants pour votre application. Le changement peut se produire sous de nombreuses formes, notamment:

• Changement de format de message de protocole pour un service
• Éléments ajoutés ou supprimés d'une API
• Changement de code sous-jacent affectant le format des données renvoyées
• Réarchitecture d'un service pour le décomposer en plusieurs parties (extrêmement répandu lorsque les organisations passent aux microservices)

Au fur et à mesure que le changement se produit, vous devez créer des cas de test pour identifier le changement et fournir des plans de correction. Utiliser une solution qui fournit des analyses pour aborder l'impact de ces changements vous permettra de comprendre quel changement s'est produit et de cibler les tests spécifiques qui sont affectés.

Le changement peut ensuite être capturé sous la forme d'un modèle, pour mettre à jour l'un des composants sous-jacents ou des tests de scénario avec de nouvelles fonctionnalités. Étant donné que le reste de vos tests fait référence à ces tests, l'impact du changement sera réduit.

Résumé

Construire une solide stratégie de tests d'API automatisés est le meilleur moyen de s'assurer que vos applications "fonctionnent de la même manière aujourd'hui qu'hier" (c'est plus qu'une simple phrase accrocheuse). Les tests d'API vous permettent de créer un cadre solide pour identifier les défauts sur plusieurs couches de votre application. Ces tests peuvent tous être automatisés et exécutés continuellement, afin que vous puissiez vous assurer que votre application est alignée sur les attentes de l'entreprise tout en étant précise sur le plan fonctionnel. Étant donné que les tests d'API fonctionnent à un niveau beaucoup plus bas que les tests d'interface utilisateur, vous savez que vous aurez une cohérence et que les tests que vous créez dureront longtemps.