telecomvalley 2017 05-18-armagnacq_automatisation+test_ihm

1

Commission

Test et Qualité Logiciel 18 mai 2017

Animateurs Julien Van Quackebeke / CEO ALL4TEST

Oliver Garrigues / QA manager Crossknowledge

Automatisation du Test des I.H.M 1. Contexte, évaluation et décision, stratégie d’automatisation du test

2. Concepts, modes enregistrement / exécution / rejeu / modulaire

3. Gestion des environnements, des données et paramétrage

4. Codage, exécution, validation, fiabilisation

Présentation de tests automatisés, code, exécution, résultat

5. Planification, évolutivité, maintenance, obsolescence

6. Campagnes de tests automatiques, statut, progrès, indicateurs

7. Outils, environnements, configurations d’automatisation

8. Profils et compétences, certification ISTQB, méthodologie

9. Retours d’expériences, quelques chiffres, conclusions

Un bref exercice d’automatisation, et retour sur investissement

Jean-Luc ARMAGNACQ Architecte Industrialisation Test Logiciel

Sophia Antipolis – 18 mai 2017 certifié ISTQB

3

1. Contexte, évaluation et décision d’automatisation des tests

▌ Contexte - Application IHM avec important volume écrans / pages > 10

- Fonctionnalités > 10 et Use cases / User stories > 20

- Développement incrémental des nouveautés fonctionnelles

- Faible taux de modification de l’existant, longue vie des tests avec faible maintenance < 10%

- Multiplicité des environnements (plate-formes, systèmes d’exploitation, navigateurs)

- Répétitivité des tests, existence de séquences communes

- Campagnes de tests de non-régression fréquentes, journalières, hebdomadaires

- Itérations et pilotage des tests avec données

- Maximisation de la couverture de test, couverture combinatoire, systématisation des tests

Evaluation de l’automatisation - Selon l’effectivité des critères présentés ci-avant.

Décision d’automatisation des tests - O U I si > 3 critères sont effectifs.

- NON dans le cas contraire; c’est aussi une décision acceptable.

4

1.1 Stratégie d’automatisation des tests

▌ Stratégie, définie selon… - Couverture du périmètre du test par l’automatisation

- Priorité des tests à automatiser

- Complexité des tests

- Disponibilité des fonctionnalités à tester

- Disponibilité des environnements de test

Tests automatisables, par type - Fonctionnel Positif : déroulement nominal de l’application

- Fonctionnel Négatif : déroulement avec traitement des erreurs

- Performance : capacités de l’application

- Stress : résistance aux sollicitations intenses

- Endurance : stabilité au cours du temps

- Sécurité : résistance aux malveillances

Objectifs - Couverture : maximisée

- Fiabilité : respect du déroulement spécifié

- Régularité : absence de fatique humaine

- Exploitabilité : exécution 24h/24

Tests non automatisables - Fonctionnalité trop évolutive

- Complexité trop grande

- Développements applicatifs spécifiques lourds

- Environnements spécifiques coûteux

- Limites techniques de l’outil d’automatisation

5

1.2 Bénéfices de l’automatisation des tests

▌ 4 contributions de l’automatisation au test logiciel industrialisé

Précision - Traçabilité de la couverture de test, définition et connaissance du périmètre testé et non testé

- Fiabilité du périmètre testé, aucun risque de simplification dans l’exécution des tests

Régularité - Répétition systématique des scénarios de test, aucune improvisation dans l’exécution des tests

- Absence de distorsion dans la couverture de test, comparaisons strictes des exécutions des tests

Productivité - Maximisation de l’utilisation des ressources machines 24H/24

- Absence de baisse de vigilance, rigueur constante au cours des exécutions des tests

Qualité - Délégation des tâches répétitives et fastidieuses aux machines

- Affectation des tests intrusifs et tâches gratifiantes aux humains

6

2. Concepts, modes enregistrement, exécution, rejeu, modulaire

▌ Concepts des tests automatiques Capacités des outils

- Enregistrement et exécution du script de test

- Reconnaissance des objets de l’IHM et de leur organisation statique et dynamique (création, modification, suppression)

- Acquisition des actions effectuées

- Acquisition des données utilisées

- Définition des états de l’IHM

- Activation des objets de l’IHM

- Vérification des états de l’IHM

Mode enregistrement

- Acquisition des actions sur l’IHM par l’utilisateur : menus, boutons, entrées clavier, déplacements pointeur.

