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 >>

Les tests API sont excellents, alors pourquoi tout le monde ne le fait-il pas?

Par Marc Lambert

24 mai 2018

7  min lire

Les tests d'API fournissent de nombreuses automatisations maintenables qui peuvent être étendues aux tests de performances et de sécurité, mais elles sont inaccessibles à votre testeur moyen. Découvrez comment réduire considérablement le temps associé à la création de scénarios de test significatifs.

Le passage aux microservices et aux architectures basées sur les API est le moteur d'une innovation significative dans tous les secteurs, mais a également ouvert les entreprises à une couche de risque cachée. Les interfaces humaines (interfaces utilisateur Web et mobiles) ne sont plus les principaux risques commerciaux. Au lieu de cela, les plus grandes vulnérabilités sont cachées dans l'interface non humaine de l'API.

Pour cette raison, les tests d'API sont de plus en plus au centre des préoccupations, mais nous entendons toujours tout le temps, "Qu'est-ce qu'un test API et pourquoi en ai-je besoin ? »

Le résumé rapide est que les interfaces de programmation d'application (API) sont la manière dont les applications communiquent entre elles à l'aide d'une interface commune gérée par un contrat défini. Le moteur de l'adoption des tests d'API est de pouvoir tester la logique métier de l'application de manière stable, indépendamment de l'interface utilisateur. Les tests API permettent des tests plus complets que les tests uniquement en front-end, permettant des tests de performance et de sécurité, par exemple. Les analystes du secteur et les experts agiles, tels que Martin Fowler et Mike Cohn, conviennent que les tests d'API sont la voie à suivre. Alors qu'est-ce qui nous retient?

L'impact des tests inefficaces

Les équipes logicielles veulent passer le temps idéal, et rien de plus, à tester et déboguer pour maximiser le potentiel des projets réussis. Traditionnellement, cependant, il était difficile de réduire ce temps passé aux tests et au débogage, car de nombreux bogues graves et vulnérabilités de sécurité ont été découverts tard dans le cycle de vie du logiciel, y compris après la publication.

Le tableau ci-dessous illustre le moment où des défauts sont introduits dans l'application et l'impact du timing sur le coût de réparation d'un défaut à chaque étape. Comme vous pouvez le voir clairement, le coût des défauts de fin de cycle est important - et cette augmentation du coût provient de nombreux facteurs (c'est-à-dire le temps nécessaire pour diagnostiquer le problème et identifier la cause profonde, le nombre de personnes impliquées dans le processus, et la complexité croissante (et donc le risque) associé à la correction des défauts).

Si vous vous dites: «J'ai déjà vu ça»… vous l'avez probablement! En 1996, Capers Jones a publié la recherche derrière ce graphique et, même avec les changements dans les pratiques de développement logiciel au cours des 20 dernières années, la recherche mise à jour indique qu'elle est toujours pertinente aujourd'hui.

Où nous voulons être: la pyramide des tests

Alors, où allons-nous mal? Nous nous trompons dans notre approche de la qualité - nous devons regarder le tableau ci-dessus et chercher des moyens de shift-left la détection de défaut et trouvez les défauts plus tôt, quand ils sont plus faciles à diagnostiquer et à corriger. Des techniques telles que l'analyse approfondie du code peuvent rapidement découvrir les problèmes de sécurité et de fiabilité intégrés dans la base de code dès que le code est écrit, mais pour pouvoir valider le comportement d'exécution ou fonctionnel, nous devons investir du temps dans la création et la maintenance de tests automatisés - et, dans un monde Agile, nous avons besoin que ces tests soient exécutés en continu une fois qu'ils ont été créés afin qu'ils puissent «décaler» la détection et capturer les régressions dès que de nouvelles fonctionnalités sont implémentées.

La manière idéale d'investir du temps et d'organiser votre portefeuille de tests est souvent représentée par la «pyramide des tests», comme indiqué ci-dessous, en poussant autant d'efforts de test que possible dans la chronologie du développement. Vous commencez par une base de tests unitaires, où les bogues trouvés sont peu coûteux à corriger, puis l'API, l'intégration, les tests de composants et les tests du système et de l'interface utilisateur complètent les niveaux de la pyramide.

