1) Ouverture à l’environnement Deux écoles s’affrontent ici : les solution orientées Web, qui ne testent que le site, et celles de tests “classiques” enrichies d’une…
1) Ouverture à l’environnement
Deux écoles s’affrontent ici : les solution orientées Web, qui ne testent que le site, et celles de tests “classiques” enrichies d’une couche Web. Dans un cas, la facilité d’utilisation et une interface spécifiquement conçue pour le Web. Dans l’autre cas, une plus grande variété de protocoles et d’applications gérées.
2) Une simulation simple
Pour mettre en place rapidement un protocole de test sur un site fonctionnellement simple, rien de mieux qu’une interface graphique destinée aux non-programmeurs. Enregistreur pour la navigation, détection automatique des variables et assistant pour mettre en place la simulation sont ici des pré-requis.
3) Une simulation complexe
Dès lors que la complexité de l’application à tester s’accroît, les limites de l’outil de test apparaissent. Ainsi, il doit être capable d’identifier les sessions des utilisateurs via la gestion des cookies et des identifiants de session. Certains logiciels clients permettent l’analyse des pages, d’autres le debogage.
4) La montée en charge
Réaliser la montée en charge né-cessite beaucoup de ressources machine lorsque l’on cherche à si-muler plusieurs centaines d’utilisateurs simultanés. Les choix techniques des éditeurs (multithreading ou pas, consommation mémoire de l’utilisateur virtuel) in-fluent lourdement sur la charge générée, et donc sur les machines que vous devrez mobiliser pour les tests.
5) Les outils d’analyse
Phase indispensable pour tirer profit du test, l’analyse doit s’appuyer sur des données fiables et diversifiées de façon à fournir à l’expert des moyens de déceler les éventuels problèmes et goulots d’étranglement. Il faut pouvoir croiser les graphes d’analyse et, éventuellement, exporter les données dans un tableur ou un SGBD pour davantage de souplesse.
