Dossier de rapport_de_tests_v1.00

DDRDT GPA

Auteur : AAB Rf : DDRDT_GPA_001.V1.00

2012/2013

Dossier de rapport de tests Gestion d'un parc automobile

Andrea, Arnold, Bellon

Objet Version Auteur Date Rdaction initiale 0.70 A.A.B 10/01/13 Validation 1.00 A.A.B 18/01/13

DDRDT GPA


Institut Limayrac | Andrea, Arnold, Bellon

2

Sommaire

1. Introduction ......................................................................................................................................... 3

1.1 Objectif du document.................................................................................................................... 3

1.2 Porte du document...................................................................................................................... 3

2. Tests ..................................................................................................................................................... 4

DDRDT GPA



3

1. Introduction

1.1 Objectif du document

Ce document prsente le rapport de tests du projet. Cette phase est parallle au dossier de

plan de tests, et permet d'tablir les rsultats de tests planifis dans le dossier de plan de tests.

1.2 Porte du document

Ce document participe la validation globale de l'application, et permet de vrifier le bon

fonctionnement du logiciel en fonction des contraintes de tests.

DDRDT GPA



4

2. Tests

TF001

Objectif de test: Contrler la procdure de connexion

Mode opratoire: Envoi des identifiants vers la base de donnes. La base de donnes vrifie la

validit de ces identifiants avant d'en autoriser ou non l'accs.

Rsultat attendu: Si les bons identifiants sont renseigns, l'accs doit tre autoris. Si ce sont les

mauvais, l'tape de connexion doit tre rpte autant de fois que ncessaire.

Resultat: Valid

TF002

Objectif de test: Contrler le bon fonctionnement de l'ajout d'un vhicule dans la BdD

Mode opratoire: Aprs avoir slectionn le mode d'ajout, un formulaire devant contenir les

caractristiques du vhicule est propos. Il doit tre rempli et valid par

l'utilisateur. Les champs du formulaire sont envoys dans la BdD, traits et

sauvegards dans une fiche vhicule.

Rsultat attendu: Aprs avoir convenablement remplis le formulaire, la BdD sauvegarde le

contenu des champs, et le logiciel cre une fiche vhicule devant apparaitre

dans la liste des vhicules.

Resultat: Valid

TUI001

Objectif de test: valuer:

Le bon affichage des pages, avec la mise en page souhaite, selon tel ou tel

navigateur (IE, Firefox, Chrome).

Mode opratoire: Pour chaque page affiche lcran, vrifier que la mise en page de celle-ci soit

correcte, quel que soit le navigateur utilis, et quil ny ai pas de problmes

daffichage.

Rsultat attendu: Affichage correct de la page.

Rsultat: Trs bon fonctionnement sous Firefox et Chrome

Srieux problmes d'affichages sous IE: INCOMPATIBILITE

DDRDT GPA



5

TUI002

Objectif de test: valuer:

La recherche par mot cl

Mode opratoire: Aprs avoir slectionn le mode recherche, l'utilisateur peut lancer une

recherche globale de vhicules sur l'ensemble de la BdD en saisissant un mot

cl.

Rsultat attendu: Aprs avoir convenablement lancer la recherche, le systme doit utiliser le mot

cl pour aller puiser l'information souhaite dans la BdD, et afficher ces

rsultats dans une liste.

Rsultat: Valid

Stratgie pour le profilage de performance

Objectif de test: Vrifier la performance dexcution du logiciel, la rapidit d'affichage des

rsultats et valuer le temps d'accs aux donnes de la BdD en charge de travail

normale.

Technique: Les procdures de test utilises sont dveloppes pour une valuation cyclique

de fonctions.

Modifier les fichiers de donnes pour accrotre le nombre de transaction ou les

scripts pour accrotre le nombre ditrations des transactions.

Les scripts doivent tre excuts sur une machine, le meilleur des cas pour

rfrencer un seul utilisateur et une seule transaction et tre rpt avec

plusieurs clients, virtuel ou rel selon les considrations particulires ci-

dessous.

Rsultat: Valid

DDRDT GPA



6

Stratgie pour les tests de stress

Objectif de test: Vrifier que la cible de test fonctionne correctement et sans erreur dans les

conditions de stress suivantes :

Mmoire vive du serveur (RAM) ou unit de stockage accs direct (DASD) disponible absente ou minime.

Nombre maximum de clients, actuels ou potentiels, connects simultanment.

Plusieurs utilisateurs excutent les mmes transactions sur lesmmes donnes.

Le pire des cas en volume et en nature de transaction, c'est dire le nombre maximum de donnes (ici des fiches vhicules) pouvant tre grs par le

systme et par la BdD avant saturation.

NOTES: Le but dun test de stress doit aussi permettre didentifier et de

documenter les conditions sous lesquelles le systme narrive pas continuer

de fonctionner correctement.

Les tests de stress pour la partie client sont dcrits la section 3.1.10 la

rubrique Tests de configuration.

Technique: Utiliser des tests dvelopps pour le profilage de la performance (Tests de

donnes et d'intgrit de base de donnes).

Pour tester un contexte de ressources limites, les tests doivent tre excuts sur

une seule machine o la RAM et le DASD doivent tre rduits.

Pour les autres tests de stress, plusieurs clients doivent excuter simultanment

le mme test ou des tests complmentaires pour simules l e pire des cas en

volume et en nature de transaction.

Rsultat: Valid mais court terme

A long terme (plusieurs annes d'exploitation), la base de donnes

devra tre amliore.

Documents

Dossier de rapport_de_tests_v1.00