Tirer parti de l'automatisation pour créer des suites de tests d'API à couverture élevée

Les interfaces de programmation d'application (API) sont la couche de service des applications. Ils connectent la couche de données et la couche de présentation (UI) et déterminent la manière dont les utilisateurs interagissent avec les applications.

Si les API ne répondent pas correctement à l'activité des utilisateurs, l'application est interrompue. C'est aux développeurs et aux testeurs de s'assurer que les API connectées fonctionnent correctement avec leur application.

Les tests d'API font partie intégrante de l'identification des défauts à plusieurs couches de votre application et garantissent une expérience client transparente. Types de tests d'API consistent à

• Tests de service
• Essais contractuels
• Tests de composants
• Tests de scénario
• Tests de charge / performance
• Tests de sécurité
• Tests omnicanaux

La réalisation de tests d'API est difficile car elle nécessite une approche technique pour concevoir les cas de test par rapport aux différents formats et protocoles de message. Cela nécessite également une compréhension des règles métier de l'organisation pour utiliser correctement les API correctes ensemble. Essayer de tester les API à l'aide d'une approche manuelle prend du temps et peut retarder les tests jusqu'à la fin du cycle de développement.

Les tests API automatisés vous permettent de protéger vos applications contre l'inconnu. Il expose les erreurs tôt, évalue la force de la construction et conduit à des versions logicielles plus rapides. Étant donné que les tests d'API peuvent être automatisés et exécutés en continu, vous pouvez vous assurer que votre application est alignée sur les attentes de l'entreprise tout en vérifiant la précision fonctionnelle.

Les avantages et les inconvénients des tests d'API automatisés

Avec le droit Outils de test d'API et les processus en place, votre équipe bénéficiera de tous les avantages de l'automatisation. Sans eux, les tests d’API peuvent rapidement devenir écrasants.

Avantages

• Fournit une automatisation maintenable d'un scénario de bout en bout.
• Ouvre les canaux de communication entre le développement et le test.
• Réduit le temps de diagnostic et de réparation.

Inconvénients

• Les testeurs ne savent pas comment tester l'API ou comment les API sont utilisées.
• Nécessite des compétences et des outils spécialisés pour obtenir une couverture complète des tests.
• Personne ne veut le faire.

Vous pouvez surmonter ces défis en incorporant une technologie de test avancée dans vos tests existants. Tout d'abord, regardons la création de tests d'API.

Le défi de la création de tests API

L'un des plus grands défis de l'établissement d'une pratique d'automatisation des tests d'API est de créer des tests d'API. Un obstacle à la mise en route - ou à l'extension d'une suite de tests d'API existante - consiste à proposer des tests appropriés.

Une partie de ce problème est la connaissance du domaine requise pour écrire des tests d'API basés uniquement sur des connaissances techniques ou des spécifications d'API documentées, le cas échéant. Ce n'est pas le domaine habituel des testeurs. La plupart des développeurs possédant les connaissances requises ne sont pas impliqués dans les tests à ce niveau. Ils ont des priorités ailleurs.

Considérez les deux approches complémentaires:

• Approche descendante. Les scénarios de test sont créés à partir de l'utilisation et des tests réguliers des applications.
• Une approche en profondeur. Les tests sont basés sur l'intention de la conception.

Combinaison d'approches descendantes et ascendantes pour la création de tests API

La plupart des applications fournissent et utilisent plusieurs API. Certains sont connus. Certains pourraient même être documentés. Il y a souvent de nombreuses pièces mobiles sous le capot qui rendent difficile le démarrage des tests d’API.

Dans l'approche descendante, les interactions API sont découvertes via l'automatisation des outils dans le cadre de l'utilisation et de l'intégration habituelles des tests.

L'autre angle d'attaque, une approche ascendante, consiste à créer des tests d'API basés sur l'intention de conception. Cela fait généralement partie des tests de composants et est assisté par des outils.

