Date Titre de la présentation 1 COMMENT VÉRIFIER LES PERFORMANCES RESSENTIES PAR L UTILISATEUR D UNE APPLICATION MOBILE JANV 2015
SOMMAIRE Contexte Objectifs Problématique Démarche Mise en œuvre ( Réalisé et à venir) Résultats Bénéfices
Contexte Suite à la refonte de l application PagesJaunes pour iphone, nous avons constaté des problèmes d accès à nos services en interne et en externe par les stores La supervision serveur n ayant rien montré de significatif, nous avons décidé de mener un audit de notre application iphone sur la performance applicative sur : - Différents réseaux (2G/3G/Wifi) - Différentes combinaisons mobiles (terminal/os/browser) La problématique de la performance utilisateur étant globale, il faut étendre cet audit à toutes les applications mobiles.
Objectifs Réaliser un benchmark comparatif entre la concurrence, notre application refondue et l ancienne version iphone KPI : Mettre au point des KPI reproductibles sur nos futures versions Mesurer les performances (côté terminal) des nouvelles versions iphone Comparer ces mesures avec les anciennes versions iphone Identification d amélioration ou de dégradation de performance Porter ce protocole de KPI sur les autres plateformes mobiles Automatiser ces mesures en Intégration Continue Prendre en compte ces mesures automatisées dans le socle de Continuous Delivery
Problématique Benchmark : Choisir un panel de concurrents avec le marketing Définir des points de mesures communs et comparables Fréquence des mesures? KPI : pour mettre au point un KPI pertinent, il faut pouvoir garantir une comparaison fiable : Comment reproduire des conditions de réseaux identiques en laboratoire pour assurer une facilité de comparaison avec un protocole de test? Quelles sont les combinaisons représentatives de notre trafic? Mesure : comment assurer la précision de la mesure? Démarche manuelle vers Automatisation Parcours applicatif : Comment assurer la reproduction du parcours? Démarche manuelle vers Automatisation
Démarche Points de mesures Description des mesures de performance (KPI) T0 : Lancement de l application : obtention du Splash screen T1 : Affichage complet de la homepage T2 : Obtention du reverse geocoding T3 & T4 : Recherche : Chargement de LR-Texte (début et fin) T5 & T6 :Chargement de LR-Carte (début et fin) T7 & T8 Accès à la FD (début et fin) (loader image/vidéo) Dans le cas du benchmark, les marqueurs ont été adaptés pour le même fonctionnel chez le concurrent
Démarche Conditions de mesures Description des prises de mesures de performance (KPI) Mesure des temps de réponse de chaque étape de ce cas d utilisation Moyenne réalisée sur plusieurs mesures (7 à 10 mesures) Elimination des extrêmes Mesure manuelle : le point de mesure doit être bien décrit Description des choix de réseaux Une série de mesures pour chaque condition d accès au réseau Wifi, 3G, Edge Après analyse, nous avons aussi utilisé les réseaux dégradés Meilleure mise en évidence des problèmes 3G dégradée, Edge dégradée
Démarche Combinaisons cibles Comment choisir les cibles Utiliser ses statistiques d audience Utiliser ses logs serveurs (parfois plus complet) Applicatif Définir les 2 ou 3 combinaisons les plus représentatives 2 pour iphone : iphone 4 ios 6.1 & iphone 5s ios 7.1 3 pour Android Web : Mobile et/ou RWD Prise en compte du format Prise en compte des browsers ( Attention aux browsers natifs sur Android) 10 Combinaisons ( 1 iphone-2 browsers, 1 android-2 browsers, 1 WP8, un ipad-2 browsers, 1 fablette android-2 browsers, 1 tablette Android-2 browsers)
Mise en œuvre - réseau Simulation des conditions d accès au réseau S affranchir des conditions opérateurs qui peuvent fluctuer Utilisation de la librairie DummyNet et IPFW Pare-feu qui permet de simuler un réseau imparfait Il est utilisé dans l'outil de tests de montée en charge NeoLoad Il est libre et embarqué par défaut dans les OS Mac Possibilité de modifier (en montant et descendant) La bande passante La latence La perte de paquet Données issues de NeoLoad Bande passante Download LatencPerte de e paquet Bande passante Upload LatencPerte de e paquet 3G+ Bon 3600Kbit/s 40ms 0 1500Kbit/s 45ms 0 3G+ Moyen 2000Kbit/s 70ms 0 830Kbit/s 75ms 0 3G+ Faible 500Kbit/s 150ms 0.01 200Kbit/s 160ms 0 3G Bon 850Kbit/s 40ms 0 420Kbit/s 45ms 0 3G Moyen 570Kbit/s 70ms 0 290Kbit/s 75ms 0 3G Faible 300Kbit/s 150ms 0.01 150Kbit/s 160ms 0 EDGE Bon 250Kbit/s 290ms 0 85Kbit/s 300ms 0 EDGE Moyen 180Kbit/s 400ms 0 60Kbit/s 440ms 0 EDGE Faible 100Kbit/s 500ms 0.01 33Kbit/s 540ms 0 GRPS Bon 52Kbit/s 350ms 0 21Kbit/s 370ms 0 GRPS Moyen 34Kbit/s 400ms 0 14Kbit/s 440ms 0 GRPS Faible 22Kbit/s 600ms 0.01 9Kbit/s 640ms 0
Mise en oeuvre - Schéma actuel Proxy Wifi + Brique DummyNet web Appareil s IP firewall Scénario «classique» T0 à T8 HP/LRT/LRC/FD/FD Proxy WIFI Application de profils réseau EDGE 3G WiFi Autres? Rapport Excel de mesures Rapport Excel de comparaison entre version
Mise en oeuvre - Schéma cible IC / PC Proxy WiFI + Brique DummyNet web Dynatrace Appareils IP firewall Serveur reporting Scénario «classique» automatisé HP/LRT/LRC/FD /FDC Application mobile marquée par Dynatrace Proxy WIFI Application de profils réseau EDGE 3 WiFi Réseaux dégradés Mise en place d un rapport automatisé sur les mesures définies
Résultats Exemples de graphiques comparatifs de données mesurées : -Sur une même version -Sur une la vie d un produit iphone v6.7 - T3 UEM iphone EDGE 7 25,00 6 20,00 5 4 3 2 1 15,00 3G 10,00 Wifi Edge Deg 5,00 - PJ 5.6.0.7 PJ 6.2 PJ 6.3 PJ 6.4.5 PJ 6.5 PJ 6.6 PJ 6.7 PJ 6.8 T0-Fin d affichage du splash screen T1-Fin d affichage complet de la HP T3-Affichage du premier bloc de la LR T7-Début d affichage de la FD Seuil 0 iphone 5S - ios 7.1 iphone 4s ios 6 nov- 13 mars- 14 mai- 14 juin- 14 Aout sept- nov- 2014 14 14 déc- 14
Résultats Exemples de graphiques comparatifs de données prises en production : - Moyenne sur iphone - Comparaison entre 2 iphone
Résultats Exemples de graphiques de production présentant la répartition du temps de réponse
Mise en oeuvre - Limitations Limites du protocole de mesure actuel Mesures manuelles Incertitude des mesures de temps souvent inférieurs à 1 seconde Coût du test important techno uniquement sur MacOS Temps serveur : Les temps mesurés peuvent être impactés par des temps serveurs Corréler les temps obtenus à une mesure serveur (Ex : recherche, Carto) Temps Carto : Dépendance forte de services externes. Comment dissocier le temps interne du temps externe? Bouchons? Déprioristaion de l indicateur en terme d alerting Nouveaux OS et terminaux : Quand et comment intégrer une nouvelle combinatoire dans les mesures? Double run, impact sur l indicateur Fréquence : 1 fois par version Fréquence faible : mise en place de la chaine d intégration continue
Mise en oeuvre - Améliorations Proposition d amélioration du protocole - Mesures automatisées Utilisation de Ranorex ou autre Automate utilisé dans le cadre des TNR fonctionnels Utilisation de Dynatrace En cours d implémentation chez PJ Complément de la supervision mise en place Coût réduit Reproductibilité à la demande Industrialisation Plus de tests sur plus de conditions Effet de sonde dû à l automate mesurer l overhead temps difficile à communiquer si overhead Utiliser la méthode EnsureVisible pour détecter les objets réellement affichés Carto : sans callback, Dynatrace ne peut pas tracer les temps Carto Perspectives : Mesure batterie/mémoire Stress applicatif (Monkey Test)
Bénéfices Eviter de mettre en production plusieurs défauts importants fonctionnels et techniques Sur iphone, Mise en évidence d un timeout de 30sec en Edge Dégradé Chantier d optimisation de l application (lancement, Autocomplétion, gestion des vues) Sur le Responsive Design, Adaptation du protocole pour mesurer avec et sans cache optimisation de la mise en cache Mise en évidence des difficultés de chargement des pages sur des navigateurs natifs Détection de régression sur le chargement de la Homepage Sur Android, report des corrections détectées sur iphone Pas d alerte à ce jour.
Plus values Nouveau Protocole de mesure Mesures manuelles Adaptation du protocole selon la stratégie (réseau dégradé ou pas? Wifi uniquement pour les tablettes?) et la charge Mesure en avance de phase, avant la supervision, reproductible Conception générique : Couvrir les besoins de benchmark protocole de mesures compatibles sur toutes nos plateformes (iphone/android/rwd) Technique : Interconnexion avec notre chaîne d Intégration Continue Automatisation Définition et réalisation d un protocole de mesure générique Confiance L équipe Collaborative donne de la visibilité sur la qualité de son livrable avant son déploiement Plus de confiance générale dans nos applis (Marketing et Technique)
Conclusion Le protocole est intégré à chaque release de produit mobile Prise en compte de ces besoins pour le passage du site fixe en Responsive mobile la Performance utilisateur est maintenant au cœur de nos développements
MERCI À TOUS ET MAINTENANT À VOS QUESTIONS