- Définition des états attendus des composants de l’IHM : activation, couleur, texte, image...

Mode exécution

- Déclenchement des actions sur l’IHM : menus, boutons, entrées, déplacements.

- Vérification des états effectifs des composants de l’IHM / états attendus.

7

2. Modes d’automatisation, mode rejeu, mode modulaire

Automatisation en mode rejeu cible : Quelques dizaines de tests très stables

- Exécution des actions avec les données enregistrées.

- Facilité de création du script des actions et des vérifications.

- Impossibilité de réutilisation des actions et des vérifications , nécessité de réenregistrer.

- Difficulté de gestion des objets dynamiques.

- Difficulté importante de maintenance des actions et des données, nécessité de réenregistrer.

- Fiabilité faible face aux aléas d’exécution (délais, temps de réponse applicatifs…).

Automatisation en mode modulaire cible : Plusieurs centaines de tests potentiellement évolutifs

- Exécution du code des actions avec les données enregistrées ou paramétrées.

- Facilité de création et accessibilité au code enregistré des actions et des vérifications.

- Réutilisation du code des actions et des vérifications.

- Gestion efficace des objets dynamiques

- Flexibilité du code, paramétrage des données, injection de données, pilotage par les données.

- Facilitation de la maintenance des actions, des vérifications et des données.

- Fiabilité assurée par gestion des délais et des temps de réponse applicatifs.

- Complexité de gestion accrue pour le code et les données.

cible : quelques dizaines de tests très stables

cible : plusieurs centaines de tests potentiellement évolutifs

8

3. Gestion des environnements, des données, paramétrage

▌ Les environnements applicatifs - Plateformes : PC, Mac, tablette, téléphone…

- Systèmes d’exploitation : Windows, Unix, Linux, MacOS, Androïd…

- Navigateurs internet : Chrome, Internet Explorer, Firefox, Safari…

Gestion des données - Script statique : déroulement prédéfini, utilisateur des données.

- Script dynamique : déroulement flexible, piloté par des données.

Paramétrage des scripts - Séparation des données, paramétrage des valeurs utilisées dans les actions, initialisation au début du code.

- Utilisation des jeux de données : URL de connexion, noms d’utilisateurs, mots de passe…

Un même script est exécuté avec des valeurs différentes

- Itération sur les données : tableaux de valeurs

Un même script est exécuté avec toutes les valeurs possibles

- Pilotage par les données : différents comportements selon les valeurs des données

Un même script est exécuté de manière différente suivant les données

9

4. Codage, exécution, validation, fiabilisation

▌ Codage pour l’automatisation en mode modulaire - Composants réutilisables, actions, données, vérifications.

- Indispensable quand des tests partagent des séquences identiques.

- Effort important à la création pour une structuration du code.

- Maintenance facilitée par l’efficacité au plus haut niveau des modifications de bas niveau.

4 niveaux de codage, du niveau 1 - natif au niveau 4 - test

1. Action : activation des composants de l’IHM

Clic bouton, sélection menu déroulant, entrée clavier, couper, coller, glisser, déplacer...

Vérification : comparaison entre état attendu et état effectif de l’IHM

État, couleur, position, valeur d’un champ de saisie, d’un menu, d’un bouton...

2. Opération : actions sur l’IHM + vérifications éventuelles.

Connexion = entrée d’un nom d’utilisateur, du mot de passe, activation de la connexion + vérification de connexion

Déconnexion = activation de la déconnexion + vérification de déconnexion

3. Séquence : suite d’opérations, d’actions et de vérifications.

Changement mot de passe = activation du changement + entrée ancien mot + entrée nouveau mot + validation

4. Test : suite de séquences , d’opérations, d’actions et de vérifications.

Modification mot de passe = Connexion + Changement mot de passe + Déconnexion

10

4.1.1 Codage, règles de développement

▌ Règles de codage - Langage de script automatique généralement faiblement typé, devenant confus si mal organisé !

- Règles indispensables pour la création et la maintenance du code.

– Objets nom préfixé selon le type pour identifier à première lecture son type et les méthodes applicables

en lettres minuscules + soulignement

• objet IHM : obj_button

• descripteur de propriétés : dsc_button

• nombres : i, j, k, index_row, nb_columns, total_amount

• chaines caractères (strings) : str_user, str_password

• tables : tab_flights

• structures (records) : rec_flight

