Dossier de plan_de_tests_v1.00

DDPDT
GPA
Auteur : AAB
Réf : DDPDT_GPA_001.V1.00
2012/2013
Dossier de plans de tests
Gestion d'un parc automobile
Andrea, Arnold, Bellon
Objet Version Auteur Date
Rédaction initiale 0.70 A.A.B 07/01/13
Validation 1.00 A.A.B 18/01/13

DDPDT
GPA
Auteur : AAB
InstitutLimayrac| Andrea,Arnold,Bellon
2
Sommaire
1. Introduction.............................................................................................................................. 3
1.1 Objectif du document .......................................................................................................... 3
1.2 Portée du document............................................................................................................ 3
2. Exigences à tester...................................................................................................................... 4
3. Stratégies de tests..................................................................................................................... 4
3.1 Types de tests...................................................................................................................... 4
3.1.1 Tests fonctionnels.......................................................................................................... 4
3.1.2 Tests d'interface utilisateur............................................................................................ 6
3.1.3 Tests de donnéeset d'intégrité de base de données........................................................ 8
3.1.4 Tests de stress............................................................................................................... 9
3.2 Outils.................................................................................................................................10
4. Ressources...............................................................................................................................11
4.1 Travailleurs.........................................................................................................................11

DDPDT
GPA
Auteur : AAB
3
1. Introduction
1.1 Objectif du document
Ce document présente les plans de tests du projet. Cette phase est parallèle au dossier de
spécifications,etpermetd'établirle suivi dubonrespectdesprincipesde basesétablitdansle cahier
des charges.
L'application sera évaluée grâce à la description de l'ensemble des étapes obligatoires pour sa
validation.
1.2 Portée du document
Ce document participe à la vérification globale de l'application, et au bon fonctionnement
face aux problématiques du cahier des charges et du dossier de spécifications.
Ce plan de tests contribuera à la validation du projet.

DDPDT
GPA
Auteur : AAB
4
2. Exigences àtester
La liste suivante représente ce qui sera testé :
- Le contrôle de la procédure de connexion
- Le contrôle de l’ajout d’un véhicule dans la base de données
- Le bon fonctionnement de la recherche par mot clé
- La performance globale d’exécution du logiciel
- La performance du logiciel lorsque celui-ci est soumis à des conditions de fonctionnement
dégradées (comme une surcharge de clients par exemple)
3. Stratégies de tests
3.1 Types de tests
3.1.1 Testsfonctionnels
TF001
Objectif de test: Contrôler la procédure de connexion
Technique: Exécuter les cas d’utilisation, chaque chemin du cas ou fonction en utilisant des
données valides et non valides tout en vérifiant:
 Les résultats attendus avec des données valides.
 Les messages d’erreur et d’avertissement lorsque des données non valides
sont utilisées.
 Que chaque règle d’affaire est appliquée correctement.
Critère de complétion:  Tous les tests prévus ont été exécutés.
 Toutes les anomalies identifiées ont été enregistrées.
TF001
Titre:Connexion
Mode opératoire: Envoi des identifiants vers la base de données. La base de données vérifie la
validité de ces identifiants avant d'en autoriser ou non l'accès.
Eléments entrants: Identifiants (login et mot de passe)
Eléments sortants: Accès autorisé ou refusé vers le logiciel
Résultat attendu: Si les bons identifiants sont renseignés, l'accès doit être autorisé. Si ce sont les
mauvais, l'étape de connexion doit être répétée autant de fois que nécessaire.

DDPDT
GPA
Auteur : AAB
5
TF002
Objectif de test: Contrôler le bon fonctionnement de l'ajout d'un véhicule dans la BdD
Technique: Exécuter les cas d’utilisation, chaque chemin du cas ou fonction en utilisant des
données valides et non valides tout en vérifiant:
 Les résultats attendus avec des données valides.
 Les messages d’erreur et d’avertissement lorsque des données non valides
sont utilisées.
 Que chaque règle d’affaire est appliquée correctement.
Critère de complétion:  Tous les tests prévus ont été exécutés.
 Toutes le anomalies identifiées ont été enregistrées.
