Système d'inscription aux cours
Plan de test pour le prototype architectural
Version 1.0
Historique des révisions
Date | Version | Description | Auteur |
---|---|---|---|
7/mars/1999 | 1.0 | Edition initiale - Plan de test du prototype | K. Stone |
|
|
|
|
|
|
|
|
|
|
|
|
Sommaire
Plan de test
pour le
prototype architectural
1. Objectifs
1.1 Objet
Ce document décrit le plan de test du prototype architectural du système d'inscription aux cours. Ce document relatif au plan de test a les objectifs suivants :
Ce plan de test offre une description des tests d'intégration et de système qui seront menés sur le prototype architectural à la suite de l'intégration des sous-systèmes et des composants identifiés dans le plan de construction et intégration du prototype [16].
Il est supposé que le test unitaire a déjà fourni un test fonctionnel complet, une couverture approfondie du code source et un test de toutes les interfaces de module.
L'objectif de l'assemblage du prototype architectural était de tester la faisabilité et les performances de l'architecture sélectionnée. Il est crucial, à ce stade, d'avoir testé toutes les interfaces système et sous-système ainsi que les performances système. Le test des fonctionnalités et caractéristiques système ne sera pas effectué sur le prototype.
Les interfaces entre les sous-systèmes suivants seront testées :
Les interfaces externes des unités suivantes seront testées :
Les mesures de performance les plus critiques à tester sont :
Les références applicables sont :
La liste ci-dessous identifie les éléments (cas d'utilisation, exigences fonctionnelles, exigences non fonctionnelles) ayant été définis comme cibles pour le test. Cette liste représente ce qui sera testé.
(Remarque : il est possible que la prochaine édition du plan de test utilise Rational RequisitePro pour lier directement vers les exigences dans les documents de cas d'utilisation et dans la spécification supplémentaire.)
2.1 Test d'intégrité des données et de la base de données
Vérifier l'accès à la base de données du catalogue des cours.
Vérifier les accès en lecture d'enregistrement simultané.
Vérifier le verrouillage lors des mises à jour du catalogue des cours.
Vérifier la récupération correcte de la mise à jour des données de la base de données.
2.2. Test de fonction
Document vision, section 12.2 : "le système s'interface avec le système de base de données du catalogue des cours existant. Le système d'inscription aux cours prend en charge le format de données défini dans [2]."
Document vision, section 12.2 : "le système s'interface avec le système de facturation existant et prend en charge le format de données défini dans [1]."
Document vision, section 12.2 : "le composant serveur du système fonctionne sur le serveur du campus et sous le système d'exploitation UNIX."
Spécification supplémentaire, section 9.3 : "le composant serveur du système fonctionne sur le serveur UNIX du Wylie College."
Document vision, section 12.2 : "le composant client du système fonctionne sur n'importe quel ordinateur personnel équipé d'un microprocesseur 486 ou supérieur."
Spécification supplémentaire, section 9.3 : "le composant client du système fonctionne sur n'importe quel ordinateur personnel équipé au minimum d'un microprocesseur 486."
Spécification supplémentaire, section 9.1 : "le système s'intègre au système en vigueur existant (base de données du catalogue des cours) qui fonctionne sur le College DEC VAX Main Frame."
Spécification supplémentaire, section 9.2 : "le système s'intègre au système de facturation des cours existant qui fonctionne sur le College DEC VAX Main Frame."
2.3 Test du cycle métier
Aucun.
2.4 Test de l'interface utilisateur
Vérifier la facilité de navigation à l'aide d'un ensemble d'exemples d'écrans.
Vérifier la conformité des exemples d'écrans avec les normes de l'interface graphique.
Document vision, section 10 : "le système doit être simple à utiliser et approprié au marché cible constitué par les participants et les professeurs connaissant l'informatique."
Document vision, section 12.1 : "l'interface utilisateur du bureau doit être compatible avec Windows 95/98."
Spécification supplémentaire, section 5.1 : "l'interface utilisateur du bureau doit être compatible avec Windows 95/98."
Spécification supplémentaire, section 5.2 : "l'interface utilisateur du système d'inscription aux cours se caractérise par sa facilité d'utilisation et ne nécessite aucun apprentissage particulier pour les utilisateurs connaissant l'informatique."
2.5 Test de performance
Vérifier le temps de réponse pour accéder au système de financement externe.
Vérifier le temps de réponse pour accéder au sous-système du catalogue des cours externe.
Vérifier le temps de réponse pour une connexion à distance.
Vérifier le temps de réponse pour une soumission à distance d'une inscription à un cours.
Document vision, section 12.3 : "le système fournit un accès à la base de données du catalogue des cours existant avec un temps d'attente ne dépassant pas 10 secondes."
Spécification supplémentaire, section 7.2 : "le système fournit un accès à la base de données du catalogue des cours existant avec un temps d'attente ne dépassant pas 10 secondes."
2.6 Test de charge
Vérifier le temps de réponse système lorsque 200 participants sont connectés.
Vérifier le temps de réponse système lorsque 50 participants accèdent simultanément au catalogue des cours.
2.7 Test sous contraintes
Aucun.
2.8 Test de volume
Aucun.
2.9 Test de sécurité et de contrôle d'accès
Vérifier la connexion à partir d'un PC local.
Vérifier la connexion à partir d'un PC distant.
Vérifier la sécurité de connexion à l'aide d'un nom d'utilisateur et d'un mot de passe.
2.10 Test de reprise en ligne / reprise sur incident
Aucun.
2.11 Test de configuration
Document vision, section 12.2 : "le composant client du système doit fonctionner sous Windows 95, Windows 98 et Microsoft Windows NT."
Spécification supplémentaire, section 9.4 : "l'interface basée sur le Web du système d'inscription aux cours doit fonctionner avec les navigateurs Netscape 4.04 et Internet Explorer 4.0.
Spécification supplémentaire, section 9.5 : "l'interface basée sur le Web doit être compatible avec l'environnement d'exécution Java 1.1 VM.
2.12 Test d'installation
Aucun.
La stratégie de test présente l'approche recommandée en ce qui concerne le test des applications logicielles. La section précédente relative aux exigences du test a présenté une description de ce qui sera testé ; cette section décrit comment le test sera effectué.
Les considérations majeures relatives à la stratégie de test sont les techniques à utiliser et le critère de détermination de l'achèvement du test.
Outre les considérations évoquées pour chaque test ci-dessous, le test ne doit être effectué qu'avec des bases de données connues et contrôlées dans des environnements sécurisés.
La stratégie de test suivante est de nature générique et destinée à une application en fonction des exigences répertoriées à la section 4 de ce document.
3.1 Types de test3.1.1 Test d'intégrité des données et de la base de données
Les bases de données et les processus de base de données doivent être testés en tant que systèmes séparés. Ces systèmes doivent être testés sans les applications (en tant qu'interface vers les données). Une recherche complémentaire dans le système de gestion de la base de données doit être effectuée afin d'identifier les outils / techniques susceptibles d'exister pour la prise en charge du test identifié ci-dessous.
Objectif du test : | S'assurer que les processus et méthodes d'accès à la base de données fonctionnent correctement et sans corruption de données. |
Technique : |
|
Critères d'achèvement : | Tous les processus et méthodes d'accès à la base de données fonctionnent comme prévu et sans corruption de données. |
Considérations spéciales : |
|
3.1.2 Test de fonctionLe test de l'application doit se centrer sur les exigences cibles dont on peut directement effectuer le suivi pour utiliser les cas (ou les fonctions métier) et les règles métier. Le but de ces tests est de vérifier l'acceptation, le traitement et la récupération corrects des données ainsi que la mise en oeuvre appropriée des règles métier. Ce type de test est basé sur des techniques fonctionnelles, c'est-à-dire sur la vérification de l'application (et de ses processus internes) en agissant sur l'application via l'interface graphique et en analysant la sortie (résultats). Vous trouverez ci-dessous le type de test recommandé pour chaque application :
Objectif du test : | S'assurer que la navigation dans l'application est appropriée et que la récupération, le traitement et l'entrée de données sont corrects. |
Technique : |
|
Critères d'achèvement : |
|
Considérations spéciales : |
|
3.1.3 Test du cycle métier
3.1.4 Test de l'interface utilisateurCette section ne s'applique pas au test du prototype architectural.
Le test de l'interface utilisateur vérifie l'interaction de l'utilisateur avec le logiciel. L'objectif du test de l'interface utilisateur est de s'assurer qu'elle permet à l'utilisateur d'accéder aux différentes fonctions des applications et de naviguer de manière appropriée au sein de ces fonctions. En outre, le test de l'interface utilisateur doit permettre de s'assurer que les objets au sein de la fonction de l'interface utilisateur fonctionnent comme prévu et sont conformes aux normes industrielles et d'entreprise.
Objectif du test : | Vérifier les éléments suivants :
|
Technique : |
|
Critères d'achèvement : | Vérification réussie de la cohérence de chaque fenêtre avec la version du test de performance ou dans le cadre de normes acceptables |
Considérations spéciales : |
|
3.1.5 Profil de performance
Le test de performance mesure les temps de réponse, les taux de transaction et d'autres exigences sensibles au temps. L'objectif du test de performance est de vérifier et de valider les exigences de performance ayant été accomplies. Le test de performance est généralement exécuté plusieurs fois et chaque fois avec une "charge d'arrière-plan" différente sur le système. Le test initial doit être effectué avec une charge "nominale", similaire à la charge normale réelle (ou escomptée) sur le système cible. Un second test de performance est exécuté avec une charge maximale.
En outre, les tests de performance peuvent être utilisés pour profiler et mettre au point les performances du système en fonction de conditions telles que la charge de travail ou les configurations matérielles.
REMARQUE : les transactions ci-dessous se réfèrent aux "transactions métier logiques". Ces transactions sont définies comme des fonctions spécifiques qu'un utilisateur du système est amené à effectuer en utilisant l'application, comme ajouter ou modifier un contrat donné.
Objectif du test : | Valider le temps de réponse système pour les transactions désignées ou les fonctions métier en respectant les deux conditions suivantes :
- volume normal escompté - volume escompté dans le pire des cas |
Technique : |
|
Critères d'achèvement : |
|
Considérations spéciales : |
|
3.1.6 Test de chargeLes mesures de test de charge soumettent le système sous test à différentes charges de travail afin d'évaluer la capacité du système à continuer de fonctionner correctement avec ces différentes charges de travail. L'objectif du test de charge est de déterminer et de s'assurer que le système fonctionne correctement au delà de la charge de travail maximale prévue. En outre, le test de charge évalue les caractéristiques de performance (temps de réponse, taux de transaction et d'autres éléments sensibles au temps).
REMARQUE : les transactions ci-dessous se réfèrent aux "transactions métier logiques". Ces transactions sont définies comme des fonctions spécifiques qu'un utilisateur du système est amené à effectuer en utilisant l'application, comme ajouter ou modifier un contrat donné.
Objectif du test : | Vérifier le temps de réponse système pour les transactions désignées ou les cas métier dans le cadre de différentes conditions de charge de travail. |
Technique : |
|
Critères d'achèvement : |
|
Considérations spéciales : |
|
3.1.7 Test sous contraintes
3.1.8 Test de volumeCette section ne s'applique pas au test du prototype architectural.
3.1.9 Test de contrôle d'accès et de sécuritéCette section ne s'applique pas au test du prototype architectural.
Le test de contrôle d'accès et de sécurité se concentre sur deux points clés en matière de sécurité :
La sécurité de l'application, comprenant l'accès aux données et aux fonctions métier.
La sécurité du système comprenant l'accès distant au système.En fonction du niveau de sécurité désiré, la sécurité de l'application s'assure que les utilisateurs disposent d'un accès restreint à certaines fonctions spécifiques ou d'un accès limité à des données qui leur sont disponibles. Par exemple, chacun peut être autorisé à entrer des données et créer de nouveaux comptes, mais seuls les responsables sont habilités à les supprimer. S'il existe une sécurité au niveau des données, le test s'assure que le premier "type" d'utilisateur puisse voir toutes les informations client, y compris les données financières, et que, en revanche, le deuxième type d'utilisateur ne puisse voir que les données statistiques relatives au même client.
La sécurité système s'assure que seuls les utilisateurs disposant d'un droit d'accès au système puissent être en mesure d'accéder aux applications et seulement par l'intermédiaire de passerelles appropriées.
Objectif du test : | Sécurité fonctions / données : vérifier que l'utilisateur ne peut accéder qu'aux fonctions / données auxquelles son type d'utilisateur lui donne le droit d'accéder.
Sécurité système : vérifier que seuls les utilisateurs ayant accès au système et aux applications sont autorisés à y accéder. |
Technique : |
|
Critères d'achèvement : | Pour chaque type d'utilisateur connu, les fonctions / données sont disponibles et toutes les transactions fonctionnent comme prévu et exécutent en priorité les tests de fonction d'application |
Considérations spéciales : |
|
3.1.10 Test de reprise en ligne et reprise sur incident
3.1.11 Test de configurationCette section ne s'applique pas au test du prototype architectural.
Le test de configuration vérifie le fonctionnement du logiciel en fonction de différentes configurations logicielles et matérielles. Dans la plupart des environnements de production, les spécifications matérielles particulières relatives aux stations de travail client, aux connexions réseau et aux serveurs de base de données peuvent varier. Les stations de travail client peuvent disposer de différents logiciels chargés comme des applications, des pilotes, etc. A tout moment, de nombreuses combinaisons différentes peuvent être actives et utiliser différentes ressources.
Objectif du test : | Valider et vérifier le bon fonctionnement des applications client sur les stations de travail client prescrites. |
Technique : |
|
Critères d'achèvement : | Pour chaque combinaison du prototype et de l'application PC, les transactions se terminent correctement sans échecs. |
Considérations spéciales : |
|
3.1.12 Test d'installation3.2 OutilsCette section ne s'applique pas au test du prototype architectural du système d'inscription aux cours.
Les outils suivants seront utilisés pour le test du prototype architectural :
Outil | Version | |
---|---|---|
Gestion de test | Rational RequisitePro
Rational Unified Process |
A venir |
Conception de test | Rational Rose | A venir |
Détection des défauts | Rational ClearQuest | A venir |
Test fonctionnel | Rational Robot | A venir |
Tests de performance | Rational Visual Quantify | A venir |
Profileur ou moniteur de couverture de test | Rational Visual PureCoverage | A venir |
Autres outils de test | Rational Purify
Rational TestFactory |
A venir |
Gestion de projet | Microsoft Project
Microsoft Word Microsoft Excel |
A venir |
Outils SGBD | A venir | A venir |
4. Ressources
Cette section présente les ressources recommandées pour le test du prototype architectural du système d'inscription aux cours, leurs responsabilités principales ainsi que l'ensemble de leurs connaissances ou compétences.
4.1 RôlesCe tableau illustre les affectations de personnel pour le test du prototype.
Ressources humaines
Rôle | Ressources minimales recommandées
(nombre de personnes à temps plein) |
Responsabilités/commentaires spécifiques |
---|---|---|
Responsable des tests | 1 - Kerry Stone | Supervise la gestion
Responsabilités :
|
Concepteur de test | Margaret Cox
Carol Smith |
Identifie, priorise et implémente les jeux d'essai
Responsabilités :
|
Testeur système | Carol Smith | Exécute les tests
Responsabilités :
|
Administrateur du système de test | Simon Jones | S'assure que les actifs et l'environnement de test sont gérés et conservés.
Responsabilités :
|
Administration de la base de données / responsable de la base de données | Margaret Cox | S'assure que les actifs et l'environnement des données de test (base de données) sont gérés et conservés.
Responsabilités :
|
Concepteur | Margaret Cox | Identifie et définit les opérations, attributs et associations des classes de test
Responsabilités :
|
Implémenteur | Margaret Cox | Implémente et teste de manière unitaire les classes de test et packages de test
Responsabilités :
|
4.2 Système
Le tableau suivant présente les ressources système pour le test du prototype du système d'inscription aux cours.
Ressources système
Ressource | Nom / type / n° de série |
---|---|
Serveur du Wylie College | N° de série : X179773562b |
Base de données du catalogue des cours | ID de version : CCDB-080885 |
Système de facturation | ID de version : BSSS-88335 |
PC de test client |
|
3 PC distants (avec accès Internet) | N° de série : A8339223
N° de série : B9334022 N° de série : B9332544 |
3 PC locaux (connectés via LAN) | N° de série : R3322411 (appartient au Responsable des inscriptions)
N° de série : A8832234 (IT Lab) N° de série : W4592233 (IT Lab) |
Référentiel du test |
|
Serveur du Wylie College | N° de série : X179773562b |
PC de développement de test - 6 | N° de série : A8888222
N° de série : R3322435 N° de série : I88323423 N° de série : B0980988 N° de série : R3333223 N° de série : Y7289732 |
Le test du prototype architectural du système d'inscription aux cours intègre les tâches de test pour chacun des efforts de test identifiés dans les sections précédentes. Des jalons de projet distincts sont identifiés afin de communiquer l'état du projet et ses réalisations.
Référez-vous au Plan de développement logiciel [13] et au Plan d'itération E1 [14] pour consulter le planning maître du projet ou le planning général des phases.
Tâche jalon | Effort (jours) | Date de début | Date de fin |
---|---|---|---|
Planification du test du prototype | 2 | 12 mars | 15 mars |
Conception du test du prototype | 3 | 15 mars | 18 mars |
Développement du test du prototype | 4 | 19 mars | 23 mars |
Exécution du test du prototype | 3 | 24 mars | 26 mars |
Evaluation du test du prototype | 1 | 29 mars | 29 mars |
Les produits des tâches de test définies dans ce plan de test sont décrits dans le tableau ci-dessous.
Produits | Propriétaire | Revue/Distribution | Date limite |
Plan de test | K. Stone | Equipe de gestion de projet sénior | 15 mars |
Environnement de test | S. Jones | - | 18 mars |
Suite de tests | C. Smith et M. Cox | Revue interne par un pair | 23 mars |
Jeux d'essai | M. Cox | Revue interne par un pair | 23 mars |
Scripts de test | M. Cox | - | 23 mars |
Modules de remplacement de test, pilotes | M. Cox | - | 23 mars |
Rapports d'anomalie de test | C. Smith | Equipe de gestion de projet sénior | 26 mars |
Résultats des tests | C. Smith | - | 26 mars |
Rapport d'évaluation de test | C. Smith | Equipe de gestion de projet sénior | 29 mars |
6.1 Suite de testsLa suite de tests doit définir l'ensemble des jeux d'essai et scripts de test associés à chaque cas d'utilisation.
6.2 Journaux de testsIl est prévu d'utiliser RequisitePro pour identifier les cas d'utilisation et effectuer le suivi de l'état de chaque jeu d'essai. Les résultats de test seront résumés dans RequisitePro, sous la forme "non testé", "validé", "validé sous conditions" ou "non validé". Pour résumer, RequisitePro sera configuré pour prendre en charge les attributs suivants pour chaque jeu d'essai, comme indiqué dans les instructions relatives aux attributs d'exigences [17] :
- Statut du test
- Numéro de construction
- Testé par
- Testé le
- Notes de test
7. Tâches du projetIl incombe au testeur de système de mettre à jour le statut du test dans RequisitePro.
Les résultats du test sont conservés dans Contrôle de la configuration.
6.3 Rapports d'incidentsRational ClearQuest doit être utilisé pour la journalisation et le suivi des différents incidents.
Voici les tâches ayant trait au test pour le test du prototype d'architecture d'inscription aux cours :
Planifier le test |
|
|
|
|
|
|
Concevoir le test |
|
|
|
|
|
Implémenter le test |
|
|
|
|
|
Exécuter le test |
|
|
|
|
|
|
Evaluer le test |
|
|
|
Déterminer si les critères d'exécution et de réussite du test ont été respectés |
Créer un rapport d'évaluation de test |
Copyright (c) IBM Corp. 1987, 2004. All rights reserved. |
Exemple Web de projet d'inscription aux cours |