Comment tester les API pour améliorer la qualité des applications
Les API exécutent des applications, il est donc essentiel de les tester et ne pas seulement vérifier leur connectivité. Étudiez les basiques pour savoir quand appliquer les tests. Découvrez les avantages de confier cette tâche au département assurance et qualité.
Le test d’API demande un effort important à l’équipe assurance et qualité. Il faut les intégrer au planning de vérification, à chaque fois que vous travaillez sur des applications Web ou mobiles, car ces interfaces sont essentielles pour l’échange de données entre applications.
Prenons l’exemple des nombreux services bancaires mobiles et en ligne que les consommateurs utilisent chaque semaine. Elles reposent sur le transfert de données d’un lieu de stockage à un autre. Sans API, les applications sont moins efficaces, moins intégrées et donc moins utiles.
Dans de nombreuses équipes de développement, les tests Q&A incombent aux développeurs. Cependant, il est bénéfique pour l’équipe d’assurance et qualité d’apprendre à effectuer lesdits tests sur vos API. Cette étape contribue à la qualité, la fiabilité et au succès commercial d’une application.
Quand tester ses API ?
Les tests d’API doivent s’inscrire dans une stratégie continue d’analyse de la qualité des applications.
Effectuez des tests d’API fréquemment, ou en continu, et selon des cycles courts. Tester les API souvent, au moins après toute modification significative du code. Il convient d’effectuer des tests rapides pour s’assurer du fonctionnement (ou non) de l’API, puis d’autres à chaque modification de l’application. Il faut aussi suivre les changements dans la base de données associée et vérifier que les deux composants fonctionnent correctement au sein de l’application.
Quoi tester ?
L’essentiel est de vérifier qu’une API est capable de se connecter, qu’elle envoie et reçoit les données.
L’équipe d’assurance qualité doit inclure des tests de sécurité. Les messages API doivent vérifier la sécurité aux deux extrémités d’un échange de données.
En plus de la connectivité et de la sécurité, il faut vérifier la validité de la base de données. Si les API autorisent des données non valides pendant un échange, elle et les applications sont susceptibles de tomber en panne à cause d’une source inattendue. La validité des données est essentielle pour la communication des API, des bases de données et des applications.
En général, les développeurs choisissent de transmettre les informations d’une base de données à une autre en utilisant le format JSON. Bien que la plupart des SGBD SQL ou NoSQL le supportent nativement, il faut s’attendre à des anomalies dans certaines tables. Tout dépend de la qualité d’indexation proposée par l’éditeur.
Pour vérifier ces domaines, assurez-vous de tester également les conditions d’erreur. Le développeur de l’API doit partager les codes d’erreur qui seront générés lorsque le système rejette un message entrant. Les raisons peuvent être diverses : un problème de sécurité ou de données, un format de message inadéquat ou un terminal API hors service.
L’ingénieur Q&A doit vérifier que l’API renvoie les données que la DSI attend d’un système à l’autre. De nombreuses applications ont des composants intégrés, tels qu’un portail web et une application mobile. Une API sert probablement les deux composants, il faut donc valider les fonctions de l’application dans les deux systèmes et s’assurer que les données correspondent – ce qui n’est pas toujours une garantie.
Si une application comprend à la fois une option web et mobile, les programmeurs codent souvent ces systèmes séparément. De même, ils peuvent avoir codé les processus différemment, ce qui nécessite des tests distincts pour chaque plateforme. Cette configuration provoque des maux de tête pour les testeurs, car les résultats de l’application fonctionnent probablement de la même manière. Vérifiez que les données qui s’affichent dans l’une correspondent à l’autre et que les deux systèmes restent synchronisés.
Une fois que vous avez couvert les bases du test de l’API, passez à des configurations plus sophistiquées. De nombreux outils de test d’API comprennent des ensembles de trames de test préprogrammées. Les équipes d’assurance qualité peuvent modifier et utiliser ces frameworks pour créer des tests d’API automatisés. Par exemple, l’outil de développement Postman comprend un vaste ensemble de snippets JavaScript que les professionnels de l’assurance qualité peuvent utiliser individuellement ou conjointement.
Dans tous les cas, les programmeurs doivent travailler de concert avec l’équipe assurance et qualité. Ensemble, ces deux parties doivent s’assurer de produire une documentation suffisamment fournie. En effet, une interface de programmation sera d’autant plus pertinente s’il est réutilisable dans un autre contexte.
De même, l’API peut être destinée à communiquer avec des applications externes, celles de partenaires par exemple. Dans ces conditions, les vérifications doivent être rigoureuses pour assurer une continuité de service aux consommateurs de l’interface.
À lire également :
Les bases du test des API RESTful
Le test d’API RESTful insuffle au sein de l’entreprise une culture de tests en continu et d’une forme de responsabilité de l’équipe. Greg Sypolt passe en revue les composants clés d’un programme de test.
Quelques outils pour tester ses API
Si vous disposez d’une automatisation des tests fonctionnels pour votre application, vous pouvez créer une suite de tests axée sur la vérification de l’exécution de l’API, le tout sans effort supplémentaire. Ils peuvent probablement couvrir les données et les conditions d’erreur en les couplant avec les tests fonctionnels existants.
Toutefois, les étapes de sécurisation ne doivent pas s’appuyer totalement sur des processus automatisés.
Les équipes d’assurance qualité n’ont pas forcément besoin d’outils pour effectuer les tests de l’API : elles peuvent travailler avec du code ou dans l’application. Mais de nombreux outils offrent des capacités très utiles pour cette tâche. Postman, API Fortress, SoapUI et SmartBear sont de ceux-là tout comme les outils d’AWS et d’autres éditeurs.
Il existe des options peu coûteuses pour les DSI, qui peuvent commencer par les bases et voir si les tests d’API apportent une valeur ajoutée, puis passer à des outils plus sophistiqués si nécessaire.