Question Test de performance en intégration continue?


Nous avons déjà un processus d'intégration continue, où nous construisons, exécutons des tests unitaires, effectuons des analyses de code statique et générons de la documentation. Cependant, nous aimerions élargir cela pour inclure des tests de performances automatiques. Dans ce cas, nous travaillons sur une application Web .NET.

Nous avons effectué des tests de performance avec JMeter (en dehors du processus CI), mais je ne sais pas si c'est le meilleur outil à inclure dans un processus CI? Le sélénium est-il une option? WAPT Pro?

Sur quels niveaux devrions-nous tester la performance? Devrions-nous avoir un ensemble de "tests unitaires de performance"? Devrions-nous exécuter JMeter (ou quelque chose de similaire) dans un environnement de production et échouer si des demandes prennent plus d'une seconde? Quelque chose comme cela n'aurait-il pas une variance trop élevée?

Alors, est-ce que vous incluez les tests automatiques de performance dans votre CI? Que testez-vous et quels outils utilisez-vous? Comment a été votre expérience?


14
2018-02-06 23:24


origine


Réponses:


Tout d'abord, JMeter est un bon choix pour l'inclusion dans CI car il peut être exécuté à partir de la ligne de commande et vous pouvez transmettre des variables lorsque vous faites cela. Je le recommanderais pour cette tâche.

En général, en intégrant Perf. le test dans CI est difficile. Vous avez déjà énuméré plusieurs des raisons pour lesquelles ceci est ainsi vous êtes déjà à mi-chemin parce que vous comprenez les limites. Et c’est le frottement: il est possible d’avoir du Perf. tests en IC mais seulement dans une mesure limitée.

Je pense qu'une bonne approche suit certains de ces principes:

Vous ne pouvez pas exécuter des tests de charge complète (ou de trempage ou de capacité) dans CI, ce n'est pas pratique.  Les résultats sont subjectifs et nécessitent une interprétation humaine et les tests prennent du temps. Mais vous pouvez exécuter un ensemble de tests simplifié, plus simple, qui mesure les temps de réponse pour les demandes, puis vous pouvez évaluer ces temps de réponse:

  • Contre une portée NFR ou attendue - Ie. Devrait être inférieur à 1 sec.
  • Contre les résultats précédents - Ie. Ne doit pas s'écarter de plus de 10% de la dernière construction.

Vous pouvez également exécuter le chargement / perf automatisé. tests - à plein volume - en dehors du processus de construction. 'Semi CI'. Alors peut-être pourriez-vous automatiser un test pour qu'il se déroule du jour au lendemain et vérifier ensuite les résultats le matin?

Répéter. Commencez par le faire et obtenez des résultats et affinez les tests et leur interprétation au fil du temps. Restez simple et concentrez-vous sur les domaines qui vous semblent utiles. Ne lancez pas en fanfare, restez silencieux jusqu'à ce que vous ayez confiance dans le processus, puis commencez à échouer et à en parler aux gens - au départ, vous risquez d'obtenir beaucoup de faux négatifs.

Instrumenter vos résultats Faites ceci Beaucoup. CI est synonyme d'échec précoce, donc si vous prenez cela comme objectif final, le meilleur moyen d'y parvenir est d'exécuter des tests tôt et souvent, mais le problème est que vous risquez d'être enfoui dans les données. Ainsi, une méthode efficace pour analyser les données et présenter les informations pertinentes vous aide considérablement.

Vous ne pouvez pas automatiser l'intégralité du processus jusqu'à Red Flag Green Flag - mais vous devez essayer d'aller aussi loin que possible dans cette voie.

Enfin, il y avait une très bonne conversation donnée par le leader Perf. testeur chez Google qui couvre ce sujet. C'est un peu vieux maintenant mais les principes sont toujours valables. De plus, dans quelques semaines je vais à un se rencontrer où Channel4, une société de médias britannique, parlera de la façon dont ils ont abordé cette question - peut-être pourriez-vous demander des diapositives.


8
2018-02-10 21:38



> Vous ne pouvez pas exécuter des tests de charge complète (ou de trempage ou de capacité) dans CI, ce n'est pas pratique.

Après le Conférence TISQA Aux États-Unis, cette semaine, je suis plus enclin à dire que nous devrions automatiser en toute confiance de plus en plus de tests de charge complets et complexes avec l'automatisation de CI.