Mais alors que des pratiques telles que le développement piloté par les tests (TDD), tests unitaires à un stade précoce, et l'automatisation accrue des tests logiciels devient de plus en plus courante, les équipes logicielles passent encore trop de temps à tester l'interface utilisateur et les systèmes de fin de cycle. Nous avons souvent décrit l'état actuel des choses comme une pyramide inversée (un cornet de crème glacée); Cependant, en examinant de plus près les données, nous constatons un manque important de tests d'API dans l'industrie, donc un verre à martini est plus approprié:

Test d'API pourquoi personne ne le fait

Il est regrettable que cette couche intermédiaire de la pyramide de test soit généralement inutilisée, car il y a des avantages certains à investir dans les tests d'API. Par exemple, les tests peuvent être effectués plus tôt dans le cycle de vie du développement logiciel (dès que les contrats / définitions d'API sont disponibles), ils peuvent être plus facilement automatisés et ils sont fondamentalement moins fragiles aux changements entrants dans l'interface utilisateur / UX de l'application. .

Il est possible de créer des tests au niveau des scénarios en organisant les tests d'API dans des cas d'utilisation courants, et l'automatisation des tests d'API ouvre la voie à des tests de performance et de sécurité à un stade précoce et basés sur des scénarios. En fin de compte, l'investissement dans les tests d'API permet aux équipes de mieux gérer le changement et d'obtenir l'agilité promise par les méthodes de développement modernes. Tester tôt et souvent, qu'est-ce qu'il ne faut pas aimer? Malheureusement, les équipes ont du mal à mettre en œuvre les tests d'API pour diverses raisons.

Qu'est-ce qui limite les tests d'API?

Le plus grand obstacle à l'adoption accrue des tests d'API est la création réelle des tests. Il n'est pas facile de créer des tests significatifs qui fonctionnent au niveau de l'API, encore moins de les assembler pour créer des scénarios de test appropriés. Le manque de connaissances qui existe entre les développeurs et les testeurs est tout aussi fondamental pour empêcher l'adoption des tests d'API. Les tests d'API nécessitent des connaissances et des capacités qui manquent souvent aux testeurs, et les responsables ne souhaitent pas confier aux développeurs des tâches d'intégration ou de test d'API.

Les développeurs travaillent du bas de la pyramide vers le haut et sont à l'aise de travailler au niveau de l'unité. C'est leur code (ou du moins, leur domaine de responsabilité), et les tests unitaires semblent s'intégrer naturellement dans leur flux de travail. La création automatique de tests unitaires a amélioré l'efficacité à ce niveau, et l'industrie du logiciel comprend la nécessité de tests approfondis ici.

Les testeurs, quant à eux, travaillent du haut de la pyramide au niveau de l'interface utilisateur, où les cas d'utilisation et les interfaces sont intuitifs et faciles à mapper aux besoins commerciaux d'origine. Leur vision de l'application est de l'extérieur.

pyramide_test

Les tests d'API se situent entre ces deux rôles et nécessitent à la fois une connaissance de la conception des interfaces et de la manière dont elles sont utilisées. Les testeurs ne fonctionnent généralement pas à ce niveau, car ils considèrent l'API comme code, et bien que les développeurs comprennent les interfaces et les API, ils n'ont généralement pas une vue complète sur la façon dont l'interface va être utilisée en conjonction avec d'autres sous-systèmes. test fonctionel et en dehors de leur rôle.

Jusqu'à récemment, il y avait un manque d'automatisation des outils de test pour aider à combler ce fossé entre les tests unitaires et système, les développeurs et les testeurs. Pour aider l'industrie du logiciel à se rapprocher de la pyramide de test idéale et à évoluer à partir du verre à martini que nous voyons aujourd'hui, nous avons introduit le Générateur de test d'API intelligent à Parasoft SOAtest, notre outil d'automatisation des tests fonctionnels facile à adopter et à utiliser.

Abandonnez le verre à martini

