Test de performance

Teneur

Les tests de performances jouent un rôle important dans l'assurance qualité des logiciels et comprennent une grande variété de contenus de test. Le China Software Evaluation Center résume le test de performance en trois aspects : le test de performance de l'application sur le client, le test de performance de l'application sur le réseau et le test de performance de l'application sur le serveur. Dans des circonstances normales, une combinaison efficace et raisonnable des trois aspects peut permettre une analyse complète des performances du système et la prédiction des goulots d'étranglement.

Client

Le but du test de performance de l'application sur le client est d'examiner les performances de l'application client, et l'entrée du test est le client. Il comprend principalement des tests de performances simultanés, des tests de résistance à la fatigue, des tests de grands volumes de données et des tests de vitesse, parmi lesquels les tests de performances simultanés sont au centre.

Les tests de performances simultanés sont le point clé

Le processus de test de performance simultané est un processus de test de charge et de test de contrainte, c'est-à-dire augmentant progressivement la charge jusqu'à ce que le goulot d'étranglement du système ou des points de performance inacceptables. Processus de détermination des performances simultanées du système en analysant de manière exhaustive les indicateurs d'exécution de transaction et les indicateurs de surveillance des ressources. Le test de charge (LoadTesting) consiste à déterminer les performances du système sous diverses charges de travail. L'objectif est de tester les éléments de sortie correspondants des composants du système lorsque la charge augmente progressivement, tels que le débit, le temps de réponse, la charge CPU, l'utilisation de la mémoire, etc. pour déterminer les performances du système. Le test de charge est un processus d'analyse des applications logicielles et des structures de support et de simulation de l'utilisation d'environnements réels pour déterminer des performances acceptables. Le test de résistance est un test visant à obtenir le niveau de service maximal que le système peut fournir en déterminant le goulot d'étranglement ou les points de performance inacceptables d'un système.

L'objectif des tests de performances simultanés se reflète principalement dans trois aspects : sur la base de l'activité réelle, sélectionnez des cas de test de conception d'opérations commerciales représentatives et clés pour évaluer les performances actuelles du système ; lors de l'extension de l'application Lorsque la fonction du programme ou d'une nouvelle application est sur le point d'être déployée, les tests de charge aideront à déterminer si le système peut toujours gérer la charge utilisateur attendue pour prédire les performances futures du système ; en simulant des centaines d'utilisateurs, en répétant et en exécutant le test, peut confirmer le goulot d'étranglement des performances et optimiser et ajuster l'application, le but est de trouver le problème de goulot d'étranglement.

Lorsqu'une entreprise organise sa propre force ou confie à une société de logiciels le développement d'un système d'applications en son nom, en particulier lorsqu'il est effectivement utilisé dans un environnement de production à l'avenir, les utilisateurs se demandent souvent si ce système peut supporter un grand nombre d'applications. . Les utilisateurs simultanés accèdent en même temps ? Ce type de problème est le plus courant dans les systèmes tels que les applications de base de données de traitement des transactions en ligne (OLTP), la navigation Web et la vidéo à la demande. La solution de ce type de problème nécessite l'aide de méthodes de test de logiciels scientifiques et d'outils de test avancés.

Illustration : Logiciel de facturation télécom

Comme nous le savons tous, vers le 20 de chaque mois est la période de pointe pour les appels locaux, et des milliers de points de péage de la ville sont activés en même temps. Le processus de charge est généralement divisé en deux étapes. Tout d'abord, selon le numéro de téléphone de l'utilisateur, l'utilisateur doit se renseigner sur les dépenses engagées au cours du mois en cours, puis collecter l'argent et modifier l'utilisateur à l'état payé. Un utilisateur semble avoir deux étapes simples, mais lorsque des centaines de milliers de terminaux effectuent de telles opérations en même temps, la situation est très différente. Tant de transactions se produisent en même temps, ce qui est très important pour l'application elle-même, le système d'exploitation et le serveur de base de données central. L'endurance des serveurs middleware et des équipements réseau est un test sévère. Il est impossible pour les décideurs de considérer l'endurance du système après la survenue d'un problème et de prévoir l'endurance concurrente du logiciel. C'est un problème qui devrait être résolu lors de la phase de test du logiciel.

La plupart des entreprises et des entreprises doivent prendre en charge des centaines d'utilisateurs, divers environnements d'applications et produits complexes assemblés à partir de composants fournis par différents fournisseurs, des charges d'utilisateurs imprévisibles et des applications de plus en plus complexes. réponse et défaillance du système. Le résultat est une perte de revenus de l'entreprise.

Comment simuler la situation réelle ? Trouver plusieurs ordinateurs et le même nombre d'opérateurs à opérer en même temps, puis utiliser un chronomètre pour enregistrer le temps de réaction ? De telles méthodes de test de style atelier manuel sont peu pratiques et ne peuvent pas capturer les changements internes du programme. Cela nécessite l'aide d'outils de test de résistance.

La stratégie de base des tests est le test de charge automatique. Il teste l'application en simulant des centaines ou des milliers d'utilisateurs virtuels sur un ou plusieurs PC pour exécuter l'entreprise en même temps. Temps de traitement des transactions, données de pointe du serveur middleware, état de la base de données, etc. Des tests reproductibles et réalistes peuvent mesurer en profondeur l'évolutivité et les performances de l'application, identifier le problème et optimiser les performances du système. Connaître à l'avance l'endurance du système fournit une base solide à l'utilisateur final pour planifier la configuration de l'ensemble de l'environnement d'exploitation.

Travail de préparation avant le test de performance simultané

Environnement de test : La configuration de l'environnement de test est une étape importante de la mise en œuvre du test. L'adéquation de l'environnement de test affectera sérieusement l'authenticité des résultats du test et l'exactitude. L'environnement de test comprend l'environnement matériel et l'environnement logiciel. L'environnement matériel fait référence à l'environnement constitué par les serveurs, les clients, les périphériques de connexion réseau et les périphériques matériels auxiliaires tels que les imprimantes/scanners nécessaires au test ; l'environnement logiciel fait référence au système d'exploitation et à la base de données lorsque le logiciel testé est en cours d'exécution et d'autres logiciels d'application.

Un environnement de test bien préparé présente trois avantages : un environnement de test stable et reproductible qui peut garantir des résultats de test corrects ; s'assurer que les exigences techniques pour l'exécution des tests sont respectées ; Assurez-vous que les résultats des tests sont corrects et reproductibles et faciles à comprendre.

Outil de test : le test de performance simultané est un test de type boîte noire effectué côté client. Généralement, il n'utilise pas de méthodes manuelles, mais utilise des outils pour mener des méthodes automatisées. Il existe de nombreux outils de test de performances concurrents et matures, et la sélection est principalement basée sur les exigences de test et le rapport performances-prix. Les outils de test de performance simultanés bien connus incluent QALoad, LoadRunner, BenchmarkFactory et Webstress. Ces outils de test sont tous des outils de test de charge automatisés. Grâce à des tests reproductibles et réels, ils peuvent mesurer en profondeur l'évolutivité et les performances de l'application. Ils peuvent effectuer des tâches de test automatiquement tout au long du cycle de développement, sur plusieurs plates-formes, et peuvent être simulés. Des centaines ou des milliers d'utilisateurs exécutent simultanément des services clés pour terminer le test de l'application.

