Tests de performance avec Digital.ai Continuous Testing

Présentation

Dans le domaine des tests logiciels, le terme « tests de performance » peut varier selon les équipes et les individus, en fonction de l'élément testé. Par exemple, les tests de charge et les tests de stress, réalisés avec des outils comme JMeter ou SoapUI, sont généralement associés aux tests de performance et servent à valider le serveur d'une application lorsque plusieurs utilisateurs interagissent simultanément avec elle.

Cependant, les tests de performance pour les applications mobiles Web et natives iOS ou Android constituent un domaine que peu d'organisations ont exploré, en partie parce que peu d'outils du marché offrent une solution de test de performance convenable pour les appareils mobiles.

Ces dernières années, les entreprises proposant des applications mobiles ont priorisé les tests d'automatisation pour appareils mobiles. Cependant, à mesure que les applications se développent, les clients exigent un fonctionnement optimal et sans interruption. Par exemple, imaginons qu'un utilisateur télécharge une application depuis l'App Store et rencontre des problèmes tels que des temps de chargement lents ou des plantages. Dans ce cas, il est probable qu'il se tourne vers une autre application répondant à ses besoins.

Alors que les scripts d'automatisation traditionnels se concentrent principalement sur l'aspect fonctionnel de l'application, ils négligent de valider d'autres éléments essentiels à ses performances. Par exemple, ils ne vérifient pas le temps de navigation et d'accès à une nouvelle page, les pics d'utilisation du processeur, de la mémoire et de la batterie, ni les requêtes réseau inutiles effectuées par les utilisateurs. Or, ces problèmes sont quotidiens pour les utilisateurs, et pourtant, les entreprises n'accordent pas suffisamment d'importance aux tests de ces aspects des applications mobiles.

Comment Digital.ai Défi d'approche ?

La véritable valeur des tests de performance sur mobile se mesure lorsqu'on peut exécuter un grand nombre de tests de performance sur différents modèles d'appareils et versions de systèmes d'exploitation.

Tester les performances d'un seul appareil peut ne pas refléter fidèlement les difficultés réelles rencontrées par les utilisateurs, mais analyser les tendances et comprendre le comportement d'une transaction unique sur différents modèles d'appareils et versions de systèmes d'exploitation permettra d'obtenir une image plus précise.

Mais comment adapter les tests de performance sur mobile pour mesurer ces données ?

Digital.ai introduit des commandes qui peuvent être implémentées dans un script Appium fonctionnel ; cela signifie que nous pouvons combiner un script d’automatisation fonctionnelle avec des tests de performance.

Si l'on examine un script Appium fonctionnel simplifié pour un scénario de test de la fonctionnalité de connexion d'une application, on constate que le test est simple. On commence par renseigner les champs nom d'utilisateur et mot de passe, puis on clique sur le bouton « Connexion » jusqu'à accéder à la page suivante :

Si nous devions intégrer des tests de performance à ce script fonctionnel Appium, cela ressemblerait à ceci :

Avant que le script ne clique sur le bouton de connexion, nous démarrons une transaction de performance, et dès que nous arrivons sur la page suivante, nous mettons fin à la transaction de performance.

Il est moins important de capturer la transaction de performance pour remplir les champs nom d'utilisateur et mot de passe, car la saisie du texte à partir d'un script d'automatisation peut ne pas refléter fidèlement le temps réel nécessaire à l'utilisateur pour saisir ses identifiants.

Nous pouvons mesurer le temps nécessaire pour naviguer de la page de connexion à la page suivante ou s'il y a eu des pics de consommation du processeur, de la mémoire ou de la batterie lorsque nous cliquons sur le bouton de connexion.

Nous pouvons également simuler différentes conditions de réseau pour observer comment l'utilisateur final perçoit l'application lorsqu'il se trouve dans différentes conditions de réseau, et le profil réseau est transmis comme premier paramètre :

pilote.executeScript(“seetest:client.startPerformanceTransaction(\”4G-average\”)”);

Examinons le type de mesures que nous recueillons et comment elles peuvent nous aider à comprendre le déroulement de la transaction de performance.