• fichiers (files) : fil_products

• base de données (data base) : dba_customers

– Conséquences sur le code applicatif IHM :

• nécessité impérative d’ identifiants définis pour les objets IHM statiques et dynamiques

• pour la reconnaissance des objets à l’enregistrement des actions et des vérifications

• pour l’ utilisation des objets à l’exécution du script

11

4.1.2 Codage, règles de développement

– Méthodes nom préfixé par le type d’objet et suffixé par l’opération sur l’objet

en lettres majuscules et minuscules sans soulignement

• DepartureCityMenuSelect()

• SearchButtonActivate()

– Scripts nom du script selon une nomenclature, par exemple <code>_<type>_<priorité>_<scénario>

• fonctionnel positif priorité 1 / élevée 100_FPS_1_VoyageRéservation

• fonctionnel positif priorité 2 / moyenne 110_FPS_2_VoyageAnnulation

• fonctionnel négatif priorité 3 / faible 120_FNG_3_VoyageErroné

pour faciliter :

• l’identification des scripts par type, fonctionalité, priorité, etc…

• l’ordonnancement automatisé dans les outils de gestion des scripts

• la construction et l’exécution des campagnes de tests selon périmètre défini

▌ Nécessité des règles de codage

Complexité faible ou moyenne du code de chaque script

Volume important et en expansion du code total de tous les scripts

12

4.2 Codage, architecture et indépendance des scripts

▌ Architecture de script automatique - Un script doit être indépendant

• Ne pas dépendre du résultat d’un script précédant (exécution précédante non garantie)

• Ne pas fournir de résultats pour un script suivant (exécution courante non garantie)

- Mais pas toujours réalisable ou souhaitable, et celà augmente la complexité des campagnes

Initialisation - Prérequis, acquisition des données d’entrée des paramètres depuis tables, fichiers, base de données

- Lancement de l’application

Exécution - Déroulement des instructions d’action et de vérification

- Utilisation des valeurs initialisées et calculs intermédiaires éventuels

- Productions des données de sortie dans tables, fichiers, base de données

Conclusion - Libération des ressources, fermeture de fichiers, bases de données

- Sortie de l’application

13

4.3 Exécution, validation, fiabilisation

▌ Exécution - Sur configuration native phase de mise au point initiale

- Sur autres configurations plateformes, systèmes, navigateurs phase de mise au point finale

Validation - Identification des objets éventuellement dépendante des configurations

- Exécution des actions

- Vérification positive et négative des états éventuellement dépendante des configurations

Fiabilisation - Gestion des délais et temps de réponse avec durées fixes

- Gestion des absences des éléments IHM avec durées variables asservies aux objets

- Exécutions multiples avec divers jeux de données pour atteindre la stabilité

Performances d’exécution

- Fortement dépendantes des temps de réponse de l’application parfois décevant…

- Légèrement supérieures à celles d’un opérateur humain sans erreur, sans fatique, toujours rassurant !

14

Présentation de tests automatisés 1/5

▌ Projet SiNOP

Tests

- arborescence

- par domaine

- nomenclature

- données paramètres

- codage niveau 4

96 tests

58 tests automatisés

75 minutes d’exécution

15


▌ Projet SiNOP

Fonctions utilitaires

- arborescence

- par domaine

- nomenclature

- codage niveau 1, 2, 3

16


▌ Projet SiNOP

Objets de l’ IHM

- arborescence

créée automatiquement

par enregistrement

- classe de l’objet

- identifiant de l’objet

17


▌ Projet SiNOP

Résultat d’exécution

- test exécuté

- paramètres instanciés

- expansion du code

- statut passé / échoué

18


▌ Projet SiNOP

Campagne de tests

- synthèse de l’exécution

- graphe de statut de la campagne

- durées d’exécution des tests

- statut d’exécution des tests

19

5. Planification, évolutivité, maintenance, obsolescence

▌ Planification - Origine des tests automatiques : tests manuels automatisés / tests spécifiques d’automatisation

- Agrégation de tests simples / exécution optimisée

- Segmentation de tests complexes / compréhension et exécution faclilitées

- Cycle de vie du test automatique avec utilisation d’états : conception, prêt, maintenance, obsolète

Evolutivité - Anticipation des évolutions de l’IHM de l’application

=> La méthode modulaire est seule garante d’une gestion à coût maîtrisé

Maintenance - Sur modification de fonctionnalité dans la conception de l’IHM et dans son fonctionnement