Données de test : dans l'environnement de test initial, vous devez saisir des données de test appropriées. Le but est d'identifier l'état des données et de vérifier le cas de test utilisé pour les tests. Le cas de test est débogué avant le début du test formel. Minimisez les erreurs au début du test formel. Lorsque le test progresse vers le lien de processus clé, il est très nécessaire de sauvegarder l'état des données. Fabriquer des données initiales signifie stocker les données appropriées et les restaurer en cas de besoin. Les données initiales fournissent une base de référence pour évaluer les résultats de l'exécution des tests.

Lorsque le test est formellement exécuté, des données de test métier sont également requises, telles que le test de requêtes simultanées, puis la base de données et la table correspondantes doivent contenir une quantité considérable de données et le type de données doit pouvoir couvrir toutes les entreprises.

Imitez le test de l'environnement réel, certains logiciels, en particulier les logiciels commerciaux pour le grand public, ont souvent besoin d'examiner les performances dans l'environnement réel lors des tests. Par exemple, lors du test de la vitesse d'analyse d'un logiciel antivirus, la proportion de différents types de fichiers placés sur le disque dur doit être aussi proche que possible de l'environnement réel, afin que les données testées aient une signification pratique.

Types et indicateurs de tests de performance simultanés

Les types de tests de performances simultanés dépendent des objets surveillés par l'outil de test de performances simultanées. Prenons l'exemple de l'outil de test de charge automatisé QALoad. Le logiciel fournit DB2, DCOM, ODBC, ORACLE, NETLoad, Corba, QARun, SAP, SQLServer, Sybase, Telnet, TUXEDO, UNIFACE, WinSock, WWW, JavaScript et d'autres objets de surveillance différents pour diverses cibles de test, et prend en charge les tests Windows et UNIX . environnement.

La chose la plus importante reste l'application flexible des objets de surveillance dans le processus de test. Par exemple, la structure à trois niveaux du mode de fonctionnement est largement utilisée, et le test de performance simultané des middleware est mentionné comme un problème à l'ordre du jour. De nombreux systèmes utilisent tous un middleware domestique, sélectionnent des objets de surveillance JavaScript et écrivent manuellement des scripts pour atteindre l'objectif des tests.

À l'aide d'outils de test de charge automatisés pour effectuer des tests de performances simultanés, le processus de test de base suivi est : les exigences de test et le contenu de test, la formulation de cas de test, la préparation de l'environnement de test, suivi de l'exécution, analyse des résultats et localisation des problèmes, rapport de test et évaluation des tests.