Quels types de mesures sont capturés dans le cadre d'une transaction de performance ?

Pour chaque transaction de performance, nous recueillons les indicateurs suivants :

• Durée : Durée totale de la transaction, du début à la fin
• Indice de vitesse : Score global calculé en fonction de la rapidité avec laquelle le contenu final a été peint
• CPU: Graphique présentant la consommation du processeur, ainsi que les valeurs moyennes et maximales pour la transaction.
• Mémoire: Graphique présentant la mémoire consommée, ainsi que les valeurs moyennes et maximales de la transaction.
• Batterie: Graphique présentant la consommation de batterie, ainsi que les valeurs moyennes et maximales pour la transaction.
• Réseau: Total de Ko téléchargés/chargés pendant la transaction, selon le profil réseau appliqué.
• Appels réseau : Tous les appels réseau effectués pendant la transaction

Nous observons ici une seule transaction de performance exécutée sur un iPhone 13 Pro. Nous pouvons lire la vidéo enregistrée lors de cette transaction et suivre, en parallèle, la consommation du processeur, de la mémoire et de la batterie.

Comment ce rapport m'aide-t-il à comprendre les tendances et les goulets d'étranglement potentiels ?

Le rapport que nous venons d'examiner porte sur une transaction de performance individuelle. Mais imaginez que nous ayons maintenant exécuté cette même transaction de performance à grande échelle sur de nombreux modèles d'appareils et versions de systèmes d'exploitation : nous pourrions alors exploiter nos fonctionnalités de reporting intégrées pour commencer à analyser les tendances.

Voici un exemple de rapport filtré pour afficher toutes les transactions que j'ai exécutées dans le cadre d'une version spécifique et d'une transaction particulière (par exemple, la recherche d'un article à partir du champ de recherche dans une application native et la compréhension du temps nécessaire pour charger la page suivante dans le contexte d'une application de vente au détail) :

Ce rapport m'indique que l'indice de vitesse était nettement plus élevé sur la version 13.2 d'iOS que sur les autres versions d'iOS.

De même, nous pouvons examiner les tendances des autres indicateurs, tels que le processeur, la mémoire et la batterie :

Ce niveau d'information permet aux testeurs QA et aux développeurs d'étudier des modèles d'appareils et des versions de systèmes d'exploitation spécifiques afin de déceler d'éventuels goulots d'étranglement et d'identifier les points à améliorer dans l'application mobile testée.

Il est important de noter que des différences de performances peuvent exister entre différents appareils ou réseaux. Il est courant d'observer des écarts allant jusqu'à 30 % entre les appareils, ce qui n'indique pas nécessairement un problème de performance majeur. Cependant, des problèmes de performance peuvent engendrer des différences de 10 à 100 fois les mesures de référence.

Dois-je intégrer des tests de performance dans mes scripts d'automatisation fonctionnelle existants ?

La pertinence d'intégrer des tests de performance dans des scripts fonctionnels existants ou de créer de nouveaux scripts autonomes pour les tests de performance dépendra de la flexibilité et de la complexité du framework d'automatisation actuel.

Dans l'exemple précédent, le code est très simplifié. Voyons maintenant cette même approche dans le contexte d'un framework d'automatisation existant. De nombreuses dépendances et couches supplémentaires peuvent intervenir lors de l'appel d'une méthode pour effectuer des opérations telles que « Cliquer » ou « Envoyer des touches ».

Regardons un exemple:

L'ajout de logique supplémentaire au cadre d'automatisation existant pourrait augmenter le temps global nécessaire à l'exécution du script automatisé, ce qui pourrait avoir un impact négatif sur les tests de performance et ne pas fournir de mesures pertinentes.

Si la complexité du cadre d'automatisation existant entrave les tests de performance, il est recommandé d'écrire des scripts d'automatisation distincts exclusivement dédiés à la capture des indicateurs de performance.

Cela nous permet de simplifier la logique du code dans une certaine mesure, ce qui nous permet de capturer avec précision les indicateurs appropriés pour les tests de performance.

Quels types de valeurs de référence dois-je définir pour garantir la mesurabilité des données recueillies ?

