Tests de performance avec Digital.ai Continuous Testing

Contexte

Dans le monde des tests de logiciels, les tests de performance peuvent signifier différentes choses pour différentes équipes et individus, en fonction de ce qu'ils testent. Par exemple, les tests de charge et les tests de stress utilisant des outils tels que JMeter ou SoapUI sont plus souvent associés aux tests de performances pour valider le serveur principal d'une application lorsque plusieurs utilisateurs interagissent simultanément avec l'application.

Cependant, les tests de performances pour le Web mobile iOS ou Android et les applications natives sont un domaine que peu d'organisations ont exploré, en partie parce que peu d'outils du marché fournissent une solution de test de performances décente pour les appareils mobiles.

Les organisations disposant d'applications orientées client ont donné la priorité aux tests d'automatisation pour mobile au cours des dernières années. Cependant, à mesure que les applications se développent, la demande des clients pour des applications qui fonctionnent de manière optimale sans interruption augmente également. Par exemple, supposons qu'un utilisateur télécharge une application depuis l'AppStore et rencontre des problèmes tels qu'un chargement lent ou des plantages. Dans ce cas, ils passeront probablement à une autre application qui répond à leurs besoins.

Alors que les scripts d'automatisation traditionnels se concentrent fortement sur l'aspect fonctionnel de l'application, ils ne parviennent pas à valider d'autres éléments critiques des performances de l'application. Par exemple, ils ne valident pas le temps nécessaire pour naviguer et atterrir sur une nouvelle page, les pics d'utilisation du processeur, de la mémoire et de la batterie, ou les appels réseau inutiles effectués pendant les flux d'utilisateurs. Ce sont des défis quotidiens auxquels les utilisateurs sont confrontés, mais les organisations ne mettent pas l'accent sur les tests de ces domaines d'applications mobiles.

Comment la Digital.ai Défi d'approche ?

La véritable valeur des tests de performances sur mobile est mesurable lorsque vous pouvez exécuter un grand nombre de tests de performances sur différents modèles d'appareils et versions de système d'exploitation.

Tester les performances d'un seul appareil peut ne pas refléter avec précision ce à quoi les utilisateurs sont réellement confrontés, mais l'utilisation des tendances et la compréhension du comportement d'une seule transaction sur une gamme de modèles d'appareils et de versions de système d'exploitation brosseront un meilleur tableau.

Mais comment mettre à l'échelle les tests de performances sur mobile pour mesurer ces données ?

Digital.ai présente des commandes pouvant ê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 nous examinons un script Appium fonctionnel simplifié pour un scénario dans lequel nous testons la fonctionnalité de connexion d'une application, nous pouvons voir que le test est simple. Tout d'abord, nous remplissons le champ du nom d'utilisateur et du mot de passe, en cliquant sur le bouton Connexion jusqu'à ce que nous arrivions enfin à la page suivante :

Si nous devions implémenter les tests de performance dans ce script Appium fonctionnel, cela ressemblerait à ceci :

Avant que le script ne clique sur le bouton de connexion, nous commençons une transaction de performance, et dès que nous avons atterri sur la page suivante, nous terminons la transaction de performance.

La capture de la transaction de performance pour remplir le champ du nom d'utilisateur et du mot de passe est moins importante car la saisie du texte à partir d'un script d'automatisation peut ne pas représenter avec précision le temps qu'il faut réellement à l'utilisateur pour saisir ses informations d'identification.

Nous pouvons mesurer le temps qu'il a fallu 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 une condition de réseau différente pour voir comment l'utilisateur final expérimente l'application lorsqu'il se trouve dans différentes conditions de réseau, et le profil réseau est transmis comme premier paramètre :

driver.executeScript("seetest:client.startPerformanceTransaction(\"moyenne 4G\")");

Examinons le type de mesures que nous capturons et comment elles peuvent nous aider à comprendre comment s'est déroulée 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 capturons les métriques suivantes :

• Durée : Durée de l'ensemble de la transaction, du début à la fin
• Indice de vitesse : Score global calculé de la rapidité avec laquelle le contenu final a été peint
• CPU: Graphique avec le CPU consommé, les valeurs moyennes et maximales pour la transaction
• Mémoire: Graphique avec la mémoire consommée, les valeurs moyennes et maximales pour la transaction
• Batterie: Graphique avec la batterie consommée, les valeurs moyennes et maximales pour la transaction
• Réseau: Total des Ko téléchargés/téléchargés pendant la transaction en fonction du profil réseau appliqué
• Appels réseau : Tous les appels réseau passés lors de la transaction

Ce que nous examinons est une seule transaction de performance exécutée sur un iPhone 13 Pro. Nous pouvons lire la vidéo qui a été capturée dans le cadre de la transaction de performance et, en ce qui concerne la vidéo, nous pouvons suivre la consommation du processeur, de la mémoire et de la batterie.

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

Le rapport que nous venons d'examiner se concentre sur une transaction de performance individuelle. Mais imaginez si nous avons maintenant exécuté la même transaction de performance à grande échelle sur de nombreux modèles d'appareils et versions de système d'exploitation, nous pouvons tirer parti de nos capacités de création de rapports intégrées pour commencer à examiner les tendances.

Voici un exemple de rapport qui est filtré pour afficher toutes les transactions que j'ai exécutées sous une version spécifique et une transaction particulière (par exemple, rechercher un élément à partir du champ de recherche dans une application native et comprendre combien de temps il a fallu pour charger le prochain page dans le cadre d'une application commerciale) :

