Catégorie : Zone technique

Pourquoi est-il important de monitorer l’impact environnemental d’une URL ?

Reading Time: 4 minutes

Plus une URL est très couramment consultée, plus réduire son impact numérique est essentiel. Une simple mesure permet de vérifier et réagir face aux changements effectués sur la page : modifications liées à la charte graphique, à des évènements (les sites e-commerce en période de soldes) ou même des modifications techniques. Tous ces changements peuvent avoir un impact fort sur le niveau de sobriété d’une page web.

Quand intégrer la mesure de sobriété numérique d’une URL ?

Ces mesures peuvent être intégrées dans le cadre d’un monitoring quotidien sur n’importe quelle page. Des pages dynamiques dont le contenu est amené à régulièrement évoluer telles que des pages d’accueil e-commerce ou de site d’information presse sont importantes à monitorer. Même des pages moins “dynamiques” pourront être elles-aussi ciblées : la mise à jour d’une librairie CDN peut, par exemple, impacter ce type de site. Dans ce cas, la mesure permettra de s’assurer que le nouvel habillage de la page n’a pas un impact négatif sur le niveau de sobriété du site web : une image trop lourde pour une bannière pourra être facilement repérée.

La mesure peut aussi être utilisée lors de la phase de développement pour tester des choix avant la mise en production ou pour rectifier très tôt des changements trop impactants. Il est souvent difficile de changer le choix d’une technologie ou d’une implémentation une fois qu’un site est mis en production, la mesure d’une URL pendant la phase de développement permet de tester très tôt différentes options et de voir laquelle correspond le mieux en prenant en compte la sobriété numérique comme un des critères.

Exemple d’un suivi quotidien d’une page web

Comment mesurer la sobriété numérique d’une URL ?

Plusieurs possibilités s’offrent à vous chez Greenspector pour mesurer une URL.

Un premier outil nous permet d’effectuer une première mesure simple d’une URL et obtenir des constats rapides : l’outil Benchmark basé sur des tests standardisés.

Pour aller plus loin, nous pouvons effectuer la mesure d’un parcours utilisateur complet sur un site web grâce à App Scan. En général ce genre de mesure est effectuée pour représenter le chemin complet sur un site web ou application mobile, comme un parcours d’achat ou la réalisation d’un virement bancaire. Il permet d’identifier les points sur lesquels se concentrer pour obtenir rapidement une amélioration significative. Dans le cadre d’un App Scan, la mesure d’une URL est également possible via un parcours automatisé ce qui va permettre l’obtention de métriques spécifiques au-delà du benchmark.

Mesure d’URL (via App Scan) vs Benchmark

Voici les différentes étapes mesurées lors d’une mesure URL (via AppScan) vs l’outil Benchmark :

Étapes mesurées

  • Chargement sans cache
  • Pause après chargement sans cache
  • Pause sur la page sans cache
  • Scroll sur la page
  • Pause sur la page après le scroll
  • Chargement avec cache
  • Pause sur la page avec cache
  • Mesure de l’application en arrière-plan

Benchmark

Mesure d’URL

La mesure URL (via App Scan) contient plus d’étapes que le benchmark, nous y reviendrons. Contrairement au benchmark, la mesure URL est plus précise sur les chargements, la durée mesurée étant la durée réelle du chargement contrairement à l’outil benchmark qui réalise les mesures sur une durée fixe de 20 secondes. Une autre différence importante est qu’une mesure URL gère les fenêtres présentes sur la page, en particulier celles qui concernent les cookies, ce que ne fait pas l’outil benchmark.

Enfin, la mesure URL via App Scan par Greenspector permet de réaliser des mesures sur d’autres navigateurs que Google Chrome. L’outil benchmark est limité à ce dernier navigateur mais notre expertise GDSL nous permet de proposer un autre navigateur tel que Firefox par exemple pour aller encore plus loin.

