CHOISIR UNE STRATÉGIE DE TEST DE MONTÉE EN CHARGE

Transcription

1 Un livre blanc Borland avril 2006 CHOISIR UNE STRATÉGIE DE TEST DE MONTÉE EN CHARGE Pourquoi et comment optimiser les performances applicatives

2 Contents Présentation générale Que sont les tests de charge? Pourquoi effectuer des tests de charge? Quand mener les tests de charge? Stratégies de conduite des tests de charge Des tests réalistes La stratégie pour réussir Tests de charge avec Borland SilkPerformer

3 Présentation générale Des logiciels de médiocre qualité exposent à des charges et risques potentiellement considérables. En effet, toutes les entreprises dépendent aujourd hui de logiciels pour gérer leurs activités de développement, de production, de distribution et/ou leurs prestations de support. Selon une étude conduite en 2002 par le NIST (National Institute of Standards and Technology), du Department of Commerce des États-Unis, les problèmes de qualité logicielle coûtent chaque année environ 60 milliards de dollars à la seule économie américaine. 1 Les tests de montée en charge sont un élément essentiel pour optimiser la qualité des logiciels. Lorsqu ils sont effectués correctement, en utilisant par exemple la gamme d outils Borland de gestion de la qualité tout au long du cycle de vie des applications, ils permettent en effet de réduire les coûts induits par d éventuels défauts. Nous aborderons successivement dans cette étude : l'importance des tests de charge ; le moment le plus opportun pour les mettre en œuvre et les apports de tests bien conçus pour maximiser les performances applicatives. Nous évaluerons également les différentes stratégies d implémentation et les véritables bénéfices que les tests de montée en charge permettent de réaliser. Nous conclurons cette étude par la présentation d une stratégie optimale pour tirer tous les bénéfices des tests de montée en charge : meilleures pratiques, planification pour des performances optimales, prise en compte que l assurance qualité est une «ingénierie de production», et enfin extension de l «assurance performance» au cœur des systèmes en production. Que sont les tests de charge? Les tests de charge consistent à systématiquement exposer une application à des conditions réelles d'exploitation et d utilisation afin de prédire le comportement du système et de localiser/diagnostiquer les erreurs de l application et/ou de son infrastructure avant son déploiement. Les tests de charge permettent d analyser trois aspects fondamentaux de la qualité de service d une application : Performances (temps de réponse) Montée en charge (débit) Fiabilité (disponibilité et intégrité fonctionnelle) Il existe plusieurs types de tests de charge répondant à différentes problématiques. Par exemple, certains d'entre eux permettent de soumettre l'intégralité de l'application à des tests de résistance extrême en simulant son nombre maximal d utilisateurs potentiels ; d autres peuvent maintenir l application dans un état stable d activité pendant plusieurs jours pour localiser de potentielles «fuites» de mémoire ; certains outils permettent de tester la résistance d un composant applicatif donné (par exemple un module de middleware comme un service Web) pour vérifier ses performances individuelles avant de tester celles de l ensemble de l application composite. Quelles que soient leurs spécificités, tous les tests de montée en charge ont pour vocation de maximiser la fiabilité des applications en identifiant où, quand et dans quelles circonstances, elles peuvent connaître des dysfonctionnements. 1 United States Department of Commerce, National Institute of Standards and Technology (NIST), «Impact économique d infrastructures inadéquates de test logiciel», mai