Ce rapport m'indique que l'indice de vitesse était significativement plus élevé sur iOS version 13.2 par rapport aux autres versions iOS.

De même, nous pouvons également examiner les tendances pour les autres mesures, telles que le processeur, la mémoire et la batterie :

Ce niveau d'informations permet aux testeurs d'assurance qualité et aux développeurs d'étudier des modèles d'appareils et des versions de système d'exploitation spécifiques pour détecter les goulots d'étranglement potentiels et d'identifier les domaines à améliorer dans l'application mobile testée.

Il est important de noter qu'il peut y avoir des différences de performances entre différents appareils ou réseaux. Il est courant de voir jusqu'à 30 % d'écart entre les appareils, ce qui n'indique pas nécessairement un grave problème de performances. Cependant, des problèmes de performances peuvent entraîner des différences de 10 à 100 fois les mesures de référence.

Dois-je implémenter des tests de performances dans des scripts d'automatisation fonctionnelle existants ?

La pertinence d'implémenter les tests de performance dans les 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 cadre d'automatisation actuel.

Dans l'exemple que j'ai donné plus tôt, le code est trop simplifié. Néanmoins, réfléchissons à la même approche dans le contexte d'un cadre d'automatisation existant. De nombreuses autres dépendances et couches peuvent être impliquées lors de l'appel d'une méthode pour effectuer des opérations telles que Click ou Send Keys.

Regardons un exemple:

L'ajout de plus de logique 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 performances et ne pas fournir de mesures utiles.

Si la complexité du cadre d'automatisation existant entrave les tests de performances, il est recommandé d'écrire des scripts d'automatisation distincts exclusivement pour capturer les mesures de performances.

Cela nous permet de simplifier la logique du code dans une certaine mesure, nous permettant de capturer avec précision les mesures appropriées pour les tests de performance.

Quel type de nombres de référence dois-je définir pour m'assurer que les données capturées sont mesurables ?

Il n'y a pas de métrique universelle ou standardisée à appliquer pour mesurer les performances, car chaque organisation et ses équipes définissent l'expérience utilisateur pour leur propre application. De plus, selon la complexité de l'application, les numéros de référence peuvent varier d'une page à l'autre ou d'une application à l'autre.

Un exemple de métrique pouvant être utilisée est le TTI (time-to-interactivity), qui mesure le temps qu'il faut pour qu'une application devienne utilisable après que l'utilisateur l'a lancée.

Des recherches ont été effectuées à ce sujet, et certaines règles empiriques utiles basées sur la recherche HCI (Human-Computer Interaction) nous disent :

• Tout retard supérieur à 500 ms devient un événement « cognitif », ce qui signifie que l'utilisateur sait que le temps s'est écoulé.
• Tout retard supérieur à 3 s devient un événement "réfléchissant", ce qui signifie que l'utilisateur a le temps de réfléchir au fait que le temps s'est écoulé. Ils peuvent être distraits ou choisir de faire autre chose.

Mais il existe également d'autres mesures qui sont considérées comme des mesures de performance clés, telles que :

• Temps de réponse le plus élevé
• Temps de réponse moyen
• Nombre maximal de demandes

Si le temps de réponse de votre serveur est lent, cela peut nuire à l'expérience utilisateur. Google PageSpeed ​​Insights recommande un temps de réponse du serveur inférieur à 200 ms. Une plage de 300 à 500 ms est considérée comme standard, tandis que tout ce qui dépasse 500 ms est inférieur à une norme acceptable.

Il est important de noter qu'il n'y a pas de réponse unique pour ces mesures, et la détermination de la ligne de base peut varier d'un cas à l'autre. Par conséquent, il est crucial de comprendre ce qui est acceptable dans le contexte de l'application testée. Cela peut impliquer une collaboration avec les développeurs d'applications pour mieux comprendre le backend de l'application, comme le nombre d'appels réseau effectués au cours d'un flux d'utilisateurs particulier, les opérations lourdes qui se produisent dans le backend lors de l'interaction avec certains composants de l'application et d'autres facteurs connexes.

Il peut également être utile d'exécuter une poignée de tests de performance à utiliser ensuite comme référence.

Dois-je exécuter mes tests de performances sur toutes les combinaisons d'appareils disponibles ?

Lors du choix des appareils à tester pour les tests de performances, il est important de prendre en compte ceux qui génèrent le plus de revenus. Déterminer cela nécessite une compréhension claire de la base d'utilisateurs et des types d'appareils utilisés le plus fréquemment pour l'application testée.

À partir de là, il est recommandé de sélectionner les 5 à 10 meilleurs appareils à tester de manière cohérente (le nombre exact peut varier en fonction de l'échelle du projet et de la base d'utilisateurs). Cette approche aide à établir une base de référence pour les appareils testés, permettant des mesures de performances plus précises.

Résumé

Les tests de performance sont essentiels pour garantir que les logiciels, les applications et les systèmes peuvent gérer les charges et le trafic attendus. Il permet d'identifier et de résoudre les goulots d'étranglement des performances et les défaillances potentielles avant deployment, garantissant aux utilisateurs finaux une expérience transparente.

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

La valeur des tests de performance réside dans la capacité d'identifier les problèmes au début du processus de développement, réduisant ainsi les coûts associés à leur résolution ultérieure. De plus, cela aide à établir une base de référence pour les mesures de performance qui peuvent être surveillées et comparées au fil du temps, fournissant des informations sur la façon dont les changements dans le système affectent les performances. Les tests de performance sont essentiels à tout cycle de développement logiciel, du développement à deployment et au-delà.

 

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