Journal d’un testeur d’applications mobiles
Comment un responsable des tests en charge et performance répond-il aux attentes des utilisateurs d’applications mobiles ?
Comment satisfaire aux attentes en matière de rapidité des temps de réponse ?
La réponse se trouve dans le test de performance pour applications mobiles. Il ne s’agit pas simplement d’appliquer les tests de performance classiques aux applications mobiles. Ces dernières sont diverses et possèdent leurs propres problématiques en
matière de performances, et donc leurs propres exigences, différentes des
applications web classiques.
Cette chronique est un journal de bord sur trois jours. Il traite de la manière
de tester une application mobile en réseau en se concentrant sur la partie
« serveur » de l’équation, et vise à donner un aperçu aussi précis
que possible du test en charge et performance dans le monde réel, de la méthodologie,
de ce qui est réellement testé, de la manière dont les tests sont menés et des
pièges inhérents à ce type de projet. Même si le cas décrit dans cet article
est spécifique à une application, il donne un bon exemple de ce à quoi vous
pouvez vous attendre dans un projet de test mobile.
L’exemple que je vais décrire concerne le test de en charge et performance
d’une application en réseau du côté « serveur ». Autrement dit,
les tests que j’ai menés n’analysent pas les performances de l’application sur
l’appareil mobile. Même si les performances de l’application sur l’appareil
mobile – liées au CPU, à la mémoire et à d’autres caractéristiques du terminal
– sont également essentielles pour avoir une image complète de l’expérience
utilisateur final, je ne m’y intéresserai pas dans cette chronique.
L’application mobile que j’ai testée est une plateforme de gestion de
contenu d’entreprise, conçue pour les intranets. Dans le cadre du test, nous
nous basons sur 200 utilisateurs simultanés et des pics de connexion autour de
500 utilisateurs simultanés (pour simuler, par exemple, la mise en ligne d’un
nouveau document).
L’objectif du test est de monter la charge à 600 utilisateurs virtuels et
d’analyser le comportement de l’application dans un environnement de test, avant
de lancer la mise en production.
Pour ce faire, nous avons utilisé une solution de test dotée de
fonctionnalités natives d’émulation de
trafic réseau mobile et de génération de charge depuis le cloud.
La pression des délais
Souvent, les projets de déploiement d’application mobile ont tendance à avoir des cycles de développement plus courts que les applications web classiques, notamment parce que ces applications mobiles sont souvent des versions « light » de l’application d’origine, avec des fonctionnalités limitées. Dans notre cas, l’application a été développée en trois semaines, et nous ne disposions que de trois jours pour tester ses performances en situation de charge. Ce défi est loin d’être simple à relever car tester des applications mobiles est autrement plus complexe que tester des applications web classiques. Il est notamment nécessaire d’intégrer deux dimensions supplémentaires : les différentes caractéristiques et conditions du réseau, et les différents appareils mobiles utilisés.
Jour 1 : Préparer le test – Phase d’étude
Les terminaux mobiles utilisés pour se connecter à l’application
La première étape de la phase d’étude consiste à identifier les terminaux utilisés
pour se connecter à l’application, et à savoir s’ils génèrent différentes
transactions sur le serveur d’application. Si tous les appareils mobiles
utilisent le même environnement et génèrent les mêmes transactions, alors vous
avez de la chance et vous n’aurez qu’à tester sur un OS unique – plutôt que de
devoir tester sur plusieurs OS. Dans notre cas, nous avons les mêmes
transactions pour tous les terminaux. Mais j’ai travaillé sur des projets où le
développement de l’application mobile était externalisé auprès de spécialistes
d’iOS et Android. L’application iPhone étant développée pour une équipe, et
l’application Android par une autre. Dans ce cas, nous avions besoin de nous
appuyer sur deux procédures de test.
Les informations sur les appareils utilisés pour se connecter à
l’application sont fournies par l’équipe de développement. Il est donc
important que les testeurs intègrent dans leur planning projet le temps
nécessaire pour avoir le retour de l’équipe de développement.
Caractéristiques et localisations géographiques du réseau
La seconde dimension qui fait une grande différence lorsqu’il s’agit de
tester les performances d’une application mobile concerne les caractéristiques
du réseau.
Ces caractéristiques – qui sont notamment la bande passante, les temps de
latence et les pertes de paquet – ont un énorme impact sur les temps de réponse
et sur la manière dont le serveur accepte la charge. Dans mon cas de test,
j’avais besoin de simuler différentes conditions de réseau afin de comprendre
les effets des changements dans l’infrastructure réseau sur les performances de
l’application.
Afin d’obtenir des indicateurs réalistes sur les différentes conditions
réseau, j’ai utilisé l’application SpeedTest (que l’on peut trouver dans
l’appstore d’iTunes) qui permet d’identifier les principales caractéristiques
du réseau telles que le temps de latence, et effectuer cette tâche pour chacun
des différents réseaux que je devais simuler.
La localisation géographique est également un aspect important qui impacte
les performances applicatives. Dans le cas de mon application, les utilisateurs
sont censés se connecter depuis partout dans le monde. Il était donc nécessaire
de simuler des utilisateurs situés dans différentes parties du globe.
Les informations réseau utilisées pour se connecter à l’application et les
principales zones géographiques peuvent également être fournies par les équipes
de développement. Dans mon cas, je devais simuler 5 conditions réseaux
différentes (Hedge bonnes conditions, Hedge mauvaises conditions, 3G bonnes
conditions, 3G mauvaises conditions, et Wi-Fi) et 10 zones géographiques.
Jour 2 : Exécution du test
Une fois que vous avez intégré les contraintes réseau et pris en compte les
différents types de terminaux mobiles utilisés, lancer un test de charge pour
une application mobile est très similaire au test d’une application web
classique.
La principale différence entre les deux est le temps dont vous disposez.
Dans mon exemple, je devais tester un OS, cinq conditions réseau et dix zones
géographiques différentes… en trois jours ! Cela représente cinq fois plus
de cas que pour le test d’une application web classique qui n’exige pas de
prendre en compte les conditions réseau. Il est donc crucial de s’appuyer sur
un outil de test permettant de concevoir rapidement des scénarios de test et
d’intégrer les différents paramètres (temps de latence, perte de paquets et
simulations de connexion depuis différentes régions géographiques dans le
monde).
Un autre paramètre que je devais prendre en compte (qui va probablement
devenir de plus en plus commun dans les applications mobiles) est le fait que
l’application était basée sur HTTPS. Toutes les méthodes d’enregistrement HTTPS
(même lorsque basés sur les tunnels) sont interprétées comme des attaques de
type « man-in-the-middle » par l’appareil mobile, ce qui conduit à un
refus de connexion définitif dans une application native. Dès lors, il est
impossible d’enregistrer le trafic sécurisé. Afin d’effectuer correctement
l’enregistrement, je devais fournir un certificat d’origine installé sur
l’appareil afin d’autoriser la connexion avec le tunnel.
Jour 3 : Analyse des résultats
Comme pour le test à proprement parler, l’analyse des résultats d’un test
d’application mobile est très similaire à celle d’une application web
classique. Encore une fois, mes tests restaient concentrés sur la partie
« serveur ». Mes tests n’incluaient pas l’analyse des
caractéristiques de l’appareil telles que le CPU, la mémoire, les capacités de
la batterie, la taille de l’écran, ou encore le comportement contextuel comme
la localisation géographique ou les interruptions dues à un appel téléphonique
ou à la réception d’un SMS.
Bien que ces aspects soient importants pour évaluer
l’expérience utilisateur, ils n’ont pas été pris en compte lors du lancement du
test en charge et en performance (on réalise d’autres tests par ailleurs).
Conclusion
Le point le plus important à garder à l’esprit est
que les principales différences entre le test d’une application web classique
et le test d’une application mobile se rencontrent dès la phase d’étude. Il est
donc opportun de se concentrer sur cette phase et rassembler l’information
nécessaire pour intégrer les contraintes réseau et les différents types
d’appareils mobiles, de même que de se préparer à fournir des rapports sur ces
aspects. Après la phase d’étude, enregistrer les scénarios de test et analyser
les résultats de test est très proche des applications web classiques.
La clé de la réussite, dans mon cas, a été de
s’appuyer sur un outil doté des fonctionnalités nécessaires pour prendre en
compte et gérer toutes les spécificités du test mobile… et pour gérer ma
contrainte de temps, avec seulement trois jours. Je devais également m’assurer
que mon interlocuteur (dans l’équipe de Développement) serait disponible
lorsque j’en aurais besoin, et être en mesure de lancer tous les scénarios de
test dans le temps imparti.
Les utilisateurs accèdent aujourd’hui aux
applications depuis un grand nombre d’appareils mobiles et fixes, et via une
multitude de réseaux et lieux géographiques. En tant que testeur de charge,
comment valider les performances d’une application mobile et confirmer qu’elles
correspondront aux attentes de l’utilisateur mobile ? Les utilisateurs
mobiles se connectent à partir de différents terminaux qui ont souvent une
bande passante et une puissance limitées, alors qu’ils attendent des temps de
réponses quasi instantanés.
Le test de performance des applications mobiles
est aujourd’hui incontournable.
A votre tout à présent !