- Préventive : notification des modifications permettant une évolution anticipée des tests

- Curative : notification déficiente des modifications induisant une évolution tardive des tests

Obsolescence - Fonctionnalité supprimée : tests inutiles pour les campagnes ultérieures.

- Fonctionnalité remaniée : maintenance plus coûteuse que la création de nouveaux tests.

20

5.1 Exemple de maintenance

Fonctionalité de connexion : utilisateur + mot de passe

Niveau 2 Opération : Connexion

entrée d’un nom d’utilisateur, du mot de passe, activation de la connexion + vérification de connexion

Niveau 4 Test : Modification mot de passe = Connexion + Changement mot de passe + Déconnexion

Fonctionalité de connexion modifiée : utilisateur + domaine + mot de passe

Niveau 2 Opération : Connexion avec séquence d’actions modifiée

entrée d’un nom d’utilisateur, du domaine, du mot de passe, activation de la connexion + vérification de connexion

Niveau 4 Test : Modification mot de passe = Connexion + Changement mot de passe + Déconnexion

- Une seule opération modifiée (Niveau 2)

- Aucun test n’est modifié (Niveau 4)

- Tous les tests utilisant cette opération bénéficient de la nouvelle version de l’opération

21

5.2 Gestion du développement des test automatiques

▌ Automatisation = développement de code !

Développement - Cycle de vie avec états des tests automatiques

- Ordonnancement du développement des tests, par type, catégorie, priorité, complexité, fonctionnalité…

Tableaux de bord

- Statut du périmètre des tests développés selon leur état.

- Progression des test développés par état.

- Analyse des états selon type, catégorie, complexité, priorité, environnement, fonctionnalité…

Indicateurs - Stabilité des scripts sur versions successives de l’application.

- Aide à la décision pour livraison des scripts permettant la construction et l’exécution des campagnes.

• Conception

• Prêt

• Maintenance script / données / environnement

• Obsolète

22

5.3 Tableau de bord de développement de tests automatiques

Progression

Statut ( jour 11 )

23

6. Campagnes de tests automatiques, statut, progrès, indicateurs

▌ Gestion des campagnes, organisation des tests, exploitation des résultats - Optimisation des diverses phases selon les ressources, consolidation progressive, décisions sur résultats

Construction des campagnes automatiques - Ordonnancement des tests, par type, catégorie, priorité, complexité, fonctionnalité…

- Périmètre réduit (vérifications préliminaires) ou périmètre total (validations complètes)

Exécution des campagnes automatiques - Allocation de machines

- Programmation des campagnes par créneaux horaires

Tableaux de bord - Statut des tests exécutés : passés, échoués, incomplets, bloqués.

- Progression des test exécutés par statut d’exécution.

- Répartition des résultats selon type, catégorie, complexité, priorité, environnement , etc…

Indicateurs - Stabilité des campagnes sur versions successives de l’application sans anomalie grave.

- Aide à la décision pour livraison de l’application IHM : accord / opposition

24

6.1 Exécution des campagnes de tests automatiques

▌ Séquencement et initialisation des phases d’exécution des tests

Sélection - Tests prêts avec scénario, données, environnements

- Périmètre testé : total ou partiel selon priorité, complexité, fonctionnalité…

- Type de test : fonctionnel positif, négatif, performance, endurance, stress, sécurité…

• Statut Non exécuté : initialisation pour l’exécution

Exclusion - Tests bloqués par anomalies non corrigées

• Statut Bloqué : initialisation excluant l’exécution - Tests temporairement inutilisables, maintenance ou fonctionnalités, données, environnements indisponibles

• Statut Non applicable : initialisation excluant l’exécution

Exécution - Lancement manuel d’une campagne de plusieurs tests

- Lancement programmé de plusieurs campagnes 24h/24

Exploitation des statuts d’exécution des tests • Statut Passé : aucune anomalie selon les vérifications définies dans le script

• Statut Echoué : anomalie détectée par une vérification définie dans le script

• Statut Incomplet : interruption imprévue hors des vérifications définies dans le script

25

6.2 Tableau de bord d’exécution de tests automatiques

Progression

Statut ( jour 2 )

26

6.3 Analyse des campagnes de tests automatiques

▌ Résultats des exécutions, analyse des anomalies et conséquences

Exécution sans anomalie

- C’est déjà un résultat !