Les étapes d’une mesure d’URL (via App Scan)

  • Chargement sans cache : Il s’agit du chargement de l’URL en ayant préalablement vider le cache et supprimer tous les cookies. Cette étape permet de mesurer le chargement de la page web lorsqu’un utilisateur s’y rend sans cache. C’est particulièrement important pour les URLs avec beaucoup de visites uniques.
  • Pause après chargement sans cache : La mesure d’une courte pause après le chargement permet de récupérer les échanges de données et autres opérations qui s’effectuent encore alors que l’affichage de l’écran est terminé. L’idéal étant bien entendu de n’avoir rien de tout ça. Dans le cas contraire cela nous permet de faire des constats et de proposer des pistes pour faire disparaitre ou réduire ces traitements. 
  • Pause sur la page sans cache : La mesure de pause sur la page représente l’action d’un utilisateur en train de lire le contenu. Aucun mouvement sur l’écran. L’idée de cette étape est de mesurer l’impact de l’affichage continu de la page.  
  • Scroll sur la page : Défilement jusqu’en bas de la page permettant de réaliser des constats sur les traitements pendant le scroll. Ici nous pouvons faire des constats sur les possibles échanges de données (pagination, téléchargement d’image, publicité) ainsi que la fluidité associée. 
  • Pause sur la page après le scroll : Mesure de pause après le défilement permettant d’observer des traitements qui continuent après la fin des interactions utilisateur.  
  • Chargement avec cache : Mesure du chargement de l’URL avec le cache des intéractions précédentes (chargement, scroll). Cette étape permet de constater l’impact de la mise en cache sur le site. C’est important pour les pages amenées à être consultées un grand nombre de fois par des visiteurs connus, comme par exemple une page d’accueil d’un site internet. 
  • Pause sur la page avec cache : La mesure de pause sur la page permettant de voir si malgré le cache il y a des traitements après le chargement.

Grâce à nos outils et notre expertise nous pouvons proposer des mesures fiables et pertinentes sur une URL. Que ce soit une mesure simple permettant des premiers constats à l’aide de notre outil de benchmark ou une mesure plus poussée avec notre langage GDSL. Ce monitoring régulier d’URL permet d’améliorer progressivement le niveau de sobriété de son site web. Cette approche par rapport à d’autres approches courament utilisées dans le web (Analyse uniquement du chargement de la page avec Lighthouse ou autres…), apporte plus de finesse sur la connaissance de la consommation de la page.

Comment nettoyer l’application Chrome pour réaliser des mesures de performances et d’énergie fiables ?

Reading Time: 5 minutes

Contexte

Bienvenue dans cette nouvelle rubrique “focus GDSL” qui explique en détail certaines méthodes du langage GDSL d’automatisation de Greenspector. Si vous n’avez pas encore lu l’article d’introduction du GDSL, n’hésitez pas avant de poursuivre la lecture de celui-ci.

Aujourd’hui, nous allons nous concentrer sur la méthode browserReset qui permet de nettoyer un navigateur pour réaliser des mesures de performances et d’énergie fiables.

Pour réaliser des mesures correctes sur navigateur, il faut pouvoir s’assurer que vous allez mesurer uniquement votre page web, sans aucun parasite pouvant provenir du navigateur comme des onglets ouverts par exemple. Sans ce travail, la mesure de la consommation d’une page web serait faussée par des pages en arrière plan effectuant des traitements et des échanges réseaux. De plus, cela nous permet de mesurer précisément la consommation du navigateur à vide, une fois le nettoyage effectué, et la comparer à la consommation du site.

En automatisation, ce que l’on ne supporte pas, c’est de ne pas connaître les conditions initiales de notre test. Cela pourrait perturber son bon fonctionnement, voire même aboutir à un test dont on ne peut rien tirer car on ne sait pas au final ce qui aura été mesuré.

Sur un banc de test automatisé, il est difficile de connaître l’état du navigateur au début de votre test : vous ignorez si un test précédent a laissé des onglets ouverts, a modifié la langue du navigateur ou quoi que ce soit d’autre. On pourrait aller voir dans la salle des téléphones me direz-vous. Oui c’est vrai, mais si elle est à l’autre bout du monde ça devient compliqué, sans parler de la situation sanitaire actuelle (cet article à été rédigé en pleine crise du Covid-19). On pourrait aussi se servir d’outils pour monitorer le téléphone à distance. Alors oui, mais cela n’est valable que si vous êtes présent au moment d’exécuter votre test. Pour des campagnes en intégration continue qui peuvent tourner toutes les heures, ou même la nuit, vous n’allez pas pouvoir surveiller en permanence.

Alors que faut-il faire ? Et bien, nettoyer le navigateur avant chaque test pardi !

Approche rapide

Pour notre cas, nous allons utiliser le navigateur Chrome, mais le raisonnement est le même avec un autre navigateur. Nous allons aussi partir du principe que ce navigateur est régulièrement mis à jour sur les téléphones.

