SlideShare une entreprise Scribd logo
Table des matières
Table des figures
Liste des tableaux
Introduction Générale 1
1 Présentation de l’organisme d’accueil 3
1.1 Présentation de l’entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.1 Organigramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.2 Domaines d’intervention . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1.3 Métiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2 Méthodologie de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.1 Définition de la méthodologie Agile . . . . . . . . . . . . . . . . . . . . . 7
1.2.2 Méthodologie AGILE : SCRUM . . . . . . . . . . . . . . . . . . . . . . . 7
2 Etude Préalable 11
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1 Contexte Générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.1 Introduction à l’assurance qualité . . . . . . . . . . . . . . . . . . . . . . 12
2.1.2 Introduction auw tests logiciel . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.3 Les Bugs (ou les anomalies) . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1.3.1 Qu’est-ce qu’un Bug ? . . . . . . . . . . . . . . . . . . . . . . . 14
2.1.3.2 Qualification de la gravité des anomalies : . . . . . . . . . . . . 15
2.1.3.3 Les sources des Bugs logiciels . . . . . . . . . . . . . . . . . . . 15
2.1.4 Terminologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Table des matières
2.1.5 Processus de test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1.5.1 La planification des tests . . . . . . . . . . . . . . . . . . . . . . 17
2.1.5.2 L’analyse et la conception des tests . . . . . . . . . . . . . . . . 17
2.1.5.3 Implémentation des tests . . . . . . . . . . . . . . . . . . . . . . 18
2.1.5.4 Exécution des tests . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.1.5.5 Evaluation, Reporting et clôture . . . . . . . . . . . . . . . . . 18
2.2 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3 Présentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.1 Description du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.2 Les objectifs du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.4 Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.4.1 Redmine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4.2 Testlink : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.4.3 Inconvénient de TestLink . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.5 Application similaire de l’outil de gestion des tests . . . . . . . . . . . . . . . . . 23
2.5.1 Les outils proposés par les grands editeurs comme HP. . . . . . . . . . . 23
2.5.1.1 IBM Rational Quality Manager . . . . . . . . . . . . . . . . . . 24
2.5.1.2 Microsoft Test Manager . . . . . . . . . . . . . . . . . . . . . . 24
2.5.1.3 HP Quality Center . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.5.2 Les outils Open source . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.5.2.1 Squash TM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.5.2.2 TestRail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3 Conception de “TestLab - Proxym Group” 31
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.1 L’outil de modélisation : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2 Les Diagrammes UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.2.1 Le Modèle des cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . 32
3.2.1.1 Identification des acteurs : . . . . . . . . . . . . . . . . . . . . . 32
3.2.2 Diagramme des cas d’utilisation global : . . . . . . . . . . . . . . . . . . 33
3.2.3 Diagramme de cas d’utilisation de l,’invité . . . . . . . . . . . . . . . . . 34
3.2.4 Diagramme de cas d’utilisation du Testeur . . . . . . . . . . . . . . . . . 35
3.2.5 Diagramme de cas d’utilisation de Concepteur de test . . . . . . . . . . . 35
3.2.6 Diagramme de cas d’utilisation d’administrateur . . . . . . . . . . . . . . 36
3.3 Diagramme de classes statique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.4 Diagramme de déploiement : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.5 Diagramme de séquence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Table des matières
4 Réalisation de “TestLab - Proxym Group” 45
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.1 Environnement de développement . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.1.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.1.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.2 Environnement de programmation . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2.1 PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2.2 HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2.3 CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2.4 JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.2.5 Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.2.6 ReactJs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.2.7 Silex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.3 Système de gestion de la base de données relationnel . . . . . . . . . . . . . . . 49
4.3.1 MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.3.2 PhpMyAdmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.4 Architecture Logicielle du système : . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.4.1 Protocole et formats de données : . . . . . . . . . . . . . . . . . . . . . . 50
4.4.1.1 Protocole de communication . . . . . . . . . . . . . . . . . . . . 50
4.4.1.2 Format de données communiquées . . . . . . . . . . . . . . . . 50
4.4.2 Sécurité et droit d’accès a API : . . . . . . . . . . . . . . . . . . . . . . . 50
4.5 Composition de la page : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.6 Maquettes du site : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.7 Les IHM de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.7.1 Administrateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.7.1.1 Interface d’authentification . . . . . . . . . . . . . . . . . . . . 53
4.7.1.2 Interface page d’acceuil . . . . . . . . . . . . . . . . . . . . . . 54
4.7.1.3 Interface de Gérer Les Projets du Tests . . . . . . . . . . . . . . 55
4.7.1.4 Interface de gérer les utlisateurs . . . . . . . . . . . . . . . . . . 56
4.7.1.5 Interface de Gérer les roles . . . . . . . . . . . . . . . . . . . . . 57
4.7.1.6 Interface de suivi de test . . . . . . . . . . . . . . . . . . . . . . 57
4.7.2 Concepteur de test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.7.2.1 Interface affectation des members sur projet de test . . . . . . . 58
4.7.2.2 Interface affectation des envirement de test . . . . . . . . . . . 58
4.7.2.3 Interface de gérer d’exigence . . . . . . . . . . . . . . . . . . . . 59
4.7.2.4 Interface de gérer la plan de test . . . . . . . . . . . . . . . . . 59
4.7.2.5 Interface de gérer la campagne de test . . . . . . . . . . . . . . 60
4.7.2.6 Interface de gérer rapport de test . . . . . . . . . . . . . . . . . 60
Table des matières
4.7.3 Testeur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.7.3.1 Interface de visualisation de campagne de test . . . . . . . . . . 61
4.7.3.2 Interface de noter resultat campagne de test . . . . . . . . . . . 62
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Conclusion Générale 64
Bibliographie 66
Annexes 70
Annexe 1 « Pour aller plus loin » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Annexe A : Dictionnaire des attributs . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Annexe B : publiéer sur server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Annexe C : Quelques APIs utilisé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Table des figures
1.1 Proxym Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Histoire de PROXYM-IT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Organisme interne de Proxym-IT . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Domaines d’intervention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5 vue globale de SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.6 Processus de SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1 La chaîne de l’erreur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2 Processus de test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3 logo Test Lab - Proxym Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.4 capture d’écran de gestion tickets . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.5 Page d’acceuil de TestLink’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.6 tableau de bord IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.7 resultat de test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.8 Module Exigences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.9 Module Plan de test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.10 Exécutions des tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.11 Module Ergonomie interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.1 Capture d’écran Microsoft Visio . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.2 Diagramme des cas d’utilisation global . . . . . . . . . . . . . . . . . . . . . . . 34
3.3 Diagramme des cas d’utilisation d’invité . . . . . . . . . . . . . . . . . . . . . . 34
3.4 Diagramme des cas d’utilisation du testeur . . . . . . . . . . . . . . . . . . . . . 35
3.5 Diagramme des cas d’utilisation de concepteur de test . . . . . . . . . . . . . . . 36
3.6 Diagramme des cas d’utilisation d’administrateur . . . . . . . . . . . . . . . . . 37
3.7 digramme de classes statisque . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Table des figures
3.8 Digramme de déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.9 Diagramme de séquence d’authentification . . . . . . . . . . . . . . . . . . . . . 40
3.10 Diagramme de séquence d’ajout de nouveau utilisateur . . . . . . . . . . . . . . 41
3.11 Diagramme de séquence d’affectation des membres du l’équipe du projet de test 42
3.12 Diagramme de séquence de visualisation de projet de test . . . . . . . . . . . . 43
4.1 architecture du systeme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.2 structure d’un jeton jwt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.3 Composition de la page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.4 Quelque Exemple De Maquette . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.5 Aperçu de l’interface d’identification . . . . . . . . . . . . . . . . . . . . . . . . 54
4.6 Aperçu de l’interface de page d’acceuil . . . . . . . . . . . . . . . . . . . . . . . 55
4.7 Apercu de l’interface de gérer les projes du tests . . . . . . . . . . . . . . . . . . 56
4.8 Aperçu de l’interface de gérer les utlisateurs . . . . . . . . . . . . . . . . . . . . 56
4.9 Aperçu de l’interface de gérer les roles . . . . . . . . . . . . . . . . . . . . . . . 57
4.10 Aperçu de l’interface de suivi de test . . . . . . . . . . . . . . . . . . . . . . . . 57
4.11 Aperçu de l’interface d’affaction de smembers d’équipe . . . . . . . . . . . . . . 58
4.12 Aperçu de l’interface d’affectation des envirement de test . . . . . . . . . . . . . 58
4.13 Aperçu de l’interface de gérer d’écigence . . . . . . . . . . . . . . . . . . . . . . 59
4.14 Aperçu de l’interface de gérer la plan de test . . . . . . . . . . . . . . . . . . . . 59
4.15 Aperçu de l’interface de gérer la campagne de test . . . . . . . . . . . . . . . . . 60
4.16 Aperçu de l’interface de gérer rapport de test . . . . . . . . . . . . . . . . . . . 60
4.17 Aperçu de l’interface de visualisation details de campagne de test . . . . . . . . 61
4.18 Aperçu de l’interface de noter resultat . . . . . . . . . . . . . . . . . . . . . . . 62
Liste des tableaux
1.1 Mot clés de La méthodologie SCRUM . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1 les différents niveaux d’anomalies . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1 Description détaillée des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
réaliser une plateforme d’automatisation et de génération des rapports de test
Introduction Générale
De nos jours, tout client a besoin de s’assurer que le produit qu’il compte s’offrir répondra bien
à ses attentes. Cette évidence générale s’applique aussi le marché informatique dans le besoin
est l’assurance qualité.
L’assurance qualité est, selon la définition ISO 9000, la partie du management qui donne
confiance en ce que les exigences de la qualité soient satisfaites. Elle constitue une garantie
de la conformité du logiciel aux normes de la qualité et s’identifie sous la forme d’un document
écrit, qui présente toute la politique qualité suivie tout au long de la production. En général,
l’assurance qualité remplit deux principales fonctions :
— Donner confiance au client et lui rassurer de la validité du logiciel.
— Permettre de s’assurer la validité de chaque étape du développement, et ainsi de prévenir
tout dysfonctionnement de la qualité.
Assurer le développement ou la maintenance de logiciels n’est pas une tâche facile. Les normes
sont définies de la façon afin de maximiser la performance de la qualité, mais les clients et les
développeurs sont souvent laissés à eux-mêmes pour décider de la manière dont ils pourraient
améliorer pratiquement la situation : C’est la problématique d’assurance qualité logicielle.
L’assurance qualité logicielle est un ensemble d’activités planifiées et systématiques de toutes les
actions nécessaires pour fournir une assurance suffisante adaptée aux exigences et aux attentes
établies. Ce concept sert à la fois des objectifs internes et externes :
— En interne, elles visent à donner confiance en sa stratégie de la direction et à maintenir
le niveau de compétence de l’entreprise.
— En externe, elles permettent d’obtenir la confiance des clients.
Dans ce contexte, on se propose de créer un processus automatisé de gestion de tests qui a pour
rôle de simplifier les tâches du service QA en tenant compte en premier lieu de la sécuriser des
droits d’accès dans les projets de tests, de générer des rapports de tests et de suivre des tests.
en second lieu de tracibiliter de chaque phase de déroulement des tests.
1
Introduction Générale
C’est dans ce cadre que se situe mon projet de fin d’études intitulé : « Conception et déve-
loppement d’un outil de gestion des tests » dont l’objectif est de concevoir une plateforme
appelée « TestLab - Proxym Group » dédiée à l’équipe assurance qualité.
En conséquence, ce rapport s’articule autour de quatre chapitres comme suit :
Le premier chapitre « présentation de l’organisme d’acceuil » consiste à présenter l’organisme
d’accueil ainsi qu’une brève description sur la methode agile SCRUN.
Le second chapitre « étude préalable » permet de placer le projet dans son contexte général en
présentant la problématique ainsi qu’une brève description du projet.
Le troieme chapitre, « conception de l’application » illustre la partie conception de notre ap-
plication de point de vue statique et dynamique et expose les différentes tables formant notre
base des données.
Enfin ,le dernier chapitre « réalisation de l’application » détaille tous les outils utilisés pour le
développement de notre application ainsi que quelques captures d’écran de la version finale de
notre plateforme.
2
réaliser une plateforme d’automatisation et de génération des rapports de test
1Présentation de l’organisme d’accueil
1.1 Présentation de l’entreprise
PROXYM-IT est une société, de services informatiques, fondée en janvier 2006 spécialisée dans
les nouvelles technologies de l’information et de la communication. Sa direction commerciale
est située à Lyon en France alors que sa direction technique est localisée à la technopole de
Sousse en Tunisie. PROXYM-IT dispose d’une équipe de haut niveau composée d’ingénieurs
issus de différentes formations élaborées au sein des Ecoles d’Ingénieurs Tunisiens et Français.
[1]
La figure 1.1 présente les différents groupes de la société PROXYM-Group :
Figure 1.1 – Proxym Group
3
Chapitre 1 Présentation de l’organisme d’accueil
La figure 1.2 représente l’historique d’évolution de l’entreprise .
Figure 1.2 – Histoire de PROXYM-IT
1.1.1 Organigramme
L’organisation interne de PROXYM-IT se compose des départements suivants :
— Direction Générale : La direction générale est constituée d’un PDG fondateur de
PROXYM-IT Wassel Berrayana.
— IT : Le département IT est le responsable de l’installation du réseau interne et de la
réparation du matériel de tous les fonctionnaires de la société. Il valide les architectures
réseau des différents projets développés chez PROXYM-IT.
— DAF : La direction financière est responsable de la gestion de paie de tous les fonction-
naires de PROXYM-IT, de l’achat et de la logistique.
— DRH : La direction Ressources Humaines est le département responsable de tout le volet
RH de la société, des gestions de carrière, des conflits, des formations et de recrutements.
— Proxym-LAB : Le laboratoire Proxym est le nouveau bébé de la société PROXYM-IT.
Son principale rôle est la veille technologique et l’innovation. Il permet la responsabilité
de toutes les études liées à des projets qui nécessitent l’utilisation de nouvelles techno-
logies sur le marché mondial.
— Département de production : Le département de production est responsable à l’im-
plémentation et la réalisation des projets clients. Il est organisé sous la logique d’une
4
Chapitre 1 Présentation de l’organisme d’accueil
organisation matricielle et Il est constitué de pôles fonctionnels (mobile First, E-Business,
Mobilité, Centre de services). Chaque pôle est constitué de développeurs, experts, consul-
tants et concepteurs gérés par un responsable de pôle . La responsabilité principale de
ce dernier est de maintenir et assurer l’évolution technique de ses ressources.
— PMO (Projet manager Office) : Ce département est constituée des chefs de projets,
des responsables qualité, des consultants et des designers . Aussi il est responsable de la
gestion des projets clients au sein de PROXYM-IT.
la figure 1.3 illustrée une vue globale sur l’organisme interne de la société Proxym-IT :
Figure 1.3 – Organisme interne de Proxym-IT
1.1.2 Domaines d’intervention
La figure 1.4 décrit les différentes étapes d’un projet informatique réaliser par PROXYM-IT.
5
Chapitre 1 Présentation de l’organisme d’accueil
Figure 1.4 – Domaines d’intervention
1.1.3 Métiers
PROXYM-IT a développé une expertise dans les domaines suivants :
Solutions E-Commerce
Sites & applications Mobile et web
E-Gov E-Admin
Réseaux Sociaux d’entreprises
Solutions d’entreprises
ERPs Médicaux
Banking
6
Chapitre 1 Présentation de l’organisme d’accueil
1.2 Méthodologie de travail
Chaque personne peut songer à une idée, peut résoudre un problème et trouver des solutions
pour faciliter n’importe quelle tâche.
C’est pour cela qu’on doit opter pour les solutions les plus optimales pour avoir recours à une
méthodologie efficace qui permet de gérer un cycle de vie d’un projet.
1.2.1 Définition de la méthodologie Agile
Une méthodologie agile est une méthode de développement informatique permettant de conce-
voir des logiciels en impliquant au maximum le client. Elle vise la satisfaction réelle du besoin
du client. Avec l’utilisation de la méthode agile les phases sont simplifiées afin d’en raccourcir
la durée. Elle se base sur la notion de communauté de projet dans laquelle les développeurs et
les utilisateurs sont présents en permanence pour exprimer ou répondre à une question liée au
projet. Grâce aux méthodes agiles, le client piloté à part entière de son projet et obtient très
vite une première mise en production de son logiciel. [2]
Cette méthode se base sur des cycles courts et permet de découper le projet en petits blocs et
les hiérarchiser en fonction des besoins.
1.2.2 Méthodologie AGILE : SCRUM
La méthode SCRUM est une méthode agile, crée en 2002, dont le nom est un terme emprunté
au rugby qui signifie « la mêlée » qui permet de produire un logiciel dans la durée la plus
courte.
Afin de comprendre cette méthodologie on a établi le tableau 1.1 pour définir des mots clés qui
vont nous servir tout au long du projet et de ce rapport.
7
Chapitre 1 Présentation de l’organisme d’accueil
Terme Définition
Backlog du Produit Définition des besoins fonctionnels sous forme de « user story »
Backlog de Sprint Liste des tâches à implémenter dans un sprint, classées par importance et état
Burn-Down Chart Diagramme permettant à suivre l’état d’avancement du projet
Produit Partiel Résultat du Sprint Testé et potentiellement livrable
SCRUMQuotidien Le SCRUM meeting est une réunion d’une durée de 15 minutes, organisée
quotidiennement, en position debout
Table 1.1 – Mot clés de La méthodologie SCRUM
La figure 1.5 donne une vue globale de SCRUM en utilisant les mots clés qu’on vient de
définir :
Figure 1.5 – vue globale de SCRUM
Ce processus s’articule en effet autour d’une équipe soudée, qui cherche à atteindre un but.
Cette méthodologie se progresse par une série d’itérations appelées sprints, qui durent de deux
à quatre semaines. Le produit envisagé est conçu, codé et testé pendant ce sprint.
A chaque fin de sprint, on peut voir fonctionnement le produit et décider soit de le livrer, soit
de continuer à l’améliorer pendant un autre sprint. la figure 1.6 suivant resume le processus sur
lequel est basé SCRUM :
8
Chapitre 1 Présentation de l’organisme d’accueil
Figure 1.6 – Processus de SCRUM
Durant le développement d’un projet avec la méthode SCRUM il y a une interaction avec
plusieurs intervenants :
1. Le « Product Owner » qui porte la vision du produit à réaliser.
2. Le « SCRUM Master » est la personne chargée de veiller à la mise en application de la
méthode et au respect de ses objectifs.
3. « L’équipe de développement » qui réalise le produit.
Conclusion
Dans ce premier chapitre, nous avons présenté l’entreprise d’accueil ainsi que la methodologie
de travail.
9
réaliser une plateforme d’automatisation et de génération des rapports de test
2Etude Préalable
Introduction
Dans ce chapitre, en premier lieu on présentera le contexte général du projet, le processus de
tests et on finira cette partie par l’étude existant avant de conclurer.
2.1 Contexte Générale
À l’heure actuelle, les entreprises informatiques, commencent à prendre conscience dans le ma-
nagement du projet de l’importance de cette phase de test .Cette phase de teste est caractérisé
par une stratégie de recette fonctionnelle et la mettre en œuvre pour assurer que le projet
reste dans la bonne direction. Cependant ces entreprises de développement sont obligées de
choisir des choix des méthodes et des outils de tests, et faire appel à des professionnels pour
l’implémentation de cette stratégie de test.
Ces méthodes de test s’évoluent ces dernières années, or des nombreux outils ont été conçus
pour aider les testeurs à effectuer leurs démarches. D’où se pose les questions suivantes :
— Comment garantir la qualité de projet pour le client ?
— Qu’est-ce que test logiciel ?
— Comment définir l’activité de test dans un projet logiciel ?
11
Chapitre 2 Etude Préalable
2.1.1 Introduction à l’assurance qualité
La planification de tests commence lors de la conception des applications ou de leur implé-
mentation. Toutefois, les activités de tests et de vérification de la qualité ne se limitent pas au
test du code des applications : la vérification de la qualité doit commencer par la validation de
spécification (par exemple : la complétude et la testabilité).
Tout d’abord, voici le contexte : Qu’est-ce que la qualité ?
L’International organisation for standardization (ISO) définissait la qualité « comme l’ensemble
des caractéristiques d’une entité qui lui confèrent l’aptitude à satisfaire des besoins exprimés et impli-
cites ». Plus récemment, elle a complété cette définition qui est devenue la suivante : la qualité
est « l’aptitude d’un ensemble de caractéristiques intrinsèques d’un produit, d’un système ou d’un
processus à satisfaire les exigences des clients et autres parties intéressées ». [3]
Les entreprises ont tendance à employer des métriques basées sur le nombre de bogues détectes :
ce n’est pas l’objectif du test de logiciels. L’objectif est vérifié que le système réagit conformé-
ment aux exigences et qu’il se comportera de même dans son environnement de production.
En s’appuyant sur les meilleures pratiques en matière, cela permet c’identifier la source du
défaut et d’en supprimer la cause, plutôt que de supprimer plusieurs fois le même défaut. C’est
le cœur de l’assurance qualité.
2.1.2 Introduction auw tests logiciel
Le test du logiciel est une approche dynamique de la vérification, destinée à s’assurer que ce
logiciel possède effectivement les caractéristiques requises pour son contexte d’utilisation. Toute
fabrication de produit suit les étapes suivantes :
1. Conception
2. Réalisation
3. Test
« Le test », est un sujet vaste et complexe : les applications sont variées, les outils sont différents,
cependant, les tests doivent être organisés et menés selon une démarche. .
12
Chapitre 2 Etude Préalable
Qu’est-ce que tester ?
Il existe plusieurs définitions sur l’activité de test logiciel : « Le test d’un logiciel est une activité
qui fait partie du processus de développement. Il est mené selon les règles de l’assurance de la qualité
et débute une fois que l’activité de programmation est terminée. Il s’intéresse aussi bien au code
source qu’au comportement du logiciel. Son objectif consiste à minimiser les chances d’apparitions
d’une anomalie avec des moyens automatiques ou manuels qui visent à détecter aussi bien les diverses
anomalies possibles que les éventuels défauts qui les provoqueraient ». [4]
Différents types de tests d’un logiciel
Un test désigne une procédure de vérification partielle d’un système pour détecter les anomalies.
Ils sont très souvent effectués sur deux niveaux :
1. Le niveau structurel : C’est-à-dire au niveau du code.
2. Le niveau fonctionnel : Représenté par des tests portés sur les fonctionnalités de bas.
Les tests fonctionnels étant appliqués sur plusieurs niveaux, il est donc préférable de présenter
les tests d’une manière générale, suivant la manière dont ils sont effectués. Il peut présenter
donc sous deux catégories : ’Les tests types boîtes blanches’ et ’Les tests types boîtes
noires’. [5]
Les tests types boîtes blanches
Les tests types boîtes blanches sont des tests effectués au niveau de l’implémentation d’une
application/module. Ils vont donc tenir compte de la structure du composant qui sera testé,
c’est-à-dire des algorithmes utilisés, typages requis lors des appels de méthodes, etc. Voici trois
tests importants pour valider la structure d’une application :
— Les tests unitaires : Ce type de tests est utilisé pour valider des structures au niveau
du code (méthodes, classes...).
— Les tests d’intégrations : Ce type de tests est utilisé pour vérifier la cohésion des
interfaces des modules et valide leurs communications.
— Les tests de performances : Ce type de tests est utilisé pour permettre de tester la
qualité du code développé.
13
Chapitre 2 Etude Préalable
Les tests types boîtes noires
Les tests types boîtes noires sont des tests qui sont mis en place, sans avoir connaissance
de la manière dont l’objet testé a été implémenté. Ils vont ainsi être utilisés pour valider les
fonctionnalités fournies par l’application et donc les exigences établies par le client. Voici deux
importants tests permettant de valider la fonctionnelle d’une application :
— Les tests fonctionnels : Ce type de tests est utilisé pour vérifier la conformité de
l’application développée avec le cahier des charges initial. Ils sont donc basés sur les
spécifications fonctionnelles et techniques.
— Les tests de non-régression : Ce type de tests est utilisé pour vérifier que des modi-
fications n’ont pas altérées le fonctionnent de l’application.
2.1.3 Les Bugs (ou les anomalies)
Le problème fondamental du développement des logiciels est « le problème de l’erreur ». De
nombreux défauts et anomalies pouvant affecter un logiciel. En effet, dans cette partie, nous
porterons notre attention sur les sources des bugs logiciels, ensuite les niveaux de la gravité des
anomalies et nous terminerons par quelques exemples de bugs et leurs conséquences.
2.1.3.1 Qu’est-ce qu’un Bug ?
Le terme BUG est utilisé pour désigner : Erreur =>Défaut => Anomalie.
Figure 2.1 – La chaîne de l’erreur
14
Chapitre 2 Etude Préalable
— Erreur : « action humaine produisant un résultat incorrect ». [6]
— Défaut : « Une imperfection dans un composant ou un système qui peut conduire
à ce qu’un composant ou un système n’exécute pas les fonctions requises, par exemple
une instruction ou une définition de données incorrecte. Un défaut, si rencontré lors de
l’exécution, peut causer la défaillance d’un composant ou d’un système ». [6]
— Anomalie : « toute condition qui dévie des attentes basées sur les exigences de
spécifications, documents de conception, documents utilisateurs, standards etc., ou des
perceptions ou expériences de quelqu’un. Les anomalies peuvent être trouvées pendant,
mais pas uniquement, les revues, tests, analyses, compilations ou utilisation des produits
logiciels ou de la documentation applicable. [6]
2.1.3.2 Qualification de la gravité des anomalies :
Il existe plusieurs niveaux d’anomalies illustrés sur ce tableau ci-dessous :
Gravité Description
Bloquante
L’anomalie provoque un arrêt complet du système ou une fonctionnalité
indispensable est inexploitable (pour des raisons fonctionnelles ou de performance,
Aucune solution de contournement.
Majeure
Une fonctionnalité indispensable est partiellement inopérante sans bloquer
l’exploitation de l’outil. L’application peut continue.
Mineure
Une fonctionnalité non essentielle présente des dysfonctionnements sans bloquer
l’exploitation de l’outil.
Table 2.1 – les différents niveaux d’anomalies
2.1.3.3 Les sources des Bugs logiciels
L’origine des bugs informatiques viennent des erreurs humaines tel que :
— Une incompréhension du besoin et des exigences de l’organisation commanditaire
— Manque du savoir faire et d’expertise,
— Manque des compétences informatiques pour comprendre l’environnement de dévelop-
pement et de l’exécution, La complexité des plates-formes
— Une faible puissance des systèmes informatisés.
15
Chapitre 2 Etude Préalable
2.1.4 Terminologie
Avant de passer à la suite, précisons quelques définitions importantes de vocabulaire. [6]
— Objet de tests : le composant ou système qui doit être testé.
— Objectif de tests : une raison ou but pour la conception et l‘exécution d‘un test.
— Anomalie : On parle d’anomalie quand le logiciel ne fait pas ce qu’on lui a demandé,
qu’il se bloque.
— Exigence : besoin ou attente formulé(e), habituellement implicite, ou imposé(e)
— Plan de test : un document décrivant l’étendue, l’approche, les ressources et le planning
des activités de test prévues. Il identifie entre autres les éléments et caractéristiques à
tester, qui fera chaque tâche, le degré d’indépendance des testeurs, l’environnement de
test, les techniques de conception des tests et les techniques de mesure des tests à utiliser,
et tout risque nécessitant des plans de contingence.
— Scenario de test (séquence de test) : C’est le concept qui précise la fonction à tester.
La description y est précise et se réfère pour la recette fonctionnelle aux exigences de
client. Un scénario de test est composé d’un ou plusieurs cas de tests.
— Recette fonctionnelle
— Cas de test : C’est un chemin fonctionnel à mettre en œuvre pour atteindre un objectif
de test. Un cas de test se définit par le jeu d’essai à mettre en œuvre, les étapes de tests
sont exécutées et les résultats attendus.
— Etape de test (pas de test) : un ensemble de valeurs d’entrées (jeu de données
de tests), de pré-conditions d’exécution, de résultats attendus et de post conditions
d’exécution, développées pour un objectif ou une condition de tests particulière, tel
qu’exécuter un chemin particulier d’un programme ou vérifier le respect d’une exigence
spécifique
— Jeu de données de test : Ce sont les données nécessaires pour l’exécution d’un cas
de test. Ces données affectent où sont affectées par le logiciel testé. Elles sont stockées
dans la base de données de tests.
— Campagne de test : C’est l’élément le plus important et qui consiste à organiser les
tests. Une campagne de test décrit quels sont les scénarios qui seront testés et donc
enchaînés les uns aux autres.
— Processus de test : processus consistant en toutes les activités du cycle de vie, statiques
et dynamiques, concernant la planification et l’évaluation de produits logiciels, pour
déterminer s’ils satisfont aux exigences, pour démontrer qu’ils sont aptes aux objectifs
et pour en détecter des anomalies.
16
Chapitre 2 Etude Préalable
2.1.5 Processus de test
Le test n’est pas limité à l’exécution du logiciel dans le but d’identifier des défaillances : il est
aussi nécessaire de planifier, définir des objectifs, concevoir des conditions de tests, prévoir des
données de tests, et définir des critères de début et d’arrêt, des environnements de tests et bien
sûr de contrôler tout cela. [7]
Le processus de test se décompose en différentes activités :
Figure 2.2 – Processus de test
2.1.5.1 La planification des tests
Avant toute activité humaine, il est nécessaire d’organiser et planifier les activités à effectuer.
Ceci vaut aussi pour le test des logiciels et systèmes. Elle consiste en la définition d’objectifs
de tests et en la spécification des activités de tests à exécuter pour atteindre ces objectifs.
2.1.5.2 L’analyse et la conception des tests
La phase d’analyse et de conception est celle où les objectifs de tests généraux – définis par
l’entreprise et au niveau du plan de tests– sont utilisés pour concevoir les conditions de tests
de l’application logicielle. Les objectifs généraux identifiés lors de la planification seront utilisés
17
Chapitre 2 Etude Préalable
pour construire les dossiers, conditions et procédures de tests. La conception des tests consiste
à transformer des objectifs de tests en conditions de tests tangibles, puis en cas de tests. Les
conditions de tests sont généralement abstraites alors que les cas de tests sont généralement
concrets.
2.1.5.3 Implémentation des tests
L’implémentation des tests consiste en la conversion des conditions de tests en cas de tests et
en procédures de tests, avec des données de tests spécifiques et des résultats attendus précis.
Des précisions sur l’environnement et les données de tests, ainsi que sur la séquences des cas
de tests sont nécessaires afin d’anticiper l’exécution des tests.
2.1.5.4 Exécution des tests
L’exécution des tests, dans l’environnement de tests, sur le logiciel ou système à tester, de façon
à découvrir des différences entre les résultats attendus et les résultats obtenus, inclut les tâches
liées à l’exécution des cas de tests, procédures de tests et suites de test.
2.1.5.5 Evaluation, Reporting et clôture
Evaluation Du point de vue de la procédure de tests, le suivi d’avancement des tests implique
la collecte d’informations. Les métriques vont prendre en compte les critères de sorties, tels que
celles validées durant la planification.
Reporting Le test est une activité dont les résultats intéressent de nombreuses parties pre-
nantes :
— Les testeurs, pour évaluer leurs propres prestations ;
— Les responsables qualité pour déterminer les améliorations à entreprendre dans les pro-
cessus, que ce soit lors des phases d’identification d’exigences, de revue, de conception
ou de tests.
Ces parties prenantes doivent être informées, par le biais de rapports d’avancement, de statis-
tiques et de graphiques, pour répondre à leurs interrogations, et leur permettre de prendre des
décisions en ayant les informations adéquates.
18
Chapitre 2 Etude Préalable
Clôture Une fois le logiciel ou système considéré comme livrable (pour une phase suivante de
tests ou pour mise en production), ou le projet de test terminé (avec succès ou annulé), il est
nécessaire de clôturer les activités de cette phase de tests.
2.2 Problématique
Assurer la qualité des systèmes opérationnels d’un organisme n’est pas une tâche facile.Les
normes sont définissaient des façons de faire pour maximiser la performance, mais les gestion-
naires et les employés sont principalement laissés à eux-mêmes pour décider comment améliorer
pratiquement la situation.
Ils font face à plusieurs problèmes :
— Pression de plus en plus élevée de livraisons rapides et de qualité.
— Augmentation de l’imposition de normes nationales, internationales, professionnelles et
de domaines.
— Multiplicité des plates-formes et des techniques.
Traditionnellement, la liste des tests à réaliser par le testeur est décrite dans les documents
qui seront traités manuellement et les résultats à la fin seront regroupés et rendus au chef de
test dans le format de rapport traité à la main ou tapé dans un éditeur de texte. Ces tâches
peuvent être responsables de perte du temps, et de diminuer l’intégrité des informations tests
si un incident se produit.
2.3 Présentation du projet
Le stage a été réalisé au sein de la société Proxym-IT durant la période allant du 15 février
au 15 juin. Notre stage, nous a permis de saisir l’opportunité de travailler sur l’un des micro-
Framework PHP les plus populaires « Silex » et biloéthique Javascript « ReactJS ».
2.3.1 Description du projet
Partant de ces besoins, la société PRPXYM-IT décidée de concevoir et de réaliser une plateforme
d’automatisation et de génération des rapports de test destinée à l’équipe assurance qualité
(QA) bien particulière gestion de tests, création et archivage des rapports de test et facilité les
tâches du service QA.
19
Chapitre 2 Etude Préalable
Notre plateforme est intitulée "Test Lab - Proxym Group".
Figure 2.3 – logo Test Lab - Proxym Group
2.3.2 Les objectifs du projet
Dans cette partie, nous identifions les objectifs qui expriment les actions que le système doit
effectuer. Notre système réalise les tâches suivantes :
— Gérer de projet de test : Cette tache permet de gérer les projets test dans l’entreprise,
d’ajouter des nouveaux projets à partir private plate-forme de l’entreprise, archiver les
anciens et supprimer ce quand n’a pas besoin.
— Gestion des plans de test : Cette tache permet de gérer les exigences d’un logiciel
tout au long de son cycle de vie, de décrire des scénarios et des cas de tests assurant la va-
lidation de ces exigences , enfin il permet de suivre l’ensemble des exceptions rencontrées
lors des tests.
— Gestion et Suivi des anomalies détectées : cette tache permet de gérer les anomalies
détectées dans la phase d’exécution de test, de déclarer et suivire leur état avec les
develepeurs.
— automatisé la génération de rapport : dans chaque étape de déroulement du test,
la plateforme doit offrir un ou plusieurs outils de collections d’informations et de calcul
des statistiques afin de générer un rapport complet sous format word.
— Interfaçage avec les applications tierces : Importer / Exporter des informations à
partir d’autres plateformes externes.
2.4 Etude de l’existant
L’étude de l’existant est une étape préliminaire qui nous a permis de dégager les problématiques
et de ressortir les vrais besoins de l’entreprise, actuellement, l’équipe assurance qualité de
Proxym-IT utilise ‘Redmine’ pour la gestion de projets et ‘teslink’ pour la gestion de tests.
Néanmoins, il n’y a aucune communication automatique entre ces deux outils.
20
Chapitre 2 Etude Préalable
C’est pour cela, il n’est pas possible de consulter les détails des projets créés dans Redmine via
testlink. De plus, au cas d’une anomalie les testeurs sont obligés de copier manuellement les
résultats de tests ainsi que leurs suivis à partir de testlink dans Redmine .
L’outil testlink est utilisé également pour la génération des rapports de tests, mais les testeurs
doivent les enrichir manuellement par d’autres informations pour répondre aux exigences de
l’équipe assurance qualité.
2.4.1 Redmine
Redmine est une application web libre de gestion de projets complète en mode web, développée
en Ruby sur la base du framework Ruby on Rails. Il a été créé par Jean-Philippe Lang. D’autres
développeurs venant de la communauté des utilisateurs de Redmine contribuent depuis au
projet. [8]
Il est simple à utiliser, à administrer et à déployer et contient de nombreuses fonctionnalités
puissantes :
— Projets multiples
— Suivi des tickets
— Intégration de contrôle de source (SVN, Git, etc.)
— Rôles et autorisations
— Wiki de projet
21
Chapitre 2 Etude Préalable
Figure 2.4 – capture d’écran de gestion tickets
2.4.2 Testlink :
TestLink est un outil basé sur le Web, utilisé pour la gestion des tests. Il permet de créer des
plans de test, de prioriser les tests, affecter la conduction de test pour les utilisateurs et suivre
les progrès. Il permet également de créer divers rapports et statistiques, a le système de gestion
des exigences, interagit avec des outils de suivi des bogues. [9]
TestLink permet de :
— Gérer plusieurs comptes,
— S’organiser efficacement les rôles lors des tests (qui effectuent le test, qui supervise, qui
valide...)
— Générer dynamiquement de nombreux graphiques et rapports de tests
— Cahiers de recette o Document de spécification de tests,
— Diagramme montrant le pourcentage de tests réussis, échoués, bloqués
— Nombre total de bugs pour chaque cas de test
— Gérer les exigences fonctionnelles
Malgré la simplicité de l’interface, certains utilisateurs désapprouvent le côté design et le
trouvent peu convivial ( figure 2.5) .
22
Chapitre 2 Etude Préalable
Figure 2.5 – Page d’acceuil de TestLink’
2.4.3 Inconvénient de TestLink
— Moins de fonctionnalités que les outils payants du marché
— Un peu moins souple que les fichiers (Word, Excel)
— Traduction partielle en français
2.5 Application similaire de l’outil de gestion des tests
Autres outils existent sur le marché permettent de gérer les exigences fonctionnelles afin d’assu-
rer une traçabilité entre exigences et plans de test, nous classerons ces outils en deux familles :
2.5.1 Les outils proposés par les grands editeurs comme HP.
Dans le marché, on dispose de plusieurs outils de gestion de test comme le ‘Microsoft Test
manager’ et ‘IBM Rational Quality’ manager ou nous choisissons d’utiliser le ’HP Quality
Center’ vue son efficacité et sa tendance à aider pour mieux comprendre le terme d’assurance
qualité et mieux expliquer démarche de processus de tests.
23
Chapitre 2 Etude Préalable
2.5.1.1 IBM Rational Quality Manager
IBM Rational Quality Manager est une solution alignée sur les cinq impératifs de la gestion du
cycle de vie des applications : planification intégrée, traçabilité des artefacts connexes, intelli-
gence de développement, automatisation et collaboration, amélioration continue des processus.
[10]
Figure 2.6 – tableau de bord IBM
2.5.1.2 Microsoft Test Manager
Visual Studio Ultimate, Visual Studio Premium et Test Professional incluent Microsoft Test
Manager depuis 2010, pour définir et gérer les plans de test pour les tests système manuels
et automatisés. Ces plans de test sont stockés sur Team Foundation Server (TFS), et sont
étroitement intégrés à ses outils de gestion du cycle de vie des builds et des applications. [11]
Avec Microsoft Test Manager on peut : planifier des tests manuels, planifier des tests d’appli-
cation à partir d’un document Microsoft Excel ou Microsoft Word, suivre la qualité logicielle,
automatiser des tests système, configurer des tests.
24
Chapitre 2 Etude Préalable
Figure 2.7 – resultat de test
2.5.1.3 HP Quality Center
L’outil HP Quality Center, est le plus pratiqué par les consultants parce qu’il permet de ré-
pondre au besoin du client grâce à ses différents modules, ses avantages, et toutes ses fonction-
nalités attendues. [11]
L’outil s’inscrit en phase opérationnelle des tests pour :
— Structurer la formalisation des tests,
— Faciliter la communication entre les acteurs,
— Gérer les anomalies,
— Produire un suivi de l’avancement de la préparation et de l’exécution des tests.
Il permet :
— La capitalisation,
— L’archivage des documents de tests,
— La traçabilité de la couverture de tests,
— La traçabilité de l’exécution des tests.
25
Chapitre 2 Etude Préalable
Module Exigences Il permet de gérer l’étape de la définition des exigences de test , identifier
les différentes exigences de test :
— l’Intégration de l’application dans le SI,
— l’Installation,
— la documentation Conformité fonctionnelle (règles de gestion),
— les tests de charge et de performance,
— la sécurité.
Figure 2.8 – Module Exigences
Module Plan de test Il permet d’effectuer l’étape de la conception des tests : un test doit
être bien précis et relié à une exigence de test.
26
Chapitre 2 Etude Préalable
Figure 2.9 – Module Plan de test
Module Exécutions des tests Il permet la préparation de l’étape de l’exécution de la recette ;
créer un scénario pour chaque processus métier et noterleur resultat.
Figure 2.10 – Exécutions des tests
27
Chapitre 2 Etude Préalable
2.5.2 Les outils Open source
2.5.2.1 Squash TM
Squash TM est le gestionnaire de référentiel de test de la suite open source Squash. Il permet
de gérer les exigences, les scénarios de tests et les campagnes d’exécution, dans un contexte
nativement multi-projet. [13]
— Module Ergonomie interface : Cet outil a une interface intuitive et disponible en
français, anglais, allemand (autres langues possibles) et contient un éditeur de texte
riche permettant la mise en forme avancée des textes saisis (puces, liens hypertexte,
polices, couleurs, images. . .)
Figure 2.11 – Module Ergonomie interface
— Module Reporting : Cet outil permet de générer des rapports d’exécution au format
HTML. Et on détecte quelque type de rapport important :
— Rapport d’exécution du test global.
— Rapport détaillé en cas d’échec d’un test (anomalies)
28
Chapitre 2 Etude Préalable
2.5.2.2 TestRail
TestRail est un logiciel de gestion de cas de test basé sur le Web complet pour gérer efficacement,
suivre et organiser vos efforts de tests de logiciels. Elle permet de suivre : Gérer efficacement
les cas, les plans et les essais ,Augmentez considérablement la productivité des tests et obtenez
des informations en temps réel sur la progression de vos tests. [14]
— Module campagne de test
Pour la plupart des projets, vous commencerez probablement à exécuter plusieurs tests pour
une suite de test particulier au fil du temps. Par exemple, si vous lancez plusieurs versions d’un
logiciel, vous pouvez effectuer une exécution de test pour chaque nouvelle version. De même,
vous pouvez effectuer plusieurs tests pour une campagne de test en particulier en même temps.
Cela peut être judicieux si vous souhaitez exécuter une campagne de test particulière pour
plusieurs configurations (par exemple, différents systèmes d’exploitation). Vous pouvez ensuite
lancer une exécution de test pour chaque configuration différente sur laquelle vous souhaitez
tester.
Les états de test suivants sont disponibles par défaut :
— Non testé : Par défaut, les nouveaux tests ont le statut Non testé. Une fois qu’un
résultat de test a été ajouté à un test, il ne peut plus jamais recevoir l’état non testé.
— Passé : Un test est marqué comme Passé lorsqu’un testeur a vérifié les étapes de test
et les résultats escomptés.
— Échec : Un testeur marque un test comme étant échoué si l’une des étapes de test
spécifiées a entraîné une erreur ou si le résultat attendu diffère du résultat réel du test.
— Bloqué : L’état bloqué est utilisé pour signaler qu’un test ne peut pas être exécuté
actuellement en raison d’une dépendance externe.
Conclusion
Dans ce chapitre, nous avons présenté le cadre général du projet ainsi qu’une brève description
du contexte du sujet. Nous avons aussi présenté le sujet du stage qui nous a été confié. Enfin,
nous avons présenté les applications similaires.
29
réaliser une plateforme d’automatisation et de génération des rapports de test
3Conception de “TestLab - Proxym Group”
Introduction
La conception est la phase la plus importante dans le cycle de développement d’un projet. Elle
permet de mettre en place un modèle sur lequel il faut s’appuyer pour l’implémentation du
système. Elle consiste à identifier les objets du système.
Ces objets nécessitent à identifier. Ainsi nous allons élaborer le diagramme de classe du système
pour décrire sa vue statique. Puis nous allons décrire la vue dynamique par les diagrammes de
déploiement, de séquences.
3.1 L’outil de modélisation :
Notre conception fait l’usage de l’outil Visio Microsoft .
Microsoft Visio
Microsoft Visio (officiellement Microsoft Office Visio) est un logiciel de diagrammes pour Win-
dows qui fait partie de la suite bureautique Microsoft Office mais se vend séparément. On peut
ainsi créer des diagrammes de Gantt et des réseaux de PERT . [15]
31
Chapitre 3 Conception de “TestLab - Proxym Group”
Figure 3.1 – Capture d’écran Microsoft Visio
Microsoft Visio nous donne la possibilité :
— De son implicite d’installation et de prise en main.
— De la possibilité de générer le squelette des classes en languages Java, C++, C#, etc .
— De créer des diagrammes professionnels rapidement avec des formes mises à jour et de
nouveaux outils et des options de mise en forme.
— D’associer des diagrammes à des données dynamiques et interpréter rapidement les don-
nées complexes.
3.2 Les Diagrammes UML
3.2.1 Le Modèle des cas d’utilisation
Les cas d’utilisation (use cases) a pour objectif de décrire sous forme d’actions et de réactions
le comportement d’un système du point de vue d’un utilisateur.
3.2.1.1 Identification des acteurs :
Un acteur est une personne, un matériel ou un logiciel qui interagit avec le système dans le but
de réaliser une ou plusieurs fonctions concernant les cas d’utilisation. Les acteurs en interaction
avec notre système sont :
32
Chapitre 3 Conception de “TestLab - Proxym Group”
L’administrateur Concepteur de test Testeur Invité
Description détaillée des acteurs :
Acteur Définition Rôle
Invité
Cet utilisateur n’appartient pas
à l’équipe QA, il peut être un
chef de projet, un développeur,
un responsable du pôle, etc.
L’invité à la permission de
visualiser les détaille du projet.
Testeur
C’est l’exécuteur des cas de tests.
Il enregistre les anomalies et les
défauts du produit dans l’outil
Le testeur ne peut qu’exécuter
les tests qui lui sont attribués.
Concepteur de test
Cet utilisateur enregistre les
exigences du produit et prépare
les scénarios de tests.
Il a les mêmes autorisations que
le testeur. Néanmoins, il peut
également gérer les plans de
tests, et affecter les membres de
l’équipe dans un projet
L’administrateur
C’est le responsable de test. Il
lance le projet de test et vérifie
les résultats de la fin de chaque
campagne de test et projet de
test
Un administrateur a toutes les
autorisations.
Table 3.1 – Description détaillée des acteurs
3.2.2 Diagramme des cas d’utilisation global :
Les cas d’utilisation permettent de décrire sous forme d’actions et de réactions le système du
point de vue utilisateur. Ils donnent l’image d’une fonctionnalité du système déclenchée par
une simulation d’acteur externe. Ils permettent de spécifier clairement et exhaustivement les
besoins relatifs à chaque type d’utilisateur.
Pour cela, nous avons utilisé les diagrammes des « cas d’utilisation » pour illustrer les fonc-
tionnalités du système, figure 3.2.
33
Chapitre 3 Conception de “TestLab - Proxym Group”
Figure 3.2 – Diagramme des cas d’utilisation global
3.2.3 Diagramme de cas d’utilisation de l,’invité
Le diagramme représenté par la figure 3.3 ci-dessous décrit les différentes actions réalisées par
l’invité.
Figure 3.3 – Diagramme des cas d’utilisation d’invité
34
Chapitre 3 Conception de “TestLab - Proxym Group”
Selon ce diagramme, l’invité peut consulter les détails de projet de test, en effet il peut :
— Visualiser les statistiques d’une campagne de test, des environnements qu’il a testés et
les scénarios de tests.
— Visualiser les statistiques d’un projet de test, consulter les exigences, les anomalies, voir
les rapports de tests et visualiser les membres d’équipe qui travaillent sur un projet
particulier.
3.2.4 Diagramme de cas d’utilisation du Testeur
Le diagramme représenté ci-dessous par la figure 3.4 décrit les différentes actions réalisées par
le testeur.
Figure 3.4 – Diagramme des cas d’utilisation du testeur
Selon ce diagramme, le testeur peut consulter les détails d’un projet de test, en effet il peut :
— Visualiser les détails d’une campagne, consulter les scénarios de tests et noter leur ré-
sultat.
— Signaler les anomalies et suivre leurs états sur Redmine
3.2.5 Diagramme de cas d’utilisation de Concepteur de test
Le diagramme représenté ci-dessous par la figure 3.5 décrit les différentes actions réalisées par
le concepteur de test.
35
Chapitre 3 Conception de “TestLab - Proxym Group”
Figure 3.5 – Diagramme des cas d’utilisation de concepteur de test
Selon ce diagramme, le concepteur de tests peut gérer processus de test, en effet il peut :
— Préparer ses plans de tests, préparer des scénarios de tests et générer des rapports de
test.
— Gérer les campagnes de tests, attribuer les scénarios a testé ont attribuant les environ-
nements de tests.
— Gérer les exigences d’un projet et générer dossier exigences.
3.2.6 Diagramme de cas d’utilisation d’administrateur
Le diagramme représenté par la figure 3.6 ci-dessous décrit les différentes actions réalisées par
l’administrateur.
36
Chapitre 3 Conception de “TestLab - Proxym Group”
Figure 3.6 – Diagramme des cas d’utilisation d’administrateur
Selon ce diagramme, l’administrateur peut :
— Gérer les projets de tests (consulter, créer, modifier, supprimer et archiver d’un projet
de test).
— Gérer les utilisateurs et leur attribuer leur rôles avec des droits d’accès bien définis.
— Configurer l’authentification avec les plateformes externes (LDAP, TestLink et Red-
mine).
3.3 Diagramme de classes statique
Les diagrammes de classes expriment de manière générale la structure statique d’un système
en termes de classes et de relations entre ces classes. Une classe permet de décrire un ensemble
d’objets (attributs et comportements), tandis qu’une relation permet de faire apparaître des
liens entre ces objets. La classe peut être vue comme la factorisation des éléments communs à
un ensemble d’objets.
En se basant sur ce qui précède, une solution conforme aux besoins exprimés et aux objectifs
déjà fixés se résume dans un diagramme composé des classes suivantes :
37
Chapitre 3 Conception de “TestLab - Proxym Group”
Figure 3.7 – digramme de classes statisque
38
Chapitre 3 Conception de “TestLab - Proxym Group”
3.4 Diagramme de déploiement :
Le diagramme de déploiement est une vue statique qui sert à représenter l’utilisation de l’infra-
structure physique par le système et la manière dont les composants du système sont répartis
ainsi que leurs relations entre eux.
Figure 3.8 – Digramme de déploiement
3.5 Diagramme de séquence
Les diagrammes de séquences sont la présentation graphique des interactions entre les acteurs
et le système selon un ordre chronologique dans la formulation UML. Dans la suite, nous
présentons quelques diagrammes de séquence de notre système.
Scénario d’authentification :
La figure 3.9 illustre le diagramme de séquence de cas d’utilisation ’authentification’
39
Chapitre 3 Conception de “TestLab - Proxym Group”
Figure 3.9 – Diagramme de séquence d’authentification
L’authentification est désormais nécessaire si l’utilisateur veut bénéficier de plus de fonctionna-
lités telles que le suivi des tests. La figure 3.9 montre les étapes qui sont concernées par cette
opération d’authentification, sachant que pour cela il faut déjà avoir créé un compte.
Scénario d’Ajout nouveau utilisateur :
La figure 3.10 illustre le diagramme de séquence de cas d’utilisation ’ajouter nouveau utilisa-
teur’
40
Chapitre 3 Conception de “TestLab - Proxym Group”
Figure 3.10 – Diagramme de séquence d’ajout de nouveau utilisateur
Pour créer un compte le contrôleur vérifie d’abord si les données saisies par l’utilisateur ne
sont pas déjà enregistrées d’où l’opération de lecture simple à partir LDAP afin d’éviter les
redondances. Puis une fois la vérification est terminée avec succès les informations peuvent être
enregistrées dans la table utilisateur.
Scénario affectation des membres du l’équipe du projet de test :
La figure ci-dessous, illustre le diagramme de séquence de cas d’utilisation ’affectation des
membres du l’équipe du projet de test’
41
Chapitre 3 Conception de “TestLab - Proxym Group”
Figure 3.11 – Diagramme de séquence d’affectation des membres du l’équipe du projet de test
Le concepteur de test a la possibilité d’affecter un testeur dans projet, il s’agit d’une opération
effectuée sur la table utilisateur, de la table rôle. Nous avons choisi d’afficher un message de
confirmation avant d’effectuer l’opération dans un souci de nous assurer que l’action n’a pas été
initiée par erreur pour assurer plus de sécurité aux données préalablement sauvegardées par ce
même utilisateur.
Scénario de visualisation de projet de test :
La figure 3.12 illustre le diagramme de séquence de cas d’utilisation ’visualisation de projet de
test’
42
Chapitre 3 Conception de “TestLab - Proxym Group”
Figure 3.12 – Diagramme de séquence de visualisation de projet de test
Un invité peut à tout moment consulter le détail complet d’un projet donné (description, afficher
membre d’équipe et environnement de test).
Conclusion
Dans ce chapitre conception, nous avons présenté la vue statique et dynamique de l’application
à développer à travers des diagrammes UML. Nous avons, ainsi, réussi à concevoir notre modèle
relationnel qui est constitué des différentes tables formant notre base des données.
43
réaliser une plateforme d’automatisation et de génération des rapports de test
4Réalisation de “TestLab - Proxym Group”
Introduction
Une des étapes de la vie d’un projet, aussi importante que la conception, est l’implémentation.
Cette étape constitue la phase d’achèvement et d’aboutissement du projet. Pour remplir cette
tâche avec succès il fut savoir utiliser les outils adéquats et nécessaires. Ce choix d’outils peut
influencer sur la qualité du produit obtenu et donc nécessite une attention particulière et doit
se baser sur les besoins du projet et le résultat escompté.
Ce chapitre présente alors l’environnement technique du travail ainsi que le choix pris en matière
d’environnement logiciel. Par la suite nous présentons les interfaces de notre solution.
4.1 Environnement de développement
Dans cette partie nous nous intéressons à l’étude de l’environnement technique disponible pour
la réalisation de notre projet ensuite nous justifions les choix pris en matière d’environnement
logiciel pour mener à terme la partie applicative.
4.1.1 Environnement matériel
Nous disposons de deux ordinateurs portables :
— Intel Core7, 2.4GHz avec 8Go de RAM (OS : Windows 10)
— server (OS : ubuntu lts 14.04)
45
Chapitre 4 Réalisation de “TestLab - Proxym Group”
4.1.2 Environnement logiciel
Les différents outils utilisés dans cette phase de réalisation sont les suivants :
WampServer
WampServer est une plateforme de développement Web de type WAMP, permettant de faire
fonctionner localement (sans se connecter à un serveur externe) des scripts PHP. WampServer
n’est en soi un logiciel, mais un environnement comprenant deux serveurs (Apache et MySQL),
un interpréteur de script(PHP), ainsi que phpMyAdmin pour l’administration Web des bases
MySQL. [16]
Webstorm
WebStorm est un environnement de développement intégré léger et puissant, parfaitement
équipé pour un développement client complexe et un développement côté serveur avec Node.js.
WebStorm dispose d’un support avancé pour JavaScript ,HTML , CSS , et leurs successeurs
modernes, ainsi que pour des cadres tels queAngularJS ou ReactJs. [17]
PhpStorm
PhpStorm PhpStorm est un IDE PHP. Il fournit une prévention des erreurs à la volée, une
autocomplification et un refactorat de code, un débogage de configuration à zéro et un éditeur
de HTML, CSS et JavaScript étendu. PhpStorm fournit également des outils intégrés puissants
pour le débogage, le test et le profilage de vos applications. [18]
Axure
Axure est un outil de création de wireframing (guide visuel qui représente le cadre squelettique
d’un site Web) et de prototypage pour les concepteurs d’expérience sur le Web et les utilisateurs.
[19]
46
Chapitre 4 Réalisation de “TestLab - Proxym Group”
PostMan
Postman est outil pour les développeurs d’API pour partager, tester, documenter et surveiller
les API. [20]
4.2 Environnement de programmation
4.2.1 PHP
Hyper text Preprocessor, est un langage de scripts libre principalement utilisé pour produire
des pages Web dynamiques via un serveur HTTP, mais pouvant également fonctionner comme
n’importe quel langage interprété de façon locale, en exécutant les programmes en ligne de
commande. PHP est un langage impératif disposant depuis la version 5 de fonctionnalités de
modèle objet complètes. En raison de la richesse de sa bibliothèque, on désigne parfois PHP
comme une plate-forme plus qu’un simple langage. [21]
4.2.2 HTML
L’HyperText Markup Language, généralement abrégé HTML, est le format de données conçu
pour représenter les pages web. C’est un langage de balisage permettant d’écrire de l’hypertexte,
d’où son nom. HTML permet également de structurer sémantiquement et logiquement et de
mettre en forme le contenu des pages, d’inclure des ressources multimédias dont des images,
des formulaires de saisie, et des programmes informatiques. [22]
4.2.3 CSS
CSS est l’acronyme de Cascading Style Sheets est un langage informatique qui décrit la pré-
sentation des documents HTML, XHTML et XML. Les standards définissant le code CSS sont
publiés par le World Wide Web Consortium (W3C). L’utilisation du CSS est indispensable
pour le developpement web ( front end ) afin de rendre le site esthétique et responsive design.
[23]
47
Chapitre 4 Réalisation de “TestLab - Proxym Group”
4.2.4 JavaScript
JavaScript est un langage de programmation utilisé pour rendre les pages Web interactives. Il
fonctionne sur l’ordinateur de votre visiteur et ne nécessite pas de téléchargements constants
sur votre site. [24]
4.2.5 Bootstrap
Bootstrap est une collection d’outils utile à la création du design (graphisme, animation et
interactions avec la page dans le navigateur , etc ) de sites et d’applications web. C’est un
ensemble qui contient des codes HTML et CSS, des formulaires, boutons, outils de navigation
et autres éléments interactifs, ainsi que des extensions JavaScript en option. C’est l’un des
projets les plus populaires sur la plate-forme de gestion de développement GitHub. [25]
4.2.6 ReactJs
React (aussi appelé React.js ou ReactJS) est une bibliothèque JavaScript libre développée
par Facebook depuis 2013. Le but principal de cette bibliothèque est de faciliter la création
d’application web , via la création de composants dépendant d’un état et générant une page
(ou portion) HTML à chaque changement d’état.
React est une bibliothèque qui ne gère que l’interface de l’application, considéré comme la vue
dans le modèle MVC. Elle peut ainsi être utilisée avec une autre bibliothèque ou un framework
MVC comme AngularJS. La bibliothèque se démarque de ses concurrents par sa flexibilité et
ses performances, en travaillant avec un DOM virtuel et en ne mettant à jour le rendu dans le
navigateur qu’en cas de nécessité. [26]
4.2.7 Silex
Silex est un micro-framework PHP développé par la société française SensioLabs, créatrice du
framework Symfony. Silex est en quelque sorte le petit frère de Symfony et les deux frameworks
reposent sur les mêmes composants. [27]
48
Chapitre 4 Réalisation de “TestLab - Proxym Group”
4.3 Système de gestion de la base de données relationnel
4.3.1 MySQL
MySQL est un système de gestion de base de données. Selon le type d’application, sa licence
est libre ou propriétaire. Il fait partie des logiciels de gestion de base de données les plus
utilisés au monde, autant par le grand public (applications Web principalement) que par des
professionnels, au même titre que Oracle ou Microsoft SQL Server. [28]
4.3.2 PhpMyAdmin
PhpMyAdmin (PMA) est une application Web de gestion pour les systèmes de gestion de base
de données MySQL réalisée en PHP. Il s’agit de l’une des plus célèbres interfaces pour gérer une
base de données MySQL sur un serveur PHP. De nombreux hébergeurs, qu’ils soient gratuits
ou payants, le proposent ce qui permet à l’utilisateur de ne pas avoir à l’installer.[29]
4.4 Architecture Logicielle du système :
l’architecture du systéme de platforme développé est une architecture 3-tiers :
Cette architecture vise a séparer les 3 couches logicielles suivantes :
Figure 4.1 – architecture du systeme
49
Chapitre 4 Réalisation de “TestLab - Proxym Group”
— la couche présentation : qui correspond à l’affichage sur écran et l’interaction avec
l’utilisateur , realiser avec reactJS
— la couche traitement : qui correspond à la mise en oeuvre de l’ensemble des règles
métier , realiser avec silex
— la couche donnée : qui correspond à l’ensemble des données à conserver
4.4.1 Protocole et formats de données :
4.4.1.1 Protocole de communication
Dans notre projet, nous avons utilisé le protocole HTTP, afin de communiquer les données
entre l’application website et le serveur web. En effet, Le HTTP est un protocole qui définit la
communication entre un serveur et un client. En général, nous avons utilisé la méthode Post
pour envoyer des données au programme situé à une URL spécifiée.
4.4.1.2 Format de données communiquées
JSON (JavaScript Object Notation) est un format léger d’échange de données. Il peut être
aisément analysé et généré par des machines. [30]
Lorsque l’application ReactJS s’exécute, elle se connectera au script PHP. Le script PHP va
récupérer les données depuis la base de données MySQL. Ensuite les données seront encodées
au format JSON et envoyées au système ReactJS. Ensuite, l’application ReactJS va obtenir ces
données codées. Elle les analysera et les affichera sur interface.
4.4.2 Sécurité et droit d’accès a API :
pour sécuriser API on choisi d’aborder JSON Web Token (JWT), un standard ouvert permet-
tant à deux parties d’échanger de manière sûre des informations encapsulées dans un jeton
signé numériquement. [31]
Un jeton JWT est une chaîne de caractères décomposable en 3 sections séparées par un point
(.) comme l’indique la figure 3.2 .
50
Chapitre 4 Réalisation de “TestLab - Proxym Group”
Figure 4.2 – structure d’un jeton jwt
En-tête : c’est un document au format JSON, encodé en base 64 et contenant des méta-
données. Il doit contenir au minimum le type de jeton et l’algorithme de chiffrement utilisé
pour le signer numériquement.
Charge utile : cette section est un document au format JSON encodé en base 64, contenant
des données fonctionnelles minimales que l’on souhaite transmettre au service. En pratique, on
y fait transiter des informations sur l’identité de l’utilisateur (login, nom complet, rôles, etc.).
Signature : cette zone contient la signature numérique du jeton. La clé privée utilisée pour
signer le jeton est stockée côté serveur.
4.5 Composition de la page :
Le site se doit être simple d’utilisation et de navigation, que ce soit dans ses fonctionnalités ou
que ce soit dans son contenu. Pour faciliter la navigation, il est obligatoire que l’ensemble des
pages du site web possèdent la même structure et organisation.
Pour cela, nous réalisé un modèle pour la structure des pages que vous pouvez observer ci-
dessous la figure 3.7. La totalité des pages visibles par l’utilisateur posséderont cette même
structure :
- Un en-tête de page avec le logo du
- Un menu de navigation complet.
- Le contenu qui se modifiera selon les pages.
- Un pied de page
51
Chapitre 4 Réalisation de “TestLab - Proxym Group”
Figure 4.3 – Composition de la page
L’intérêt de procéder ainsi est que seul le contenu du site varie d’une page à l’autre, c’est
pourquoi de page en page on inclue toujours le même en-tête, le même menu de navigation et
le même pied de page. Cela évite de devoir implémenter à nouveau chaque partie du site, ce
qui entraine un gain de temps considérable.
4.6 Maquettes du site :
La maquette fonctionnelle (wireframe) Il s’agit de définir en noir en blanc la mise en page,
l’organisation des différents éléments. La réalisation des maquettes est une étape déterminante
dans la création d’un site internet. Pour que notre site web soit agréable, il faut naturellement
soigner le design de l’interface graphique, mais surtout, pour que nos plates-formes internet
soient efficaces, il faut construire une mise en page adaptée à nos objectifs et nos contenus.
La réalisation des maquettes doit passer par plusieurs étapes, du design fonctionnel en noir et
blanc, au design graphique intégrant votre identité et vos couleurs.
Le wireframe ci-contre (figure 3.8) a a été réalisé à l’aide du logiciel Axure.
52
Chapitre 4 Réalisation de “TestLab - Proxym Group”
Figure 4.4 – Quelque Exemple De Maquette
4.7 Les IHM de l’application
Cette section est consacrée à la présentation du travail réalisé à travers les aperçus des interfaces
les plus pertinentes.
4.7.1 Administrateur
4.7.1.1 Interface d’authentification
Tout d’abord, l’interface de démarrage est celle de l’authentification
53
Chapitre 4 Réalisation de “TestLab - Proxym Group”
Figure 4.5 – Aperçu de l’interface d’identification
Cette interface permet à l’utilisateur de s’authentifier et de se connecter au serveur de la base de
données. L’utilisateur doit entrer son login et son mot de passe pour accéder à l’application.
En cas d’erreur un message d’alerte s’affiche :
1ierMessage d’erreur : Le message « le nom est obligatoire / email est obligatoire » c’est un
message d’erreur, il s’affiche lorsque l’utlisateur laisse les champs vides.
2ème Message d’erreur Le message « Vérifier votre coordonné » c’est un message d’erreur qui
s’affiche lorsque l’utlisateur a donné des cordonnes non valide.
4.7.1.2 Interface page d’acceuil
La figure suivante présente la page d’accueil après authentification. Cette dernière comporte
les menus qui sont les principales fonctions dans site web
54
Chapitre 4 Réalisation de “TestLab - Proxym Group”
Figure 4.6 – Aperçu de l’interface de page d’acceuil
4.7.1.3 Interface de Gérer Les Projets du Tests
Cette interface est la plus importante dans notre application. Elle présente la liste des projets
de tests.
55
Chapitre 4 Réalisation de “TestLab - Proxym Group”
Figure 4.7 – Apercu de l’interface de gérer les projes du tests
4.7.1.4 Interface de gérer les utlisateurs
Figure 4.8 – Aperçu de l’interface de gérer les utlisateurs
56
Chapitre 4 Réalisation de “TestLab - Proxym Group”
4.7.1.5 Interface de Gérer les roles
Figure 4.9 – Aperçu de l’interface de gérer les roles
4.7.1.6 Interface de suivi de test
Figure 4.10 – Aperçu de l’interface de suivi de test
57
Chapitre 4 Réalisation de “TestLab - Proxym Group”
4.7.2 Concepteur de test
4.7.2.1 Interface affectation des members sur projet de test
Figure 4.11 – Aperçu de l’interface d’affaction de smembers d’équipe
4.7.2.2 Interface affectation des envirement de test
Figure 4.12 – Aperçu de l’interface d’affectation des envirement de test
58
Chapitre 4 Réalisation de “TestLab - Proxym Group”
4.7.2.3 Interface de gérer d’exigence
Figure 4.13 – Aperçu de l’interface de gérer d’écigence
4.7.2.4 Interface de gérer la plan de test
Figure 4.14 – Aperçu de l’interface de gérer la plan de test
59
Chapitre 4 Réalisation de “TestLab - Proxym Group”
4.7.2.5 Interface de gérer la campagne de test
Figure 4.15 – Aperçu de l’interface de gérer la campagne de test
4.7.2.6 Interface de gérer rapport de test
Figure 4.16 – Aperçu de l’interface de gérer rapport de test
60
Chapitre 4 Réalisation de “TestLab - Proxym Group”
4.7.3 Testeur
4.7.3.1 Interface de visualisation de campagne de test
Figure 4.17 – Aperçu de l’interface de visualisation details de campagne de test
61
Chapitre 4 Réalisation de “TestLab - Proxym Group”
4.7.3.2 Interface de noter resultat campagne de test
Figure 4.18 – Aperçu de l’interface de noter resultat
Conclusion
Dans ce chapitre nous avons présenté l’environnement de développement (matériel et logiciel)
ainsi que les Framework utilisés pour le développement de notre application. Nous avons ensuite
décrit le travail réalisé, et enfin, nous avons présenté quelques interfaces de l’application.
62
réaliser une plateforme d’automatisation et de génération des rapports de test
Conclusion Générale
Ce stage de fin d’étude était une bonne occasion pour améliorer mes connaissances théoriques
et pratiques en informatique. En effet, nous avons eu l’opportunité de participer à la fois à la
conception et à la réalisation d’une application Web au profit de la société d’accueil PRPOXYM-
IT. L’application réalisée sert à la mise en place d’une plateforme d’automatisation et de géné-
ration des rapports de test destinée à l’équipe assurance qualité (QA).
Il n’est pas évident d’éviter les problèmes et les difficultés au niveau de la modélisation concep-
tuelle ainsi que celles dans l’écriture des codes. Cependant, nous avons essayé de dégager les
solutions les mieux adaptées à nos objectifs, nos contraintes et nos possibilités.
En général, ce stage m’a beaucoup intéressé. J’ai pu découvrir des différents langages de pro-
grammation HTML5 , CSS3 , ReactJS ,Silex et d’avoir un aperçu global de son fonctionnement.
Il m’a permis aussi, de me familiariser avec les différents services et d’avoir une approche réelle
du monde de travail.
J’ai pu faire le rapprochement entre ce que j’avais appris en cours et ce qui se passe vraiment
dans l’entreprise. Ce projet ne doit pas être considéré comme un produit fini par l’applica-
tion pour la société mais plutôt comme un premier prototype qui sera la base des éventuelles
extensions.
64
réaliser une plateforme d’automatisation et de génération des rapports de test
Bibliographie
[1] auteur : RH Dernière fois visité : 13 février 2017
Département Ressources Humaines chez PROXYM-IT
[2] auteur : C. Aubry Dernière fois visité : 13 février 2017
SCRUM le guide pratique de la méthode agile la plus populaire, Dunod, 2010.
[3] auteur : Organisme français de certification Dernière fois visité : 15 février 2017
https ://www.ofcertification.fr/qualite
[4] auteur : Patrick FELIX Dernière fois visité : 16 février 2017
Test et Validation du Logiciel [ page 17]
[5] auteur : Software Testing Romania Dernière fois visité : 21 février 2017
http ://www.softwaretesting.ro/Francais/Files/TestMethods/Software-Testing-
Methods.html
[6] auteur : CFTL/ISTQB Dernière fois visité : 22 février 2017
http ://swisstestingboard.org/wp-
content/uploads/2014/04/Glossaire_des_tests_de_logiciel_-
_2_1_F_ISTQB.pdf
[7] auteur : journal du net Dernière fois visité : 22 février 2017
http ://www.journaldunet.com/developpeur/algo-methodes/test-logiciel-processus-
fondamentaux/
[8] auteur : Dernière fois visité : 28 février 2017
https ://fr.wikipedia.org/wiki/Redmine
66
Bibliographie
[9] auteur : Kodjo Agbemebia Dernière fois visité : 5 Mars 2017
https ://blog.netapsys.fr/utilisez-testlink-pour-gerer-vos-cas-de-tests-2/
10] auteur : All4Test Dernière fois visité : 8 Mars 2017
http ://www.all4test.fr/actualites/480-qu-est-qu-un-plan-de-test-logiciel-comment-
rediger-un-bon-plan-de-test
[11] auteur : Dernière fois visité : 22 Mars 2017
https ://msdn.microsoft.com/fr-fr/library/dd421945.aspx
[12] auteur : Drifa KESRAOUI Dernière fois visité : 6 avril 2017
MEMOIRE « Test et Recette dans un Projet Logiciel, Evolution des Méthodes et
Outils »
Le 17 décembre 2014
[13] auteur : Dernière fois visité : 12 avril 2017
http ://www.squashtest.org/fr/decouvrir-squash-tm/contenu-statique/outils-et-
fonctionnalites/squash-tm-test-management
[14] auteur : Dernière fois visité : 12 avril 2017
http ://www.gurock.com/testrail/
[15] auteur : Dernière fois visité : 15 avril 2017
https ://fr.wikipedia.org/wiki/Microsoft_Visio
[16] auteur : Dernière fois visité : 6 mai 2017
https ://fr.wikipedia.org/wiki/WampServer
[17] auteur : Dernière fois visité : 11 juin 2017
https ://www.jetbrains.com/help/webstorm/meet-webstorm.html
[18] auteur : Dernière fois visité : 11 juin 2017
https ://www.jetbrains.com/help/phpstorm/meet-phpstorm.html
[19] auteur : Dernière fois visité : 11 juin 2017
https ://en.wikipedia.org/wiki/Axure_RP
67
Bibliographie
[20] auteur : Dernière fois visité : 11 juin 2017
https ://www.getpostman.com/company
[21] auteur : Dernière fois visité : 11 juin 2017
https ://fr.wikipedia.org/wiki/PHP
[22] auteur : Dernière fois visité : 11 juin 2017
https ://fr.wikipedia.org/wiki/Hypertext_Markup_Language
[23] auteur : Dernière fois visité : 11 juin 2017
https ://fr.wikipedia.org/wiki/Feuilles_de_style_en_cascade
[24] auteur : Dernière fois visité : 11 juin 2017
https ://fr.wikipedia.org/wiki/JavaScript
[25] auteur : Dernière fois visité : 11 juin 2017
https ://fr.wikipedia.org/wiki/Bootstrap_(framework)
[26] auteur : Dernière fois visité : 11 juin 2017
https ://fr.wikipedia.org/wiki/React_(JavaScript)
[27] auteur : Baptiste Pesquet Dernière fois visité : 11 juin 2017
https ://openclassrooms.com/courses/premiers-pas-avec-le-framework-php-silex
[28] auteur : Dernière fois visité : 11 juin 2017
https ://fr.wikipedia.org/wiki/MySQL
[29] auteur : Dernière fois visité : 11 juin 2017
https ://fr.wikipedia.org/wiki/PhpMyAdmin
[30] auteur : Dernière fois visité : 13 juin 2017
http ://www.json.org/jsonfr.html
[31] auteur : Kadda SAHNINE Dernière fois visité : 13 juin 2017
http ://blog.inovia-conseil.fr/ ?p=236
68
réaliser une plateforme d’automatisation et de génération des rapports de test
Annexes
Annexe 1 « Pour aller plus loin »
Nous vous proposons des adresses des sites internet (sites spécialisés) des grands acteurs des
services de la qualité des logiciels et de la gestion de projets, des cabinets de conseil en infor-
matique qui proposent des solutions et les outils :
1. Acial : http ://www.acial.fr/fr/slideshow/126-le-referentiel-tmmi-un-outil-pour-lamelioration-
delactivite-de-test8.html
2. ConseilOrga : http ://www.conseilorga.com/Pages/Recettestestsetqualificationinformatique.aspx
3. Altea-conseil : http ://www.altea-conseil.com/consulter-nos-offres.html
4. Akal-consulting : http ://www.akal-consulting.com/# !resolution-incident/cd0d
5. irage-groupe : http ://www.viragegroup.com/fr/services/nos-services
6. Hsc :http ://www.hsc.fr/services/conseil.html.fr#ouvrage
7. LESORGANISATIONS PROFESSTIONNELLES :
a) CFTL : http ://www.cftl.fr
b) PMI : http ://www.pmi-france.org
c) APRIL : http ://www.april.org/association
8. BLOGS/CLUB DES CONSULTANTS :
a) http ://ulrichinaction.blogspot.fr/2013/04/integration-des-tests-fonctionnels.html
b) http ://blog-du-consultant.fr/les-septs-galeres-du-consultant-independant/
c) http ://blogduconsultant.blogspot.fr/
d) http ://www.osaxis.fr/blog/automatiser-ses-tests-fonctionnels-partie-2-2/
e) http ://gestiondeprojets.wordpress.com/sabonner-au-blog/
f) http ://blog.univ-angers.fr/qsfs/category/test-logiciel/
g) http ://t37.net/tag/blogs-twitter-micro-blogging/
h) http ://t37.net/preparer-ses-plans-de-tests.html
i) http ://je-choisis-ma-vie.fr/2012/11/19/ssii-consultants-changez/
j) http ://www.acial.fr/club-acial-test-logiciel/
70
Annexes
Annexe A : Dictionnaire des attributs
Voici une brève description des données mises en jeu dans l’application :
1. Exigence
2. Séquence de test
3. Cas De Test
4. Pas De Test
5. Resultat Pas de Test
6. Pièce jointe de résultat Pas de Test
7. Campagne De Test
8. itreation
9. resultat Iteration
10. Utilisateur
11. Role
12. Droit d’accès
13. Project_Role_Users
14. Projet De Test
15. Environnement De Test
Annexe B : publiéer sur server
Annexe C : Quelques APIs utilisé
LDAP description sur ldap API
Redmine description sur readmine API
71

