Dossier de plan_de_tests_v1.00

402 vues

Publié le

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

1 commentaire
1 j’aime
Statistiques
Remarques
  • Avec plus de 700 véhicules en gestion externalisée, Buy Made Easy adopte une approche résolument NEUTRE et INDÉPENDANTE vis-à-vis des financeurs et constructeurs.

    Gestion de parc automobile dans sa globalité, Buy Made Easy prend en charge votre flotte à 100% avec un tarif unique mensuel par véhicule afin d'adapter le budget aux variations de votre activité.

    http://www.buymadeeasy.com/nos-metiers-solutions/consulting-en-achats/flotte-automobile.html#gestions-de-parc
       Répondre 
    Voulez-vous vraiment ?  Oui  Non
    Votre message apparaîtra ici
Aucun téléchargement
Vues
Nombre de vues
402
Sur SlideShare
0
Issues des intégrations
0
Intégrations
1
Actions
Partages
0
Téléchargements
25
Commentaires
1
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Dossier de plan_de_tests_v1.00

  1. 1. 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
  2. 2. DDPDT GPA Auteur : AAB Réf : DDPDT_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. 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ées et 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
  3. 3. DDPDT GPA Auteur : AAB Réf : DDPDT_GPA_001.V1.00 Institut Limayrac | Andrea, Arnold, Bellon 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, et permet d'établir le suivi du bon respect des principes de bases établit dans le 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.
  4. 4. DDPDT GPA Auteur : AAB Réf : DDPDT_GPA_001.V1.00 Institut Limayrac | Andrea, Arnold, Bellon 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 Tests fonctionnels 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.
  5. 5. DDPDT GPA Auteur : AAB Réf : DDPDT_GPA_001.V1.00 Institut Limayrac | Andrea, Arnold, Bellon 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é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. Eléments entrants: Formulaire contenant les champs de caractéristiques du véhicule. Eléments sortants: 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.
  6. 6. DDPDT GPA Auteur : AAB Réf : DDPDT_GPA_001.V1.00 Institut Limayrac | Andrea, Arnold, Bellon 6 3.1.2 Tests d'interface utilisateur 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 pour chaque é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.
  7. 7. DDPDT GPA Auteur : AAB Réf : DDPDT_GPA_001.V1.00 Institut Limayrac | Andrea, Arnold, Bellon 7 TUI002 Objectif de test: Évaluer: La recherche par mot clé Technique: Produire des tests pour chaque é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 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é. Eléments entrants: Valeurs des champs influents sur les résultats de la recherche. Eléments sortants: Résultat de la recherche 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.
  8. 8. DDPDT GPA Auteur : AAB Réf : DDPDT_GPA_001.V1.00 Institut Limayrac | Andrea, Arnold, Bellon 8 3.1.3 Tests de données et d'intégrité de base de 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 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. Critère de complétion: Un seul utilisateur 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 sur le 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 tester le trafic réseau. Utiliser plusieurs clients physiques, par l’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’assurer de 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.
  9. 9. DDPDT GPA Auteur : AAB Réf : DDPDT_GPA_001.V1.00 Institut Limayrac | Andrea, Arnold, Bellon 9 3.1.4 Tests de 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 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. 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.
  10. 10. DDPDT GPA Auteur : AAB Réf : DDPDT_GPA_001.V1.00 Institut Limayrac | Andrea, Arnold, Bellon 10 3.2 Outils Les outils suivants ont été employés pour mener à bien ce projet : Outil Suivi des anomalies Firedebug Environnement de développement WampServer CakePHP Notepad++ Développement collaboratif GitHub WorkBrench ArgoUML
  11. 11. DDPDT GPA Auteur : AAB Réf : DDPDT_GPA_001.V1.00 Institut Limayrac | Andrea, Arnold, Bellon 11 4. Ressources 4.1 Travailleurs Trois personnes sont nécessaires à l’effort de test : - Bellon LOUBAKI, responsable qualité, est par la même occasion le responsable des tests. - Andrea DUPUY est le concepteur de test. - Arnold BOUNGOUNGOU est le testeur. Ce tableau énumère les ressources humaines nécessaires à la réalisation de 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.

×