Chapitre 4 par Broadcom
Métier ●●○○○
Technique ●●●○○
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 :
Le produit Test Advisor du Continuous Delivery Director (CDD) de Broadcom intègre ces approches.
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 :
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.
Pour replacer le volume des tests dans leur contexte, revenons à l'exemple de Google. Les chiffres de tests correspondants sont les suivants:
É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.
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.
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.
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.
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 :
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).
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.
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.
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.