4 Pourquoi effectuer des tests de charge? Les tests de charge complètent les tests fonctionnels attestant qu'une application remplit bien la fonction requise. Ces derniers valident généralement le bon comportement de la fonction dans des conditions normales d'utilisation et la gestion des erreurs en cas d'utilisation incorrecte ; cependant, ils ne sont pas en mesure d'indiquer quelle charge une application peut supporter avant de connaître des dysfonctionnements voire de tomber en panne. La recherche de ces points potentiels de rupture et des goulets d étranglement, ainsi que l identification des erreurs fonctionnelles ne survenant que dans des conditions particulières de stress, exigent de mener des tests de charge. Toutes les décisions d'entreprise finissent par se résumer à des choix économiques Les tests de charge ne font pas exception à la règle. Leur justification est obtenue à travers leurs deux avantages majeurs : Réduction du nombre de pannes applicatives tant en termes de performances, que d erreurs réelles et de surcharges. Réduction des coûts des infrastructures applicatives Réduction du nombre de pannes applicatives Lorsqu ils sont correctement implémentés et réalisés tout au long du cycle de développement, les tests de charge permettent de significativement réduire le nombre de pannes rencontré par une application. Ce nombre varie naturellement en fonction de la complexité de l application, de l «habileté» des développeurs et des modalités d utilisation. Tout système permettant de limiter ces pannes ou incidents a toutes les chances de «se rembourser» très vite et plusieurs fois Ceci est tout particulièrement vrai pour les applications stratégiques, destinées essentiellement aux clients ou à générer du chiffre d affaires, et plus généralement à toutes celles qui sont tournées vers un public extérieur à l entreprise. Selon Gartner, le coût moyen d une panne imprévue sur une application critique s élève à $ Cependant, il est capital de reconnaître que le véritable coût d un incident logiciel va bien au-delà des pertes de chiffre d affaires intervenues lors de la panne. Pour complètement «récupérer», le système doit en effet être «nettoyé» - une opération dont le simple coût peut largement dépasser les pertes de revenus Pour rendre ce point plus évocateur, des calculs simples peuvent être réalisés pour illustrer les coûts induits par de médiocres performances applicatives. Au-delà des coûts directs, certaines charges sont plus «pernicieuses» comme l impact sur l image de marque, la satisfaction des clients, la perception concurrentielle, etc. Les coûts induits par une médiocre qualité logicielle sont donc multiples. Pertes immédiates de chiffre d affaires ou de productivité (CA/min.) x (min. de panne) Pour une entreprise dont une application commerciale Web génère un chiffre d affaires de / heure, la perte directe d une interruption de 30 minutes sera de S il existe des canaux alternatifs de commande (centres d appels), ce chiffre pourra être diminué de l afflux des commandes déroutées et augmenté des charges supplémentaires induites par leur traitement. Par exemple, si cette même entreprise reçoit 100 commandes supplémentaires d un montant moyen de 50 dans son centre d appels lors de la panne de l application Web, et si le traitement des commandes par ce canal coûte 5 de plus, la perte totale de chiffre d'affaires ressortira à ( ). Bien entendu, 4 2 «Qualité de développement Un facteur critique pour les technologies émergentes» - Theresa Lanowitz, Gartner Group, 23 avril 2003 (Note de recherche n K ) 3 Source : Gartner Choisir une stratégie de test de montée en charge

5 plus l entreprise dépend d Internet pour réaliser son chiffre d affaires, plus les pannes de ses systèmes Web sont dommageables. Cet exemple permet de mesurer la rapide progression dans le temps des pertes de chiffre d affaires en cas d indisponibilité de l application. A ses débuts, ebay a ainsi perdu entre 3 et 5 millions de dollars de chiffre d affaires et connu une baisse de la valorisation de ses stocks de 26 % à la suite d une panne unique de 22 heures.3 La société a dès lors très rapidement perçu le véritable impact de médiocres performances sur son compte d exploitation ; elle utilise aujourd hui un système interne extrêmement robuste de validation permettant de tester avec une grande précision tous les nouveaux logiciels avant leur déploiement. Lorsqu une application interne stratégique (par exemple un PGI) tombe en panne, la productivité de tous les collaborateurs qui en dépendent s en ressent immédiatement et les coûts induits connaissent un développement exponentiel. Au-delà de ces pertes de productivité, il faut également considérer l impact potentiellement désastreux sur l entreprise. Par exemple, si la panne intervient en fin de trimestre, à la suite d une montée en charge excessive, le traitement des commandes peut être interrompu et interdire la production du chiffre d affaires sur le trimestre concerné. Les problèmes de disponibilité des systèmes de traitement des commandes ont connu un exemple très médiatisé lors d une panne intervenue en août 2004 dans la Division s d entreprise et Solutions de stockage de Hewlett-Packard ayant conduit sa Présidente, Carly Fiorina à provisionner une perte trimestrielle d environ 400 millions de dollars de chiffre d affaires et de 275 millions de profits opérationnels. 4 Renoncement des clients Une étude de Jupiter Media Metrix portant sur plus de utilisateurs (voir figure 1 ci-dessous) démontre que 46 % d entre eux sont prêts à abandonner temporairement ou définitivement toute relation avec l un de leurs sites favoris en raison de difficultés techniques ou de problèmes de performances. Changent définitivement de site : 9 % Utilisent régulièrement un nouveau site : 24 % N utilisent pas un autre site : 53 % Utilisent un nouveau site pour une session : 13 % Pas de réponse : 1 % Source : Étude consommateur Jupiter Media Metrix Figure 1 Étude consommateur Jupiter Media Metrix : 46 % des utilisateurs sont susceptibles d abandonner temporairement ou définitivement l un de leurs sites favoris en raison de problèmes techniques ou de performance 5 4 «HP fait porter le chapeau à sa migration SAP». Marc Songini, Computerworld, 17 août «Outils et méthodologies de test», Foster et Allard, Jupiter Media Metrix, janvier

