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

Transcender les obstacles liés aux données de test à l'aide de la virtualisation des services

Par Chris Colosimo

27 juillet 2017

5  min lire

 


Les données sont un problème de coût

L'un des défis majeurs auxquels les développeurs et testeurs de logiciels sont confrontés au quotidien provient de l'incapacité d'obtenir des données réalistes. En tant que développeur, vous interagissez souvent avec un service en aval et vous devez utiliser toutes les données disponibles dans cet environnement, car le processus d'obtention de données utilisables réelles pour votre scénario prend beaucoup de temps. Souvent, vous ne trouvez pas les données dont vous avez besoin et elles doivent être extraites de la production, ce qui introduit une nouvelle série de défis.

Pour compliquer les choses, les données personnelles ne peuvent pas être utilisées à partir de la production car elles augmentent le risque de vol, de perte ou d'exposition d'une organisation. Prenez la récente violation de Yahoo, où 500 millions de comptes de messagerie ont été violés, ou les quelque 68 milliards d'utilisateurs de LinkedIn dont les données ont été récemment compromises. Ces violations ont eu lieu au niveau de la production où la sécurité est élevée. Les données de production utilisées dans les zones de développement ne sont pas rares et la sécurité a tendance à être plus faible. Opérer de cette manière présente un risque important pour la réputation de marque d'une organisation. Ainsi, les données sensibles doivent être nettoyées ou masquées, ce qui est un processus chronophage nécessitant une expertise des données.


Utiliser la virtualisation des services pour surmonter les coûts de données

Quoi qu'il en soit, les données sont un problème de coût car elles vous ralentissent. En utilisant la virtualisation des services, vous pouvez non seulement prendre le contrôle du comportement et des fonctionnalités d'une application dépendante dans le but de stabiliser vos environnements de test, mais vous pouvez également contrôler complètement les sources de données de ces dépendances et fournir les données dont vous avez besoin ce jour-là pour vos efforts. À ce stade, les règles changent car vous contrôlez non seulement les données, mais également la logique. Vous pouvez créer des services qui se comportent comme vous le souhaitez, par opposition au strict respect de leurs modèles de comportement normaux.

Dans un blog précédent, j'ai discuté de la virtualisation des défauts, qui repose sur les mêmes principes de base. Mais là, nous parlions de logique de service. Ce blog passera à l'étape suivante et parlera du contrôle des données. Au début, concentrons-nous sur le défi actuel des données auquel les testeurs et les développeurs sont confrontés au quotidien.

Une journée typique de données dans la vie d'un développeur

Au début du processus de développement d'une application, les données requises pour les tests sont généralement simples car la fonctionnalité complète du service n'a pas encore été réalisée. À mesure que le développement continue d'ajouter des fonctionnalités, la maturité des tests augmente, tout comme la complexité des données.

Par exemple, utilisons l'exemple de mon Blog post précédent - disons que je suis une compagnie aérienne, développant des fonctionnalités sur ma page de billets. Je dois vérifier que les utilisateurs peuvent obtenir des billets pour leurs vols, et en fonction de la distance future des vols, l'utilisateur recevra l'une des nombreuses réponses, qui changeront à mesure que le temps se rapproche. Au début du processus de développement, je pourrais simplement générer un tas de données complexes avec des vols 3 mois dans le futur, ce qui me permettrait de faire tous les tests dont j'ai besoin pour le moment. Mais bien sûr, le problème est que je viens d'allumer la mèche sur une bombe à retardement. Dans trois mois, ces belles données expireront, et il y a de fortes chances que je les ai oubliées. Soudainement, tous mes tests commenceront à échouer, exactement au mauvais moment car la sortie arrivera et je n'aurai tout simplement pas le temps de régénérer les données… Cela vous semble familier?

Tracez une voie durable

En introduisant la virtualisation des services au début du processus de développement, vous pouvez jeter les bases pour apporter des solutions à ces défis liés aux données. Les données d'un service virtuel peuvent être dérivées de nombreux emplacements, mais au début, de simples services virtuels commencent par des données fixes. Vous créez ces «immobilisations» ou simulacres pour aborder les étapes de test de scénario de simulation et garder les choses très simples. L'idée ici est: «J'ai juste besoin d'un service qui répondra avec cette charge utile particulière.»