Une méthode rapide et qui va fonctionner dans beaucoup de cas pour nettoyer un navigateur consiste à fermer les onglets ouverts et nettoyer le cache au début de chacun de nos tests. De cette manière, quand le navigateur s’ouvrira la prochaine fois pour prendre des mesures, il sera sur un onglet vide.

Cette méthode va fonctionner sur la majorité des smartphones mais va être à la peine sur tablette à cause de la gestion des onglets. Sur tablette, les onglets sont en général affichés sur une barre en haut (ou en bas) du navigateur, comme sur un ordinateur. La particularité de cette barre d’onglet est qu’elle est invisible pour les outils classiques d’automatisation, ce qui rend très compliqué de cliquer sur la croix pour fermer l’onglet. De plus, la taille d’un onglet va dépendre du nombre d’onglets ouverts, rendant le clic par coordonnées encore plus hasardeux.

Pour couronner le tout, le bouton pour fermer tous les onglets d’un coup n’apparait qu’avec un appui long sur la croix de fermeture du premier onglet, le rendant inutilisable pour nous.

La dernière difficulté que peut rencontrer cette méthode est sa maintenance. En effet en mettant à jour l’application, la gestion des onglets peut changer, tout comme l’architecture de l’application, obligeant à modifier régulièrement les scripts d’automatisation.

Solution complète

La solution utilisée chez Greenspector pour nettoyer le navigateur avant nos mesures et nous assurer de la pertinence de nos résultats est la suivante :

  • Nettoyer les données de l’application. Ceci est généralement fait à l’aide de la commande adb shell pm clear PACKAGE_NAME, mais peut aussi être réalisée dans le menu paramètres du téléphone.
  • Passer les popups de premier lancement du navigateur avec l’automatisation.

Une fois ceci effectué, il reste un dernier point qui peut poser problème : certains constructeurs ou opérateurs mobiles affichent une page d’accueil personnalisée sur le navigateur. Pour permettre de comparer des mesures entre plusieurs smartphones, il faut se débarrasser de cette page d’accueil. Nous avons choisi de désactiver la home page dans les paramètres du navigateur.

Il reste un dernier point concernant cette page d’accueil. En effet celle-ci à été chargée au premier lancement du navigateur et est donc ouverte, ce qui n’est pas pratique pour faire des mesures. Notre solution a été de naviguer vers la page « nouvel onglet » de Chrome à l’url suivante :

  • « chrome://newtab »

Une fois toutes ces opérations effectuées, votre navigateur est prêt pour réaliser des mesures sans risque d’avoir des conditions existantes pour venir le perturber.

L’idéal est même d’effectuer ce nettoyage aussi à la fin de votre test. De cette manière vous laissez le téléphone prêt à l’emploi pour la personne suivante.

MISE À JOUR : Pour nos besoins de mesures, nous nous intéressons aux données de performances, d’énergie et les données mobiles entre autres. Cette méthode répond parfaitement aux besoins de performances et d’énergie, mais ne convient pas pour les données sur le navigateur Chrome. En effet, en réinitialisant le navigateur, Chrome resynchronise automatiquement les données du compte Google, et sur au moins les deux premières minutes d’utilisation, il y a des échanges de données liées au compte Google. Se déconnecter du compte Google sur Chrome ou du téléphone ne semble pas régler le problème entièrement. Par conséquent, chez Greenspector, nous n’utilisons plus cette méthode pour nettoyer un navigateur. Aucune mesure n’a été effectuée sur d’autres navigateurs que Chrome permettant de dire que cette méthode n’est pas valide sur ceux-ci.

Voila vous savez tout sur la méthode browserReset. À bientôt pour un nouveau focus GDSL où je vous ferais découvrir une autre fonctionnalité du langage d’automatisation de Greenspector.

Introduction au GDSL : le langage d’automatisation par Greenspector

Reading Time: 3 minutes

Qu’est-ce que le GDSL ?

Le terme GDSL signifie Greenspector Domain-Specific Language. Il s’agit d’un langage créé par Greenspector pour simplifier l’automatisation de test sur Android et iOS. Concrètement c’est une surcouche basée sur les frameworks d’automatisation de Google et d’Apple agrémentée de fonctions pour faciliter l’automatisation de test. 

Ce langage est le fruit de l’expertise Greenspector accumulée depuis plusieurs années déjà. Il combine la simplicité d’écriture à la possibilité de mesurer les performances énergétiques d’une application ou d’un site internet. 