6 Comme indiqué, 13 % des utilisateurs ne quittent le site que pour une session ; 24 % établissent une relation parallèle avec un site concurrent et 9 % le «désertent» définitivement. Rétablir des relations avec le premier groupe de 13 % est relativement peu coûteux (un d excuse peut suffire ) ; en revanche, regagner la confiance des 24 % avec lesquels l exclusivité à été perdue peut exiger des méthodes plus onéreuses : remises concurrentielles, gratuité de la livraison, etc. Dans une telle situation, après une journée complète de panne, AT&T a été contraint de créditer 40 millions $ de remises à ses clients. 6 Enfin, les 9 % d anciens clients ayant définitivement déserté le site devront être remplacés à travers des politiques standards et souvent coûteuses d acquisition de prospects. Il faut également noter, qu il n est pas toujours nécessaire que le site tombe réellement en panne pour que les utilisateurs l abandonnent ; une étude a notamment démontré qu une simple dégradation de 10 % des temps de réponse fait progresser de 5 % le taux d abandon des utilisateurs. 7 Les utilisateurs internes qui n ont pas le choix de changer de service peuvent simplement refuser d'utiliser une application plutôt que de tolérer des performances dégradées. L optimisation et la qualité des performances sont donc des facteurs essentiels pour satisfaire les besoins d'ergonomie de tous les utilisateurs (internes ou externes) et pour conserver ou développer sa position concurrentielle. Coûts spécifiques des incidents Selon le type d application et de panne, les entreprises peuvent être exposées à des coûts substantiels dans des domaines connexes. Par exemple, s il s agit d investir immédiatement des milliers d euros pour assurer la réparation des systèmes et leur mise à jour. En outre, certaines entreprises sont engagées à fournir un niveau de service prédéfini à leurs clients (par exemple, dans le cadre de contrats SLA) et les manquements peuvent être sanctionnés par des pénalités financières ou des coûts juridiques De même, si l incident devient de notoriété publique, il sera sans doute nécessaire de réviser les budgets marketing ou de relations publiques pour éviter que les concurrents ne s engouffrent dans la brèche Dans un autre ordre d idée, si le problème est lié à des attaques de type déni de service ou à d autres tentatives malveillantes, la mise en œuvre des mesures de protection indispensables peut rapidement se chiffrer en centaines de milliers de dollars Réduction du coût des infrastructures applicatives Les applications dont les paramètres de performance sont imparfaits exigent naturellement une plus grande quantité de ressources système pour fonctionner correctement. En outre, si les besoins d une application ne sont pas évalués en amont, il est fréquent que l infrastructure sous-jacente soit surdimensionnée pour garantir des performances acceptables. Cette situation conduit naturellement à l inflation des coûts matériels et de maintenance qui peuvent rapidement devenir prohibitifs. Ces investissements redondants pourraient pourtant être facilement évités grâce à des tests adéquats de montée en charge, de réglage applicatif («tuning») et de planification de capacité. Ainsi, grâce à des tests avancés de montée en charge, un éditeur leader de logiciels comptables est parvenu à tripler ses performances applicatives sur les mêmes infrastructures et a ainsi réalisé des économies matérielles très substantielles. 6 6 Source : Rapport d analyse Gartner 7 «Lier les performances au profit», Peter Christy, Jupiter Media Metrix, juin 2001

