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

14 («threading»), etc. Ces carences fonctionnelles conduisent généralement à des résultats biaisés qui remettent en cause l utilisation de tels outils pour tester des applications Web critiques. Les outils open source sont généralement des solutions ponctuelles, dédiées aux tests de charge de sites ou applications Web, et ne proposant aucune intégration avec d'autres outils gérant les tests fonctionnels/de régression, le monitoring, les performances et l administration générale des tests applicatifs. Par ailleurs, ils ne disposent pas d un écosystème de support et de services techniques permettant de faciliter une implémentation performante en entreprise. Frameworks de test intégrés aux EDI Une nouvelle tendance de l industrie du développement logiciel consiste à concevoir des «MégaEDI» intégrant également des fonctions de test et notamment de montée en charge. Les exemples les plus révélateurs sont certainement Microsoft Visual Studio Team System/Test pour l univers.net et Eclipse/Project Hyades dans l environnement Java. L avantage de ces solutions est de promouvoir un développement orienté sur les tests, n exigeant pas de maîtriser plusieurs outils et permettant de tester l'application dans un environnement familier. Cependant, l avantage majeur des «MégaEDI» est aussi leur plus gros inconvénient puisqu ils proposent une vue entièrement tournée sur le développement, supposant que les développeurs réalisent toutes les activités c'est-à-dire non seulement le codage mais aussi les tests unitaires, de charge et de production. Les perspectives du cycle de vie de l application sont dés lors calquées sur celles du développeur et les exigences d assurance qualité ou des systèmes d information en restent exclues. Colin Doyle, Chef de produit Integrity Solution de MKS Inc., une société spécialisée dans la configuration logicielle et membre du projet Eclipse/Hyades, déclare : «Aucun responsable de l assurance qualité ou décideur senior ne peut s approcher d Eclipse ou Visual Studio qui sont avant tout des frameworks pour développeurs.» 11 En outre, ces outils ne prennent en charge que leur propre environnement (.NET ou Java) ; ne proposent que des fonctions très rudimentaires pour tester la charge des applications Web et ne supportent pas d autres environnements de développement. Si ces solutions répondent parfaitement aux petits projets où les développeurs réalisent également les tests de charge, elles se révèlent insuffisantes pour tester des applications stratégiques complexes, hétérogènes ou impliquant des applications centrales traditionnelles. Par ailleurs, aucun de ces frameworks ne couvre tous les aspects des tests fonctionnels aux tests de performance dans un environnement intégré et leurs fonctionnalités ne sont pas extensibles aux environnements de production. Outils dédiés Web Il existe sur le marché quelques outils dédiés aux tests de charge des applications Web. Bien entendu, il peut être extrêmement risqué de ne tester que la partie Web d une application, d autant plus que la plupart des applications modernes intègrent des environnements hétérogènes exigeant un autre outil de test pour une validation complète. Cette multiplicité des outils de test suppose bien sûr une augmentation des frais de formation, de maintenance et d implémentation d autant plus que les compétences acquises sur le système de test Web ne pourront pas être réutilisées dans d autres environnements. Il est donc grandement préférable d utiliser une solution globale «En route vers les Méga-EDI Les éditeurs sont pour mais les utilisateurs sont-ils prêts?», Jennifer dejong, Software Development Times, 15 septembre 2004,

