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

Qu'est-ce que le test continu et comment l'intégrer dans votre organisation

Par Chris Colosimo

12 novembre 2019

7  min lire

Les entreprises se concentrent de plus en plus sur l'expérience client dans le cadre de leur stratégie de commercialisation, et un élément clé de l'expérience client est leur capacité à parcourir votre logiciel de manière rapide et transparente.

Pour réduire les risques d'une mauvaise expérience client, les organisations doublent leurs initiatives de qualité, et l'industrie du développement de logiciels adopte les tests continus comme une activité courante.

Qu'est-ce que le test continu?

Le test continu est un principe de test logiciel, dans lequel tous vos tests sont exécutés en permanence, fournissant une rétroaction continue sur la qualité et la santé de vos applications. Mais pour réaliser des tests continus, les organisations doivent d'abord adopter l'automatisation des tests. Il existe de nombreux types d'automatisation des tests, couvrant toute l'étendue d'une application en commençant par la couche d'interface utilisateur, en passant par les systèmes middleware et même les systèmes dorsaux. Comprendre comment intégrer ces différents types de pratiques d'automatisation des tests aussi efficacement que possible vous permet de vous diriger vers la voie des tests continus.

Construire la bonne stratégie d'automatisation des tests

Le désormais largement accepté pyramide de test (popularisé par Michael Cohen et Martin Fowler) identifie la stratégie optimale pour les différents types d'activités de test. À la base, représentant la plus grande quantité de tests, nous souhaitons établir une large couverture de tests unitaires et API, qui sont les plus faciles à exécuter dans l'automatisation, mais qui nécessitent souvent des compétences techniques à construire. En arrivant au sommet de la pyramide des tests, vous trouverez des tests d'interface utilisateur automatisés et des tests manuels. Nous voulons ce type d'activité de test au sommet car c'est le seul moyen d'assurer l'expérience client.

La plupart des gens se concentrent en bas et en haut de la pyramide de test avec un "Automatiser ce qui est manuel" approche pour les tests de l'interface utilisateur et une "Les développeurs devraient tester" mentalité pour les tests unitaires. Bien que ces pratiques soient importantes, se concentrer sur le haut et le bas crée un écart au milieu, au niveau de la couche API, entre l'interface utilisateur et le code. Mais cet écart ne fera que continuer à devenir de plus en plus problématique, avec un enquête récente de Programmable Web prédire plus de 22,000 2021 API accessibles au public d'ici XNUMX. Les tests d'API sont plus critiques que jamais et doivent faire partie intégrante de la stratégie de test continu que vous développez.

3 étapes pour activer les tests continus avec l'automatisation des tests

déjà discuté comment choisir la meilleure solution de test d'API pour les besoins uniques de votre organisation, en faisant ressortir les fonctionnalités clés dont vous pourriez avoir besoin en fonction de votre secteur et de votre application. Il est utile de commencer avec une solution de test d'API qui peut évoluer avec vous à mesure que votre maturité de test d'API grandit. Une fois que vous avez choisi un outil, comment commencer? Voici les trois étapes essentielles pour réaliser plus rapidement l'automatisation des tests fonctionnels et permettre vos tests continus.

Étape 1: Établissez une large couverture de test de vos API existantes pour l'automatisation

Pour créer un large éventail de tests automatisés, vous pouvez créer des tests sans script à partir d'enregistrements Web et de contrats d'API, puis utiliser ces tests pour valider en permanence la santé de vos API, en vous assurant que les API fonctionnent comme elles ont été conçues. Considérez cela comme un test unitaire pour les API mais sans le gruntwork - non seulement c'est une technique de test précieuse, mais c'est aussi l'un des premiers types de validation de test fonctionnel que vous pouvez faire, car les contrats de service pour les API sont généralement l'une des premières choses qui sont écrits, au fur et à mesure que de nouvelles fonctionnalités ou fonctionnalités sont créées.