Le principe du GDSL est d’être un langage de description des actions qui seront effectuées sur le smartphone. En ce sens il peut être rapproché du Gherkin avec qui il partage la qualité de ne pas nécessiter de formation de développeur pour être lu.

Le GDSL est une suite d’actions qui seront exécutées dans l’ordre par le smartphone. Il dispose des actions basiques que sont les WAIT, CLICK ou encore PAUSE ainsi que d’actions plus complexes comme le lancement d’application ou la gestion du GPS. 

Avec le GDSL il est possible d’automatiser rapidement la plupart des parcours critiques de vos applications ou site web mobile. 

La syntaxe du GDSL

Voici une ligne de GDSL: 

waitUntilText,identifiants,10000

Le premier élément, en vert (waitUntilText), est le nom de la méthode. En général elle sera en anglais et explicite. Ici on va attendre un texte. Les principales actions de WAIT et de CLICK sont disponibles avec des déclinaisons pour id, texte ou content-description

Le second élément, en orange (identifiants), va être le paramètre principal de la méthode. Il s’agit généralement de l’élément graphique sur lequel doit être effectuée l’action. Selon la méthode appelée il s’agira d’un id, d’un texte ou encore d’une description. Dans l’exemple il s’agit d’un texte. 

Le dernier élément, en bleu (10000), est un second paramètre de la méthode. Il s’agit le plus souvent de paramètres optionnels donnant des conditions supplémentaires lors de l’exécution. Ici il s’agit d’un temps en milli secondes. 

Pour séparer chaque élément on utilise une virgule. 

La méthode présentée en exemple sert donc à attendre l’élément avec le texte “identifiants” pendant une durée maximum de 10 secondes. 

Dans l’état actuel du langage il n’y a pas de méthodes demandant plus de deux paramètres. Si la méthode échoue alors le test s’arrêtera et le rapport indiquera le test comme échoué. 

Les avantages du GDSL

  • Le GDSL ne demande aucune compétence en développement ou connaissance en langages de programmation pour être utilisé ou lu. Le nom des méthodes est explicite et permet à n’importe quelle personne arrivant sur le projet de lire et comprendre vos tests. 
  • Aucun IDE ou environnement de développement spécifique n’est nécessaire pour écrire du GDSL, un simple éditeur de texte suffit
  • Un test = un fichier. Avec le GDSL pas besoin d’architecture de fichier compliquée, un seul fichier contient votre test. 
  • Sa facilité d’utilisation permet d’écrire un test très rapidement sans dépendance au reste du projet de test comme le demanderaient d’autres langages de test automatique. 
  • De plus sa facilité d’exécution avec les outils associés chez Greenspector permet de mettre très rapidement en intégration continue chaque nouveau test. 
  • Mis à jour et maintenu régulièrement, le langage possède déjà des fonctions avancées pour l’automatisation de site internet telle que l’ouverture d’onglet ou la navigation d’url. 
  • En directe association avec les outils et l’expertise de Greenspector le GDSL est le seul langage d’automatisation qui vous permet de mesurer les performances et l’impact environnemental de votre application tout en effectuant vos tests quotidiens. 

Les limites actuelles du GDSL

  • Le GDSL ne permet pas encore d’effectuer des tests à logique complexe (exemple : si je suis connecté alors je vois l’élément 1, sinon je vois l’élément 2). Il faut écrire un test différent pour chaque cas. 
  • Le GDSL se base sur des éléments graphiques présents sous forme descriptive. Il est incapable d’interpréter le contenu d’une image ou d’analyser la mise en page de votre application. Impossible de faire un test vérifiant que le bouton est bien situé en bas à droite de l’écran. 

L’équipe Greenspector travaille au quotidien pour améliorer le langage et ajouter des fonctionnalités. L’état actuel permet d’automatiser la plupart des scénarios nécessaires à une campagne de mesure complète d’une application ou d’un site web ainsi que les parcours critiques de la plupart des applications. Dans un prochain article, nous vous parlerons des outils Greenspector permettant l’exécution des tests GDSL.

Les nouveautés Greenspector : release note v.2.9.0

Reading Time: 2 minutes

L’équipe Greenspector est fière d’annoncer la sortie de sa nouvelle release : la version 2.9.0.

