État de l'Intelligence Artificielle appliquée à l'Ingénierie de la Qualité 2021-2022
Section 2 : Conception des tests

Chapitre 4 par Broadcom

L'optimisation dynamique des cas de test

Métier ●●○○○
Technique ●●●○○

 

Download the "Section 2: Design" as a PDF

Use the site navigation to visit other sections and download further PDF content

 

By submitting this form, I understand that my data will be processed by Sogeti as described in the Privacy Policy.

Les techniques d'IA et d'apprentissage automatique permettent une optimisation dynamique des suites de tests à l'échelle dans le cadre du cycle de vie de l'intégration et de la livraison continues.

Introduction

À l'ère d'Agile et de DevOps, l'agilité de la livraison des logiciels est d'une importance capitale. Dans la section 1, chapitre 1 intitulé "Ingénierie de la qualité et tendances récentes", nous avons déjà discuté de la façon dont les tests, en tant qu'activité finale du flux de travail, sont incontestablement le plus grand goulot d'étranglement dans la livraison d'un code de haute qualité. Des tests sous-optimaux entraînent non seulement plus d'efforts et de coûts, mais aussi une baisse de productivité, des retards de publication et un impact négatif potentiel sur l'entreprise.
Actuellement, les techniques de test basées sur des modèles sont utilisées pour effectuer une optimisation statique des tests via la modélisation des exigences. Cependant, l'optimisation statique ignore les conditions dynamiques telles que les modifications apportées à des corps de code spécifiques, l'historique des exécutions de test précédentes, la fragilité des tests et d'autres critères d'exécution (taux de rotation du code, qualité du code, nombre d'auteurs ayant modifié le code, etc.)

En fait, sauf dans certaines circonstances, les tests optimisés à l'aide de tests basés sur des modèles peuvent être sous-optimaux - ce qui implique que nous ne faisons pas tout ce qui est possible pour réduire l'effort de test et le temps de cycle. D'autre part, essayer de prendre manuellement des décisions d'optimisation des tests sur la base d'une pléthore de ces données prendrait un temps prohibitif et ne serait pas extensible.
Ce chapitre traite de la manière dont de telles solutions peuvent être mises en œuvre en utilisant des études de cas de clients comme exemples. Nous démontrons comment nous tirons parti de l'IA/ML pour générer des jeux de tests optimisés de manière dynamique en utilisant, entre autres, les techniques suivantes :

  • Établir une association entre les tests exécutés et le code exécuté. Chaque fois que le code est modifié, nous pouvons signaler les tests qui doivent être exécutés. Cela permet de réduire considérablement le nombre de tests - souvent jusqu'à 90 % - par rapport à ceux effectués sans l'utilisation de cette technique.
  • L'analyse du schéma des résultats des tests précédents permet d'identifier les tests défaillants, qui sont signalés comme devant être ré-exécutés.
  • L'établissement d'une corrélation entre les défauts antérieurs (découverts lors des tests) et les composants du code afin d'identifier le code qui nécessite des tests rigoureux.


Le produit Test Advisor du Continuous Delivery Director (CDD) de Broadcom intègre ces approches.

Le défi des tests en développement agile

Une étude de cas récente de Google étude de cas récente de Google a révélé un taux de développement stupéfiant parmi 25 000 ingénieurs logiciels :

  • 40 000 modifications de code par jour
  • 50 000 constructions par jour

Nous voyons également des données comparables provenant d'autres organisations. Selon une étude de cas récente menée chez Microsoft, l'équipe de développement de Windows a effectué en moyenne 8500 poussées de code par jour, ce qui a donné lieu à environ 1760 constructions ! Et l'application mobile de Facebook reçoit environ 1 500 poussées de code par jour.

Considérez maintenant ce qui se passe en termes de tests à la suite de ce type d'activité de développement frénétique.

  1. Avant de valider le code, un développeur effectue des tests unitaires locaux à l'aide d'un build local. Bien qu'il n'existe pas de normes concernant le nombre de tests unitaires à exécuter dans le cadre d'une validation de code, les données de Facebook indiquent qu'une validation de code moyenne contient environ 200 lignes de code en régime permanent. Cela implique l'exécution d'au moins 3 à 5 tests unitaires avant la validation.
  2. Après la validation du code, les constructions sont déclenchées à des intervalles prédéfinis (par exemple, toutes les deux à cinq validations en moyenne), ce qui entraîne l'exécution de tests de vérification de la construction, de tests unitaires, de tests de composants et de tests d'intégration, entre autres. Cela implique l'exécution d'environ (ou au minimum) 15 tests unitaires et 5 tests d'intégration par build. En outre, nous exécutons généralement une série de tests de régression, dont le nombre peut dépasser 500.
  3. Si la version réussit les tests, elle est transférée vers des environnements en aval, tels que les environnements de test système et de pré-prod, où nous exécutons des tests de bout en bout, l'UAT, etc. Le nombre de tests ne cesse de croître.
  4. Enfin, les tests sont effectués en production à l'aide d'une variété de techniques de test différentes, notamment le contrôle synthétique, les tests de chaos, etc.

Pour replacer le volume des tests dans leur contexte, revenons à l'exemple de Google. Les chiffres de tests correspondants sont les suivants:

  • 120 000 suites de tests automatisés
  • 75 millions de cas de test sont exécutés quotidiennement.

Étant donné que la majorité des autres entreprises ne sont probablement pas aussi matures que Google, supposons une moyenne d'un build par jour par développeur, ce qui donne environ 750 tests par build. Étant donné que la majorité des entreprises n'utilisent pas de manière significative l'automatisation des tests, supposons que 50% des 750 tests soient automatisés et que les tests manuels prennent en moyenne 5 minutes (chacun :) à être exécutés. Cela équivaut à environ 32 heures de tests manuels par build, sans parler de l'effort supplémentaire (et du temps) nécessaire pour préparer les données et les environnements de test pour ces tests.

Ainsi, pour une équipe agile typique d'environ huit personnes (disons cinq développeurs), cela équivaut à plus de 160 heures de tests manuels par build ! Il s'agit d'un surcoût important qui pourrait entraîner des retards de publication ou, plus vraisemblablement, l'incapacité des testeurs à effectuer des tests adéquats, augmentant ainsi le risque d'échec.

Cela démontre clairement combien il est difficile pour les tests de suivre le rythme de développement dans un environnement agile. Alors que des techniques telles que les tests basés sur des modèles permettraient probablement de réduire ce fardeau d'environ 50 %, elles exigeraient un effort de modélisation supplémentaire et pourraient encore être insuffisantes pour suivre le rythme sans automatiser complètement tous les tests. Par conséquent, nous devons envisager de nouvelles façons de résoudre ce problème en utilisant l'IA/ML.

SOS AI/ML

L'IA/ML peut aider à résoudre ce problème de plusieurs manières, notamment en corrélant plusieurs ensembles de données associés au processus de test. Tous ces éléments contribuent à la réduction du volume de tests à un sous-ensemble essentiel sur la base des différentes approches décrites ci-dessous.

Figure 1: Reduction of test volume

Examinons trois approches différentes de la solution Test Advisor du Continuous Delivery Director (CDD) de Broadcom.

Associer les tests aux changements de code

Étant donné la fréquence à laquelle le code est modifié, une approche critique consiste à déterminer quels tests sont impactés lorsque le code spécifique est modifié. En instrumentant le code testé, nous pouvons établir un lien entre les tests exécutés et le code testé. Le système d'IA est entraîné (et continue d'apprendre au fur et à mesure que d'autres tests sont exécutés) en exécutant des tests existants par rapport à la base de code. 

00203 S2C4 Figure 2

 

Par la suite, chaque fois que le code est modifié (via un commit dans le système de gestion du code source), Test Advisor signale les tests qui sont affectés par le changement, en donnant la priorité à leur exécution.

 

00203 S2C4 Figure 3

 

Naturellement, tous les nouveaux tests (ou les tests mis à jour) seraient qualifiés automatiquement comme des tests qui doivent être exécutés dans le cadre d'un build.

Comprendre le modèle des résultats de tests antérieurs

Un système d'IA peut déduire des modèles à partir des résultats précédents afin de déterminer quels ensembles de tests doivent être exécutés en priorité. L'un de ces modèles est ce que nous appelons les tests d'écrasement. Il s'agit de suites de tests qui présentent une ou plusieurs des caractéristiques énumérées ci-dessous :

  1. Suites de test qui ont échoué de nombreuses fois lors d'exécutions précédentes.
  2. Suites de test qui sont erratiques et alternent entre succès et échec lors des cycles de test suivants
  3. Suites de tests qui ont échoué lors de l'exécution précédente

Si les résultats de la suite de tests montrent une tendance discernable et que les dernières exécutions de tests sont toutes réussies, le test n'est pas identifié comme erratique. Ce type de résultat de test indique qu'un problème existait mais a été résolu. Un test peut être défectueux à cause d'un bogue dans le code ou à cause d'un défaut dans le test lui-même. Une suite de test "flaky" est automatiquement sélectionnée pour le prochain cycle de test. 

Associer les défauts découverts aux composants du code

En associant les défauts découverts lors des tests aux composants applicatifs dont ils proviennent, un système d'IA peut identifier les builds qui nécessitent des tests supplémentaires en fonction des composants de code inclus dans le build. Naturellement, nous devons hiérarchiser les défauts de manière appropriée en fonction de leur gravité, de leur emplacement dans le cycle de vie CI/CD et de leur type. Cela permet au système d'IA d'identifier de manière proactive les composants à haut risque ou sujets aux défauts et de signaler les tests qui leur sont associés (comme décrit dans la fonctionnalité (A) ci-dessus) chaque fois qu'ils sont inclus dans un build.

En résumé, Test Advisor aide à réduire la quantité de tests nécessaires en signalant les tests qui doivent être exécutés dans le cadre d'un build. Cela se traduit fréquemment par une réduction de plus de 60% du nombre de tests exécutés (par rapport à ceux exécutés avec des approches traditionnelles).

00203 S2C4 Figure 4

 

Cas concret d'utilisation

Un grand fournisseur de services de télécommunications a mis en œuvre des pratiques DevOps pour passer à un cycle de vie de livraison agile. Naturellement, il était préoccupé par le volume de tests qu'il devait exécuter en conjonction avec les modifications fréquentes du code et les constructions associées à ses cycles de publication bihebdomadaires. Ils devaient généralement exécuter plus de 500 tests par construction d'une application (y compris des tests unitaires, de composants et BDD, des tests d'API et d'intégration, et des tests système), dont la majorité étaient manuels. L'exécution de tous ces tests ralentissait considérablement leur cycle de publication. Ils ont pu réduire le volume des tests de 70 à 90 % selon l'application en mettant en œuvre CDD et Test Advisor. En réduisant le nombre de tests, ils ont pu réduire considérablement le temps écoulé et les retards liés aux tests.

Perspectives d'avenir

Nous n'avons fait qu'effleurer la surface des applications IA/ML dans le domaine des tests et de la qualité - et un vaste domaine de possibilités nous attend. Parmi les cas d'utilisation clés que nous envisageons d'améliorer à l'avenir, citons la prédiction des défauts et l'identification de leur source, la quantification des risques liés à la mise en production ou au déploiement avant la mise en service, et la génération automatique de tests (et de données de test) sur la base de scénarios d'utilisation en production.

About the author

Shamim Ahmed

Shamim Ahmed

Shamim Ahmed is CTO for DevOps Solution Engineering at Broadcom Technologies, where he is responsible for innovating intelligent DevOps and BizOps solutions using Broadcom's industry leading technologies.

His key focus areas include: applications of AI/machine learning to DevOps, "model-based everything" in Continuous Delivery (specifically model-based requirements, testing, deployment, release, test data and services) , site reliability engineering (SRE), and modern application architectures.

About Broadcom

Broadcom Inc. is a global technology leader that designs, develops and supplies a broad range of semiconductor and infrastructure software solutions. Broadcom’s category-leading product portfolio serves critical markets including data center, networking, enterprise software, broadband, wireless, storage and industrial. Our solutions include data center networking and storage, enterprise, mainframe and cyber security software focused on automation, monitoring and security, smartphone components, telecoms and factory automation. For more information, go to www.broadcom.com. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries.

 

 

CA-Broadcom_Horizontal_red-black.png