Qu'est-ce qu'une approche basée sur l'environnement pour les tests de logiciels ?

Tester des applications et des services de manière isolée ne vous mène pas loin et vous devez éventuellement effectuer des tests dans un environnement opérationnel. L'approche de test «basée sur l'environnement» de Parasoft permet aux équipes de tester leurs applications dans le contexte de toutes les dépendances qui existent dans l'environnement réel.

Souvent, les testeurs et les développeurs examinent leur environnement de déploiement et ses composants sur une base individuelle, en testant ces éléments de manière isolée. Cela fonctionne dans une certaine mesure mais ne teste pas suffisamment le système. Une autre version de cela consiste à tester au niveau de l'interface utilisateur, à un moment où les causes profondes des échecs sont difficiles à diagnostiquer. Le terrain d'entente est l'endroit où les applications peuvent être testées dans un environnement aussi réaliste que possible en utilisant des services virtuels pour imiter des dépendances qui ne sont pas disponibles ou suffisamment cohérentes pour les tests. Au fur et à mesure que de plus en plus de dépendances se mettent en ligne, vous pouvez passer des services virtualisés aux versions actives.

Chez Parasoft, nous appelons cela une approche de test «basée sur l'environnement», qui permet à toute l'équipe de tester leur application dans le contexte complet de l'environnement réel. Les tests sont déployés dans un environnement réel, partiellement virtualisé ou entièrement virtualisé selon les besoins. L'approche des tests basée sur les environnements fournit une plate-forme stabilisée pour l'exécution des tests.

Tests basés sur l'environnement

L'approche des tests basée sur l'environnement fournit plus de contexte, pour mieux comprendre l'impact des dépendances sur l'application lors des tests d'interface utilisateur, et aide l'équipe à aller plus loin en créant des tests d'API et de base de données pour les composants dépendants. Ce faisant, vous pouvez obtenir une couverture de test plus complète pour votre application et découpler les tests de l'interface utilisateur, afin que les deux puissent être exécutés ensemble ou indépendamment. Les échecs de test sont mis en évidence dans l'environnement, ce qui facilite l'identification des échecs.

Voici quelques avantages supplémentaires associés à une approche de test basée sur l'environnement:

• Déplacement des tests à gauche en testant l'application dans l'environnement de production dès que possible. Cela est rendu possible grâce à la virtualisation des services, à la création de services virtuels, puis au transfert vers des services en direct à mesure qu'ils deviennent à la fois disponibles et stables.
• Réduction du temps et des efforts de diagnostic des échecs de test en identifiant exactement où et pourquoi les tests ont échoué.
• Étendre facilement les tests des tests d'interface utilisateur aux tests d'API, qui est configurable dans le contexte de l'environnement, ainsi que dans le cadre d'un pipeline CI / CD.
• Augmentation de la couverture des tests en créant des scénarios qui ne pourraient pas être mis en œuvre à partir des seuls tests d'interface utilisateur.

Ces avantages réduisent la charge globale des testeurs pour configurer, exécuter et diagnostiquer les tests d'application tout en augmentant la couverture des tests et en permettant d'effectuer les tests plus tôt et de manière plus complète.

Tests basés sur l'environnement en action avec Parasoft SOAtest

Alors regardons cela en action. Parasoft SOAtest fournit un gestionnaire d'environnement qui affiche visuellement l'environnement d'exécution de l'application testée. Ci-dessous, un exemple avec une application, dans son environnement, connectée à des dépendances. Chaque composant de l'environnement peut être provisionné en direct ou virtualisé selon les besoins, en fonction de la stabilité et de la disponibilité de ces composants.

Parasoft SOAtest fournit un gestionnaire d'environnement qui affiche visuellement l'environnement d'exécution de l'application testée. Ci-dessous, un exemple avec une application dans son environnement, connectée à des dépendances. Chaque composant de l'environnement peut être provisionné en direct ou virtualisé selon les besoins:

Les préréglages de déploiement configurent l'environnement en fonction des exigences de test actuelles. Différentes catégories de scénarios peuvent nécessiter des préréglages différents. Ces préréglages contiennent tous les paramètres nécessaires pour le gestionnaire d'environnement:

 

 

 

 

 

 

 

 

 

Une fois qu'un environnement est provisionné, un ensemble d'interactions API et UI sont exécutées sur l'application testée. Les résultats sont capturés, enregistrés et comparés aux résultats attendus dans l'EDI et dans le portail Web Parasoft, où l'utilitaire de gestion d'environnement sert de plaque tournante pour les tests fonctionnels.

Les échecs sont mis en évidence dans le gestionnaire d'environnement et il est possible de suivre les rapports d'erreurs à partir de là dans un rapport plus détaillé.

 

 

 

 

 

 

Les rapports de test API générés indiquent à la fois les échecs et les informations de couverture des tests. Les échecs signifient que la nouvelle fonctionnalité est interrompue ou qu'il y a un problème avec un test. La cause première de ces échecs peut être retracée de l'échec ici à l'API appropriée. Les informations de couverture des tests sont importantes car elles indiquent des tests manquants et potentiellement un code d'expédition non testé.

Le rôle de la virtualisation des services

Les erreurs proviennent également de dépendances manquantes. C'est ici que la virtualisation des services entre en jeu. Il n'est souvent pas possible d'avoir des dépendances actives disponibles pour les tests, peut-être parce qu'elles ne sont pas encore prêtes ou parce qu'il est difficile et long de les dupliquer à partir de l'environnement de production. Mais pour garantir des applications de haute qualité dans le respect des contraintes de calendrier et de budget, il est essentiel d'avoir un accès illimité à un environnement de test fiable et réaliste, qui inclut l'application testée et tous ses composants dépendants (par exemple, les API, les services tiers, les bases de données, applications et autres points finaux).

 

 

 

 

 

La virtualisation des services permet aux équipes logicielles d'accéder à un environnement de test complet, y compris tous les composants système dépendants critiques, ainsi que de modifier le comportement de ces composants dépendants d'une manière qui serait impossible avec un environnement de test par étapes - vous permettant de tester plus tôt et plus rapidement , et plus complètement. Cela vous permet également d'isoler différentes couches de l'application pour le débogage et les tests de performances, mais nous n'allons pas en parler autant aujourd'hui.

Les services individuels peuvent être configurés en direct ou virtualisés. Les configurations de déploiement qui sont des combinaisons de dépendances actives et virtualisées peuvent être enregistrées en tant que préréglages.

Intégration avec les pipelines CI/CD

Les exemples de tests manuels sont intéressants, mais le vrai travail se déroule dans un pipeline d'intégration continue. Les environnements de test dynamiques de Parasoft peuvent être déployés à partir de Jenkins dans le cadre d'un pipeline d'intégration / déploiement continu. L'exemple suivant montre un «Deploy Dynamic Environment» en tant que build Jenkins.

À l'aide du plug-in Parasoft Jenkins, des étapes de compilation sont ajoutées pour déployer des suites de tests à partir de la compilation. Les résultats sont capturés et liés au gestionnaire d'environnement.

Une fois la construction terminée, les résultats des tests sont affichés dans Jenkins. Les échecs sont directement liés au gestionnaire d'environnement et au scénario de déploiement.

Résumé

En considérant d'abord l'environnement opérationnel et en tirant parti d'une approche de test basée sur l'environnement, les testeurs de logiciels peuvent s'assurer que tout est en place pour rendre les tests productifs et efficaces. Plutôt que de passer du temps à essayer de tester des applications isolément ou dans un environnement pseudo-réaliste, les testeurs peuvent passer plus de temps sur les tests eux-mêmes.