7 Quand mener les tests de charge? Plus les tests de charge débutent tôt dans le processus de développement, plus ils permettent de mettre rapidement en évidence les possibles défauts du logiciel ou de son infrastructure sous-jacente. Si l on sait que le coût de correction des défauts non découverts progresse exponentiellement à chaque phase suivante du cycle de développement, 8 il n en est que plus essentiel de débuter les tests de montée en charge le plus tôt que possible. Compte tenu de la structure multi-niveau des applications modernes (présentation/logiques métier/données) et de la nécessité d une couche d intégration aux applications existantes, les différentes phases du processus de développement ont été synthétisées ci-dessous, dans la figure 2 avec les tests correspondant à chaque phase Tests de stress de niveau composant 2. Tests de charge de l infrastructure 3. Tests de charge de l architecture 4. Tests de charge de bout en bout Tests de charge de l architecture Tests de charge de l infrastructure Tests de stress de niveau composant Utilisateur interne Web GIU Prototype App Server EJB 1 Service Web 1 Base de données SQL Table 1 Table 2 Internet WAN Équilibrage de charge Servlet 1 Table n Utilisateurs externes d applications Web... Figure 2 - Phases au cours desquelles des activités de test de charge peuvent être intégrées Tests de niveau composant Les tests unitaires sont désormais une activité parfaitement acceptée dans les premières itérations du cycle de développement pour vérifier les fonctionnalités des modules logiciels distribués. Néanmoins, les composants applicatifs sur serveur (par exemple les EJB ) qui hébergent des logiques métiers ou les services Web donnant accès aux données gérées par des applications centrales peuvent être utilisés simultanément par de multiples clients. Dès lors, les tests unitaires conventionnels ne sont plus suffisants et seuls des tests de «stress» (voir figure 3) permettent de localiser simplement et économiquement les problèmes potentiels : situations d inter-blocage (deadlock), problèmes de 8 Economie de l ingénierie logicielle, Barry Boehm, Prentice-Hall, «Bonnes pratiques de déploiement d applications Web», Ernst Ambichl, Segue Software, allocution lors du «Total Performance Management Symposium», 18 mars

8 synchronisation, fuites mémoire, enjeux de performance ou architecturaux, etc. Le diagnostic de ces problèmes immédiatement avant le déploiement avec une solution classique de test «de bout en bout» est généralement trop complexe, et dans tous les cas, leur résolution est infiniment plus coûteuse que s ils avaient été détectés en amont. Tests de stress de niveau composant d applications EJB 1 Table 1 Service Web 1 Base de données SQL... d applications Figure 3 Tests de stress de niveau composant Par rapport à d autres phases de test, celle portant sur les composants est unique dans la mesure où elle est généralement réalisée avant qu'il n'existe de véritables clients permettant d'enregistrer un script de test ; ces derniers doivent donc être réutilisés (tests unitaires) ou développés manuellement. Tests de charge de l infrastructure (benchmark) Les décisions portant sur les infrastructures matérielles et logicielles des projets sont généralement prises assez tôt. Cependant, l infrastructure retenue qui peut intégrer un système d équilibrage de charge, des serveurs Web, des serveurs d applications et de bases de données et les matériels et systèmes d exploitation nécessaires à leur hébergement jouera un rôle clé dans les caractéristiques de performance, d extensibilité, de fiabilité et de coût de l application devant être déployée. Par conséquent, toutes les options d infrastructure disponibles doivent être évaluées avec beaucoup d attention - et tout particulièrement leur rapport prix/performance. Les résultats officiels aux benchmarks standards ne sont généralement pas d une grande aide pour cette évaluation dans la mesure où ils ne sont généralement disponibles que pour des composants uniques et ne peuvent pas prendre en compte l architecture de l application. Par opposition, les premiers résultats des benchmarks et tests de montée en charge avec différentes options d infrastructure (voir figure 4) fournissent des informations exploitables sur la meilleure option et permettent aussi d influencer les décisions architecturales (par exemple, J2EE ou.net). Par ailleurs, une bonne compréhension des effets des différents paramètres de configuration système permet de disposer suffisamment tôt de données utiles pour l optimisation ultérieure des performances. Enfin, la connaissance des indicateurs clés de performance fournit un benchmark significatif pour les tests ultérieurs de montée en charge de bout en bout et de monitoring applicatif. 8