Vous pourriez même envisager de disposer d'une instance de CI distincte s'exécutant dans le plus grand laboratoire de test de charge, configurée avec une infrastructure plus réaliste pour prendre en charge des résultats de test significatifs. Le processus de test de charge lui-même n'est pas différent d'un processus de développement logiciel distinct (conception, construction, déploiement, exécution, analyse, répétition). La plupart de tous les outils de performance soutient maintenant des intégrations plus élégantes et robustes à des solutions CI, y compris SOASTA, LoadRunner / PC, JMeter, Neotys, Blazemeter, Flood.io.

Mais voici trois choses à surveiller - similaires aux commentaires d'Oliver:    - Il y a beaucoup plus de nuances dans les résultats de performance ... pas seulement clairement PASS ou FAIL    - N'oubliez pas la maintenance du script pour rester synchronisé avec les modifications de l'application    - La synchronisation / mise à l'échelle de votre laboratoire de test de charge avec la production pourrait également être automatisée

Si vous le souhaitez, passez en revue certaines des diapositives de ma propre présentation TISQA ici. Cela pourrait être un début sur la façon d'utiliser CI + Performance sur l'ensemble du cycle de vie. Par exemple, pourquoi ne pas avoir une instance de CI qui «surveille la configuration» à mesure qu'elle change dans PROD et synchronise ces modifications avec votre environnement de test de charge?


2
2018-03-14 19:19



Ni JMeter ni Selenium ne sont des outils pour CI. JMeter est un outil de test de performance, Selenium est un outil de test fonctionnel automatisé. Ainsi, pour que les tests de performance soient intégrés au processus de génération, vous pouvez utiliser JMeter avec n'importe quel serveur CI: Jenkins, Bamdoo, etc.

AFAIK, il existe deux solutions courantes pour utiliser JMeter avec Jenkins de nos jours:

  1. Utilisez le plug-in Jenkins / Hudson avec JMeter pour cela, ce qui permet de lancer une tâche de test de performance après avoir terminé le processus de construction. Dans ce cas, vous devez avoir un nombre approprié de générateurs de charge avec JMeter configuré.

  2. Une autre façon - en utilisant Nuage de test JMeter. Ce service fournit Plugin Jenkins, qui permet de lancer un test à distance après la création d’une application. Dans ce cas, vous n'avez pas à vous soucier de la configuration des serveurs de test.

P.S. Pendant que je travaille pour Blazemeter, je voulais fournir des informations objectives. J'espère que c'est utile.


1
2018-02-08 12:36



Dans votre question, vous avez demandé - Le sélénium est-il une option?

Si vous utilisez de CI en utilisant soit un réseau interne d'ordinateurs ou le Cloud public alors vous devriez envisager des tests de performance en utilisant Sélénium WebDriver avec le pilote du navigateur Headless.

Sur une petite machine virtuelle Amazon (ami), je fais environ 25 utilisateurs virtuels simulés en utilisant cette approche. Donc, si vos besoins sont de l’ordre de 500 VU, alors je rechercherais ceci car les avantages incluent: -

Plus de "corrélation" pour la réécriture d'URL, etc. car le navigateur sans tête gère cela automatiquement.

Vos tests fonctionnels sont réutilisés car les tests de performance permettent de devenir un expert et de ne pas retravailler.


0
2018-03-29 15:40



Vous n'êtes pas le seul à chercher à intégrer des tests de performances à une intégration continue. En général, les tests non fonctionnels étaient ignorés ou laissés à la fin du processus de livraison de logiciels par de nombreuses ogranisations. Je peux constater un changement positif dans l’attitude et un intérêt accru pour la vérification automatique des exigences non fonctionnelles dans le cadre du CI / CD. Cela inclut la performance, l'accessibilité et la sécurité, dans une mesure différente. Vous avez mentionné l'utilisation de Selenium pour les tests de performance. Je sais que certaines personnes (essayez de le faire), et même vu à quel point l'une de ces tentatives a échoué. Je comprends parfaitement pourquoi les gens envisagent de le faire, même si je suggère de rester loin de cela. Sauf si vous avez une très bonne raison de faire le contraire. En général, il est plus difficile à réaliser qu'on ne le pense. Le sélénium est un excellent outil à inclure dans CI à des fins de test d'interface graphique, mais son intégration dans les tests de performances est quelque peu problématique.

Il existe maintenant un nouvel outil, qui peut vous aider à intégrer JMeter avec le serveur CI de votre choix, avec certaines fonctionnalités dédiées à TeamCity et Jenkins:

https://github.com/automatictester/lightning

Les demandes de fonctionnalités sont les bienvenues.


0
2017-07-26 16:15