Les objets des tests et de la surveillance simultanés des performances sont différents, et les principaux indicateurs du test sont également différents. Les principaux indicateurs de test incluent les indicateurs de performance de traitement des transactions et la surveillance des ressources UNIX. Parmi eux, les indicateurs de performance du traitement des transactions incluent les résultats des transactions, le nombre de transactions par minute, le temps de réponse des transactions (Min : temps de réponse minimum du serveur ; Moyenne : temps de réponse moyen du serveur ; Max : temps de réponse maximum du serveur ; StdDev : écart de réponse du serveur de transactions, valeur Plus la valeur est élevée, plus l'écart est important ; Médiane : temps de réponse médian ; 90 % : temps de réponse du serveur pour le traitement des transactions à 90 %), le nombre d'utilisateurs virtuels simultanés.

Exemple d'application : « Base de données multimédia de l'agence de presse Xinhua V1.0 » Test de performance

Centre de test de logiciels de Chine (CSTC) selon les normes nationales « Base de données multimédia (Phase I) Performance » proposée par le Bureau de la technologie de l'agence de presse Xinhua « Exigences de test » et GB/T17544 « Exigences et tests de qualité des packages », en utilisant des outils de test de charge standard de l'industrie pour effectuer des tests de performance sur la "base de données multimédia de l'agence de presse Xinhua V1.0" utilisée par l'agence de presse Xinhua.

L'objectif du test de performance est de simuler plusieurs utilisateurs accédant simultanément à la base de données multimédia de l'agence de presse Xinhua, d'effectuer des services de récupération de clés et d'analyser les performances du système.

L'objectif des tests de performance est d'effectuer des tests simultanés et des tests de fatigue pour l'activité principale de récupération qui a une charge de pression simultanée importante. Le système adopte le mode de fonctionnement B/S. Les tests simultanés sont conçus pour effectuer des cas de test simultanés dans la bibliothèque chinoise, la bibliothèque anglaise et la bibliothèque d'images au cours d'une période spécifique, tels que des termes de recherche uniques, des termes de recherche multiples, des formules de recherche variables et des services de recherche mixtes. Le cas de test de fatigue comprend 200 utilisateurs simultanés dans la base de données chinoise et une recherche par terme de recherche unique avec une période de test d'environ 8 heures. Lors des tests de concurrence et de fatigue, les indicateurs de test surveillés incluent les performances de traitement des transactions et les ressources UNIX (Linux), Oracle, Apache, etc.

Conclusion du test : dans l'environnement de test de la salle informatique de l'agence de presse Xinhua et dans l'environnement de test intranet, dans des conditions de bande passante de 100 M, pour chaque cas de test simultané spécifié, le système peut résister à la pression de charge de 200 utilisateurs simultanés et à la transaction maximale. minute atteint 78,73, le fonctionnement est fondamentalement stable, mais à mesure que la pression de charge augmente, les performances du système sont atténuées.

Le système peut résister au stress de fatigue de 200 utilisateurs simultanés pendant environ 8 heures par cycle et peut fonctionner de manière stable.

Grâce à la surveillance des ressources système UNIX (Linux), Oracle et Apache, les ressources système peuvent répondre aux exigences de performances de concurrence et de fatigue mentionnées ci-dessus, et les ressources matérielles du système ont encore beaucoup de place pour l'utilisation.

Lorsque le nombre d'utilisateurs simultanés dépasse 200, les erreurs HTTP500, de connexion et de délai d'attente sont surveillées et le serveur Web signale une erreur de dépassement de mémoire. Le système devrait encore améliorer les performances pour prendre en charge un plus grand nombre d'utilisateurs simultanés.

Il est recommandé d'optimiser davantage le système logiciel, d'utiliser pleinement les ressources matérielles et de réduire le temps de réponse des transactions.

Test de résistance à la fatigue et de grand volume de données

Le test de fatigue consiste à utiliser le nombre maximal d'utilisateurs simultanés que le système peut prendre en charge dans le cadre d'un fonctionnement stable du système, de continuer à exécuter des activités pendant un certain temps et d'analyser de manière approfondie les indicateurs d'exécution de transaction et les indicateurs de surveillance des ressources pour déterminer le processus du système. pour gérer les performances d'intensité de charge de travail maximale.

Les tests de résistance à la fatigue peuvent être effectués de manière automatisée par outil, ou ils peuvent être programmés manuellement pour les tests, dont ce dernier représente une plus grande proportion.

Dans des circonstances normales, le nombre maximal d'utilisateurs simultanés auxquels le serveur peut répondre normalement et de manière stable aux demandes est utilisé pour effectuer un test de fatigue pendant une certaine période de temps afin d'obtenir des données d'index d'exécution de transaction et des données de surveillance des ressources système. Si une erreur se produit et que le test ne peut pas être exécuté avec succès, les indicateurs de test doivent être ajustés dans le temps, par exemple en réduisant le nombre d'utilisateurs et en raccourcissant le cycle de test. Dans un autre cas, le test de fatigue consiste à évaluer les performances du système actuel, en utilisant le nombre d'utilisateurs simultanés dans des conditions commerciales normales du système comme base d'un test de fatigue pendant une certaine période de temps.

Les tests de volume de données volumineuses peuvent être divisés en deux types : les tests indépendants de volume de données volumineux pour certains services de stockage, de transmission, de statistiques et de requêtes du système ; et tests de performance de contrainte, tests de performance de charge, Un programme complet de test de volume de données combiné à des tests de performance de fatigue. La clé des tests sur de gros volumes de données est la préparation des données de test, et vous pouvez compter sur des outils pour préparer les données de test.

Le test de vitesse consiste principalement à mesurer manuellement la vitesse pour l'activité clé avec des exigences de vitesse. La valeur moyenne peut être calculée sur la base de plusieurs tests, et elle peut être comparée et analysée avec le temps de réponse mesuré par l'outil.

Côté réseau

L'objectif de l'application sur le test de performance du réseau est d'utiliser une technologie d'automatisation mature et avancée pour la surveillance des performances des applications réseau, l'analyse des performances des applications réseau et la prédiction du réseau.

Analyse des performances des applications réseau

L'objectif de l'analyse des performances des applications réseau est de montrer avec précision comment les modifications de la bande passante du réseau, de la latence, de la charge et des ports TCP affectent le temps de réponse de l'utilisateur. L'utilisation d'outils d'analyse des performances des applications réseau, tels qu'ApplicationExpert, peut détecter les goulots d'étranglement des applications. Nous pouvons connaître le comportement de l'application qui se produit à chaque étape lorsque l'application s'exécute sur le réseau et analyser les problèmes d'application au niveau du thread d'application. De nombreux problèmes peuvent être résolus : le client exécute-t-il des requêtes inutiles vers le serveur de base de données ? Lorsque le serveur reçoit une requête du client, le serveur d'applications passe-t-il un temps inacceptable à contacter le serveur de base de données ? Prédire le temps de réponse de l'application avant sa mise en production ; utiliser ApplicationExpert pour ajuster les performances de l'application sur le WAN ; ApplicationExpert vous permet de simuler rapidement et facilement les performances de l'application. Selon le temps de réponse de l'utilisateur final dans différents environnements de configuration réseau, les utilisateurs peuvent suivre leurs propres conditions Décider de l'environnement réseau dans lequel l'application sera mise en production.

Surveillance des performances des applications réseau

Après la mise en service du système, il est nécessaire de savoir à temps et avec précision ce qui se passe sur le réseau ; quelles applications sont en cours d'exécution et comment les exécuter ; combien de PC accèdent au LAN ou au WAN : quelles applications provoquent des goulots d'étranglement du système ou une concurrence entre les ressources ? À l'heure actuelle, la surveillance des performances des applications réseau et la gestion des ressources réseau sont essentielles au fonctionnement normal et stable du système. En utilisant les outils de surveillance des performances des applications réseau, vous pouvez obtenir deux fois plus de résultat avec la moitié de l'effort. À cet égard, l'outil que nous pouvons fournir est NetworkVantage. En termes simples, il est principalement utilisé pour analyser les performances des applications clés et localiser la source du problème sur le client, le serveur, l'application ou le réseau. Dans la plupart des cas, les utilisateurs se préoccupent davantage des applications qui consomment beaucoup de bande passante et des utilisateurs qui génèrent le trafic réseau le plus important. Cet outil peut également répondre aux exigences.

Prédiction de réseau

Compte tenu de l'expansion future du système, il est très important de prévoir l'impact des modifications du trafic réseau et des modifications de la structure du réseau sur les systèmes des utilisateurs. Faites des prévisions basées sur les données de planification et fournissez des données de prévision des performances du réseau en temps opportun. Nous utilisons l'outil de planification de la capacité d'analyse prédictive du réseau PREDICTOR pour : définir les niveaux de service, effectuer la planification quotidienne de la capacité du réseau, tester le réseau hors ligne, analyser les défaillances du réseau et les limites de capacité, effectuer le diagnostic quotidien des pannes, prévoir la migration des équipements réseau et les mises à niveau des équipements réseau sur l'ensemble du réseau Impacter.

Obtenez la structure de la topologie du réseau à partir du logiciel de gestion de réseau et obtenez les informations de flux à partir du logiciel de surveillance de flux existant (s'il n'y a pas un tel logiciel, les données de flux peuvent être générées manuellement), afin que la structure de base du réseau existant puisse être obtenu. Sur la base de la structure de base, des rapports et des graphiques peuvent être générés en fonction des changements dans la structure du réseau et des changements dans le trafic réseau pour illustrer comment ces changements affectent les performances du réseau. PREDICTOR fournit les informations suivantes : selon les résultats prévus, il aide les utilisateurs à mettre à niveau le réseau à temps pour éviter la dégradation des performances du système causée par des équipements clés dépassant le seuil d'utilisation ; quel équipement réseau doit être mis à niveau, ce qui peut réduire les retards du réseau et éviter les goulots d'étranglement du réseau ; Mises à niveau réseau nécessaires.

Serveur

Pour tester les performances de l'application sur le serveur, vous pouvez utiliser la surveillance des outils ou vous pouvez utiliser les commandes de surveillance du système lui-même. Par exemple, dans Tuxedo, vous pouvez utiliser la commande Top pour surveiller l'utilisation des ressources . L'objectif du test de mise en œuvre est de réaliser une surveillance complète de l'équipement du serveur, du système d'exploitation du serveur, du système de base de données et des performances des applications sur le serveur. Le principe du test est illustré dans la figure ci-dessous.

Indicateurs et descriptions de surveillance des ressources UNIX

Description des indicateurs de suivi

Le nombre moyen de processus de synchronisation au cours des 60 dernières secondes dans l'état normal du système de moyenne de charge

Taux de conflit Le nombre de conflits par seconde surveillés sur l'Ethernet

Taux d'échange de processus/fil Échanges de processus et de fil par seconde

Utilisation du processeur Taux d'occupation du processeur (%)

Taux de change du disque Taux de change du disque

Taux d'erreur de paquet de réception Le nombre d'erreurs par seconde lors de la réception de paquets de données Ethernet

Taux d'entrée des paquets Entrée par seconde Nombre de paquets Ethernet

Taux d'interruption Le nombre d'interruptions traitées par la CPU par seconde

Taux d'erreur des paquets de sortie Le nombre d'erreurs par seconde lors de l'envoi de paquets Ethernet

Packets Input rate Le nombre de paquets Ethernet émis par seconde

Le taux de lecture des pages mémoire par seconde dans la mémoire physique Le nombre de pages mémoire lues par seconde dans la mémoire physique

Le taux d'écriture de pages mémoire par seconde à partir de la mémoire physique Le nombre de pages mémoire écrites dans le fichier d'échange dans la mémoire

Le nombre de pages mémoire supprimées de la mémoire physique

Le taux d'échange des pages mémoire écrites sur les pages mémoire et les esclaves par seconde Le nombre de pages lues dans la mémoire physique

Le nombre de processus qui entrent dans la zone de change du taux de change.

Le nombre de processus qui traitent hors de la zone de change du taux de change

Taux d'occupation du processeur système Taux d'occupation du processeur système (%)

Taux d'occupation du processeur par l'utilisateur en mode utilisateur (%)

Blocage du disque Le nombre d'octets par seconde bloqués par le disque

But

Le but est de vérifier si le système logiciel peut atteindre les indicateurs de performance proposés par l'utilisateur, et de trouver les goulots d'étranglement de performance dans le système logiciel, d'optimiser le logiciel et enfin d'atteindre l'objectif d'optimisation du système.

Inclure les aspects suivants

1. Pour évaluer les capacités du système, les données de charge et de temps de réponse obtenues lors du test peuvent être utilisées pour vérifier les capacités du modèle prévu et aider à prendre des décisions.

2. Identifier les faiblesses du système : La charge contrôlée peut être augmentée à un niveau extrême et la franchir, réparant ainsi les goulots d'étranglement ou les faiblesses du système.

3. Réglage du système : exécutez le test à plusieurs reprises pour vérifier que les activités de réglage du système obtiennent les résultats attendus, améliorant ainsi les performances.

Détectez les problèmes dans le logiciel : l'exécution de tests à long terme peut entraîner l'échec du programme en raison de fuites de mémoire, révélant des problèmes cachés ou des conflits dans le programme.

4. Vérifier la stabilité (résilience) fiabilité (fiabilité) : Effectuer un test pendant une certaine période de temps sous une charge de production est le seul moyen d'évaluer si la stabilité et la fiabilité du système répondent aux exigences.

Taper

Les types de test de performance incluent le test de charge, le test de résistance, le test de capacité, etc.

Test de charge (LoadTesting) : le test de charge consiste principalement à tester si le système logiciel répond aux objectifs de la conception du document d'exigences, tels que le nombre maximal d'utilisateurs simultanés pris en charge par le logiciel sur une certaine période de temps, le taux d'erreur des demandes de logiciel , etc. , Le test principal est la performance du système logiciel.

Tests de stress : Les tests de stress sont également des tests de stress. Les tests de résistance consistent principalement à tester si le système matériel atteint les objectifs de performances de la conception du document d'exigences, tels que l'utilisation du processeur et de la mémoire du système sur une certaine période de temps. Taux d'utilisation, débit d'E/S du disque, débit du réseau, etc. La plus grande différence entre le test de résistance et le test de charge est l'objectif du test.

Test de volume : déterminez la capacité maximale du système, comme le nombre maximal d'utilisateurs du système, la capacité de stockage maximale et le flux de données le plus traité.

Le test de performance comprend les types de test suivants :

Le test de référence compare les performances d'objets de test nouveaux ou inconnus avec des normes de référence connues (telles que des logiciels existants ou des normes d'évaluation).

