Rédigé en Mars 2013
Introduction : ce que l’on va couvrir (et ne pas couvrir)
Définition : Qu’est-ce que l’automatisation des tests ?
Objectifs : Pourquoi automatiser ?
Couverture :
Qu’est-ce qu’on automatise ?
Pre et Post Process
Comment déterminer ce qu’on automatise ?
Responsabilité : Qui fait quoi?
ROI : Combien ça coute ?
Infrastructure de test
Processus d’automatisation
Conclusion
Rédigé en Mars 2013
Comment automatiser les tests ?
Les différents types de tests automatisés : TU, BDD/TDD, GUI, TDC, Test de vie …
Méthodes d’automatisation
Capture/replay
Projet de développement
Techniques d’automatisation
Data driven
Keyword driven
DSTL
Composants technique pour l’automatisation
Oracle
Bouchon
Techniques de comparaison
Reporting
Rédigé en Mars 2013
Introduction : ce que l’on va couvrir (et ne pas couvrir)
Définition : Qu’est-ce que l’automatisation des tests ?
Objectifs : Pourquoi automatiser ?
Couverture :
Qu’est-ce qu’on automatise ?
Pre et Post Process
Comment déterminer ce qu’on automatise ?
Responsabilité : Qui fait quoi?
ROI : Combien ça coute ?
Infrastructure de test
Processus d’automatisation
Conclusion
Rédigé en Mars 2013
Comment automatiser les tests ?
Les différents types de tests automatisés : TU, BDD/TDD, GUI, TDC, Test de vie …
Méthodes d’automatisation
Capture/replay
Projet de développement
Techniques d’automatisation
Data driven
Keyword driven
DSTL
Composants technique pour l’automatisation
Oracle
Bouchon
Techniques de comparaison
Reporting
JFTL2015 - Tester une application mobile de A à ZCedric GAUTIER
Test des applications mobiles
Cédric Gautier / Hien-Thuan Quach - PagesJaunes
La présentation "Test des applications mobiles" a pour but de présenter les différentes étapes pour qualifier une application mobile depuis la fin de sa phase de conception fonctionnelle (conception recette, et l’écriture des tests dans le code par l’équipe de développement) à sa mise en ligne en passant par sa validation.
Nous aborderons chacune des étapes en évoquant la stratégie (couverture des combinaisons terminaux/OS), les méthodes, les outils utilisés (dev, déploiement, supervision, sniffing) ainsi que les différents écueils déjà rencontrés et les solutions mises en place ( intégration Continue, Equipe Agile, Outillage) ou à venir ( vers un mode Continuous Delivery, Agilité, feature flipping, mise en place de train de releases)
Nous évoquerons donc le test au niveau de la phase de développement, les différentes typologies de tests (unitaires, Acceptance, fonctionnels (Manuels & Automatisés), performance, tests graphiques et ergonomie, tests 2à2, tests dos à dos, tests en extérieur), la non-régression et leur implémentation dans notre organisation.
La présentation ne se veut pas didactique mais au contraire sera réalisée sur des échanges interactifs qui permettront d'aborder les problématiques rencontrées par le public sur les applications mobiles comme le
cycle de vie d'une application (mise à jour, compatibilité, débranchement), la gestion des versions par store interne, la gestion d’un éco-système hétérogène avec de nombreux SDK externes embarqués dans le produit, le suivi de la qualité (crashlogs, audience)
La performance Back Office et applicative sera aussi évoquée ainsi que les impacts de l’application sur le terminal (Batterie, mémoire, géolocalisation) et les méthodes utilisées pour tester ces conditions aux limites. Pour finir comment gérer la mise en ligne selon les stores et les délais de validation (itération, déploiement progressif et suivi de crashes, beta-testing)
Aujourd’hui, les tests sont devenu un élément crucial au cycle de développement logiciel, des sociétés ont investi dans la création d’un service interne de tests, rien ne peut être mis en production sans être validé par ce service.
Pour cela, cette présentation va mettre en évidence les fondamentaux de test logiciel à savoir: définitions, types, processus, méthodes, outils, principes, stratégies, jeux de test, etc.
Strategie de test à agile tour bordeauxNicolas Fédou
Une stratégie de tests, on sait tous que c’est nécessaire, mais sans forcément savoir à quoi ça ressemble.
Une stratégie de tests est la façon de s’organiser pour montrer qu’une application est de qualité suffisante pour aller en production. Il ne s’agit donc pas d’un inventaire de tests manuels ou automatisés, mais d’un raisonnement avec des choix et des renoncements.
Dans cette présentation nous verrons comment une stratégie de tests vise à optimiser la confiance et les preuves de qualité dans le cadre du développement d’un produit agile.
Il s'agit d'une initiation a l'utilisation des tests unitaires
La formation présentera les éléments suivants :
•Qu’est ce qu’un test ?
•Définition
•Quelques règles
•Avantage et intérêt
•Outil de test
•Cas à tester
•Les résultats
•Test Driven Development
•Mock
•Convention nommage
•Utilisation Junit
•Conclusion
Cette formation est proposée par ISEN Dev, un projet associatif étudiant de l'association Isen Engineering.
Elle est réalisé en 2013 par SAEZ Jonathan
JFTL2015 - Tester une application mobile de A à ZCedric GAUTIER
Test des applications mobiles
Cédric Gautier / Hien-Thuan Quach - PagesJaunes
La présentation "Test des applications mobiles" a pour but de présenter les différentes étapes pour qualifier une application mobile depuis la fin de sa phase de conception fonctionnelle (conception recette, et l’écriture des tests dans le code par l’équipe de développement) à sa mise en ligne en passant par sa validation.
Nous aborderons chacune des étapes en évoquant la stratégie (couverture des combinaisons terminaux/OS), les méthodes, les outils utilisés (dev, déploiement, supervision, sniffing) ainsi que les différents écueils déjà rencontrés et les solutions mises en place ( intégration Continue, Equipe Agile, Outillage) ou à venir ( vers un mode Continuous Delivery, Agilité, feature flipping, mise en place de train de releases)
Nous évoquerons donc le test au niveau de la phase de développement, les différentes typologies de tests (unitaires, Acceptance, fonctionnels (Manuels & Automatisés), performance, tests graphiques et ergonomie, tests 2à2, tests dos à dos, tests en extérieur), la non-régression et leur implémentation dans notre organisation.
La présentation ne se veut pas didactique mais au contraire sera réalisée sur des échanges interactifs qui permettront d'aborder les problématiques rencontrées par le public sur les applications mobiles comme le
cycle de vie d'une application (mise à jour, compatibilité, débranchement), la gestion des versions par store interne, la gestion d’un éco-système hétérogène avec de nombreux SDK externes embarqués dans le produit, le suivi de la qualité (crashlogs, audience)
La performance Back Office et applicative sera aussi évoquée ainsi que les impacts de l’application sur le terminal (Batterie, mémoire, géolocalisation) et les méthodes utilisées pour tester ces conditions aux limites. Pour finir comment gérer la mise en ligne selon les stores et les délais de validation (itération, déploiement progressif et suivi de crashes, beta-testing)
Aujourd’hui, les tests sont devenu un élément crucial au cycle de développement logiciel, des sociétés ont investi dans la création d’un service interne de tests, rien ne peut être mis en production sans être validé par ce service.
Pour cela, cette présentation va mettre en évidence les fondamentaux de test logiciel à savoir: définitions, types, processus, méthodes, outils, principes, stratégies, jeux de test, etc.
Strategie de test à agile tour bordeauxNicolas Fédou
Une stratégie de tests, on sait tous que c’est nécessaire, mais sans forcément savoir à quoi ça ressemble.
Une stratégie de tests est la façon de s’organiser pour montrer qu’une application est de qualité suffisante pour aller en production. Il ne s’agit donc pas d’un inventaire de tests manuels ou automatisés, mais d’un raisonnement avec des choix et des renoncements.
Dans cette présentation nous verrons comment une stratégie de tests vise à optimiser la confiance et les preuves de qualité dans le cadre du développement d’un produit agile.
Il s'agit d'une initiation a l'utilisation des tests unitaires
La formation présentera les éléments suivants :
•Qu’est ce qu’un test ?
•Définition
•Quelques règles
•Avantage et intérêt
•Outil de test
•Cas à tester
•Les résultats
•Test Driven Development
•Mock
•Convention nommage
•Utilisation Junit
•Conclusion
Cette formation est proposée par ISEN Dev, un projet associatif étudiant de l'association Isen Engineering.
Elle est réalisé en 2013 par SAEZ Jonathan
Soyons honnête : nous aimerions tous tester nos plateformes, nos codes, mais personne ne le fait vraiment bien. Heureusement, ce n’est pas une fatalité, et il n’est jamais trop tard pour tester ! La vraie question est : comment tester ? Derrière toute stratégie de tests efficace, il y a une connaissance de tous les types de tests disponibles, de leurs coûts et de leurs utilités. Tout au long de cette journée, nous allons vous détailler les différents types de tests, du test unitaire au test de charge, afin que vous puissiez évaluer la pertinence de chacun dans votre propre contexte.
Au cours de cette session, nous plongerons avec vous dans le quotidien d’une startup qui vient de se lancer sur le Net.
Alors que les premiers utilisateurs affluent vers ses serveurs, l’équipe se retrouve confrontée à ses premiers problèmes de performance. Le prix du succès… ! Nous verrons avec eux comment simuler une arrivée massive d’utilisateurs pour “stresser” leur plateforme. Nous utiliserons les outils d’APM pour monitorer les serveurs et applications Java mais aussi évaluer l’expérience utilisateur. Enfin, nous proposerons une démarche et des outils pour tester la performance en continue.
Avec de nombreuses démos en live, cette session en français s’adresse aux développeurs, architectes et décideurs sur les projets IT.
Animé avec Landry DEFO KUATE (OCTO)
Une usine logicielle est un ensemble d’outils pré-configurés, de frameworks, de conventions, de processus, de documentations et de modèles de projets qui structurent les développeurs et leurs développements.
L’objectif est d’automatiser au maximum la production et la maintenance des applications afin d’améliorer leur qualité et le « time to market ».
Capacity Planning : Pratiques et outils pour regarder la foudre tomber sans p...Normandy JUG
Un petit tour des pratiques et outils de capacity planning. Graphite, JMX Trans, JMeter (sans frein à main), et leurs amis Amazon EC2, jenkins, VisualVM … Et en bonus la basic-web-perf application pour tester votre infrastructure à blanc !
SQLSaturday Paris 2014 - Automatisez les tests de vos développements BI grâce...GUSS
Si vous voulez accélérer le testing de votre solution BI, sans devoir coder en .Net, la meilleure méthode est l’automatisation de tests via un framework dédié. Durant cette session, nous découvrirons la puissance du framework de tests, open-source, nommé NBi (nbi.codeplex.com) aussi bien sur les databases que sur les cubes ou les etls. Les démos nous permettrons de comprendre les meilleures techniques pour vérifier rapidement et sûrement la qualité de vos développements mais aussi comprendre comment minimiser le temps de développement et de maintenance de tels tests en utilisant les richesses de ce Framework. Session présentée lors du SQLSaturday Paris 2014
Automatiser les tests des développements BI grâce à NBiCédric Charlier
Pourquoi et comment automatiser les tests d'une solution BI? Ce slide deck met en avant les possibilités diverses et variées du framework NBi et explique comment réussir son automatisation des tests.
Issue d’une expérience sur un projet transverse chez un client bancaire, cette présentation vous présentera la migration d’une application web initialement déployée sur Windows vers un Paas Openshift.
Le panel de transition des applications vers un PaaS ne se résume pas choisir entre appliquer des migrations de type Lift and Shift. Les organisations et méthodologies à adopter doivent être repensées, tout comme les architectures applicatives déployées sur ces infrastructures.
Nous présenterons au cours de cette session les évolutions réalisées sur une application web initialement déployée sur Windows, mais également les gains du passage à OpenShift qui en découlent, ainsi que les problématiques et difficultés qui ont été résolues au cours de cette transition.
Presentation du socle technique Java open source Scub FoundationStéphane Traumat
Scub Foundation est un ensemble de frameworks, de conventions, d'outils et de procédures qui structurent les développeurs et leurs développements. Pour simplifier, c'est une plateforme qui permet l'industrialisation des projets de développement informatique.
Plus d'informations à http://www.scub-foundation.org
Objectifs du socle
- Ne pas réinventer la roue ! (Intégration d'Eclipse et des frameworks populaires comme hibernate, spring, gwt, JUnit…).
- Avoir des modèles de projets pour chaque type de projet mais avec des structures identiques.
- Avoir des tâches automatisées pour l'ensemble du cycle de vie du projet (compilation, packaging, test…).
- Développement SOA (intégration de la notion de noyau et du découplage Interface/implémentation).
- Gestion automatique des dépendances / librairies.
- Gérer les différents environnements (Test / Développement / Pré production / Production…).
Concrètement, notre socle technique offre au développeur un environnement de développement intégrant les meilleurs éléments Open Source (Eclipse, Maven, Spring, GWT…) ainsi que des modèles de projet.
L’état de l’art des tests front-end
Maîtriser et fiabiliser son code sont aujourd’hui devenus incontournables pour tout développeur devant faire face à des architectures Web de plus en plus riches et complexes.
Il existe des outils pour réaliser des tests front-end d’applications Web et répondre aux besoins d’un développement de qualité.
Nous vous invitons ici à parcourir l’écosystème de ces tests front-end d’applications Web. Que vous soyez déjà convaincus par les tests ou tout simplement curieux, ce document vous guidera pour les mettre en place sur vos projets.
François PEYRET, Directeur du laboratoire GEOLOC – IFSTTARATECITSFRANCE
Journée Technique ATEC ITS FRANCE du 26 mars 2015
Mieux connaître les systèmes de navigation par satellite pour une mobilité plus intelligente
Table Ronde : Comment mieux utiliser le GNSS dans ce nouveau paradigme ?
Animée par Roger PAGNY, Chargé de mission – MEDDE/DGITM
Similaire à 20100608 2 - TNR automatisés (Generali) (20)
20130523 02 - BREDForge foundations - Gense et perspectives
20100608 2 - TNR automatisés (Generali)
1. Automatisation des TNRAutomatisation des TNR
Projet Open SourceProjet Open Source «« SquashSquash »»
Pilote GENERALI application TIGREPilote GENERALI application TIGRE
Présentation Club Qualimétrie du 8 juin 2010
Jean-Louis Vaine
2. 2 I Automatisation des TNR – Projet Open Source « Squash » du 08/06/2010V1.2
Atelier de conception des Tests : CubicTest3
Mise en place du processus d’automatisation des TNR
Référentiel de scénario et de cas de tests : TestLink2
1
Automatisation des TNR
Sommaire
Exécution des TNR fonctionnels automatisés4
Les Outils5
Projet « Squash »7
Bilan Pilote – Axes d’amélioration6
3. 3 I Automatisation des TNR – Projet Open Source « Squash » du 08/06/2010V1.2
Atelier de conception des Tests : CubicTest3
Mise en place du processus d’automatisation des TNR
Référentiel de scénario et de cas de tests : TestLink2
1
Automatisation des TNR
Exécution des TNR fonctionnels automatisés4
Les Outils5
Projet « Squash »7
Bilan Pilote – Axes d’amélioration6
4. 4 I Automatisation des TNR – Projet Open Source « Squash » du 08/06/2010V1.2
Automatisation des TNR
Mise en place du processus
d’automatisation des TNR
Processus de mise en place en 5 phases :
- Mise en place du mécanisme de
chargement des jeux de données
- Développement d’une couche d’appel
des services métiers à tester (batch)
- Création d’un mécanisme de
vérification des données en BDD
- Définition de la stratégie d’exécution
des scénarios automatisés
- Mise en place de l’architecture
technique
- Configuration des environnements de
lancement des tests
- Configuration des environnements
d’exécution du code métier (Mainframe
et distribué)
- Spécifications techniques des
scénarios à modéliser
- Modélisation des scénarios
individuels
- Exécution des TNR individuellement
- Agrégation des scénarios en suites de
tests
- Automatisation du lancement des
scénarios
- Exécution des TNR sous forme de
suites de tests
- Génération des rapports d’exécution
- Analyse des scénarios existants
- Extraction des cas de tests de non
régression
- Constitution des jeux de données à
utiliser
- Spécifications fonctionnelles des tests
(actions et résultats attendus)
- Création des scénarios
- Développement itératif des scénarios
avec validation par la MOA des résultats
Modélisation,
documentation
des scénarios et tests
unitaires des scripts
Analyse et
sélection des
cas de tests
Définition
et mise en place
d’un environnement
d’exécution maîtrisé
Adaptation des outils
et frameworks de test
au contexte
Validation, intégration
et exécution des scénarios
5. 5 I Automatisation des TNR – Projet Open Source « Squash » du 08/06/2010V1.2
Atelier de conception des Tests : CubicTest3
Mise en place du processus d’automatisation des TNR
Référentiel de scénario et de cas de tests : TestLink2
1
Automatisation des TNR
Exécution des TNR fonctionnels automatisés4
Les Outils5
2.1 - TestLink : Référentiel unique de tests
2.2 - TestLink : ses Fonctionnalités
2.3 - TestLink : ses Atouts
2.4 - TestLink : Ergonomie
Projet « Squash »7
Bilan Pilote – Axes d’amélioration6
6. 6 I Automatisation des TNR – Projet Open Source « Squash » du 08/06/2010V1.2
Automatisation des TNR
TestLink : Référentiel unique de tests
TestLink est un outil web open source équivalent de
TestDirector/Quality Center
La qualification Logicielle repose sur un processus
itératif et incrémental des phases :
Production de tests
Plan de tests
Exécution des tests
Analyse
Suivi anomalies
Métriques
Le Référentiel unique assure une meilleure visibilité et
facilite le suivi
7. 7 I Automatisation des TNR – Projet Open Source « Squash » du 08/06/2010V1.2
Automatisation des TNR
TestLink : ses Fonctionnalités
La gestion des exigences
La gestion des scénarios ou fiches de tests
La gestion des plans et campagnes de tests
La planification et le suivi des campagnes de tests
Le reporting et l’analyse de la couverture des tests
La gestion des utilisateurs de TestLink et leurs droits
d’accès
L’import et l’export des données sous des formats
divers et préformatés
8. 8 I Automatisation des TNR – Projet Open Source « Squash » du 08/06/2010V1.2
Automatisation des TNR
TestLink : ses Atouts
Constituer une bibliothèque de cas de test sous forme
hiérarchique
Réutiliser les parties de test communes
Réutiliser facilement les fiches de test grâce aux fonctions
de Drag and Drop
Lier les cas de test aux exigences
Assurer une traçabilité et un versionning des cas de tests
Générer des rapports pour le suivi d’une campagne, la
synthèse des résultats
Exporter des rapports aux formats Excel, Html et Word
-> Son application n’est pas limitée aux simples TNR mais
peut prendre en compte toutes les phases de recette
9. 9 I Automatisation des TNR – Projet Open Source « Squash » du 08/06/2010V1.2
Automatisation des TNR
TestLink : Ergonomie
10. 10 I Automatisation des TNR – Projet Open Source « Squash » du 08/06/2010V1.2
Atelier de conception des Tests : CubicTest3
Mise en place du processus d’automatisation des TNR
Référentiel de scénario et de cas de tests : TestLink2
1
Automatisation des TNR
Exécution des TNR fonctionnels automatisés4
Les Outils5
3.1 - CubicTest : ses fonctionnalités
3.2 - CubicTest : ses Atouts
3.2 - CubicTest : Ergonomie
Projet « Squash »7
Bilan Pilote – Axes d’amélioration6
11. 11 I Automatisation des TNR – Projet Open Source « Squash » du 08/06/2010V1.2
Automatisation des TNR
CubicTest : Ses fonctionnalités
CubicTest est un plug-in Eclipse de modélisation graphique
des scénarios de tests IHM
Editeur intuitif pour application web Java classiques et Ajax
Modélisation graphique des tests sous forme de graphes d'états /
transition
Organisation des tests sous forme de modules réutilisables appelés
SubTest
Construction de test simple, constitution de scénarios en chaînant
les modules (en glissant les éléments graphiques)
Génération automatique du script par Cubictest lors de l'exécution
des tests modélisés
Permet un suivi graphique de l’exécution des tests
Dispose d’un enregistreur et d’un lanceur basé sur Selenium RC
totalement intégré à l éditeur graphique
Paramétrage des états (objets de la page) et des actions utilisateurs
permettant de jouer un même test avec différents jeux de données
12. 12 I Automatisation des TNR – Projet Open Source « Squash » du 08/06/2010V1.2
Automatisation des TNR
CubicTest : Ses atouts
Élaboration de tests automatisés ne nécessite pas la connaissance
d'un langage de script : Conception entièrement graphique basée
sur les objets ou éléments graphiques présents sur l'IHM web
Modularité et réutilisabilité des modules automatisés (subtests)
Extension des fonctionnalités de Cubictest grâce au développement
de Custom Steps
Multi navigateurs : Mozilla Firefox, Internet Explorer, Opera,
Chrome, Safari
Variabilisation des cas de test grâce aux tableaux de paramètres
Debuggage facile des modules et scénarios lors de la conception,
grâce au suivi graphique d'exécution
-> Attention à gérer la cohérence de découpage entre TestLink et
Cubic
(1 cas de test = 1 module = 1 script stocké dans Subversion)
13. 13 I Automatisation des TNR – Projet Open Source « Squash » du 08/06/2010V1.2
Automatisation des TNR
CubicTest – Ergonomie
14. 14 I Automatisation des TNR – Projet Open Source « Squash » du 08/06/2010V1.2
Atelier de conception des Tests : CubicTest3
Démarche du processus d’automatisation des TNR
Référentiel de scénario et de cas de tests : TestLink2
1
Automatisation des TNR
Automatisation des TNR fonctionnels4
Les Outils5
4.1 - Gestion des Environnements et des jeux de données
4.2 - Etapes d’une campagne de tests automatisés
4.3 - Exécution des campagnes avec Subversion et Maven
4.4 - Maven – Exécution et Reporting
Projet « Squash »7
Bilan Pilote – Axes d’amélioration6
15. 15 I Automatisation des TNR – Projet Open Source « Squash » du 08/06/2010V1.2
Automatisation des TNR
Gestion des Environnements
et des jeux de données
La mise en place d’environnements de recette dédiés aux TNR
automatisés est un pré-requis indispensable
Les jeux de données de ces environnements doivent être petits,
échantillonnés, pour permettre des réinitialisations rapides
complètes ou partielles, même lors de l’exécution de scénarios
Il faut donc disposer d’outils d’échantillonnage, dans la solution
SQUASH, l’outil Open source Jailer est proposé
Generali pour son Pilote s’appuie sur son outil d’échantillonnage
Mainframe : FileAid RDS
Dans le cadre de ce pilote nous avons rencontré des difficultés coté
Mainframe car ce type d’environnement n’existe pas et est
contraire aux contraintes d’exploitabilité qui s’appuient sur des
ordonnanceurs ne permettant pas le lancement de batchs unitaires
à la demande
16. 16 I Automatisation des TNR – Projet Open Source « Squash » du 08/06/2010V1.2
Automatisation des TNR
Etapes d’une campagne
de tests automatisés
Campagne
Cas de test
2. Exécution
Pasdetest
Préparation
1. Préparation
4. Nettoyage
3. Vérification post-
exécution
Nettoyage
Reporting
Préparation de l’environnement avant la suite de test
Ex : Peuplement des tables de paramètres de la BDD
Préparation de l’environnement et mise en place des pré-conditions du
cas de test
Ex : Injection du jeu de données propre au cas de test en BDD.
Ex : Dépôt d’un fichier en entrée d’un traitement batch.
Exécution des pas de test (sollicitation du système testé, et
vérifications dynamiques associées).
Exemples d’actions :
- Saisie dans une IHM.
- Requête à un web service.
- Lancement d’un traitement batch.
Vérifications dynamiques :
- Vérification sur une IHM.
- Vérification sur la réponse d’un service web.
- Vérification du code retour d’un batch.
Dans la majorité des cas, il s’agit de vérifier les données persistées
lors du test.
Ex : Vérification de données en BDD.
Ex : Vérification d’un fichier en sortie d’un traitement batch.
Nettoyage de l’environnement suite à l’exécution de la suite de test.
Publication d’un rapport d’exécution de la campagne de tests.
Action (sollicitation
du système testé)
Vérification
dynamique
Nettoyage de l’environnement suite à l’exécution du cas de test.
Ex : Suppression des données qui ont été insérées ou modifiées
en base lors des étapes précédentes
17. 17 I Automatisation des TNR – Projet Open Source « Squash » du 08/06/2010V1.2
Automatisation des TNR
Exécution des campagnes
avec Subversion & Maven
: Téléchargement des sources (scripts, jeux de données, fichiers de configuration, classes Java non compilées,
descripteur de projet Maven) depuis le repository Subversion
: Téléchargement des bibliothèques Java utilisées par le projet de test (dépendances du projet de test,
exécutable du serveur Selenium).
: Filtrage éventuel des scripts et jeux de données (génération dynamique et injection de variables, etc.)
: Compilation des classes Java
: Exécution de la campagne
18. 18 I Automatisation des TNR – Projet Open Source « Squash » du 08/06/2010V1.2
Automatisation des TNR
Maven – Exécution et Reporting
Maven Lance Selenium Server, exécute les scripts
CubicTest et assure la Publication de rapports d’exécution
19. 19 I Automatisation des TNR – Projet Open Source « Squash » du 08/06/2010V1.2
Atelier de conception des Tests : CubicTest3
Mise en place du processus d’automatisation des TNR
Référentiel de scénario et de cas de tests : TestLink2
1
Automatisation des TNR
Exécution des TNR fonctionnels automatisés4
Les Outils5
Projet « Squash »7
5.1 - Outils : Poste de travail et Usine
5.2 - Outils : Architecture Pilote TIGRE
5.2 - CATS : IHM Lancement Batch
5.3 - CATS : Lancement Batch Mainframe
Bilan Pilote – Axes d’amélioration6
20. 20 I Automatisation des TNR – Projet Open Source « Squash » du 08/06/2010V1.2
Automatisation des TNR
Outils : Poste de travail et Usine
USINE Transverse
USINE TNR
Gestion des Anomalies
JIRA
WIKI (Documentation)
Lanceur de Batch
CATS
Référentiel de Tests
TESTLINK
Référentiel de Binaires
NEXUS
Poste de Travail
TNR ToolBox
Référentiels
Scénarios et
Cas de tests
CONFLUENCE
Echantillonnage
FILEAID RDX
FILEAID CS
Référentiel de Sources
SUBVERSION (SVN)
Scripts
versionnés
Gestion des Scripts
CUBICTEST
SUBVERSIVE
IE7, [FIREFOX]
SELENIUM Core
SOAPUI
Automatisation
MAVEN 2
xUNIT
Matrice choix Scénarios
EXCEL
Connection Mainframe
DB2 CONNECT
Socle développement
ECLIPSE
Sécurité - SSO
CROWD
21. 21 I Automatisation des TNR – Projet Open Source « Squash » du 08/06/2010V1.2
Automatisation des TNR
Outils : Architecture Pilote TIGRE
ENVIRONNEMENT DE RECETTE
Oracle 10G
Windows 2003 server
MAVEN
Eclipse
Cubic Test
Subversive
Navigateurs
I.E + IE devTb
Firefox + Trump IDE
DB2
CONNECT
Exécutable TNR
application TIGRE
Apache 2.2.10
PHP 5.2.10
Oracle Instant Client 10.0.2.4
Eclipse Navigateurs
MAVEN
DB2
Connect
FireFox
+ Trump
IDE
I.E
+ I.E dev
ToolBar
S
U
B
V
E
R
S
I
V
E
C
U
B
I
C
T
E
S
T
Svn
Nexus
Jboss 4.3.0
Webapp Cats (Service
d’accès aux données)
Station de recette
22. 22 I Automatisation des TNR – Projet Open Source « Squash » du 08/06/2010V1.2
Automatisation des TNR
CATS : IHM Lancement Batch
L’application CATS met à disposition une IHM de lancement
des batchs utilisable dans les scénarios CubicTest
23. 23 I Automatisation des TNR – Projet Open Source « Squash » du 08/06/2010V1.2
Automatisation des TNR
CATS : Lancement Batch Mainframe
Serveur
Mainframe
Serveur
J2EE
IHM de Lancement
des Batchs
Shadow / CICS
WS Lancement Batch
Service d’écoute
WS réception
résultat du batch
Service d’activation
Appel du WS
Lancement Batch
Client gestion
Des Données
Service Données
Lancement des
requêtes
Service Fichiers
Transfert
De fichiers
SQLFTP
Puit E/S
De Fichiers
Base
TIGRE
Bases externes
TIGRE
OPC
Batch
Préparation
Batch à lancer
Batch retour
résultat
Batch
TIGRE
SOAP SOAP
24. 24 I Automatisation des TNR – Projet Open Source « Squash » du 08/06/2010V1.2
Atelier de conception des Tests : CubicTest3
Mise en place du processus d’automatisation des TNR
Référentiel de scénario et de cas de tests : TestLink2
1
Automatisation des TNR
Exécution des TNR fonctionnels automatisés4
Les Outils5
Projet « Squash »7
6.1 - Axes d’amélioration 1/2
6.2 - Axes d’amélioration 2/2
6.3 - Nouvelle cible – Tests de services
Bilan Pilote – Axes d’amélioration6
25. 25 I Automatisation des TNR – Projet Open Source « Squash » du 08/06/2010V1.2
Automatisation des TNR
Axes d’amélioration 1/2
Documentation – Normes et Bonnes Pratiques :
• Tableau matrice de la terminologie entre les outils
• Normes et Bonnes pratiques de gestion des scénarios
Nommage : Applications, Fonctions, cas de tests, …
Respect même découpage TestLink (cas de tests) et Cubic (Modules)
Automatisation Maven
• Eclaircir la gestion des classes Java associées à chaque scénario, à
paramétrer pour éviter trop d’interventions MOE pour définir une
campagne
• Automatiser la création des Campagnes Maven à partir de TestLink
• Synchroniser les résultats des tests dans TestLink pour avoir une vision
globale du résultat d’une campagne de tests (Recette manuelle et
automatique)
Gestion des Environnements Distribués
• Lancement des Batchs
• Echantillonnage, adaptation et contrôles résultats Bases de données
26. 26 I Automatisation des TNR – Projet Open Source « Squash » du 08/06/2010V1.2
Automatisation des TNR
Axes d’amélioration 2/2
MainFrame
• Remplacement DB2 Connect par WebMethods (requêtes SQL DB2 et
VSAM)
• Gestion lancement des Batchs sur 2ème Mainframe (GCONS)
• Demande d’environnements spécifiques TNR
Usine et Poste de travail
• Demande de Serveurs Production pour installation des outils
• Packaging de la TNR ToolBox (Poste de travail TNR)
• Autoriser l’utilisation de FIREFOX pour rapidité exécution des
scénarios et permettre l’utilisation de SELENIUM en mode capture de
scénarios
Gestion des Anomalies
• Intégrer JIRA dans le Processus
Reprise de scénarios de tests Existant
• Etudier la possibilité d’importer des scénarios d’autres outils de Tests
27. 27 I Automatisation des TNR – Projet Open Source « Squash » du 08/06/2010V1.2
Automatisation des TNR
Nouvelle cible – Test de services
La solution actuelle s’appuie sur des tests d’IHM, nous
voulons maintenant implémenter les tests de services
Dans notre environnement de développement Java,
nous proposons l’outil Open source SOAPUI pour réaliser
ces tests de services
L’objectif est donc de faire intégrer cet outil dans la
solution Open source SQUASH, en complément de
CubicTest pour les tests IHM
28. 28 I Automatisation des TNR – Projet Open Source « Squash » du 08/06/2010V1.2
Atelier de conception des Tests : CubicTest3
Mise en place du processus d’automatisation des TNR
Référentiel de scénario et de cas de tests : TestLink2
1
Automatisation des TNR
Exécution des TNR fonctionnels automatisés4
Les Outils5
Projet « Squash »7
Bilan Pilote – Axes d’amélioration6
7.1 – Le projet Open source Squash
7.2 – Les priorités du 1er groupe de travail
29. 29 I Automatisation des TNR – Projet Open Source « Squash » du 08/06/2010V1.2
Automatisation des TNR
Le Projet Open source SQUASH
Projet Open source qui a pour objet la structuration et
l’industrialisation des activités de test logiciel :
• Techniques et fonctionnels
• S’appuyant sur des outils Open source
Fournir des modèles de fiabilité / conformité logicielle :
• Mieux piloter les activités de tests
• Améliorer la mesure de la qualité logicielle
Fournir une méthodologie de tests outillée de mise en
œuvre des activités de tests :
• Centre de service de qualification logicielle
Constituer un référentiel pédagogique et
méthodologique des métiers du test logiciel
30. 30 I Automatisation des TNR – Projet Open Source « Squash » du 08/06/2010V1.2
Automatisation des TNR
Les priorités du 1er groupe de travail
Intégrer les process d’éxécution des tests automatisés à
TestLink:
• Permettre la sélection et le lancement des campagnes
directement à partir de TestLink
• Afficher et stocker dans TestLink les résultats de ces
campagnes
Créer un lien avec le Bug Tracker, permettant la
création automatique des anomalies détectées
Encapsuler les différentes étapes techniques de la
phase d’exécution des tests automatisés :
• génération des classes Java qui vont être lancées par Maven
En proposant un niveau d’abstraction
• Fichier DSL, IHM spécifique ou intégré à TestLink, …