Afin de mesurer la consommation des applications et des sites web, vous pouvez exécuter des parcours utilisateurs sur nos fermes de smartphone. Dans ce contexte, nous avons amélioré notre langage de test simplifié (le GDSL) avec par exemple des fonctionnalités de préparation des browsers, prise en compte de Firefox… Contrairement à de nombreux outils qui vous fournissent un impact environnemental uniquement sur la page principale et sur des environnements simulés, ces capacités vous permettront d’évaluer et de suivre précisément l’impact de votre solution numérique !

API Swagger pour les routes existantes
Vous pouvez désormais changer de navigateur très facilement

Mesurer la performance des applications mobiles : monitoring synthétique ou real user monitoring ?

Reading Time: 3 minutes

La “digitalisation” des entreprises et particulièrement l’offre de plus en plus importante d’applications numériques, rendent le critère de qualité des applications mobiles de plus en plus nécessaire. La performance est dans ce cadre un critère de contrôle obligatoire. Sans cela, les risques sont nombreux pour les concepteurs d’applications : désinstallations, taux d’attrition en hausse, échec de projet, chiffre d’affaires en baisse…

Mais le fait de tester la performance des applications mobiles n’est pas aussi simple que de tester une application classique comme en avait l’habitude les équipes des DSI. En effet de plus en plus, les applications mobiles sont d’une part exécutées dans un environnement contraint (en termes de batterie, ressources…) et d’autre part, elles intègrent des services tiers qui sont complexes à maîtriser. Au final, avec des serveurs répondant en moins de 200ms, on arrive très souvent à des temps de réponses des applications malheureusement supérieurs à 3s.

Pour répondre à ce problème, il est important de bien comprendre les méthodes utilisées par les outils de ce marché en constante évolution.

Outils de monitoring vs outils de développement

Tester la performance de son application reste possible et accessible, surtout avec les SDK et les IDE de développement (Xcode, Android Studio…). Pour aller plus loin, de nombreuses solutions sont disponibles en open source. Cependant, cette approche nécessite de lancer des tests manuels sur son téléphone.

Avantages :

  • Mesure de la performance pendant le développement
  • Analyse détaillée possible dès détection d’un problème

Inconvénients :

  • Mesure assez aléatoire et pas forcément reproductible
  • Nécessite un smartphone de test à disposition

Les outils de monitoring permettent d’industrialiser la démarche de mesure de la performance en se basant sur des agents qui prennent la place du développeur.

Outils de monitoring synthétique vs outil de monitoring en usage réel (Real User Monitoring)

Les outils de monitoring synthétique sont des outils qui testent la performance des solutions dans des cas d’usages proches de ceux d’un utilisateur. Pour cela, des agents extérieurs stimulent l’application dans un environnement soit simulé soit réel (Emulateurs ou fermes de devices). L’avantage de cette solution est de surveiller la performance en continu. Cette approche s’applique même avant la mise en production de la solution ou avant que les utilisateurs finaux soient présents.

Avantages :

  • Remontée de la performance avant la mise en production
  • Mesure en continue pour l’identification des problèmes

Inconvénients :

  • Simulation pas nécessairement représentative de l’usage réel de l’application par les utilisateurs finaux
  • Nécessité d’utiliser des devices en continu pour faire tourner le monitoring

Les outils RUM remontent la performance réelle des utilisateurs. Cela nécessite l’intégration d’un agent dans l’application. Cette intégration permet la remontée d’autres métriques : parcours utilisateur, usages de l’application…

Avantage :

  • Vision réelle de la performance des applications

Inconvénients :

  • Impact de l’agent sur la performance de l’application
  • Détection trop tardive des problèmes
  • Trop d’informations lors de l’analyse des problèmes

Tests techniques vs tests fonctionnels pour les outils de monitoring

La simulation de l’application dans les outils de monitoring nécessite des tests automatiques. La solution la plus simple à mettre en œuvre repose sur les tests techniques : Lancement de l’application, ouverture de pages…

Avantages :

  • Mise en œuvre immédiate
  • Tests standards permettent d’identifier facilement des problèmes ou de se comparer avec des applications concurrentes

Inconvénient :

  • Tests pas forcément adaptés aux spécificités et au fonctionnel de l’application
  • Certains outils proposent d’effectuer des tests fonctionnels pour suivre la consommation. Le parcours utilisateur est alors simulé ou réellement effectué. Cela nécessite de scripter les actions de l’utilisateur. Généralement les outils se basent sur des technologies de script standardisés.

Avantages :

  • Simulation proche du parcours réel de l’utilisateur
  • Mutualisation des tests développés pour d’autres usages (tests fonctionnels par exemple)