Test de contention :-Vérifiez si l'objet de test peut accepter les demandes de plusieurs protagonistes pour les mêmes ressources (enregistrements de données, mémoire, etc.).

Configuration de performance - pour vérifier l'acceptabilité du comportement de performance du sujet d'essai lors de l'utilisation de différentes configurations à condition que les conditions de fonctionnement restent inchangées.

Test de charge - pour vérifier l'acceptabilité du comportement de performance de l'objet de test dans différentes conditions de fonctionnement (telles que différents nombres d'utilisateurs, nombre de transactions, etc.) tout en conservant la configuration inchangée.

Test de force - pour vérifier l'acceptabilité du comportement de performance du sujet de test dans des conditions anormales ou extrêmes (telles que des ressources réduites ou un nombre excessif d'utilisateurs).

Test de capacité - pour vérifier le nombre maximum de logiciels utilisés par les utilisateurs de test en même temps.

L'évaluation des performances est généralement réalisée en collaboration avec les représentants des utilisateurs et selon une méthode à plusieurs niveaux.

Le premier niveau d'analyse des performances implique l'évaluation des résultats d'un seul protagoniste/cas d'utilisation et la comparaison des résultats de plusieurs exécutions de tests. Par exemple, lorsqu'il n'y a aucune autre activité sur l'objet de test, enregistrez le comportement de performance d'un seul acteur exécutant un seul cas d'utilisation et comparez les résultats avec plusieurs autres exécutions de test du même acteur/cas d'utilisation. Le premier niveau d'analyse permet d'identifier les tendances qui peuvent indiquer des conflits dans les ressources système qui affecteront la validité des conclusions tirées d'autres résultats de tests de performances.

Le deuxième niveau d'analyse examine les statistiques récapitulatives et les valeurs de données réelles exécutées par un protagoniste/cas d'utilisation spécifique, ainsi que le comportement de performance de l'objet de test. Les statistiques récapitulatives incluent l'écart type et la distribution en centiles du temps de réponse. Cette information montre comment la réponse du système a changé, tout comme chaque protagoniste le voit.

Le troisième niveau d'analyse permet de comprendre les causes et les poids des problèmes de performance. Cette analyse détaillée utilise des données de bas niveau et des méthodes statistiques pour aider les testeurs à tirer des conclusions correctes à partir des données. L'analyse détaillée fournit des critères objectifs et quantitatifs pour la prise de décision, mais elle prend beaucoup de temps et nécessite une compréhension de base des statistiques.

Lorsque des différences de performances et de comportement existent ou sont causées par des événements aléatoires liés à la collecte de données de test, une analyse détaillée utilise le concept de pondération statistique pour aider à comprendre. C'est-à-dire qu'au niveau de base, tout événement est aléatoire. Les tests statistiques déterminent s'il existe des différences systématiques qui ne peuvent pas être expliquées par des événements aléatoires.

Indicateurs