9 Tests de charge de l infrastructure Équilibrage de charge Web Prototype IHM... Web s sous-jacents Figure 4 - Tests de charge de l infrastructure Tests de charge de l infrastructure (benchmark) En réalisant assez tôt les tests de charge de l architecture, il est possible de vérifier que les composants résidant dans différentes couches «collaborent» comme prévu. L utilisation d un prototype «Tous niveaux» - incluant un sous-ensemble de la fonctionnalité complète touchant tous les niveaux de l'architecture (voir figure 5) permet de réaliser les tests suffisamment tôt dans le processus de développement pour détecter rapidement les défauts potentiels de conception. Comme nous l avons précédemment évoqué, plus les erreurs sont détectées tôt dans le processus de développement moins elles sont coûteuses à solutionner. Il est également possible d'évaluer différentes alternatives de conception comme la distribution et la réplication des couches de présentation/métier/données. Test de charge de l architecture Équilibrage de charge Web Servlet 1... Web d applications EJB 1 Service Web 1... d applications Base de données SQL Table 1 Table 2 Table n Servlet Figure 5 - Tests de charge de l architecture 9

10 Tests de charge de bout en bout Les traditionnels tests de charge de bout en bout (voir figure 6 ci-dessous) permettent d analyser le fonctionnement de l ensemble de l application dans différents scénarii réalistes d utilisation et de charge ; ils peuvent ne durer que quelques heures ou se prolonger plusieurs jours. Ces tests sont généralement conduits dans un environnement temporaire de préproduction et leurs résultats permettent de répondre aux questions suivantes : Des erreurs fonctionnelles se produisent-elles dans des conditions particulières de charge? Quelle est la capacité système requise pour toutes les couches de l application? L application pourra-t-elle satisfaire les niveaux de service requis? L application est-elle optimisée pour offrir les meilleures performances? Les activités de résolution des erreurs, d optimisation et de réglage ou l introduction de nouvelles fonctionnalités ont-elles eu des effets négatifs sur les performances? L application est-elle prête pour un déploiement intégral? Base de données SQL Web Tests de charge de bout en bout Équilibrage de charge Web Figure 6 - Tests de charge de bout en bout Stratégies de conduite des tests de charge Après avoir défini la nature des tests de charge, démontré leur importance et identifié le moment où il est le plus important de les réaliser, nous allons maintenant explorer les différentes stratégies de mise en œuvre pour lesquelles les entreprises peuvent opter ; bien qu il en existe un grand nombre, très peu sont réellement viables De surcroît, cette activité essentielle est généralement gouvernée par des préoccupations d ordre économique plutôt que par l importance métier ou la criticité de l application en question Pourtant une telle approche peut avoir de fâcheuses conséquences économiques si les défauts ne sont découverts qu à la fin du processus. 10