TF002
Titre:AjoutV
Mode opératoire: Après avoir sélectionné le mode d'ajout, un formulaire devant contenir les
caractéristiquesduvéhicule estproposé.Il doitêtre rempli et validé par l'utilisateur. Les champs du
formulaire sont envoyés dans la BdD, traités et sauvegardés dans une fiche véhicule.
Eléments entrants: Formulaire contenant les champs de caractéristiques du véhicule.
Eléments sortants: Fiche véhicule
Résultatattendu:Aprèsavoirconvenablement remplis le formulaire, la BdD sauvegarde le contenu
des champs, et le logiciel crée une fiche véhicule devant apparaitre dans la liste des véhicules.

DDPDT
GPA
Auteur : AAB
6
3.1.2 Testsd'interfaceutilisateur
TUI001
Objectif de test: Évaluer:
Le bon affichage des pages,avec la mise en page souhaitée,selon tel ou tel
navigateur (IE, Firefox, Chrome).
Technique: Produire des tests pourchaque écran afin de vérifier l’affichage, la navigation
et les états de chacun des écrans et composants de l’application.
Critère de complétion: La vérification de chaque écran est concluante en se conformant à la référence
ou à une norme acceptable.
Considérations:
particulières
Il est possible que toutes les propriétés personnalisables ou des composants
d’un tiers ne soient testées.
TUI001
Titre:AffichP
Mode opératoire:Pour chaque page affichée à l’écran, vérifier que la mise en page de celle-ci soit
correcte, quel que soit le navigateur utilisé, et qu’il n’y ai pas de problèmes d’affichage.
Eléments entrants:Interaction nécessitant l’ouverture d’une page.
Eléments sortants:Affichage de la page
Résultat attendu:Affichage correct de la page.

DDPDT
GPA
Auteur : AAB
7
TUI002
Objectif de test: Évaluer:
La recherche par mot clé
Technique: Produire des tests pourchaque écran afin de vérifier la navigation et les états de
chacun des écrans et composants de l’application en fonction des résultats de la
recherche.
Critère de complétion: La vérification de chaque écran est concluante en se conformant à la référence
ou à une norme acceptable.
Considérations:
particulières
Il est possible que toutes les propriétés personnalisables ou des composants
d’un tiers ne soient testées.
TUI002
Titre:RechMC
Modeopératoire:Aprèsavoirsélectionné le moderecherche,l'utilisateur peut lancer une recherche
globale de véhicules sur l'ensemble de la BdD en saisissant un mot clé.
Eléments entrants: Valeurs des champs influents sur les résultats de la recherche.
Eléments sortants: Résultat de la recherche
Résultatattendu:Aprèsavoirconvenablementlancerlarecherche, le systèmedoitutiliser le mot clé
pour aller puiser l'information souhaitée dans la BdD, et afficher ces résultats dans une liste.

DDPDT
GPA
Auteur : AAB
8
3.1.3 Testsde donnéeset d'intégritédebasede données
Stratégie pour le profilage de performance
Objectif de test: Vérifier la performance d’exécution du logiciel, la rapidité d'affichage des
résultats et évaluer le temps d'accès aux données de la BdD en charge de travail
normale.
Technique: Les procédures de test utilisées sont développées pourune évaluation cyclique
de fonctions.
Modifier les fichiers de données pouraccroître le nombre de transaction ou les
scripts pour accroître le nombre d’itérations des transactions.
Les scripts doivent être exécutés surune machine, le meilleur des cas pour
référencer un seul utilisateur et une seule transaction et être répété avec
plusieurs clients, virtuel ou réel selon les considérations particulières ci-
dessous.
Critère de complétion: Un seulutilisateur et une seule transaction : Complétion réussie des scripts de
test sans problèmes et dans le temps requis prévu par transaction.
Plusieurs transactions et plusieurs utilisateurs: Complétion réussie des scripts
de test sans problèmes et dans le temps requis prévu par transaction.
Considérations:
particulières
Une évaluation de performance valable suppose une charge de travail en arrière
plan sur le serveur:
Pour y arriver, différentes méthodes peuvent être utilisées :
 Émuler des ajouts de véhicules directement surle serveur à partir de
requêtes SQL.
 Créer une charge utilisateur virtuelle, pour simuler plusieurs centaines de