Inconvénient :

  • Nécessité de développer les tests automatiques au préalable

NB : Des outils permettent de simuler une suite de requête vers les serveurs. Cette pratique issue des technologies serveurs (par exemple Jmeter) permet de tester plus la partie serveur mais est peu adaptée à la mobilité. En effet, elle ne permet pas de prendre en compte la complexité des plateformes mobiles.

Environnement émulé ou physique

Les environnements émulés (ou virtuels) sont identiques aux émulateurs de développement.

Avantage :

  • Mise en place assez rapide

Inconvénient :

  • Performance ne correspondant pas à des devices réels

Les environnements réels sont des téléphones mis à disposition par les outils de monitoring.

Avantage :

  • Performance identique aux devices réels

Inconvénients :

  • Coûts plus importants
  • Difficulté d’être représentatif de l’ensemble des devices des utilisateurs.

Les conseils des experts GREENSPECTOR

La clé est de détecter au plus tôt les problèmes de performance avant qu’ils n’affectent vos utilisateurs finaux. Il est donc nécessaire d’utiliser des outils de monitoring synthétique. Les outils de développement permettront de compléter l’analyse des problèmes de performance. Afin d’être représentatif de l’usage final de l’application, il sera nécessaire de mettre en place la bonne stratégie : tests fonctionnels à minima, exécution sur un échantillon représentatif de devices réels d’utilisateurs, simulation de différentes conditions de communication… Les outils RUM permettront de confirmer et compléter les hypothèses.

Les utilisateurs de GREENSPECTOR ont la possibilité d’appliquer cette stratégie via différents modules :

Pourquoi automatiser les tests de ses applications mobiles ?

Reading Time: 3 minutes

L’automatisation des tests est bien souvent considérée comme un surcoût au sein des équipes de développement, et cela pour différentes raisons :

Nécéssite une montée en compétence des équipes sur un outil en particulier

Les temps de rédaction sont plus importants que les temps d’éxécution manuels

Nécéssite un maintien des tests sur la durée

Le développement mobile comprenant des coûts projets plus faibles et des temps de développement raccourcis n’aide pas au passage à l’automatisation des tests. Les bénéfices ne sont en effet pas forcément bien évalués vis-à-vis du coût de l’automatisation. Au final, les projets d’automatisation des applications mobiles passent souvent à la trappe ou sont décalés trop tard dans le projet. C’est une erreur car les bénéfices de l’automatisation des tests pour les applications mobiles sont nombreux.

Les applications mobiles sont des applications comme les autres : complexes, techniques…

Les applications mobiles sont considérées comme des applications nécessitant peu de développement, des coûts faibles… Or ce n’est pas toujours le cas. Nous ne sommes plus dans la même situation des dernières années où les projets d’applications mobiles étaient des Proofs Of Concept et autres balbutiements. Les applications mobiles ont maintenant subi l’entropie naturelle de tout projet logiciel : contraintes de sécurité renforcées, librairies et SDK intégrées, architectures modulaires, intéractions multiples avec des serveurs backend

Cette maturité (mélée à l’entropie des logiciels) ne permet plus de laisser de côté les tests. Une industrialisation des tests, et en particulier l’automatisation, permet d’assurer une qualité nécessaire aux projets mobiles. Sans cela, c’est un échec assuré.

L’échec n’est plus envisageable

Associées à cette complexification des projets mobiles, les applications sont devenues des projets critiques pour les entreprises. En effet, elles sont les nouvelles vitrines des marques et des organisations. Et compte-tenu des cycles de développement rapides, un échec du projet (retards, détection trop tardive de bugs utilisateurs…) peut être fatal à l’image de l’entreprise. D’autant plus qu’une mauvaise expérience vécue par l’utilisateur peut amener tout simplement à la désinstallation, la non-utilisation de l’application ou encore la rédaction d’un avis négatif sur les stores.

Le niveau de qualité doit donc être au rendez-vous et les tests automatisés sont un passage obligé pour contrôler la performance de son application.

Tester c’est douter, le doute est bon

Une équipe de développement de qualité, un processus “carré” et des tests manuels pourraient permettre d’assurer cette qualité. Tester serait mettre en doute les compétences de l’équipe ? Non, car comme le stress du funambule qui lui permet de traverser le ravin, le doute est bon pour la qualité. Un SDK avec un comportement inattendu, une regression non-désirée… Autant assurer avec des tests.

