Whitepaper
Addressing Mobile Load Testing Challenges

Introduction

Une application mobile ou un site internet mobile est désormais un élément essentiel dans la stratégie commerciale, la communication et la relation client. Auparavant, le mobile tenait un rôle marginal dans la diffusion d’applications commerciales, et les défauts et incidents étaient minimisés. Ce n’est plus le cas. Aujourd’hui, un défaut de performance d’une application mobile entraîne directement une perte de revenu, compromet l’image de marque et altère la productivité. Depuis longtemps, les équipes de développement ont intégré le besoin de soumettre leur application web à des tests de charge pour garantir un fonctionnement satisfaisant avec un volume d’utilisateurs donné. Avec l’apparition des applications mobiles et des sites mobiles, les besoins de test en charge restent identiques. Néanmoins, le test mobile apporte de nouveaux défis que votre outil de test doit savoir relever. Les applications mobiles et les applications web classiques partagent les mêmes bases technologiques. La plupart des opérations de test sont identiques. Il n’est pas nécessaire d’acquérir un autre outil de test en charge pour le mobile. En revanche, un logiciel de test performant doit vous permettre de prendre en compte les particularités du test d’applications mobiles. Tester, non seulement les applications classiques, mais aussi les applications mobiles, avec un seul et même outil vous permet de tirer profit des compétences internes acquises à la conception et au paramétrage de scripts, à l’exécution de tests et à l’analyse de résultats. Les applications mobiles et les applications web classiques partagent les mêmes bases technologiques. Malgré les similitudes entre le test classique et le test mobile, il subsiste trois différences :

  • La simulation des réseaux sans fil. Avec les protocoles 3G, un terminal mobile bénéficie d’une connexion internet plus lente et moins régulière qu’un terminal fixe. Les conséquences sur les temps de réponse du terminal et sur le serveur lui-même doivent être prises en compte au moment où vous configurez vos tests et quand vous analysez les résultats.
  • L’enregistrement sur un terminal mobile. Une application mobile est conçue pour fonctionner sur un terminal mobile, ce qui peut représenter une difficulté pour enregistrer un scénario de test, surtout dans le cas d’une application HTTPS sécurisée.
  • Les multiples terminaux mobiles. Le grand nombre de terminaux mobiles sur le marché a contraint les créateurs d’applications web à adapter leur contenu aux limitations des plateformes clientes, ce qui complique l’enregistrement et le rejeu de tests.

Ce livre blanc présente les défis du test d’applications mobiles, les solutions et les meilleures pratiques pour enregistrer un scénario de test mobile, réaliser un test réaliste, et en analyser les résultats.

Name
Mobile Load Testing Challenges
Type

Essayez NeoLoad, la plateforme de tests de performance la plus automatisée pour les entreprises testant APIs et Applications critiques en continue

 

Les principes du test d’applications mobiles

 

Vous savez sans doute qu’un test fonctionnel d’une application mobile permet de reproduire automatiquement les actions d’un utilisateur (tapoter, balayer, zoomer, saisir du texte, etc.) enregistrées sur un véritable terminal ou sur un émulateur. L’objectif d’un test en charge ne consiste pas à vérifier le bon fonctionnement de l’application pour un seul un utilisateur. Le but est d’étudier la capacité du serveur à traiter les requêtes d’un grand nombre d’utilisateurs, afin de comprendre le rapport entre les temps de réponses et le nombre d’utilisateurs de l’application. Un test en charge efficace doit simuler un gros volume d’utilisateurs qui vont sollicitent votre serveur par le biais de votre application. Tester avec de vrais terminaux mobiles ou des émulateurs est inapplicable car il faudrait mettre en place, configurer, et administrer des centaines ou des milliers de terminaux ou d’ordinateurs pour les émulateurs. La solution consiste évidemment à prendre une approche de test en charge prévue pour évoluer selon les besoins. Avec une approche basée sur le client, les actions de l’utilisateur dans le navigateur ou dans l’application native sont enregistrées et rejouées. Avec une approche de test basée sur le protocole, c’est le trafic du réseau entre l’appareil et le serveur qui est enregistré et rejoué. Pour contrôler la performance de l’application sous une forte charge, les outils de tests basés sur le protocole sont plus efficaces que les outils de tests basés seulement sur le client parce qu’ils peuvent générer des millions d’utilisateurs tout en contrôlant les erreurs et les temps de réponse de chacun d’eux. Un test en charge d’application mobile basé sur le protocole comprend essentiellement les étapes suivantes :

  1. Enregistrement du trafic réseau entre le terminal et le serveur
  2. Rejeu des requêtes réseau par un grand nombre d’utilisateurs virtuels
  3. Analyse des résultats