15 d'administration des tests d entreprise plutôt que de gérer de multiples solutions ponctuelles en fonction des systèmes ou technologies testés. En outre, même lorsqu il ne s agit de tester que des applications Web les solutions dédiées présentent encore des désavantages par rapport à une plate-forme globale de test d entreprise : Une précision et une fiabilité limitées Les outils de test dédiés aux applications Web utilisent tous la même approche : piloter Internet Explorer pour lui faire réaliser des scripts de test en tant qu utilisateur virtuel. Ces outils sont par conséquent précis ou extensibles mais pas les deux à la fois en raison de leurs limitations techniques. Microsoft n a pas architecturé la bibliothèque d Internet Explorer pour de multiples utilisations simultanées. Ce n est donc pas la fondation idéale pour construire des tests de charge. Généralement, ces outils deviennent plus précis en pilotant l instance complète (sans IHM) d Internet Explorer, cependant, dans ce mode, («thick replay») ils sont alors incapables d exécuter même un petit nombre d utilisateurs virtuels simultanés en raison d une trop forte empreinte sur les ressources. Cette technique ne convient donc que pour les tests fonctionnels et pas pour les tests de montée en charge. Pour progresser en extensibilité, il est nécessaire de réduire la consommation de ressources par utilisateur virtuel ; le seul moyen d y parvenir est de piloter directement la bibliothèque de communication Internet/HTTP d Internet Explorer (WinInet.dll) pour éliminer les charges de traitement induites par le navigateur complet (pool de connexion, cache, gestion des cookies, etc.) Cependant la précision d une telle approche est discutable dans la mesure où elle oblige tous les utilisateurs virtuels à partager des pools communs de ressources ce qui n est pas une représentation réaliste d'un contexte de production. Une compatibilité limitée avec les navigateurs Les outils dédiés aux tests de charge Web fonctionnent exclusivement avec Internet Explorer et les autres navigateurs ne sont absolument pas pris en charge (Mozilla, Firefox, Netscape, Opera) ce qui interdit de prévoir une distribution réaliste des utilisateurs dans la modélisation du test. De faibles opportunités de réemploi L un des principaux inconvénients des outils dédiés aux tests de charge Web réside dans les limites des fonctionnalités de leurs langages de script. Focalisés sur une approche visuelle, ils ignorent les principes élémentaires de tout langage de programmation (modularisation, scripting, boucles, «if-else», etc.). La réutilisation des scripts pour d autres projets est donc très difficile quand elle n est pas simplement impossible. Absence de support des tests de niveau composant Les applications Web sont souvent développées à partir de composants distribués (EJB,.NET, middleware, bases de données) qu il est important de tester suffisamment tôt pour vérifier les fonctionnalités et les performances dans des conditions serveur réalistes afin de réduire les coûts de résolution des problèmes éventuellement détectés. Alors que les plates-formes de test d entreprise permettent de parfaitement anticiper ces tests (car elles supportent directement les interfaces client de technologies telles que Java RMI,.NET Remoting ou ODBC), les solutions dédiées aux tests Web en sont incapables. 15

16 Services hébergés de test de charge Les services hébergés de test de charge des applications Web sont généralement réalisés depuis un serveur Internet distant. Cette approche ne nécessite aucun matériel, logiciel ni expertise du côté client et peut présenter des avantages pour découvrir les premiers bénéfices de tests de montée en charge. Le seul inconvénient de cette solution est que les tests doivent préférablement être réalisés de façon régulière tout au long du cycle de développement tant pour les composants individuels que pour l application dans son entier. Par ailleurs, certains composants applicatifs ne sont pas accessibles sur les réseaux publics et leur test avec une solution hébergée est dès lors difficile voire impossible. En tout état de cause, les applications Web accessibles doivent pouvoir être testées fréquemment ; ce qui peut induire des coûts importants avec un service hébergé. En outre, le «comportement» d Internet étant largement imprévisible, les tests hébergés ne sont pas reproductibles (contrairement aux tests internes) ; ils sont donc surtout utiles pour tester un concept et valider les tests internes. Cependant, pour véritablement fournir une couverture complète, ils doivent être réalisés suffisamment tôt, fréquemment et de l'intérieur et pas uniquement en production après que l application a été déployée. Solutions d entreprise de test de charge Les plates-formes de test en entreprise sont les seules répondant à l intégralité des besoins de test de charge des applications critiques. Au-delà de la simple capture/exécution de tests de montée en charge des applications Web, ces solutions sont suffisamment extensibles pour véritablement tester des environnements applicatifs hétérogènes pour un coût raisonnable. En assurant également les tests de stress des composants, elles permettent de détecter les enjeux de performance en amont du cycle et de réduire d autant leurs coûts de résolution. Ces plates-formes intègrent des outils graphiques et ergonomiques de conception des tests qui réduisent les délais d apprentissage et sont accessibles à d autres intervenants que les professionnels du développement. Leur capacité à contrôler intégralement les flux d activité des utilisateurs virtuels et un langage de script avancé et flexible permettent de facilement réutiliser les scripts dans différents scénarii d'utilisation. Des API de haut niveau (au-dessus de TCP/IP) pour les environnements applicatifs supportés simplifient grandement la maintenance des scripts de test. Des outils performants et précis d émulation des utilisateurs et de détection des erreurs permettent de produire des résultats fiables qui prévoient précisément le comportement de l application en production. De puissants outils de reporting permettent également d'analyser rapidement les résultats des tests de charge à travers des outils de diagnostic localisant la cause source des éventuels problèmes pour en accélérer la résolution. Les éditeurs développant des plates-formes de test d'entreprise, ne proposent pas seulement un logiciel de test de montée en charge mais aussi des modules complémentaires couvrant l'intégralité du cycle de vie des applications : administration des tests, suivi des enjeux/problèmes, gestion des performances applicatives, etc. Ainsi la problématique qualité est traitée dans une approche globale de l initialisation à la mise en production. En outre, ces éditeurs proposent généralement des prestations de support, de formation et de consulting pour garantir une implémentation optimisée et réussie. Il existe bien sur de notables différences entre ces différentes offres mais elles sont dans tous les cas bien plus performantes que les différentes alternatives que nous avons précédemment évoquées. 16