Les tests de performance utilisent principalement des outils de test automatisés pour simuler une variété de conditions de charge normales, de pointe et anormales afin de tester divers indicateurs de performance du système. Les tests de charge et les tests de résistance sont tous deux des tests de performance, et les deux peuvent être combinés. Grâce aux tests de charge, déterminez les performances du système sous diverses charges de travail. L'objectif est de tester l'évolution des différents indicateurs de performance du système lorsque la charge augmente progressivement. Le test de résistance est un test visant à obtenir le niveau de service maximal que le système peut fournir en déterminant le goulot d'étranglement ou les points de performance inacceptables d'un système.

Dans le travail réel, nous testons souvent deux types de logiciels : bs et cs. Quels sont les indicateurs de performance de ces deux aspects ?

Les indicateurs généraux auxquels les programmes de structure Bs prêtent généralement attention sont les suivants (abrégés) :

Indicateurs de serveur Web :

*AvgRps : nombre moyen de réponses par seconde = Temps total de requête/secondes ;

*Avgtimetolastbyteperterstion(mstes) : nombre moyen d'itérations de scripts métier par seconde. Certaines personnes confondront les deux ;

*SuccessfulRounds : requêtes réussies ;

*FailedRounds : demandes ayant échoué ;

*SuccessfulHits : clics réussis ;

*FailedHits : clics échoués ;

*HitsPerSecond : le nombre de clics par seconde ;

*SuccessfulHitsPerSecond : le nombre de clics réussis par seconde ;

*FailedHitsPerSecond : le nombre de clics échoués par seconde ;

*AttemptedConnections : le nombre de tentatives de connexion ;

Programme de structure CS, parce que l'arrière-plan général du logiciel est généralement une base de données, nous prêtons plus d'attention aux indicateurs de test de la base de données :

*User0Connections : le nombre de connexions utilisateur, c'est-à-dire le nombre de connexions à la base de données ;

*Nombre de blocages : blocage de la base de données ;

*BufferCachehit : accès au cache de la base de données

Bien sûr, dans la pratique, nous observerons toujours l'utilisation de la mémoire, du processeur et des ressources système dans le cadre du test multi-utilisateurs. Ces indicateurs sont en fait l'un des tests de performance étendus : les tests de compétition. Qu'est-ce qu'un test compétitif ? Le logiciel est en concurrence pour utiliser diverses ressources (enregistrements de données, mémoire, etc.), en fonction de sa capacité à rivaliser pour les ressources avec d'autres systèmes connexes.

Nous savons que l'architecture logicielle restreint le choix des stratégies et des outils de test dans les tests réels. Comment choisir une stratégie de test de performance est ce que nous devons comprendre dans le travail réel. Les logiciels généraux peuvent être divisés en plusieurs types selon l'architecture du système :

c/s

architecture client/serveur client/serveur

Basé sur l'architecture client/serveur à trois couches

Architecture distribuée client/serveur

b/s

Architecture à trois niveaux basée sur un navigateur/serveur Web

Architecture à trois niveaux basée sur un serveur d'application middleware

Architecture multi-tiers basée sur un serveur Web et un middleware

Pas

Dans la mise en œuvre de l'architecture du système, les développeurs peuvent choisir différentes méthodes de mise en œuvre, ce qui entraîne des situations réelles complexes et compliquées. Il nous est impossible d'expliquer chaque technologie en détail. Il s'agit simplement d'introduire une méthode pour vous expliquer comment choisir une stratégie de test, afin d'aider à analyser les indicateurs de performance des différentes parties du logiciel, puis d'analyser les indicateurs de performance et les goulots d'étranglement de l'architecture globale.

En raison des différences entre les projets et les projets, les métriques et les méthodes d'évaluation sélectionnées sont également différentes. Mais il y a encore quelques étapes générales pour nous aider à mener à bien un projet de test de performance. Les étapes sont les suivantes

1. Fixation des objectifs et système d'analyse

2. Choisissez la méthode de mesure du test

3. Technologies et outils d'apprentissage associés

4. Développer des critères d'évaluation

5. Concevoir des cas de test

6. Exécuter des cas de test

7. Analyser les résultats des tests

Élaborer des objectifs et analyser le système

La première étape de chaque plan de test de performance consiste à formuler des objectifs et à analyser la composition du système. Ce n'est qu'en clarifiant l'objectif et en comprenant la structure du système que la portée du test peut être clarifiée et savoir quel type de technologie maîtriser dans le test.

But:

1. Déterminer les besoins et les attentes des clients

2. Besoins commerciaux réels

3. Configuration requise

Composition du système

La composition du système comprend plusieurs significations : catégorie du système, composition du système, fonction du système, etc. Comprendre la nature de ces contenus nous aide en fait à clarifier la portée du test et à choisir la méthode de test appropriée pour effectuer le test.

System category: distinguishing the system category is the prerequisite for what kind of technology we have mastered, and the performance test can be successful if we master the corresponding technology. For example: the system category is a bs structure, and you need to master http protocol, java, html and other technologies. Or the cs structure, you may need to understand the operating system, winsock, com, etc. Therefore, the classification of the system is very important for us.

System composition: Hardware settings and operating system settings are the constraints of performance testing. Generally, performance testing uses testing tools to imitate a large number of actual user operations, and the system operates under overload conditions. Different system composition performance tests will get different results.

System function: System function refers to the different subsystems provided by the system, the official document subsystem in the office management system, the conference subsystem, etc. The system function is the link to be simulated in the performance test. It is necessary to understand these .

Choose the method of test measurement

After the first step, you will have a clear understanding of the system. Next, we will focus on software metrics and collect system-related data.

Related aspects of measurement:

*Develop specifications

*Develop relevant processes, roles, responsibilities

*Develop improvement strategies

*Develop results comparison standards

Related technologies and tools learned

Performance testing is to use tools to simulate a large number of user operations and increase the load on the system. Therefore, a certain knowledge of tools is required to perform performance testing. Everyone knows that performance testing tools generally record user operations through winsock, http and other protocols. The protocol selection is based on the implementation of the software system architecture (web generally chooses http protocol, cs chooses winsock protocol), and different performance testing tools have different scripting languages. For example, the vu script in rationalrobot is implemented in c-like language.

To carry out performance testing, various performance testing tools need to be evaluated, because each performance testing tool has its own characteristics. Only after tool evaluation, can performance testing tools that conform to the existing software architecture be selected. After determining the test tools, you need to organize testers to learn about the tools and train related technologies.

Develop evaluation criteria

The purpose of any test is to ensure that the software meets the pre-specified goals and requirements. Performance testing is no exception. Therefore, a set of standards must be developed.

Generally, there are four model technologies for performance testing:

*Linear projection: use a large amount of past, extended or future data to form a scatter diagram, use this The chart is constantly compared with the current state of the system.

*Analysis model: Use queuing theory formulas and algorithms to predict response time, and use data describing workloads to correlate with the nature of the system

*Imitation: imitate actual users' usage methods to test you System

*Benchmark: Define the test and your initial test as a standard, and use it to compare with all subsequent test results

Design test cases