11 Cette section évalue indépendamment chaque stratégie de test en fournissant ses avantages et inconvénients respectifs. Les principales approches utilisées pour mener à bien les tests de montée en charge sont les suivantes : Tests manuels Applications développées en interne Outils open source Frameworks de test intégrés aux EDI Outils dédiés au Web Services de test hébergés Plates-formes d entreprise de test de montée en charge Tests manuels de montée en charge Nous avons déjà couvert plusieurs raisons essentielles pour mener des tests de charge et illustré par des conséquences bien réelles les risques que courent les entreprises ne testant pas suffisamment leurs applications avant de les mettre en production. Il est cependant important de mentionner que celles qui pratiquent des tests manuels ne sont pas pour autant à l abri de problèmes majeurs dans la mesure où leur organisation est une opération généralement inefficace en matière d utilisation du temps, des budgets et des ressources. En outre, les tests manuels ne permettent pas de générer des résultats reproductibles, ne fournissent aucun niveau quantifiable de stress des applications et ne peuvent pas être coordonnés dans des conditions satisfaisantes. Il s'agit par ailleurs d'un processus non-extensible ne permettant pas d intégrer des outils de localisation de la cause source d un problème de performance. Les limitations des tests manuels sont illustrées à la figure 7. Figure 7 Les tests manuels sont souvent problématiques 11

12 Pour illustrer les limites des tests manuels, prenons l exemple d une application Web devant supporter un modeste volume de 50 transactions simultanées. Pour valider ses performances, il sera nécessaire de mobiliser 50 utilisateurs sur 50 machines afin d initialiser des scripts de transaction simultanés ; ces dernières seront ensuite réalisées à vitesse fixe et les utilisateurs devront disposer d'un moyen quelconque pour journaliser toutes les erreurs trouvées. Lorsqu un test doit être relancé, les mêmes 50 utilisateurs devront réaliser à nouveau exactement la même opération dans le même timing Même avec 5 utilisateurs, une telle procédure est lourde à gérer ; elle est évidemment exclue (ou financièrement prohibitive) s il s agit de tester des centaines de milliers d utilisateurs virtuels. En outre, lorsqu un problème est localisé, la réalisation du diagnostic de sa cause source sans fonctionnalités dédiées d assistance reste très hasardeuse et complexe. En dépit de ces limitations, de nombreuses entreprises continuent à penser qu il suffit que «tout le monde» teste l application avant de la mettre en production pour être rassuré Nous savons malheureusement qu une telle stratégie conduit immanquablement à la livraison d applications dépourvues de fiabilité Applications de test développées en interne De nombreux responsables du développement comprennent la valeur ajoutée des tests de charge, mais ne disposent pas des budgets nécessaires pour acquérir une solution dédiée à cette problématique. Il leur arrive alors d'opter pour le développement en interne d une solution spécifique ; bien que cette stratégie soit louable, elle présente néanmoins de solides inconvénients Couverture applicative La plupart des plates-formes de test développées en interne sont composées de scripts permettant de valider des fonctions très spécifiques. Par exemple, le développeur écrira un script réalisant de rapides mises à jour simultanées d une table de base de données. Lorsqu ils sont correctement développés, ces scripts «ponctuels» permettent de tester la capacité de l application à gérer une action donnée mais pas de mesurer sa capacité à traiter un ensemble composite de transactions tel qu'en générerait un véritable utilisateur. Le seul moyen pour y parvenir consiste à modéliser, enregistrer et réutiliser des scénarii simultanés, différents et représentatifs de la charge utilisateur prévisible. Sauf à consacrer de considérables investissements à la construction d une solution complète de test, l obtention de résultats exploitables est quasiment impossible. Spécificité des outils Les scripts «maison» étant développés pour tester une fonction spécifique d une application spécifique, ils ne peuvent généralement pas être modifiés simplement pour tester d autres fonctions, applications ou technologies. Le processus de correction des scripts initiaux pour répondre à un nouveau besoin peut souvent s avérer tout aussi long que d en développer un nouveau en partant de zéro Spécificités des compétences Chaque script est une unité autonome avec ses propres logiques et mécanismes de reporting des erreurs souvent conçu par un auteur unique Ils sont par conséquent assez peu exploitables et compréhensibles par les intervenants fonctionnels qui sont pourtant les mieux placés pour juger des fonctionnalités de l application. À l inverse, les applications commerciales d administration des tests de charge peuvent être prises en main par des analystes fonctionnels pour modéliser les interactions des utilisateurs. Dans le cas d une solution interne, cette tâche incombe toujours aux développeurs qui, répétons-le, ne sont pas les plus aptes à la remplir Cette spécificité des compétences peut même s exprimer entre développeurs et il n est pas rare que le code des scripts conçus par une personne reste hermétique aux autres s il n est pas suffisamment documenté un problème pouvant être aggravé si ledit auteur quitte la société en milieu de projet. 12