Contenu connexe

Tendances

Rapport-PFE2013-RahmaGhali-Gestion des Candidatures(Jaas,Primefaces,JFS2,JPA)
Rapport-PFE2013-RahmaGhali-Gestion des Candidatures(Jaas,Primefaces,JFS2,JPA)Rapport-PFE2013-RahmaGhali-Gestion des Candidatures(Jaas,Primefaces,JFS2,JPA)
Rapport-PFE2013-RahmaGhali-Gestion des Candidatures(Jaas,Primefaces,JFS2,JPA)
Ghali Rahma
 
Application web de gestion de recrutement- Recruitement managment system
Application web de gestion de recrutement- Recruitement managment systemApplication web de gestion de recrutement- Recruitement managment system
Application web de gestion de recrutement- Recruitement managment system
Sarra ERRREGUI
 
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_webRapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
Salma Gouia
 
Rapport PFE Ilef Ben Slima
Rapport PFE Ilef Ben SlimaRapport PFE Ilef Ben Slima
Rapport PFE Ilef Ben Slima
Ilef Ben Slima
 
Rapport pfe Conceptionet Developpement d'une Application web et Mobile
Rapport pfe Conceptionet Developpement d'une Application web et  Mobile Rapport pfe Conceptionet Developpement d'une Application web et  Mobile
Rapport pfe Conceptionet Developpement d'une Application web et Mobile
Raoua Bennasr
 
