Test de charge et de performance dans un pipeline de livraison DevOps

Les applications logicielles modernes doivent répondre rapidement aux exigences changeantes de l'entreprise et corriger rapidement les bogues, les problèmes de performances et les problèmes de sécurité pour rester compétitives. Cependant, dans un environnement de développement traditionnel, le temps nécessaire pour tester minutieusement une application logicielle avant sa sortie entre en conflit avec le rythme auquel l'application doit évoluer.

Les méthodologies DevOps se sont révélées efficaces pour concilier ces exigences contradictoires de publication rapide et de fourniture de logiciels de haute qualité. Pour cette raison, ils ont été largement adoptés par les organisations de développement de logiciels tournées vers l’avenir.

DevOps utilise largement le concept de processus continu, qui s'applique à toutes les étapes du cycle de vie des applications, y compris la modification du code, les tests des applications et la surveillance du déploiement et de la production. Alors que les pratiques de tests unitaires et d'intégration continus ont été largement adoptées, tests de performances continus est particulièrement à la traîne, en grande partie à cause des difficultés des organisations à intégrer les tests de performances traditionnellement manuels dans un pipeline DevOps hautement automatisé. Dans cet article, nous décrivons comment les tests de performances doivent évoluer pour devenir une partie intégrante de l'environnement DevOps.

Pourquoi les tests de performances sont-ils vitaux pour les applications serveur ?

Les applications peuvent échouer de plusieurs manières. Pour détecter les erreurs, le développement logiciel et l'assurance qualité utilisent plusieurs types de tests. Les plus courants sont les suivants.

• Tests unitaires
• Tests d'intégration
• Tests de sécurité
• Des tests de performance
• Tests de distribution

Chacun de ces types de tests s'adresse à une catégorie spécifique d'échecs qu'une application peut rencontrer en production. Les tests de performances, qui font l'objet de cet article, ciblent un ensemble de types d'échecs qui se produisent lorsque l'application est soumise à une charge de requêtes simultanées. Vous trouverez ci-dessous les six types de pannes les plus courants.

1. Temps de réponse lents. Des délais de réponse inférieurs au niveau acceptable en raison de goulots d'étranglement au niveau des applications ou de l'infrastructure.
2. Indisponibilité partielle. Un état dans lequel certaines requêtes client ne reçoivent pas de réponses. Cela peut se produire en raison d'allocations de ressources insuffisantes, de fuites de ressources, de problèmes de concurrence (conditions de concurrence, blocages), etc.
3. Indisponibilité totale. Des pannes d'application peuvent se produire lorsque les effets provoquant une indisponibilité partielle s'accumulent jusqu'à atteindre des niveaux où ils affectent l'ensemble de l'application.
4. Réponses aux erreurs. Les réponses de l'application indiquent qu'elle n'a pas réussi à traiter les demandes des clients, en renvoyant par exemple des réponses HTTP 500. Cela peut être dû aux mêmes raisons qui provoquent une indisponibilité partielle de l'application, mais entraîner un comportement différent en raison de la logique de l'application.
5. Mauvais contenu dans les réponses. L'application renvoie des réponses bien formées avec un contenu incorrect. Par exemple, un contenu erroné intermittent dans les réponses peut être dû à des conditions de concurrence.
6. Implications potentielles en matière de sécurité causées par des problèmes de performances. Un exemple de ceci est la gestion incorrecte des attaques DOS (déni de service) ou la divulgation des détails internes de l'application, qui peuvent s'infiltrer dans les réponses du serveur sous forme de descriptions d'erreur lorsque l'application se trouve dans un mauvais état en raison d'une surcharge.

Chacune de ces défaillances est susceptible d'entraîner des pertes financières et de nuire à la réputation de l'organisation en tant que fournisseur de services fiable. Ci-dessous, nous examinerons les étapes à suivre pour intégrer les tests de performances dans le pipeline DevOps afin de détecter ces problèmes le plus tôt possible.

Intégrer les tests de performance dans le pipeline de livraison continue

Vous pouvez commencer à intégrer des tests de performances dans le pipeline de livraison continue en ajoutant des tests de performances sélectionnés à Jenkins, ou à un outil d'intégration continue de votre choix, et en les exécutant régulièrement.

En fonction de vos besoins, vous pouvez exécuter des tests de performances à un ou plusieurs des points suivants lors de la création ou du test de l'infrastructure.

• Après chaque construction avec un ensemble réduit de tests de performance «fumée».
• Une fois par jour avec un ensemble plus complet de tests de performance.
• Une fois par week-end ou en fonction de la disponibilité de l'infrastructure, avec un ensemble de tests de longue durée pour les tests d'endurance ou des tests de charge à grand volume pour les tests de contrainte.

