Rejoignez-nous le 30 avril : dévoilement de Parasoft C/C++test CT pour l'excellence en matière de tests continus et de conformité | En savoir plus

Temps de lecture: 4 minutes

Vue d’ensemble

Avant la virtualisation des services, l'équipe de test de performance de Comcast était souvent confrontée à des conflits de planification autour du partage de l'infrastructure de test. Parfois, les systèmes en aval n'étaient pas disponibles. D'autres fois, les ingénieurs de test essaieraient d'exécuter des tests en même temps, ce qui pourrait affecter les résultats des tests. Cela a entraîné une variabilité entre les tests, ce qui a rendu difficile l'identification de problèmes particuliers.

Découvrez les résultats obtenus par Comcast après avoir mis en œuvre avec succès la virtualisation des services et pourquoi la virtualisation des services est un élément clé de notre initiative DevOps.

Les défis

Par Frank Jennings, directeur des tests de performance TQM chez Comcast

Mon équipe chez Comcast exécute des tests de performances dans un certain nombre de secteurs verticaux de l'entreprise, des services commerciaux à notre plate-forme de services d'entreprise, en passant par les interfaces utilisateur orientées client, les systèmes dorsaux qui effectuent le provisionnement et l'activation des appareils pour les abonnés sur le Réseau Comcast. Alors que nos cibles de test (AUT) ont généralement des environnements de mise en scène qui représentent avec précision les performances des systèmes de production, les systèmes de mise en scène pour les dépendances de l'AUT ne le font pas.

Pour compliquer encore les choses, ces environnements étaient difficiles d'accès. Lorsque nous avons obtenu l'accès, nous avons parfois réduit les environnements inférieurs (les environnements de test d'assurance qualité ou d'intégration) car ils n'étaient pas suffisamment dimensionnés et ne pouvaient tout simplement pas gérer la charge. Même lorsque les systèmes pouvaient supporter la charge, nous avons reçu des temps de réponse très faibles de ces systèmes. Cela signifiait que les résultats de nos tests de performances n'étaient pas vraiment prédictifs des performances réelles.

Un autre problème est que nous avons dû contourner des temps d'arrêt fréquents et longs dans les environnements de transfert. L'environnement intermédiaire n'était pas disponible lors des fréquentes mises à niveau ou mises à jour logicielles. Par conséquent, nous n'avons pas pu exécuter nos tests de performances complets. Les équipes de test de performance ont dû éteindre des projets clés à des périodes critiques afin de rester occupées.

Ces défis augmentaient les coûts, réduisaient l'efficacité de l'équipe et affectaient la fiabilité et la prévisibilité de nos tests de performance. Nous savions que nous devions agir, et c'est pourquoi nous avons commencé à envisager la virtualisation des services. En fin de compte, nous avons constaté que le temps et le coût de mise en œuvre de la virtualisation des services étaient bien inférieurs au temps et au coût associés à la mise en œuvre de tous les différents systèmes dans tous ces environnements de simulation ou à la création de la connectivité entre les différents environnements de simulation.

Les Résultats

Nous nous sommes tournés vers la virtualisation des services pour deux raisons principales. Premièrement, nous voulions augmenter la précision des résultats des tests de performance. Deuxièmement, nous travaillions constamment autour de temps d'arrêt fréquents et longs dans les environnements de test par étapes.

Au départ, nous nous sommes concentrés sur les plus gros problèmes en termes de conflits de planification au sein des équipes de test de performance, de systèmes indisponibles et de systèmes où nos tests auraient un impact sur d'autres groupes de développement ou de test. Depuis que nous avons commencé, nous avons pu virtualiser environ 98 % des interfaces impliquées dans nos tests, et nous avons constaté une réduction annuelle de 65 % du temps qu'il nous faut pour créer et maintenir les données de test (en tenant compte du temps que nous dépenser pour créer et mettre à jour des actifs virtuels). Nous avons également réduit les temps d'arrêt de l'environnement de transfert de 60 %.

Étant donné que nous pouvons commencer à travailler sur nos scripts par rapport aux actifs virtuels dans l'environnement de développement, nous avons généralement tout prêt à démarrer assez tôt dans chaque sprint. Auparavant, nous avions besoin de deux semaines pour tester les performances du code une fois que nous l'avions obtenu dans nos environnements de transfert (par exemple, avec des tests de charge moyenne, des tests de charge de pointe, des tests d'endurance, etc.). Nous avons réduit cela à seulement deux ou trois jours.

Avantages de la solution

Nos tests sont désormais plus prévisibles, plus cohérents et plus représentatifs de ce qui serait vu en production. De plus, nous sommes également en mesure d'élargir la portée des tests dans de nombreux cas. Par exemple, nous ne pouvons pas mettre de charges de production sur certains services réels, mais lorsque nous travaillons avec des services virtuels, nous pouvons les augmenter avec des charges de niveau de production et obtenir des réponses réalistes, à la fois en termes de données et de performances. Nous pouvons vraiment isoler l'AUT, non seulement du point de vue des tests de performances, mais également du point de vue du profilage des performances. Au lieu de simplement dire au développement : « Voici les performances de votre système », nous pouvons également dire : « C'est là que nous voyons les goulots d'étranglement et c'est là que nous pensons que les changements pourraient améliorer le débit de l'application. »

Le principal avantage pour l'équipe de test de performance est l'augmentation du temps de fonctionnement et de la disponibilité des environnements de test. La virtualisation des services nous a permis d'obtenir une excellente utilisation de notre personnel de test, de terminer plus de projets à temps et également d'économiser de l'argent en réduisant le coût total global de la réalisation des tests requis pour une version donnée.

Virtualisation des services et DevOps

Au-delà Test de performance dans nos environnements de développement, nous avons également été en mesure d'utiliser la virtualisation des services pour tout, des tests unitaires et des tests de régression dans l'environnement de développement, aux tests de performances de base dans les premiers environnements en aval, aux tests fonctionnels et de régression dans l'environnement QA/intégré, à tests manuels/exploratoires dans un environnement assez proche de la production (mais utilisant des ressources virtuelles dans certains cas).

Toute la configuration et le déploiement des actifs virtuels pour les différents environnements sont automatisés dans le cadre de notre infrastructure DevOps. Les environnements basculent automatiquement entre les actifs virtuels et les actifs réels selon les règles métier que nous avons définies, par exemple, en fonction du point de terminaison d'où provient le trafic, des données contenues dans les paquets de test, etc. Cette solution de virtualisation de service nous a permis de réaliser des tests continus dans le cadre de notre processus DevOps.

Découvrez comment choisir la bonne solution de virtualisation des services pour votre organisation.

  • Industrie: Philadelphie, Pennsylvanie
  • Taille de l'entreprise: 190,000
  • Lieu: Télécommunications
  • Solution: Virtualiser