clients effectuant une recherche en même temps. Des outils d’émulation de
terminal à distance peuvent être utilisés. La technique peut aussiêtre
utilisés pour testerle trafic réseau.
 Utiliser plusieurs clients physiques,parl’exécution de scripts de test pour
charger le système.
Les tests de performance doivent être exécutés sur une machine dédiée ou à un
moment dédié, afin de s’assurerde mesures contrôlées exactes.
Les bases de données utilisées pour les tests de performance doivent avoir une
taille courante ou avoir une taille proportionnellement comparable.

DDPDT
GPA
Auteur : AAB
9
3.1.4 Testsde stress
Stratégie pour les tests de stress
Objectif de test: Vérifier que la cible de test fonctionne correctement et sans erreur dans les
conditions de stress suivantes :
 Mémoire vive du serveur (RAM) ou unité de stockage à accès direct
(DASD) disponible absente ou minime.
 Nombre maximum de clients, actuels ou potentiels,connectés
simultanément.
 Plusieurs utilisateurs exécutent les mêmes transactions sur lesmêmes
données.
 Le pire des cas en volume et en nature de transaction,c'est à dire le nombre
maximum de données (ici des fiches véhicules) pouvant être gérés par le
système et par la BdD avant saturation.
NOTES: Le but d’un test de stress doit aussipermettre d’identifier et de
documenter les conditions sous lesquelles le système n’arrive pas à continuer
de fonctionner correctement.
Les tests de stress pourla partie client sont décrits à la section 3.1.10 à la
rubrique Tests de configuration.
Technique: Utiliser des tests développés pour le profilage de la performance (Tests de
données et d'intégrité de base de données).
Pour testerun contexte de ressources limitées, les tests doivent être exécutés sur
une seule machine où la RAM et le DASD doivent être réduits.
Pour les autres tests de stress,plusieurs clients doivent exécuter simultanément
le même test ou des tests complémentaires pour simules l e pire des cas en
volume et en nature de transaction.
Critère de complétion: Tous les tests planifiés sont exécutés et les limites du système sont atteintes ou
dépassées sans défaillance du logicielle ou lorsque la défaillance survient alors
que les conditions ne sont pas les conditions spécifiées.
Considérations:
particulières
Une surcharge de réseau peut requérir des outils réseau pour charger des
messages ou des paquets.
Le DASD utilisé pour le système doit être temporairement réduit pour
restreindre l’espace disque nécessaire à la croissance de la base de données.
Une synchronisation des accès simultanés des clients aux mêmes données est
nécessaire.

DDPDT
GPA
Auteur : AAB
10
3.2 Outils
Les outilssuivantsontété employéspourmeneràbience projet :
Outil
Suivi des anomalies Firedebug
Environnement de développement WampServer
CakePHP
Notepad++
Développement collaboratif GitHub
WorkBrench
ArgoUML

DDPDT
GPA
Auteur : AAB
11
4. Ressources
4.1 Travailleurs
Troispersonnessontnécessairesàl’effortde test :
- BellonLOUBAKI,responsable qualité,estparlamême occasionle responsabledestests.
- AndreaDUPUY estle concepteurde test.
- ArnoldBOUNGOUNGOU estle testeur.
Ce tableauénumère lesressourceshumainesnécessairesàla réalisationde ce plan :
Ressources humaines
Travailleur Nombre minimum
(plein temps)
Responsabilités - commentaires
Responsable des tests 1 personne
Fournir un encadrement de gestion
Responsabilités:
 Fournir une direction technique
 Recruter les ressources appropriées
 Gérer les rapports
Concepteur de test 1 personne
Identifier, prioriser et implémenter les cas de test
Responsabilités:
 Générer le plan de tests
 Générer le modèle de tests
 Évaluer l’efficacité de l’effort de test
Testeur 1 personne
Exécuter les tests
Responsabilités:
 Exécuter les tests
 Journaliser les résultats
 Reprendre sur les erreurs
 Documenter les anomalies et les demandes de changement.

Dossier de plan_de_tests_v1.00

Contenu connexe

Tendances

En vedette

Plus de Arnold Stellio

Dossier de plan_de_tests_v1.00