Designing test cases is based on understanding the software business process. The principle of designing test cases is to provide the most test information with the least impact. The goal of designing test cases is to include as many test elements as possible at a time. These test cases must be achievable by the test tool, and different test scenarios will test different functions. Because performance testing is different from the usual test cases, it is possible to find the performance bottleneck of the software by designing the performance test cases as complex as possible.

Run test cases

Run test cases through performance testing tools. The test results obtained from the performance test under the same environment are inaccurate, so when running these test cases, you need to use different test environments and different machine configurations to run.

Analyze the test results

After running the test case, collect relevant information, perform statistical analysis of the data, and find the performance bottleneck. By eliminating errors and other factors, the test results are close to the real situation. Different architectures have different methods of analyzing test results. For the bs structure, we will analyze the network bandwidth and the impact of traffic on user operation response, while for the cs structure, we may be more concerned about the impact of the overall system configuration on user operations.

Methods

For enterprise applications, there are many methods for performance testing, some of which are more difficult to implement than others. The type of performance test to be performed depends on the desired result. For example, for reproducibility, benchmarking is the best method. To test the upper limit of the system from the perspective of current user load, capacity planning testing should be used. This article will introduce several methods for setting up and running performance tests, and discuss the differences between these methods.

Without reasonable planning, performance testing of J2EE applications will be a daunting and somewhat confusing task. Because for any software development process, it is necessary to collect requirements, understand business needs, and design a formal schedule before actual testing. The requirements for performance testing are driven by business needs and clarified by a set of use cases. These use cases can be based on historical data (for example, the load pattern of the server for a week) or predicted approximations. After you figure out what needs to be tested, you need to know how to test.

In the early stages of the development phase, benchmark testing should be used to determine whether performance regressions occur in the application. Benchmarking can collect repeatable results in a relatively short period of time. The best way to benchmark is to change one and only one parameter per test. For example, if you want to know whether increasing the JVM memory will affect the performance of the application, you can increase the JVM memory gradually (for example, from 1024MB to 1224MB, then 1524MB, and finally 2024MB), collect the results and environmental data at each stage, and record Information, and then go to the next stage. In this way, there are traces to follow when analyzing the test results. In the next section, I will introduce what a benchmark is and the best parameters for running a benchmark.

In the late development phase, bugs in the application have been resolved. After the application reaches a stable state, more complex tests can be run to determine the performance of the system under different load patterns. These tests are called capacity planning tests, penetration tests (soaktest), peak-rest tests (peak-resttest), and they aim to test scenarios close to the real world by testing the reliability, robustness, and scalability of the application.对于下面的描述应该从抽象的意义上理解，因为每个应用程序的使用模式都是不同的。例如，容量规划测试通常都使用较缓慢的ramp-up（下文有定义），但是如果应用程序在一天之中的某个时段中有快速突发的流量，那么自然应该修改测试以反映这种情况。但是，要记住，因为更改了测试参数（比如ramp-up周期或用户的考虑时间（think-time)），测试的结果肯定也会改变。一个不错的方法是，运行一系列的基准测试，确立一个已知的可控环境，然后再对变化进行比较。

基准测试

基准测试的关键是要获得一致的、可再现的结果。可再现的结果有两个好处：减少重新运行测试的次数；对测试的产品和产生的数字更为确信。使用的性能测试工具可能会对测试结果产生很大影响。假定测试的两个指标是服务器的响应时间和吞吐量，它们会受到服务器上的负载的影响。服务器上的负载受两个因素影响：同时与服务器通信的连接（或虚拟用户）的数目，以及每个虚拟用户请求之间的考虑时间的长短。很明显，与服务器通信的用户越多，负载就越大。同样，请求之间的考虑时间越短，负载也越大。这两个因素的不同组合会产生不同的服务器负载等级。记住，随着服务器上负载的增加，吞吐量会不断攀升，直到到达一个点。

注意，吞吐量以稳定的速度增长，然后在某一个点上稳定下来。

在某一点上，执行队列开始增长，因为服务器上所有的线程都已投入使用，传入的请求不再被立即处理，而是放入队列中，当线程空闲时再处理。

注意，最初的一段时间，执行队列的长度为零，然后就开始以稳定的速度增长。这是因为系统中的负载在稳定增长，虽然最初系统有足够的空闲线程去处理增加的负载，最终它还是不能承受，而必须将其排入队列。

当系统达到饱和点，服务器吞吐量保持稳定后，就达到了给定条件下的系统上限。但是，随着服务器负载的继续增长，系统的响应时间也随之延长，虽然吞吐量保持稳定。

注意，在执行队列（图2）开始增长的同时，响应时间也开始以递增的速度增长。这是因为请求不能被及时处理。

为了获得真正可再现的结果，应该将系统置于相同的高负载下。为此，与服务器通信的虚拟用户应该将请求之间的考虑时间设为零。这样服务器会立即超载，并开始构建执行队列。如果请求（虚拟用户）数保持一致，基准测试的结果应该会非常精确，完全可以再现。

您可能要问的一个问题是：“如何度量结果？”对于一次给定的测试，应该取响应时间和吞吐量的平均值。精确地获得这些值的唯一方法是一次加载所有的用户，然后在预定的时间段内持续运行。这称为“flat”测试。

与此相对应的是“ramp-up”测试。

ramp-up测试中的用户是交错上升的（每几秒增加一些新用户）。 ramp-up测试不能产生精确和可重现的平均值，这是因为由于用户的增加是每次一部分，系统的负载在不断地变化。因此，flat运行是获得基准测试数据的理想模式。

这不是在贬低ramp-up测试的价值。实际上，ramp-up测试对找出以后要运行的flat测试的范围非常有用。 ramp-up测试的优点是，可以看出随着系统负载的改变，测量值是如何改变的。然后可以据此选择以后要运行的flat测试的范围。

Flat测试的问题是系统会遇到“波动”效果。

注意波动的出现，吞吐量不再是平滑的。

这在系统的各个方面都有所体现，包括CPU的使用量。

注意，每隔一段时间就会出现一个波形。 CPU使用量不再是平滑的，而是有了像吞吐量图那样的尖峰。

此外，执行队列也承受着不稳定的负载，因此可以看到，随着系统负载的增加和减少，执行队列也在增长和缩减。

注意，每隔一段时间就会出现一个波形。执行队列曲线与上面的CPU使用量图非常相似。

最后，系统中事务的响应时间也遵循着这个波动模式。

注意，每隔一段时间就会出现一个波形。事务的响应时间也与上面的图类似，只不过其效果随着时间的推移逐渐减弱。

当测试中所有的用户都同时执行几乎相同的操作时，就会发生这种现象。这将会产生非常不可靠和不精确的结果，所以必须采取一些措施防止这种情况的出现。有两种方法可以从这种类型的结果中获得精确的测量值。如果测试可以运行相当长的时间（有时是几个小时，取决于用户的操作持续的时间），最后由于随机事件的本性使然，服务器的吞吐量会被“拉平”。或者，可以只选取波形中两个平息点之间的测量值。该方法的缺点是可以捕获数据的时间非常短。