13 Intégration limitée Comme mentionné précédemment, il existe généralement peu de coordination entre les différents scripts de test, de sorte qu il est extrêmement difficile de produire des rapports de synthèse standardisés sur les différents tests réalisés. Même dans le cas d un seul script de test, il reste difficile de concevoir la façon dont un utilisateur fonctionnel ou un responsable de l assurance qualité souhaite disposer des données (formatage, rapport, etc.). Pour toutes ces raisons, le développement interne d outils de test de montée en charge n est généralement pas recommandé dans la mesure où, à l issue du cycle de développement, ils ont généralement coûté plus cher qu une application packagée sans pour autant donner des preuves tangibles que l application est réellement prête à être déployée Par ailleurs, l absence de possibilités de réemploi rend les outils spécifiques caducs pour tester de nouvelles applications et même pour tester de futures versions de la même application. Les responsables du développement ayant fait ce choix pour des raisons d immédiateté devraient reconsidérer cette option en mettant en exergue son véritable coût par rapport à des solutions commerciales dédiées. Comme nous l avons déjà vu, le ROI d'une solution de test de montée en charge est très réel dès qu'on le met en rapport avec les risques et les impacts économiques de performances médiocres. Outils open source La communauté open source propose plusieurs outils gratuits pour réaliser des tests de charge ; seuls certains d'entre eux intègrent également un enregistreur graphique permettant aux testeurs de mémoriser les actions des utilisateurs dans des scripts puis de les exécuter simultanément pour réaliser les tests de montée en charge. Bien que ces outils permettent de réaliser des tests élémentaires d applications Web simples, des fonctionnalités essentielles leur font encore défaut pour tester des applications critiques. Selon eweek, 10 «leur principale faiblesse réside dans le manque d options avancées de codification des scripts pour tester des applications complexes et dans une offre de reporting très limitée.» Au-delà des limitations propres aux scripts et au reporting,ces outils ont de nombreux autres inconvénients qui interdisent leur adoption pour tester des applications critiques. En particulier, l absence de support pour les technologies autres que Web/HTTP rend leur utilisation impossible dans les environnements applicatifs standards des entreprises (PGI, applications de GRC, déploiements Citrix, applications client/serveur, applications distribuées avec clients natifs Windows ou Java, solutions sans fil ou spécifiques TCP/IP, accès mainframe par terminal, etc.). Beaucoup de ces outils sont en outre incapables de mener des tests anticipés de montée en charge des composants des implémentations de middleware ou de bases de données qu il est pourtant capital de diagnostiquer très tôt pour que les coûts de résolution d éventuels problèmes ne deviennent pas prohibitifs par la suite. Par ailleurs, en raison de l'absence d'api de haut niveau, les scripts ont tendance à devenir extrêmement longs et d'autant plus difficiles à maintenir La plupart de ces outils open source sont en outre basés sur la technologie Java dont les implications sur les performances ne sont pas neutres. Cette limitation a souvent pour conséquence de multiplier les coûts des matériels/ressources requis pour maintenir plusieurs machines de test de charge. Les outils open source ne peuvent généralement pas émuler avec précision une session utilisateur dans un navigateur Web en raison d un manque de fonctionnalités dans plusieurs domaines stratégiques : émulation des différentes vitesses de modem, mise en cache, support complet des cookies, «IP spoofing», gestion des connexions par les utilisateurs 10 «Testeurs Open-Source Une alternative économique», Jim Rapoza, eweek, 11 août 2003: 13