Cependant, cela ne suffit pas en soi.

L'analyse manuelle des rapports de tests de charge peut prendre du temps et nécessiter des compétences particulières que tous les développeurs ne possèdent pas. Sans la possibilité d’automatiser l’analyse des rapports de tests de charge, l’examen des résultats des tests de performances devient une perte de temps fastidieuse. Des informations vitales sur les performances peuvent également être négligées. Dans de tels scénarios, vous pouvez exécuter des tests de performances en continu, mais leurs avantages seront limités.

Automatisez la collecte et l'analyse des résultats des tests de performance

À Bénéficiez pleinement des tests de performances continus, vous devez mettre en place un mécanisme efficace pour analyser les résultats des tests de performances. Test de charge Parasoft et son LoadTest Continuum, un module de Parasoft SOAtest, vous fournissent des outils qui vous aident à automatiser la collecte et l'analyse des résultats des tests de performances et vous donnent un aperçu des performances de votre application.

Comment configurer votre environnement pour une exécution continue des tests de performance

Les étapes suivantes vous aideront à configurer votre environnement pour une exécution de tests de performances avec Parasoft LoadTest et LoadTest Continuum:

1. Passez en revue et configurez les métriques QoS du projet LoadTest pour l'automatisation.
2. Déployez et configurez LoadTest Continuum pour la collecte de rapports de test de charge.
3. Configurez les projets LoadTest en lots pour exécution.
4. Commencez à exécuter des lots de projets LoadTest dans le cadre d’une intégration continue et utilisez LoadTest Continuum pour examiner et analyser régulièrement les résultats des tests de performances.

Passons en revue ces étapes individuellement plus en détail ci-dessous.

Étape 1 - Examiner et configurer les métriques QoS pour l'automatisation

Les mesures de qualité de service (QoS) de Parasoft LoadTest sont l'une des fonctionnalités clés pour automatiser l'analyse des résultats des tests de performance. Les métriques QoS réduisent de grandes quantités de données dans un rapport de test de charge en un ensemble de réponses de réussite / échec sur les performances de votre application. Parasoft LoadTest propose un ensemble complet de métriques QoS qui vont des métriques de seuil prêtes à l'emploi aux métriques à script personnalisé qui vous permettent d'utiliser l'API LoadTest pour l'analyse avancée des données de test de charge.

Pour préparer vos tests de performances pour l'automatisation, vous devez examiner les métriques QoS dans vos projets LoadTest. Exécutez un projet LoadTest et examinez le rapport: tous les critères de réussite et d'échec que vous utilisez pour analyser manuellement un rapport de test de charge doivent être représentés sous forme de métriques QoS. Convertissez autant de métriques que possible en métriques «numériques». Une métrique QoS numérique renvoie non seulement un résultat de réussite / échec, mais quantifie également un indicateur de performance clé pour cette métrique. Par exemple, une métrique qui valide un seuil d'utilisation du processeur fournirait également la valeur d'utilisation réelle du processeur sous forme de métrique numérique.

Les métriques numériques sont largement utilisées dans LoadTest Continuum pour tracer les performances des métriques au fil du temps:

Une fois que vous avez configuré les métriques QoS pour votre Projets LoadTest, il est temps de configurer le continuum LoadTest pour la collecte et l’analyse des données de performances.

Étape 2 - Déployer et configurer LoadTest Continuum