性能规划测试

对于性能规划类型的测试来说，其目标是找出，在特定的环境下，给定应用程序的性能可以达到何种程度。此时可重现性就不如在基准测试中那么重要了，因为测试中通常都会有随机因子。引入随机因子的目的是为了尽量模拟具有真实用户负载的现实世界应用程序。通常，具体的目标是找出系统在特定的服务器响应时间下支持的当前用户的最大数。例如，您可能想知道：如果要以5秒或更少的响应时间支持8,000个当前用户，需要多少个服务器？要回答这个问题，需要知道系统的更多信息。

要确定系统的容量，需要考虑几个因素。通常，服务器的用户总数非常大（以十万计），但是实际上，这个数字并不能说明什么。真正需要知道的是，这些用户中有多少是并发与服务器通信的。其次要知道的是，每个用户的“考虑时间”即请求间时间是多少。这非常重要，因为考虑时间越短，系统所能支持的并发用户越少。例如，如果用户的考虑时间是1秒，那么系统可能只能支持数百个这样的并发用户。但是，如果用户的考虑时间是30秒，那么系统则可能支持数万个这样的并发用户（假定硬件和应用程序都是相同的）。在现实世界中，通常难以确定用户的确切考虑时间。还要注意，在现实世界中，用户不会精确地按照间隔时间发出请求。

于是就引入了随机性。如果知道普通用户的考虑时间是5秒，误差为20%，那么在设计负载测试时，就要确保请求间的时间为5×（1+/-20%）秒。此外，可以利用“调步”的理念向负载场景中引入更多的随机性。它是这样的：在一个虚拟用户完成一整套的请求后，该用户暂停一个设定的时间段，或者一个小的随机时间段（例如，2×（1+/-25%）秒），然后再继续执行下一套请求。将这两种随机化方法运用到测试中，可以提供更接近于现实世界的场景。

进行实际的容量规划测试了。接下来的问题是：如何加载用户以模拟负载状态？最好的方法是模拟高峰时间用户与服务器通信的状况。这种用户负载状态是在一段时间内逐步达到的吗？如果是，应该使用ramp-up类型的测试，每隔几秒增加x个用户。或者，所有用户是在一个非常短的时间内同时与系统通信？如果是这样，就应该使用flat类型的测试，将所有的用户同时加载到服务器。两种不同类型的测试会产生没有可比性的不同测试。例如，如果进行ramp-up类型的测试，系统可以以4秒或更短的响应时间支持5,000个用户。而执行flat测试，您会发现，对于5,000个用户，系统的平均响应时间要大于4秒。这是由于ramp-up测试固有的不准确性使其不能显示系统可以支持的并发用户的精确数字。以门户应用程序为例，随着门户规模的扩大和集群规模的扩大，这种不确定性就会随之显现。

这不是说不应该使用ramp-up测试。对于系统负载在一段比较长的时间内缓慢增加的情况，ramp-up测试效果还是不错的。这是因为系统能够随着时间不断调整。如果使用快速ramp-up测试，系统就会滞后，从而报告一个较相同用户负载的flat测试低的响应时间。那么，什么是确定容量的最好方法？结合两种负载类型的优点，并运行一系列的测试，就会产生最好的结果。例如，首先使用ramp-up测试确定系统可以支持的用户范围。确定了范围之后，以该范围内不同的并发用户负载进行一系列的flat测试，更精确地确定系统的容量。

渗入测试

渗入测试是一种比较简单的性能测试。渗入测试所需时间较长，它使用固定数目的并发用户测试系统的总体健壮性。这些测试将会通过内存泄漏、增加的垃圾收集（GC)或系统的其他问题，显示因长时间运行而出现的任何性能降低。测试运行的时间越久，您对系统就越了解。运行两次测试是一个好主意——一次使用较低的用户负载（要在系统容量之下，以便不会出现执行队列），一次使用较高的负载（以便出现积极的执行队列）。

测试应该运行几天的时间，以便真正了解应用程序的长期健康状况。要确保测试的应用程序尽可能接近现实世界的情况，用户场景也要逼真（虚拟用户通过应用程序导航的方式要与现实世界一致），从而测试应用程序的全部特性。确保运行了所有必需的监控工具，以便精确地监测并跟踪问题。

峰谷测试

峰谷测试兼有容量规划ramp-up类型测试和渗入测试的特征。其目标是确定从高负载（例如系统高峰时间的负载）恢复、转为几乎空闲、然后再攀升到高负载、再降低的能力。

实现这种测试的最好方法就是，进行一系列的快速ramp-up测试，继之以一段时间的平稳状态（取决于业务需求），然后急剧降低负载，此时可以令系统平息一下，然后再进行快速的ramp-up；反复重复这个过程。这样可以确定以下事项：第二次高峰是否重现第一次的峰值？其后的每次高峰是等于还是大于第一次的峰值？在测试过程中，系统是否显示了内存或GC性能降低的有关迹象？测试运行（不停地重复“峰值/空闲”周期）的时间越长，您对系统的长期健康状况就越了解。

原则

1）情况许可时，应使用几种测试工具或手段分别独立进行测试，并将结果相互印证，避免单一工具或测试手段自身缺陷影响结果的准确性；

2）对于不同的系统，性能关注点是有所区别的，应该具体问题具体分析；

3）查找瓶颈的过程应由易到难逐步排查：

服务器硬件瓶颈及网络瓶颈（局域网环境下可以不考虑网络因素）

应用服务器及中间件操作系统瓶颈（数据库、WEB服务器等参数配置）

应用业务瓶颈（ SQL语句、数据库设计、业务逻辑、算法、数据等）

4）性能调优过程中不宜对系统的各种参数进行随意的改动，应该以用户配置手册中相关参数设置为基础，逐步根据实际现场环境进行优化，一次只对某个领域进行性能调优（例如对CPU的使用情况进行分析），并且每次只改动一个设置，避免相关因素互相干扰；

5）调优过程中应仔细进行记录，保留每一步的操作内容及结果，以便比较分析；

6）性能调优是一个经验性的工作，需要多思考、分析、交流和积累；

7）了解“有限的资源，无限的需求”；

8）尽可能在开始前明确调优工作的终止标准。

工具

自动化测试工具介绍LR篇

HPLoadRunner是一种预测系统行为和性能的负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner能够对整个企业架构进行测试。通过使用LoadRunner，企业能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。

企业的网络应用环境都必须支持大量用户，网络体系架构中含各类应用环境且由不同供应商提供软件和硬件产品。难以预知的用户负载和愈来愈复杂的应用环境使公司时时担心会发生用户响应速度过慢，系统崩溃等问题。这些都不可避免地导致公司收益的损失。 LoadRunner能让企业保护自己的收入来源，无需购置额外硬件而最大限度地利用现有的IT资源，并确保终端用户在应用系统的各个环节中对其测试应用的质量，可靠性和可扩展性都有良好的评价。