La combinaison des approches descendante (tests d'intégration) et ascendante (test des composants) permet de surmonter l'obstacle à la création de tests et augmente la couverture des tests API. Reportez-vous à l'illustration ci-dessous.

Création de tests API par utilisation

L'un des meilleurs moyens de capturer des scénarios de test d'API consiste à utiliser l'utilisation existante du produit à la fois en production et en test. En exploitant des enregistrements et une lecture intelligents, il est possible de créer des tests et des scénarios réutilisables.

À l'aide d'outils tels que Parasoft Recorder, vous pouvez capturer et modéliser les interactions API qui se produisent sous le capot de l'application. Ensuite, le générateur de tests Smart API de SOAtest utilise l'intelligence artificielle pour organiser le trafic complexe en modèles d'utilisation de l'API. Cela permet de créer une suite de tests API à l'aide de tests d'interface utilisateur Web pour extraire, filtrer et créer des scénarios de test API.

SOAtest utilise ensuite l'IA pour identifier des modèles et établir des relations de données pour créer le modèle de test d'API. Vous pouvez modifier et réutiliser le modèle avec des variantes. Ces tests peuvent être exploités pour les tests de sécurité et de performance. Plus important encore, une fois créés, ces tests sont découplés de l'interface utilisateur et de l'application sous-jacente, et ses dépendances peuvent être exercées à partir des seuls tests d'API.

L'enregistrement et l'analyse du trafic API dans les scénarios de test s'étendent aux tests automatisés de l'interface utilisateur avec des outils tels que Selenium. Toute utilisation de l'application qui initie des appels d'API, qu'elle soit manuelle ou automatisée, peut être utilisée pour créer des tests d'API. Il est également possible de lier des scénarios enregistrés à des exigences de traçabilité.

Une fois enregistrés, ces scénarios peuvent être étudiés et modifiés dans SOAtest comme indiqué ci-dessous.

SOAtest détecte les différents appels d'API et l'interaction de données qui se produit. Il est alors possible de modifier le scénario et les charges utiles des données selon les besoins. Une fois les modèles compris, des assertions peuvent être insérées dans le scénario pour vérifier les valeurs et les comportements corrects.

La possibilité de créer une suite de tests API prête à l'emploi basée uniquement sur les techniques de test existantes permet de créer rapidement des tests avec la possibilité de les réutiliser et de les étendre. C'est un raccourci à travers l'un des plus grands obstacles au test d'API.

Création de tests API par (Service) Design

Vous pensez peut-être: «Nous ne connaissons pas la conception des API. La plupart d'entre eux ne sont pas documentés! Dans la plupart des cas, c'est correct. Cependant, il est toujours possible de rassembler des tests d'API à partir d'informations existantes pour aider à étendre la couverture des tests d'API de bas en haut, en examinant les définitions de service et les contrats qui sont explicites ou implicites dans l'application.

En termes de spécification API, la plupart des services ont une définition dans un document Swagger ou WSDL. SOAtest peut lire ces définitions et créer un modèle de scénario de test API. Il comprend un cas de test pour tous les clients de la définition. Vous pouvez modifier et manipuler le modèle pour créer des tests API significatifs.

SOAtest fournit de nombreuses options pour créer des tests sans script à partir du modèle, y compris des données paramétrées basées sur des nombres aléatoires ou des résultats de tests précédents, comme illustré dans l'exemple ci-dessous.

À l'aide de techniques simples de copier-coller, de création de tests sans script et d'une gestion flexible des données de test, SOAtest offre un moyen simple de créer des suites de tests. Il ne vise pas à remplacer l'approche descendante, mais plutôt à la compléter. Lorsque les tests manuels ou d'interface utilisateur manquent des parties importantes d'une API (informées par les résultats de la couverture), l'approche ascendante comble ces lacunes. Cependant, il est difficile de déterminer ce qu'il faut tester et ce qui manque sans une compréhension de la couverture.

Comprendre votre couverture de test

La couverture signifie plusieurs choses selon le contexte. En règle générale, il s'agit de la couverture du code, de l'API et des exigences. Vous devez comprendre tout cela pour avoir une image claire de la complétude de vos efforts de test.

• Tests unitaires. Le problème est la couverture du code. Quelle part du code un test est-il associé à son exécution?
• Apis. Il est important de savoir lesquels sont testés et dans quelle mesure chaque API a été utilisée.
• Exigences. Chaque exigence doit avoir un test prouvant qu'elle est correctement mise en œuvre.

Ce sont des problèmes qui se chevauchent et qui comptent à différents moments du cycle de vie du projet. Par exemple, si vous suivez la couverture des tests d'API, il est important de vous assurer que les tests couvrent correctement les API et d'augmenter les tests existants là où ils font défaut. La meilleure façon de voir cela est à partir de la définition du service, comme indiqué dans l'image ci-dessous.

SOAtest garde une trace de chaque test exécuté et des API couvertes : entièrement, partiellement ou pas du tout. Savoir où les tests manquent nous permet d'orienter nos efforts vers un test ascendant basé sur la définition du service, ou éventuellement vers un nouveau test basé sur l'interface utilisateur, le cas échéant. Il indique également où les tests échouent (en rouge), attirant notre attention sur les tests qui nécessitent des mises à jour ou qui présentent un problème lors de l'implantation.

Parasoft DTP (Development Testing Platform) agit comme un référentiel central et un hub pour les résultats de diverses pratiques de test et fournit une vue de haut niveau de la situation du projet en termes de différents types de couverture, comme indiqué dans le tableau de bord suivant.

Cette vue intègre les résultats agrégés de l'analyse de code statique, des tests unitaires, de l'API et des tests d'interface utilisateur manuels et automatisés. C'est la gamme complète de la pyramide des tests. Il fournit une image complète de la couverture sous tous les aspects: API, exigences et couverture du code.

Considérez la couverture des exigences en termes de user stories enregistrées dans JIRA. Le tableau de bord de test fonctionnel (illustré ci-dessous) comprend un widget JIRA Story Status, qui est un moyen de suivre la couverture des exigences.

En examinant de plus près l'état JIRA, les informations de survol de la souris indiquent le nombre de tests réussis, échoués, incomplets ou manquants sans tests.

Vous pouvez approfondir le rapport de traçabilité détaillé pour découvrir les exigences manquantes, les échecs de leurs tests, etc.

Vous pouvez approfondir votre recherche en explorant le rapport de traçabilité pour comprendre quels tests touchent à cette histoire.

En outre, vous pouvez lier cette couverture aux API et à la couverture de code si nécessaire. Vous pouvez accéder aux tests d'API à partir d'ici pour déterminer où des modifications sont nécessaires et quels tests supplémentaires sont nécessaires. Cette vue globale et agrégée de la couverture fournit l'image la plus complète de l'état des tests. La couverture des tests «augmente» avec le temps à mesure que les développeurs convergent vers une application terminée, et le nouveau code est «couvert» par des API et des tests unitaires créés pour les exigences associées.

Résumé

L'importance des tests d'API est reconnue par les organisations de développement de logiciels, mais elles ont souvent du mal à adopter pleinement la pratique. Une partie de la difficulté consiste à créer un ensemble de tests, car la création de tests manuels est complexe et nécessite des connaissances techniques approfondies. Même les équipes qui adoptent les tests d'API sont mises au défi d'augmenter la couverture de leurs tests d'API, car beaucoup d'entre eux ne sont pas documentés.

Des outils de test fonctionnel avancés tels que SOAtest peuvent aider à automatiser la création de tests d'API à l'aide d'une approche descendante basée sur l'analyse du comportement en cours d'utilisation à partir de tests manuels et de l'utilisation régulière des applications. Cette génération de tests intelligents aide les équipes à créer rapidement et facilement des tests à partir de leurs pratiques existantes.

Une approche ascendante simultanée et complémentaire est possible en utilisant l'automatisation SOAtest pour créer des tests sans script à partir de définitions de service. En plus d'une analyse complète de la couverture, vous pouvez étendre la couverture des tests d'API au fil du temps en utilisant des techniques descendantes et ascendantes. Étant donné que les tests d'API fonctionnent à un niveau beaucoup plus bas que les tests d'interface utilisateur, vous pouvez être sûr que les tests cohérents et complets que vous créez dureront longtemps.