APPLICATIONS MOBILES : QUELLES EXIGENCES NON FONCTIONNELLES ET COMMENT LES TESTER ? - Thierry leboucq (greenspector)
1 j'aime1,788 vues
Le document aborde les exigences non-fonctionnelles pour le développement de logiciels, soulignant leur complexité et leur dépriorisation par rapport aux exigences fonctionnelles. Il met l'accent sur l'importance de considérer les contraintes de performance et de consommation des ressources dans le cadre du développement, ainsi que la nécessité d'utiliser des outils de mesure appropriés pour surveiller ces exigences. Enfin, il encourage l'intégration de ces concepts dans les processus agiles pour améliorer la gestion des performances des applications.
![ISO9126 sur l’efficience :
"A set of attributes that bear on the relationship between the
level of performance of the software and the amount of
resources used, under stated conditions."
La définition d’une NFR d’efficience doit donc lister au moins
un élément de chaque domaine :
Le système doit respecter [cette performance] en
consommant [au maximum ce niveau de ressource] dans [cet
environnement / condition d’exécution]](https://image.slidesharecdn.com/thierryleboucq-greenspector-testnonfonctionnel-181022130855/85/APPLICATIONS-MOBILES-QUELLES-EXIGENCES-NON-FONCTIONNELLES-ET-COMMENT-LES-TESTER-Thierry-leboucq-greenspector-11-320.jpg)
![Le système doit respecter [cette performance]
en consommant [au maximum ce niveau de ressource]
dans [cet environnement / condition d’exécution]
NFR
Budget](https://image.slidesharecdn.com/thierryleboucq-greenspector-testnonfonctionnel-181022130855/85/APPLICATIONS-MOBILES-QUELLES-EXIGENCES-NON-FONCTIONNELLES-ET-COMMENT-LES-TESTER-Thierry-leboucq-greenspector-13-320.jpg)
APPLICATIONS MOBILES : QUELLES EXIGENCES NON FONCTIONNELLES ET COMMENT LES TESTER ? - Thierry leboucq (greenspector)
- 4. Il s’agit d’une exigence non-associée à une fonctionnalité demandée par le client mais cependant lié à un besoin client sous laquelle un logiciel doit fonctionner ou être développé. Performance Fiabilité Utilisabilité Maintenabilité
- 5. Particularités des Exigences non-fonctionnelles vs fonctionnelles : - Souvent dépriorisées par les équipes - Vérifiées en fin de cycle (en recette) car souvent au niveau système - Non adaptées aux nouvelles pratiques de développement (Agilité par exemple) - Exigences incomplètes compte-tenu des systèmes complexes Elles sont généralement traitées en production.
- 6. Outil de profiling + Mesures complètes des ressources mais non axés exigences - Complexe, peu d’automatisation Outils de testing (Performance) + Offre existante sur les outils de performance - Axés souvent uniquement backend Outils de monitoring + De nombreuses métriques - Trop d’information pour vérifier des exigences
- 7. 7 53% de visiteurs abandonnent le site si ce dernier ne se charge pas en 3 secondes Source : Chrome Dev Summit 2017
- 8. 8 19 secondes de chargement moyen en 3G pour les sites mobile Source : Chrome Dev Summit 2017
- 11. ISO9126 sur l’efficience : "A set of attributes that bear on the relationship between the level of performance of the software and the amount of resources used, under stated conditions." La définition d’une NFR d’efficience doit donc lister au moins un élément de chaque domaine : Le système doit respecter [cette performance] en consommant [au maximum ce niveau de ressource] dans [cet environnement / condition d’exécution]
- 12. La notion de consommation de ressources est une contrainte à prendre en compte pour respecter une performance donnée. Les conditions d’exécution sont aussi des contraintes (La 2G implique par exemple une consommation limitée de bande passante) La contrainte devient un cadre pour les exigences non-fonctionnelles La notion de contrainte est adaptée dans le contexte de plateforme hétérogène (Smartphones toute génération et toute puissance par exemple) Ces contraintes forment un cadre qui peut être considéré comme un budget La performance doit être respectée sans dépassement du budget ressource ou comme un objectif à challenger
- 13. Le système doit respecter [cette performance] en consommant [au maximum ce niveau de ressource] dans [cet environnement / condition d’exécution] NFR Budget
- 14. Modèle RAIL (Google) Response : 100ms Animation : 16 ms Idle : 100 ms Load : 1s + : Répartition sur les éléments de la page - : Absence de contrainte et de consommation ressource
- 15. Permet d’étendre la définition des NFR et de les répartir sur des éléments plus granulaires Par exemple : - Temps de chargement des éléments : JS, images, …. dans une page web - Permet de surveiller le respect en agilité - Se base sur le même principe que le nombre limite de tâche dans le Kanban (WIP) - Engagement entre toutes les parties (pas uniquement les développeurs) Plusieurs actions possibles suite aux dépassements - Discussion en fin de sprint - Optimisation - Médiation avec adaptation des besoins fonctionnels - Transfert des budgets sur d’autres fonctions
- 18. x3
- 19. Budget de 200 uAh/s Dépassement important Performance OK sur matériel performant Optimisation nécessaire Consommation de l’OS et du matériel Consommation Dans le budget Consommation en excès
- 20. Le dépassement de budget permet de : - Détecter un problème de consommation ressources malgré une performance correcte - Lever des problèmes de performance sur certains devices - Limiter le temps de debug et de profilling - Remettre en cause la gestion des interruptions de Android
- 21. 2 jours de correction pour une amélioration notable
- 23. Un certain besoin utilisateur non fonctionnel doit être respecté avec une (ou des) contrainte(s) de consommation matérielle. Affichage en moins de 2 secondes 8 heures d’autonomie Durée de vie de la batterie de plus de 3 ans Connexion 2G Smartphone 1 coeur Batterie 2000 mAh Besoinsouexigences Contraintes Sans contraintes, pas d’efficience mais uniquement de la performance !
- 24. L’adéquation entre le besoin et la contrainte se formalise avec un budget « Ressources » réparti sur les fonctionnalités. Besoin 8 heures d’autonomie Contrainte Batterie 3000 mAh 200 scans par jour Usage 2 heures de veille Comportement non-fonctionnel 6 mAh par scan Un 1er budget nécessite des données estimées ou des 1ères mesures
- 25. 25 • • •
- 26. -2000 -1000 0 1000 2000 3000 0 1 2 3 4 5 6 7 8 Projection d’autonomie pour le Bluebird Cible config_01 config_02 config_03 config_04 config_05 config_06 config_07 config_08 config_09 config_10 config_11 config_12 config_13 config_14 config_15 config_16 config_17 config_18 config_19 config_20 config_21 En 2G l’autonomie n’est pas respectée Autonomie respectée pour configuration réaliste (luminosité 50%,WIFI , 4G,
- 31. Au-delà du besoin de réduire la consommation d’énergie, la métrique énergie est un indicateur majeur pour piloter la consommation de toutes les parties du système (CPU, mémoire, réseau…)
- 33. L’intégration du concept dans les plateforme d’intégration continue (PIC) permet de contrôler en continu les budgets. Tout outil qui permettra de mesurer les métriques classiques et d’être automatisable est compatible : - Web Page Tests - Outils de chrome (Lighthouse) - Instrumentation de performance classique (CPU, mémoire…) Pour ajouter l’énergie : - Power API (modélisation de l’énergie sur PC) - API Android - Greenspector - Instrumentation dans les data centers
- 34. Les outils de mesure doivent être utilisés en parallèle de tests automatisés. • Nécessité d’avoir un périmètre maîtrisé (Unité fonctionnelle, unité de temps, contraintes connues) • Nécessité d’être répétable • Les tests fonctionnels sont idéals (un budget associé à une fonctionnalité) Attention, les outils de Real User Monitoring (Dynatrace, Appdynamics…) ou de profiling ne permettent pas forcément cette approche Notion de budget et de contrainte complexe (manque unité de temps entre autre)
- 35. Les NFR atteignent leurs limites telles qu’appliquées avec les méthodes actuelles. La notion de budget et de contraintes associées permet d’intégrer tous les acteurs et de mieux formaliser et tester les NFR De plus, la notion de budget va permettre l’intégration dans les process agiles La performance pure (temps de réponse) est une métrique importante mais doit être complétée par l’énergie.
- 36. Nous contacter : GREENSPECTOR [email protected] Tél. : 09 51 44 55 79 6 Rue Rose Dieng-Kuntz CS 90729 – 44307 Nantes Cedex 3 www.greenspector.com @Green_spector