- Certitude de bon fonctionnement du périmètre applicatif testé

- Incertitude hors du périmètre testé

=> Extension nécessaire du périmètre testé pour augmenter les probabiltés de détection d’anomalies

Exécution avec anomalies

- Des régressions ont été introduites dans le périmètre testé

- Efficacité avérée du périmètre défini pour la détection d’anomalies

- Incertitude hors du périmètre testé

=> Extension prévisionnelle du périmètre testé pour augmenter les probabiltés de détection d’anomalies

Analyse des anomalies

- Détection de non-conformités par rapport aux comportements nominaux attendus par les tests

- Validation d’une réelle anomalie de l’application

- Evolution application, données, environnement non intégrée dans les tests : maintenance curative des tests

- Evaluation d’un suivi des anomalies des tests automatiques (scripts, données, environnements) avec tableau de bord

27

7. Outils, environnements, configurations d’automatisation

▌ Quelques caractéristiques communes - Expérience sur du long terme

- Evolution permanente des capacités (plateformes, systèmes, navigateurs)

- Support technique et réactivité

- Couplage avec outils de gestion de tests et leurs diagrammes et rapports de suivi

- Forums d’utilisateurs

- Coût d’utilisation non négligeable

U.F.T + A.L.M www8.hp.com/fr/fr/software-solutions/unified-functional-automated-testing

TestComplete + QAComplete smartbear.com/product/testcomplete/overview

Quality First Software QF-Test www.qfs.de

Squish www.froglogic.com/squish

28

7.1.1 Outils et environnements d’automatisation

▌ HP U.F.T

Caractéristiques • Enregistrement des actions sur l’IHM, Reconnaissance objets IHM, Accès aux propriétés des objets • Contrôles textes, d’images, états, Synchronisation et délais • Bibliothèques de composants, Paramétrage des données, Interface Excel et bases de données • Exécution de tests en séquence, Pilotage par outil en mode 24h / 24

• Android, iOS, Windows

• Chrome, Firefox, Internet Explorer, Safari

• VBScript

Commentaires

+ intégration avec HP-ALM + gestion code et données partagées - support multi-navigateur restreint - quelques lourdeurs à l’usage

29


▌ Smartbear TestComplete Caractéristiques

• Enregistrement des actions sur l’IHM, Reconnaissance objets IHM, Accès aux propriétés des objets • Contrôles textes, d’images, états, Synchronisation et délais • Bibliothèques de composants, Paramétrage des données, Interface Excel et bases de données • Exécution de tests en séquence, Pilotage par outil en mode 24h / 24

• Desktop, Mobile, Web • Chrome, Edge, Firefox, Internet Explorer, Opera, Safari

• C++Script, C#Script, DelphiScript, Jscript, JavaScript, Python, VBScript

Commentaires

+ intégration avec QAComplete + support multi-navigateur étendu - rigueur d’utilisation requise

30


▌ Quality First Software QF-test

Caractéristiques • Enregistrement des actions sur l’IHM, Reconnaissance des objets IHM, Accès aux objets par Jython • Contrôles textes, d’images, états, Synchronisation et délais • Bibliothèques de composants, Paramétrage des données, Interface Excel et bases de données • Exécution de tests en séquence, Pilotage par commande

• Unix / Linux, Windows

• Chrome, Edge (2016), Firefox, Internet Explorer, Safari (2016)

• QF script (pour fonctions basiques) + Jython ( pour fonctions complexes)

Commentaires

+ initiation aisée mais des limitations - support multi-navigateur restreint - scripting QF + Jython peu pratique et confus

31

7.2 Configuration de la plateforme d’automatisation

▌ Poste de développement

Caractéristiques générales • Similaires aux postes de développement logiciel applicatif

• Puissance CPU pour gestion simultanée

application

outil développement de test

outil de gestion des tests

• Bi-écran pour gestion des multiples fenêtres

• application

• code de test

• arborescence et propriétés des objets IHM

• paramètres de test

▌ Machine d’exécution

Configuration classique • Minimum : postes de développement license développement utilisation nuit et week-end

• Optimum : machines d’exécution license d’exécution utilisation 24h / 24

Bonus • 2 machines / développeur de script automatique pour utilisation parallèle développement / exécution / debug

(L’exécution des scripts automatisés interdit l’utilisation clavier et pointeur sur l’IHM en cours de test)

32

8. Profils et compétences, certification ISTQB, méthodologie

