Je suis sur le point de commencer à tester une application web intranet. Plus précisément, je dois déterminer les performances de l'application.
Quelqu'un pourrait-il me suggérer des normes formelles ou informelles me permettant de juger des performances de l'application ?
Utilisez un outil pour les tests de stress et de charge. Si vous utilisez Java, jetez un coup d'oeil à JMeter . Il fournit différentes méthodes pour tester les performances de votre application. Vous devez vous concentrer sur :
Commencez par cela, si vous êtes intéressé, il existe d'autres types de tests.
"Spécifiquement, je dois déterminer la performance de l'application...."
Cela nous ramène à la question des exigences, c'est-à-dire les attentes exprimées par votre communauté d'utilisateurs quant à ce qui est considéré comme raisonnable et efficace. Les exigences ont un certain nombre de composantes
Vous remarquerez que les temps de réponse et les autres mesures ne sont pas absolus. Si l'on s'inspire des principes de fabrication Six Sigma, le coût du passage d'une exception sur un million à une exception sur un milliard est extraordinaire et le coût du passage à zéro exception est généralement insupportable pour l'organisation moyenne. Ce qui est considéré comme un temps de réponse acceptable pour une application unique pour votre organisation sera probablement entièrement différent d'une offre hautement banalisée qui est une application publique tournée vers l'Internet. Pour les solutions hautement concurrentielles, les attentes en matière de temps de réponse sur l'internet tendent à se situer dans la fourchette des 2 à 3 secondes, où l'abandon de l'utilisateur s'accélère sérieusement. Au cours de la dernière décennie, le temps de réponse est passé de 8 secondes à 4 secondes, puis à 2 ou 3 secondes. Certaines applications, comme Facebook, visent des temps de réponse presque imperceptibles, inférieurs à une seconde, pour des raisons de concurrence. Si vous cherchez une norme stricte, elle n'existe tout simplement pas.
Pour vous aider à comprendre, lisez quelques références industrielles en matière de style, de forme et de fonction.
La mise en place d'un ensemble solide de tests de performance représentatifs de vos besoins n'est pas une mince affaire. Vous pouvez faire appel à un spécialiste pour gérer cette phase de vos efforts d'assurance qualité.
Lors du choix de votre outil, assurez-vous d'en obtenir un qui puisse
Si vous vous trompez sur l'un des quatre éléments ci-dessus, vous pouvez aussi bien acheter l'outil le plus cher du marché et engager la société la plus chère pour le déployer.
Bonne chance !
Pour tester le front-end, YSlow est un excellent outil pour obtenir des statistiques sur le temps de chargement de vos pages du point de vue de l'utilisateur. Il fournit des statistiques pour chaque requête HTTP spécifique, le temps qu'elle prend, etc. Vous pouvez l'obtenir à l'adresse suivante http://developer.yahoo.com/yslow/
Firebug, bien sûr, est également indispensable. Vous pouvez profiler votre JS explicitement ou en temps réel en appuyant sur le bouton profil. Vous pouvez effectuer des optimisations si nécessaire et voir le temps d'exécution de toutes vos fonctions. Cela a changé ma façon de mesurer les performances de mon code JS. http://getfirebug.com/js.html
Le principal critère est le temps de réponse, mais les autres indicateurs que j'examinerais sont l'utilisation du processeur et de la mémoire par rapport au nombre d'utilisateurs/processus simultanés. Je vérifierais également que tout fonctionne comme prévu dans des conditions de charge normale puis de pointe. Vous pouvez rencontrer des scénarios où une charge plus élevée provoque des erreurs d'application en raison de l'empiètement de diverses demandes les unes sur les autres.
Si vous voulez vraiment obtenir des informations détaillées, vous devrez exécuter différents types de tests de charge/stress. Vous voudrez probablement envisager un test de charge par étapes (une augmentation progressive du nombre d'utilisateurs sur le système au fil du temps) et un test de pointe (un nombre important d'utilisateurs accédant tous en même temps alors que presque personne n'y accédait auparavant). J'effectuerais également des tests sur le serveur juste après son redémarrage pour voir comment cela affecte le système.
Vous voudrez probablement aussi vous pencher sur un concept appelé HEAT (Hostile Environment Application Testing). Il s'agit en fait de montrer ce qui se passe lorsqu'une partie du système est mise hors ligne. Le système se dégrade-t-il avec succès ? Cela devrait être une norme clé.
Ma seule suggestion vraiment importante est de déterminer ce que le système est censé faire avant de procéder aux tests. La raison principale est la responsabilité. Faites en sorte que les gens admettent que le système est censé faire quelque chose, puis testez pour voir si cela est vrai. C'est essentiel, car les gens verront immédiatement les résultats et cela constituera le point de référence de base de ce qui est acceptable.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