À titre d'exemple, disons que l'équipe a ajouté de nouvelles fonctionnalités dans notre application bancaire. Dans un premier temps, l'équipe de développement a publié un nouveau définition du service. Dans ce cas, un document swagger a été généré. Le nouveau service ajouté était le service RequestLoan. Ce service prend une série d'intrants et répond avec un fournisseur de prêt pour le nouveau prêt. Pour tester ce service, je pourrais consommer le Swagger YAMLet créez une série de clients pour chaque opération individuelle.

L'un de ces clients serait le service de prêt sur demande. Je pourrais créer une série d'entrées, à la fois positives et négatives, pour valider que le service s'est comporté de manière appropriée. Je pourrais ensuite réutiliser ces tests à des fins de régression.

Bien sûr, bien que ce type de test soit extrêmement précieux, il ne représente que la moitié du puzzle des tests d'API car il ne valide pas la manière dont les API sont réellement utilisées. Entrez dans l'étape 2.

Étape 2: combler le fossé entre l'interface utilisateur et l'API

La deuxième partie de la stratégie de test d'API est de pouvoir modéliser l'utilisation humaine de votre application dans des scénarios de test d'API complets. Vous pouvez commencer à combler cette lacune dans la pyramide des tests en tirant parti de intelligence artificielle pour augmenter votre capacité à comprendre ce qui se passe réellement dans les coulisses lorsque les utilisateurs naviguent dans votre application et interpréter ces transactions en coulisse comme des appels d'API. Ce type de test vous permet d'aligner l'expérience utilisateur avec vos tests API critiques.

L'IA est un élément clé de la stratégie car nous pouvons utiliser l'IA de manière fiable pour nous aider à décomposer ces communications en relations et modèles, à comprendre les règles métier de la façon dont nos applications sont testées. Nous pouvons combiner cela avec nos tests d'API au niveau de l'unité pour obtenir une large couverture de notre spectre d'API.

Poursuivant mon exemple ci-dessus, vous remarquerez que le service de demande de prêt nécessite des entrées provenant d'autres domaines de mon application. Spécifiquement:

Maintenant, bien que je puisse fournir arbitrairement customerID et accountAccountID, j'ai vraiment besoin qu'ils existent dans mon application. Je devrai donc créer un scénario dynamique dans lequel j'interroge d'abord l'utilisateur individuel pour obtenir l'ID client et l'ID de compte afin de pouvoir transmettre ces informations au service de demande de prêt et m'assurer qu'un scénario dynamique fonctionne comme décrit. S'assurer que je travaille avec de vraies données dynamiques garantit que le comportement qui existe à la suite de l'interaction des API les unes avec les autres peut être étoffé.

Ces types de techniques nous permettront de déplacer vers la gauche la pratique de test des API et de créer une large couverture de nos applications dès les premières étapes possibles. Une fois réalisée, il y a un troisième élément essentiel de cette pratique, qui concerne notre capacité à comprendre et à s'adapter au changement.

Étape 3: assurer la confiance grâce à un processus de gestion du changement maintenable

J'ai parlé à tant de gens de leur initiative de tests fonctionnels qui a échoué une fois que leur application a changé. C'est un phénomène courant, car les testeurs passent la majeure partie de leur temps à créer des tests d'API riches et performants, pour les interrompre lorsque les API de l'application changent. Cela peut avoir pour effet cumulatif de réduire la confiance dans la stratégie de test d'API, car les testeurs passent une grande partie de leur temps à maintenir leurs tests d'API au lieu de créer une nouvelle valeur.

La gestion du changement est un élément clé de toute stratégie de test fonctionnel, et l'IA peut également être un catalyseur essentiel ici. En analysant automatiquement les définitions de service (oui, les mêmes définitions de service utilisées pour créer initialement les cas de test) pour identifier quand vos API ont changé, vous pouvez comprendre quand vous serez impacté, puis créer un modèle pour la migration des services existants vers le nouveau version.