17 Des tests réalistes L une des objections récurrentes à l adoption de solutions de test de charge réside dans leur prix. Elles ont pourtant de très sérieux arguments à faire valoir pour démontrer leur retour sur investissement - parfois même sur un seul cycle de développement - encore faut-il le prévoir Importance des tests pour une entreprise Les tests sont encore trop souvent une préoccupation secondaire contrainte par des délais et des budgets généralement inadaptés. Les services d assurance qualité ne sont souvent intégrés qu à la fin du processus de développement, bien que de nombreuses études aient démontré que ce n est résolument pas une bonne méthode pour produire et déployer des logiciels de qualité et souvent la plus coûteuse. Les responsables de projets ont des objectifs de réussite mais sont souvent contraints de réduire les activités de test à leur plus simple expression, dans la mesure où les budgets leur font défaut, ainsi que la capacité à démontrer par des informations quantitatives le retour sur investissement d'une plate-forme performante de test d'entreprise. Sans ces métriques et ces critères quantitatifs, l intervention de l assurance qualité en phase de planification produit ou l engagement de budgets de dizaines de milliers d euros dans des outils de test peut se révéler une dépense de temps et de ressources en pure perte. Parallèlement, retarder le lancement d un produit sous le prétexte qu un testeur «sent» que quelque chose pourrait mal se passer génère aussi des coûts d opportunité et de consommation des ressources. Le moyen le plus transparent de prouver la rentabilité d'une suite d'outils de test est de démontrer régulièrement aux directions fonctionnelles par des rapports chiffrés et documentés - que la meilleure qualité des produits est créatrice de valeur. Ces informations permettent en effet de mettre en lumière les éventuels défauts de l application et de produire des rapports d état contenant des métriques de qualité exploitables pour optimiser les décisions d allocation des ressources, de révision des spécifications ou de date de lancement. Qui de la poule ou de l œuf? Il est simple de justifier la rentabilité d une solution de test après son implémentation mais comment les responsables de l assurance qualité peuvent-ils obtenir le budget initial pour l acquérir? Voici quelques suggestions pour les aider à faire valoir la pertinence d un tel investissement : Localiser le/les bons budgets Il est rare que le budget d un seul projet puisse supporter des dépenses additionnelles. Par exemple, un système de génération de coupons pour le département marketing n intègre généralement pas le budget d achat d un nouveau serveur d applications même s il serait bien utile à la cause L investissement dans une solution de test fournit une couverture beaucoup plus large dans la mesure où il bénéficie à la vaste majorité des projets de développement logiciel. Il est donc légitime d en répartir la charge sur de multiples initiatives ; il ne fait alors pas de doute que les responsables des projets métier seront désireux de financer une partie de l acquisition pour bénéficier des multiples avantages qu'elle procure. 17