PFE :: Application de gestion des dus d'enseignement
PFE :: Application de gestion des dus d'enseignementPFE :: Application de gestion des dus d'enseignement
PFE :: Application de gestion des dus d'enseignement
Nassim Bahri
 
RAPPORT DE PROJET DE FIN D’ETUDES
RAPPORT DE PROJET DE FIN D’ETUDESRAPPORT DE PROJET DE FIN D’ETUDES
RAPPORT DE PROJET DE FIN D’ETUDES
TombariAhmed
 
Rapport pfe talan_2018_donia_hammami
Rapport pfe talan_2018_donia_hammamiRapport pfe talan_2018_donia_hammami
Rapport pfe talan_2018_donia_hammami
Donia Hammami
 
rapport de projet de fin d'étude_PFE
rapport de projet de fin d'étude_PFErapport de projet de fin d'étude_PFE
rapport de projet de fin d'étude_PFE
Donia Hammami
 
Rapport pfe
Rapport pfeRapport pfe
Rapport pfe
Ahmed rebai
 
Rapport de projet de conception et de développement
Rapport de projet de conception et de développementRapport de projet de conception et de développement
Rapport de projet de conception et de développement
Donia Hammami
 
Rapport Projet de fin d'etude sur le parc informatique
Rapport Projet  de fin d'etude sur le parc informatiqueRapport Projet  de fin d'etude sur le parc informatique
Rapport Projet de fin d'etude sur le parc informatique
Hicham Ben
 