Le processus semble élémentaire. Pourtant, chaque étape présente des subtilités. Heureusement elles peuvent être résolues avec une approche efficace de test en charge.

Automatisez vos tests de performances d'APIs et d'Applications end-to-end grâce à NeoLoad, la plateforme de test de performance en continue.

 

Enregistrer un scénario de test mobile

 

Pour créer un scénario de test mobile, il faut d’abord définir le type d’application mobile à tester. La saisie des échanges de données entre une application mobile et le serveur dépend du mode de conception de l’application :

  • Application native. Cette application est développée avec un langage de programmation (Objective-C pour iOS, Java pour Android) et une API spécifique au terminal. De ce fait, elle est liée à une plateforme mobile et diffusée depuis un store ou market en ligne.
  • WebApp. Créée avec des technologies web (comme HTML et JavaScript), cette application est accessible avec n’importe quel navigateur mobile. Certaines WebApps avancées peuvent disposer de fonctionnalités avancées comme la géolocalisation ou le stockage local de données, ou peuvent être spécialisées pour le navigateur utilisé. Deux WebApps connues sont http://touch.linkedin.com et http://m.gmail.com.
  • Application hybride. Une WebApp intégrée dans une application native est considérée comme une application hybride. Sa partie native se compose de quelques éléments d’interface comme le menu ou les icônes de navigation, et de fonctions comme l’identification automatique. Le contenu principal est affiché dans un composant dédié à la navigation web.

Enregistrer le test d’une application native

 

Une application native requiert un terminal ou un émulateur dédié. Son enregistrement nécessite d’intercepter le trafic réseau émis par le terminal ou l’émulateur. Pour capturer ce flux, l’enregistreur doit être connecté au même réseau que le terminal. Quand la machine d’enregistrement est sur un intranet derrière un pare-feu, il lui est alors impossible d’accéder au terminal mobile connecté en 3G ou 4G. Le terminal mobile et la machine qui héberge l’enregistreur doivent être connectés au même réseau Wi-Fi. La plupart des outils de test en charge disposent d’un enregistreur qui utilise un proxy, ce qui reste la technique la plus facile pour capturer le trafic réseau d’une application. Pour suivre cette approche, vous devez régler les paramètres Wi-Fi du terminal mobile de telle manière que le trafic passe par le proxy d’enregistrement. Les systèmes d’exploitation mobiles comme iOS et Android 4 supportent cette configuration, mais les versions plus anciennes d’Android ne sont pas toujours compatibles. De plus, certaines applications se connectent directement serveur quels que soient les paramètres du proxy du système d’exploitation. Dans ces deux situations, vous avez besoin d’une alternative aux méthodes d’enregistrement basées sur le proxy avec un outil basé sur la capture du flux réseau en mode tunnel. Remarque : Pour vérifier si votre application peut être enregistrée avec un proxy, vous pouvez faire le test suivant. D’abord, vous devez modifier les paramètres de proxy de votre terminal mobile pour enregistrer toutes les interactions entre un site web et un navigateur mobile. Ensuite, vous pouvez essayer d’enregistrer le flux de l’application native. Si votre outil de test réussit à enregistrer le trafic généré par le navigateur, mais ignore le trafic généré par l’application native, vous pouvez en conclure que votre application native ne reconnaît pas les paramètres du proxy, et qu’il vous faut suivre une autre méthode.

Enregistrer le test d’une WebApp ou d’un site web mobile

 