Il n'existe pas de métriques universelles ou standardisées pour mesurer les performances, car chaque organisation et ses équipes définissent l'expérience utilisateur de leur propre application. De plus, selon la complexité de l'application, les indicateurs de performance peuvent varier d'une page à l'autre ou d'une application à l'autre.

Un exemple de mesure utilisable est le TTI (temps d'interactivité), qui mesure le temps nécessaire pour qu'une application devienne utilisable après son lancement par l'utilisateur.

Des recherches ont été menées à ce sujet, et certaines règles empiriques utiles, basées sur la recherche en IHM (Interaction Homme-Machine), nous indiquent :

• Tout délai supérieur à 500 ms devient un événement « cognitif », ce qui signifie que l'utilisateur sait que du temps s'est écoulé.
• Tout délai supérieur à 3 secondes est considéré comme un temps de réflexion, laissant à l'utilisateur le temps de constater le passage du temps. Il peut alors se laisser distraire ou choisir de faire autre chose.

Mais il existe d'autres indicateurs considérés comme des indicateurs clés de performance, tels que :

• Temps de réponse le plus élevé
• Temps de réponse moyen
• Nombre maximal de requêtes

Un temps de réponse trop long de votre serveur peut nuire à l'expérience utilisateur. Google PageSpeed ​​Insights recommande un temps de réponse inférieur à 200 ms. Une plage de 300 à 500 ms est considérée comme standard, tandis qu'un temps supérieur à 500 ms est jugé insuffisant.

Il est important de noter qu'il n'existe pas de solution unique pour ces indicateurs, et que la définition de la valeur de référence peut varier d'un cas à l'autre. Il est donc essentiel de comprendre ce qui est acceptable dans le contexte de l'application testée. Cela peut impliquer une collaboration avec les développeurs de l'application afin d'obtenir des informations sur son fonctionnement interne, comme le nombre d'appels réseau effectués lors d'un parcours utilisateur particulier, les opérations importantes effectuées côté serveur lors de l'interaction avec certains composants de l'application, et d'autres facteurs connexes.

Il peut également être utile d'exécuter quelques tests de performance afin de les utiliser comme référence.

Dois-je effectuer mes tests de performance sur toutes les combinaisons d'appareils disponibles ?

Lors du choix des appareils à tester pour les tests de performance, il est important de privilégier ceux qui génèrent le plus de revenus. Pour ce faire, il est essentiel de bien comprendre la base d'utilisateurs et les types d'appareils les plus fréquemment utilisés pour l'application testée.

Il est ensuite recommandé de sélectionner les 5 à 10 appareils les plus performants pour effectuer des tests réguliers (ce nombre peut varier selon l'envergure du projet et la base d'utilisateurs). Cette approche permet d'établir une base de référence pour les appareils testés, garantissant ainsi des mesures de performance plus précises.

Résumé

Les tests de performance sont essentiels pour garantir que les logiciels, les applications et les systèmes peuvent supporter les charges et le trafic prévus. Ils permettent d'identifier et de corriger les goulots d'étranglement et les défaillances potentielles avant le déploiement, assurant ainsi une expérience utilisateur optimale.

Contrairement aux scripts d'automatisation traditionnels, les tests de performance visent à mesurer le temps qu'il faut à un utilisateur pour naviguer entre les pages, à identifier les pics de consommation du processeur, de la mémoire et de la batterie, et à repérer les appels réseau inutiles.

L'intérêt des tests de performance réside dans leur capacité à identifier les problèmes dès les premières étapes du développement, réduisant ainsi les coûts liés à leur correction ultérieure. De plus, ils permettent d'établir une base de référence pour les indicateurs de performance, qui peuvent être suivis et comparés dans le temps, offrant ainsi une vision claire de l'impact des modifications apportées au système sur les performances. Les tests de performance sont essentiels à tout cycle de développement logiciel, du développement au déploiement et au-delà.

 

Prêt à commencer les tests de performance pour mobile ? Contactez-nous dès aujourd’hui à https://digital.ai/why-digital-ai/contact/