Revenant à la première partie de notre exemple d'application bancaire, j'ai déclaré qu'un nouveau service avait été ajouté à mon application. Cela représente en fait un changement d'API. Depuis que j'ai créé la première série de tests de base à l'aide de la définition de service, je peux maintenant comparer les différentes versions de la définition de service entre elles, non seulement pour identifier ce qui a changé, mais pour créer une carte pour mettre à jour mes cas de test existants:

En examinant le modèle de changement, il est facile de voir que non seulement un nouveau service a été ajouté, mais que bon nombre de mes services existants ont également été re-factorisés. Dans l'image ci-dessus, vous remarquerez que attirer des clients a une série de nouveaux champs qui ont été ajoutés. À l'aide d'un flux de travail de gestion des modifications, vous pouvez identifier de manière proactive les modifications de service tout en gérant la mise à jour des cas de test existants, afin de pouvoir récupérer le plus rapidement possible.

C'est sans doute la pratique la plus importante à établir lors de l'élaboration de leur stratégie de test fonctionnel, et avoir une compréhension et un engagement envers la qualité dès le début vous aidera, vous et votre organisation, à adopter cette pratique.

Qu'en est-il des environnements de test irréguliers?

Il serait donc facile de s'arrêter là, avec votre excellente automatisation des tests permettant des tests continus. Mais disons que vous avez passé beaucoup de temps à construire cette stratégie de test fonctionnel riche et puissante, vous exécutez vos tests dans votre environnement dans le cadre de votre processus de test continu nocturne automatisé, et en examinant les résultats, vous constatez qu'une grande partie de vos tests ont échoué en raison d'un système hors de votre contrôle. Cela signifie-t-il que vos tests étaient mauvais? Êtes-vous désormais tenu responsable des systèmes qui sont techniquement hors du champ de vos tests?

Ce n'est pas une histoire rare. Nous savons que les tests fonctionnels ne peuvent être aussi efficaces que les environnements de test dans lesquels ils s'exécutent. Des environnements de test instables, indisponibles ou tout simplement irréguliers peuvent réduire le retour sur investissement que nous obtenons de nos outils de test fonctionnel. Je dois donc, au moins brièvement, mentionner l'un des meilleurs moyens de stabiliser vos environnements de test, à savoir: virtualisation des services.

À ne pas confondre avec les machines virtuelles (c'est matériel virtualisation), la virtualisation des services vous permet de simuler réellement les services qui communiquent entre différents composants matériels. Par exemple, pensez à une application appelant une base de données. Avez-vous réellement besoin de cette base de données dans votre environnement de test? Et s'il ne dispose pas des données dont vous avez besoin? Avec la virtualisation des services, vous pouvez enregistrer les transactions avec la base de données, puis utiliser cet enregistrement pour créer une version simulée de cette base de données, avec tout le comportement souhaité pour votre environnement de test. Mais bien sûr, cela ne s'arrête pas aux seules bases de données - il peut s'agir de n'importe quel type de service, comme une API SOAP ou REST, même TCP et Microservices.

Dans le cadre de l'élaboration d'une stratégie de test d'API durable, vous devrez élaborer une stratégie de virtualisation de services durable, et cela commence par répondre à des questions telles que:

  • Quels services sont de bons candidats pour la virtualisation?
  • Comment les services virtuels sont-ils créés?
  • Comment puis-je maintenir un environnement virtuel?
  • Comment puis-je déployer un environnement virtuel dans le cadre de ma stratégie de test continu?

La virtualisation des services est un facteur clé pour une stratégie de test continu durable, mais la compréhension où et quand l'apporter et comment être aussi efficace que possible est la clé du succès.

Maintenant quoi?

Maintenant que vous comprenez mieux comment intégrer les tests d'API dans le cadre de votre stratégie de tests continus, la prochaine étape consiste à vous lancer ! Engagez-vous avec un fournisseur d'outils de test d'API et commencez par la première étape. Comprendre l'objectif final au début vous aidera à faire des choix judicieux en cours de route. Bon test continu !

Comment choisir la bonne solution de test d'API

Par Chris Colosimo

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.

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