Les tests du système ArcGIS doivent confirmer que la conception mise en œuvre fonctionnera comme prévu et prendra en charge les processus, les utilisateurs et la charge pour lesquels elle est destinée. Les tests du système permettent d’identifier les problèmes et de les corriger avant qu’ils n’apparaissent en phase de production. Bien qu’il ne soit peut-être pas réaliste de tester tous les composants, événements ou situations possibles, il est nécessaire de définir une approche pragmatique pour tester les aspects cruciaux du système. Par exemple, la capacité du système à prendre en charge des processus spécifiques, à se remettre d’une défaillance d’un composant ou à gérer une nouvelle charge de travail.
Des tests intentionnels et structurés sont essentiels au succès de toute application et de tout processus ou système. Il existe de nombreux types de tests qui sont pertinents tout au long du cycle de développement, notamment les tests fonctionnels, les tests d’accessibilité, les tests d’acceptation, etc. Les tests sont un élément clé du processus d’architecture, car ils permettent à la fois de valider une recommandation architecturale, mais aussi de fournir des informations susceptibles de conduire à une proposition de modification architecturale. Cela peut concerner, par exemple une certaine base de données ou une version logicielle dont les performances sont nettement supérieures ou inférieures à celles d’une autre offre.
La présente section se concentrera sur les tests de performance, c’est-à-dire les méthodes et les processus qui permettent d’identifier si les critères de performance de base du système sont respectés. Les tests doivent avoir lieu parallèlement à la surveillance télémétrique et doivent permettre de tester chaque composant surveillé. Au fur et à mesure que des changements sont introduits dans le système, il est impératif d’effectuer à nouveau des tests pour identifier toute dégradation éventuelle des performances. Les tests donnent également des indications sur les goulets d’étranglement potentiels de l’architecture en fonction des changements de charge prévus.
Ce niveau idéal de tests itératifs, standardisés et reproductibles nécessite l’automatisation du processus pour réussir. Avec les modèles de déploiement SaaS, la mise en œuvre des tests automatisés et en particulier des tests de performance exige également une bonne coordination avec d’autres fournisseurs, systèmes et parties prenantes.
Une approche de test solide doit déterminer les objectifs des tests, ce que vous comptez tester ou non (le périmètre), ce qui sera mesuré (télémétrie) et les critères de réussite.
Lors des tests de performance, de nombreux facteurs ont un impact sur les performances d’un processus, comme le matériel du client final, la connectivité réseau au système back-end et la configuration du système back-end. Il est essentiel d’avoir une bonne connaissance de ces composants pour déterminer si les mesures de performance sont principalement influencées par le logiciel ArcGIS testé ou par d’autres composants (tels qu’un proxy, une base de données ou un commutateur réseau qui introduit de la latence ou des interruptions).
Divers types de tests peuvent être utilisés pour atteindre différents objectifs. Par exemple, vous pouvez :
En identifiant clairement les objectifs lors de l’élaboration d’une stratégie de test, les étapes supplémentaires se dérouleront plus efficacement.
De nombreux systèmes maintiennent un environnement « inférieur » (test ou pré-production, par exemple) destiné aux tests fonctionnels ou de charge. Pour plus d’informations sur l’utilisation concluante des environnements de test ou de pré-production, consultez la section Isolement de l’environnement sur ce site.
Un système d’entreprise comporte souvent plusieurs applications distinctes, où les processus sont exécutés, y compris les clients bureautiques, mobiles et Web. Il peut mettre en jeu à la fois des processus en lecture/écriture et de création de rapports, et prendre en charge de nombreux types d’utilisateurs différents. Tester le système sans avoir défini le périmètre au préalable donnera lieu à de nombreux scénarios de test. Il est peu probable, en outre, que les enseignements tirés de ces tests soient d’un quelconque intérêt pour la suite des opérations.
Un bon test du système simule la façon dont le système sera utilisé. Vous aurez ainsi l’assurance qu’il sera opérationnel et fonctionnera comme prévu. Par conséquent, le périmètre doit tenir compte des processus pris en charge spécifiquement par le système et conçus pour fournir les mesures nécessaires à l’évaluation des critères de réussite. Par exemple, si vous mettez à niveau un logiciel sur un système existant, le périmètre doit inclure tous les processus clés mis à contribution lors d’une charge de travail, ce qui représente le nombre maximal d’opérations par heure attendues.
Il est possible que certaines charges de travail ne se produisent pas en même temps. C’est le cas, par exemple, pour le traitement nocturne des scripts destinés à importer ou exporter des données, par rapport aux opérations diurnes normales. Dans ces cas, le système peut être testé deux fois : une première fois pour s’assurer qu’il peut gérer les charges de travail des personnes accédant au système pendant la journée et une deuxième fois pour s’assurer que le traitement de nuit est terminé dans les délais requis. Le système doit également être testé de nouveau lorsque des changements sont introduits afin de déterminer s’ils ont eu des effets négatifs.
La télémétrie est utilisée pendant les tests du système pour recueillir des informations sur les performances du système dans différents scénarios afin d’évaluer si le système répond aux exigences et d’identifier les erreurs ou anomalies éventuelles. Bien que de nombreuses personnes puissent initialement envisager de tester la charge du déploiement ArcGIS Server, il est important de capturer les données de télémétrie à l’échelle du système. Par exemple, vous pouvez collecter des données de télémétrie sur l’infrastructure du serveur qui montrent que le système était très performant, et découvrir par la suite que les utilisateurs finaux avaient du mal à terminer les processus car leurs ordinateurs de bureau manquaient de ressources, de sorte que les performances acceptables du système back-end étaient, au final, insuffisantes pour eux.
L’un des principaux objectifs doit être de modéliser le script de test et les requêtes envoyées dans le cadre des tests en tenant compte des requêtes collectées via la surveillance de la télémétrie (qu’il s’agisse de moyennes ou de valeurs aberrantes). L’autre intérêt des tests est de tester des composants individuels ainsi que des processus de bout en bout. Compte tenu de la complexité de la plupart des systèmes d’entreprise, un seul outil de test ne suffira probablement pas à exécuter toutes les fonctions de test. Il convient donc de configurer des outils de tests automatisés, tels que JMeter, pour permettre l’ajustement des routines de test avec des entrées et des sorties de test standardisées.
De bons critères de réussite vous permettront de déterminer si le système a réussi ou échoué à un test et l’origine des problèmes, le cas échéant. Ils vous aideront à définir la portée de vos tests (le périmètre), ainsi que le type et la granularité des données de télémétrie que vous capturez. Les critères peuvent inclure des mesures telles que le nombre d’opérations par heure, les utilisateurs simultanés, les performances matérielles ou la date et l’heure d’achèvement du processus.
Voici plusieurs autres ressources intéressantes se rapportant aux tests :