▌ Automatisation de test : c’est une activité spécifique - Automatiser les tests, c’est développer du code !

- Développement “léger” spécifié dans un plan de test rigoureusement documenté.

- Complexité engendrée par le nombre des tests et leur maintien en condition opérationelle.

Profils

- « Testautomaticien » = développement 80% + fonctionnel 20%

Compétences

- Maîtrise architecture des IHM et les hiérarchies, les propriétés et les méthodes des objets.

- Codage modulaire VB, C#, Java…

Certification ISTQB

- Foundation

- Advanced / Automation

- Facultative : structurante dans les pratiques et qualifiante pour les profils.

33

8.1 Méthodologie : séquencement en 3 phases

▌ Phase 1 - Audit - Analyse de l’existant : tests manuels, campagnes de test, outils de suivi et métriques associées

- Définition de la stratégie : périmètre initial, périmètre final, priorités, calendrier, jalons

- Proposition de solution d’automatisation et outillage

- Préconisation d’architecture de la plateforme (machines d’automatisation et d’exécution)

▌ Phase 2 - Concept Probatoire (P.O.C) - Définition d’un périmètre réduit de tests significatifs

- Expérimentations des capacités, contraintes et limites des outils d’automatisation pour l’ IHM

- Paramétrage des outils, configurations, personnalisations

- Elaboration du suivi de l’activité, indicateurs, graphes, tableaux de bord, rapports…

- Evaluations en multi-navigateur, en multi-système

- Prototypes des plateformes :

• pour développement et maintenance des tests

• pour exécution des campagnes

- Validation de la stratégie, évaluation des profils requis

- Validation de la solution technique et de son suivi

34

8.2 Méthodologie

▌ Phase 3 - Industrialisation

- Installation de la plateforme (machines d’automatisation et d’exécution)

- Déploiement de la solution selon la stratégie et extension progressive au périmètre complet

- Migration de l’existant (exigences, tests, données de test, environnements de test, campagnes de tests…)

- Création progressive des nouveaux éléments de test directement dans le nouvelle solution industrialisée

- Suivi des indicateurs de progression du déploiement de la solution

- Formation des profils à la solution technique

- Accompagnement et suivi de la stratégie

35

▌ 5 projets / 10 années - Forte volonté d’automatisation du test, sans expérience ou expérience peu concluante.

- Déploiement stratégie modulaire.

- Réussite opérationnelle validée par d’intensives campagnes de non-régression.

IN7 2001

- 50 scripts / 150 tests, IHM Java, 3 systèmes X11-Unix, X11-VMS, Windows Segue SilkTest

e-Travel 2003 - 2007

- 350 scripts / 800 tests, IHM web, 1 navigateur, 3 environnements (GDS) Mercury WinRunner

Wallaby & Hotel Portal 2011

- 50 + 20 scripts / tests, IHM web, 1 navigateur HP Quick Test Pro (Q.T.P)

PlantstruXure 2011 - 2013

- 300 scripts / tests, IHM Java, 2 systèmes Windows 7, Windows 8 SmartBear TestComplete

eCommerce 2015

- 50 scripts / 300 tests, IHM web, 2 navigateurs, 3 portails, Windows HP Unified Functional Testing (U.F.T)

9. Retours d’expériences, quelques chiffres

36

Abaque effort ( jour.homme / nombre de scripts )

▌ L’effort de d’automatisation diminue avec l’augmentation de la couverture de test.

37

Abaque charge ( jour.homme / script )

▌ La charge unitaire d’automatisation diminue par capitalisation et réutilisation.

38

9. Conclusions pour l’automatisation des tests I.H.M

▌ Comment réussir l’automatisation…

Gestion de l’automatisation comme un projet, avec ses propres ressources techniques et humaines.

Sélection d’un outil approprié au contexte de l’application.

Allocation de ressources pour le développement et la maintenance des tests automatiques.

Définition des responsabilités de conception, développement, maintenance des tests automatiques.

Spécificité des profils d’automaticiens de tests différents des testeurs et des développeurs.

Utilisation de l’automatisation pour pallier les déficiences de l’exécution des tests manuels.

Définition de tests automatiques raisonnablement complexes.

Minimisation du nombre de tests automatiques défectueux (simplicité, maintenabilité).

Début de l’automatisation dès la disponibilité d’une version relativement stable de l’application.

Anticipation de la maintenance des tests pour assurer leur fiabilité et leur réutilisation.

