Table des matières
Quand commencent les tests de performances ?
1. Formuler des objectifs de test de performance
2. Acquisition de scénarios de test de performance
3. Détermination des données de test de performance
4. Conception de cas de test de performance
5. Préparation et construction de l'environnement de test de performance
11. Dessiner et rédiger des rapports
Quand commencent les tests de performances ?
Généralement, il commence à s'exécuter une fois que le fonctionnement du système est stable et qu'il n'y a pas de défauts majeurs. Cependant, les travaux préparatoires peuvent commencer par l'analyse des exigences du système : formulation d'objectifs de performance, acquisition de scène, application d'environnement, etc.
1. Formuler des objectifs de test de performance
Tester le temps de réponse d'un scénario spécifique sous un nombre spécifique d'utilisateurs simultanés
Tester le nombre maximum d'utilisateurs simultanés dans un scénario spécifique sous une certaine exigence de temps de réponse
Tester le TPS d'un scénario spécifique
1. Système en ligne
Analysez les journaux du système en ligne pour obtenir l'état d'accès de chaque fonction du système, le nombre maximum d'utilisateurs simultanés et le temps de réponse moyen/maximum/minimum. Utilisez ensuite la tendance de croissance quotidienne pour déterminer le nombre maximal d'utilisateurs simultanés, et le temps de réponse fait référence aux résultats de l'analyse du journal, ce qui équivaut au temps de réponse moyen.
2. Nouveau projet
Documentation relative au processus de développement
Les documents tels que les plans de développement de projet, les spécifications des exigences et les spécifications de conception peuvent tous impliquer des exigences pour les tests de performance. En rassemblant ces matériaux, des exigences de performance préliminaires peuvent être trouvées. Cependant, ces exigences de test de performance ne sont souvent pas suffisamment précises et nécessitent des conseils professionnels de la part de testeurs de performance.
Articles similaires
D'autres produits ou projets passés de l'entreprise accumuleront certaines données, qui peuvent être utilisées comme référence.
modèle d'utilisation de l'utilisateur
L'analyse des modèles d'utilisation des utilisateurs est un moyen efficace d'obtenir les exigences de test de performance, en considérant quels utilisateurs utilisent quels services typiques du système et combien d'utilisateurs exécutent quelles fonctions à quel moment. Par exemple : dans un système OA, 200 utilisateurs se connecteront au système en 10 minutes à 8h00 tous les matins ; le pic des transactions de requêtes quotidiennes est de 9h00 à 11h00 et de 14h00 à 16h00. l'après-midi, etc., puis selon Cet utilisateur utilise le modèle et combine le principe 80/20 pour calculer le volume simultané des services de requête de connexion et de transaction du système OA.
Principe 80/20
Le principe 80/20 est que 80 % de l'activité du système est réalisée en 20 % du temps chaque jour ouvrable, ou 80 % des utilisateurs du système se concentreront sur les opérations d'application en 20 % du temps. Prenons deux exemples pour illustrer :
(1) Un site web compte au total 100 000 visiteurs quotidiens, dont 30 % parcourent les pages produits, 20 % sont des services de recherche et 50 % sont des services de connexion + achat. En utilisant le principe 80-20, 20% de 8 heures est utilisé comme temps de référence pour calculer le nombre simultané de chaque entreprise.
Entreprise de recherche : (100 000 * 20 % * 80 %)/(8 * 3 600 * 20 %) = 2,78 arrondi à 3
Parcourir la page produit unique : (100000*30%*80%)/(8*3600*20%)=4.17 arrondi à 5
Connexion+achat : (100000*50%*80%)/(8*3600*20%)=6.94 arrondi à 7
(2) L'activité annuelle du système est concentrée sur 8 mois, avec une moyenne de 20 jours ouvrables par mois, et chaque jour ouvrable est de 8 heures.Selon le principe 80/20, 80% de l'activité est réalisée en 1,6 heures par jour. L'année dernière, environ 1 million de transactions commerciales ont été traitées, dont 15% du traitement commercial nécessaire pour soumettre 7 demandes au serveur d'application pour chaque entreprise, dont 70% du traitement commercial nécessaire pour soumettre 5 demandes au serveur d'application pour chaque entreprise, et les 15 % de traitement d'entreprise restants, chaque entreprise doit soumettre 3 requêtes au serveur d'application. Selon les résultats statistiques précédents, la croissance annuelle de l'activité est de 15 %. Compte tenu des besoins de développement de l'activité au cours des trois prochaines années, le test doit calculer le TPS que le système devrait atteindre en fonction du nombre de demandes deux fois le volume d'activité actuel.
Le nombre total de demandes par an = (1 million*15%*7+1 million*70%*5+1 million*15%*3)*2=10 millions
TPS=(10000000*80%)/(8*20*8*3600*20%)=8.68, TPS=9
norme de temps de réponse
En 2 secondes, l'utilisateur se sent bien
2 ~ 5 secondes, l'utilisateur le trouve acceptable
5 à 10 secondes, l'utilisateur se sentira très irritable, incapable de recevoir et actualisera fréquemment la page
Pendant plus de 10 secondes, l'utilisateur ne peut pas recevoir du tout et quitte directement
Tutoriel vidéo d'ingénieur de test de performance : 2023 dernière explication détaillée de l'ensemble du processus d'un projet de test de performance d'entreprise réel, le type qui peut être écrit dans l'entretien de CV_哔哩哔哩_bilibili 
https://www.bilibili.com/video/ BV1PW4y1R7ye/?spm_id_from=333.999.0.0
2. Acquisition de scénarios de test de performance
1. Système en ligne
Scène unique :
Selon les résultats de l'analyse du journal du système en ligne, les fonctions avec le plus grand nombre de visites, les fonctions qui sont modifiées et peuvent être affectées par ce changement, et les fonctions liées à l'argent. Pour être sûr, il est préférable de confirmer avec le développeur les fonctions qui seront affectées.
Scène mixte :
Toujours sur la base des résultats de l'analyse du journal du système en ligne, le nombre maximum de simultanéité au niveau du système est obtenu, puis un incrément est effectué en fonction de la tendance de croissance quotidienne pour obtenir le nombre maximum final de simultanéité. Attribuez ensuite des utilisateurs en fonction de la proportion de chaque fonction importante dans les résultats de l'analyse du journal.
Scénario de stabilité :
Après avoir déterminé la scène unique et la scène mixte, la scène de stabilité doit également être prise en compte. Son but est de tester si le système a des fuites de mémoire, et il peut également tester le temps moyen entre les pannes du système. Par conséquent, des tests de stabilité à long terme peuvent être effectués avec des scènes mixtes.
2. Nouveau projet
Scène unique :
Fonctions de base importantes
Fonctions communes
Fonctions avec des processus métier complexes
Fonctions gourmandes en ressources (telles que les requêtes multi-tables ou l'insertion de données dans plusieurs tables)
Scène mixte :
Ajoutez toutes les fonctions importantes à la scène de mixage selon un certain ratio
Scénario de stabilité :
Envisagez d'utiliser des scénarios mixtes pour les tests de stabilité à long terme.
3. Détermination des données de test de performance
Un point très important dans les tests de performance est la conception des données de scène. Par exemple, dans un scénario de requête de données, si la table de base de données correspondant au scénario ne contient que 10 éléments de données, le résultat de la requête doit être relativement rapide. Cependant, si la table de base de données correspondant à ce scénario de requête contient 10 millions d'éléments de données, le résultat de la requête sera certainement plus lent que le résultat de la requête avec seulement 10 éléments de données. Si le test de performances ne tient pas compte de la quantité de données, les résultats du test de performances seront inexacts et il y aura une forte probabilité de problèmes de performances causés par des facteurs qui ne tiennent pas compte de la quantité de données après la mise en ligne.
Pour le système en ligne, le volume de données de chaque table peut être déterminé en fonction du volume de données et de l'incrément de chaque table dans le système en ligne. Le nouveau système doit être déterminé en fonction des documents de développement et des parties prenantes concernées du projet (tels que : les représentants des clients, les chefs de projet, les analystes des exigences, les architectes système et les chefs de produit)
4. Conception de cas de test de performance
1. Scène unique
Description du scénario : simuler la connexion d'un utilisateur
Concurrence : simulez le nombre d'utilisateurs simultanés à 1, 10 et 50 respectivement pour les tests
Temps de test de pression : 15 minutes à chaque fois
Volume de données : il y a 700 000 comptes dans la table des utilisateurs MySQL
Rendez-vous : pas de rendez-vous
Concentrez-vous sur les indicateurs : temps de réponse, taux de réussite des transactions, utilisation des ressources du serveur d'application (CPU, mémoire, IO), utilisation des ressources de la base de données MySQL (CPU, mémoire, IO), s'il y a des erreurs telles que le blocage dans le journal des applications, s'il y a toute erreur dans le journal de la base de données Erreurs telles que les blocages, l'utilisation de la mémoire JVM et les conditions GC
Indicateurs attendus : temps de réponse dans les 2 secondes, taux de réussite des transactions de 100 %, utilisation du processeur du serveur d'application et du serveur de base de données ≤ 60 %, aucune fuite de mémoire, blocage de base de données, blocage de thread, etc.
2. Scène mixte
Les scénarios mixtes ne combinent pas tous les scénarios de test pour former un grand scénario, mais doivent d'abord envisager différentes combinaisons de scénarios mixtes, tels que des scénarios mixtes d'opérations de requête de base de données, des scénarios mixtes d'opérations d'écriture de base de données et des opérations de requête et d'écriture de base de données. mélanger la scène. comme suit:
Description du scénario : simulez un scénario mixte dans lequel le système n'exige pas que les utilisateurs effectuent des opérations de lecture et d'écriture dans la base de données. Les scénarios incluent la connexion de l'utilisateur, la requête par défaut du mot d'annonce, un nouveau groupe d'annonces, la création d'un mot d'annonce par défaut, l'examen des annonces, la validation des annonces et mots triés par prix.
Concurrence : un total de 300 utilisateurs sont simulés pour fonctionner en même temps, dont les opérations de connexion représentent 20 %, la requête par défaut pour les publicités représente 25 %, les nouveaux groupes d'annonces représentent 15 %, la création par défaut de publicités représente 8 % , l'examen des publicités représente 10 % et les publicités prennent effet 15 %, les mots publicitaires triés par prix 7 %
Temps de test de pression : 15 minutes à chaque fois
Volume de données : la table cpc de MySQL contient 1,5 million de données, la table de plan contient 100 000 données, la table de groupe contient 500 000 données, la table d'audit contient 1 million de données, la table de rapport MongoDB contient 1 To de données, la table utilisateur contient 900 000 données d'article.
Rendez-vous : pas de rendez-vous
Concentrez-vous sur les indicateurs : temps de réponse, taux de réussite des transactions, utilisation des ressources du serveur d'application (CPU, mémoire, IO), utilisation des ressources de la base de données MySQL (CPU, mémoire, IO), s'il y a des erreurs telles que le blocage dans le journal des applications, s'il y a toute erreur dans le journal de la base de données Erreurs telles que les blocages, l'utilisation de la mémoire JVM et les conditions GC
Indicateurs attendus : le temps de réponse pour les opérations telles que la connexion, la requête par défaut des mots publicitaires et le nouveau groupe d'annonces est inférieur à 2 secondes ; le temps de réponse pour les opérations telles que la création par défaut des mots publicitaires, l'examen des publicités, l'activation des publicités et le classement des publicités mots par prix est dans les 3 secondes; le taux de réussite des transactions 100%, l'utilisation du processeur du serveur d'applications et du serveur de base de données ≤ 60%, pas de fuites de mémoire, de blocages de base de données, de blocages de threads, etc.
3. Scénario de stabilité
Description du scénario : simulez un scénario mixte dans lequel le système n'exige pas que les utilisateurs effectuent des opérations de lecture et d'écriture dans la base de données. Les scénarios incluent la connexion de l'utilisateur, la requête par défaut du mot d'annonce, un nouveau groupe d'annonces, la création d'un mot d'annonce par défaut, l'examen des annonces, la validation des annonces et mots triés par prix.
Concurrence : un total de 300 utilisateurs sont simulés pour fonctionner en même temps, dont les opérations de connexion représentent 20 %, la requête par défaut pour les publicités représente 25 %, les nouveaux groupes d'annonces représentent 15 %, la création par défaut de publicités représente 8 % , l'examen des publicités représente 10 % et les publicités prennent effet 15 %, les mots publicitaires triés par prix 7 %
Durée du test de pression : 2 * 24 heures
Volume de données : la table cpc de MySQL contient 1,5 million de données, la table de plan contient 100 000 données, la table de groupe contient 500 000 données, la table d'audit contient 1 million de données, la table de rapport MongoDB contient 1 To de données, la table utilisateur contient 900 000 données d'article.
Rendez-vous : pas de rendez-vous
Focus sur les métriques : utilisation de la mémoire JVM et GC
Métriques attendues : aucune fuite de mémoire ou signe d'occurrence
Tutoriel vidéo d'ingénieur de test de performance : 2023 dernière explication détaillée de l'ensemble du processus d'un projet de test de performance d'entreprise réel, le type qui peut être écrit dans l'entretien de CV_哔哩哔哩_bilibili https://www.bilibili.com/video/ BV1PW4y1R7ye/?spm_id_from=333.999.0.0
5. Préparation et construction de l'environnement de test de performance
L'environnement de test de performance comprend l'environnement logiciel, l'environnement matériel et l'environnement réseau. Ces trois environnements font non seulement référence à l'environnement du serveur d'applications, mais incluent également les serveurs de bases de données, les serveurs de cache, les serveurs de fichiers et d'autres environnements de serveurs d'applications intermédiaires.
L'environnement matériel comprend : le processeur, la mémoire, le disque et d'autres facteurs de base.
L'environnement logiciel comprend : le numéro de version du système d'exploitation, la configuration, la partition de disque Linux, la version JDK, le numéro de bit, le fabricant, le numéro de version du middleware, le numéro de bit, le numéro de version de la base de données, le numéro de bit et les chemins d'installation de ces logiciels. en ligne L'environnement est cohérent. Les fichiers de configuration incluent la configuration JVM, la configuration du middleware, les fichiers de configuration de la base de données, etc.
L'environnement réseau comprend : le protocole réseau et la bande passante réseau.
L'environnement de cluster comprend : l'environnement d'équilibrage de charge des serveurs liés aux applications, l'environnement de secours automatique ou maître-esclave de la base de données, l'environnement de cluster, etc.
Lors de la demande d'un environnement de test de simulation hors ligne, les principes suivants doivent être suivis :
(1) L'environnement matériel est aussi cohérent que possible avec l'environnement de production
(2) S'il s'agit d'un environnement de cluster, il est impossible de postuler pour autant de serveurs dans l'environnement de test, vous pouvez donc envisager de postuler pour 3 machines compatibles avec l'environnement de production en ligne en tant que machines de test de performances hors ligne. Au cours du test de performances, vous pouvez tester les performances de l'équilibrage de charge sur une seule machine, deux machines et trois machines respectivement, puis calculer la perte de performances de l'environnement de production en ligne (par exemple, 100 machines) pour l'équilibrage de charge selon à la performance dans les trois cas Rate, afin de calculer de manière plus réaliste l'indice de performance lorsque 100 machines de la ligne sont équilibrées en charge.
(3) Si l'environnement de cluster de base de données est trop grand, par exemple, la base de données comporte 8 groupes de 32 machines, les tests hors ligne ne s'appliqueront pas aux 32 machines pour les tests de performances. Généralement, dans ce cas, seul un ensemble de bases de données (un maître et trois esclaves) sera appliqué comme base de données pour les tests de performance. Étant donné que les clusters de grandes bases de données adoptent essentiellement la stratégie de fractionnement des bases de données et des tables, cela conduira à d'énormes clusters de bases de données. Le test de performance peut être effectué en postulant pour un ensemble de machines de base de données. Il suffit de s'assurer que les données utilisateur utilisées pour le test de performance correspondent à l'ensemble de bases de données appliqué.
(4) S'il est impossible de s'assurer que l'environnement matériel est cohérent avec l'environnement en ligne, seul l'environnement à faible configuration peut être utilisé pour les tests. Si les résultats mesurés dans l'environnement à faible configuration peuvent répondre aux exigences en ligne, alors l'environnement en ligne à haute configuration doit également répondre aux exigences établies. Si cela ne peut pas être satisfait, l'estimation de la modélisation n'est pas recommandée, car si le nombre de granules de CPU, le cache, la taille de la mémoire physique et la vitesse du disque sont différents, les résultats de performances obtenus par la modélisation des performances ne seront pas suffisamment précis. Si le test sur une machine à faible configuration ne répond pas aux exigences, l'environnement de test doit être indiqué dans le rapport de test, et il ne peut être garanti que l'environnement de test répondra aux exigences en raison de l'amélioration de l'environnement de test.
Préparation du serveur fictif :
Il s'appelle Mock Server dans l'industrie Internet, et il s'appelle déflecteur de test de performance dans les secteurs bancaires et autres secteurs financiers. Parfois, le débogage conjoint du système doit appeler l'interface d'autres systèmes, mais le développement d'autres systèmes n'est pas terminé. Dans cette situation, une solution courante consiste à créer un serveur temporaire, à simuler ces services et à fournir des données pour le débogage et les tests conjoints. L'utilisation de Mock Server apporte généralement les avantages suivants :
(1) Isolez les erreurs de test de ce module causées par d'autres modules ou des erreurs système.
(2) Isolez l'état de développement des autres modules, tant que l'interface est définie, peu importe que le développement soit terminé ou non.
(3) Certaines opérations lentes peuvent être remplacées par Mock Object et renvoyées rapidement.
6. Créez un scénario
Pas décrit en détail ici.
Seven, scène de course
Exécutez des scénarios de test basés sur des cas de test.
Huit, faites le suivi
Dans le processus de test des performances, utilisez d'abord les commandes pour surveiller, puis connectez-vous à l'outil de surveillance en cas de problème.
9. Analyse et réglage
Après chaque réglage, les informations de configuration et les résultats des tests doivent être enregistrés en détail.
10. Tests de régression
Après le test de régression, une fois tous les objectifs atteints, le rapport de test de performance est rédigé et envoyé aux membres de l'équipe projet.
11. Dessiner et rédiger des rapports
1. Objectifs des tests
Quels scénarios, nombre d'utilisateurs simultanés, temps de réponse, TPS
2. Conclusion de l'essai
réussite/échec
3. Optimisation de ce test
Un certain scénario : le TPS était de 5 au début du test, et le TPS a atteint 30 après l'optimisation. Quels problèmes ont été trouvés et comment les résoudre.
4. Changements optimisés
le code
JVM
base de données
middleware
Serveur Linux
5. Conditions d'essai spécifiques
structure du système
environnement d'essai
Méthodes d'essai
Résultats de test
6. Suggestions d'optimisation ultérieures
Résumer:
Merci à tous ceux qui ont lu mon article sérieusement! ! !
J'ai personnellement trié certains documents techniques que j'ai compilés au cours de ma carrière de testeur de logiciels au cours des dernières années, notamment : des livres électroniques, des modules de CV, divers modèles de travail, des livres d'entretien, des projets d'auto-apprentissage, etc. Chacun est invité à laisser un message dans l'espace commentaire 333 pour le recevoir gratuitement.