Déployez et configurez l'archive de l'application Web LoadTest Continuum ltc.war (disponible dans le répertoire d'installation SOAtest / LoadTest à partir de la version 9.10.2), comme décrit dans la section «LoadTest Continuum» de la documentation LoadTest.

Étape 3 - Configurer les projets LoadTest en lots pour l'exécution

Combinez vos projets LoadTest dans des scripts .cmd pour une exécution par lots. Les scripts LoadTest .cmd vous permettent de spécifier des groupes de projets qui constitueront différents ensembles de tests de performances, tels que les tests «fumée», les tests quotidiens ou les tests du week-end mentionnés précédemment.

Configurez les scripts .cmd pour envoyer des données de rapport à LoadTest Continuum comme décrit dans la section «Envoi de rapports à LoadTest Continuum» de la documentation LoadTest. Configurez votre outil d'intégration continue pour exécuter des scripts LoadTest .cmd dans le cadre d'un processus de construction ou à intervalles réguliers. Par exemple, dans Jenkins, vous pouvez exécuter un script LoadTest .cmd à l'aide de l'étape de génération de commande par lots Execute Windows comme suit:

% SOATEST_HOME% \ lt.exe "-J-Xmx4096M -cmd -run"% WORKSPACE% \ ltcontinuum.cmd

Étape 4 - Configurer un tableau de bord dans Parasoft DTP

PAO Parasoft contient des tableaux de bord de reporting et d'analyse qui vous permettent de suivre la santé et l'avancement de votre projet logiciel avec une variété de widgets et de rapports.

Un continuum de test de charge Parasoft Widget PAO vous permet d'ajouter le résumé des résultats LoadTest le plus récent au tableau de bord de votre projet PAO et offre un moyen rapide d'évaluer l'état des résultats des tests de performances dans votre routine quotidienne d'examen de l'état du projet.

Le widget affiche le nombre de tests et de métriques totaux, réussis et échoués pour les exécutions de LoadTest les plus récentes. Pour afficher les résultats plus en détail, cliquez sur le lien du projet dans le widget, et la page LoadTest Continuum s'ouvrira dans un nouvel onglet.

Pour configurer un widget HTML personnalisé LoadTest Continuum dans DTP, vous pouvez simplement suivre ces étapes:

1. Dans le Centre de rapports Parasoft DTP, créez un nouveau tableau de bord ou ouvrez-en un existant.
2. Appuyez sur Ajouter un widget. Dans la boîte de dialogue Ajouter un widget, sélectionnez Personnalisé -> Widget HTML personnalisé.
3. Copiez le contenu du fichier suivant de l'installation de LoadTest Continuum dans la zone de texte HTML de la boîte de dialogue:% TOMCAT_HOME% \ webapps \ ltc \ dtp \ ltc_dtp_widget.html
4. Modifiez le HTML avec vos paramètres personnalisés:
   1. Recherchez la fonction getServerURL (). Modifiez la valeur de retour avec l'hôte et le port de votre installation LoadTest Continuum.
   2. Recherchez la fonction getProjectName (). Modifiez la valeur de retour avec le nom du projet que vous souhaitez suivre dans le widget.
5. Appuyez sur Créer.

Étape 5 - Examiner et analyser les résultats des tests de performance

Parasoft LoadTest Continuum sert à la fois de point de collecte pour vos rapports LoadTest et d'outil d'analyse qui organise les données de test de charge à partir de plusieurs exécutions. LoadTest Continuum organise les données en une pyramide d'informations qui vous permet de passer en revue les résultats de vos tests de performance à différents niveaux de détail, des résumés quotidiens de haut niveau en haut, aux résultats de métriques QoS au cœur, aux rapports de test de charge détaillés au bas:

Considérez le flux de travail suivant comme un exemple d'examen de test régulier (quotidien):

1. Pour les tests échoués, suivez les étapes suivantes:
   1. Ouvrez la vue Historique des tests, vérifiez si le test échoue régulièrement ou sporadiquement. Le premier cas indiquerait probablement une régression; le second cas une instabilité.
   2. Inspectez les métriques ayant échoué du test:
      1. Pour une métrique numérique, ouvrez la vue graphique de l'historique des métriques. Utilisez le graphique d'historique des métriques pour obtenir des informations. Par exemple, si un test auquel appartient la métrique est instable, de petites fluctuations du graphique de métrique indiquent généralement que le seuil de métrique doit être ajusté. De grandes fluctuations indiquent des problèmes de code ou d'infrastructure.
      2. Ouvrez le lien Tous les graphiques de ce test. Vérifiez les graphiques des autres métriques numériques pour le même test pour les fluctuations qui n'ont pas franchi le seuil de métrique.
2. Si vous n'avez pas configuré les widgets DTP LoadTest Continuum, commencez par vérifier les résumés de réussite / échec des tests et des métriques dans la page principale du projet LTC.
3. Pour les projets qui ont échoué, suivez le lien vers la page du projet LTC pour examiner les détails.
4. Commencez par vérifier l'état de vos dernières exécutions de test de charge dans les widgets LoadTest Continuum DTP.
5. Faites de même pour le lien Tous les graphiques de cette métrique pour vérifier si des métriques similaires d'autres tests ont été affectées. Si oui, cela indique un problème systémique avec votre application ou infrastructure qui ne se limite pas à un seul test (voir Fig. 4).
6. Pour une analyse plus approfondie, ouvrez les rapports de test de charge HTML ou binaire du test ayant échoué.

L'intégration d'un processus de test de performance dans le pipeline de livraison continue est essentielle pour garantir la qualité du logiciel. Pour tirer pleinement parti de ce processus, vous devez mettre en place un mécanisme efficace d'automatisation de l'analyse des résultats des tests de performance.

Soyez continu avec Parasoft

Atteignez tous vos objectifs ambitieux d'automatisation de l'analyse des résultats de tests avec Parasoft LoadTest et LoadTest Continuum à l'intérieur de Parasoft SOAtest. Ces outils offrent une automatisation sophistiquée des tests fonctionnels, afin que vous puissiez fournir des logiciels de meilleure qualité.