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

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 planiﬁcation 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 Identiﬁcation 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 ﬁgures
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 diﬀérents niveaux d’anomalies . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1 Description détaillée des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

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

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

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

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

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

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

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

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

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

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

— 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

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

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

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

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éﬁnissaient 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 ﬁn 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

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

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

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

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

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

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 diﬀé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

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

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

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

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

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 Identiﬁcation 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

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

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 ﬁgure 3.3 ci-dessous décrit les diﬀérentes actions réalisées par
l’invité.
Figure 3.3 – Diagramme des cas d’utilisation d’invité
34

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

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

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

Figure 3.7 – digramme de classes statisque
38

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

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

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

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

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, aﬃcher
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 diﬀérentes tables formant notre base des données.
43

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
inﬂuencer 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 justiﬁons 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

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éﬁnissant 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 ) aﬁn de rendre le site esthétique et responsive design.
[23]
47

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 ﬂexibilité 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

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

— 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

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

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

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’authentiﬁcation
Tout d’abord, l’interface de démarrage est celle de l’authentiﬁcation
53

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

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

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

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

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

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

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

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

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 enﬁn, nous avons présenté quelques interfaces de l’application.
62

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

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 certiﬁcation Dernière fois visité : 15 février 2017
https ://www.ofcertiﬁcation.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
http ://www.gurock.com/testrail/
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
https ://www.jetbrains.com/help/phpstorm/meet-phpstorm.html
https ://en.wikipedia.org/wiki/Axure_RP
67

Bibliographie
https ://www.getpostman.com/company
https ://fr.wikipedia.org/wiki/PHP
https ://fr.wikipedia.org/wiki/Hypertext_Markup_Language
https ://fr.wikipedia.org/wiki/Feuilles_de_style_en_cascade
https ://fr.wikipedia.org/wiki/JavaScript
https ://fr.wikipedia.org/wiki/Bootstrap_(framework)
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
https ://fr.wikipedia.org/wiki/MySQL
https ://fr.wikipedia.org/wiki/PhpMyAdmin
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

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/Recettestestsetqualiﬁcationinformatique.aspx
3. Altea-conseil : http ://www.altea-conseil.com/consulter-nos-oﬀres.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

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

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

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

Ähnlich wie réaliser une plateforme d’automatisation et de génération des rapports de test (20)

Mehr von ahmed oumezzine

Mehr von ahmed oumezzine (6)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

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