Les tests continus sont une pratique de test qui comprend des activités de test impliquant toutes les caractéristiques de qualité. Par conséquent, les tests continus incluent également les tests non fonctionnels. Comme nous le savons tous, les caractéristiques de qualité des logiciels incluent la fonctionnalité, la fiabilité, la convivialité, l'efficacité, etc. Nous avons introduit certaines méthodes de mise en œuvre fonctionnelle dans les tests continus, expliquons donc les tests non fonctionnels dans les tests continus.
Test de performance
Les tests de performances sont probablement un terme que tous les ingénieurs de test connaissent. De nombreuses personnes peuvent expliquer comment effectuer des tests de performances. Quant à ce qu'est un test de performance, il est difficile de donner une définition. Les tests de performances sont un concept global qui fait référence au nombre d'utilisateurs simultanés que le système de test peut supporter sous certaines contraintes. Les contraintes font ici référence à des contraintes externes telles que les logiciels, le matériel et le réseau requis pour le fonctionnement du système testé.
Les tests de performances impliquent également des concepts tels que les tests de charge, les tests de contrainte, les tests de limites et les tests de capacité. Ces concepts sont étroitement liés et il n'existe pas de définition généralement acceptée dans l'industrie.
En fait, les tests de charge sont un test qui simule les conditions de charge supportées par le système logiciel réel. Les tests de résistance sont utilisés pour évaluer la façon dont un système fonctionnera aux charges prévues ou au-dessus. Les tests de limite sont similaires aux tests de contrainte et les tests de capacité sont similaires aux tests de charge. Mais ce ne sont que des classifications conceptuelles et il nous est difficile de faire une distinction claire entre les tests de charge et les tests de contrainte au cours du processus de test.
Dans le travail réel, les tests de performances, les tests de contrainte et les tests de charge font souvent référence à une seule chose, à savoir les tests de charge. Ainsi, au travail, lorsque les concepts ci-dessus sont mentionnés, à moins qu'il n'y ait d'autres conditions préalables, vous pouvez vous préparer selon le test de charge.
Les tests continus sont plus enclins au processus de livraison fluide et continu des produits, donc dans les tests de performances, ils sont plus enclins à la pratique d'application de la technologie de test de performance bidirectionnelle du pipeline DevOps, en particulier la mise en œuvre des tests de performance en tant que technologie de code.
Présentation des outils de test de performances
Le test de performances est effectué en simulant un accès simultané élevé. Cette simulation n'implique pas vraiment que plusieurs utilisateurs accèdent au système ensemble, mais est effectuée via des outils. Il existe trois modes pour les outils de test de performances permettant de simuler une concurrence élevée, à savoir multi-processus, multi-thread et coroutine. La relation entre les processus, les threads et les coroutines est illustrée dans la figure 3-1.
Les processus sont définis pour une meilleure utilisation des ressources du processeur et sont utilisés pour allouer les ressources système et identifier les tâches. Un processus est la plus petite unité d'allocation de ressources système et occupe principalement des ressources telles que l'espace d'adressage, les variables globales, les descriptions de fichiers et le matériel. Le système d'exploitation effectue plusieurs tâches de manière multi-processus, afin que les ressources du système puissent être pleinement utilisées.
Parmi les outils de test de performances courants actuels, LoadRunner prend en charge le multi-processus, mais les frais d'autorisation de cet outil sont très coûteux. De plus, le mode multi-processus occupe plus de ressources système et la surcharge de planification entre les processus est relativement importante, il n'est donc pas recommandé d'utiliser le mode multi-processus dans les tests de performances.
Les threads sont différents.Les threads réduisent la consommation de changement de contexte et améliorent la concurrence du système. Les threads sont comme plusieurs lignes de production dans un atelier de production automobile, et chaque ligne de production traite simultanément le même travail de transaction. Si plusieurs threads sont démarrés dans un processus pour traiter la même logique, l'effet d'un traitement simultané est obtenu. LoadRunner et JMeter prennent en charge le modèle d'accès simultané multithread, parmi lesquels JMeter est un outil de test de performances open source.
Dans le processus de test de performances, le modèle multithreading est souvent utilisé pour simuler un accès simultané, afin que l'accès simultané puisse être effectué et que les ressources système puissent être pleinement utilisées. Coroutine est un concept relativement nouveau. Il complète la planification via le contrôle de l'utilisateur au lieu du CPU, évitant ainsi la consommation de ressources causée par le changement de contexte au niveau du noyau et brise les performances des threads sur les goulots d'étranglement des E/S. La coroutine ne nécessite pas de mécanisme de verrouillage multithread et la planification est implémentée en fonction des threads.
Locust est un outil de test de performances basé sur le modèle d'accès coroutine. De nombreux lecteurs engagés dans des tests de performances auraient dû entendre parler de LoadRunner, mais il y a probablement moins de personnes qui connaissent Locust. Ces deux outils ont leurs propres avantages, et celui à choisir dans un projet réel dépend de la situation.
Cependant, à l’ère actuelle de la technologie de conteneurisation, LoadRunner est devenu moins utile. LoadRunner et Locust fournissent tous deux des fonctions telles que l'édition et l'enregistrement de scripts d'interface utilisateur, le réglage de scènes, etc., ce qui conduit à une simulation simultanée uniquement lors de leur utilisation sur le conteneur, et l'écriture du script doit être effectuée sur le PC client. Pour l'outil de test de performances sur le conteneur, nous espérons qu'il aura les fonctions suivantes.
Prend en charge l'édition et le débogage de scripts sur PC.
Prend en charge l'édition de scripts et le débogage sur le conteneur.
Prise en charge des tests de performances côté serveur.
Il dispose d'une fonction de configuration de scénarios de performances côté serveur.
Il dispose d'une fonction de paramétrage de scène sans interface utilisateur côté serveur.
Il peut être intégré au système CI (Continuous Integration).
En résumé, Locust est fortement recommandé. Même s'il n'est pas utilisé sur des conteneurs, Locust est un bon choix. Locust est un outil de test de performances open source qui prend en charge l'utilisation du code Python pour définir les comportements des utilisateurs et utilise du Python pur pour décrire les scripts de test.
Utilisez Locust pour simuler des millions d'utilisateurs simultanés accédant au système. En plus de HTTP/HTTPS, Locust peut également être utilisé pour tester des systèmes utilisant d'autres protocoles, il suffit d'utiliser Python pour appeler la bibliothèque correspondante et décrire la requête.
Locust est également un outil de test de charge utilisateur distribué qui peut être utilisé pour tester des sites Web ou d'autres systèmes. Locust peut être utilisé pour tester le nombre d'utilisateurs traités simultanément du système, qui est entièrement basé sur le temps, de sorte qu'une seule machine peut prendre en charge des milliers d'utilisateurs simultanés.
Il est difficile pour LoadRunner et d'autres outils de test qui utilisent des processus et des threads de simuler une pression de concurrence élevée sur une seule machine. Comparé à de nombreuses autres applications basées sur les événements, Locust n'utilise pas de rappels, mais utilise une méthode de traitement légère : les coroutines.
Une coroutine est un thread léger en mode utilisateur contrôlé par l'utilisateur. La coroutine a son propre contexte de registre et sa propre pile. Lorsque le changement est en cours, la coroutine enregistrera le contexte de registre et la pile à d'autres emplacements. Lors du retour en arrière, la coroutine peut non seulement restaurer le contenu enregistré, réduisant ainsi la consommation de changement de noyau, mais également accéder aux variables globales sans verrouillage. La coroutine évite la planification des ressources au niveau du système, améliorant ainsi considérablement la capacité de concurrence d'une seule machine.
Parmi les huit caractéristiques de qualité du GB/T 25000.10, la caractéristique de qualité indépendante de l'efficacité des performances comprend des sous-caractéristiques de qualité telles que les caractéristiques de temps, l'utilisation des ressources, la capacité et la conformité à l'efficacité des performances. Le processus d'utilisation de moyens techniques pour tester l'efficacité des performances des systèmes d'information est appelé test de performance. Les tests de performance nous permettent d'évaluer dans quelle mesure un système d'information répond aux exigences d'efficacité de performance. Les systèmes d'information contiennent généralement des informations sur les aspects suivants.
Nombre d'utilisateurs simultanés : il s'agit du serveur, faisant référence au nombre d'utilisateurs en ligne interagissant avec le serveur en même temps. Lors des tests de résistance, le nombre d'utilisateurs simultanés fait référence au nombre d'utilisateurs qui exécutent une ou plusieurs opérations en même temps, ou au nombre d'utilisateurs qui exécutent un certain script en même temps. La situation de concurrence dans différents scénarios est différente. Dans le travail de test réel, le nombre d'utilisateurs simultanés doit être défini en fonction d'exigences spécifiques.
Le nombre maximum d'utilisateurs simultanés : utilisé pour décrire la capacité maximale de service du système d'information.
Débit : nombre de requêtes que le système peut traiter par unité de temps. Pour les systèmes interactifs, l'unité de débit est généralement octets/seconde, pages/seconde ou requêtes/seconde ; pour les systèmes non interactifs, l'unité de débit est généralement transactions/seconde.
Temps de réponse : divisé en temps de réponse de l'utilisateur et temps de réponse du système. Le temps de réponse de l'utilisateur fait référence au temps de réponse du système que l'utilisateur peut percevoir pour son fonctionnement. Les yeux humains ne peuvent détecter que des changements visuels de plus de 0,1 s en raison du phénomène de « persistance de la vision », de sorte que le temps de réponse de l'utilisateur ne doit pas dépasser 0,1 s. Le temps de réponse du système est le temps nécessaire à un ordinateur pour répondre à la saisie ou à la demande d'un utilisateur. Les tests de résistance considèrent généralement les problèmes du point de vue des utilisateurs et mesurent donc le temps de réponse des utilisateurs.
Utilisation des ressources : série d'indicateurs de données décrivant l'état des performances du système d'information, notamment l'utilisation du processeur, l'utilisation de la mémoire, le débit d'E/S du disque, le débit du réseau, etc. du serveur testé.
Temps d'attente : intervalle de temps entre deux requêtes consécutives émises par les utilisateurs du système d'information lors de la réalisation d'opérations métiers.
Les tests de performances sont utilisés pour évaluer l’état de fonctionnement du système. Les tests de performances sont principalement divisés en trois types suivants.
Test de contrainte de charge : en ajoutant continuellement de la charge au système, observez les changements de performances du système et déterminez que le système répond à une série d'indicateurs de performances (y compris le temps de réponse, l'utilisation du processeur, l'utilisation de la mémoire, le débit du réseau, le taux d'E/S du disque, etc., parmi lesquels les indicateurs de performance clés sont la charge maximale qui peut être supportée en fonction du temps de réponse, de l'utilisation du processeur et de l'utilisation de la mémoire.
Test de récupération après panne : pour le système qui fournit une sauvegarde de redondance du système ou un mécanisme d'équilibrage de charge, après une défaillance partielle du système simulé, dans le cas où un grand nombre d'utilisateurs continuent d'accéder au système, la récupération de la capacité de service du système est testée. principalement utilisé pour évaluer la robustesse et la récupérabilité du système.
Test de fatigue : le test de fonctionnement du système pendant une longue période à condition de garantir le volume d'affaires total est principalement utilisé pour évaluer la capacité du système à fonctionner de manière stable pendant une longue période sans panne (la période de test est généralement de 7 × 24 heures. heures, 3×24 heures ou 1× 24 heures).
Enfin, je voudrais remercier tous ceux qui ont lu attentivement mon article. La réciprocité est toujours nécessaire. Bien que ce ne soit pas une chose de très grande valeur, vous pouvez la retirer si vous en avez besoin :
Applet d'entretien de test logiciel
La banque de questions de tests logiciels optimisée par des millions de personnes ! ! ! Qui est qui sait ! ! ! Le mini programme de quiz le plus complet de tout le réseau, vous pouvez utiliser votre téléphone portable pour faire les quiz, dans le métro ou dans le bus, roulez-le !
Les sections de questions d'entretien suivantes sont couvertes :
1. Théorie de base des tests logiciels, 2. Web, applications, tests de fonctions d'interface, 3. réseau, 4. base de données, 5. Linux
6. Web, application, automatisation de l'interface, 7. tests de performances, 8. bases de la programmation, 9. questions d'entretien RH, 10. questions de test ouvertes, 11. tests de sécurité, 12. bases de l'informatique
Ces matériaux devraient constituer l'entrepôt de préparation le plus complet et le plus complet pour les amis [des tests de logiciels]. Cet entrepôt a également accompagné des dizaines de milliers d'ingénieurs de test tout au long du voyage le plus difficile. J'espère qu'il pourra vous aider aussi !