Découvrez comment intégrer facilement l'analyse statique, les tests unitaires et d'autres méthodes de test de logiciels C et C++ dans votre pipeline CI/CD. Inscrivez-vous pour la démo >>

Un micro-manifeste sur les tests d'API pour inspirer et recharger votre organisation

Par Ed Kit

14 août 2019

6  min lire

Dans cet article, Ed Kit, auteur du blog invité, PDG de Software Development Technologies, déclare qu'il est temps pour tout le monde, partout, d'accepter le besoin de tests d'API et nous fournit 13 conseils d'inspiration pour développer l'énergie nécessaire.

Après 25 ans à diriger de nombreux projets d'ingénierie logicielle dans de petites et grandes entreprises Fortune 200, j'en suis venu à une réalisation majeure. Les tests d'interface de programme d'application (API) sont plus importants que les tests d'interface utilisateur (UI). En termes de manifeste, Tests d'API sur les tests d'interface utilisateur. Ce n'est pas pour diminuer la valeur des tests d'interface utilisateur - je souhaite simplement vous inciter à valoriser davantage l'élément de gauche (test d'API)!

Nous pouvons enfin combler l'écart de productivité des tests d'API et offrir aux équipes de développement et de test des capacités de niveau équivalent ou supérieur à celles des tests d'interface utilisateur et unitaires. Une comparaison peut être faite entre les tests d'API et les tests d'interface utilisateur pour critiquer assez à quel point les tests d'API sont loin d'être exécutés de manière productive dans le cycle de vie global. Chaque niveau de test présente des défis uniques, des approches de conception uniques et des outils uniques, mais les connaissances actuelles, la technologie, la formation et les nouveaux services tiers ont changé cela pour les tests d'API.

Nous aborderons bientôt les faits et recommandations inspirants importants, mais tout d'abord, voici un bref aperçu des raisons pour lesquelles les tests d'API sont si importants maintenant.

Présentation des tests d'API

Les applications communiquent efficacement et puissamment entre elles en utilisant un langage commun ou une interface de programme d'application. Les tests au niveau de l'API sont une partie essentielle des tests de logiciels techniques, entre les tests d'interface utilisateur et les tests unitaires. Avec les tests d'API, les API sont testées directement pour déterminer si elles répondent aux attentes en matière de fonctionnalité, de fiabilité, de performances et de sécurité. Lorsqu'une API n'a pas été correctement testée et ne se comporte pas comme elle le devrait, des défauts de qualité, de confidentialité et de sécurité (potentiellement très importants) se produisent.

Au niveau de l'API, nous pouvons automatiser les tests pour:

  • Services Web SOA (XML, WSDL, SOAP, GZIP, etc.)
  • Services Web RESTful (JSON, RAML, Swagger / Open API, WADL)
  • Microservices (Kafka, RabbitMQ, MQTT, WebSockets, etc.)
  • Protocoles (HTTP, JMS, MQ, TCP / IP, SMTP, Tibco, etc.)
  • SQL (JDBC, ODBC...)
  • Formats de message (Swift, EDI, etc.)

Cela semble écrasant? Test des API est technique, et peut donc sembler un peu effrayant au début - c'est-à-dire jusqu'à ce que nous comprenions ce qui est vraiment impliqué. Je pense que les tests d'API sont le type de test le plus important qui a été régulièrement sous-performé dans la plupart des organisations.

La bonne nouvelle est qu'en tant qu'industrie, nous considérons l'API dans une perspective de test maintenant - nous n'avons pas à décider entre RESTful et SOAP. Nous devons simplement découvrir les informations relatives à l'API spécifique en cours de test.

En tant que PDG d'une entreprise de test en affaires et surveillant les tendances depuis 25 ans, je suis heureux d'annoncer que les tests d'API sont désormais la forme de test la plus demandée dans mon entreprise, Software Development Technologies (SDT). Cette année marque en fait un point de basculement pour SDT. Je ne l'ai jamais prédit, mais après 25 ans à fournir tous les types de services de test possibles, c'est la première année que nous faisons plus de tests d'API pour les clients que tout autre type de test.

Cela peut sembler évident, mais comme la communication avec les applications se produit au niveau de l'API, il s'agit du niveau le plus efficace pour effectuer les tests. Les tests conçus, implémentés et exécutés au niveau de l'API interagiront directement avec les API sous-jacentes. Duh. Et pourtant, tant d'équipes ne testent pas les API - parfois le résultat est que le client effectue les tests pour nous, à leur grand dam.

Voici donc mes 13 points d'inspiration et mes recommandations sur les tests d'API, que j'ai classés ci-dessous.

Test API: critique pour le client

1. L'Internet des objets (IoT) touche tout le monde aujourd'hui et, comme l'interface utilisateur typique n'existe pas là-bas, les tests d'API sont essentiels. Les tests d'API sont nécessaires pour bien faire le travail de test IoT.

2. Les pirates attaqueront les logiciels vulnérables au niveau de l'API, de sorte que les tests de sécurité doivent être effectués au niveau de l'API. Nous protégeons le client en effectuant des tests d'attaque de pénétration malveillante, etc. au niveau de l'API.

3. Avec Agile, la rétroaction rapide bat la rétroaction plus lente. Les tests d'API fournissent un retour rapide, de sorte que le client n'a pas à attendre une livraison de qualité.

Tests d'API: essentiels pour l'efficacité du cycle de vie

4. Les tests d'API peuvent être conçus plus tôt dans le processus de développement, avant que l'interface utilisateur ne soit connue. Les tests par rapport à l'interface utilisateur prennent plus de temps que les tests au niveau de l'API. Qui peut se permettre les retards du cycle de construction en raison de la durée d'exécution des tests d'interface utilisateur plus longue?

5. Lorsque nous exécutons des cas de test d'API avant les cas de test d'interface utilisateur, nous pouvons ignorer les cas de test d'interface utilisateur inutiles qui n'ajoutent aucune valeur.

6. Les tests API sont moins fragiles que les tests d'interface utilisateur et résistent donc mieux aux changements logiciels au fil du temps.

7. Les tests d'API ont tendance à être plus faciles à déboguer, en raison de leur objectif.

8. Beaucoup moins de tests d'interface utilisateur sont nécessaires lorsque vous disposez d'un nombre suffisant de tests d'API. Les cas de test de l'interface utilisateur ont toujours leur place importante.

9. Les tests API ont une durée de vie plus longue que les tests d'interface utilisateur. Lorsque les tests d'API ont été mis en place, ils ont tendance à rester à jour plus longtemps que les tests d'interface utilisateur. En effet, les approches et technologies actuelles mènent à des solutions plus maintenables sur le long terme.

10. Vous pouvez intégrer des tests d'API avec CI / CD / CT (intégration continue / livraison continue / tests continus) dans votre processus de développement - chez SDT, nous utilisons généralement Jenkins.

Test d'API: il est essentiel de faire et de bien le faire

11. Trouvez le bon propriétaire pour vos tests d'API. Dans une étude récente, 80% des développeurs ont déclaré que l'organisation de test est responsable des tests API, et 70% des testeurs ont déclaré que l'organisation de développement est responsable des tests API! Cela ressemble à une blague - mais ce n'est pas une blague.

Dans la plupart des organisations, il n'est pas réaliste de s'attendre à ce que les développeurs possèdent les tests d'API. Si vos développeurs se sont approprié cela et font un excellent travail - fantastique - laissez-les faire, mais d'après mon expérience, dans la plupart des organisations, ils ne le font pas maintenant et ne commenceront pas à le faire de si tôt. Leur assiette est pleine - s'ils font bien les tests unitaires, soyez reconnaissants.

Peut-être que l'équipe de test devrait posséder des tests d'API, mais mon expérience a montré que les testeurs ne savent pas comment tester les API - techniquement, cela dépasse largement les capacités et la bande passante de la personne moyenne de l'équipe de test moyenne.

Envisagez de vous associer à un fournisseur de services tiers indépendant et expérimenté spécialisé dans les tests d'API - quelqu'un qui peut démontrer ses compétences et son expérience avec les tests d'API et les technologies associées. Un partenaire, passionné par les tests d'API, le processus et la technologie, peut concevoir et mettre en œuvre le cadre de test et vous aider à être opérationnel rapidement. À tout le moins, cela vaut la peine d'avoir une conversation avec un partenaire potentiel pour déterminer la valeur qu'il peut apporter à la table.

12. Il est important de trouver les bons outils pour les tests d'API. Les outils de test d'API ont été faibles dans le passé, mais cela a depuis été résolu.

Les outils de test manuels peuvent vous aider à démarrer les tests d'API. Nos équipes de services de test SDT ont utilisé Postman pour les tests manuels initiaux - pour explorer l'API et aider à la conception des tests API. Mais les tests manuels sans automatisation sont une formule pour l'échec - l'exécution répétée des mêmes tests manuellement ne répondra pas aux exigences du monde Agile d'aujourd'hui et ne fournira pas une couverture suffisante pour les complexités des logiciels d'aujourd'hui.

Beaucoup sont familiarisés avec l'utilisation des tests de mots-clés pour les défis clés de l'entreprise de test associés au cloud, au Web, au client / serveur, à Java, au mainframe, aux appareils intégrés, aux appareils mobiles et au bureau, mais cette excellente approche fonctionne également pour les tests d'API!

Les mots-clés sont les éléments de base réutilisables pour la conception de tests basés sur les mots-clés. Un scénario de test de mot-clé est une séquence de mots-clés avec des paramètres, et les mots-clés définissent des actions qui dirigent ou obtiennent des informations à partir d'éléments d'application. Un mot-clé de niveau supérieur se compose généralement de mots-clés de niveau inférieur. La réutilisation des mots-clés garantit un développement rapide des tests et une maintenance simplifiée. Les API peuvent être considérées comme des éléments constitutifs, tout comme les mots clés.

L'outil open source Robot Framework ajoute un paradigme de cas de test piloté par mots-clés pour fournir une réutilisation significative des artefacts (mots-clés de bas niveau, mots-clés de haut niveau, cas de test et ensembles de tests) et une bibliothèque intégrée pour réduire l'effort de développement de tests et simplifier maintenance.

Tout comme Selenium est un plug-in de Robot Framework qui pilote le comportement des applications Web et valide les résultats à l'aide d'une riche bibliothèque de méthodes (mots-clés de bas niveau), HTTPLibrary et la bibliothèque de requêtes sont des plug-ins qui stimulent les tests d'API. Le langage Python est souvent utilisé pour créer des mots-clés personnalisés de bas niveau.

13. Lorsque vous êtes prêt, vous trouverez les principaux facteurs qui indiquent qu'il est temps d'envisager une solution d'entreprise.

Tout d'abord, le désir d'atteindre des niveaux de couverture de test plus élevés pour des cas d'utilisation plus complexes, par exemple des interfaces non SOAP et REST, des microservices, des ESB ou des bases de données. À ce stade de maturité, les organisations se tournent vers des solutions de test d'API d'entreprise. Lorsque vous êtes prêt pour une solution commerciale complète pour les tests d'API, consultez SOAtest de Parasoft.  Parasoft SOAtest est largement reconnu comme la principale solution de niveau entreprise pour les tests d'API, et vous aidera à passer au niveau supérieur des tests d'API, pour une mise à l'échelle via des technologies et des fonctionnalités de niveau supérieur.

Résumé

Les tests d'API connaissent une poussée que les tests d'interface utilisateur ont déjà connue. Peut-être que votre plus grande opportunité actuelle pour améliorer la qualité des logiciels est le test des API. Vous voulez faire quelque chose de grand pour votre entreprise ? Abordez les tests d'API - soyez le champion - utilisez ce blog pour vous aider à défendre votre cause - écrivez votre propre micro-manifeste pour votre entreprise et faites-moi savoir comment ça se passe. Je suis sérieux - écrivez-moi à kit@sdtcorp.com.

Lectures et références connexes:

Comment choisir la bonne solution de test d'API

Par Ed Kit

Leader international des logiciels avec plus de 25 ans d'expérience en génie logiciel, Ed a supervisé la mise en place de l'automatisation des tests et des centres d'excellence pour UGS / Siemens PLM Software, Southwest Airlines, PepsiCo, California State Compensation Insurance Fund, JC Penney, WellPoint, et bien d'autres. autres petites entreprises ainsi que Fortune 500. Titulaire d'un brevet d'automatisation des tests logiciels et défenseur passionné des tests API. Gestionnaire principal d'une grande organisation responsable des tests indépendants, des performances, des tests système, de la publication de logiciels, des outils, de l'ingénierie logicielle, des mesures, de la formation et de la qualité. Fondateur et président de Software Development Technologies (SDT), une société fournissant des services de tests pratiques de classe mondiale.

Recevez les dernières nouvelles et ressources sur les tests de logiciels dans votre boîte de réception.