Incapacité de l’automatisation à remplacer tous les tests manuels.

39

▌ Application I.H.M

Réservation de voyages sur internet :

- comportant de 1 à 3 éléments Avion Hôtel Voiture

- pour 3 navigateurs internet i.explorer chrome firefox

Couverture de test prévue - Tests positifs : scénarios de voyages élaborés par association de 1à 3 éléments, tous séquencements possibles.

• 3 scénarios avec 1 élément : A H V

• 6 scénarios avec 2 éléments : AH AV HV HA VA VH

• 6 scénarios avec 3 éléments : AHV AVH HVA HAV VAH VHA

- Tests négatifs : destinations invalides ou indisponibles, dates erronées, séquences de dates invalides ou indisponibles.

• 3 scénarios avec destinations : A H V

• 3 scénarios avec dates : A H V

- Totalité des scénarios sur les 3 navigateurs ie cr fx

- Couverture totale nécessite la définition de 63 tests = 21 scénarios x 3 navigateurs

Un bref exercice d’automatisation 1/3

40

▌ Stratégies de test tests manuels

- selon fréquence d’occurrence, exclusion des similarités, minimisation de la sollicitation des ressources humaines

- Tests positifs : 7 scénarios avec 1 à 3 éléments A H V AH AV HV AHV

- Tests négatifs : 6 scénarios avec destinations et dates A H V

13 scenarios sur les 3 navigateurs ie cc fx

39 tests manuels = couverture de 60 % avec capacité d’exécution = 5 tests / h durée = 8 heures / 1,0 jour début j0 / matin fin j0 / soir

63 tests manuels durée = 12 heures / 1,5 jour début j0 / matin fin j0 + 1 / midi

tests automatiques - sans a priori de fréquence, ni sur les similarités, et maximisation de l’exploitation des ressources machines

- Tests positifs : 15 scénarios avec 1 à 3 éléments A H V

AH AV HV HA VA VH

AHV AVH HVA HAV VAH VHA

- Tests négatifs : 6 scénarios avec destinations et dates A H V

21 scenarios sur les 3 navigateurs ie cr fx

63 tests automatiques = couverture de 100% avec capacité d’exécution = 5 tests / h durée = 12 heures / 1,0 nuit début j0 / soir fin j0 + 1 / matin


41


▌ Analyse de l’automatisation du test

Bilan manuel / automatique - Tests manuels couvrent une combinatoire partielle des 3 éléments pour une couverture raisonnable.

- Tests automatisés couvrent la combinatoire complète des 3 éléments pour une couverture exhaustive.

- Avec des ressources machines utilisées 24h/24.

- Supériorité de l’automatisation après l’effort de codage des scripts avec retour sur investissement avéré.

Optimisation de l’automatisation - Fusion des tests négatifs avec les destinations et dates : réduction de 6 tests à 3 tests de thèmes similaires.

- Création d’un seul script piloté par les données, instancié 15 fois pour les 15 scénarios positifs.

script_A (aéroport_départ, aéroport_arrivée, date_aller, date_retour) /* test avion par script spécifique */

script_H (ville_séjour, date_arrivée, date_départ) /* test hôtel par script spécifique */

script_V (agence_location, date_début, date_fin) /* test voiture par script spécifique */

script_G (E, lieu_départ, lieu_arrivée, date_initiale, date_finale) /* script générique de voyage */

script_G (A, aéroport_départ, aéroport_arrivée, date_aller, date_retour) / * test avion, instance du script générique */

script_G (H, ville_séjour, 0, date_arrivée, date_départ) / * test hôtel, instance du script générique */

script_G (V, agence_location, 0, date_début, date_fin) / * test voiture, instance du script générique */

F i N

jean-

[email protected]

+33 6 31 84 78 04

43

www.telecom-valley.fr

Merci de votre attention !

▌ Telecom Valley : Commission Test & Qualité Logiciel

▌ Meetup : Software Testers Club - Test et Qualité Logiciel

▌ Hub Linkedin : Test & Qualité Logiciel de Telecom Valley

http://www.telecom-valley.fr/communautes-thematiques/gt-test-qualite-logiciel/

https://www.meetup.com/fr-FR/Meetup-Software-Testers-Club-Test-et-Qualite-Logiciel/events/236116401/







https://www.linkedin.com/groups/8460876

https://www.linkedin.com/groups/8460876