À mesure que les services virtuels mûrissent, il devient nécessaire de séparer les données du service afin que si vous souhaitez ajouter de la logique à la simulation, vous n'ayez pas à ouvrir le service virtuel pour manipuler les données. En fait, les utilisateurs matures créent un service virtuel de telle sorte que la source de données gère l'essentiel de la logique. Ils peuvent ensuite confier la source de données à un testeur ou à une équipe de gestion des données de test pour insérer toutes les données dont ce service pourrait avoir besoin à l'avenir. L'ajout de nouvelles fonctionnalités au service est aussi simple que l'ajout d'une ligne à la source de données. Cela permet de partager l'effort de virtualisation et un service virtuel peut accueillir plusieurs équipes. Les services virtuels deviennent des organismes vivants qui se développent et changent selon les besoins.

D'où proviennent ces données?

Une fois que le développement a créé le service simple initial, il est temps que l'équipe de test prenne le relais. Les équipes de test auront des exigences de données plus complexes. D'où viennent ces données? En règle générale, vous tirez ces données de l'enregistrement et de la lecture. Il s'agit souvent de la première étape lors de la création d'un service virtuel. Vous enregistrez les transactions entre une application et les systèmes backend dépendants et utilisez cet enregistrement pour créer votre service virtuel. Cela vous permet de créer une source de données de base très utilisable qui peut être étendue chaque fois que le besoin s'en fait sentir. Dans mon exemple de compagnie aérienne, cela nous permettrait d'obtenir des numéros de vol et des destinations réalistes. Les données auraient toute la complexité nécessaire, y compris les vols multi-segments et internationaux. La corrélation de source de données gère toutes les relations complexes de demande / réponse, et comme les modifications ultérieures des données «réelles» peuvent simplement être réenregistrées et fusionnées dans le service virtuel existant, l'obtention de nouvelles données devient triviale.

Les données que nous enregistrons ne proviennent pas de la production, ce qui nous protège contre une violation de données dans les environnements inférieurs. Le défi avec ces données est que, puisqu'elles ne proviennent pas de la production, elles ne sont pas aussi complètes ou à jour. C'est là que la génération et la manipulation de données deviennent un outil puissant fonction de virtualisation des services.

Les données inexistantes peuvent être complétées par des données générées simples pour accomplir exactement ce dont nous avons besoin. Dans mon exemple de compagnie aérienne, les dates de vol dans les réponses peuvent toujours être la date du jour décalée de 3 mois. En utilisant la génération de données, cette tâche devient triviale.

Nous pouvons continuer à masser et manipuler les données en fournissant des données dynamiques pour gérer toute relation demande / réponse «non définie». Ce sont les types de relations qui ne pourraient jamais exister dans un ensemble de données statique. Dans l'exemple de la compagnie aérienne, disons que lorsqu'une demande au composant en aval est faite, il fournit l'emplacement actuel de l'utilisateur et cela sera utilisé dans la réponse comme départ. Étant donné que nos cas de test changeraient constamment, un vrai service devrait maintenir tous les emplacements actuels afin qu'ils puissent être fournis dans la réponse. En utilisant un service virtuel, vous n'avez pas besoin de gérer tous les emplacements, vous pouvez simplement renvoyer dynamiquement l'emplacement actuel de l'utilisateur comme ville de départ.

Enfin, l'utilisation de données négatives peut être fournie de manière statique ou insérée dans la source de données pour faciliter les tests négatifs ou anormaux. Dans mon exemple de compagnie aérienne, par exemple, il s'agirait d'insérer un vol annulé ou retardé au hasard pour valider que l'utilisateur est averti avant son départ pour l'aéroport.


Dans la vidéo suivante, je décris certains de ces défis typiques auxquels les développeurs sont confrontés lorsqu'ils travaillent avec des données, et je vous montre comment les surmonter de ce que je pense être des moyens assez intéressants avec la virtualisation des services.

 

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.