18 Démarrer modestement et croître Des tests incomplets peuvent parfois être plus dommageables que pas de test du tout Même si leurs budgets interdisent l acquisition d une véritable plate-forme de test, les entreprises ne devraient pas céder à la tentation d acquérir des solutions bas de gamme ne produisant aucune valeur ajoutée. Au contraire, en débutant par une solution susceptible d être mise à jour pour tester les performances, les entreprises peuvent mieux intégrer leurs processus de test et de développement et les rendre plus performants tout en restant suffisamment flexibles pour migrer vers de nouvelles fonctionnalités ultérieurement. La plupart des éditeurs de solutions de test de montée en charge tarifent leur offre au nombre d utilisateurs virtuels ; l utilisation d un faible nombre d utilisateurs virtuels en amont du processus de développement permet souvent de justifier le coût d une plate-forme de test automatisé. En outre, les budgets pourront être complétés par la suite pour étendre la couverture fonctionnelle dès que l entreprise aura pris conscience des avantages réels des tests de performance. Certains éditeurs proposent également des solutions de test de charge d entrée de gamme mais il est important de valider qu ils soient évolutifs et ne cantonnent pas l utilisateur dans un environnement restreint. Débuter par une offre d entrée de gamme ne présente d intérêt que si toutes les compétences acquises et les scripts réalisés peuvent être réutilisés dans une plate-forme globale d entreprise en cas de mise à jour ultérieure. Journaliser les coûts Quelle que soit la situation, il est toujours préférable de documenter l intégralité des coûts encourus à l occasion des tests. Au fil du temps les opérations manuelles, la conception de scripts «maison», les défauts non détectés mis en production et d autres facteurs de coût viennent s accumuler et il ne fait pas de doute qu à l issue d une itération complète, la pertinence économique d une plate-forme de test de charge d entreprise sera démontrée. La stratégie pour réussir Les tests de montée en charge et de performance sont indispensables pour optimiser la qualité des applications logicielles. Les entreprises ne peuvent plus aujourd hui prendre les considérables risques financiers auxquels les exposent une panne des applications critiques ni les coûts redondants de maintenance d infrastructures dont la seule justification est de combler les déficiences applicatives tout particulièrement s il s agit d applications «visibles du marché» ou utilisées pour générer du chiffre d affaires. En outre, les erreurs rencontrées par des intervenants externes laissent l entreprise d autant plus vulnérable à la concurrence. Pour pleinement bénéficier des avantages des tests de charge, la qualité doit être considérée selon une perspective globale couvrant l intégralité du cycle de vie de l application, y compris après sa mise en production. Comme nous l avons amplement démontré, plus les tests de charge débutent tôt dans le cycle de vie de l application plus leur retour sur investissement est important Livre blanc «Révolutionner l assurance qualité pour les e-entreprises», Bernd Greifeneder, Segue Software, 16 août 2002

19 Planifier des performances optimales Il faut encore noter que l objectif des tests de charge ne doit pas forcément être de construire l'application la plus rapide possible mais d'optimiser son rapport prix/performance. Pour maximiser les performances d une application, il est avant tout nécessaire de connaître le niveau de qualité de service dont se satisfont les utilisateurs. La réalisation d études d ergonomie et de comportement en phase bêta, intermédiaire et de production permet d'identifier les facteurs clés de performance. Chaque application, module ou page doit être évalué et «réglé» individuellement pour générer un rapport coût/valeur optimal. La figure 8 ci-dessous illustre les dépenses redondantes de temps et de ressources encourues lorsque le «tuning» d une application va au-delà du point où les utilisateurs sont satisfaits en période de pointe. 12 Satisfaction Performance 100% Coût/valeur optimum Dépenses perdues 0% Coûts Figure 8 Optimisation des performances La figure 9 ci-dessous illustre comment la règle des «8 secondes par page» ne permet pas systématiquement de réussir Il est en effet nécessaire d analyser et d optimiser les modules applicatifs un par un et page à page. Les pages les plus fréquemment utilisées avec un minimum d interactions utilisateur (par exemple, cliquer sur un lien hypertexte) exigent de meilleurs temps de réponse que des pages plus occasionnelles exigeant des entrées complexes. Page Web Durée A/R 16s 8s 0s Performance optimale page Web Pages Web Figure 9 Ratio optimal performance/coût de «tuning» par module 19