L’automatisation permet de faire du Test Driven Development (TDD)

Anticiper l’automatisation va permettre de plus d’aller vers des pratiques de Test Driven Development. Rédiger les tests avant le développement est tout à fait possible dans les projets mobiles. Avec ou sans outillage, il est intéressant d’automatiser un scénario spécifié et de le lancer en cours de développement.

Et sans parler de Test Driven Development, le fait d’avoir des tests qui suivent de près le développement permettra de détecter au plus tôt des problèmes et autres bugs.

La fragmentation des plateformes ne peut être géré avec des tests manuels

Tester manuellement sur un device uniquement ne permet plus de s’assurer du bon fonctionnement d’une application. La diversité des matériels avec des configurations matérielles et logicielles variées est source de bug. Tailles d’écran différentes, surcouches constructeurs… une automatisation va permettre de lancer des tests en parallèle sur différents devices et de détecter des potentiels bugs. On évitera comme cela de confondre utilisateurs finaux et bêta-testeurs de l’application !

Maîtriser les régressions en maintenance

La sortie de la première release de l’application n’est que le début du cycle de vie de l’application. 80% de la charge de développement correspond à de la maintenance et à l’évolution de l’application. Il est donc nécessaire de se projeter sur la durée. En automatisant, on va ainsi éviter d’ajouter des régressions dans l’application. Le lancement des tests sera systématique à chaque évolution de l’application.

L’automatisation permet d’avoir des métriques de performance

Au final, l’automatisation va permettre de suivre d’autres exigences que les exigences fonctionnelles : les exigences non-fonctionnelles. En effet, associés à des outils des mesures, les tests automatisés vont permettre de remonter de nouvelles métriques : performance, consommation de ressources…

C’est la stratégie que GREENSPECTOR préconise à ses utilisateurs. En intégrant l’API GREENSPECTOR dans les tests automatisés, ils peuvent suivre à chaque campagne de test : l’efficience et la performance de leur développement. Le coût de l’automatisation est alors largement couvert par les bénéfices. CQFD

Adaptive Battery sous Android 9 Pie : Votre application risque d’être fortement impactée

Reading Time: 4 minutes

Android 9 Pie (API level 28) introduit une nouvelle fonctionnalité de gestion de la batterie : l’Adaptive Battery. En fonction de l’usage des applications par l’utilisateur, le système va restreindre certains mécanismes pour ces applications.

Nouveauté Android 9 : Adaptive Battery

Le système priorise l’usage des ressources d’après la fréquence d’usage des applications ainsi que le temps écoulé depuis leur dernière utilisation. 5 classes d’applications (buckets) ont été mises en place :

  • Active : L’utilisateur utilise fréquemment l’application. Certains critères d’architecture sont également pris en compte : lancement d’une activité, service foreground [premier-plan], utilisateur qui clique sur une notification…
  • Working set : L’application est utilisée fréquemment mais n’est pas tout le temps active. Une application de type réseau social sera par exemple assignée en Working set. Une application utilisée indirectement sera aussi dans cette classe.
  • Frequent : L’application est utilisé fréquemment mais pas forcément quotidiennement.
  • Rare : Une application utilisée de façon irrégulière. Par exemple une application de réservation de vol d’avion pour un particulier.
  • Never : L’application a été installée mais jamais utilisée.

L’algorithme se base sur l’intelligence artificielle (IA), il est probable que l’apprentissage de l’usage prenne plusieurs jours. Il est probable que beaucoup d’applications seront attribuées à la classe Frequent voire Rare. Les applications system ou Google (Maps, Appareil photo…) seront probablement en Working Set et les applications usuelles (banque, voyage…) risquent d’être classées comme Frequent. L’implémentation pourra aussi dépendre du constructeur du smartphone.

Restrictions liées à l’Adaptive Battery

En fonction des buckets, plusieurs restrictions seront mise en place :

  • Job
  • Alarm
  • Network
  • Firebase Cloud Messaging

Cela signifie plusieurs fonctionnalités de vos applications pourraient être impactées :

  • Requête réseau pour mettre à jour des ressources
  • Téléchargement d’information
  • Tâche de fond
  • Appel périodique d’API système

Les restrictions seront les suivantes :