Conception et developpement d'une application mobile Android e-location
Conception et developpement d'une application mobile Android e-locationConception et developpement d'une application mobile Android e-location
Conception et developpement d'une application mobile Android e-location
ALALSYSE
 
Rapport de stage de fin d'études ISI 2015
Rapport de stage de fin d'études ISI 2015Rapport de stage de fin d'études ISI 2015
Rapport de stage de fin d'études ISI 2015
Anouar Kacem
 
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
mouafekmazia
 
Projet de fin étude ( LFIG : Conception et Développement d'une application W...
Projet de fin étude  ( LFIG : Conception et Développement d'une application W...Projet de fin étude  ( LFIG : Conception et Développement d'une application W...
Projet de fin étude ( LFIG : Conception et Développement d'une application W...
Ramzi Noumairi
 
gestion de projet
gestion de projetgestion de projet
gestion de projet
Wajdi kanzali
 
Rappport PFE 2012 Ghodhbane Hani - OpenSNC
Rappport PFE 2012 Ghodhbane Hani - OpenSNCRappport PFE 2012 Ghodhbane Hani - OpenSNC
Rappport PFE 2012 Ghodhbane Hani - OpenSNC
Ghodbane Heni
 
Rapport pfe 2017 Système de gestion des rendez-vous médicaux
Rapport pfe 2017 Système de gestion des rendez-vous médicaux Rapport pfe 2017 Système de gestion des rendez-vous médicaux
Rapport pfe 2017 Système de gestion des rendez-vous médicaux
fehmi arbi
 
Rapport de stage PFE - Mémoire master: Développement d'une application Android
Rapport de stage PFE - Mémoire master: Développement d'une application AndroidRapport de stage PFE - Mémoire master: Développement d'une application Android
Rapport de stage PFE - Mémoire master: Développement d'une application Android
BadrElattaoui
 

Tendances (20)

Rapport-PFE2013-RahmaGhali-Gestion des Candidatures(Jaas,Primefaces,JFS2,JPA)
Rapport-PFE2013-RahmaGhali-Gestion des Candidatures(Jaas,Primefaces,JFS2,JPA)Rapport-PFE2013-RahmaGhali-Gestion des Candidatures(Jaas,Primefaces,JFS2,JPA)
Rapport-PFE2013-RahmaGhali-Gestion des Candidatures(Jaas,Primefaces,JFS2,JPA)
 
Application web de gestion de recrutement- Recruitement managment system
Application web de gestion de recrutement- Recruitement managment systemApplication web de gestion de recrutement- Recruitement managment system
Application web de gestion de recrutement- Recruitement managment system
 
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_webRapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
 
Rapport PFE Ilef Ben Slima
Rapport PFE Ilef Ben SlimaRapport PFE Ilef Ben Slima
Rapport PFE Ilef Ben Slima
 
Rapport pfe Conceptionet Developpement d'une Application web et Mobile
Rapport pfe Conceptionet Developpement d'une Application web et  Mobile Rapport pfe Conceptionet Developpement d'une Application web et  Mobile
Rapport pfe Conceptionet Developpement d'une Application web et Mobile
 
PFE :: Application de gestion des dus d'enseignement
PFE :: Application de gestion des dus d'enseignementPFE :: Application de gestion des dus d'enseignement
PFE :: Application de gestion des dus d'enseignement
 
RAPPORT DE PROJET DE FIN D’ETUDES
RAPPORT DE PROJET DE FIN D’ETUDESRAPPORT DE PROJET DE FIN D’ETUDES
RAPPORT DE PROJET DE FIN D’ETUDES
 
Rapport pfe talan_2018_donia_hammami
Rapport pfe talan_2018_donia_hammamiRapport pfe talan_2018_donia_hammami
Rapport pfe talan_2018_donia_hammami
 
rapport de projet de fin d'étude_PFE
rapport de projet de fin d'étude_PFErapport de projet de fin d'étude_PFE
rapport de projet de fin d'étude_PFE
 
Rapport pfe
Rapport pfeRapport pfe
Rapport pfe
 
Rapport de projet de conception et de développement
Rapport de projet de conception et de développementRapport de projet de conception et de développement
Rapport de projet de conception et de développement
 
Rapport Projet de fin d'etude sur le parc informatique
Rapport Projet  de fin d'etude sur le parc informatiqueRapport Projet  de fin d'etude sur le parc informatique
Rapport Projet de fin d'etude sur le parc informatique
 
Conception et developpement d'une application mobile Android e-location
Conception et developpement d'une application mobile Android e-locationConception et developpement d'une application mobile Android e-location
Conception et developpement d'une application mobile Android e-location
 
Rapport de stage de fin d'études ISI 2015
Rapport de stage de fin d'études ISI 2015Rapport de stage de fin d'études ISI 2015
Rapport de stage de fin d'études ISI 2015
 
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
 
Projet de fin étude ( LFIG : Conception et Développement d'une application W...
Projet de fin étude  ( LFIG : Conception et Développement d'une application W...Projet de fin étude  ( LFIG : Conception et Développement d'une application W...
Projet de fin étude ( LFIG : Conception et Développement d'une application W...
 
gestion de projet
gestion de projetgestion de projet
gestion de projet
 
Rappport PFE 2012 Ghodhbane Hani - OpenSNC
Rappport PFE 2012 Ghodhbane Hani - OpenSNCRappport PFE 2012 Ghodhbane Hani - OpenSNC
Rappport PFE 2012 Ghodhbane Hani - OpenSNC
 
Rapport pfe 2017 Système de gestion des rendez-vous médicaux
Rapport pfe 2017 Système de gestion des rendez-vous médicaux Rapport pfe 2017 Système de gestion des rendez-vous médicaux
Rapport pfe 2017 Système de gestion des rendez-vous médicaux
 
Rapport de stage PFE - Mémoire master: Développement d'une application Android
Rapport de stage PFE - Mémoire master: Développement d'une application AndroidRapport de stage PFE - Mémoire master: Développement d'une application Android
Rapport de stage PFE - Mémoire master: Développement d'une application Android
 

Similaire à réaliser une plateforme d’automatisation et de génération des rapports de test

Gestion des actifs applicatifs
Gestion des actifs applicatifsGestion des actifs applicatifs
Gestion des actifs applicatifs
SafaAballagh
 
OpenERP - Gestion de prix de revient
OpenERP - Gestion de prix de revientOpenERP - Gestion de prix de revient
OpenERP - Gestion de prix de revient
Taieb Kristou
 
Mise en place d'une Plateforme de Supervision et de Détection d'Intrusion Sys...
Mise en place d'une Plateforme de Supervision et de Détection d'Intrusion Sys...Mise en place d'une Plateforme de Supervision et de Détection d'Intrusion Sys...
Mise en place d'une Plateforme de Supervision et de Détection d'Intrusion Sys...
Alaaeddine Tlich
 
Conception et développement d'une marketplace basée sur l'architecture micros...
Conception et développement d'une marketplace basée sur l'architecture micros...Conception et développement d'une marketplace basée sur l'architecture micros...
Conception et développement d'une marketplace basée sur l'architecture micros...
Adem Amen Allah Thabti
 
Belwafi bilel
Belwafi bilelBelwafi bilel
Belwafi bilel
Belwafi Bilel
 
Belwafi bilel
Belwafi bilelBelwafi bilel
Belwafi bilel
Belwafi Bilel
 
Implémentation et mise en place d’un système décisionnel pour la solution Meg...
Implémentation et mise en place d’un système décisionnel pour la solution Meg...Implémentation et mise en place d’un système décisionnel pour la solution Meg...
Implémentation et mise en place d’un système décisionnel pour la solution Meg...
Houssem Eddine Jebri
 
pfe_rapport_poste_licence_LFIG.pdf
pfe_rapport_poste_licence_LFIG.pdfpfe_rapport_poste_licence_LFIG.pdf
pfe_rapport_poste_licence_LFIG.pdf
nesrine haloui
 
Fourth year internship report
Fourth year internship reportFourth year internship report
Fourth year internship report
Slimane Akaliâ , سليمان أقليع
 
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Yasmine Lachheb
 
Conception et réalisation d’un Système d’information des étudiants du départe...
Conception et réalisation d’un Système d’information des étudiants du départe...Conception et réalisation d’un Système d’information des étudiants du départe...
Conception et réalisation d’un Système d’information des étudiants du départe...
Ilyas CHAOUA
 
Outpatient Department System (OPD)
Outpatient Department System (OPD) Outpatient Department System (OPD)
Outpatient Department System (OPD)
Ben Ahmed Zohra
 
Evaluation de la quantité de travail (in)utile dans l’exécution des programmes
Evaluation de la quantité de travail (in)utile dans l’exécution des programmesEvaluation de la quantité de travail (in)utile dans l’exécution des programmes
Evaluation de la quantité de travail (in)utile dans l’exécution des programmes
Benjamin Vidal
 
iRecruite
iRecruiteiRecruite
iRecruite
Donia Hammami
 
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes TechnologiquesLe Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Genève Lab
 
Projet de conception et de développement
Projet de conception et de développementProjet de conception et de développement
Projet de conception et de développement
Glei Hadji
 
Rapport pfe isi_Big data Analytique
Rapport pfe isi_Big data AnalytiqueRapport pfe isi_Big data Analytique
Rapport pfe isi_Big data Analytique
Yosra ADDALI
 
Deploy automatic in the cloud
Deploy automatic in the cloudDeploy automatic in the cloud
Deploy automatic in the cloud
Abdelhalim KADDOUR GUETTAOUI
 
Mémoire fin d'étude gestion des interventions
Mémoire fin d'étude gestion des interventionsMémoire fin d'étude gestion des interventions
Mémoire fin d'étude gestion des interventions
Mohamed Arar
 
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Sofien Benrhouma
 

Similaire à réaliser une plateforme d’automatisation et de génération des rapports de test (20)

Gestion des actifs applicatifs
Gestion des actifs applicatifsGestion des actifs applicatifs
Gestion des actifs applicatifs
 
OpenERP - Gestion de prix de revient
OpenERP - Gestion de prix de revientOpenERP - Gestion de prix de revient
OpenERP - Gestion de prix de revient
 
Mise en place d'une Plateforme de Supervision et de Détection d'Intrusion Sys...
Mise en place d'une Plateforme de Supervision et de Détection d'Intrusion Sys...Mise en place d'une Plateforme de Supervision et de Détection d'Intrusion Sys...
Mise en place d'une Plateforme de Supervision et de Détection d'Intrusion Sys...
 
Conception et développement d'une marketplace basée sur l'architecture micros...
Conception et développement d'une marketplace basée sur l'architecture micros...Conception et développement d'une marketplace basée sur l'architecture micros...
Conception et développement d'une marketplace basée sur l'architecture micros...
 
Belwafi bilel
Belwafi bilelBelwafi bilel
Belwafi bilel
 
Belwafi bilel
Belwafi bilelBelwafi bilel
Belwafi bilel
 
Implémentation et mise en place d’un système décisionnel pour la solution Meg...
Implémentation et mise en place d’un système décisionnel pour la solution Meg...Implémentation et mise en place d’un système décisionnel pour la solution Meg...
Implémentation et mise en place d’un système décisionnel pour la solution Meg...
 
pfe_rapport_poste_licence_LFIG.pdf
pfe_rapport_poste_licence_LFIG.pdfpfe_rapport_poste_licence_LFIG.pdf
pfe_rapport_poste_licence_LFIG.pdf
 
Fourth year internship report
Fourth year internship reportFourth year internship report
Fourth year internship report
 
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
 
Conception et réalisation d’un Système d’information des étudiants du départe...
Conception et réalisation d’un Système d’information des étudiants du départe...Conception et réalisation d’un Système d’information des étudiants du départe...
Conception et réalisation d’un Système d’information des étudiants du départe...
 
Outpatient Department System (OPD)
Outpatient Department System (OPD) Outpatient Department System (OPD)
Outpatient Department System (OPD)
 
Evaluation de la quantité de travail (in)utile dans l’exécution des programmes
Evaluation de la quantité de travail (in)utile dans l’exécution des programmesEvaluation de la quantité de travail (in)utile dans l’exécution des programmes
Evaluation de la quantité de travail (in)utile dans l’exécution des programmes
 
iRecruite
iRecruiteiRecruite
iRecruite
 
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes TechnologiquesLe Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
 
Projet de conception et de développement
Projet de conception et de développementProjet de conception et de développement
Projet de conception et de développement
 
Rapport pfe isi_Big data Analytique
Rapport pfe isi_Big data AnalytiqueRapport pfe isi_Big data Analytique
Rapport pfe isi_Big data Analytique
 
Deploy automatic in the cloud
Deploy automatic in the cloudDeploy automatic in the cloud
Deploy automatic in the cloud
 
Mémoire fin d'étude gestion des interventions
Mémoire fin d'étude gestion des interventionsMémoire fin d'étude gestion des interventions
Mémoire fin d'étude gestion des interventions
 
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
 

Plus de ahmed oumezzine

Rapport PFE : Cloud Insights
Rapport PFE : Cloud InsightsRapport PFE : Cloud Insights
Rapport PFE : Cloud Insights
ahmed oumezzine
 
Présentatin PFE : Cloud Insights
Présentatin PFE : Cloud InsightsPrésentatin PFE : Cloud Insights
Présentatin PFE : Cloud Insights
ahmed oumezzine
 
PHP Training
PHP TrainingPHP Training
PHP Training
ahmed oumezzine
 
Gestion d'erreurs et accès à distance
Gestion d'erreurs et accès à distanceGestion d'erreurs et accès à distance
Gestion d'erreurs et accès à distance
ahmed oumezzine
 
Gestion d'erreurs et accès à distance
Gestion d'erreurs et accès à distanceGestion d'erreurs et accès à distance
Gestion d'erreurs et accès à distance
ahmed oumezzine
 

Plus de ahmed oumezzine (6)

Rapport PFE : Cloud Insights
Rapport PFE : Cloud InsightsRapport PFE : Cloud Insights
Rapport PFE : Cloud Insights
 
Présentatin PFE : Cloud Insights
Présentatin PFE : Cloud InsightsPrésentatin PFE : Cloud Insights
Présentatin PFE : Cloud Insights
 
PHP Training
PHP TrainingPHP Training
PHP Training
 
rapportDigital-TV
rapportDigital-TVrapportDigital-TV
rapportDigital-TV
 
Gestion d'erreurs et accès à distance
Gestion d'erreurs et accès à distanceGestion d'erreurs et accès à distance
Gestion d'erreurs et accès à distance
 
Gestion d'erreurs et accès à distance
Gestion d'erreurs et accès à distanceGestion d'erreurs et accès à distance
Gestion d'erreurs et accès à distance
 

Dernier

Burkina Faso libraries newsletter for June 2024
Burkina Faso libraries newsletter for June 2024Burkina Faso libraries newsletter for June 2024
Burkina Faso libraries newsletter for June 2024
Friends of African Village Libraries
 
Chap1 Généralités sur les réseaux informatiques.pdf
Chap1 Généralités sur les réseaux informatiques.pdfChap1 Généralités sur les réseaux informatiques.pdf
Chap1 Généralités sur les réseaux informatiques.pdf
TimogoTRAORE
 
La Révolution Bénédictine Casadéenne du Livradois-Forez: De Charlemagne à Fra...
La Révolution Bénédictine Casadéenne du Livradois-Forez: De Charlemagne à Fra...La Révolution Bénédictine Casadéenne du Livradois-Forez: De Charlemagne à Fra...
La Révolution Bénédictine Casadéenne du Livradois-Forez: De Charlemagne à Fra...
Editions La Dondaine
 
1e Espaces productifs 2024.Espaces productif
1e Espaces productifs 2024.Espaces productif1e Espaces productifs 2024.Espaces productif
1e Espaces productifs 2024.Espaces productif
NadineHG
 
1eT Revolutions Empire Revolution Empire
1eT Revolutions Empire Revolution Empire1eT Revolutions Empire Revolution Empire
1eT Revolutions Empire Revolution Empire
NadineHG
 
Auguste Herbin.pptx Peintre français
Auguste   Herbin.pptx Peintre   françaisAuguste   Herbin.pptx Peintre   français
Auguste Herbin.pptx Peintre français
Txaruka
 
Zineb Mekouar.pptx Écrivaine marocaine
Zineb Mekouar.pptx   Écrivaine  marocaineZineb Mekouar.pptx   Écrivaine  marocaine
Zineb Mekouar.pptx Écrivaine marocaine
Txaruka
 

Dernier (7)

Burkina Faso libraries newsletter for June 2024
Burkina Faso libraries newsletter for June 2024Burkina Faso libraries newsletter for June 2024
Burkina Faso libraries newsletter for June 2024
 
Chap1 Généralités sur les réseaux informatiques.pdf
Chap1 Généralités sur les réseaux informatiques.pdfChap1 Généralités sur les réseaux informatiques.pdf
Chap1 Généralités sur les réseaux informatiques.pdf
 
La Révolution Bénédictine Casadéenne du Livradois-Forez: De Charlemagne à Fra...
La Révolution Bénédictine Casadéenne du Livradois-Forez: De Charlemagne à Fra...La Révolution Bénédictine Casadéenne du Livradois-Forez: De Charlemagne à Fra...
La Révolution Bénédictine Casadéenne du Livradois-Forez: De Charlemagne à Fra...
 
1e Espaces productifs 2024.Espaces productif
1e Espaces productifs 2024.Espaces productif1e Espaces productifs 2024.Espaces productif
1e Espaces productifs 2024.Espaces productif
 
1eT Revolutions Empire Revolution Empire
1eT Revolutions Empire Revolution Empire1eT Revolutions Empire Revolution Empire
1eT Revolutions Empire Revolution Empire
 
Auguste Herbin.pptx Peintre français
Auguste   Herbin.pptx Peintre   françaisAuguste   Herbin.pptx Peintre   français
Auguste Herbin.pptx Peintre français
 
Zineb Mekouar.pptx Écrivaine marocaine
Zineb Mekouar.pptx   Écrivaine  marocaineZineb Mekouar.pptx   Écrivaine  marocaine
Zineb Mekouar.pptx Écrivaine marocaine
 

réaliser une plateforme d’automatisation et de génération des rapports de test

  • 1. Table des matières Table des figures Liste des tableaux Introduction Générale 1 1 Présentation de l’organisme d’accueil 3 1.1 Présentation de l’entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1.1 Organigramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1.2 Domaines d’intervention . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1.3 Métiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.2 Méthodologie de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.2.1 Définition de la méthodologie Agile . . . . . . . . . . . . . . . . . . . . . 7 1.2.2 Méthodologie AGILE : SCRUM . . . . . . . . . . . . . . . . . . . . . . . 7 2 Etude Préalable 11 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.1 Contexte Générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.1.1 Introduction à l’assurance qualité . . . . . . . . . . . . . . . . . . . . . . 12 2.1.2 Introduction auw tests logiciel . . . . . . . . . . . . . . . . . . . . . . . . 12 2.1.3 Les Bugs (ou les anomalies) . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.1.3.1 Qu’est-ce qu’un Bug ? . . . . . . . . . . . . . . . . . . . . . . . 14 2.1.3.2 Qualification de la gravité des anomalies : . . . . . . . . . . . . 15 2.1.3.3 Les sources des Bugs logiciels . . . . . . . . . . . . . . . . . . . 15 2.1.4 Terminologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
  • 2. Table des matières 2.1.5 Processus de test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.1.5.1 La planification des tests . . . . . . . . . . . . . . . . . . . . . . 17 2.1.5.2 L’analyse et la conception des tests . . . . . . . . . . . . . . . . 17 2.1.5.3 Implémentation des tests . . . . . . . . . . . . . . . . . . . . . . 18 2.1.5.4 Exécution des tests . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.1.5.5 Evaluation, Reporting et clôture . . . . . . . . . . . . . . . . . 18 2.2 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.3 Présentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.3.1 Description du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.3.2 Les objectifs du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.4 Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.4.1 Redmine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.4.2 Testlink : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.4.3 Inconvénient de TestLink . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.5 Application similaire de l’outil de gestion des tests . . . . . . . . . . . . . . . . . 23 2.5.1 Les outils proposés par les grands editeurs comme HP. . . . . . . . . . . 23 2.5.1.1 IBM Rational Quality Manager . . . . . . . . . . . . . . . . . . 24 2.5.1.2 Microsoft Test Manager . . . . . . . . . . . . . . . . . . . . . . 24 2.5.1.3 HP Quality Center . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.5.2 Les outils Open source . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.5.2.1 Squash TM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.5.2.2 TestRail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3 Conception de “TestLab - Proxym Group” 31 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.1 L’outil de modélisation : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.2 Les Diagrammes UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.2.1 Le Modèle des cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . 32 3.2.1.1 Identification des acteurs : . . . . . . . . . . . . . . . . . . . . . 32 3.2.2 Diagramme des cas d’utilisation global : . . . . . . . . . . . . . . . . . . 33 3.2.3 Diagramme de cas d’utilisation de l,’invité . . . . . . . . . . . . . . . . . 34 3.2.4 Diagramme de cas d’utilisation du Testeur . . . . . . . . . . . . . . . . . 35 3.2.5 Diagramme de cas d’utilisation de Concepteur de test . . . . . . . . . . . 35 3.2.6 Diagramme de cas d’utilisation d’administrateur . . . . . . . . . . . . . . 36 3.3 Diagramme de classes statique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 3.4 Diagramme de déploiement : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 3.5 Diagramme de séquence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
  • 3. Table des matières 4 Réalisation de “TestLab - Proxym Group” 45 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.1 Environnement de développement . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.1.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.1.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.2 Environnement de programmation . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.2.1 PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.2.2 HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.2.3 CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.2.4 JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 4.2.5 Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 4.2.6 ReactJs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 4.2.7 Silex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 4.3 Système de gestion de la base de données relationnel . . . . . . . . . . . . . . . 49 4.3.1 MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 4.3.2 PhpMyAdmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 4.4 Architecture Logicielle du système : . . . . . . . . . . . . . . . . . . . . . . . . . 49 4.4.1 Protocole et formats de données : . . . . . . . . . . . . . . . . . . . . . . 50 4.4.1.1 Protocole de communication . . . . . . . . . . . . . . . . . . . . 50 4.4.1.2 Format de données communiquées . . . . . . . . . . . . . . . . 50 4.4.2 Sécurité et droit d’accès a API : . . . . . . . . . . . . . . . . . . . . . . . 50 4.5 Composition de la page : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 4.6 Maquettes du site : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.7 Les IHM de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.7.1 Administrateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.7.1.1 Interface d’authentification . . . . . . . . . . . . . . . . . . . . 53 4.7.1.2 Interface page d’acceuil . . . . . . . . . . . . . . . . . . . . . . 54 4.7.1.3 Interface de Gérer Les Projets du Tests . . . . . . . . . . . . . . 55 4.7.1.4 Interface de gérer les utlisateurs . . . . . . . . . . . . . . . . . . 56 4.7.1.5 Interface de Gérer les roles . . . . . . . . . . . . . . . . . . . . . 57 4.7.1.6 Interface de suivi de test . . . . . . . . . . . . . . . . . . . . . . 57 4.7.2 Concepteur de test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 4.7.2.1 Interface affectation des members sur projet de test . . . . . . . 58 4.7.2.2 Interface affectation des envirement de test . . . . . . . . . . . 58 4.7.2.3 Interface de gérer d’exigence . . . . . . . . . . . . . . . . . . . . 59 4.7.2.4 Interface de gérer la plan de test . . . . . . . . . . . . . . . . . 59 4.7.2.5 Interface de gérer la campagne de test . . . . . . . . . . . . . . 60 4.7.2.6 Interface de gérer rapport de test . . . . . . . . . . . . . . . . . 60
  • 4. Table des matières 4.7.3 Testeur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.7.3.1 Interface de visualisation de campagne de test . . . . . . . . . . 61 4.7.3.2 Interface de noter resultat campagne de test . . . . . . . . . . . 62 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Conclusion Générale 64 Bibliographie 66 Annexes 70 Annexe 1 « Pour aller plus loin » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Annexe A : Dictionnaire des attributs . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Annexe B : publiéer sur server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Annexe C : Quelques APIs utilisé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
  • 5. Table des figures 1.1 Proxym Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Histoire de PROXYM-IT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3 Organisme interne de Proxym-IT . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.4 Domaines d’intervention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.5 vue globale de SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.6 Processus de SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.1 La chaîne de l’erreur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.2 Processus de test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.3 logo Test Lab - Proxym Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.4 capture d’écran de gestion tickets . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.5 Page d’acceuil de TestLink’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.6 tableau de bord IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.7 resultat de test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.8 Module Exigences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.9 Module Plan de test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.10 Exécutions des tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.11 Module Ergonomie interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.1 Capture d’écran Microsoft Visio . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.2 Diagramme des cas d’utilisation global . . . . . . . . . . . . . . . . . . . . . . . 34 3.3 Diagramme des cas d’utilisation d’invité . . . . . . . . . . . . . . . . . . . . . . 34 3.4 Diagramme des cas d’utilisation du testeur . . . . . . . . . . . . . . . . . . . . . 35 3.5 Diagramme des cas d’utilisation de concepteur de test . . . . . . . . . . . . . . . 36 3.6 Diagramme des cas d’utilisation d’administrateur . . . . . . . . . . . . . . . . . 37 3.7 digramme de classes statisque . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
  • 6. Table des figures 3.8 Digramme de déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 3.9 Diagramme de séquence d’authentification . . . . . . . . . . . . . . . . . . . . . 40 3.10 Diagramme de séquence d’ajout de nouveau utilisateur . . . . . . . . . . . . . . 41 3.11 Diagramme de séquence d’affectation des membres du l’équipe du projet de test 42 3.12 Diagramme de séquence de visualisation de projet de test . . . . . . . . . . . . 43 4.1 architecture du systeme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 4.2 structure d’un jeton jwt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 4.3 Composition de la page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.4 Quelque Exemple De Maquette . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.5 Aperçu de l’interface d’identification . . . . . . . . . . . . . . . . . . . . . . . . 54 4.6 Aperçu de l’interface de page d’acceuil . . . . . . . . . . . . . . . . . . . . . . . 55 4.7 Apercu de l’interface de gérer les projes du tests . . . . . . . . . . . . . . . . . . 56 4.8 Aperçu de l’interface de gérer les utlisateurs . . . . . . . . . . . . . . . . . . . . 56 4.9 Aperçu de l’interface de gérer les roles . . . . . . . . . . . . . . . . . . . . . . . 57 4.10 Aperçu de l’interface de suivi de test . . . . . . . . . . . . . . . . . . . . . . . . 57 4.11 Aperçu de l’interface d’affaction de smembers d’équipe . . . . . . . . . . . . . . 58 4.12 Aperçu de l’interface d’affectation des envirement de test . . . . . . . . . . . . . 58 4.13 Aperçu de l’interface de gérer d’écigence . . . . . . . . . . . . . . . . . . . . . . 59 4.14 Aperçu de l’interface de gérer la plan de test . . . . . . . . . . . . . . . . . . . . 59 4.15 Aperçu de l’interface de gérer la campagne de test . . . . . . . . . . . . . . . . . 60 4.16 Aperçu de l’interface de gérer rapport de test . . . . . . . . . . . . . . . . . . . 60 4.17 Aperçu de l’interface de visualisation details de campagne de test . . . . . . . . 61 4.18 Aperçu de l’interface de noter resultat . . . . . . . . . . . . . . . . . . . . . . . 62
  • 7. Liste des tableaux 1.1 Mot clés de La méthodologie SCRUM . . . . . . . . . . . . . . . . . . . . . . . . 8 2.1 les différents niveaux d’anomalies . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.1 Description détaillée des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
  • 9. Introduction Générale De nos jours, tout client a besoin de s’assurer que le produit qu’il compte s’offrir répondra bien à ses attentes. Cette évidence générale s’applique aussi le marché informatique dans le besoin est l’assurance qualité. L’assurance qualité est, selon la définition ISO 9000, la partie du management qui donne confiance en ce que les exigences de la qualité soient satisfaites. Elle constitue une garantie de la conformité du logiciel aux normes de la qualité et s’identifie sous la forme d’un document écrit, qui présente toute la politique qualité suivie tout au long de la production. En général, l’assurance qualité remplit deux principales fonctions : — Donner confiance au client et lui rassurer de la validité du logiciel. — Permettre de s’assurer la validité de chaque étape du développement, et ainsi de prévenir tout dysfonctionnement de la qualité. Assurer le développement ou la maintenance de logiciels n’est pas une tâche facile. Les normes sont définies de la façon afin de maximiser la performance de la qualité, mais les clients et les développeurs sont souvent laissés à eux-mêmes pour décider de la manière dont ils pourraient améliorer pratiquement la situation : C’est la problématique d’assurance qualité logicielle. L’assurance qualité logicielle est un ensemble d’activités planifiées et systématiques de toutes les actions nécessaires pour fournir une assurance suffisante adaptée aux exigences et aux attentes établies. Ce concept sert à la fois des objectifs internes et externes : — En interne, elles visent à donner confiance en sa stratégie de la direction et à maintenir le niveau de compétence de l’entreprise. — En externe, elles permettent d’obtenir la confiance des clients. Dans ce contexte, on se propose de créer un processus automatisé de gestion de tests qui a pour rôle de simplifier les tâches du service QA en tenant compte en premier lieu de la sécuriser des droits d’accès dans les projets de tests, de générer des rapports de tests et de suivre des tests. en second lieu de tracibiliter de chaque phase de déroulement des tests. 1
  • 10. Introduction Générale C’est dans ce cadre que se situe mon projet de fin d’études intitulé : « Conception et déve- loppement d’un outil de gestion des tests » dont l’objectif est de concevoir une plateforme appelée « TestLab - Proxym Group » dédiée à l’équipe assurance qualité. En conséquence, ce rapport s’articule autour de quatre chapitres comme suit : Le premier chapitre « présentation de l’organisme d’acceuil » consiste à présenter l’organisme d’accueil ainsi qu’une brève description sur la methode agile SCRUN. Le second chapitre « étude préalable » permet de placer le projet dans son contexte général en présentant la problématique ainsi qu’une brève description du projet. Le troieme chapitre, « conception de l’application » illustre la partie conception de notre ap- plication de point de vue statique et dynamique et expose les différentes tables formant notre base des données. Enfin ,le dernier chapitre « réalisation de l’application » détaille tous les outils utilisés pour le développement de notre application ainsi que quelques captures d’écran de la version finale de notre plateforme. 2
  • 12. 1Présentation de l’organisme d’accueil 1.1 Présentation de l’entreprise PROXYM-IT est une société, de services informatiques, fondée en janvier 2006 spécialisée dans les nouvelles technologies de l’information et de la communication. Sa direction commerciale est située à Lyon en France alors que sa direction technique est localisée à la technopole de Sousse en Tunisie. PROXYM-IT dispose d’une équipe de haut niveau composée d’ingénieurs issus de différentes formations élaborées au sein des Ecoles d’Ingénieurs Tunisiens et Français. [1] La figure 1.1 présente les différents groupes de la société PROXYM-Group : Figure 1.1 – Proxym Group 3
  • 13. Chapitre 1 Présentation de l’organisme d’accueil La figure 1.2 représente l’historique d’évolution de l’entreprise . Figure 1.2 – Histoire de PROXYM-IT 1.1.1 Organigramme L’organisation interne de PROXYM-IT se compose des départements suivants : — Direction Générale : La direction générale est constituée d’un PDG fondateur de PROXYM-IT Wassel Berrayana. — IT : Le département IT est le responsable de l’installation du réseau interne et de la réparation du matériel de tous les fonctionnaires de la société. Il valide les architectures réseau des différents projets développés chez PROXYM-IT. — DAF : La direction financière est responsable de la gestion de paie de tous les fonction- naires de PROXYM-IT, de l’achat et de la logistique. — DRH : La direction Ressources Humaines est le département responsable de tout le volet RH de la société, des gestions de carrière, des conflits, des formations et de recrutements. — Proxym-LAB : Le laboratoire Proxym est le nouveau bébé de la société PROXYM-IT. Son principale rôle est la veille technologique et l’innovation. Il permet la responsabilité de toutes les études liées à des projets qui nécessitent l’utilisation de nouvelles techno- logies sur le marché mondial. — Département de production : Le département de production est responsable à l’im- plémentation et la réalisation des projets clients. Il est organisé sous la logique d’une 4
  • 14. Chapitre 1 Présentation de l’organisme d’accueil organisation matricielle et Il est constitué de pôles fonctionnels (mobile First, E-Business, Mobilité, Centre de services). Chaque pôle est constitué de développeurs, experts, consul- tants et concepteurs gérés par un responsable de pôle . La responsabilité principale de ce dernier est de maintenir et assurer l’évolution technique de ses ressources. — PMO (Projet manager Office) : Ce département est constituée des chefs de projets, des responsables qualité, des consultants et des designers . Aussi il est responsable de la gestion des projets clients au sein de PROXYM-IT. la figure 1.3 illustrée une vue globale sur l’organisme interne de la société Proxym-IT : Figure 1.3 – Organisme interne de Proxym-IT 1.1.2 Domaines d’intervention La figure 1.4 décrit les différentes étapes d’un projet informatique réaliser par PROXYM-IT. 5
  • 15. Chapitre 1 Présentation de l’organisme d’accueil Figure 1.4 – Domaines d’intervention 1.1.3 Métiers PROXYM-IT a développé une expertise dans les domaines suivants : Solutions E-Commerce Sites & applications Mobile et web E-Gov E-Admin Réseaux Sociaux d’entreprises Solutions d’entreprises ERPs Médicaux Banking 6
  • 16. Chapitre 1 Présentation de l’organisme d’accueil 1.2 Méthodologie de travail Chaque personne peut songer à une idée, peut résoudre un problème et trouver des solutions pour faciliter n’importe quelle tâche. C’est pour cela qu’on doit opter pour les solutions les plus optimales pour avoir recours à une méthodologie efficace qui permet de gérer un cycle de vie d’un projet. 1.2.1 Définition de la méthodologie Agile Une méthodologie agile est une méthode de développement informatique permettant de conce- voir des logiciels en impliquant au maximum le client. Elle vise la satisfaction réelle du besoin du client. Avec l’utilisation de la méthode agile les phases sont simplifiées afin d’en raccourcir la durée. Elle se base sur la notion de communauté de projet dans laquelle les développeurs et les utilisateurs sont présents en permanence pour exprimer ou répondre à une question liée au projet. Grâce aux méthodes agiles, le client piloté à part entière de son projet et obtient très vite une première mise en production de son logiciel. [2] Cette méthode se base sur des cycles courts et permet de découper le projet en petits blocs et les hiérarchiser en fonction des besoins. 1.2.2 Méthodologie AGILE : SCRUM La méthode SCRUM est une méthode agile, crée en 2002, dont le nom est un terme emprunté au rugby qui signifie « la mêlée » qui permet de produire un logiciel dans la durée la plus courte. Afin de comprendre cette méthodologie on a établi le tableau 1.1 pour définir des mots clés qui vont nous servir tout au long du projet et de ce rapport. 7
  • 17. Chapitre 1 Présentation de l’organisme d’accueil Terme Définition Backlog du Produit Définition des besoins fonctionnels sous forme de « user story » Backlog de Sprint Liste des tâches à implémenter dans un sprint, classées par importance et état Burn-Down Chart Diagramme permettant à suivre l’état d’avancement du projet Produit Partiel Résultat du Sprint Testé et potentiellement livrable SCRUMQuotidien Le SCRUM meeting est une réunion d’une durée de 15 minutes, organisée quotidiennement, en position debout Table 1.1 – Mot clés de La méthodologie SCRUM La figure 1.5 donne une vue globale de SCRUM en utilisant les mots clés qu’on vient de définir : Figure 1.5 – vue globale de SCRUM Ce processus s’articule en effet autour d’une équipe soudée, qui cherche à atteindre un but. Cette méthodologie se progresse par une série d’itérations appelées sprints, qui durent de deux à quatre semaines. Le produit envisagé est conçu, codé et testé pendant ce sprint. A chaque fin de sprint, on peut voir fonctionnement le produit et décider soit de le livrer, soit de continuer à l’améliorer pendant un autre sprint. la figure 1.6 suivant resume le processus sur lequel est basé SCRUM : 8
  • 18. Chapitre 1 Présentation de l’organisme d’accueil Figure 1.6 – Processus de SCRUM Durant le développement d’un projet avec la méthode SCRUM il y a une interaction avec plusieurs intervenants : 1. Le « Product Owner » qui porte la vision du produit à réaliser. 2. Le « SCRUM Master » est la personne chargée de veiller à la mise en application de la méthode et au respect de ses objectifs. 3. « L’équipe de développement » qui réalise le produit. Conclusion Dans ce premier chapitre, nous avons présenté l’entreprise d’accueil ainsi que la methodologie de travail. 9
  • 20. 2Etude Préalable Introduction Dans ce chapitre, en premier lieu on présentera le contexte général du projet, le processus de tests et on finira cette partie par l’étude existant avant de conclurer. 2.1 Contexte Générale À l’heure actuelle, les entreprises informatiques, commencent à prendre conscience dans le ma- nagement du projet de l’importance de cette phase de test .Cette phase de teste est caractérisé par une stratégie de recette fonctionnelle et la mettre en œuvre pour assurer que le projet reste dans la bonne direction. Cependant ces entreprises de développement sont obligées de choisir des choix des méthodes et des outils de tests, et faire appel à des professionnels pour l’implémentation de cette stratégie de test. Ces méthodes de test s’évoluent ces dernières années, or des nombreux outils ont été conçus pour aider les testeurs à effectuer leurs démarches. D’où se pose les questions suivantes : — Comment garantir la qualité de projet pour le client ? — Qu’est-ce que test logiciel ? — Comment définir l’activité de test dans un projet logiciel ? 11
  • 21. Chapitre 2 Etude Préalable 2.1.1 Introduction à l’assurance qualité La planification de tests commence lors de la conception des applications ou de leur implé- mentation. Toutefois, les activités de tests et de vérification de la qualité ne se limitent pas au test du code des applications : la vérification de la qualité doit commencer par la validation de spécification (par exemple : la complétude et la testabilité). Tout d’abord, voici le contexte : Qu’est-ce que la qualité ? L’International organisation for standardization (ISO) définissait la qualité « comme l’ensemble des caractéristiques d’une entité qui lui confèrent l’aptitude à satisfaire des besoins exprimés et impli- cites ». Plus récemment, elle a complété cette définition qui est devenue la suivante : la qualité est « l’aptitude d’un ensemble de caractéristiques intrinsèques d’un produit, d’un système ou d’un processus à satisfaire les exigences des clients et autres parties intéressées ». [3] Les entreprises ont tendance à employer des métriques basées sur le nombre de bogues détectes : ce n’est pas l’objectif du test de logiciels. L’objectif est vérifié que le système réagit conformé- ment aux exigences et qu’il se comportera de même dans son environnement de production. En s’appuyant sur les meilleures pratiques en matière, cela permet c’identifier la source du défaut et d’en supprimer la cause, plutôt que de supprimer plusieurs fois le même défaut. C’est le cœur de l’assurance qualité. 2.1.2 Introduction auw tests logiciel Le test du logiciel est une approche dynamique de la vérification, destinée à s’assurer que ce logiciel possède effectivement les caractéristiques requises pour son contexte d’utilisation. Toute fabrication de produit suit les étapes suivantes : 1. Conception 2. Réalisation 3. Test « Le test », est un sujet vaste et complexe : les applications sont variées, les outils sont différents, cependant, les tests doivent être organisés et menés selon une démarche. . 12
  • 22. Chapitre 2 Etude Préalable Qu’est-ce que tester ? Il existe plusieurs définitions sur l’activité de test logiciel : « Le test d’un logiciel est une activité qui fait partie du processus de développement. Il est mené selon les règles de l’assurance de la qualité et débute une fois que l’activité de programmation est terminée. Il s’intéresse aussi bien au code source qu’au comportement du logiciel. Son objectif consiste à minimiser les chances d’apparitions d’une anomalie avec des moyens automatiques ou manuels qui visent à détecter aussi bien les diverses anomalies possibles que les éventuels défauts qui les provoqueraient ». [4] Différents types de tests d’un logiciel Un test désigne une procédure de vérification partielle d’un système pour détecter les anomalies. Ils sont très souvent effectués sur deux niveaux : 1. Le niveau structurel : C’est-à-dire au niveau du code. 2. Le niveau fonctionnel : Représenté par des tests portés sur les fonctionnalités de bas. Les tests fonctionnels étant appliqués sur plusieurs niveaux, il est donc préférable de présenter les tests d’une manière générale, suivant la manière dont ils sont effectués. Il peut présenter donc sous deux catégories : ’Les tests types boîtes blanches’ et ’Les tests types boîtes noires’. [5] Les tests types boîtes blanches Les tests types boîtes blanches sont des tests effectués au niveau de l’implémentation d’une application/module. Ils vont donc tenir compte de la structure du composant qui sera testé, c’est-à-dire des algorithmes utilisés, typages requis lors des appels de méthodes, etc. Voici trois tests importants pour valider la structure d’une application : — Les tests unitaires : Ce type de tests est utilisé pour valider des structures au niveau du code (méthodes, classes...). — Les tests d’intégrations : Ce type de tests est utilisé pour vérifier la cohésion des interfaces des modules et valide leurs communications. — Les tests de performances : Ce type de tests est utilisé pour permettre de tester la qualité du code développé. 13
  • 23. Chapitre 2 Etude Préalable Les tests types boîtes noires Les tests types boîtes noires sont des tests qui sont mis en place, sans avoir connaissance de la manière dont l’objet testé a été implémenté. Ils vont ainsi être utilisés pour valider les fonctionnalités fournies par l’application et donc les exigences établies par le client. Voici deux importants tests permettant de valider la fonctionnelle d’une application : — Les tests fonctionnels : Ce type de tests est utilisé pour vérifier la conformité de l’application développée avec le cahier des charges initial. Ils sont donc basés sur les spécifications fonctionnelles et techniques. — Les tests de non-régression : Ce type de tests est utilisé pour vérifier que des modi- fications n’ont pas altérées le fonctionnent de l’application. 2.1.3 Les Bugs (ou les anomalies) Le problème fondamental du développement des logiciels est « le problème de l’erreur ». De nombreux défauts et anomalies pouvant affecter un logiciel. En effet, dans cette partie, nous porterons notre attention sur les sources des bugs logiciels, ensuite les niveaux de la gravité des anomalies et nous terminerons par quelques exemples de bugs et leurs conséquences. 2.1.3.1 Qu’est-ce qu’un Bug ? Le terme BUG est utilisé pour désigner : Erreur =>Défaut => Anomalie. Figure 2.1 – La chaîne de l’erreur 14
  • 24. Chapitre 2 Etude Préalable — Erreur : « action humaine produisant un résultat incorrect ». [6] — Défaut : « Une imperfection dans un composant ou un système qui peut conduire à ce qu’un composant ou un système n’exécute pas les fonctions requises, par exemple une instruction ou une définition de données incorrecte. Un défaut, si rencontré lors de l’exécution, peut causer la défaillance d’un composant ou d’un système ». [6] — Anomalie : « toute condition qui dévie des attentes basées sur les exigences de spécifications, documents de conception, documents utilisateurs, standards etc., ou des perceptions ou expériences de quelqu’un. Les anomalies peuvent être trouvées pendant, mais pas uniquement, les revues, tests, analyses, compilations ou utilisation des produits logiciels ou de la documentation applicable. [6] 2.1.3.2 Qualification de la gravité des anomalies : Il existe plusieurs niveaux d’anomalies illustrés sur ce tableau ci-dessous : Gravité Description Bloquante L’anomalie provoque un arrêt complet du système ou une fonctionnalité indispensable est inexploitable (pour des raisons fonctionnelles ou de performance, Aucune solution de contournement. Majeure Une fonctionnalité indispensable est partiellement inopérante sans bloquer l’exploitation de l’outil. L’application peut continue. Mineure Une fonctionnalité non essentielle présente des dysfonctionnements sans bloquer l’exploitation de l’outil. Table 2.1 – les différents niveaux d’anomalies 2.1.3.3 Les sources des Bugs logiciels L’origine des bugs informatiques viennent des erreurs humaines tel que : — Une incompréhension du besoin et des exigences de l’organisation commanditaire — Manque du savoir faire et d’expertise, — Manque des compétences informatiques pour comprendre l’environnement de dévelop- pement et de l’exécution, La complexité des plates-formes — Une faible puissance des systèmes informatisés. 15
  • 25. Chapitre 2 Etude Préalable 2.1.4 Terminologie Avant de passer à la suite, précisons quelques définitions importantes de vocabulaire. [6] — Objet de tests : le composant ou système qui doit être testé. — Objectif de tests : une raison ou but pour la conception et l‘exécution d‘un test. — Anomalie : On parle d’anomalie quand le logiciel ne fait pas ce qu’on lui a demandé, qu’il se bloque. — Exigence : besoin ou attente formulé(e), habituellement implicite, ou imposé(e) — Plan de test : un document décrivant l’étendue, l’approche, les ressources et le planning des activités de test prévues. Il identifie entre autres les éléments et caractéristiques à tester, qui fera chaque tâche, le degré d’indépendance des testeurs, l’environnement de test, les techniques de conception des tests et les techniques de mesure des tests à utiliser, et tout risque nécessitant des plans de contingence. — Scenario de test (séquence de test) : C’est le concept qui précise la fonction à tester. La description y est précise et se réfère pour la recette fonctionnelle aux exigences de client. Un scénario de test est composé d’un ou plusieurs cas de tests. — Recette fonctionnelle — Cas de test : C’est un chemin fonctionnel à mettre en œuvre pour atteindre un objectif de test. Un cas de test se définit par le jeu d’essai à mettre en œuvre, les étapes de tests sont exécutées et les résultats attendus. — Etape de test (pas de test) : un ensemble de valeurs d’entrées (jeu de données de tests), de pré-conditions d’exécution, de résultats attendus et de post conditions d’exécution, développées pour un objectif ou une condition de tests particulière, tel qu’exécuter un chemin particulier d’un programme ou vérifier le respect d’une exigence spécifique — Jeu de données de test : Ce sont les données nécessaires pour l’exécution d’un cas de test. Ces données affectent où sont affectées par le logiciel testé. Elles sont stockées dans la base de données de tests. — Campagne de test : C’est l’élément le plus important et qui consiste à organiser les tests. Une campagne de test décrit quels sont les scénarios qui seront testés et donc enchaînés les uns aux autres. — Processus de test : processus consistant en toutes les activités du cycle de vie, statiques et dynamiques, concernant la planification et l’évaluation de produits logiciels, pour déterminer s’ils satisfont aux exigences, pour démontrer qu’ils sont aptes aux objectifs et pour en détecter des anomalies. 16
  • 26. Chapitre 2 Etude Préalable 2.1.5 Processus de test Le test n’est pas limité à l’exécution du logiciel dans le but d’identifier des défaillances : il est aussi nécessaire de planifier, définir des objectifs, concevoir des conditions de tests, prévoir des données de tests, et définir des critères de début et d’arrêt, des environnements de tests et bien sûr de contrôler tout cela. [7] Le processus de test se décompose en différentes activités : Figure 2.2 – Processus de test 2.1.5.1 La planification des tests Avant toute activité humaine, il est nécessaire d’organiser et planifier les activités à effectuer. Ceci vaut aussi pour le test des logiciels et systèmes. Elle consiste en la définition d’objectifs de tests et en la spécification des activités de tests à exécuter pour atteindre ces objectifs. 2.1.5.2 L’analyse et la conception des tests La phase d’analyse et de conception est celle où les objectifs de tests généraux – définis par l’entreprise et au niveau du plan de tests– sont utilisés pour concevoir les conditions de tests de l’application logicielle. Les objectifs généraux identifiés lors de la planification seront utilisés 17
  • 27. Chapitre 2 Etude Préalable pour construire les dossiers, conditions et procédures de tests. La conception des tests consiste à transformer des objectifs de tests en conditions de tests tangibles, puis en cas de tests. Les conditions de tests sont généralement abstraites alors que les cas de tests sont généralement concrets. 2.1.5.3 Implémentation des tests L’implémentation des tests consiste en la conversion des conditions de tests en cas de tests et en procédures de tests, avec des données de tests spécifiques et des résultats attendus précis. Des précisions sur l’environnement et les données de tests, ainsi que sur la séquences des cas de tests sont nécessaires afin d’anticiper l’exécution des tests. 2.1.5.4 Exécution des tests L’exécution des tests, dans l’environnement de tests, sur le logiciel ou système à tester, de façon à découvrir des différences entre les résultats attendus et les résultats obtenus, inclut les tâches liées à l’exécution des cas de tests, procédures de tests et suites de test. 2.1.5.5 Evaluation, Reporting et clôture Evaluation Du point de vue de la procédure de tests, le suivi d’avancement des tests implique la collecte d’informations. Les métriques vont prendre en compte les critères de sorties, tels que celles validées durant la planification. Reporting Le test est une activité dont les résultats intéressent de nombreuses parties pre- nantes : — Les testeurs, pour évaluer leurs propres prestations ; — Les responsables qualité pour déterminer les améliorations à entreprendre dans les pro- cessus, que ce soit lors des phases d’identification d’exigences, de revue, de conception ou de tests. Ces parties prenantes doivent être informées, par le biais de rapports d’avancement, de statis- tiques et de graphiques, pour répondre à leurs interrogations, et leur permettre de prendre des décisions en ayant les informations adéquates. 18
  • 28. Chapitre 2 Etude Préalable Clôture Une fois le logiciel ou système considéré comme livrable (pour une phase suivante de tests ou pour mise en production), ou le projet de test terminé (avec succès ou annulé), il est nécessaire de clôturer les activités de cette phase de tests. 2.2 Problématique Assurer la qualité des systèmes opérationnels d’un organisme n’est pas une tâche facile.Les normes sont définissaient des façons de faire pour maximiser la performance, mais les gestion- naires et les employés sont principalement laissés à eux-mêmes pour décider comment améliorer pratiquement la situation. Ils font face à plusieurs problèmes : — Pression de plus en plus élevée de livraisons rapides et de qualité. — Augmentation de l’imposition de normes nationales, internationales, professionnelles et de domaines. — Multiplicité des plates-formes et des techniques. Traditionnellement, la liste des tests à réaliser par le testeur est décrite dans les documents qui seront traités manuellement et les résultats à la fin seront regroupés et rendus au chef de test dans le format de rapport traité à la main ou tapé dans un éditeur de texte. Ces tâches peuvent être responsables de perte du temps, et de diminuer l’intégrité des informations tests si un incident se produit. 2.3 Présentation du projet Le stage a été réalisé au sein de la société Proxym-IT durant la période allant du 15 février au 15 juin. Notre stage, nous a permis de saisir l’opportunité de travailler sur l’un des micro- Framework PHP les plus populaires « Silex » et biloéthique Javascript « ReactJS ». 2.3.1 Description du projet Partant de ces besoins, la société PRPXYM-IT décidée de concevoir et de réaliser une plateforme d’automatisation et de génération des rapports de test destinée à l’équipe assurance qualité (QA) bien particulière gestion de tests, création et archivage des rapports de test et facilité les tâches du service QA. 19
  • 29. Chapitre 2 Etude Préalable Notre plateforme est intitulée "Test Lab - Proxym Group". Figure 2.3 – logo Test Lab - Proxym Group 2.3.2 Les objectifs du projet Dans cette partie, nous identifions les objectifs qui expriment les actions que le système doit effectuer. Notre système réalise les tâches suivantes : — Gérer de projet de test : Cette tache permet de gérer les projets test dans l’entreprise, d’ajouter des nouveaux projets à partir private plate-forme de l’entreprise, archiver les anciens et supprimer ce quand n’a pas besoin. — Gestion des plans de test : Cette tache permet de gérer les exigences d’un logiciel tout au long de son cycle de vie, de décrire des scénarios et des cas de tests assurant la va- lidation de ces exigences , enfin il permet de suivre l’ensemble des exceptions rencontrées lors des tests. — Gestion et Suivi des anomalies détectées : cette tache permet de gérer les anomalies détectées dans la phase d’exécution de test, de déclarer et suivire leur état avec les develepeurs. — automatisé la génération de rapport : dans chaque étape de déroulement du test, la plateforme doit offrir un ou plusieurs outils de collections d’informations et de calcul des statistiques afin de générer un rapport complet sous format word. — Interfaçage avec les applications tierces : Importer / Exporter des informations à partir d’autres plateformes externes. 2.4 Etude de l’existant L’étude de l’existant est une étape préliminaire qui nous a permis de dégager les problématiques et de ressortir les vrais besoins de l’entreprise, actuellement, l’équipe assurance qualité de Proxym-IT utilise ‘Redmine’ pour la gestion de projets et ‘teslink’ pour la gestion de tests. Néanmoins, il n’y a aucune communication automatique entre ces deux outils. 20
  • 30. Chapitre 2 Etude Préalable C’est pour cela, il n’est pas possible de consulter les détails des projets créés dans Redmine via testlink. De plus, au cas d’une anomalie les testeurs sont obligés de copier manuellement les résultats de tests ainsi que leurs suivis à partir de testlink dans Redmine . L’outil testlink est utilisé également pour la génération des rapports de tests, mais les testeurs doivent les enrichir manuellement par d’autres informations pour répondre aux exigences de l’équipe assurance qualité. 2.4.1 Redmine Redmine est une application web libre de gestion de projets complète en mode web, développée en Ruby sur la base du framework Ruby on Rails. Il a été créé par Jean-Philippe Lang. D’autres développeurs venant de la communauté des utilisateurs de Redmine contribuent depuis au projet. [8] Il est simple à utiliser, à administrer et à déployer et contient de nombreuses fonctionnalités puissantes : — Projets multiples — Suivi des tickets — Intégration de contrôle de source (SVN, Git, etc.) — Rôles et autorisations — Wiki de projet 21
  • 31. Chapitre 2 Etude Préalable Figure 2.4 – capture d’écran de gestion tickets 2.4.2 Testlink : TestLink est un outil basé sur le Web, utilisé pour la gestion des tests. Il permet de créer des plans de test, de prioriser les tests, affecter la conduction de test pour les utilisateurs et suivre les progrès. Il permet également de créer divers rapports et statistiques, a le système de gestion des exigences, interagit avec des outils de suivi des bogues. [9] TestLink permet de : — Gérer plusieurs comptes, — S’organiser efficacement les rôles lors des tests (qui effectuent le test, qui supervise, qui valide...) — Générer dynamiquement de nombreux graphiques et rapports de tests — Cahiers de recette o Document de spécification de tests, — Diagramme montrant le pourcentage de tests réussis, échoués, bloqués — Nombre total de bugs pour chaque cas de test — Gérer les exigences fonctionnelles Malgré la simplicité de l’interface, certains utilisateurs désapprouvent le côté design et le trouvent peu convivial ( figure 2.5) . 22
  • 32. Chapitre 2 Etude Préalable Figure 2.5 – Page d’acceuil de TestLink’ 2.4.3 Inconvénient de TestLink — Moins de fonctionnalités que les outils payants du marché — Un peu moins souple que les fichiers (Word, Excel) — Traduction partielle en français 2.5 Application similaire de l’outil de gestion des tests Autres outils existent sur le marché permettent de gérer les exigences fonctionnelles afin d’assu- rer une traçabilité entre exigences et plans de test, nous classerons ces outils en deux familles : 2.5.1 Les outils proposés par les grands editeurs comme HP. Dans le marché, on dispose de plusieurs outils de gestion de test comme le ‘Microsoft Test manager’ et ‘IBM Rational Quality’ manager ou nous choisissons d’utiliser le ’HP Quality Center’ vue son efficacité et sa tendance à aider pour mieux comprendre le terme d’assurance qualité et mieux expliquer démarche de processus de tests. 23
  • 33. Chapitre 2 Etude Préalable 2.5.1.1 IBM Rational Quality Manager IBM Rational Quality Manager est une solution alignée sur les cinq impératifs de la gestion du cycle de vie des applications : planification intégrée, traçabilité des artefacts connexes, intelli- gence de développement, automatisation et collaboration, amélioration continue des processus. [10] Figure 2.6 – tableau de bord IBM 2.5.1.2 Microsoft Test Manager Visual Studio Ultimate, Visual Studio Premium et Test Professional incluent Microsoft Test Manager depuis 2010, pour définir et gérer les plans de test pour les tests système manuels et automatisés. Ces plans de test sont stockés sur Team Foundation Server (TFS), et sont étroitement intégrés à ses outils de gestion du cycle de vie des builds et des applications. [11] Avec Microsoft Test Manager on peut : planifier des tests manuels, planifier des tests d’appli- cation à partir d’un document Microsoft Excel ou Microsoft Word, suivre la qualité logicielle, automatiser des tests système, configurer des tests. 24
  • 34. Chapitre 2 Etude Préalable Figure 2.7 – resultat de test 2.5.1.3 HP Quality Center L’outil HP Quality Center, est le plus pratiqué par les consultants parce qu’il permet de ré- pondre au besoin du client grâce à ses différents modules, ses avantages, et toutes ses fonction- nalités attendues. [11] L’outil s’inscrit en phase opérationnelle des tests pour : — Structurer la formalisation des tests, — Faciliter la communication entre les acteurs, — Gérer les anomalies, — Produire un suivi de l’avancement de la préparation et de l’exécution des tests. Il permet : — La capitalisation, — L’archivage des documents de tests, — La traçabilité de la couverture de tests, — La traçabilité de l’exécution des tests. 25
  • 35. Chapitre 2 Etude Préalable Module Exigences Il permet de gérer l’étape de la définition des exigences de test , identifier les différentes exigences de test : — l’Intégration de l’application dans le SI, — l’Installation, — la documentation Conformité fonctionnelle (règles de gestion), — les tests de charge et de performance, — la sécurité. Figure 2.8 – Module Exigences Module Plan de test Il permet d’effectuer l’étape de la conception des tests : un test doit être bien précis et relié à une exigence de test. 26
  • 36. Chapitre 2 Etude Préalable Figure 2.9 – Module Plan de test Module Exécutions des tests Il permet la préparation de l’étape de l’exécution de la recette ; créer un scénario pour chaque processus métier et noterleur resultat. Figure 2.10 – Exécutions des tests 27
  • 37. Chapitre 2 Etude Préalable 2.5.2 Les outils Open source 2.5.2.1 Squash TM Squash TM est le gestionnaire de référentiel de test de la suite open source Squash. Il permet de gérer les exigences, les scénarios de tests et les campagnes d’exécution, dans un contexte nativement multi-projet. [13] — Module Ergonomie interface : Cet outil a une interface intuitive et disponible en français, anglais, allemand (autres langues possibles) et contient un éditeur de texte riche permettant la mise en forme avancée des textes saisis (puces, liens hypertexte, polices, couleurs, images. . .) Figure 2.11 – Module Ergonomie interface — Module Reporting : Cet outil permet de générer des rapports d’exécution au format HTML. Et on détecte quelque type de rapport important : — Rapport d’exécution du test global. — Rapport détaillé en cas d’échec d’un test (anomalies) 28
  • 38. Chapitre 2 Etude Préalable 2.5.2.2 TestRail TestRail est un logiciel de gestion de cas de test basé sur le Web complet pour gérer efficacement, suivre et organiser vos efforts de tests de logiciels. Elle permet de suivre : Gérer efficacement les cas, les plans et les essais ,Augmentez considérablement la productivité des tests et obtenez des informations en temps réel sur la progression de vos tests. [14] — Module campagne de test Pour la plupart des projets, vous commencerez probablement à exécuter plusieurs tests pour une suite de test particulier au fil du temps. Par exemple, si vous lancez plusieurs versions d’un logiciel, vous pouvez effectuer une exécution de test pour chaque nouvelle version. De même, vous pouvez effectuer plusieurs tests pour une campagne de test en particulier en même temps. Cela peut être judicieux si vous souhaitez exécuter une campagne de test particulière pour plusieurs configurations (par exemple, différents systèmes d’exploitation). Vous pouvez ensuite lancer une exécution de test pour chaque configuration différente sur laquelle vous souhaitez tester. Les états de test suivants sont disponibles par défaut : — Non testé : Par défaut, les nouveaux tests ont le statut Non testé. Une fois qu’un résultat de test a été ajouté à un test, il ne peut plus jamais recevoir l’état non testé. — Passé : Un test est marqué comme Passé lorsqu’un testeur a vérifié les étapes de test et les résultats escomptés. — Échec : Un testeur marque un test comme étant échoué si l’une des étapes de test spécifiées a entraîné une erreur ou si le résultat attendu diffère du résultat réel du test. — Bloqué : L’état bloqué est utilisé pour signaler qu’un test ne peut pas être exécuté actuellement en raison d’une dépendance externe. Conclusion Dans ce chapitre, nous avons présenté le cadre général du projet ainsi qu’une brève description du contexte du sujet. Nous avons aussi présenté le sujet du stage qui nous a été confié. Enfin, nous avons présenté les applications similaires. 29
  • 40. 3Conception de “TestLab - Proxym Group” Introduction La conception est la phase la plus importante dans le cycle de développement d’un projet. Elle permet de mettre en place un modèle sur lequel il faut s’appuyer pour l’implémentation du système. Elle consiste à identifier les objets du système. Ces objets nécessitent à identifier. Ainsi nous allons élaborer le diagramme de classe du système pour décrire sa vue statique. Puis nous allons décrire la vue dynamique par les diagrammes de déploiement, de séquences. 3.1 L’outil de modélisation : Notre conception fait l’usage de l’outil Visio Microsoft . Microsoft Visio Microsoft Visio (officiellement Microsoft Office Visio) est un logiciel de diagrammes pour Win- dows qui fait partie de la suite bureautique Microsoft Office mais se vend séparément. On peut ainsi créer des diagrammes de Gantt et des réseaux de PERT . [15] 31
  • 41. Chapitre 3 Conception de “TestLab - Proxym Group” Figure 3.1 – Capture d’écran Microsoft Visio Microsoft Visio nous donne la possibilité : — De son implicite d’installation et de prise en main. — De la possibilité de générer le squelette des classes en languages Java, C++, C#, etc . — De créer des diagrammes professionnels rapidement avec des formes mises à jour et de nouveaux outils et des options de mise en forme. — D’associer des diagrammes à des données dynamiques et interpréter rapidement les don- nées complexes. 3.2 Les Diagrammes UML 3.2.1 Le Modèle des cas d’utilisation Les cas d’utilisation (use cases) a pour objectif de décrire sous forme d’actions et de réactions le comportement d’un système du point de vue d’un utilisateur. 3.2.1.1 Identification des acteurs : Un acteur est une personne, un matériel ou un logiciel qui interagit avec le système dans le but de réaliser une ou plusieurs fonctions concernant les cas d’utilisation. Les acteurs en interaction avec notre système sont : 32
  • 42. Chapitre 3 Conception de “TestLab - Proxym Group” L’administrateur Concepteur de test Testeur Invité Description détaillée des acteurs : Acteur Définition Rôle Invité Cet utilisateur n’appartient pas à l’équipe QA, il peut être un chef de projet, un développeur, un responsable du pôle, etc. L’invité à la permission de visualiser les détaille du projet. Testeur C’est l’exécuteur des cas de tests. Il enregistre les anomalies et les défauts du produit dans l’outil Le testeur ne peut qu’exécuter les tests qui lui sont attribués. Concepteur de test Cet utilisateur enregistre les exigences du produit et prépare les scénarios de tests. Il a les mêmes autorisations que le testeur. Néanmoins, il peut également gérer les plans de tests, et affecter les membres de l’équipe dans un projet L’administrateur C’est le responsable de test. Il lance le projet de test et vérifie les résultats de la fin de chaque campagne de test et projet de test Un administrateur a toutes les autorisations. Table 3.1 – Description détaillée des acteurs 3.2.2 Diagramme des cas d’utilisation global : Les cas d’utilisation permettent de décrire sous forme d’actions et de réactions le système du point de vue utilisateur. Ils donnent l’image d’une fonctionnalité du système déclenchée par une simulation d’acteur externe. Ils permettent de spécifier clairement et exhaustivement les besoins relatifs à chaque type d’utilisateur. Pour cela, nous avons utilisé les diagrammes des « cas d’utilisation » pour illustrer les fonc- tionnalités du système, figure 3.2. 33
  • 43. Chapitre 3 Conception de “TestLab - Proxym Group” Figure 3.2 – Diagramme des cas d’utilisation global 3.2.3 Diagramme de cas d’utilisation de l,’invité Le diagramme représenté par la figure 3.3 ci-dessous décrit les différentes actions réalisées par l’invité. Figure 3.3 – Diagramme des cas d’utilisation d’invité 34
  • 44. Chapitre 3 Conception de “TestLab - Proxym Group” Selon ce diagramme, l’invité peut consulter les détails de projet de test, en effet il peut : — Visualiser les statistiques d’une campagne de test, des environnements qu’il a testés et les scénarios de tests. — Visualiser les statistiques d’un projet de test, consulter les exigences, les anomalies, voir les rapports de tests et visualiser les membres d’équipe qui travaillent sur un projet particulier. 3.2.4 Diagramme de cas d’utilisation du Testeur Le diagramme représenté ci-dessous par la figure 3.4 décrit les différentes actions réalisées par le testeur. Figure 3.4 – Diagramme des cas d’utilisation du testeur Selon ce diagramme, le testeur peut consulter les détails d’un projet de test, en effet il peut : — Visualiser les détails d’une campagne, consulter les scénarios de tests et noter leur ré- sultat. — Signaler les anomalies et suivre leurs états sur Redmine 3.2.5 Diagramme de cas d’utilisation de Concepteur de test Le diagramme représenté ci-dessous par la figure 3.5 décrit les différentes actions réalisées par le concepteur de test. 35
  • 45. Chapitre 3 Conception de “TestLab - Proxym Group” Figure 3.5 – Diagramme des cas d’utilisation de concepteur de test Selon ce diagramme, le concepteur de tests peut gérer processus de test, en effet il peut : — Préparer ses plans de tests, préparer des scénarios de tests et générer des rapports de test. — Gérer les campagnes de tests, attribuer les scénarios a testé ont attribuant les environ- nements de tests. — Gérer les exigences d’un projet et générer dossier exigences. 3.2.6 Diagramme de cas d’utilisation d’administrateur Le diagramme représenté par la figure 3.6 ci-dessous décrit les différentes actions réalisées par l’administrateur. 36
  • 46. Chapitre 3 Conception de “TestLab - Proxym Group” Figure 3.6 – Diagramme des cas d’utilisation d’administrateur Selon ce diagramme, l’administrateur peut : — Gérer les projets de tests (consulter, créer, modifier, supprimer et archiver d’un projet de test). — Gérer les utilisateurs et leur attribuer leur rôles avec des droits d’accès bien définis. — Configurer l’authentification avec les plateformes externes (LDAP, TestLink et Red- mine). 3.3 Diagramme de classes statique Les diagrammes de classes expriment de manière générale la structure statique d’un système en termes de classes et de relations entre ces classes. Une classe permet de décrire un ensemble d’objets (attributs et comportements), tandis qu’une relation permet de faire apparaître des liens entre ces objets. La classe peut être vue comme la factorisation des éléments communs à un ensemble d’objets. En se basant sur ce qui précède, une solution conforme aux besoins exprimés et aux objectifs déjà fixés se résume dans un diagramme composé des classes suivantes : 37
  • 47. Chapitre 3 Conception de “TestLab - Proxym Group” Figure 3.7 – digramme de classes statisque 38
  • 48. Chapitre 3 Conception de “TestLab - Proxym Group” 3.4 Diagramme de déploiement : Le diagramme de déploiement est une vue statique qui sert à représenter l’utilisation de l’infra- structure physique par le système et la manière dont les composants du système sont répartis ainsi que leurs relations entre eux. Figure 3.8 – Digramme de déploiement 3.5 Diagramme de séquence Les diagrammes de séquences sont la présentation graphique des interactions entre les acteurs et le système selon un ordre chronologique dans la formulation UML. Dans la suite, nous présentons quelques diagrammes de séquence de notre système. Scénario d’authentification : La figure 3.9 illustre le diagramme de séquence de cas d’utilisation ’authentification’ 39
  • 49. Chapitre 3 Conception de “TestLab - Proxym Group” Figure 3.9 – Diagramme de séquence d’authentification L’authentification est désormais nécessaire si l’utilisateur veut bénéficier de plus de fonctionna- lités telles que le suivi des tests. La figure 3.9 montre les étapes qui sont concernées par cette opération d’authentification, sachant que pour cela il faut déjà avoir créé un compte. Scénario d’Ajout nouveau utilisateur : La figure 3.10 illustre le diagramme de séquence de cas d’utilisation ’ajouter nouveau utilisa- teur’ 40
  • 50. Chapitre 3 Conception de “TestLab - Proxym Group” Figure 3.10 – Diagramme de séquence d’ajout de nouveau utilisateur Pour créer un compte le contrôleur vérifie d’abord si les données saisies par l’utilisateur ne sont pas déjà enregistrées d’où l’opération de lecture simple à partir LDAP afin d’éviter les redondances. Puis une fois la vérification est terminée avec succès les informations peuvent être enregistrées dans la table utilisateur. Scénario affectation des membres du l’équipe du projet de test : La figure ci-dessous, illustre le diagramme de séquence de cas d’utilisation ’affectation des membres du l’équipe du projet de test’ 41
  • 51. Chapitre 3 Conception de “TestLab - Proxym Group” Figure 3.11 – Diagramme de séquence d’affectation des membres du l’équipe du projet de test Le concepteur de test a la possibilité d’affecter un testeur dans projet, il s’agit d’une opération effectuée sur la table utilisateur, de la table rôle. Nous avons choisi d’afficher un message de confirmation avant d’effectuer l’opération dans un souci de nous assurer que l’action n’a pas été initiée par erreur pour assurer plus de sécurité aux données préalablement sauvegardées par ce même utilisateur. Scénario de visualisation de projet de test : La figure 3.12 illustre le diagramme de séquence de cas d’utilisation ’visualisation de projet de test’ 42
  • 52. Chapitre 3 Conception de “TestLab - Proxym Group” Figure 3.12 – Diagramme de séquence de visualisation de projet de test Un invité peut à tout moment consulter le détail complet d’un projet donné (description, afficher membre d’équipe et environnement de test). Conclusion Dans ce chapitre conception, nous avons présenté la vue statique et dynamique de l’application à développer à travers des diagrammes UML. Nous avons, ainsi, réussi à concevoir notre modèle relationnel qui est constitué des différentes tables formant notre base des données. 43
  • 54. 4Réalisation de “TestLab - Proxym Group” Introduction Une des étapes de la vie d’un projet, aussi importante que la conception, est l’implémentation. Cette étape constitue la phase d’achèvement et d’aboutissement du projet. Pour remplir cette tâche avec succès il fut savoir utiliser les outils adéquats et nécessaires. Ce choix d’outils peut influencer sur la qualité du produit obtenu et donc nécessite une attention particulière et doit se baser sur les besoins du projet et le résultat escompté. Ce chapitre présente alors l’environnement technique du travail ainsi que le choix pris en matière d’environnement logiciel. Par la suite nous présentons les interfaces de notre solution. 4.1 Environnement de développement Dans cette partie nous nous intéressons à l’étude de l’environnement technique disponible pour la réalisation de notre projet ensuite nous justifions les choix pris en matière d’environnement logiciel pour mener à terme la partie applicative. 4.1.1 Environnement matériel Nous disposons de deux ordinateurs portables : — Intel Core7, 2.4GHz avec 8Go de RAM (OS : Windows 10) — server (OS : ubuntu lts 14.04) 45
  • 55. Chapitre 4 Réalisation de “TestLab - Proxym Group” 4.1.2 Environnement logiciel Les différents outils utilisés dans cette phase de réalisation sont les suivants : WampServer WampServer est une plateforme de développement Web de type WAMP, permettant de faire fonctionner localement (sans se connecter à un serveur externe) des scripts PHP. WampServer n’est en soi un logiciel, mais un environnement comprenant deux serveurs (Apache et MySQL), un interpréteur de script(PHP), ainsi que phpMyAdmin pour l’administration Web des bases MySQL. [16] Webstorm WebStorm est un environnement de développement intégré léger et puissant, parfaitement équipé pour un développement client complexe et un développement côté serveur avec Node.js. WebStorm dispose d’un support avancé pour JavaScript ,HTML , CSS , et leurs successeurs modernes, ainsi que pour des cadres tels queAngularJS ou ReactJs. [17] PhpStorm PhpStorm PhpStorm est un IDE PHP. Il fournit une prévention des erreurs à la volée, une autocomplification et un refactorat de code, un débogage de configuration à zéro et un éditeur de HTML, CSS et JavaScript étendu. PhpStorm fournit également des outils intégrés puissants pour le débogage, le test et le profilage de vos applications. [18] Axure Axure est un outil de création de wireframing (guide visuel qui représente le cadre squelettique d’un site Web) et de prototypage pour les concepteurs d’expérience sur le Web et les utilisateurs. [19] 46
  • 56. Chapitre 4 Réalisation de “TestLab - Proxym Group” PostMan Postman est outil pour les développeurs d’API pour partager, tester, documenter et surveiller les API. [20] 4.2 Environnement de programmation 4.2.1 PHP Hyper text Preprocessor, est un langage de scripts libre principalement utilisé pour produire des pages Web dynamiques via un serveur HTTP, mais pouvant également fonctionner comme n’importe quel langage interprété de façon locale, en exécutant les programmes en ligne de commande. PHP est un langage impératif disposant depuis la version 5 de fonctionnalités de modèle objet complètes. En raison de la richesse de sa bibliothèque, on désigne parfois PHP comme une plate-forme plus qu’un simple langage. [21] 4.2.2 HTML L’HyperText Markup Language, généralement abrégé HTML, est le format de données conçu pour représenter les pages web. C’est un langage de balisage permettant d’écrire de l’hypertexte, d’où son nom. HTML permet également de structurer sémantiquement et logiquement et de mettre en forme le contenu des pages, d’inclure des ressources multimédias dont des images, des formulaires de saisie, et des programmes informatiques. [22] 4.2.3 CSS CSS est l’acronyme de Cascading Style Sheets est un langage informatique qui décrit la pré- sentation des documents HTML, XHTML et XML. Les standards définissant le code CSS sont publiés par le World Wide Web Consortium (W3C). L’utilisation du CSS est indispensable pour le developpement web ( front end ) afin de rendre le site esthétique et responsive design. [23] 47
  • 57. Chapitre 4 Réalisation de “TestLab - Proxym Group” 4.2.4 JavaScript JavaScript est un langage de programmation utilisé pour rendre les pages Web interactives. Il fonctionne sur l’ordinateur de votre visiteur et ne nécessite pas de téléchargements constants sur votre site. [24] 4.2.5 Bootstrap Bootstrap est une collection d’outils utile à la création du design (graphisme, animation et interactions avec la page dans le navigateur , etc ) de sites et d’applications web. C’est un ensemble qui contient des codes HTML et CSS, des formulaires, boutons, outils de navigation et autres éléments interactifs, ainsi que des extensions JavaScript en option. C’est l’un des projets les plus populaires sur la plate-forme de gestion de développement GitHub. [25] 4.2.6 ReactJs React (aussi appelé React.js ou ReactJS) est une bibliothèque JavaScript libre développée par Facebook depuis 2013. Le but principal de cette bibliothèque est de faciliter la création d’application web , via la création de composants dépendant d’un état et générant une page (ou portion) HTML à chaque changement d’état. React est une bibliothèque qui ne gère que l’interface de l’application, considéré comme la vue dans le modèle MVC. Elle peut ainsi être utilisée avec une autre bibliothèque ou un framework MVC comme AngularJS. La bibliothèque se démarque de ses concurrents par sa flexibilité et ses performances, en travaillant avec un DOM virtuel et en ne mettant à jour le rendu dans le navigateur qu’en cas de nécessité. [26] 4.2.7 Silex Silex est un micro-framework PHP développé par la société française SensioLabs, créatrice du framework Symfony. Silex est en quelque sorte le petit frère de Symfony et les deux frameworks reposent sur les mêmes composants. [27] 48
  • 58. Chapitre 4 Réalisation de “TestLab - Proxym Group” 4.3 Système de gestion de la base de données relationnel 4.3.1 MySQL MySQL est un système de gestion de base de données. Selon le type d’application, sa licence est libre ou propriétaire. Il fait partie des logiciels de gestion de base de données les plus utilisés au monde, autant par le grand public (applications Web principalement) que par des professionnels, au même titre que Oracle ou Microsoft SQL Server. [28] 4.3.2 PhpMyAdmin PhpMyAdmin (PMA) est une application Web de gestion pour les systèmes de gestion de base de données MySQL réalisée en PHP. Il s’agit de l’une des plus célèbres interfaces pour gérer une base de données MySQL sur un serveur PHP. De nombreux hébergeurs, qu’ils soient gratuits ou payants, le proposent ce qui permet à l’utilisateur de ne pas avoir à l’installer.[29] 4.4 Architecture Logicielle du système : l’architecture du systéme de platforme développé est une architecture 3-tiers : Cette architecture vise a séparer les 3 couches logicielles suivantes : Figure 4.1 – architecture du systeme 49
  • 59. Chapitre 4 Réalisation de “TestLab - Proxym Group” — la couche présentation : qui correspond à l’affichage sur écran et l’interaction avec l’utilisateur , realiser avec reactJS — la couche traitement : qui correspond à la mise en oeuvre de l’ensemble des règles métier , realiser avec silex — la couche donnée : qui correspond à l’ensemble des données à conserver 4.4.1 Protocole et formats de données : 4.4.1.1 Protocole de communication Dans notre projet, nous avons utilisé le protocole HTTP, afin de communiquer les données entre l’application website et le serveur web. En effet, Le HTTP est un protocole qui définit la communication entre un serveur et un client. En général, nous avons utilisé la méthode Post pour envoyer des données au programme situé à une URL spécifiée. 4.4.1.2 Format de données communiquées JSON (JavaScript Object Notation) est un format léger d’échange de données. Il peut être aisément analysé et généré par des machines. [30] Lorsque l’application ReactJS s’exécute, elle se connectera au script PHP. Le script PHP va récupérer les données depuis la base de données MySQL. Ensuite les données seront encodées au format JSON et envoyées au système ReactJS. Ensuite, l’application ReactJS va obtenir ces données codées. Elle les analysera et les affichera sur interface. 4.4.2 Sécurité et droit d’accès a API : pour sécuriser API on choisi d’aborder JSON Web Token (JWT), un standard ouvert permet- tant à deux parties d’échanger de manière sûre des informations encapsulées dans un jeton signé numériquement. [31] Un jeton JWT est une chaîne de caractères décomposable en 3 sections séparées par un point (.) comme l’indique la figure 3.2 . 50
  • 60. Chapitre 4 Réalisation de “TestLab - Proxym Group” Figure 4.2 – structure d’un jeton jwt En-tête : c’est un document au format JSON, encodé en base 64 et contenant des méta- données. Il doit contenir au minimum le type de jeton et l’algorithme de chiffrement utilisé pour le signer numériquement. Charge utile : cette section est un document au format JSON encodé en base 64, contenant des données fonctionnelles minimales que l’on souhaite transmettre au service. En pratique, on y fait transiter des informations sur l’identité de l’utilisateur (login, nom complet, rôles, etc.). Signature : cette zone contient la signature numérique du jeton. La clé privée utilisée pour signer le jeton est stockée côté serveur. 4.5 Composition de la page : Le site se doit être simple d’utilisation et de navigation, que ce soit dans ses fonctionnalités ou que ce soit dans son contenu. Pour faciliter la navigation, il est obligatoire que l’ensemble des pages du site web possèdent la même structure et organisation. Pour cela, nous réalisé un modèle pour la structure des pages que vous pouvez observer ci- dessous la figure 3.7. La totalité des pages visibles par l’utilisateur posséderont cette même structure : - Un en-tête de page avec le logo du - Un menu de navigation complet. - Le contenu qui se modifiera selon les pages. - Un pied de page 51
  • 61. Chapitre 4 Réalisation de “TestLab - Proxym Group” Figure 4.3 – Composition de la page L’intérêt de procéder ainsi est que seul le contenu du site varie d’une page à l’autre, c’est pourquoi de page en page on inclue toujours le même en-tête, le même menu de navigation et le même pied de page. Cela évite de devoir implémenter à nouveau chaque partie du site, ce qui entraine un gain de temps considérable. 4.6 Maquettes du site : La maquette fonctionnelle (wireframe) Il s’agit de définir en noir en blanc la mise en page, l’organisation des différents éléments. La réalisation des maquettes est une étape déterminante dans la création d’un site internet. Pour que notre site web soit agréable, il faut naturellement soigner le design de l’interface graphique, mais surtout, pour que nos plates-formes internet soient efficaces, il faut construire une mise en page adaptée à nos objectifs et nos contenus. La réalisation des maquettes doit passer par plusieurs étapes, du design fonctionnel en noir et blanc, au design graphique intégrant votre identité et vos couleurs. Le wireframe ci-contre (figure 3.8) a a été réalisé à l’aide du logiciel Axure. 52
  • 62. Chapitre 4 Réalisation de “TestLab - Proxym Group” Figure 4.4 – Quelque Exemple De Maquette 4.7 Les IHM de l’application Cette section est consacrée à la présentation du travail réalisé à travers les aperçus des interfaces les plus pertinentes. 4.7.1 Administrateur 4.7.1.1 Interface d’authentification Tout d’abord, l’interface de démarrage est celle de l’authentification 53
  • 63. Chapitre 4 Réalisation de “TestLab - Proxym Group” Figure 4.5 – Aperçu de l’interface d’identification Cette interface permet à l’utilisateur de s’authentifier et de se connecter au serveur de la base de données. L’utilisateur doit entrer son login et son mot de passe pour accéder à l’application. En cas d’erreur un message d’alerte s’affiche : 1ierMessage d’erreur : Le message « le nom est obligatoire / email est obligatoire » c’est un message d’erreur, il s’affiche lorsque l’utlisateur laisse les champs vides. 2ème Message d’erreur Le message « Vérifier votre coordonné » c’est un message d’erreur qui s’affiche lorsque l’utlisateur a donné des cordonnes non valide. 4.7.1.2 Interface page d’acceuil La figure suivante présente la page d’accueil après authentification. Cette dernière comporte les menus qui sont les principales fonctions dans site web 54
  • 64. Chapitre 4 Réalisation de “TestLab - Proxym Group” Figure 4.6 – Aperçu de l’interface de page d’acceuil 4.7.1.3 Interface de Gérer Les Projets du Tests Cette interface est la plus importante dans notre application. Elle présente la liste des projets de tests. 55
  • 65. Chapitre 4 Réalisation de “TestLab - Proxym Group” Figure 4.7 – Apercu de l’interface de gérer les projes du tests 4.7.1.4 Interface de gérer les utlisateurs Figure 4.8 – Aperçu de l’interface de gérer les utlisateurs 56
  • 66. Chapitre 4 Réalisation de “TestLab - Proxym Group” 4.7.1.5 Interface de Gérer les roles Figure 4.9 – Aperçu de l’interface de gérer les roles 4.7.1.6 Interface de suivi de test Figure 4.10 – Aperçu de l’interface de suivi de test 57
  • 67. Chapitre 4 Réalisation de “TestLab - Proxym Group” 4.7.2 Concepteur de test 4.7.2.1 Interface affectation des members sur projet de test Figure 4.11 – Aperçu de l’interface d’affaction de smembers d’équipe 4.7.2.2 Interface affectation des envirement de test Figure 4.12 – Aperçu de l’interface d’affectation des envirement de test 58
  • 68. Chapitre 4 Réalisation de “TestLab - Proxym Group” 4.7.2.3 Interface de gérer d’exigence Figure 4.13 – Aperçu de l’interface de gérer d’écigence 4.7.2.4 Interface de gérer la plan de test Figure 4.14 – Aperçu de l’interface de gérer la plan de test 59
  • 69. Chapitre 4 Réalisation de “TestLab - Proxym Group” 4.7.2.5 Interface de gérer la campagne de test Figure 4.15 – Aperçu de l’interface de gérer la campagne de test 4.7.2.6 Interface de gérer rapport de test Figure 4.16 – Aperçu de l’interface de gérer rapport de test 60
  • 70. Chapitre 4 Réalisation de “TestLab - Proxym Group” 4.7.3 Testeur 4.7.3.1 Interface de visualisation de campagne de test Figure 4.17 – Aperçu de l’interface de visualisation details de campagne de test 61
  • 71. Chapitre 4 Réalisation de “TestLab - Proxym Group” 4.7.3.2 Interface de noter resultat campagne de test Figure 4.18 – Aperçu de l’interface de noter resultat Conclusion Dans ce chapitre nous avons présenté l’environnement de développement (matériel et logiciel) ainsi que les Framework utilisés pour le développement de notre application. Nous avons ensuite décrit le travail réalisé, et enfin, nous avons présenté quelques interfaces de l’application. 62
  • 73. Conclusion Générale Ce stage de fin d’étude était une bonne occasion pour améliorer mes connaissances théoriques et pratiques en informatique. En effet, nous avons eu l’opportunité de participer à la fois à la conception et à la réalisation d’une application Web au profit de la société d’accueil PRPOXYM- IT. L’application réalisée sert à la mise en place d’une plateforme d’automatisation et de géné- ration des rapports de test destinée à l’équipe assurance qualité (QA). Il n’est pas évident d’éviter les problèmes et les difficultés au niveau de la modélisation concep- tuelle ainsi que celles dans l’écriture des codes. Cependant, nous avons essayé de dégager les solutions les mieux adaptées à nos objectifs, nos contraintes et nos possibilités. En général, ce stage m’a beaucoup intéressé. J’ai pu découvrir des différents langages de pro- grammation HTML5 , CSS3 , ReactJS ,Silex et d’avoir un aperçu global de son fonctionnement. Il m’a permis aussi, de me familiariser avec les différents services et d’avoir une approche réelle du monde de travail. J’ai pu faire le rapprochement entre ce que j’avais appris en cours et ce qui se passe vraiment dans l’entreprise. Ce projet ne doit pas être considéré comme un produit fini par l’applica- tion pour la société mais plutôt comme un premier prototype qui sera la base des éventuelles extensions. 64
  • 75. Bibliographie [1] auteur : RH Dernière fois visité : 13 février 2017 Département Ressources Humaines chez PROXYM-IT [2] auteur : C. Aubry Dernière fois visité : 13 février 2017 SCRUM le guide pratique de la méthode agile la plus populaire, Dunod, 2010. [3] auteur : Organisme français de certification Dernière fois visité : 15 février 2017 https ://www.ofcertification.fr/qualite [4] auteur : Patrick FELIX Dernière fois visité : 16 février 2017 Test et Validation du Logiciel [ page 17] [5] auteur : Software Testing Romania Dernière fois visité : 21 février 2017 http ://www.softwaretesting.ro/Francais/Files/TestMethods/Software-Testing- Methods.html [6] auteur : CFTL/ISTQB Dernière fois visité : 22 février 2017 http ://swisstestingboard.org/wp- content/uploads/2014/04/Glossaire_des_tests_de_logiciel_- _2_1_F_ISTQB.pdf [7] auteur : journal du net Dernière fois visité : 22 février 2017 http ://www.journaldunet.com/developpeur/algo-methodes/test-logiciel-processus- fondamentaux/ [8] auteur : Dernière fois visité : 28 février 2017 https ://fr.wikipedia.org/wiki/Redmine 66
  • 76. Bibliographie [9] auteur : Kodjo Agbemebia Dernière fois visité : 5 Mars 2017 https ://blog.netapsys.fr/utilisez-testlink-pour-gerer-vos-cas-de-tests-2/ 10] auteur : All4Test Dernière fois visité : 8 Mars 2017 http ://www.all4test.fr/actualites/480-qu-est-qu-un-plan-de-test-logiciel-comment- rediger-un-bon-plan-de-test [11] auteur : Dernière fois visité : 22 Mars 2017 https ://msdn.microsoft.com/fr-fr/library/dd421945.aspx [12] auteur : Drifa KESRAOUI Dernière fois visité : 6 avril 2017 MEMOIRE « Test et Recette dans un Projet Logiciel, Evolution des Méthodes et Outils » Le 17 décembre 2014 [13] auteur : Dernière fois visité : 12 avril 2017 http ://www.squashtest.org/fr/decouvrir-squash-tm/contenu-statique/outils-et- fonctionnalites/squash-tm-test-management [14] auteur : Dernière fois visité : 12 avril 2017 http ://www.gurock.com/testrail/ [15] auteur : Dernière fois visité : 15 avril 2017 https ://fr.wikipedia.org/wiki/Microsoft_Visio [16] auteur : Dernière fois visité : 6 mai 2017 https ://fr.wikipedia.org/wiki/WampServer [17] auteur : Dernière fois visité : 11 juin 2017 https ://www.jetbrains.com/help/webstorm/meet-webstorm.html [18] auteur : Dernière fois visité : 11 juin 2017 https ://www.jetbrains.com/help/phpstorm/meet-phpstorm.html [19] auteur : Dernière fois visité : 11 juin 2017 https ://en.wikipedia.org/wiki/Axure_RP 67
  • 77. Bibliographie [20] auteur : Dernière fois visité : 11 juin 2017 https ://www.getpostman.com/company [21] auteur : Dernière fois visité : 11 juin 2017 https ://fr.wikipedia.org/wiki/PHP [22] auteur : Dernière fois visité : 11 juin 2017 https ://fr.wikipedia.org/wiki/Hypertext_Markup_Language [23] auteur : Dernière fois visité : 11 juin 2017 https ://fr.wikipedia.org/wiki/Feuilles_de_style_en_cascade [24] auteur : Dernière fois visité : 11 juin 2017 https ://fr.wikipedia.org/wiki/JavaScript [25] auteur : Dernière fois visité : 11 juin 2017 https ://fr.wikipedia.org/wiki/Bootstrap_(framework) [26] auteur : Dernière fois visité : 11 juin 2017 https ://fr.wikipedia.org/wiki/React_(JavaScript) [27] auteur : Baptiste Pesquet Dernière fois visité : 11 juin 2017 https ://openclassrooms.com/courses/premiers-pas-avec-le-framework-php-silex [28] auteur : Dernière fois visité : 11 juin 2017 https ://fr.wikipedia.org/wiki/MySQL [29] auteur : Dernière fois visité : 11 juin 2017 https ://fr.wikipedia.org/wiki/PhpMyAdmin [30] auteur : Dernière fois visité : 13 juin 2017 http ://www.json.org/jsonfr.html [31] auteur : Kadda SAHNINE Dernière fois visité : 13 juin 2017 http ://blog.inovia-conseil.fr/ ?p=236 68
  • 79. Annexes Annexe 1 « Pour aller plus loin » Nous vous proposons des adresses des sites internet (sites spécialisés) des grands acteurs des services de la qualité des logiciels et de la gestion de projets, des cabinets de conseil en infor- matique qui proposent des solutions et les outils : 1. Acial : http ://www.acial.fr/fr/slideshow/126-le-referentiel-tmmi-un-outil-pour-lamelioration- delactivite-de-test8.html 2. ConseilOrga : http ://www.conseilorga.com/Pages/Recettestestsetqualificationinformatique.aspx 3. Altea-conseil : http ://www.altea-conseil.com/consulter-nos-offres.html 4. Akal-consulting : http ://www.akal-consulting.com/# !resolution-incident/cd0d 5. irage-groupe : http ://www.viragegroup.com/fr/services/nos-services 6. Hsc :http ://www.hsc.fr/services/conseil.html.fr#ouvrage 7. LESORGANISATIONS PROFESSTIONNELLES : a) CFTL : http ://www.cftl.fr b) PMI : http ://www.pmi-france.org c) APRIL : http ://www.april.org/association 8. BLOGS/CLUB DES CONSULTANTS : a) http ://ulrichinaction.blogspot.fr/2013/04/integration-des-tests-fonctionnels.html b) http ://blog-du-consultant.fr/les-septs-galeres-du-consultant-independant/ c) http ://blogduconsultant.blogspot.fr/ d) http ://www.osaxis.fr/blog/automatiser-ses-tests-fonctionnels-partie-2-2/ e) http ://gestiondeprojets.wordpress.com/sabonner-au-blog/ f) http ://blog.univ-angers.fr/qsfs/category/test-logiciel/ g) http ://t37.net/tag/blogs-twitter-micro-blogging/ h) http ://t37.net/preparer-ses-plans-de-tests.html i) http ://je-choisis-ma-vie.fr/2012/11/19/ssii-consultants-changez/ j) http ://www.acial.fr/club-acial-test-logiciel/ 70
  • 80. Annexes Annexe A : Dictionnaire des attributs Voici une brève description des données mises en jeu dans l’application : 1. Exigence 2. Séquence de test 3. Cas De Test 4. Pas De Test 5. Resultat Pas de Test 6. Pièce jointe de résultat Pas de Test 7. Campagne De Test 8. itreation 9. resultat Iteration 10. Utilisateur 11. Role 12. Droit d’accès 13. Project_Role_Users 14. Projet De Test 15. Environnement De Test Annexe B : publiéer sur server Annexe C : Quelques APIs utilisé LDAP description sur ldap API Redmine description sur readmine API 71