20 Voir l assurance qualité comme une «ingénierie de production» Dans aucune industrie manufacturière les produits ne sont mis en production dès leur sortie des studios de design, sans qu au préalable n interviennent des services d ingénierie de production. Dans l industrie du logiciel, il n est pas rare que les tests applicatifs soient extrêmement réduits l équivalent de l ingénierie de production avant le déploiement en environnement de production. Des tests insuffisants et une communication déficiente entre les équipes de développement et de production peuvent générer de véritables problèmes de performance postérieurs au déploiement. Dans l ensemble de ce document, nous nous sommes référés aux équipes d assurance qualité comme les «garantes» de la qualité des logiciels. Cependant, une récente étude des meilleures pratiques réalisée par Jean-Pierre Garbani (Forrester Research) propose de les positionner comme des acteurs de l ingénierie de production. Ce concept a le mérite de faire entrer l assurance qualité dans l «ingénierie qualité» - même si le terme n est pas employé et de laisser augurer de progrès de qualité et de ROI pour les entreprises. Nous allons revenir plus en détail sur cette notion.. La plupart des équipes d assurance qualité sont très proches du développement mais manquent de «connexions» similaires avec la production. Si les relations avec le développement sont essentielles pour couvrir les aspects fonctionnels ; il est tout aussi important de disposer de canaux équivalents avec les équipes de production pour vérifier la compatibilité de la nouvelle application avec l'environnement ou pour s assurer que les exigences de qualité et de performance sont remplies. Cette double préoccupation indique bien que l'assurance qualité doit être transformée en un groupe d'ingénierie de production - également concerné par l'«assurance performance» (voir figure 10). L autorité du département d assurance qualité doit lui permettre de rejeter les applications ne répondant pas aux standards de production pour des raisons de conception, d architecture, de configuration ou de performance. Le rôle de ce département doit aller au-delà des tests : il est le pont essentiel entre le développement et la production. 13 Figure 10 L assurance qualité devient de l «ingénierie de production» «Gestion des performances et du cycle de vie des applications», Jean-Pierre Garbani, Forrester Research, 11 février «Gestion des performances et du cycle de vie des applications», Jean-Pierre Garbani, Forrester Research, 11 février 2005

21 Assurance performance en production grâce à l administration des performances applicatives et aux tests en boucle fermée Les systèmes d administration des performances applicatives (ou APM pour Application Performance Management) sont la contrepartie des tests de montée en charge, une fois l application déployée en production. Ces solutions mesurent les performances, la disponibilité et la précision dans un environnement réel sous charge, et intègrent des outils de diagnostic pour identifier pro-activement les problèmes et les résoudre dès qu ils se posent. Les tests de charge de pré-production ayant de nombreux points communs avec les tests de performance, les ressources développées dans les premières phases devraient pouvoir être réutilisées par la suite en phase de production. De la même façon, les données de production (erreurs, informations, etc.) devraient pouvoir être retournées en pré-production pour réaliser des tests de charge reflétant les conditions réelles d utilisation. Ce processus, dit en «boucle fermée», est présenté à la figure 11. Figure 11 Tests en boucle fermée Les tests en boucle fermée permettent non seulement de réutiliser les ressources de pré-production pour valider les performances, mais aussi de faire circuler les compétences entre les équipes de R&D, d assurance qualité et de production. Lorsque les «boucles rétroactives» fournissent à l assurance qualité les résultats de production, les résultats des tests peuvent être validés par des données d utilisation réelles. En outre, les métriques de base, issues des tests de charge en pré-déploiement, peuvent à leur tour être utilisées comme valeurs seuil pour repérer pro-activement des problèmes de performance après le déploiement de l application. Par ailleurs, l approche en boucle fermée améliore l efficacité des tests de charge : les métriques de performance de production peuvent devenir les standards des prochains cycles de livraison de versions ; les valeurs capturées auprès de véritables utilisateurs peuvent être utilisées comme données de test extrêmement réaliste s approchant de plus en plus avec le temps du comportement réel des utilisateurs. Cette organisation permet une couverture plus étendue, des tests de scénarii plus réalistes et des mesures de performance plus précises. Les sessions enregistrées d utilisateurs ayant connu de véritables problèmes peuvent être directement «réinjectées» en pré-déploiement et réutilisées dans des scripts de test pour réduire les délais nécessaires pour recréer l incident et le résoudre. 21

