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.

Contexte

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 !