création d’un simulateur de charge pour le logiciel iptax · a l’ei-cesi, le projet de...
Post on 20-Jun-2020
2 Views
Preview:
TRANSCRIPT
Résumé :
Création d’un
simulateur de
charge pour le
logiciel IPTAX Sujet : Amélioration et
développement des outils de test
d’Evistel
Gilles Lefebvre EI.CESI Promotion FIFC 10-12
Evistel 7, rue de Sainte Hélène 75 013 Paris France www.evistel.com Tél : +33 (0)1 53 62 95 51 Fax : +33 (0)1 53 62 95 53 Tuteur : Omar Ait-amrane
Ei.cesi
93, boulevard de la Seine
BP 602
92 006 Nanterre Cedex
France
www.cesi.fr
Tél : +33 (0)1 55 17 80 00
Fax : +33 (0)1 55 17 80 01
Tuteur : Tahsin Evirgen
Résumé :
Ce document est un mémoire de stage de fin
d’étude effectué dans le cadre d’une formation
d’ingénieur généraliste de l’ei.CESI. Il décrit la
réalisation d’un simulateur de charge
développé dans le cadre du projet
d’amélioration des outils de tests de
l’entreprise Evistel.
Résumé :
Ce document est un mémoire de stage de fin
d’étude effectué dans le cadre d’une formation
d’ingénieur généraliste de l’ei.CESI. Il décrit la
réalisation d’un simulateur de charge
développé dans le cadre du projet
d’amélioration des outils de tests de
l’entreprise Evistel.
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 1
Table des matières Remerciements .................................................................................................................................................. 4
Avant - propos .................................................................................................................................................... 5
Introduction ....................................................................................................................................................... 6
Glossaire & Acronymes ...................................................................................................................................... 7
1. Evistel, une PME atypique .......................................................................................................................... 8
1.1 Historique de la société ....................................................................................................................... 8
1.2 L’organisation de l’entreprise ............................................................................................................. 8
1.3 Un positionnement marketing différent ............................................................................................. 9
1.3.1 Les produits ................................................................................................................................ 10
1.3.2 Les clients ................................................................................................................................... 12
1.4 Les valeurs de l’entreprise ................................................................................................................ 12
1.5 La qualité, le parent pauvre? ............................................................................................................ 13
2. Améliorer la qualité des produits ............................................................................................................. 14
2.1 Le contexte ........................................................................................................................................ 14
2.1.1 Le produit IPTAX ........................................................................................................................ 14
2.1.2 Les clients ................................................................................................................................... 15
2.1.3 Le service Intégration & support ............................................................................................... 15
2.2 La problématique .............................................................................................................................. 15
2.3 Le projet : Création d’un simulateur de charge pour le produit IPTAX ............................................ 16
2.3.1 Les objectifs ............................................................................................................................... 16
2.3.2 Les enjeux................................................................................................................................... 16
2.3.3 Les contraintes ........................................................................................................................... 17
2.3.4 Les difficultés pressenties .......................................................................................................... 17
2.3.5 Les livrables ................................................................................................................................ 17
2.3.6 Les limites du projet ................................................................................................................... 18
3. L’organisation du projet ........................................................................................................................... 19
3.1 La méthodologie utilisée ................................................................................................................... 19
3.2 La préparation du projet ................................................................................................................... 20
3.2.1 Les phases du projet .................................................................................................................. 20
3.2.2 Le WBS ....................................................................................................................................... 22
3.3 Le macro planning ............................................................................................................................. 25
3.4 L’analyse des risques initiaux ............................................................................................................ 26
3.5 Les indicateurs de suivi ..................................................................................................................... 27
3.6 Le système d’information ................................................................................................................. 29
3.6.1 Le référentiel documentaire du projet ...................................................................................... 29
3.6.2 La gestion de configuration pour le simulateur de charge ........................................................ 30
3.6.3 La communication sur le projet ................................................................................................. 30
3.7 Les moyens ........................................................................................................................................ 31
3.8 Les intervenants ................................................................................................................................ 32
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 2
3.9 Le budget prévisionnel ...................................................................................................................... 32
4. Le déroulement du projet : de la théorie à la pratique ............................................................................ 34
4.1 Une activité transversale : le management du projet ...................................................................... 34
4.1.1 Rédiger la note de clarification, le plan de management et créer le planning initial ............... 35
4.1.2 Piloter le projet .......................................................................................................................... 35
4.1.3 Gérer les réunions et rédiger les comptes rendus afférents ..................................................... 35
4.2 L’étude préalable .............................................................................................................................. 36
4.2.1 Familiarisation avec l’environnement ....................................................................................... 36
4.2.2 Formation à l’environnement technique ................................................................................... 37
4.2.3 État des lieux .............................................................................................................................. 37
4.2.4 Définition du cahier des charges ............................................................................................... 39
4.2.5 Prototypage et maquettage....................................................................................................... 40
4.2.6 Validation de la phase ................................................................................................................ 46
4.3 La phase de conception ..................................................................................................................... 47
4.3.1 Définition de l’architecture du simulateur ................................................................................ 47
4.3.2 Rédaction du plan de tests du simulateur ................................................................................. 50
4.3.3 Rédaction des spécifications fonctionnelles détaillées ............................................................. 50
4.3.4 Validation de la phase ................................................................................................................ 53
4.4 La réalisation du simulateur .............................................................................................................. 54
4.4.1 Développement ......................................................................................................................... 54
4.4.2 Passage des tests ....................................................................................................................... 54
4.4.3 Réalisation de la documentation ............................................................................................... 54
4.4.4 Recette ....................................................................................................................................... 55
4.5 La mise en œuvre .............................................................................................................................. 56
4.5.1 Déploiement .............................................................................................................................. 56
4.5.2 Formation des ingénieurs à l’outil ............................................................................................. 56
4.5.3 Le bilan provisoire du projet ...................................................................................................... 56
4.6 Exploitation et Maintenance ............................................................................................................. 58
4.6.1 Exploitation, Assistance et Maintenance corrective et évolutive ............................................. 58
4.6.2 Participation aux campagnes de tests ....................................................................................... 58
5. Conclusion ................................................................................................................................................ 60
6. Annexes .................................................................................................................................................... 61
6.1 Références ......................................................................................................................................... 61
6.2 Planning détaillé ................................................................................................................................ 62
6.3 Fiches de lot de travaux .................................................................................................................... 63
6.4 Les solutions Open sources étudiées ................................................................................................ 67
6.4.1 Les solutions logicielles .............................................................................................................. 67
6.5 Les solutions matérielles ................................................................................................................... 70
6.6 Un exemple de fiche de tests ............................................................................................................ 71
6.7 Modèle de fichier de synthèse d’une campagne de test .................................................................. 73
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 3
Liste des tableaux Tableau 1 : Liste des documents du projet ...................................................................................................... 18
Tableau 2 : Matrice des risques projet ............................................................................................................ 26
Tableau 3 : Types de documents générés par le projet et sigles associés ...................................................... 29
Tableau 4 : Liste des acteurs du projet ............................................................................................................ 32
Tableau 5 : Matrice des responsabilités (RACI) ............................................................................................... 32
Tableau 6 : Le coût du projet LOADTT ............................................................................................................. 57
Liste des figures Figure 1 : Organigramme de la société .............................................................................................................. 9
Figure 2 : Architecture de réseau GSM-GPRS .................................................................................................. 10
Figure 3 : Références des clients d’Evistel à travers le monde ........................................................................ 12
Figure 4 : Position du logiciel IPTAX dans un réseau de télécommunication .................................................. 14
Figure 5 : Structure de découpage de projet ................................................................................................... 23
Figure 6 : Structure de découpage de projet (suite) ....................................................................................... 24
Figure 7 : Le macro planning des taches du projet .......................................................................................... 25
Figure 8 : Format des Indicateurs d'avancement des tâches et livrables........................................................ 27
Figure 9 : Instantané du tableau de bord projet le 01/06/12.......................................................................... 28
Figure 10 : Architecture de l’outil de test fonctionnel initial........................................................................... 38
Figure 11 : Bête à corne du simulateur de charge ........................................................................................... 39
Figure 12 : Diagramme pieuvre du simulateur ................................................................................................ 40
Figure 13 : Analyse multicritères des outils de charge .................................................................................... 41
Figure 14 : architecture matérielle de la plate-forme de tests de charge ....................................................... 42
Figure 15 : architecture fonctionnelle du simulateur ...................................................................................... 49
Figure 16 : Modélisation de la plate-forme de tests ....................................................................................... 51
Figure 17 : Un test de charge modélisé ........................................................................................................... 52
Figure 18 : Objets génériques de l’application ................................................................................................ 52
Figure 19 : Diagramme d’état du programme ................................................................................................. 53
Figure 20 : Le simulateur LoadTT en action ..................................................................................................... 55
Figure 21 : LOADTT la configuration minimale requise pour effectuer les tests de charge ............................ 57
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 4
Remerciements Je tiens tout d’abord à remercier la société Evistel pour m’avoir accueilli au sein de ses locaux. Je tiens à
remercier plus particulièrement mon tuteur de stage Omar Ait-amrane pour m’avoir accueilli dans son
équipe et Thierry Lafue pour m’avoir proposé ce stage dans son service. Enfin je souhaite remercier toutes
les personnes qui m’ont apporté leur aide et leurs conseils durant cette période, et tout particulièrement
mes collègues :
Pablo Garcia pour son aide lors du passage des tests;
Benoît Crapart pour son esprit zen qui m’a permis de garder mon calme dans les moments difficiles;
Philippe Verdier pour sa disponibilité.
Je remercie aussi mon ingénieur formateur, Monsieur Tashin Evirgen, pour ses conseils avisés et son
soutien moral.
Enfin, je remercie l’état français pour avoir financé ma formation par l’intermédiaire du FONGECIF Île-
de-France, effort financier important que je n’aurais pu assumer seul.
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 5
Avant - propos
A l’ei-CESI, le Projet de Formation en Entreprise (PFE) a pour but de confronter les élèves en fin de
cycle de formation au métier de l’ingénieur. Pour démontrer leur capacité à tenir un poste d’ingénieur, ils
doivent trouver un stage permettant de :
S'entraîner à leur future fonction en se confrontant aux difficultés rencontrées dans leur milieu
professionnel,
Prouver leur capacité à exercer une fonction d'ingénieur en entreprise,
Mettre en pratique les connaissances, les conseils et outils méthodologiques reçus pendant la
formation,
Enfin, permettre leur réflexion et compléter leur information sur la fonction envisagée dans le cadre
de leur projet professionnel.
La durée du Projet de Formation en Entreprise de 5 mois et demi, du 16/01/2012 au 29/06/2012,
permet de se confronter à de multiples situations professionnelles. Les choix du secteur et du sujet sont
quant à eux, libres.
Pour ma part, j’ai choisi de rester dans le secteur Hi-Tech (Informatique & Télécom) où j’ai réalisé toute
ma carrière et de compléter mon expérience en intégrant une petite structure spécialisée dans l’édition de
logiciel, afin de découvrir un univers différent de celui des sociétés de service en ingénierie informatique.
Ce projet s’inscrit dans le cadre de mon projet professionnel individuel. Celui-ci se déroule en 3 phases :
Phase une, le court terme : faire reconnaître mon expérience d’ingénieur intégration
Phase deux, à moyen terme : prendre la responsabilité d’une équipe de test
Phase trois, le long terme : intégrer une société de conseil comme expert des tests logiciel
J’ai donc choisi de réaliser mon stage au sein de la société Evistel qui m’a proposé un projet consacré à
l’amélioration de leurs outils de tests. Ce projet a pour but de réaliser un simulateur de tests de charge
destiné à valider les performances du logiciel IPTAX, un logiciel de taxation des communications vers les
réseaux IP développé par l’entreprise. Ce projet me permettra d’étudier les solutions existantes du marché
en matière de tests de charge, plus particulièrement de connaître leurs tarifs, et de mettre en œuvre un
projet informatique intégralement du début à la fin, validant ainsi mes compétences en gestion de projet.
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 6
Introduction La société Evistel est une PME éditrice de logiciel de télécommunication ayant pour particularité
d’avoir des clients à travers le monde entier : Afrique, Amérique du sud, Asie et Europe. Elle développe
notamment une solution de taxation des services de communications sur réseau GSM, le logiciel IPTAX,
qu’elle a vendu à la filiale chilienne de l’opérateur de télécommunication MoviStar1. Le management de
l’entreprise a donc décidé de valider les performances théoriques du logiciel IPTAX en matière de trafic et
nombre d’utilisateurs supporté, afin de s’assurer que la qualité de la solution vendue correspond aux
attentes du client.
La société a commencé par chercher une solution permettant de réaliser des tests de charge. Une
première phase, terminée en fin d’année dernière, a consisté à réaliser une analyse du marché des outils
de tests de charge. Elle a permis au management de l’entreprise de réaliser que l’achat d’une de ces
solutions commerciales était inenvisageable, l’investissement étant prohibitif pour une PME. Le
management d’Evistel a finalement décidé de s’orienter vers une solution alternative, soit du monde Open
Source, à déterminer et à personnaliser pour s’adapter aux besoins de l’entreprise, soit un développement
interne à réaliser ou toute autre solution viable économiquement.
Mon stage consiste donc à déterminer la solution la plus adaptée aux besoins de l’entreprise et à
réaliser les développements nécessaires à la création d’un simulateur de charge, puis de réaliser les tests
de l’application afin de valider les performances du logiciel.
Ce document a donc pour objectif de présenter le déroulement de mon stage, que j’ai réalisé en me
positionnant comme ingénieur intégration. Il se découpe en cinq parties.
La première partie donnera une présentation de la société incluant un historique, quelques chiffres
essentiels, ses différents domaines d’activité et ses valeurs.
La seconde partie décrira mon projet en cernant son contexte, ses objectifs et son périmètre.
Dans la troisième partie, je présenterai l’organisation du projet et la méthodologie choisie.
Enfin, la quatrième partie sera consacrée à la mise en œuvre du projet et aux résultats obtenus.
Une conclusion viendra terminer ce document, où j’exposerai les résultats obtenus, expliquerai les
évolutions possibles du projet et je donnerai en tout dernier lieu mes conclusions personnelles.
1 Voir http://en.wikipedia.org/wiki/Movistar
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 7
Glossaire & Acronymes Cahier des charges : Document contractuel décrivant les produits attendus. DASP : DAta Service Platform. Plateforme logicielle et matérielle permettant la création d’application de
taxation.
IP Charging : Taxation du trafic des réseaux IP
Maitrise d'œuvre : Instance chargée de réaliser les travaux qui lui sont confiés par la maitrise d'ouvrage. Maitrise d'ouvrage : Instance ayant autorité pour définir ce qu’il y a à faire, charger quelqu'un de le faire et
de coordonner les travaux. Planification : Action d'ordonnancer des taches dans le temps en intégrant les contraintes et paramètres
dégagés lors de la phase d'analyse. PMP : Plan de management de projet. Document ayant pour objectif d'expliciter les choix en matière de gestion du projet Socket : Interface logicielle avec les services du système d’exploitation permettant la communication inter processus à travers un réseau TCP/IP. WBS ou SDP : Works Break-down Structure (organigramme des taches) ou Structure De Découpage du
Projet. Découpage du projet en tache afin de permettre sa réalisation. OTA configuration : Over The Air configuration. Configuration des mobiles à distance à partir réseau de
l’opérateur
DMAIC : Define Measure Analyze Improve Control. Méthodologie de résolution de problème issue du 6-σ
DMADV : Define Measure Analyze Design Verify. Méthodologie de résolution de problème issue du 6-σ
EIR : Equipment Identity Register
GSM : Global System for Mobile communication
GPRS : General Packet Radio Service
HTTP : HyperText Transfer Protocol
IP : Internet Protocol
IPTAX : Logiciel de taxation sur réseau IP
MMS : Multimedia Messaging Service
SMS : Short Message system
SMS-MO : Short Message system Mobile Originated
SMS-MT : Short Message system Mobile Terminated
SUT : System Under Test
STP : Signal Transfer Point
TCP : Transmission Control Protocol
USSD : Unstructured Supplementary Service Data
WiFi : Wireless Fidelity
WAP : Wireless Access Protocol
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 8
1. Evistel, une PME atypique Ce premier chapitre est donc consacré à l’entreprise. La
première partie retracera l’histoire de cette jeune société. La
seconde s’intéressera à son portefeuille de produits et à ses clients
introduisant ce qui fait une de ses originalités : sa grande ouverture
à l’international. Enfin nous parlerons de ses valeurs, celles qui lui
permettent de séduire de nouveaux clients tout en conservant son
parc de clients existants.
1.1 Historique de la société
La société Evistel est une société dont le cœur de métier est
l'édition de logiciels de télécommunications. Cette société française,
constituée avec des capitaux privés, dont le siège social est situé à
Paris a été créée en 2000 par une équipe d’ingénieurs évoluant dans
le secteur des télécommunications depuis plus de 15 années.
La société en quelques chiffres clés
6 : Le nombre de nationalités différentes au sein de l’entreprise
18 : Le nombre d’employés en mai 2012
19 : Les pays où l’entreprise a vendu ses solutions à des clients
2000 : L’année de sa création
3000002 : Le Capital Social en €
1.2 L’organisation de l’entreprise
Comme beaucoup de PME l’organisation adoptée, de type
entrepreneuriale ou simple3, se reflète dans l’organigramme de
l’entreprise présenté en page suivante qui révèle une structure
fonctionnelle où le service technique tient une place prépondérante.
2 Voir http://www.verif.com/societe/EVISTEL-431563105
3 Voir http://foad.refer.org/IMG/pdf/INTRODUCTION_ANALYSE_ORGANISATIONNELLE_M2.pdf p46
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 9
Figure 1 : Organigramme de la société
On notera dans cet organigramme la présence de salariés sur trois continents : l’Europe, l’Amérique du sud
et l’Afrique. C’est une des caractéristiques de l’entreprise, son ouverture à l’international. On peut aussi
remarquer les multiples rôles joués par le PDG de l’entreprise : en charge du développement commerciale
de l’entreprise et de sa gestion.
Le service Intégration et support m’accueillera en son sein durant toute la durée du projet.
Une autre des caractéristiques de l’entreprise est son positionnement marketing, que nous allons
découvrir dans le paragraphe suivant.
1.3 Un positionnement marketing différent
Le marché des télécommunications est connu grâce à plusieurs des géants le constituant :
Alcatel-Lucent, le franco-américain, 78000 employés, 15 696M€ de revenu en 2011
Huawei, le chinois, 110 000 employés, 185 176M CNY (~22 266M€) de revenu en 2010
Nokia-Siemens Networks, l’européen, 73 700 employés ,14 041M€ de revenu en 2011
respectivement numéro un, deux et trois mondial du marché des infrastructures de réseau de
télécommunication. Ces dernières années ce marché a connu une complète restructuration suite aux
fusions entre différents acteurs le composant entraînant la création d’entreprises internationales
implantées sur tous les continents. Quelle place existe-t-il pour un petit éditeur de logiciel au pays des
géants ? Intéressons-nous à ses produits, ses clients et ses valeurs pour apporter une réponse.
Source : Evistel
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 10
1.3.1 Les produits
Une infrastructure de réseau GSM-GPRS (ou 2G-2,5G) typique est donnée dans la figure ci-dessous :
Figure 2 : Architecture de réseau GSM-GPRS
Les entreprises majeures du secteur se concentrent sur les éléments clés des réseaux GSM-GPRS :
Les Base Transmission Stations et Base Station Controllers pour la partie hertzienne du réseau,
parfois appelée Radio Access Network4, gérant le signal radio et permettant la mobilité
Les Mobile Station Controller, Network Management Controller, Serving GPRS Support Node (resp
Gateway GSN) éléments majeurs du cœur de réseau permettant d’accéder aux différents réseaux
de communications Voix (PSDN ou ISDN) ou données (internet, PLMN)
Les Operational Maintenance Center(-Radio) , Human Location Ressources ,Vehicle Location
Ressources qui sont des éléments de gestion du réseau
Un certain nombre d’éléments du réseau, considérés comme mineurs, ne sont pas développés en interne
par ces grands groupes (Equipment Identity Register, SMSCenter) ou sont sujets à la concurrence de
4 Ce terme est surtout utilisé dans les réseaux 3G et 4G
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 11
petites sociétés5 développant des solutions adaptés aux besoins des opérateurs de télécommunication.
Evistel s’est positionné sur ce créneau.
L’entreprise fournit ainsi aux opérateurs de téléphonie mobile et fixe des solutions globales, évolutives,
pour une rentabilité optimale, dans les domaines suivants :
Taxation en temps réel en environnements prépayé et post-payé des services suivants : SMS-MO,
Push & Pull SMS-MT, SMS+, MMS, GPRS, WAP, IP, WiFi, ainsi que pour les voyageurs itinérants,…
Messagerie : SMSC fixe et mobile, Router SMS, intelligent STP, passerelle pour les services de
messagerie à valeur ajoutée, portails SMS & USSD,...
Gestion des terminaux mobiles : EIR, OTA configuration
Centre d’itinérance : Accès aux services du client à partir des réseaux des opérateurs étrangers
visités et offre de nouveaux services propres au réseau visité.
Supervision et anti-fraude : supervision du trafic, anti-spam, interception, anti-fraude,…
Si le positionnement marketing en matière de produit permet à Evistel d’avoir une place sur ce marché, il
se traduit aussi par des clients atypiques lui permettant de se différencier de la concurrence.
5 http://www.intersec.com/solutions/messaging-solutions_11.php ou http://www.halys.fr/fr/produits/ sont notamment des
concurrents d’Evistel
Ci-contre et ci-dessous un exemple de baie en phase de tests juste
avant livraison à un des clients de l’entreprise, l’opérateur de
téléphonie mobile irakien Asiacell (http://www.asiacell.com)
On pourra noter l’utilisation de matériel standard du marché adapté aux
besoins des clients. Cette utilisation de produits standards s’applique
aussi aux systèmes d’exploitation, logiciels et outils de développement
de l’entreprise. La généralisation de l’utilisation des logiciels Open
source se fait progressivement, la base de données postgresql
remplaçant progressivement Oracle, par exemple.
Les produits développés se caractérisent par trois qualités essentielles :
- Leur prix,
- Leur simplicité,
- Leur robustesse.
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 12
1.3.2 Les clients
Evistel vend ses solutions dans le monde entier. Ces dernières années la société a étoffé son
portefeuille de clients aussi bien en France qu’à l’étranger : Afrique, Moyen-Orient ou Asie. La plupart des
clients sont des opérateurs de téléphonie mobile et fixe créés récemment ou installés de longue date. Voici
quelques références clients localisés sur une carte du monde. Parmi les principales nous citerons :
SFR (France);
Maroc Telecom;
SONATEL (Sénégal);
Movistar chili;
Figure 3 : Références des clients d’Evistel à travers le monde
Les clients sont repartis sur la surface du globe obligeant ainsi l’entreprise à être présente sur tous les
continents afin de répondre le plus rapidement possible à leurs besoins.
Afin de répondre à ces besoins, Evistel a aussi choisi un positionnement différent au niveau de ses valeurs,
lui permettant de se démarquer de ses concurrents.
1.4 Les valeurs de l’entreprise
Pour survivre dans un monde de géants, l’entreprise a dû développer des valeurs lui permettant de
rester attractive aux yeux des clients existants et potentiels. On peut citer :
La Flexibilité : L’entreprise doit s’adapter aux besoins et exigences spécifiques de ses clients. Son
objectif est d'offrir des solutions qui répondent parfaitement à leurs souhaits et d'avoir des
solutions qui s’intègrent de manière transparente sur l'infrastructure existante.
La Réactivité : le déploiement des solutions a lieu en quelques semaines et toutes les demandes de
changement sont mises en œuvre rapidement.
Source : Evistel
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 13
La Satisfaction du client : l’entreprise considère que l'écoute et le soutien de ses clients est le cœur
de son travail. Ses solutions sont motivées par les besoins des clients qu’elle accompagne durant
tout le cycle de vie des produits. Ainsi un service de support technique mondial accessible 24
heures sur 24 et 7 jours sur 7 a été mis en place et un support personnalisé sur site est fourni, en
collaboration avec des partenaires présents dans le pays d’origine du client.
L’Innovation : l’équipe Recherche & Développement est en constante recherche de solutions de
pointe qui sont compatibles avec les dernières technologies et les normes en constante évolution.
La Qualité de service : Les solutions sont constamment testées et améliorés pour garantir leurs
performances et s’assurer de la qualité du service livré.
Une entreprise doit sans cesse trouver un équilibre entre Coût, Qualité et Délai afin de satisfaire ses
clients. Le coût et les délais sont privilégiés par Evistel, au détriment de la qualité ?
1.5 La qualité, le parent pauvre?
De toutes ces valeurs celles qui sont les plus appréciées des clients sont celles relatives à la souplesse
de l’entreprise. Mais si les coûts et les délais doivent être respectés pour garder les clients, il faut éviter de
le faire au détriment de la qualité. C’est donc dans le cadre de l’amélioration continue des outils de tests
d’Evistel et en finalité de la qualité des produits de la société que Thierry Lafue m’a proposé ce stage.
Cette première partie, traditionnellement consacrée à l’entreprise, a aussi permis de découvrir
l’architecture d’un réseau de télécommunications à la norme GSM ce qui a été utile pour présenter
les produits développés par Evistel et ainsi comprendre son positionnement. La présentation de ses
clients nous a permis d’appréhender la spécificité de l’entreprise : sa forte ouverture à
l’internationale. Enfin l’énoncé de ses valeurs a mis en avant ses forces, sa faculté à respecter les
coûts et les délais tout en introduisant sa faiblesse : la qualité.
Le chapitre suivant va cadrer le projet.
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 14
2. Améliorer la qualité des produits Ce chapitre a pour but de donner une image globale du projet. Il se découpe en trois parties
principales :
La définition du contexte : cette première partie présente les raisons qui sont à l’origine du projet
La problématique : dans un second temps la problématique et les solutions trouvées pour y
répondre sont traitées
La présentation du projet : pour conclure ce chapitre le périmètre du projet est défini, des objectifs
aux livrables.
2.1 Le contexte
Cette partie a pour objet de présenter le logiciel IPTAX qui est le produit devant être testé, puis
d’introduire les différentes causes ayant données vie à ce projet.
2.1.1 Le produit IPTAX
Le logiciel IPTAX est un logiciel de taxation des appels réalisés à partir d’un périphérique connecté à un
réseau de télécommunications et communicant vers des réseaux de données de type IP. Il a pour fonction
de générer les enregistrements permettant la facturation des clients finaux. Ces enregistrements seront
exploités par un logiciel de facturation afin de produire la facture envoyée au client. Le logiciel peut ainsi
générer les enregistrements permettant de facturer un client utilisant son téléphone portable, de type
GSM, pour accéder à l’internet. Le schéma suivant, complément utile de la figure 2, présente la position du
logiciel dans un réseau GSM-GPRS.
Figure 4 : Position du logiciel IPTAX dans un réseau de télécommunication
Source : Evistel
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 15
D’un point de vue technique, le logiciel est placé en coupure de ligne : il intercepte les appels du GGSN, les
analyse et génère les informations de facturation, puis les renvoie vers internet si le compte est crédité.
2.1.2 Les clients
Ce logiciel est notamment utilisé par la filiale chilienne de l’opérateur de télécommunication espagnole
Movistar. Les performances vendues à l’opérateur sont de 200 000 connexions simultanées.
2.1.3 Le service Intégration & support
Afin de tester les logiciels produits en interne avant livraison aux clients, le service intégration-
validation de l'entreprise utilise des outils de tests et des simulateurs pour valider leur fonctionnement. Les
outils créés pour tester IPTAX ne sont plus maintenus actuellement suite au départ de la société de
l’ingénieur en charge de leur développement. De plus les plates-formes de tests utilisées ont besoin
d'évoluer afin d'être adaptés aux besoins des ingénieurs en charge de l'exécution des tests, notamment
ceux réalisant les tests de charge.
2.2 La problématique
Pour valider la solution vendue à Movistar il est donc nécessaire d’avoir un outil simulant des
utilisateurs de mobiles générant un nombre de connexions au réseau internet suffisamment important
pour certifier les performances du logiciel : un simulateur de charge. Mais la durée de passage de ces tests
est en moyenne de quatre semaines par an. La problématique à laquelle s’est donc trouvé confronté le
management d’Evistel est d’ordre économique et technique :
Comment trouver une solution qui soit économiquement viable pour l’entreprise tout en étant
suffisamment performante pour générer la charge requise afin de valider les performances du logiciel
IPTAX ?
En effet les tests de charge nécessitent des outils performants et souvent coûteux, qu’une PME ne peut
s’offrir. Une première phase d’analyse du marché des outils de tests de charge réalisée en fin d’année 2011
a permis d’évaluer diverses solutions commerciales tel le produit IxLoad d’Ixia6. Ce produit s’il est
performant nécessite un investissement initial de plusieurs dizaines de millier d’euros impossible à réaliser.
Le management de l’entreprise a donc décidé d’évaluer d’autres solutions :
L’utilisation de solution Open source
Des développements internes à l’entreprise
Des logiciels du commerce, solutions alternatives à celles déjà étudiés
Tout autre type de solution satisfaisante d’un point de vue économique, comme la location de
matériel, par exemple
Le projet que m’a confié Thierry Lafue en début d’année a donc été de réaliser cet outil de charge afin
de valider les performances du logiciel IPTAX. LOADTT, abréviation de LOAD Test Tool, sera le nom de
l’outil développé afin de simuler du trafic réseau pour tester IPTAX.
6 Voir http://www.ixiacom.com/products/ixload/index.php
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 16
2.3 Le projet : Création d’un simulateur de charge pour le produit IPTAX
Après avoir cadré le projet lors des deux premières parties du chapitre, cette partie va terminer sa
définition en établissant son périmètre initial. Commençons par les objectifs.
2.3.1 Les objectifs
Les objectifs existent à la fois au niveau du produit à développer et du projet.
2.3.1.1 Objectifs du projet
Ces objectifs sont de différents ordres :
Techniques
Améliorer les plates-formes de tests en introduisant des outils nouveaux via des développements
interne, l’utilisation d’outils Open Source ou l’achat d’outils standard du commerce
Améliorer la qualité des logiciels développés par Evistel en participant à des compagnes de tests.
L’utilisation des nouveaux outils devra permettre de répondre aux exigences des clients relatives
aux performances du logiciel IPTAX.
Organisationnels
Référencer les logiciels du monde du libre permettant les tests de charge
Permettre à l'équipe d'intégration/validation de réaliser les tests de charge de manière autonome
Économiques
Trouver une solution économiquement viable pour la société : le coût moyen d’une solution
matérielle ou logicielle permettant de simuler un nombre illimité d’utilisateurs permettant les tests
de charge varie autour 50K€. La fréquence estimée des tests de charge étant de deux périodes de
deux semaines par an en moyenne, ce coût d’investissement est prohibitif pour une PME.
Minimiser les investissements en logiciel et matériel par l’utilisation des logiciels open source par
exemple
Humains
Former les ingénieurs d’intégration aux outils de tests open source
2.3.1.2 Objectifs du produit
Permettre les tests de charge sur le logiciel de facturation IPTAX en créant un outil suffisamment
performant pour émettre le nombre de paquets requis et simuler le nombre d’utilisateurs prévu
dans les spécifications du produit.
Être suffisamment simple pour permettre des évolutions rapides en facilitant sa prise en main et en
documentant les développements.
2.3.2 Les enjeux
Afin de conserver ses clients une entreprise a besoin d’améliorer ses logiciels, notamment leur qualité.
Un des axes d’amélioration retenu par Evistel est l’optimisation des performances des logiciels suite à des
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 17
demandes issues de plusieurs clients, principalement Movistar. L’enjeu principal est l’amélioration de la
satisfaction des clients afin de :
Conserver les clients actuels,
Gagner de nouveaux clients : pouvoir répondre aux demandes des clients potentiels en matière
de performances des logiciels est important dans un marché fortement concurrentiel comme
celui des télécommunications, les performances étant de plus en plus un critère préférentiel de
choix lors de leur sélection.
2.3.3 Les contraintes
Les contraintes à respecter sont de quatre types différents : temporels, économiques, techniques et de
performances.
Contraintes de délais
o Le projet devra être terminé le 28 Juin au plus tard.
Contraintes économiques
o Utilisation des logiciels libres si possible afin de minimiser les coûts
Contraintes techniques
o Utilisation des plates-formes matérielles et logicielles en place dans l'entreprise
o Utilisation du système d'exploitation LINUX
o Être évolutif afin d’accompagner la montée en charge des produits
Contraintes de performances
o Le simulateur de charge devra permettre :
Dans une première phase : de simuler 100 000 téléphones mobiles connectés et
70 000 communications réseau simultanées (HTTP ou autres)
À terme : de simuler 200000 utilisateurs, performance vendue à Movistar
2.3.4 Les difficultés pressenties
Les difficultés sont les suivantes :
Phase d’appropriation de l’environnement longue en raison de la perte des connaissances et du
savoir-faire suite au départ du développeur des outils de tests existants
Programmes existants insuffisamment documentés nécessitant un travail de documentation
important
Ressources matérielles insuffisantes pour réaliser des tests de charges réalistes
2.3.5 Les livrables
Ce chapitre dresse la liste des livrables attendus en fin de projet. Ces livrables sont de deux types :
documentaires et logiciels.
2.3.5.1 Les documents à fournir
La liste des documents à fournir en fin de projet est donnée dans le tableau suivant.
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 18
Document à fournir Gilles Lefebvre Format
Note de clarification X Word 2007 (.doc)
Plan de management de projet X Word 2007 (.doc)
Planning projet X MsProject (.mpp)
Étude comparative X Word 2007 (.doc)
Benchmark des solutions Open Source retenues
X Word 2007 (.doc)
Présentation technique X PowerPoint(.ppt)
Cahier des charges fonctionnel du simulateur
X Word 2007 (.doc)
Document d’architecture X Word 2007 (.doc)
Manuel d’utilisation du simulateur
X Word 2007 (.doc)
Présentation du simulateur X Word 2007 (.doc)
Résultats des campagnes de tests
X Word 2007 (.doc)
Tableau 1 : Liste des documents du projet
2.3.5.2 Les logiciels à réaliser
Outre les documents, divers logiciels seront à rendre en fin de projet :
Le prototype qui aura servi à valider les solutions évalués
Le simulateur qui servira pour les tests de charge du logiciel IPTAX
Enfin, une formation à l’outil développé devra être réalisée durant le stage afin de permettre son
utilisation par le personnel d’Evistel et transférer les compétences acquises pendant le PFE en matière de
tests de charge.
2.3.6 Les limites du projet
La maintenance du simulateur ne sera pas prise en compte au-delà de la date butoir du 29 juin
2012.
Les anomalies de fonctionnement du simulateur seront référencées hors du système de gestion des
anomalies de l’entreprise.
La période de maintenance corrective se terminera le 22 Juin 2012 afin de pouvoir valider les
corrections entreprises jusqu'à cette date. Les anomalies constatées ultérieurement à cette date
seront uniquement référencées pour traitement par la MOA.
Toute cette partie consacrée au projet s’est traduite concrètement par la rédaction d’un Plan de
Management de Projet, outil indispensable à la gestion d’un projet. Réalisé en tout début de stage il
m’a permis de structurer le projet et a constitué un fil rouge durant toute sa durée. Le PMP contient
aussi les différentes phases du projet, qui correspondent à une démarche pour aboutir à un
résultat : la réalisation du simulateur de charge.
Je vais maintenant expliquer la démarche suivie pour réaliser le projet.
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 19
3. L’organisation du projet Ce troisième chapitre est consacré à l’organisation du projet. En tout premier lieu est présentée la
méthodologie utilisée pour le réaliser. Puis, dans une seconde partie, les phases découlant des choix
méthodologiques seront exposés, débouchant sur le macro planning. La quatrième partie sera dédiée à
l’analyse des risques relatifs au projet. En dernier lieu, les indicateurs du projet, outils permettant de suivre
l’avancement de celui-ci, seront décrits.
3.1 La méthodologie utilisée
Dans le monde industriel plusieurs méthodologies existantes permettent de mettre en œuvre des
projets. La méthode 6-Sigma propose ainsi deux méthodologies adaptées à différents types de projets :
DMAIC : pour les processus existants défectueux
DMADV : pour développer un nouveau produit ou service
Le PDCA, rendu populaire par Edwards Deming, est une démarche qui est souvent utilisé par les
services qualités pour résoudre les problèmes dans le cadre de l’amélioration continue d’un service ou
d’un processus.
L’industrie du logiciel, bien que récente, dispose aussi de ses propres méthodes, développées au cours
de ses trente dernières années. Le génie logiciel propose plusieurs modèles de cycle de vie du logiciel :
linéaire, non linéaire, incrémentaux, méthodes agiles, etc... J’ai choisi de mettre en œuvre un cycle de
développement hybride combinant le cycle de vie en V du logiciel, qui permet des phases de
recouvrement permettant les retours sur une phase et des tests à chaque phases, et une phase initiale de
prototypage permettant de m’assurer de la faisabilité du projet et de mieux cerner les besoins des
ingénieurs en charge des tests.
Le Prototype est une version d'essai du logiciel réalisé pour tester les différents concepts et exigences
et montrer au client les fonctions que l'on veut mettre en œuvre. Lorsque le client a donné son accord, le
développement suit un cycle de vie en V. Le principal avantage est que les efforts consacrés au
développement d'un prototype sont le plus souvent compensées par ceux gagnés à ne pas développer de
fonctions inutiles.
Le cycle de vie du logiciel propose 6 phases principales7 pour distinguer les différentes étapes de
développements.
Analyse-étude préalable : Analyse de l’existant, définition des besoins du système d’information
et du logiciel sont les principales actions de cette phase
Conception : La conception du Système d’information et du logiciel sont mises en œuvre
Réalisation : Le codage consiste à traduire les algorithmes précédemment définis en un
programme compréhensible par l’ordinateur
Tests : Vérification du bon fonctionnement du programme
Exploitation : Utilisation du logiciel installé
Maintenance : La correction des erreurs trouvées et l’amélioration des fonctions existantes
sont réalisées durant cette phase.
7 Voir Reference [4] en annexe 6.1
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 20
Le génie logiciel propose aussi des phases et des documents standards pour la réalisation d’un logiciel
définissant le cycle de vie du logiciel. J’ai donc utilisé ces phases et documents que j’ai adaptés au projet
qui m’était confié. Les Livrables sont issus des demandes initiales de Thierry Lafue et Omar Ait-amrane et
des exigences projets. Les jalons correspondent soit à des demandes du management d’Evistel, soit à des
dates butoirs permettant la réalisation du projet dans son intégralité.
La partie suivante est consacrée à l’analyse des phases du projet et présente la structure de découpage du
projet qui en résulte.
3.2 La préparation du projet
Le cycle de vie du logiciel choisi entraîne ainsi le découpage en phase suivant.
3.2.1 Les phases du projet
Expliquons brièvement les tâches et activités liés à chaque phase avant de présenter le WBS qui en résulte
1-Étude préalable : Cette phase permet d’étudier l’environnement du projet afin de vérifier sa faisabilité et
de se former aux produits existant ainsi qu’aux méthodes de travail de l’entreprise.
1.1 Recueil de l'existant – État des lieux
1.1.1 Familiarisation avec l’organisation : Étape de prise en compte de l’environnement du projet :
humain, matériel, organisationnel.
1.1.2 Formation à l’environnement technique : Formation aux outils existants et à l’environnement
de tests (plate-forme, fiches de tests, stratégie de tests)
1.1.3 État des lieux : Réalisation d’un document décrivant l’état des outils de simulation sur la
plate-forme de tests.
1.2 Définition du cahier des charges : Cette étape permet de définir les besoins du client.
1.2.1 Recueil des besoins : Cette étape permet de recueillir les besoins des acteurs du projet en
matière de
1.2.2 Rédaction du cahier des charges : Cette étape consiste à formaliser les besoins recueillis dans
l’étape d’interview afin de créer un document initial de travail.
1.2.3 Mise à jour : Cette activité consiste à mettre à jour le CDC en fonction des retours de la MOA
afin de satisfaire à ses besoins
1.3 Prototypage et Maquettage : Cette phase permet d’explorer des solutions techniques variées et de
valider ces choix.
Amélioration des outils de tests
Création d'un simulateur de charge
1-Étude préalable 2-Conception 3-Réalisation 4- Mise en œuvre 5-Exploitation 6-Management de
projet
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 21
1.3.1 Prototypage : Réalisation d’un simulateur fonctionnant avec des fonctionnalités réduites afin
de valider les choix techniques. Cette étape a débuté en même temps que l’étape 1.1.2 à des fins
de formation à l’environnement. Cette étape recense les outils de tests de charge existants du
marché et comprend le benchmark des solutions.
1.3.2 Maquettage : Cette étape (optionnelle) permet d’avoir une idée de l’IHM du simulateur.
1.4 Validation de la phase : Cette étape s’effectue avec le responsable R&D et le directeur technique
afin de valider les choix techniques et décider du passage à la phase suivante.
2-Conception : Cette phase permet de définir l’architecture technique du simulateur
2.1 Conception générale : Cette étape permet de concevoir théoriquement le simulateur
2.1.1 Définition de l’architecture du simulateur : On s’occupe dans cette étape de l’architecture du
simulateur. On définit par exemple les besoins en équipements (éléments de réseaux, ordinateurs,
cartes de communication, câblage,..) et en logiciel (Base de données, système d’exploitation,
langage de programmation, outils de développement, Gestion de configuration) ainsi que
l’organisation de celui-ci. Les paquetages sont, par exemple, définit dans cette phase.
2.1.2 Rédaction du plan de tests : Il permet la validation du logiciel
2.2 Conception détaillée : Cette étape permet de détailler les procédures, fonctions, objets, packages
nécessaire à la réalisation du simulateur
2.2.1 Spécifications détaillées des paquetages : la description détaillée des paquetages du
simulateur, en vue de sa réalisation
2.2.2 Définition de l’IHM : Les écrans, leurs enchaînements et l’ergonomie du logiciel seront
définies dans cette partie.
2.3 Validation de la phase : Cette étape permet la validation des choix réalisés et permettra de débuter
la phase de réalisation.
3-Réalisation : Cette phase consiste à réaliser le simulateur
3.1 Développement : Codage
3.2 Tests : Cette étape permet de valider le simulateur
3.3 Documentation : Rédaction des divers documents constituant le simulateur
3.3.1 Rédaction du manuel utilisateur : Document permettant la prise en main du logiciel
3.3.2 Rédaction faq : Document répondant à des questions d’ordre générale permettant de faciliter
l’assistance technique
3.3.3 Rédaction HowTo : Document de prise en main rapide du simulateur
3.4 Recette : Cette étape valide le produit
4-Mise en œuvre : Cette phase permet de mettre à disposition le simulateur aux utilisateurs.
4.1 Déploiement du logiciel : Cette étape peut être réduite à une installation sur les PC de la plate-
forme de tests.
4.2 Formations des ingénieurs à l’outil : Cette étape permet la formation des ingénieurs à l’outil de
simulation.
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 22
4.2.1 Création d’un document de formation : Cette étape permet de laisser des documents
permettant une prise en main rapide de l’outil.
4.2.2 Session de formation : Elle dure une journée et sera constituée d’une session théorique et
d’une session pratique afin de prendre en main le simulateur.
4.3 Bilan de fin de projet : Cette étape permet, d’une part, de comparer les dispositions initialement
prévues avec le déroulement réel du projet et, d’autre part, de porter un regard critique sur tous les
aspects du projet pour en tirer des voies d’amélioration pour les futurs projets.
5-Exploitation et Maintenance : Cette phase démarre dès la formation des ingénieurs d’intégration et s’effectue en parallèle avec l’étape de participation aux campagnes de tests. Elle a pour but d’apporter un support technique aux utilisateurs.
5.1 Assistance technique : Cette activité se traduit par une assistance aux utilisateurs afin de les
accompagner dans leur utilisation quotidienne et de répondre à leurs questions
5.2 Maintenance corrective et évolutive : Elle permet de réaliser des corrections d’anomalies dans
l’outil après sa mise en œuvre et de recenser les demandes d’évolutions de la part des utilisateurs. Ne
seront traités que les évolutions mineures pouvant être développées avant la fin du projet.
5.3 Participation aux campagnes de tests : Cette étape permet les tests de l’application IPTAX.
6-Management de projet : Cette phase se déroule pendant toute la durée du projet et elle est constituée
d’activités récurrentes ou de tâches servant à l’initialiser comme l’écriture du PMP.
6.1 Rédaction du PMP et des documents Projets : Ce document contractuel de communication servira
de référence durant le pilotage du Projet. Il permet de structurer, d'assurer et d'optimiser le bon
déroulement du Projet. Il est rédigé par le chef de Projet et validé par la Maîtrise d'Ouvrage. Il est diffusé à
l'ensemble des acteurs du Projet pour que tous aient le même niveau d'information. Ce document pourra
subir des réajustements et des modifications en fonction des aléas rencontrés pendant la durée du projet.
Tout changement et remaniement du document doit être réalisé par le Chef de projet. Une fois les mises à
jour effectuées, il est impératif de faire valider celui-ci par la Maîtrise d'Ouvrage et de communiquer les
éventuels changements à l'ensemble de l'équipe Projet. Une note de clarification sera rédigée au tout
début du projet.
6.2 Planification : Cette activité permet de PRÉVOIR un programme d’action en début de projet puis de
CONTRÔLER le déroulement de celui-ci, d'ADAPTER le plan aux nouvelles exigences enfin de DÉCIDER en
continu, jusqu’à la fin du projet.
6.3 Pilotage du projet : Le pilotage de projet permet de valider le bon déroulement du projet. Il est
effectué par le responsable de projet et il est réalisé durant toute la durée du projet.
6.4 Réunions et comptes rendus : Ils permettent de communiquer avec la MOA
6.4.1 Réunions d’avancement projet : permettant le suivi du projet par la MOA
6.4.2 Réunions techniques ponctuelles : Cette activité permet la validation des choix techniques
effectués.
6.4.3 Rédaction des comptes rendus : Permettant de communiquer avec la MOA et de tracer les
événements durant la vie du projet.
3.2.2 Le WBS
Le WBS, résultant du découpage en tâche précédent, est donné dans les figures suivantes. Il est aussi
un des points d’entrées du macro planning donné dans la partie suivante.
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 23
Figure 5 : Structure de découpage de projet
Amélioration des outils de tests
1-Étude préalable
1.1 Recueil de l'existant – État
des lieux
1.1.1 Familiarisation
avec l’organisation
1.1.2 Formation à l'
environnement technique
1.1.3 État des lieux
1.2 Définition du cahier des
charges
1.2.1 Recueil des besoins
1.2.2 Rédaction du cahier des
charges
1.2.3 Suivi du CDC
1.3 Prototypage et Maquettage
1.3.1 Prototypage
1.3.2 Maquettage
1.4 Validation de la phase
2-Conception
2.1 Conception générale
2.1.1 Définition de l’architecture du
simulateur
2.2.2 Rédaction du plan de tests
2.2 Conception détaillée
2.2.1 Spécifications détaillées des paquetages
2.2.2 Définition de IHM
2.3 Validation de la phase - Présentation
3-Réalisation
3.1 Développement
3.2 Tests
3.3 Documentation
3.4 Recette
4- Mise en œuvre
4.1 Déploiement
4.2 Formations des ingénieurs à
l’outil
4.3 Bilan projet
5-Exploitation
5.1 Assistance
5.2 Maintenance corrective et
évolutive
5.3 Participation
aux campagnes de tests
6-Management de projet
6.1 Rédaction du PMP
6.2 Planification
6.3 Pilotage du projet
6.4 Réunions et comptes rendus
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 24
Figure 6 : Structure de découpage de projet (suite)
3.3 Documentation
3.3.1 Rédaction du manuel utilisateur
3.3.2 Rédaction faq 3.3.3 Rédaction HowTo
4.2 Formations des
ingénieurs à l’outil
4.2.1 Création d’un document de formation
4.2.2 Session de formation
6.4 Réunions et comptes rendus
6.4.1 Réunions d’avancement projet
6.4.2 Réunions techniques ponctuelles
6.4.3 Rédaction des CR
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 25
3.3 Le macro planning
Figure 7 : Le macro planning des taches du projet
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 26
3.4 L’analyse des risques initiaux
Les différents risques ainsi que les actions prévues pour les prévenir ou les corriger sont définis dans le
tableau suivant.
N° Description du Risque Proba bilité
Gravité Criticité Actions Préventives / Actions correctives
1 Cahier des charges fonctionnel du simulateur de charge mal défini
4 2 8 - Revue du cahier des charges - Développement incrémental si nécessaire
2 Mauvaise compréhension du problème
2 4 8 - Rencontre d'utilisateurs - Réunions techniques
3 Perfectionnisme 4 3 12 - Examen critique des spécifications - Maquettage - Analyse de la valeur (enjeux des fonctions)
4 Ajout de spécifications durant le projet
4 2 8 - Seuil d'acceptation des changements - Développement incrémental, gestion de lots - Report des modifications en fin de projet, gestion de versions
5 Simulateur inadapté aux besoins de la MOA
2 4 8
- Rédaction anticipée des tests de recette
6 Complexité du problème mal estimée entraînant un dépassement des délais
3 4 12 - Suivi hebdomadaire de l'avancement - Remise en cause des demandes - Développement incrémental - Réutilisation de code existant
7 Disponibilité réduite des ressources matérielles car en nombre limitée et partagées entre les différentes équipes. exemple : plate-forme de tests.
3 4 12 - Planning d’utilisation des plates-formes - Respect des délais
8 Disponibilité des ingénieurs
3 4 12 - Anticipation des problèmes - Auto formation
Tableau 2 : Matrice des risques projet
C= Px G avec P, G et C définis dans les tableaux ci-après.
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 27
NIVEAU DE CRITICITÉ (C)
C <10 Risques mineurs – Acceptables Management du projet
10 <= C <=12 Risques majeurs – Sous surveillance Plan d’action suivi régulièrement
15 <= C <=16 Risques critiques – Action d'urgence à mettre en œuvre
Communication au client Plan d’action suivi à la semaine
C >=20 Risques Inacceptables – Actions Préventives
Arrêt du projet Communication au client Renforcement de l’équipe et/ou des compétences Plan d’action suivi à la semaine ou à la journée
3.5 Les indicateurs de suivi
Pour assurer le suivi de projet, il est nécessaire de piloter l’ensemble des tâches dans le temps et de
pouvoir les suivre en temps réel. Il faut donc mettre en place des indicateurs de suivis pertinents pour le
projet. Les indicateurs retenus sont les suivant :
Indicateur de suivi des tâches : Il permet de suivre l’état d’avancement de chaque tâche.
Indicateur de suivi des livrables : Il permet de connaître le statut d’un livrable (non commencé, en
création, …)
Ces indicateurs prendront la forme d’un diagramme en bâton :
Figure 8 : Format des Indicateurs d'avancement des tâches et livrables
0%10%20%30%40%50%60%70%80%90%
100%
Tâche 1 Tâche 2 Tâche 3 Tâche 4
% Restant à faire
% Réalisé
PROBABILITÉ (P)
1 Impossible ou improbable
2 très peu probable
3 Peu probable Décennie
4 probable Annuelle, semestrielle
5 Très probable à certain mensuelle, hebdomadaire, quotidien
GRAVITÉ (G)
1 Détail
2 Alerte
3 Mineur
4 Majeur
5 Critique
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 28
Afin de simplifier la gestion de projet les taches ont été regroupées en lots8 qui servent essentiellement au
suivi de projet. Les indicateurs de réalisation des lots synthétisant l’avancement du projet sont regroupés
dans une feuille Excel qui fera office de tableau de bord du projet. Un exemple du tableau de bord est
donné ci-dessous.
Figure 9 : Instantané du tableau de bord projet le 01/06/12
8 Voir annexe 6.2 pour une description des lots de travaux
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 29
3.6 Le système d’information
Le système d’information permet de faciliter la communication sur le projet. Celui mis en œuvre sur le
projet concerne la communication écrite et orale et formalise le format des documents, des réunions et
des échanges d’informations.
3.6.1 Le référentiel documentaire du projet
Les règles de nommage choisies pour les documents générées pendant la durée du projet sont les
suivantes :
<Nom_Document>_AméliorationOutilsDeTestsEvistel_Ed<xx>_Pr<yy>.<ext>
Avec :
NOM_DOCUMENT : Sigle représentant le type du document
Sigle Type de Document BEN Benchmark
CR Compte Rendu de réunion
CDC Cahier des charges
DCG Dossier de conception générale
DCD Dossier de conception détaillée
NDC Note de clarification
PMP Plan de Management de projet
DDT Dossier de tests
MU Manuel Utilisateur
PRES Présentation
FAQ Frequently Asked Questions
SYN Synthèse
PLAN Planning
HOWTO Livre de recette
DOC Documents divers
Tableau 3 : Types de documents générés par le projet et sigles associés
Edxx : Version majeure du document. Ce nombre correspond à une version validée par
l’approbateur du document.
[Pr]yy : Version mineur du document. Ce nombre correspond à une version de travail dans
l’édition courante n’ayant pas encore été approuvée (Pryy) ou à une version mineure.
ext : Le type du fichier (.pdf, .doc, .docx, .xls, .ppt, …)
Les fichiers Word sont au format Word 2007 pour pouvoir être utilisés avec open office.
Une charte graphique sera utilisée tout au long du projet, un modèle de référence servant de base aux
divers documents générés. Ce fichier suit par conséquent la charte graphique.
Pour les fichiers Word, on utilisera une page de garde constitué des deux cadres suivants pour mettre en
évidences les différents ajouts et les corrections apportées.
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 30
Le cadre gestion des évolutions
Gestion des évolutions
Mise à jour Prénom Nom jj/mm/aa EdXXPrYY
Document initial Gilles Lefebvre 20/01/12 Ed01Pr01
Historique Nom Date Révisions
Le cadre des responsabilités
3.6.2 La gestion de configuration pour le simulateur de charge
Un logiciel de gestion de configuration est prévu sur le projet afin de faciliter le référencement et le
suivi des versions des livrables. Le logiciel utilisé est CVS.
3.6.3 La communication sur le projet
Pour assurer une bonne communication entre les différents acteurs du projet il est nécessaire de
mettre en place des étapes de communication planifiées, efficaces et adaptées au contexte. Dans cette
partie, il est fait mention de l'ensemble des moyens et techniques (réunions diverses, système
d’information) qui sont mise en place afin de communiquer à tous les membres de l'équipe projet l'état
d'avancement des différentes phases et étapes de celui-ci.
3.6.3.1 La liste des intervenants
La liste des intervenants est la même que celle des acteurs à laquelle on peut rajouter des ingénieurs
d’intégration ou des chefs de projets en fonction des besoins ou des problèmes rencontrés.
3.6.3.2 Les réunions
Durant le Projet un certain nombre de réunions sont organisées. La nature de ces réunions varie
suivant leurs objectifs, on peut néanmoins citer les réunions suivantes :
Les réunions de recadrage : Prévues en fin de phase elles permettent de gérer les écarts entre
prévu et réalisé.
Les réunions bimensuelles : ces réunions sont des outils de coordination entre les différents acteurs
du Projet. Leur rôle est d'informer les membres du Projet sur le déroulement de celui-ci, d'échanger
les connaissances donc de favoriser l'expertise et de critiquer certaines démarches ou solutions
Rédacteur Approbation Autorisation de diffusion
Nom Gilles Lefebvre Omar Ait-amrane Thierry Lafue Responsabilité Responsable de projet Responsable R&D Directeur Technique Date 20/01/12 20/02/12 20/02/12 Visa
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 31
pour donner une nouvelle orientation, enfin de mettre en place des axes d'amélioration. Ces
réunions auront une durée de 30 minutes maximum.
Réunions contractuels avec le CESI : ces réunions influent sur le cours du projet et son calendrier et
sont données ci-après :
Mardi 6 mars 2012 1er retour obligatoire en centre pour une présentation PowerPoint de l’élève ingénieur sur son stage
Lundi 14 mai 2012 2ième retour obligatoire en centre pour une présentation Powerpoint version 1 de la soutenance orale finale
Entre le lundi 11 juin et le vendredi 15 juin 2012
Prévoir 2 demi-journées pour les soutenances blanches
Mercredi 20 juin 2012 Soutenances Vendredi 29 juin 2012 AM Réunion de bilan de la formation à Nanterre
3.6.3.3 Les échanges d’informations
L’échange des informations entre les différents acteurs du projet se fait par mails afin de laisser des
traces perdurables.
Les réunions font l’objet de comptes rendus diffusés aux acteurs du projet auxquels on rajoute les
intervenants ponctuels nécessaires à l’avancement du projet.
Les livrables sont diffusés et stockés sur les espaces partagés mis à disposition pour le projet par
Evistel. Des sauvegardes périodiques sont réalisées pour archivage.
3.7 Les moyens
Les moyens mis à ma disposition pendant la durée du projet ont été de deux types : matériels et
humains. J’ai disposé d’un bureau, d’un ordinateur et d’un accès à l’internet pour réaliser le projet. J’ai
aussi eu accès aux ressources suivantes :
à la messagerie de l’entreprise pour communiquer avec les sociétés extérieures
à la documentation relative aux produits développés par Evistel
aux équipements de la plate-forme de tests afin d’installer les logiciels et les outils développés et
tester les produits Evistel
Outre les moyens matériels, j’ai aussi eu besoin d’aide et de support de la part des ingénieurs d’Evistel
pour réaliser le projet.
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 32
3.8 Les intervenants
Pour terminer cette phase de préparation du projet je vais citer les principaux intervenants du projet et
donner leurs rôles respectifs dans les deux tableaux suivants:
Nom Fonction E-mail Téléphone
Gilles Lefebvre Responsable du projet
gilles.lefebvre@evistel.com 01 53 62 40 69
Philippe Verdier Ingénieur responsable du produit IPTAX
philippe.verdier@evistel.com
Omar Ait-amrane responsable R&D omar.aitamrane@evistel.com
Thierry Lafue Directeur technique thierry.lafue@evistel.com
Tableau 4 : Liste des acteurs du projet
Acteurs
Phases / Tâches
Responsable de projet
Gilles Lefebvre
Ingénieur responsable du produit IPTAX
Philippe Verdier
Responsable R&D
Omar Ait-amrane
Directeur technique
Thierry Lafue
1 R C A I
2 R C A I
3 R A I
4 R A I
5 R A I
6 R A I
Tableau 5 : Matrice des responsabilités (RACI)
Liste des responsabilités associées aux phases du projet :
R : Responsible
A : Accountable
C : Consulted
I : Informed J’ai eu besoin des connaissances techniques de Philippe Verdier pour comprendre le logiciel IPTAX et
pour passer les tests, et de celles plus organisationnelles de Thierry Lafue et Omar Ait-amrane pour la
partie gestion de projet afin de de valider mes décisions.
Ce chapitre va se clore sur le budget alloué au projet.
3.9 Le budget prévisionnel
Aucun budget initial n’avait été prévu à l’origine par l’entreprise pour l’achat de logiciel ou de matériel.
Néanmoins un ordinateur DELL Précision T3500 d’une valeur de 750€ HT (897 € TTC) suffisamment
puissant pour tester le logiciel IPTAX a été acheté pour les besoins du projet.
En outre, hormis le recours à un stagiaire pour réaliser le projet, seules les ressources humaines
précédemment cités, ont été utilisé pour le calcul. Le projet est chiffré en « charge de travail » et non en
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 33
«coût» dans cette partie du projet. Concrètement, la charge de travail comptabilise l’estimation des heures
de main-d’œuvre sur les ressources utilisées pour la réalisation du projet. Le nombre d’heures estimé est
directement issu des jours prévus dans le planning détaillé donné en annexe.
Acteurs Type de l’inducteur de coût Quantité de travail en jour (h)
Gilles Lefebvre Pilotage du projet, actions à réaliser, réunions
115 (805)
Omar Ait-Amrane Réunions, Relecture de documents 1 (7)
Thierry Lafue Réunions, Relecture de documents 2 (14)
Philippe Verdier Formation, Réunion, Tests, Relecture 4 (28)
Total (h) 122 (854) Une journée de travail équivaut à 7 heures travaillés
Les trois premières parties ont présentés l’entreprise, le projet, et son organisation théorique. Avant de passer à la suivante, plus pratique, Citons Jan van de Sneptscheut :
« La différence entre la théorie et la pratique, c’est qu’en théorie, il n’y a pas de différence entre la théorie et la pratique, mais qu’en pratique, il y en a une. »
De la théorie à la pratique, que s’est-il passé sur le projet? Car hélas, tout projet subi des aléas qui
l’amène à prendre des retards voir à échouer dans le pire des cas et rare sont les projets
informatiques totalement réussi (Voir l’annexe 6.1 référence 5).
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 34
4. Le déroulement du projet : de la théorie à la pratique Ce chapitre décrit le travail réalisé sur le projet en détaillant chacune de ses phases. Pour chaque phase
un point est réalisé, permettant de distinguer les tâches réalisées des tâches en cours et de celles restant à
faire ou annulé. Pour réaliser cela, le WBS est utilisé, chaque case étant colorée en fonction de son
avancement. Le code couleur utilisé est le suivant :
Vert : réalisée
orange : en cours de réalisation
Rouge : non réalisée
Commençons par la gestion de projet, activité qui a débutée avec le projet et qui a permis de le structurer.
4.1 Une activité transversale : le management du projet
Cette activité qui couvre toute la durée du stage a permis de démarrer le projet en le structurant. Elle a
permis de définir et délimiter le projet dans un premier temps puis à consister à assurer son suivi durant la
période du stage. Elle se découpe en cinq tâches élémentaires :
Rédiger la note de clarification
Rédiger le plan de management
Créer le planning initial
Piloter le projet
Gérer les réunions et rédiger les comptes rendus afférents
Amélioration des outils de tests
6-Management de projet
6.1 Rédaction du PMP
6.2 Planification 6.3 Pilotage du
projet 6.4 Réunions et comptes rendus
6.4.1 Réunions d’avancement
projet
6.4.2 Réunions techniques ponctuelles
6.4.3 Rédaction des CR
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 35
4.1.1 Rédiger la note de clarification, le plan de management et créer le planning initial
La rédaction de la note de clarification m’a permis de lancer le projet en synthétisant les données
obtenues lors des différents entretiens précédant le début du projet.
Elle s’est enchaînée immédiatement avec la réalisation du plan de management constituant mon
second livrable. Cette tâche s’est déroulée en parallèle avec d’autres tâches initiales du projet me
permettant d’assimiler le fonctionnement de l’entreprise et les demandes du management. Je l’ai réalisé
en me servant des compétences acquises au cours de ma carrière en matière de génie logiciel et de celles
nouvellement acquises en matière de gestion de projet.
La rédaction du PMP a découlé de ces choix initiaux et de mes compétences nouvellement acquises
dans le domaine de la gestion de projet.
Le PMP a été le fil rouge du projet et a aussi servi de contrat entre mon responsable de projet et moi
en définissant les grandes lignes du projet. Il a été validé par mon responsable de stage avant d’être
envoyé au CESI.
Le planning initial à quant à lui résulté du WBS réalisé pour le PMP. Il m’a permis d’avoir une idée
précise du futur avancement du projet.
4.1.2 Piloter le projet
Cette activité m’a permis de suivre mon projet et notamment son avancement. Pour ce faire, j’ai utilisé
certaines des données de mon plan de management ainsi que les outils suivants :
Le planning,
Les fiches de lots9,
L’analyse des risques
La fréquence du pilotage (2 fois par mois en début de projet puis 1 fois par semaine dans la seconde moitié
du stage) m’a permis d’avoir une vue d’avancement de mon projet en temps réel et d’obtenir les résultats
suivants :
Suivi de l’avancement des tâches,
Mise à jour La liste des risques qui bloquent l’avancement du projet,
Archivage des documents projet,
Surveillance et mise à jour de mon Plan de management.
4.1.3 Gérer les réunions et rédiger les comptes rendus afférents
Les réunions ont été moins nombreuses que prévu, une fois par mois, et donc moins chronophage. La
communication par e-mail a permis de transmettre les informations essentielles sur l’avancement du
projet.
La phase d’initialisation du projet terminée, j’ai commencé la phase la plus importante du projet :
l’étude préalable.
9 Voir en annexe 6.3 pour une description détaillée
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 36
4.2 L’étude préalable
L’étude préalable a permis de vérifier la faisabilité du projet grâce à la réalisation du prototype tout en
le structurant par la rédaction d’un cahier des charges. Mais le premier livrable que j’ai rédigé a été l’état
des lieux initial qui a permis de référencer l’existant. Ce document a été réalisé à l’issue des taches de
familiarisation avec l’environnement et de formation à l’environnement technique ayant pour but de
m’intégrer à l’entreprise.
4.2.1 Familiarisation avec l’environnement
Cette première étape de prise en compte de l’environnement du projet, m’a permis de me familiariser
avec l’entreprise. D’un point de vue humain elle m’a permis de découvrir mes collègues, apprendre quelles
étaient leurs positions respectives dans l’entreprise et leur travail afin de savoir à qui m’adresser en cas de
problèmes et enfin, de découvrir les caractères de chacun.
Du point de vue organisationnel elle m’a permis de découvrir le fonctionnement de l’entreprise et de
comprendre les circuits d’information. Par exemple, Evistel n’a pas de services transverses réalisant les
tâches de support classiques comme dans les grandes entreprises. Il est donc important de comprendre
l’organisation de l’entreprise afin de déterminer le niveau d’autonomie requis pour réaliser une tâche. En
outre cette étape m’a permis de cerner le type de comportement à adopter afin de mener à bien le projet
et de déterminer les marges de manœuvres laissées à chacun dans l’exécution de son travail. Enfin elle
m’a permis d’obtenir les informations nécessaires au démarrage du projet. Savoir où sont stockés les
divers documents projet (fiches de tests, stratégie de tests, document de références, présentations…) est
important accomplir le projet. Cette étape initiale de recherche d’information a été complétée par une
activité de recherche d’informations qui a duré durant toute la durée du projet.
Amélioration des outils de tests
1-Étude préalable
1.1 Recueil de l'existant – État des
lieux
1.1.1 Familiarisation avec
l’organisation
1.1.2 Formation à l' environnement
technique
1.1.3 État des lieux
1.2 Définition du cahier des charges
1.2.1 Recueil des besoins
1.2.2 Rédaction du cahier des charges
1.2.3 Suivi du CDC
1.3 Prototypage et Maquettage
1.3.1 Prototypage
1.3.2 Maquettage
1.4 Validation de la phase
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 37
Comprendre le fonctionnement de l’entreprise est important, mais le secteur Hi-Tech est très
technique, il est donc important de comprendre quelles sont les outils et méthodes utilisés et de se
familiariser avec l’environnement de travail.
4.2.2 Formation à l’environnement technique
Cette formation s’est faite en lisant les documents recueillis lors de l’étape précédente et en discutant
avec les ingénieurs testant les produits. Elle m’a permis de me familiariser aux outils et à l’environnement
de tests existant. Par exemple, savoir comment accéder aux serveurs, connaître leur emplacement en
plate-forme de tests, récupérer les mots de passes sont des prérequis au démarrage du projet. J’ai ainsi
appris que l’entreprise utilise uniquement le système d’exploitation LINUX mais plusieurs distributions,
principalement Debian et Red Hat, et les logiciels Open Source pour ses produits: PostgreSql comme base
de données, CVS comme logiciel de gestion des configurations, les langages C, Perl et Python pour le
développement. Pour être utilisé le simulateur créé devait donc s’intégrer les plus possible dans
l’environnement existant sans remette en cause les choix technique déjà réalisé. J’ai donc décidé d’utiliser
LINUX comme système d’exploitation et le langage Perl associé à des SHELL scripts pour la programmation.
Le langage de scripting Perl est utilisé pour sa polyvalence et sa base de paquetages importante.
Je me suis plus particulièrement intéressé aux outils de tests existants. Les ingénieurs les utilisent pour
les tests fonctionnels du produit IPTAX. Ma première idée a été de les utiliser et de les adapter pour
réaliser mon projet. Pour cela il était nécessaire de réaliser un état des lieux.
4.2.3 État des lieux
Si les deux tâches précédentes étaient nécessaires afin de pouvoir accéder au serveur où étaient
stockés les outils de tests existants, l’état des lieux initial qui s’est concrétisé par un document, premier
livrable du projet, m’a permis de déterminer la charge de travail à réaliser.
L’entreprise utilisait en interne des outils de tests fonctionnels afin de valider les logiciels qu’elle
développe. Il existait notamment des outils pour tester IPTAX. Un ingénieur ayant quitté l’entreprise avait
ainsi déjà réalisé un embryon d’outil permettant de générer du trafic WEB. Connaître les limites de cet
outil et savoir quelles parties réutiliser m’a permis de minimiser les développements. J’ai ainsi récupéré
des informations précieuses sur l’existant et réalisé qu’il était impossible de continuer dans la voie choisie,
débouchant sur une impasse en raisons des performances limités de l’outil créé et de l’impossibilité à
l’améliorer dû à l’architecture matérielle et logicielle employée comme le montre le schéma ci-dessous.
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 38
Figure 10 : Architecture de l’outil de test fonctionnel initial
Les points faibles de l’architecture sont indiqués en rouge dans le schéma précédent. Détaillons-les en
les traitant par ordre d’importance:
La puissance de la configuration simulant le GGSN est le plus gênant pour les tests de charge. La
comparaison entre le serveur IPTAX et le simulateur tourne clairement à l’avantage d’IPTAX ! Afin
d’y remédier il faut impérativement plus de mémoire vive, 512 Mo étant suffisant pour générer le
trafic nécessaire pour les tests fonctionnels mais insuffisant pour de la charge. De plus le
processeur est vieillissant et ses performances sont insuffisantes pour stresser un processeur de
nouvelle génération.
Le processus émetteur de requêtes utilise Perl qui est un langage interprété ayant des
performances limitées.
Le processus gérant les réponses est un programme Python : Le support de nouveaux protocoles
nécessite des développements importants et les performances sont limitées.
Le réseau IP utilise Ethernet 100Mbits/s : Utiliser un réseau Gigabit permet d’augmenter la charge.
L’architecture client-serveur choisie ne permet pas un dimensionnement de la plate-forme en
fonction de la charge : un client émet vers un serveur, plus de charge signifie une duplication des
environnements.
Le serveur d’authentification Radius est localisé sur la même machine que le serveur générant la
charge.
On peut remarquer une double difficulté dans le choix des outils :
Le client doit être performant : L’injecteur de charge doit être capable de générer un trafic
important
Le serveur doit être performant : Le bouchon doit être capable de tenir la charge générée par
l’injecteur
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 39
La recherche de nouvelles voies s’avérait donc nécessaires. Mais pour réaliser un simulateur de charge
adapté aux besoins il était nécessaire de les formaliser sous la forme d’un cahier des charges.
4.2.4 Définition du cahier des charges
Le cahier des charges a été écrit à partir des besoins exprimés oralement par T. Lafue et P.Verdier lors
de discussion informels sur le projet. Il en est ressorti les besoins suivants :
Avoir une solution simple à mette en œuvre et facile à utiliser. Les tests doivent pouvoir être
exécutés rapidement.
Avoir une solution peu coûteuse, et donc favoriser la piste des logiciels open Source. Un
document recensant les solutions possibles et plus s’intéressant plus particulièrement aux
solutions Open source valable pour la charge requise a d’ailleurs été demandé par T Lafue. Ce
document a été rédigé pendant la phase de prototypage.
Être évolutive et pouvoir s’adapter à des besoins changeant.
Supporter les protocoles HTTP et HTTPS
Être capable de mesurer le temps de latence du logiciel IPTAX
Être capable de générer une charge de 200 000 utilisateurs pour valider la solution vendue à
Movistar.
Ce recueil des besoins a été complété par une analyse fonctionnelle réalisée à l’aide de la méthode
APTE m’ayant permis de valider les besoins auprès des utilisateurs. Les diagrammes de type bête à corne
et pieuvre issus de cette phase de réflexion sont donnés ci-dessous.
à qui rend il service? Sur quoi agit-il ?
Dans quel but le système existe-il?
Figure 11 : Bête à corne du simulateur de charge
Simulateur de tests de
charge
Aux développeurs
Le logiciel IPTAX
Exécuter les tests, Réaliser des mesures
Conserver les résultats de tests
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 40
Figure 12 : Diagramme pieuvre du simulateur
Les besoins m’ont conforté dans le choix de l’open source, la contrainte liée au coût de la solution
étant la plus importante pour le management. La solution devant être la moins chère possible, la
programmation d’un outil « maison » s’est avérée impossible dans le temps imparti.
La partie la plus importante du projet a alors débuté : trouver une solution Open Source capable de
générer un trafic HTTP important.
4.2.5 Prototypage et maquettage
La réalisation du prototype s’est faite en suivant les étapes suivantes:
Collecte d’informations relatives aux outils de charge Open Source sur le WEB : injecteur et
bouchon
Rédaction du livrable relatif aux outils de charge existants en insistant sur les solutions Open Source
Choix des injecteurs et bouchons possibles en fonction des performances théoriques des outils
Réalisation d’un benchmark des outils sélectionnés afin de sélectionner les outils appropriés dans la
configuration le plus performante
Réalisation du prototype afin de valider les choix et s’assurer de la faisabilité du projet
Par rapport au plan de management de projet initial, j’ai jugé le maquettage inutile, une interface
graphique ne s’avérant pas nécessaire.
Détaillons maintenant chacun des points précédents.
FP1 : Stresser le logiciel IPTAX
FP2 : Gérer les tests
FC1 : Gérer l’environnement de tests
FC2 : Conserver les résultats de tests
FC3 : Permettre les Campagnes de tests
FC4 : S’adapter aux tests existants
Simulateur de tests
de charge
IPTAX
Plate-forme de tests
Résultats de tests
Campagnes de tests
Fiches de tests
Utilisateur FP1
FC3
FC1
FC2
FP2
FC4
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 41
Evistel n’ayant pas une culture des outils de tests Open Source, il était impossible de trouver les
ressources dans l’entreprise pour m’orienter dans mes recherches. La collecte d’informations s’est donc
faite essentiellement à partir de l’internet. Les cours relatifs à la veille technologique m’ont permis d’être
plus performant dans le domaine de la recherche d’informations. J’ai principalement utilisé les outils
suivants :
Moteurs de recherches : Exalead, Bing et bien sur Google
Sites spécialisés dans l’open Source : http://www.opensourcetesting.org/performance.php ,
http://www.smile.fr/Livres-blancs/Culture-du-web/Guide-de-l-open-source
Sites spécialisés dans les tests : http://www.aptest.com/resources.html ,
http://performance-testing.org/ ,
http://www.automatedtestinginstitute.com/home/index.php?option=com_alphacontent&view
=alphacontent&Itemid=114 ,
http://www.loadtestingtools.org/?opensource
Sites pour les professionnels de l’informatique : http://pro.01net.com/editorial/402397/les-
outils-de-test-en-route-vers-lindustrialisation/
Sites de passionnés : http://www.jayphilips.com/2010/01/07/50-open-source-performance-
testing-tools/ , http://nbonvin.wordpress.com/2011/03/24/serving-small-static-files-which-
server-to-use/
Parallèlement à la recherche d’information j’ai rédigé un document recensant les solutions disponibles
sur le web en matière d’outils de tests de charge dont des extraits sont donnés en annexe 6.4. Ces
différents sites m’ont permis d’obtenir des informations et de faire des recoupements entre ces
informations afin de réaliser une analyse multicritères dans le but de sélectionner les outils les plus
adaptés au projet.
Figure 13 : Analyse multicritères des outils de charge
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 42
La méthode utilisée pour déterminer l’outil le plus performant est la Weight Sum Method qui utilise une
pondération pour chaque critère retenu. Les deux injecteurs les plus performants pour les tests de charge
massifs sont, suivant cette méthode :
Curl-loader10 : pour les tests de montée en charge
Tsung11 : pour les tests de charge
De même il m’a fallu trouver une solution pour le bouchon, le serveur WEB Apache étant trop lent pour
les tests de charge, je me suis orienté vers deux solutions parmi les plus performantes du moment: Nginx
et G-WAN.
Pour valider les solutions retenues j’ai réalisé un benchmark. Pour établir la plate-forme matérielle
nécessaire pour les tests je suis parti de l’architecture client/serveur de l’outil de test fonctionnel existant
que j’ai généralisé afin de satisfaire aux besoins des tests de charges comme le montre la figure suivante :
Figure 14 : architecture matérielle de la plate-forme de tests de charge
10
Voir en annexe 6.4.1 pour une présentation rapide du logiciel et le site web associé pour une présentation détaillée 11
Voir en annexe 6.4.1 pour une présentation rapide du logiciel et le site web associé pour une présentation détaillée
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 43
Les tests retenus dans le cadre du benchmark concernent uniquement la capacité à transmettre des
fichiers de différentes tailles afin de pouvoir générer un trafic minimal. Ces tests permettent la mesure du
nombre de sockets ouverts en parallèle lors d’un téléchargement. Ils sont donnés pour informations :
Test M1 – mesure du nombre maximal de sockets ouverts lors d’un téléchargement d’un fichier de
1Ko
Test M2 - mesure du nombre maximal de sockets ouverts lors d’un téléchargement d’un fichier de
taille 10Ko
Test M3 - mesure du nombre maximal de sockets ouverts lors d’un téléchargement d’un fichier de
taille 50Ko
Test M4 - mesure du nombre maximal de sockets ouverts lors d’un téléchargement d’un fichier de
taille 100Ko
Enfin, pour les tests du prototype il a fallu trouver du matériel suffisamment puissant pour tenir la
charge. Un PC a été acheté à cet effet en début de stage, pour être utilisé comme injecteur. Le 15 mars
une station de travail, prêtée par SUN-ORACLE pour une durée d’un mois dans le cadre d’un partenariat,
est arrivée d’Allemagne pour être évaluée. Elle a notamment été utilisée pour jouer le rôle du bouchon,
permettant le début des tests de benchmark. L’installation des différents logiciels n’a posé aucun problème
et les tests ont pu démarrer rapidement.
Les résultats suivants ont été obtenus en utilisant Tsung et Nginx. En abscisse la coordonnée est le
temps exprimé en seconde alors qu’en ordonnée se trouve le nombre de sockets créés et utilisés.
Transfert d’un fichier de 10KOctets
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 44
Transfert d’un fichier de 50KOctets
Transfert d’un fichier de 100Kctets
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 45
Les fichiers de résultats montrent une réelle dégradation des performances à partir d’un fichier de taille
100ko, aussi bien en nombre de sockets ouverts que de durée du test.
Le résultat suivant a été obtenu en utilisant Tsung et G-WAN.
Transfert d’un fichier de 10KOctets
La comparaison avec le graphe équivalent dans la configuration précédente, en page 43, fait apparaître
deux résultats défavorables à G-WAN :
Un nombre moyen de socket crées inferieur, en moyenne 50 000 vs 60 000
Un nombre de socket utilisés inferieur 5000 vs 10 000
De plus, un bug trouvé au cours du benchmark obligeant l’arrêt systématique de G-WAN après un test pour
détruire des sockets encore ouvert alors qu’ils sont inutilisés, associé à son mode de distribution, gratuit
mais non Open Source, a permis à NGINX d’être retenu pour devenir le futur serveur WEB de la plate-
forme de tests.
Les résultats des tests de montée en charge avec Curl-loader ont conclu qu’il était possible d’atteindre
la limite de 60000 utilisateurs en utilisant des paliers de 7500 utilisateurs avant d’épuiser les 4Gb de
mémoire vive disponibles sur l’injecteur, 8 Montées en charge étant nécessaires pour atteindre cette
limite.
Cette étude a aussi permis le dimensionnement matériel de la plate-forme de tests. Tsung et NGINX
permettent de réaliser les tests avec une configuration réduite à 4 injecteurs (machines DELL Precision
T3500 équipées d’un processeur P6 à 2 cœurs et de 4 Go de mémoire) pour simuler la charge requise de
200 000 sockets ouvertes en moyenne. Un bouchon s’avérant suffisant (Machine SUN Fire X4170 24 cœurs
et 4 Go de mémoire).
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 46
Cette étape m’a permis de prouver la faisabilité du projet et de déterminer la configuration matérielle
et logicielle du simulateur. La suivante a consisté à intégrer les logiciels Tsung et NGINX dans l’outil de tests
fonctionnels afin d’obtenir une première version du simulateur permettant de tester le logiciel IPTAX.
Cette opération a été réalisée en trois jours permettant de débuter des tests de charge du logiciel IPTAX
avec l’ingénieur en charge de son développement.
4.2.6 Validation de la phase
La validation de la phase s’est faite en deux étapes. La première a consisté à réaliser un document au
format Powerpoint décrivant les choix réalisés et les résultats obtenus. Ce document a été transmis aux
acteurs du projet pour approbation. La seconde a consisté en une utilisation pendant quatre jours du
simulateur afin de commencer à stresser le logiciel IPTAX, permettant de voir quelques problèmes
spécifiques au logiciel, notamment des problèmes de pertes de paquets, rapidement réglés par P. Verdier
l’ingénieur en charge du développement d’IPTAX.
Intéressons-nous un instant au planning. Cette phase devait se terminer fin semaine 9. Elle a
commencé fin semaine 11 pour se terminer en fin de semaine 15. Ce décalage temporel, fréquent
dans les projets informatiques ou télécom, nécessite des capacités spécifiques au métier d’ingénieur
intégration/validation:
Être capable de travailler en avance de phase, en démarrant les tâches pouvant l’être. La
conception a donc débutée avant la validation du prototype.
Savoir gérer les délais et les priorités.
Adapter son planning en fonction des aléas ou des opportunités : Les tests du produit
IPTAX ont ainsi commencé mi-avril permettant à P. Verdier d’anticiper la résolution des
problèmes.
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 47
4.3 La phase de conception
La phase de conception a permis de modéliser le simulateur. Durant cette phase j’ai défini son
architecture logicielle et finalisé l’architecture matérielle. Cette phase a surtout consisté en la rédaction de
documents permettant sa réalisation. L’interface homme machine a été réduite à sa plus simple
expression : une fenêtre s’ouvrant afin de visualiser l’exécution du programme.
4.3.1 Définition de l’architecture du simulateur
Cette étape a permis la rédaction du Dossier de Conception Générale. Ce document définissant
l’architecture matérielle et logicielle du simulateur utilise le langage UML. UML est un langage de
modélisation graphique à base de pictogrammes permettant la conception de système informatique. Afin
de faciliter la tâche de conception j’ai choisi d’utiliser un outil de modélisation. Mon choix s’est tourné vers
un logiciel Open source, StarUML12, permettant le développement objet sous UML. Les raisons du choix de
ce logiciel sont les suivantes :
Ce logiciel est Open Source sous licence GPL
Il supporte UML 2.0
Tous les types de diagrammes UML 2.0 sont disponibles
Le défaut principal de cet outil par rapport à MODELIO ou BOUML, est le système d’exploitation nécessaire
pour l’utiliser : Windows. Si les deux derniers outils sont multi plate-forme, LINUX et Windows, ils sont soit
restreint dans le choix de diagrammes UML dans le cas de MODELIO, soit payant dans le cas de BOUML.
12
Voir http://staruml.sourceforge.net/en/
Amélioration des outils de tests
2-Conception
2.1 Conception générale
2.1.1 Définition de l’architecture du
simulateur
2.2.2 Rédaction du plan de tests
2.2 Conception détaillée
2.2.1 Spécifications détaillées des paquetages
2.2.2 Définition de IHM
2.3 Validation de la phase - Présentation
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 48
Néanmoins, ce défaut peut être contourné en installant une machine virtuelle Windows de type QEMU13
sur un système LINUX. Le document de conception générale contient les informations suivantes :
Une définition de l'architecture générale du simulateur de charge,
Un découpage des actions à réaliser en tâches,
Un regroupement des fonctionnalités en paquetages,
Des classes modélisant les principaux objets du système,
Une définition des interfaces de communication entre les paquetages
Intéressons-nous maintenant à la conception du système proprement dite.
L'architecture matérielle du projet est une architecture distribuée (voir la figure 14) qui a été définie
durant la phase de prototypage. L'application à développer peut être répartie sur cinq types de stations en
fonction des performances des stations de travail utilisées :
L’ordinateur maître dont le rôle est de superviser les tests
Un agent de communication de type injecteur qui va générer les requêtes HTTP vers
Un agent de communication de type bouchon qui va, en réponse aux requêtes de l’injecteur,
générer du trafic de données
Le SUT qui va contenir une partie supervision permettant de valider le fonctionnement de
l’application IPTAX.
Les sondes permettant des mesures de performances
De plus l’injecteur et le bouchon peuvent être situés sur plusieurs machines différentes pour générer la
charge appropriée. Le schéma suivant résume l’architecture choisie pour réaliser la plate-forme et définit
l’architecture fonctionnelle du simulateur.
13
Voir http://en.wikibooks.org/wiki/QEMU/Windows_XP
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 49
Figure 15 : architecture fonctionnelle du simulateur
Les différents modules sont : Des logiciels comme Tsung ou Nginx permettant de gérer le trafic Des scripts lancés par l’ordinateur maître pour superviser le SUT lors du tests Des programmes optionnels démarrés pour réaliser des mesures ou superviser le réseau
Les fonctionnalités sont regroupées selon des «paquetages de gestion» qui ont des interfaces de communications entre eux. L'architecture comprend :
Le paquetage de gestion des tests de charge: ce bloc comprend l'interface utilisateur. Il a une interface avec le paquetage de gestion du trafic et le paquetage de gestion de supervision des mesures.
Le paquetage de gestion du trafic qui a une interface de communication avec le paquetage de génération du trafic sur l’injecteur et du trafic sur le bouchon.
Le paquetage de supervision des mesures : partie du système chargée d'analyser le trafic et le comportement de l’application testée. Le gestionnaire d'analyse du trafic, optionnelle, est une application observatrice du trafic et doit être installée sur une station externe dans un souci de percevoir tous les messages. Le SUT est supervisé par différents paquetages : système qui s’occupe de l’OS, applicatif qui s’occupe du logiciel IPTAX et réseau qui mesure les performances réseau du SUT.
Le Paquetage de gestion des résultats de tests : les méthodes de sauvegarde des résultats des tests ainsi que les méthodes de traitement des résultats a posteriori y sont définies.
Le paquetage de service générique fourni les objets et services de base à l’application
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 50
L’architecture logicielle est très simple. Le simulateur est composé de quatre programmes perl ayant
les rôles suivants :
MakeAliases : programme permettant d’initialiser l’environnement de tests CheckPlatformConfig : programme permettant de vérifier l’état des principaux agents et services
constituant la plate-forme. RunLoadTests : programme permettant de
o générer du trafic sur le réseau afin de tester le logiciel IPTAX o démarrer la supervision du SUT et des agents remontant des informations utile au test o sauvegarder les résultats de tests
ConfigurePlatformConfig : programme permettant de mettre à jour la configuration de la plate-forme. Ce programme aura un GUI permettant de mettre à jour facilement l’ensemble des fichiers de configuration de la plate-forme.
Ces quatre programmes sont indépendants et peuvent être utilisé en mode commande à partir d’un shell
LINUX. L’application ConfigurePlatformConfig avec une GUI sera développée en fin de projet pour
compléter ces programmes si nécessaire.
4.3.2 Rédaction du plan de tests du simulateur
Cette étape de rédaction des documents de conceptions s’est poursuivie par la rédaction du plan de
test du simulateur qui m’a permis de définir les procédure d’intégration et validation du logiciel. Le logiciel
développé étant relativement simple j’ai choisi de fusionner les tests d’intégration et validation en un
unique document. Ce plan de test, court, comporte trois parties :
Des tests de documentation : Afin de vérifier la livraison de tous les livrables attendus
Des tests d’installation : Pour vérifier la capacité à installer le simulateur sur une autre machine
Des tests fonctionnels : Afin de vérifier la capacité à réaliser un test de charge
Ces trois parties permettent de valider le déploiement du logiciel à chaque livraison. La phase s’est ensuite
achevée par la conception détaillée permettant de préciser certains points de conception nécessitant
d’être approfondie.
4.3.3 Rédaction des spécifications fonctionnelles détaillées
Cette étape, prolongement naturel de l’étape de conception générale, s’est traduite par la rédaction
d’un nouveau document : le dossier de conception détaillée.
Pour réaliser cette partie j’ai utilisé StarUML afin de détailler, pour chacune des classes définies dans le
DCG, leurs attributs et méthodes. Ainsi la modélisation de l’outil de tests de charge donne les trois
résultats principaux suivants.
La plate-forme de test est constituée des objets suivants :
o Un ou plusieurs injecteurs, objet Send, qui envoient les messages
o Un ou plusieurs bouchons, objet Resp, qui répondent à l’injecteur
o Un SUT, qui modélise la configuration testée
o Des sondes optionnelles, objet Probe, qui réalisent des mesures
o Un serveur Radius qui donne les autorisations et identifie les accès au réseau internet
o Une base de données des utilisateurs référencés sur le réseau, objet UserMsIsdnDataBase
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 51
Figure 16 : Modélisation de la plate-forme de tests
Un test est composé des objets suivants :
o D’un scenario de tests : utilisant les outils TSUNG ou CURL-loader il décrit le test à réaliser.
o D’une plate-forme de test qui décrit la plate-forme utilisée
o D’un objet résultat de test, optionnel, permettant de générer les résultats du test et de les
stocker.
Le schéma ci-dessous résume ce modèle :
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 52
Figure 17 : Un test de charge modélisé
Enfin les éléments de la plate-forme sont issus d’un objet générique modélisant un élément d’un
réseau :
Figure 18 : Objets génériques de l’application
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 53
Les diagrammes de classes précédents montrent la structure interne du programme. Ils permettent de
fournir une représentation abstraite des objets du système qui vont interagir ensemble lors de l’exécution
du programme. Le diagramme d’états-transitions suivant décrit le comportement interne des objets à
l’aide d’un automate à états finis. Il présente les séquences possibles d’états et d’actions que le
programme peut traiter au cours de son cycle de vie en réaction à des événements discrets (de type
signaux, invocations de méthode).
Figure 19 : Diagramme d’état du programme
Cette étape m’a permis de définir les objets constituant le simulateur ainsi que son comportement. J’ai
réalisé une conception suffisamment détaillée pour commencer le développement. Malheureusement, je
n’ai pu utiliser une des fonctionnalités majeures de ce genre d’outil, la génération de squelette de code, le
langage de développement choisi, Perl, n’étant pas supporté par cet outil. Il a fallu donc fallu coder le
logiciel en intégrant certaines parties du prototype.
4.3.4 Validation de la phase
La validation de la phase a consisté à soumettre les documents générés pour approbation afin de
démarrer le codage, la présentation technique ayant été livré dès la fin du benchmark.
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 54
4.4 La réalisation du simulateur
La réalisation d’un logiciel consiste principalement à l’écrire et à le tester afin de s’assurer de son bon
fonctionnement. La documentation permet à l’utilisateur de prendre en main le logiciel. Cette phase se
conclut par la recette, qui entraîne le passage en production : la vie du logiciel débute alors réellement.
4.4.1 Développement
Le début du développement s’est effectué alors que le travail de rédaction des spécifications détaillées
se terminait, afin d’affiner le modèle lors d’une période de recouvrement. L’écriture des programmes en
perl s’est fait directement sur la machine de tests, des backups étant réalisés périodiquement sur mon
ordinateur afin d’assurer la sauvegarde des programmes générés. L’utilisation de CVS sur la machine de
développement afin de pouvoir gérer les évolutions du simulateur, s’est avérée inutile, le logiciel n’étant
pas supposée être livré et donc n’ayant pas besoin de se voir attribué une version. De la documentation en
ligne utilisant le format PERLPOD a été généré dans le code afin d’aider à son utilisation ultérieure.
4.4.2 Passage des tests
Des tests unitaires ont été réalisés durant la phase de développement afin de s’assurer du bon
fonctionnement du code généré, notamment pour les objets génériques.
4.4.3 Réalisation de la documentation
La documentation comporte trois livrables principaux : un manuel utilisateur, un FAQ et HowTo
J’ai tout d’abord rédigé un manuel utilisateur afin de permettre l’utilisation du simulateur par les
ingénieurs. Ce court document à l’usage des débutants décrit comment utiliser le simulateur.
Amélioration des outils de tests
3-Réalisation
3.1 Développement
3.2 Tests 3.3
Documentation
3.3.1 Rédaction du manuel utilisateur
3.3.2 Rédaction faq
3.3.3 Rédaction HowTo
3.4 Recette
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 55
La rédaction d’un document de type Frequently Asked Question a permis de regrouper les réponses
aux questions les plus souvent posés. Ce type de document fréquent sur internet, permet de répondre aux
questions usuelles posées par les utilisateurs ayant plus d’exprience dans l’utilisation d’un logiciel.
Enfin la rédaction d’un HowTo a permis de regrouper des informations diverses et utiles à l’usage des
utilisateurs : Ce livre de cuisine, contient quelques trucs et astuces sur l’utilisation du simulateur.
4.4.4 Recette
En fin de phase le plan de tests généré en 4.3.2 a permis de valider la livraison des principaux éléments
du simulateur, permettant ainsi sa recette. La recette a permis de décider la mise en production du logiciel,
dans notre cas son utilisation pour des campagnes de tests comme dans la figure ci-dessous où le logiciel
est utilisé pour un test d’endurance d’une semaine.
Figure 20 : Le simulateur LoadTT en action
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 56
4.5 La mise en œuvre
La mise en œuvre est une phase d’installation du simulateur sur un autre environnement de test afin
d’avoir deux plates-formes pour exécuter des campagnes de tests en parallèle suivi d’une période de
formation afin de permettre aux ingénieurs d’utiliser l’outil.
4.5.1 Déploiement
Cette phase qui aurait dû être très courte a été supprimée car il n’y avait pas d’ordinateur disponible à
sa réalisation. J’utiliserai donc la plate-forme de développement pour réaliser les sessions de formation et
les tests à venir.
4.5.2 Formation des ingénieurs à l’outil
Cette étape sera réalisée en une heure et complétée par une aide au quotidien des ingénieurs en
charge des tests. Une session de formation doit être réalisée avant la fin du stage afin de transférer les
compétences aux ingénieurs d’Evistel.
4.5.3 Le bilan provisoire du projet
Le logiciel permet de réaliser des tests de performances et d’endurance conformément aux besoins
initiaux. Il peut aussi être dimensionné en fonction des besoins permettant de générer une charge variable
en fonction de la configuration vendue au client. Enfin il est simple à utiliser, permettant une prise en main
rapide.
La configuration matérielle et logicielle minimale requise pour la réalisation des tests de charge et
d’endurance est la suivante :
Amélioration des outils de tests
4- Mise en œuvre
4.1 Déploiement 4.2 Formations des ingénieurs à l’outil
4.2.1 Création d’un document de
formation
4.2.2 Session de formation
4.3 Bilan projet
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 57
Figure 21 : LOADTT la configuration minimale requise pour effectuer les tests de charge
Le coût théorique du projet est détaillé dans le tableau ci-dessous :
Matériel Prix unitaire TTC
Nombre Durée Prix total
Commentaires
Ordinateurs DELL 897 € 5 4485
Logiciels 0 € 4 0
Main d’oeuvre
Ingénieurs Intégration en charge du développement
600€ 1 95 57000 Ce coût est celui d’une ressource chez Evistel. Il inclut les frais fixes.
Aide extérieure 600€ 1 4 2400
Total 63885€
Tableau 6 : Le coût du projet LOADTT
Ce coût est celui du développement du simulateur. Il n’inclut pas le coût de passage des tests.
L’aide extérieure a été évaluée à 4 jours sur la durée du stage.
Les 95 jours de développement incluent 89 jours de développement réalisés au 23/06/12 et 6 jours de
maintenance à réaliser d’ici la fin du projet.
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 58
4.6 Exploitation et Maintenance
La phase d’exploitation et maintenance consiste principalement à réaliser de l’assistance aux
utilisateurs et à la participation à des campagnes de tests.
4.6.1 Exploitation, Assistance et Maintenance corrective et évolutive
Cette étape est en cours à l’heure actuelle.
Des améliorations peuvent notamment être envisagées dans les domaines suivants :
Surveillance de l’application via une MIB : des données pourraient être collectées afin de
générer des statistiques plus fines sur les tests réalisés
Évolution vers un Système d’exploitation 64 bits afin de pouvoir gérer une taille de RAM
supérieure à 4Mo. La création de 200 000 adresses IP entraîne l’utilisation de 400Mo de
RAM et limite donc la taille de la mémoire vive utilisable à 3 Go, ce qui est pénalisant pour
les tests de charge où la RAM est une ressource critique. Les systèmes 32 bits étant limités
à 4Go (=232 octets) de mémoire, l’utilisation d’un SE 64 bits permettrait de gérer plus de
mémoire et d’utiliser moins de machines.
4.6.2 Participation aux campagnes de tests
Cette phase est la plus importante pour le management puisqu’elle permet de mesurer les
performances et la stabilité du logiciel. J’ai commencé par rédiger un plan de tests permettant de valider
les principaux tests à réaliser. Ces tests peuvent être divisés en plusieurs catégories :
Tests de montée en charge : Simuler un nombre croissant d’utilisateurs pour déterminer les
limites
Amélioration des outils de tests
5-Exploitation
5.1 Assistance
5.2 Maintenance corrective et évolutive
5.3 Participation aux campagnes de tests
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 59
Tests de charge : Simuler un nombre prédéfini d’utilisateurs pour valider le comportement de
l’application (temps de réponse, utilisation des ressources, remontée des informations)
Test de stress : Tester le comportement du logiciel au-delà des limites
Test d’endurance : Tester le comportement de l’application dans le temps
Tests aux limites : Déterminer que le logiciel atteint les limites définis dans le cahier des charges
Ce plan de tests a été validé par les ingénieurs en charge du développement et ceux en charge de
l’avant-vente, qui souhaitaient obtenir des informations sur les performances d’IPTAX.
Des fiches de tests ont été rédigées pour permettre le passage des tests et une feuille Excel créée
pour synthétiser les résultats obtenus14.
J’utilise notamment le simulateur pour tester la version 1.46 d’IPTAX, version qui corrige certains
problèmes liés à la performance du logiciel. Je détaillerai cette phase lors de la soutenance de fin de stage
en insistant sur les possibles améliorations du processus de tests dans sa globalité.
Plusieurs problèmes de stabilité ont été trouvés durant les deux semaines de tests réalisées entre le
21/05/12 et le 01/06/12 (principalement des tests d’endurance) conduisant à des livraisons de correctifs
afin de les résoudre. Parmi ceux-ci on notera :
L’utilisation d’une nouvelle librairie GctLoad en version 32 bit
Un nouveau paramétrage de la pile de protocole TCP/IP afin d’absorber la charge
14
Une fiche de test et une feuille Excel type sont données en annexe 6.6 et 6.7
L’outil développé a déjà permis de trouver plusieurs problèmes, démontrant ainsi son efficacité. Sa
souplesse lui permet de s’adapter aux ressources disponibles pour le passage des tests.
Le plan de tests créé pour tester IPTAX contient des tests couvrant tout le périmètre des tests de
charge permettant ainsi de valider les performances globales d’IPTAX.
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 60
5. Conclusion En tout premier lieu ce stage m'a permis de renouer avec le secteur de l'informatique et des télécoms
après quatorze mois passés à l'Ei.CESI sur le site de Nanterre. Les débuts ont été difficiles, car il a fallu que
je me réapproprie certaines connaissances propres au secteur de l'informatique, moins utilisées pendant
plusieurs mois passés à acquérir de nouvelles compétences. Ensuite ce stage m'a permis de mettre en
application une partie de ces nouvelles compétences. Ce sont principalement celles relatives à la gestion
de projet, pour le mener à bien, de résolution de problème afin de trouver des solutions aux problèmes
rencontrés et la veille technologique afin de trouver les informations nécessaires à la réalisation du
simulateur.
J’avais choisi une PME éditrice de logiciels afin de découvrir une autre structure organisationnelle,
différente de celles des multinationales du secteur Hi-Tech que j’avais connu avant d’entamer ma
formation au CESI. Les moyens financiers limités des petites sociétés entraînent des choix différents en
matière de gestion de l’entreprise, par exemple en privilégiant le développement d’outils basé sur les
logiciels libres à l’achat de solution standard du marché. Cela m’a permis de découvrir de nouveaux outils
de tests et d’obtenir des informations sur les prix des différentes solutions, complétant mes connaissances,
jusque-là purement technique. Mais le manque de moyens entraîne aussi des tests limités en temps et en
nombre. Il faut alors sélectionner les tests à réaliser précisément pour répondre aux besoins des clients.
Un travail en équipe permet de définir précisément ces besoins et de les valider.
Ce stage me sera utile pour la suite de ma carrière. Il m’a permis de valider un niveau ingénieur
d’intégration-validation, poste vers lequel je souhaite m’orienter lors du retour dans mon entreprise HP.
D’un point de vue personnel, il m’a apporté une certitude la gestion de projet m’intéresse maintenant
beaucoup plus que la technique. Je chercherai à l’avenir des postes à fonction élargie ou la gestion de
projet tient une part importante.
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 61
6. Annexes
6.1 Références [1] Alcatel - http://www.alcatel-lucent.com/aboutus/companyoverview_fr.html (Dernière consultation le
14/04/12)
[2] Nokia-Siemens - http://www.nokia.com/global/about-nokia/investors/financials/reports/results---
reports/ (Dernière consultation le 14/04/12)
[3] Huawei - http://fr.wikipedia.org/wiki/Huawei_Technologies (Dernière consultation le 14/04/12)
[4] Cours d’analyse et conception des systèmes d’information, Olivier Guibert -
www.labri.fr/perso/guibert/DocumentsEnseignement/ACSI_v2.pdf (Dernière consultation le 14/04/12)
[5] Quelles sont les causes d’échec des projets informatiques? - http://www.portail-
management.ch/praxistipp_view.cfm?nr=3291 (Dernière consultation le 14/04/12)
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 62
6.2 Planning détaillé
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 63
6.3 Fiches de lot de travaux
Réalisation d’un simulateur de charge pour le produit IPTAX
Identifiant de fiche : FDL_01 Date de mise à jour : 12/02/12
Intitulé de la fiche de lot : Initialisation du projet
Responsable : Gilles Lefebvre Phase du projet : Management de projet
Objectifs : Initier le projet
Description de la fiche de lot : Ce lot consiste à rédiger les principaux documents projet permettant son démarrage.
Éléments d’entrées (Documents, Matériels, Informations, …) : Description orale du projet
Éléments de sorties/Livrables : Note de clarification, Plan de management projet, Planning
Durée de la tâche : 6J (4J réels) Date de Début : 24/01/12 Date de fin : 31/01/12
Budget : 0 € Ressources Humaines : Un élève ingénieur Matériels : Ordinateur, Suite bureautique (MS Office / Open Office)
Risques liés à la tâche : Perfectionnisme, Mauvaise compréhension du problème
Commentaires : La tâche de rédaction du PMP se fait en parallèle avec la phase recueil des besoins et nécessite un effort à hauteur de 70 % du temps
Visa / date : 15/02/12
Chef de Projet Responsable de lot Responsable de service
Gilles Lefebvre Gilles Lefebvre Omar ait-amrane
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 64
Réalisation d’un simulateur de charge pour le produit IPTAX
Identifiant de fiche : FDL_02 Date de mise à jour : 12/02/12
Intitulé de la fiche de lot : Etude de la faisabilité technique du simulateur
Responsable : Gilles Lefebvre Phase du projet : Étude préalable
Objectifs : Prouver la faisabilité théorique et pratique du simulateur. Définir différentes approches du problème. Choisir une solution adaptée au problème
Description de la fiche de lot : Ce lot consiste à rédiger le CDC puis à l’exploiter pour réaliser un prototype et une maquette de l’Interface Homme-Machine.
Éléments d’entrées (Documents, Matériels, Informations, …) : Description orale du projet, PMP
Éléments de sorties/Livrables : Cahier des charges, Prototype, Maquette de l’IHM, Étude comparative des outils de charge du marché
Durée de la tâche : 29J Date de Début : 24/01/12 Date de fin : 02/03/12
Budget : 0 € Ressources Humaines : Un élève ingénieur Matériels : Ordinateur, Outils de développement open source, Système d’exploitation Linux
Risques liés à la tâche : Perfectionnisme, Mauvaise compréhension du problème
Commentaires : L’environnement de développement est laissé au libre choix du développeur en charge du prototype et de la maquette tant que des logiciels open source sont utilisés. La cible est une machine Linux.
Visa / date : 15/02/12
Chef de Projet Responsable de lot Responsable de service
Gilles Lefebvre Gilles Lefebvre Omar ait-amrane
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 65
Réalisation d’un simulateur de charge pour le produit IPTAX
Identifiant de fiche : FDL_03 Date de mise à jour : 12/02/12
Intitulé de la fiche de lot : Réalisation du simulateur
Responsable : Gilles Lefebvre Phases du projet : Conception / Réalisation
Objectifs : Implémenter le simulateur.
Description de la fiche de lot : Ce lot consiste à réaliser les études techniques du simulateur puis de le réaliser.
Éléments d’entrées (Documents, Matériels, Informations, …) : Cahier des charges, prototype, maquette de l’IHM
Éléments de sorties/Livrables : Document d’architecture, Présentation technique du simulateur, Simulateur, Manuel utilisateur
Durée de la tâche : 45J Date de Début : 05/03/12 Date de fin : 09/05/12
Budget : 0 € Ressources Humaines : Un élève ingénieur Matériels : Ordinateur, Outils de développement open source, Système d’exploitation Linux
Risques liés à la tâche : Cahier des charges fonctionnel du simulateur de charge mal défini, Ajout de spécifications durant le projet, Simulateur inadapté aux besoins de la MOA, Complexité du problème mal estimée entraînant un dépassement des délais
Commentaires : Une recette valide cette phase permettant le déploiement du simulateur sur les plateformes de tests et son utilisation pour réaliser les tests de performances du logiciel IPTAX. Des documents de type faq et HowTo devront être livrés si nécessaires. La décision sera prise au moment de la recette et pourra reculer la signature du PV de recette.
Visa / date : 15/02/12
Chef de Projet Responsable de lot Responsable de service
Gilles Lefebvre Gilles Lefebvre Omar ait-amrane
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 66
Réalisation d’un simulateur de charge pour le produit IPTAX
Identifiant de fiche : FDL_04 Date de mise à jour : 12/02/12
Intitulé de la fiche de lot : Déploiement et maintenance du simulateur
Responsable : Gilles Lefebvre Phases du projet : Mise en Œuvre, Exploitation et maintenance
Objectifs : Formation, Support aux utilisateurs, Maintenance corrective et évolutive
Description de la fiche de lot : Ce lot est une prestation de support technique auprès des utilisateurs
Éléments d’entrées (Documents, Matériels, Informations, …) : Simulateurs, Plate formes de tests, Logiciel IPTAX
Éléments de sorties/Livrables : Présentation powerpoint du simulateur, Session de formation, Liste des anomalies résiduelles, Résultats des campagnes de tests
Durée de la tâche : 35 Date de Début : 10/05/12 Date de fin : 29/06/12
Budget : 0 € Ressources Humaines : Un élève ingénieur Matériels : Ordinateur, Simulateur, Plate-forme de tests, Logiciel IPTAX
Risques liés à la tâche : Disponibilité réduite des ressources matérielles car limitées en nombre et partagées entre les différentes équipes. exemple : plate-forme de tests.
Commentaires : Cette partie inclura la réalisation de campagnes de tests afin de mesurer les performances du logiciel IPTAX. La phase de maintenance se terminera le 22/06/12 afin de rédiger un document des anomalies résiduelles du simulateur et transmettre le simulateur à l’équipe d’intégration.
Visa / date : 15/02/12
Chef de Projet Responsable de lot Responsable de service
Gilles Lefebvre Gilles Lefebvre Omar ait-amrane
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 67
6.4 Les solutions Open sources étudiées Cette annexe est un extrait du document de synthèse relatif à l’étude des solutions Open Source
6.4.1 Les solutions logicielles
Les solutions logicielles ont pour principales caractéristiques de nécessiter à la fois un injecteur pour
simuler la charge et un outil complémentaire pour simuler les réponses aux requêtes générées par
l’injecteur de charge : le bouchon. L’étude des outils permettant ces réponses n’entre pas dans la cadre de
cette étude mais peuvent influencer les choix des injecteurs en fonction de critères fonctionnels ou de
performances. Les outils Open Source sont étudiés dans la première partie de cette section, la seconde
partie traitant des solutions commerciales.
6.4.1.1 Open Source
Les solutions étudiées sont toutes les dernières solutions stables livrées par les auteurs du logiciel.
6.4.1.1.1 Siege
Siege
Version étudiée : 2.70 (stable)
Site Internet de la solution : http://www.joedog.org/siege-home/
l’application est supportée par Jeff Fulmer
Siege permet de faire des tests de montée en charge en simulant un grand nombre de connexions simultanées sur une ou plusieurs URLs données. Le logiciel supporte les protocoles HTTP et HTTPS 1.0 et 1.1, les méthodes GET & POST, les cookies et l’authentification basique. L’affichage ne se fait pas en temps réels lors du passage des tests comme avec les solutions matériels de Spirent ou Ixia mais le programme indique en sortie le nombre total de hits enregistrés, de bytes transférés, le temps de réponse, les accès concurrents et le statut du serveur. Des statistiques minimalistes sont disponibles à la fin du test : Transactions, Elapsed time( secs), Data transferred (bytes), Response time(secs), Transaction rate(trans/sec), Throughput(bytes/sec), Status code 200, Successful transactions, Failed transactions
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 68
6.4.1.1.2 Jmeter
Jmeter
Version étudiée : 2.6 (stable)
Site Internet de la solution : http://jmeter.apache.org/
l’application est supportée par la fondation apache
Jmeter est un outil d'injection de trafic édité par la fondation Apache. Il est utilisé pour réaliser des tests de charge sur plusieurs types de serveurs : Web, LDAP, Bases de données, etc… JMeter est distribuée sous licence Apache. Il est réalisé en Java. Son développement a commencé en 2001. Il dispose d'une interface graphique, ce qui rend la création de scenarios d'utilisation plus facile. Les scénarios en eux-mêmes peuvent être d'une grande complexité, avec des boucles, conditions, extraction et réutilisation de variables, chargement de variables depuis un fichier externe, et de nombreux types de graphes et de statistiques. À la fin de tests des logs sont générés qui doivent être analysée avec l’outil « Graph Results » ou à l’aide de plugin à installer comme StatAggVisualizer.zip . Enfin, des outils extérieurs peuvent être utilisés comme dans l’exemple suivant : http://blog.zenika.com/index.php?post/2009/09/16/Analyser-vos-donn%C3%A9es-JMeter-lors-de-stress-tests Une synthèse est accessible à http://www.methodsandtools.com/tools/tools.php?jmeter
6.4.1.1.3 Tsung
Tsung
Version étudiée : 1.4.2 (stable)
Site Internet de la solution : http://tsung.erlang-projects.org/
l’application est supportée par une communauté : https://lists.process-one.net/mailman/listinfo/tsung-users
Tsung est un outil d'injection de trafic, utilisé pour les tests de charge de différents types de serveurs. Initialement crée par la société française Idealx, en 2006, il est désormais développé par une communauté indépendante. Le produit évolue régulièrement grâce à une communauté active. Il est disponible sous licence GPL. Il supporte HTTP(S) et quelques dérivés (SOAP, WebDAV), les bases MySQL et PostgreSQL, ainsi que XMPP. Réalisé en ERLANG, un langage spécialisé dans les applications hautes performances, il ne souffre pas des limites traditionnelles de ce type d'outils, et peut donc simuler un trafic très important. Les scénarios sont écrits en XML. De nombreux exemples ainsi qu’une documentation importante existent sur le site. Il ne propose pas de statistique en temps réel durant l’exécution du test, mais dispose d'un générateur automatique de statistiques permettant d’obtenir des graphes à son terme.
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 69
6.4.1.1.4 Curl-loader
Curl-loader
Version étudiée : 0.56 (stable)
Site Internet de la solution : http://curl-loader.sourceforge.net/
l’application est supportée par Robert Iakobashvili et Michael Moser
Curl-loader (également connu sous le nom "omes-nik" et "davilka") est un outil open-source écrit en langage C, qui permet de tester une application en charge en simulant le comportement de dizaines de milliers de clients HTTP/HTTPS et FTP/FTPS chacun ayant sa propre adresse IP. Contrairement à d'autres outils curl-loader utilise des piles de protocoles écrites en C, à savoir, les piles HTTP et FTP de libcurl et TLS/SSL de openssl, et supporte les connexions et authentification des utilisateurs. Cet outil permet principalement des tests de montée en charge. L'objectif du projet est d'offrir une solution de test open-source puissante et flexible qui soit une réelle alternative aux produits Spirent Avalanche et IXIA IxLoad. L’application est supportée par deux programmeurs indépendants. Curl-loader est distribuée sous License GPL v2
6.4.1.1.5 Conclusion
Les solutions Tsung pour générer de la charge et Curl-loader pour générer des tests de montée en
charge sont les solutions open source les plus performantes, les deux autres solutions ont l’avantage de la
simplicité mais sont limités au niveau de la charge. Elles peuvent être utiles pour générer du trafic.
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 70
6.5 Les solutions matérielles
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 71
6.6 Un exemple de fiche de tests
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 72
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 73
6.7 Modèle de fichier de synthèse d’une campagne de test
IPTAX PERFORMANCE TEST REPORT
IPTAX Performance test Results
CLIENT : Movistar ORIGINATOR : INTEGRATION & SUPPORT
PLATFORM: TESTER : Gilles Lefebvre
SOFTWARE: 1-46 DATE :
Approvals Function IPTAX Validation Manager
Name
TEST CAMPAIGN SUMMARY Number of Test
total
Numb. of Test performed Number of
Test OK
Number of
Test NOK
Number of Test
POK
Compliance
%(Nb test OK /Nb test
performed)
0 0 0 0 0 not started
LIST OF PROBLEMS
Problem reference System impacted Gravity Problem description
CLIENT
Reference
Evistel reference (IPTAX or NETWORK) (G0 > G4)
IPTAX G3
Création d’un simulateur de charge pour le logiciel IPTAX Sujet : Amélioration et développement des outils de test d’Evistel
Page 74
TEST CAMPAIGN DETAILED RESULTS
Priority P0=Urgent
P1=Normal
P2=BckGrd
NIS=NotInScope
Result OK=Pass,
NOK=Fail (G0,G1,G2),
POK=Fail (G3,G4),
INC=Inconclusive, NP=Not Performed,NA=Not applicable
Section Test Title Priority Result Comments
Test type 1 Scalability tests
1.1 PT1-MC1 : Simulate 200 000 mobile users - Increase of 7500 users between two thresholds
P0 NP
Test type 2 Load tests
2.1 PT2-C1 : Check the performances deterioration is regular (no sharp changes in
performances) when packet size increases. P0 NP
2.2 PT8-C2 : Simulate 40000 mobile users performing HTTP and HTTPS connections P0 NP
2.3 PT9-C3 : Check the ability to filter IP addresses during a load tests P0 NP
Test type 3 Soak tests
3.1 PT3-E1 : Simulate a background activity of 10000 users during 7 days. P0 NP
Test type 4 Stress tests
4.1 PT4-S1 : Burst test to simulate a peak activity type end of year 25/12-26/12 or 31/12-01/01 around midnight (11h30 - 12h30)
P0 NP
Test type 5 Limit tests
5.1 PT5-L1 : Check the maximum number of radius connections opened P0 NP
5.2 PT6-L2 : Check the ability to open new radius sessions as long as IPTAX limits are not reached and while opened sessions are used to send HTTP packets
P0 NP
5.3 PT7-L3 : Check the maximal number HTTPS opened connections P0 NP
top related