Découvrez comment la solution Parasoft Continuous Quality permet de contrôler et de gérer les environnements de test pour fournir des logiciels de haute qualité en toute confiance. Inscrivez-vous pour la démo >>
Temps de lecture : 8 minutesIl y a quelques semaines, nous avons lancé une nouvelle fonctionnalité en Parasoft SOAtest appelée Générateur de test d'API intelligent. J'étais geek. Cette technologie est légitimement révolutionnaire - elle utilise l'intelligence artificielle pour convertir les tests manuels d'interface utilisateur en tests API automatisés, vous n'avez donc pas besoin d'expertise dans les tests d'API ou même de la capacité d'écrire du code pour commencer. Tout est sans script, et il est activé via un simple plugin pour Chrome, vous n'avez donc pas besoin d'installer un grand ensemble d'outils pour l'utiliser.
Mais lors de la conférence de test de STAREAST en mai, où j'ai longuement parlé de l'excellence de cette technologie, j'ai continué à rencontrer des gens qui me demandaient en quoi c'était différent des technologies d'enregistrement et de relecture, qui existent déjà sur le marché.
La réponse est l'intelligence artificielle et l'apprentissage automatique… mais pourquoi? L'IA pour l'intelligence artificielle n'a pas de sens - pourquoi avons-nous besoin d'ajouter l'intelligence artificielle aux tests d'API? Eh bien, nous en avons besoin car les tests d'enregistrement et de relecture ne suffisent tout simplement pas. Je vais entrer dans cela plus dans un peu.
Pour vraiment faire évoluer l'adoption des tests d'API et résoudre les problèmes rencontrés par les équipes de test au rythme du développement, vous avez besoin de plus! Au lieu de simplement collecter le trafic, de l'enregistrer et de le lire, nous voulions être en mesure d'aider automatiquement les utilisateurs à identifier et à organiser l'activité d'API capturée en tests significatifs, réutilisables et extensibles. Nous devions abaisser la barre d'adoption des tests d'API et impliquer davantage de testeurs.
Mais d'abord, laissez-moi vous expliquer pourquoi c'est si important.
Historiquement, les organisations se sont appuyées sur les tests d'interface utilisateur comme principale pratique de test, car il est facile et intuitif à définir et à exécuter, et facile à automatiser, du moins au début. Il y a une faible barrière à l'entrée et elle peut évoluer à travers une grande équipe de testeurs.
Mais le défi de cette dépendance exclusive sur les tests manuels et d'interface utilisateur réside dans les coûts cachés. Quiconque a travaillé avec Selenium sait que les choses deviennent difficiles lorsque l'interface utilisateur change et que vous devez mettre à jour vos scripts. En fait, nous avons constaté que jusqu'à 80% du temps de test est passé à exécuter des tests manuels d'interface utilisateur ou à réparer des tests d'interface utilisateur automatisés qui ont échoué à la suite d'un changement d'application. En plus de tout cela, les tests d'interface utilisateur ne peuvent pas être exécutés tant que l'application complète n'est pas disponible - et si un défaut est découvert, il y a un coût élevé de retouche car l'application doit être déchirée, réparée et réassemblée avant que le test puisse Continuez. Souvent, cette détection de défaut de cycle tardif entraîne des retards de libération importants et augmente le coût total des tests.
Pour compléter et réduire la dépendance aux tests d'interface utilisateur, les organisations peuvent tirer parti des tests d'API, qui résolvent bon nombre de ces problèmes en fournissant des scénarios maintenables de bout en bout qui peuvent être réutilisés pour plus que de simples tests fonctionnels. Les tests d'API créent un bon canal de communication entre les développeurs et les testeurs, car ils aident à documenter le comportement de l'API en termes concrets et réalistes. Déplacer le diagnostic et la correction des bogues et des vulnérabilités de sécurité détectés par les tests d'API à un stade plus précoce du cycle de vie a un grand avantage pour atteindre les objectifs de calendrier et de qualité.
Les organisations, cependant, ont eu du mal à adopter Méthodes de test des API car même les outils de test d'API les plus géniaux n'ont jamais fourni suffisamment d'aide. Afin d'utiliser efficacement les outils de test d'API, les testeurs ont besoin d'une connaissance approfondie des API qu'ils essaient de tester, y compris de la manière dont les API sont utilisées par l'application en question, ce qui nécessite des compétences et une expertise spécialisées. Et les développeurs n'ont pas le temps de les tester, donc cette pratique extrêmement bénéfique est évitée - intenable pour les testeurs et indésirable pour les développeurs.
Pour résoudre ce défi, les entreprises d'automatisation des tests fonctionnels ont eu il y a de nombreuses années l'idée d'enregistrer les activités d'API et de créer des tests d'API à partir du trafic. C'était puissant car en enregistrant simplement les transactions entre l'application et le système backend, vous pouviez capturer les activités des API, y compris la façon dont les appels d'API restructuraient les données transmises.
Avec cette technologie, vous avez pu enregistrer les scénarios qui se déroulaient dans les systèmes backend. Cela a aidé les utilisateurs non techniques à comprendre quelles API étaient appelées et à acquérir une compréhension de base des données utilisées lorsque chacune était appelée; Cependant, la simple collecte du trafic ne les a pas aidés à améliorer leurs compétences ou à apprendre à maintenir ou à mettre à l'échelle leurs tests. Il ne pouvait pas leur enseigner les compétences techniques nécessaires pour créer différents tests avec tous les différents formats de messages et protocoles utilisés par les API, et il n'a pas fourni suffisamment d'aide à lui seul pour permettre à un utilisateur non technique d'approcher la pratique. C'est un long chemin entre un enregistrement du trafic et un scénario de test d'API pleinement fonctionnel.
Et c'est là que nous avons commencé à réfléchir à la prochaine étape pour abaisser les barrières à l'adoption des tests d'API. Nous avons réfléchi. Le simple fait d'enregistrer le trafic réseau entre l'interface utilisateur du testeur et l'application cible n'est pas suffisant pour aider à automatiser les tests d'API au point de réaliser son utilité. C'est peut-être analogue à un enregistrement audio MP3. Vous pouvez le reproduire pour écouter le morceau, mais il ne contient aucune information sur la façon dont le morceau est créé ou sur les instruments utilisés. La chanson ne peut pas être modifiée ou étendue.
Considérez les problèmes suivants avec des tests d'enregistrement et de relecture simples:
Les interfaces utilisateur sont en constante évolution pendant le développement et la maintenance de l'automatisation des tests basée sur l'interface utilisateur prend du temps. Les interfaces utilisateur n'exposent qu'une certaine représentation, éventuellement limitée, de la logique métier sous-jacente de l'application, et le fait de s'appuyer sur l'enregistrement et la relecture est à la fois limitant et susceptible d'être rompu par des changements fréquents.
Les tests d'application au niveau du système à partir de l'interface utilisateur vont créer beaucoup de trafic réseau. Il est difficile, même pour un œil averti, de déchiffrer quel trafic fait partie d'un scénario de test réel se déroulant au niveau de l'interface utilisateur. S'appuyer sur une interprétation humaine du trafic réseau est à la fois chronophage et source d'erreurs. De plus, ce n'est généralement pas une compétence des testeurs, ils doivent donc compter sur les développeurs pour les aider.
La création de scénarios de test à partir d'enregistrements de trafic de base est difficile. Si plusieurs tests sont nécessaires pour créer un scénario, cette difficulté se multiplie. La relecture d'un enregistrement de trafic à la place d'un scénario est souvent difficile car elle repose sur des conditions préalables exactes pour le test d'origine. De plus, il peut être impossible de rejouer le même test en répétition, par exemple, ce qui est important pour créer des tests de performance ou liés à la sécurité.
Un enregistrement du trafic est simplement une somme de toute l'activité du réseau pendant une session de test. Il n'y a pas de compréhension inhérente du passage du message sous-jacent ni de la relation avec les services d'API. Sans cela, il est impossible d'étendre ces enregistrements à d'autres fins, ou même d'apporter des modifications pour s'adapter aux nouvelles exigences. Ils sont souvent figés dans le temps et ne sont utiles que pour la période où ils ont été enregistrés.
C'est là que l'intelligence artificielle entre en jeu, de sorte que l'enregistrement du trafic puisse non seulement avoir lieu, mais être étendu à une valeur réelle et exploitable pour ses utilisateurs. C'est pourquoi nous avons développé le Générateur de test d'API intelligent, afin que nous puissions créer un endroit pour les testeurs d'API novices pour commencer les tests d'API sans écrire une seule ligne de code. Ainsi, les utilisateurs peuvent rapidement commencer à créer des scénarios de test complets et significatifs, et même étendre ces tests API à des tests de sécurité et de performance, en tirant parti de l'interface simple et intuitive de Parasoft SOAtest.
Lorsque vous testez votre interface utilisateur, le Smart API Test Generator surveille les appels d'API sous-jacents qui sont effectués vers votre application, tout comme le ferait un collecteur de trafic, puis utilise l'intelligence artificielle pour découvrir des modèles et comprendre les relations entre ces appels d'API. Il peut ensuite générer des scénarios de test d'API automatisés qui effectuent les mêmes actions que vos tests d'interface utilisateur, mais qui sont entièrement automatisés et facilement extensibles.
Essentiellement, ceci:
Mais pourquoi est-ce important? Voici quelques-uns des avantages de cette méthode:
Pour résumer, l'outil crée automatiquement des tests basés sur une interprétation significative de l'activité API capturée et prend en charge l'extension et la maintenance faciles de ces tests afin que leur valeur soit multipliée tout au long du cycle de vie du logiciel.
Tout cela est bon en soi. Mais la partie qui m'enthousiasme encore plus est la partie où le Smart API Test Generator aide les utilisateurs à comprendre les relations entre les actions de l'interface utilisateur et les appels d'API, ce qui permet aux testeurs de se perfectionner et d'adopter une pratique de test d'API complète. . Étant donné que les tests d'API peuvent être entièrement automatisés et facilement évolutifs, les équipes peuvent réduire le coût total de la qualité tout en évitant les versions retardées.
Décomposons cela un peu. Parce que le Générateur de test d'API intelligent prend en charge le gros du travail, offrant aux testeurs un endroit facile et sans script pour commencer à créer des tests d'API, cela réduit le point d'entrée technique des tests d'API, amenant les débutants dans le monde des tests d'API et dans l'écosystème convivial Parasoft SOAtest, dont les utilisateurs bénéficient des outils visuels puissants, faciles à adopter et à utiliser.
Oh, les implications! La collecte du trafic de l'activité des API pendant les tests du système et de l'interface utilisateur est insuffisante pour automatiser les tests des API, mais c'est tout ce que l'industrie a eu jusqu'à présent. La dépendance vis-à-vis des conditions préalables rend ces enregistrements moins réutilisables et presque impossibles à étendre à d'autres fins. Sans parler de la difficulté à créer des scénarios de tests significatifs à partir d'un trafic complexe, ce que la plupart des testeurs ne maîtrisent pas.
Mais cela n'a plus d'importance! Maintenant que nous avons le générateur de test Parasoft SOAtest Smart API, les utilisateurs peuvent tirer parti de l'intelligence artificielle pour le gros du travail. Les testeurs d'API débutants peuvent l'utiliser pour démarrer et apprendre comment les tests d'API fonctionnent, et les testeurs d'API expérimentés peuvent en tirer parti pour être beaucoup plus efficaces (c'est l'une des principales façons dont nous l'utilisons maintenant, ici chez Parasoft). Et en fin de compte, les entreprises peuvent gagner du temps et de l'argent en créant des tests significatifs, extensibles et réutilisables en tirant parti d'une machine. Il is 2018, non?
Chef de produit chez Parasoft, Chris élabore des stratégies de développement de produits pour les solutions de test fonctionnel de Parasoft. Son expertise en accélération SDLC grâce à l'automatisation l'a conduit à des déploiements majeurs en entreprise, tels que Capital One et CareFirst.