Le Smart API Test Generator est un plugin pour le navigateur Web Google Chrome qui surveille les tests manuels et utilise l'intelligence artificielle pour créer des tests de scénario d'API automatisés, réduisant les compétences techniques requises pour adopter les tests d'API et vous aidant à créer une stratégie de test d'API complète qui évolue à travers l'équipe et l'organisation. Cela fonctionne comme ceci:

Le Smart API Test Generator surveille le trafic en arrière-plan pendant que vous exécutez des tests manuels et l'envoie à son moteur d'intelligence artificielle, qui identifie les appels d'API, découvre des modèles, analyse les relations entre les appels d'API et génère automatiquement des scénarios de test d'API complets et significatifs, pas seulement une série d'étapes de test API.

Rendre les tests d'API plus accessibles

Le générateur de test d'API intelligent rend les tests d'API plus accessibles aux équipes de test, car ces scénarios de test d'API sont créés à l'aide de pratiques de test déjà en cours. Et contrairement aux tests d'interface utilisateur manuels ou même automatisés, l'activité API enregistrée aide les testeurs à mieux collaborer avec les développeurs, avec un seul artefact qui peut être facilement partagé et compris par les deux équipes, et est plus efficace pour diagnostiquer la cause première des défauts qu'un test d'interface utilisateur complexe. cela nécessite l'assemblage de l'ensemble de l'application.

Avec uniquement les tests d'interface utilisateur, en revanche, les développeurs et les testeurs ont tendance à rester cloisonnés dans leurs techniques de communication et de débogage, ce qui entraîne souvent de longs temps d'attente et des itérations entre l'introduction des défauts, la détection des défauts et la résolution des défauts.

La puissance des scénarios de test API

Les interactions API enregistrées lors des tests d'interface utilisateur nécessitent une sorte d'organisation en scénarios ou cas d'utilisation. L'intelligence artificielle de SOAtest Smart API Test Generator permet de créer des scénarios basés sur les relations entre les différents appels d'API.

Sans le Smart API Test Generator, qui en tire parti, les utilisateurs devraient passer du temps à étudier leurs cas de test, à rechercher des modèles et à créer manuellement les relations pour former chaque scénario de test. En outre, Parasoft SOAtest fournit une méthode intuitive et basée sur l'interface utilisateur pour décrire les assertions, permettant aux testeurs d'exécuter une logique d'assertion complexe sans avoir à écrire de code. Sans cela, les utilisateurs codent chaque assertion à la main et ils pourraient en manquer une ou la créer de manière erronée. Ces tests d'API peuvent ensuite être étendus à l'aide d'outils visuels et d'une logique assistée par outils pour créer des suites de tests à plus grande échelle.

Conclusion

Bien que les équipes logicielles reconnaissent le désir d'atteindre une distribution idéale des tests unitaires, d'API et d'interface utilisateur, la réalité est que votre équipe moyenne effectue un travail moyen de tests unitaires et s'appuie toujours sur des tests d'interface utilisateur et de système de stade avancé. Les tests d'API fournissent un mécanisme de communication idéal entre les développeurs et les testeurs avec un haut niveau d'automatisation maintenable qui peut être étendu aux tests de performance et de sécurité.

Déplacer ces tests vers la gauche et les exécuter plus tôt dans le cycle de vie du logiciel signifie détecter précocement les défauts de sécurité et d'architecture critiques, là où ils sont plus faciles à diagnostiquer et moins risqués à corriger. Tirer parti de l'automatisation fournie par Parasoft SOAtest's Générateur de test d'API intelligent, Les tests d'API sont plus accessibles et le temps associé à la création de scénarios de test significatifs peut être considérablement réduit.

Accélérez la création de tests d'API grâce à l'intelligence artificielle

Par Marc Lambert

Vice-président des produits chez Parasoft, Mark est chargé de s'assurer que les solutions Parasoft apportent une valeur réelle aux organisations qui les adoptent. Mark travaille chez Parasoft depuis 2004, travaillant avec un large éventail de clients de Global 2000, des implémentations technologiques spécifiques aux initiatives plus larges d'amélioration des processus SDLC.

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