modèles de fabrication

TOY Stratégie de TNR TOY
Nom Giacopelli Vincent
Date 02/04/2013
© Groupe CGI inc. CONFIDENTIEL
Sommaire
• Objectifs
• Activités TNR dans TOY
• Planning
•
•
•
•
• projet à moyen terme
• projet 2013
Environnement et organisation
Outils
Analyse de risque TOY
• Du prototype
• De la fabrication
Stratégie
• TNR sur prototype
• TNR sur générateurs
2
Objectifs
• L’objectif est de mettre en place un patrimoine de tests de non
régression pour assurer la qualité TOY des versions mineures
correctives et des versions majeures sur les périmètres suivants :
• Prototype
• Modèles de fabrications (# Générateur)
• Contexte :
• Versions majeures tous les trimestres
• Versions mineures hebdomadaires ou bi-mensuelles
• Déploiement sur des VM (1 par type de projet)
• Enjeux
• Déploiement de l’outil au niveau CGI monde
3
Activités TNR dans TOY
Conception métier avec
l’outil de prototypage
Développement des
modèles de
fabrication pour la
technologie cible
(Java, .NET, iOS,
Android, …)
+
Définition des règles
métier spécifiques
Prototype
Application
complète
TNR
Fabrication
Code généré pour la mécanique standard
(80%)
TNR
4
Modèle de
Modèle
de de
Modèle
fabrication
Modèle
fabrication
fabrication de
Modèle de
fabrication
Androiid
fabrication
Modèle de
iOS
.Net
fabrication
Java
Code
développé
(20%)
Développement
règles métier
spécifiques
Planning Projet à moyen terme
2011 Oct
TOY Product Roadmap
TOY release 1.0
(July 2012)
2012 Oct
2013 Oct
Initial release (Java environment)
V2.0 : Mobile environments (iOS + Android)
Prototyper and User Interface enhancements, Assistant
V2.1 : .NET models
V2.2 : Spring / Hibernate Java models
TOY release 2.0
(1st January 2013)
TOY release 3.0
(1st January 2014)
2014 Oct
Workflow integration
Protototype worklow processing
Prototype business organizational structures
Workflow models for external processors
TOY release 4.0
( 1st January 2015)
Rule engine integration :
Prototype advanced business rules processsing
Models for Rule server engines (JRULES, DROOLS)
Launch of TOY Center
TOY Center
Business Support
TOY Center extension
Hosting for other countries
5
Planning Version 2013
TOY
Avril 2013
Juillet 2013
Octobre 2013
2.1.0
2.2.0
2.3.0
Décembre 2013
0
Layer .Net ASP
TOY Product Roadmap
1.0.0
1.2.0
Layer .Net WPF
1.1.0
1.0.0
Layer .DLL
Layer .iOS
Layer DOC
1.3.0
1.2.0
Version majeure
Layer JPA
Layer JSF2
Layer SQL
2
1.1.0
1
1
1.4.0
2
3
1.5.0
1.4.0
6
Version mineure
Gestion des versions
Version majeure : 2.x.0 (prototype) 1.x.0 (layer)
• Fréquence : Tous les 2 ou 3 mois
• Contenu :
•
•
•
Version du prototype (évolution et correctifs)
Versions sur les générateurs déjà implémentés (évolutions et correctifs de layer)
Version 1.0.0 pour un nouveau layer
Les TNR sont à exécuter sur le prototype et sur les layer déjà implémentés
Version mineure : 2.2.x (prototype) 1.1.x (layer)
• Fréquence : Hebdomadaire ou bimensuelle
• Contenu :
•
•
Version du prototype (mais pas obligatoire, correctifs ou évolutifs)
Version sur des générateurs existants (mais pas obligatoire, correctifs et évolutifs)
 Les TNR sont à exécuter sur le prototype et/ou sur les layer
 Concentrer les évolutions et correction sur les versions majeures
 Réduire les versions mineures aux correctifs et évolutifs urgents (fréquence à
réduire ?)
 Effectuer des TNR exhaustifs sur les versions majeures. Réduire le risque de
régression sur les versions mineures.
7
Environnements et Organisation
Utilisateurs : Demande de correctifs ou
d’évolutions par ticket sous Mantis
Développement : Equipe Toy Lab
• Poste de travail Développeur
• Référentiel source hébergé sur la forge
(SVN)
Demande de
modification
Déploiement
Bug et évolution
Tests :
• Test unitaire fait sur le poste de
développement
• Tests d’intégration et de non régression à
faire sur la VM de tests (Nouveau)
Tests de non
régression
Développement
sur le Prototype
Test d’intégration
Développement
sur les
générateurs
Test unitaire
Déploiement : Equipe Toy Lab
• Serveur centralisé
• 1 VM de test
• puis 4 VM de Production (1 VM par
projet)
Utilisateurs TOY
TOY Lab
Equipe Test
8
Outils
PIC
Intégration des modules développés sur chaque PC par Hudson
Tests manuels
Outil ALM (Connect) https://quality-center.global.logica.com/qcbin/start_a.jsp
Tests automatiques :
•Jtest :
Automatisation des TU (Junit), revue de code
•Selenium : Automatisation des tests fonctionnels
•QTP :
Automatisation des tests fonctionnels, suite HPQC (connect)
Proposition d’un POC pour le choix de l’outil
Comparaison de fichier de codes sources
•JAVA: codes source java(J2EE) : Comparaison du code généré (Vn et Vn+1) par WINDIFF ou éclipse.
•.Net : se base sur plusieurs technologies (Visual studio). Comparaison du code généré (Vn et Vn+1) par WINDIFF
• ANDROID : un système d’exploitation fondé sur un noyau Linux, il comporte une interface spécifique, développement en
JAVA. Comparaison du code généré (Vn et Vn+1) par WINDIFF
•IOS : Syst. d’exploitation pour Mobile. Outil de comparaison ??
Gestion des anomalies
•Utilisation du Mantis actuel (http://toy.groupinfra.com/mantis/account_page.php)
Plateforme de tests
•VM spécifique pour les tests d’intégration, manuels, automatique, comparaison de source :
http://fr-wst-vm-0862.groupinfra.com:8080/toy/
9
Analyse de risque du prototype
Extraction des risques par WIKI Toy et du fichier « TOY Features Fonctionnalités.xlsx »
Analyse des risques faite avec la participation de J. Lacour
Critères : Fréquence et impact sur un projet
81 exigences/risques fonctionnels ont été identifiés sur le prototype, avec la répartition
suivante sur les criticités :
RISQUES PROTOTYPE
Volume
52
15
3
11
81
03-Impératif
02-Important
01-Intéressant
00-Ignoré
Total
Répartition
64%
19%
4%
14%
100%
Leur couverture nécessite 267 cas de tests (126 après réduction),
CAS DE TESTS PROTOTYPE
03-Impératif
02-Important
01-Intéressant
00-Ignoré
Total
Effort de tests
181
38
4
7
230
Effort réduit
100
18
3
1
122
Répartition
82%
15%
2%
1%
100%
Pas de contraintes techniques fortes identifiées à ce jour (performance, sécurité,
navigateur…)
Détails :
10
Analyse de risque de la fabrication
Extraction des risques par WIKI Toy et du fichier « TOY Features Fonctionnalités.xlsx »
Analyse des risques faite avec la participation de J. Lacour
Critères : Fréquence et impact sur un projet
19 exigences/risques ont été identifiés lors de la génération du code à partir du prototype,
avec la répartition suivante sur les criticités :
CAS DE TESTS GENERATEUR
Criticités différentes suivants les layers
03-Impératif
02-Important
01-Intéressant
00-Ignoré
Total
Layers impératifs
Effort de tests
9
4
6
0
19
Effort réduit
9
4
6
0
19
Autres Layers
Layer Java Jweb + JSF2 + SQL
Layer .iOS et Androïd
Layer Java Jweb + JSF2 + JPA
Layer .net WPF (Juillet 2013)
Layer .net ASP (Avril 2013)
Layer .DDL et DOC
Détails :
11
Répartition
47%
21%
32%
0%
100%
Stratégie des TNR sur Prototype (1/2)
Initialiser les TNR avec des tests manuels.
Application modèle : L’application DEMO
Version mineure: Une seule campagne de test est à prévoir (probabilité
faible de la présence d’une régression)
Objectif : Avoir une campagne de TNR restreint
• Devant se dérouler sur un délai court (0,5 ou 1 jour suivant l’impact de
la version).
• Restreinte à 15-30 cas de tests ciblés sur les risques impératifs et
ciblés sur les fonctions impactés par les évolutions/correctifs
A terme, ces tests manuels pourront être automatisés pour augmenter la
couverture des tests sans impact sur le délai de la campagne
12
Stratégie des TNR sur Prototype (2/2)
Initialiser les TNR avec des tests manuels.
Application modèle : L’application DEMO
Version majeure: 2 campagnes de test (100% puis 25%)
Couvrir l’ensemble des risques impératifs et ciblés
Effort complet
: Référentiel de 267 cdt
• 1er campagne : 8 jours de tests manuels (267 cdt)
• 2nd campagne : 2 jours (65 Cdt=25%)
Effort réduit
: Référentiel de 126 cdt
• 1er campagne : 4 jours (126 cdt)
• 2nd campagne
: 1 jour (35 cdt=25%)
 Afin de limiter le délai et la charge, nous proposons d’exclure une campagne sur
l’effort de TNR complet, et de se restreindre uniquement sur l’effort de tests réduit.
A terme, ces tests manuels pourront être automatisés pour réduire le délai de la
campagne
13
Stratégie des TNR sur Générateurs
Contrôle statique du code généré :
• Comparaison de fichier : Comparaison des exécutables de la Vn initiale
avec la Vn+1 modifiée par les développeurs
Significatif si peu de modification (cas des versions mineures)
• Code Review par des outils tels que Jtest (intégré dans la PIC)
Contrôle dynamique:
• Automatisation de scénarios de tests fonctionnels sur l’application
générée (Application DEMO)
• Java
• .net
A terme sur mobile (périmètre de l’automate ?)
• Android
• .Ios
14
POC automatisation des TNR
Choix de l’outil :
• Selenium
• Selenium est un outil libre de droit permettant d’automatiser des tests
fonctionnels et de les rejouer à l’identique.
• Retour d’expérience : Selenium est très efficace pour s’interfacer avec des
applications Web et simuler leur utilisation
• Selenium n’adresse pas les applications mobiles (émulateur sur client lourd)
• QuickTest Pro QTP
• QTP est l’automate de test de HP qui s’intègre dans la suite ALM.
• QTP propose des Addins permettant de s’interfacer facilement. Il possède ainsi
des AddIns Ajax, .Net, java, SAP, Citrix
• QTP devrait pouvoir adresser des applications mobiles (émulateur sur client
lourd)
• QTP a déjà été mis en place sur une PIC utilisant Hudson
• JTEST : Pas de retour d’expérience. Utilisé plutôt en test unitaire,
modulaire (Junit).
15
POC automatisation des TNR
Objectif du POC
A partir d’un scénario TNR de Toy :
• Confirmer la faisabilité de l’automatisation sur une même application
générée par les principaux layers
• Java
• .Net
• .iOS et Androïd
• L’estimation du coût de l’automatisation des TNR résultant prendra en
compte :
• La réalisation du socle technique
• La réalisation des scripts
• L’exécution d’une campagne V0
• Le coût de la maintenance
16
Notre engagement
Nous réalisons chaque mandat dans
un seul but : contribuer au succès
de nos clients.