BucketsJobAlarmNetworkFCM
ActivePas de restrictionPas de restrictionPas de restrictionPas de restriction
Working setDécalé jusqu’à 2 heuresDécalé jusqu’à 6 minutesPas de restrictionPas de restriction
FrequentDécalé jusqu’à 8 heuresDécalé jusqu’à 30 minutesPas de restrictionHigh priority: 10/jour
RareDécalé jusqu’à 24 heuresDécalé jusqu’à 2 heuresDécalé jusqu’à 24 heuresHigh priority: 5/jour

Comment améliorer le classement de son application ?

L’une des manières d’éviter d’être déclassé est l’attribution est que l’utilisateur place votre application dans la whitelist Doze. En effet, les applications figurant sur cette liste blanche sont exemptées des restrictions.

  • Si votre application n’a pas de launcher activity, il faut penser à en implémenter une si possible.
  • Il est important que vos utilisateurs puissent interagir avec les notifications.
  • N’encombrez pas votre utilisateur de trop de notifications, sinon ce dernier pourrait les bloquer et votre application serait déclassée.

La difficulté de tester

Il va être difficile de prévoir dans quelle classe votre application sera affectée. Il est probable que l’usage des utilisateurs sera fragmenté et votre application pourra se retrouver dans chacune des 5 classes. Si vous souhaitez connaître la classe de votre application (mais dans le cas de votre usage), vous pouvez utiliser l’API :

Il est cependant nécessaire de tester votre application dans les différents cas. Pour cela vous pouvez placer l’application dans la classe voulue avec ADB :

adb shell am set-standby-bucket packagename active|working_set|frequent|rare

Il est évident que la durée des tests va être plus longue.

À noter que si vous avez une application multi-apk, il est possible que tous les APK n’aient pas la même classe. Il est alors important de réfléchir à une stratégie de test adaptée.

L’Adaptive battery réduit-elle réellement la consommation de batterie ?

Avec l’annonce de cette nouvelle feature (associée au buzzword d’Intelligence Artificielle) de nombreuses spéculations sur le fonctionnement ont été entendues : Android mettrait en mémoire les applications les plus utilisées, permettrait des gains importants en énergie… Google annonçait 30% de gain CPU sur le lancement de l’application. Or ce chiffre correspondait en fait plus à des mesures réalisées dans le contexte Google. On est plus probablement autour de 5% de réduction. L’implémentation de l’Adaptive battery est en effet plus restreint : en fonction de l’usage, certains traitements, surtout en tâche de fond, sont décalés. Cela permet par exemple dans certains cas où l’utilisateur n’aurait plus de batterie de les reporter à une période où l’appareil sera branché. On décale donc le traitement, mais il n’est en aucun cas supprimé. (Source). L’Adaptive battery permettra probablement plus de gain au fur est à mesure que les développeurs utiliseront les alarms et les jobs. L’Intelligence Artificielle qui réduirait drastiquement la consommation d’énergie est une cible pour Android mais nous n’assistons qu’à ces débuts.

On le voit, les différentes versions Android amènent de plus en plus des fonctionnalités de gestion d’énergie (Doze, Adaptive battery…). Les gains pour les utilisateurs sont en revanche difficilement chiffrables. En tout cas, nous n’assistons pas à une explosion de la durée d’autonomie des smartphones. Cependant, cela amène une visibilité supplémentaire pour les applications qui sont détectées en tant que trop consommatrices par le système. Et l’impact est alors fort pour l’application, car l’utilisateur, une fois prévenu, risque tout simplement de la désinstaller.

Au final, que faire ?

Il est difficile de prévoir comment le système va percevoir une application donnée (Fréquemment utilisée, rarement…). Cependant trois axes sont importants :

  • Une application efficiente, fluide et bien conçue sera probablement plus souvent utilisée. Au-delà des bonnes pratiques que l’on donne dans cet article, il est important d’avoir un niveau de qualité élevée pour son application. Cela implique plus de test, un contrôle élevé de la qualité, la mesure des métriques de consommation de ressources et d’énergie…
  • Les traitements en tâches de fond via Alarmes et Jobs ainsi que les traitements réseaux sont ciblés par Android. Il est important de concevoir une architecture d’application efficace et de tester le comportement de ces tâches. Et cela dans diverses conditions : connexions réseau différentes, plateformes fragmentées….
  • Les OS et constructeurs continuent de rechercher des mécanismes pour éviter que les applications n’utilisent trop de batterie. En tant que développeur d’application il est critique d’anticiper cette problématique. En effet, la clé du problème est la conception des applications. Sans un meilleur comportement des applications, les systèmes risquent de continuer à mettre des mécanismes peu efficaces mais contraignants.