Une WebApp utilise les mêmes technologies web qu’un navigateur de bureau récent. Aussi pouvez-vous enregistrer une application ou la version mobile d’un site internet avec un navigateur classique, ce qui représente une alternative plus simple et plus rapide que l’enregistrement depuis le terminal. La plupart du temps, une application web identifie le type de navigateur et la plateforme utilisés. Cela permet, quand l’application est consultée depuis un terminal mobile, de recevoir du contenu mobile, avec peut-être moins de texte ou d’images. Pour tester ce type d’application depuis un ordinateur, vous devez modifier les requêtes pour qu’elles ressemblent à celles d’un terminal mobile. Sinon, vous allez tester la version fixe au lieu de recevoir du serveur le contenu mobile de l’application. Il existe des modules complémentaires pour transformer l’identité du navigateur (en changeant l’entête User-Agent des requêtes). Cette fonction est aussi disponible directement dans l’enregistreur des outils de test en charge avancés. Transformer l’identité du navigateur est parfois insuffisant. Par exemple, vous ne pouvez pas changer Internet Explorer 6 en navigateur compatible HTML5. Votre navigateur doit être en mesure de parser et de gérer le contenu mobile. Il est donc recommandé d’utiliser un navigateur récent comme Internet Explorer 9, Firefox 5, Chrome 15 ou Safari 5 (ou la dernière version disponible). Quand l’application contient des fonctions WebKit particulières, vous devez utiliser un navigateur basé sur WebKit, de préférence Chrome ou Safari.

Commencez à tester avec Neoload, la plus rapide, la plus réaliste, et la plus automatisée des plateformes de test de performance en continue

 

Enregistrer le test d’une application hybride

 

Tester une application native est naturellement impossible avec un navigateur de bureau. En revanche, c’est faisable avec de nombreuses applications hybrides. Il se peut que vous puissiez saisir directement l’URL mobile, par exemple http://m.facebook.com pour l’application Facebook, et enregistrer votre scénario comme pour une application web classique.

Enregistrer le test d’une application native sécurisée

 

Vous pouvez rencontrer d’autres obstacles pour enregistrer le test d’une application native sécurisée, qui utilise le protocole HTTPS pour l’identification ou pour d’autres traitements.

Par défaut, toutes les méthodes d’enregistrement d’une application sécurisée, en mode proxy ou en mode tunnel, sont considérées comme des intrusions de service par le terminal. Tandis qu’un navigateur classique ou mobile émettra une alerte non-bloquante, une application native va refuser strictement la connexion, ce qui empêchera l’enregistrement du flux sécurisé.

La seule issue pour enregistrer un test d’une application native sécurisée consiste à fournir un certificat racine qui autorise la connexion avec le proxy ou le tunnel. Bien que cette fonctionnalité soit actuellement supportée par un très petit nombre de solutions, elle est fondamentale pour réaliser le test en charge d’une application native en HTTPS.

Remarque : Le certificat racine doit être installé sur le terminal. Cette manipulation est facile sur les terminaux iOS. Il suffit d’envoyer le certificat dans un email et d’ouvrir le fichier attaché depuis le terminal. Pour les autres plateformes, et notamment Android, la procédure est un peu plus complexe et dépend de la version du système d’exploitation et du fabricant du terminal.

Créer des scénarios pour le test sur véritable terminal mobile

 

Lors des tests fonctionnels d’une application mobile, les équipes Qualité utilisent des outils de test sur de véritables terminaux, pour valider différents modèles. Ces outils permettent de créer des scripts, portables sur plusieurs terminaux.

Les cycles de test pour les applications mobiles sont plus courts que pour une application PC traditionnelle. C’est pourquoi les Ingénieurs de Performance voudront réutiliser les scénarios de test créés pour les tests fonctionnels avec les outils de test sur de véritables terminaux.

Ce même scénario sera ensuite utilisé lors des tests basés sur l’intégration des outils de test sur terminaux mobiles et des outils de test de charge. Le testeur de performance choisira la gamme de terminaux représentative des utilisateurs de l’application.

Avec cette approche, le testeur de performance se contentera de configurer l’outil de test de charge pour exécuter les scénarios de test mobile et corréler les résultats finaux avec les indicateurs de temps de réponse mesurés sur les véritables terminaux mobiles.

 

Réaliser un test réaliste

 

 

Un scénario de test enregistré doit être configuré pour simuler des utilisateurs avec des définitions et des comportements différents et ainsi rejouer le test sur le serveur avec une charge réaliste. Cette étape est indispensable pour une application classique et une application web mobile, et les outils pour ce faire sont identiques. C’est au moment du rejeu que le test en charge d’une application mobile peut constituer un défi.

You have read 39% of the article