轻松创建虚拟用户

使用LoadRunner的VirtualUserGenerator，您能很简便地创立起系统负载。该引擎能够生成虚拟用户，以虚拟用户的方式模拟真实用户的业务操作行为。它先记录下业务流程（如下订单或机票预定），然后将其转化为测试脚本。利用虚拟用户，您可以在Windows，UNIX或Linux机器上同时产生成千上万个用户访问。所以LoadRunner能极大的减少负载测试所需的硬件和人力资源。另外，LoadRunner的TurboLoad专利技术能。

提供很高的适应性。 TurboLoad使您可以产生每天几十万名在线用户和数以百万计的点击数的负载。

用VirtualUserGenerator建立测试脚本后，您可以对其进行参数化操作，这一操作能让您利用几套不同的实际发生数据来测试您的应用程序，从而反映出本系统的负载能力。以一个订单输入过程为例，参数化操作可将记录中的固定数据，如订单号和客户名称，由可变值来代替。在这些变量内随意输入可能的订单号和客户名，来匹配多个实际用户的操作行为。

LoadRunner通过它的DataWizard来自动实现其测试数据的参数化。 DataWizard直接连于数据库服务器，从中您可以获取所需的数据（如定单号和用户名）并直接将其输入到测试脚本。这样避免了人工处理数据的需要，DataWizard为您节省了大量的时间。

为了进一步确定您的Virtualuser能够模拟真实用户，您可利用LoadRunner控制某些行为特性。例如，只需要点击一下鼠标，您就能轻易控制交易的数量，交易频率，用户的思考时间和连接速度等。

创建真实的负载

Virtualusers建立起后，您需要设定您的负载方案，业务流程组合和虚拟用户数量。用LoadRunner的Controller，您能很快组织起多用户的测试方案。 Controller的Rendezvous功能提供一个互动的环境，在其中您既能建立起持续且循环的负载，又能管理和驱动负载测试方案。

而且，您可以利用它的日程计划服务来定义用户在什么时候访问系统以产生负载。这样，您就能将测试过程自动化。同样您还可以用Controller来限定您的负载方案，在这个方案中所有的用户同时执行一个动作---如登陆到一个库存应用程序——---来模拟峰值负载的情况。另外，您还能监测系统架构中各个组件的性能——---包括服务器，数据库，网络设备等——---来帮助客户决定系统的配置。

LoadRunner通过它的AutoLoad技术，为您提供更多的测试灵活性。使用AutoLoad，您可以根据用户人数事先设定测试目标，优化测试流程。例如，您的目标可以是确定您的应用系统承受的每秒点击数或每秒的交易量。

最大化投资回报

所有MercuryInteractive的产品和服务都是集成设计的，能完全相容地一起运作。由于它们具有相同的核心技术，来自于LoadRunner和ActiveTestTM的测试脚本，在MercuryInteractive的负载测试服务项目中，可以被重复用于性能监测。借助MercuryInteractive的监测功能－－TopazTM和ActiveWatchTM，测试脚本可重复使用从而平衡投资收益。更重要的是，您能为测试的前期部署和生产系统的监测提供一个完整的应用性能管理解决方案。

支持无线应用协议

随着无线设备数量和种类的增多，您的测试计划需要同时满足传统的基于浏览器的用户和无线互联网设备，如手机和PDA。 LoadRunner支持2项最广泛使用的协议：WAP和I-mode。此外，通过负载测试系统整体架构，LoadRunner能让您只需要通过记录一次脚本，就可完全检测上述这些无线互联网系统。

支持MediaStream应用

LoadRunner还能支持MediaStream应用。为了保证终端用户得到良好的操作体验和高质量MediaStream，您需要检测您的MediaStream应用程序。使用LoadRunner，您可以记录和重放任何流行的多媒体数据流格式来诊断系统的性能问题，查找原由，分析数据的质量。

完整的企业应用环境的支持。

LoadRunner支持广泛的协议，可以测试各种IT基础架构。

性能测试工具PerformanceRunner

PerformanceRunner（简称PR）是性能测试软件，通过模拟高并发的客户端，通过协议和报文产生并发压力给服务器，测试整个系统的负载和压力承受能力，实现压力测试、性能测试、配置测试、峰值测试等。

功能如下：

●录制测试脚本

PR通过兼听应用程序的协议和端口，录制应用程序的协议和报文，创建测试脚本。 PR采用java作为标准测试脚本，支持参数化、检查点等功能。

●关联与session

对于应用程序，特别是B/S架构程序中的session，通过“关联”来实现。用户只需要点击“关联”的按钮，PR会自动扫描测试脚本，设置关联，实现有session的测试。

●集合点

PR支持集合点，通过函数可以设置集合点。设置集合点能够保证在一个时间点上的并发压力达到预期的指标，使性能并发更真实可信。

●产生并发压力

性能脚本创建之后，通过创建项目，设置压力模型，就可以产生压力。 PR能够在单台机器上产生多达5000个并发的压力。

●应用场景支持

通过设置多项目脚本的压力曲线，可以实现应用场景测试。

●执行监控

在启动性能测试之后，系统会按照设定的场景产生压力。在执行过程中，需要观察脚本执行的情况，被测试系统的性能指标情况。 PR通过执行监控来查看这些信息。

●性能分析报表

一次性能测试执行完成，会创建各种性能分析报表，包括cpu相关、吞吐率、并发数等。

系统要求：windows(32位/64位)2000/xp/vista/2003/7/2008

问题

本文介绍了进行性能测试的几种方法。取决于业务需求、开发周期和应用程序的生命周期，对于特定的企业，某些测试会比其他的更适合。但是，对于任何情况，在决定进行某一种测试前，都应该问自己一些基本问题。这些问题的答案将会决定哪种测试方法是最好的。

这些问题包括：

结果的可重复性需要有多高？

测试需要运行和重新运行几次？

您处于开发周期的哪个阶段？

您的业务需求是什么？

您的用户需求是什么？

您希望生产中的系统在维护停机时间中可以持续多久？

在一个正常的业务日，预期的用户负载是多少？

将这些问题的答案与上述性能测试类型相对照，应该就可以制定出测试应用程序的总体性能的完美计划。

性能测试是为描述测试对象与性能相关的特征并对其进行评价，而实施和执行的一类测试，如描述和评价计时配置文件、执行流、响应时间以及操作的可靠性和限制等特征。不同类型的性能测试侧重于不同的测试目标，这些性能测试的实施贯穿于整个软件开发生命周期(SoftwareDevelopmentLifeCycle,SDLC)。起初，在构架迭代中，性能测试侧重于确定和消除与构架有关的性能瓶颈。在构建迭代中还将实施和执行其他类型的性能测试，以调整软件和环境（优化响应时间和资源），并核实应用程序和系统是否能够处理高负载和高强度的情况，如有大量事务、客户机和/或数据的情况。