22 Tests de charge avec Borland SilkPerformer Borland SilkPerformer est une plate-forme d entreprise de test de charge fournissant toutes les fonctionnalités nécessaires aux entreprises pour tester leurs applications stratégiques. Puissant et simple à utiliser, SilkPerformer est une solution d automatisation des tests de performance et de montée en charge pour maximiser la vitesse, l extensibilté et la fiabilité des applications d entreprise. Avec SilkPerformer, les entreprises peuvent localiser simplement les points de rupture potentiels de l application ou de ses infrastructures sous-jacentes et y remédier avant le déploiement. SilkPerformer peut simuler des centaines ou des milliers d utilisateurs simultanés travaillant dans de multiples environnements applicatifs (Web, client/serveur, PGI/GRC, etc.). Grâce à une approche visuelle de la conception des scripts et de l analyse des causes sources, les fonctionnalités de SilkPerformer restent toujours simples et ergonomiques. Borland SilkPerformer Lite est une solution d entrée de gamme, dédiée aux tests de charge Web et entièrement architecturée autour de la technologie SilkPerformer. C est une solution économique pour débuter une implémentation professionnelle de test de montée en charge. Il en est de même pour SilkPerformer Component Test Edition, qui assure les tests anticipés des composants distants sous des accès simultanés. Lorsque les besoins de test deviennent plus importants, ces solutions peuvent ensuite migrer simplement vers la plate-forme d entreprise SilkPerformer pour capitaliser sur les compétences acquises et les ressources déjà développées. Borland SilkPerformer propose une connexion transparente avec la plate-forme d optimisation de la qualité Borland SilkCentral. Cette dernière permet de structurer, contrôler et améliorer la visibilité des enjeux de qualité des logiciels. SilkCentral intègre des solutions d'administration des tests, de suivi des erreurs et de gestion des performances applicatives et permet aux entreprises de définir, mesurer, gérer et faire évoluer leurs niveaux de qualité tout au long du cycle de vie des applications. Borland SilkCentral couvre l intégralité du cycle de vie des applications et des problématiques de qualité : intégration des moteurs de monitoring et de test, modules d administration, interfaces ouvertes, fonctions de reporting, etc. Cette solution favorise également la productivité dans la mesure où ses utilisateurs peuvent bénéficier de tous les «actifs qualité» (plans de test, scripts, monitoring d'infrastructure, métriques, résultats, etc.) tout au long du cycle de développement, de déploiement et d'optimisation des performances de production (dans le cadre d une boucle fermée et rétroactive). Enfin, SilkCentral propose un framework collaboratif, des accès Web et un référentiel d informations partagées pour accélérer les cycles de développement/déploiement et respecter des délais toujours plus brefs de mise sur le marché. Une gestion intégrale de la qualité Tout au long du cycle de vie des applications ; à travers différentes couches technologiques et environnements ; en liaison avec de multiples solutions et applications tierces et dans toutes les implantations des entreprises globales. SilkCentral de Borland Un nouveau standard de gestion de la qualité tout au long du cycle de vie des applications. 22

23 Notes 23

24 Copyright 2006 Borland Software Corporation. Tous droits réservés. Tous les noms de produits et marques Borland sont des marques, marques de service ou marques déposées de Borland Software Corporation aux États-Unis et dans d autres pays