Dossier de rapport_de_tests_v1.00

393 vues

Publié le

Projet : Création d'un logiciel de gestion de parc automobile.
CPI. Institut Limayrac, Toulouse

0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
393
Sur SlideShare
0
Issues des intégrations
0
Intégrations
2
Actions
Partages
0
Téléchargements
7
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Dossier de rapport_de_tests_v1.00

  1. 1. DDRDT GPA Auteur : AAB Réf : DDRDT_GPA_001.V1.00 2012/2013 Dossier de rapport de tests Gestion d'un parc automobile Andrea, Arnold, Bellon Objet Version Auteur Date Rédaction initiale 0.70 A.A.B 10/01/13 Validation 1.00 A.A.B 18/01/13
  2. 2. DDRDT GPA Auteur : AAB Réf : DDRDT_GPA_001.V1.00 Institut Limayrac | Andrea, Arnold, Bellon 2 Sommaire 1. Introduction......................................................................................................................................... 3 1.1 Objectif du document.................................................................................................................... 3 1.2 Portée du document...................................................................................................................... 3 2. Tests..................................................................................................................................................... 4
  3. 3. DDRDT GPA Auteur : AAB Réf : DDRDT_GPA_001.V1.00 Institut Limayrac | Andrea, Arnold, Bellon 3 1. Introduction 1.1 Objectif du document Ce document présente le rapport de tests du projet. Cette phase est parallèle au dossier de plan de tests, et permet d'établir les résultats de tests planifiés dans le dossier de plan de tests. 1.2 Portée du document Ce document participe à la validation globale de l'application, et permet de vérifier le bon fonctionnement du logiciel en fonction des contraintes de tests.
  4. 4. DDRDT GPA Auteur : AAB Réf : DDRDT_GPA_001.V1.00 Institut Limayrac | Andrea, Arnold, Bellon 4 2. Tests TF001 Objectif de test: Contrôler la procédure de 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. 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. Resultat:  Validé TF002 Objectif de test: Contrôler le bon fonctionnement de l'ajout d'un véhicule dans la BdD Mode opératoire: Après avoir sélectionné le mode d'ajout, un formulaire devant contenir les caractéristiques du véhicule est proposé. 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. Résultat attendu: Après avoir convenablement 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. Resultat:  Validé 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). 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. Résultat attendu: Affichage correct de la page. Résultat:  Très bon fonctionnement sous Firefox et Chrome  Sérieux problèmes d'affichages sous IE: INCOMPATIBILITE
  5. 5. DDRDT GPA Auteur : AAB Réf : DDRDT_GPA_001.V1.00 Institut Limayrac | Andrea, Arnold, Bellon 5 TUI002 Objectif de test: Évaluer: La recherche par mot clé Mode opératoire: Après avoir sélectionné le mode recherche, l'utilisateur peut lancer une recherche globale de véhicules sur l'ensemble de la BdD en saisissant un mot clé. Résultat attendu: Après avoir convenablement lancer la recherche, le système doit utiliser le mot clé pour aller puiser l'information souhaitée dans la BdD, et afficher ces résultats dans une liste. Résultat:  Validé 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 pour une évaluation cyclique de fonctions. Modifier les fichiers de données pour accroî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 sur une 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. Résultat:  Validé
  6. 6. DDRDT GPA Auteur : AAB Réf : DDRDT_GPA_001.V1.00 Institut Limayrac | Andrea, Arnold, Bellon 6 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 aussi permettre d’identifier et de documenter les conditions sous lesquelles le système n’arrive pas à continuer de fonctionner correctement. Les tests de stress pour la 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 tester un 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. Résultat:  Validé mais à court terme A long terme (plusieurs années d'exploitation), la base de données devra être améliorée.

×