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

  1. Objectifs
  2. Exigences du test
  3. Stratégie de test
  4. Ressources
  5. Dates limite du projet
  6. Produits
  7. Tâches du projet

 

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 :

1.2 Portée

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 :

    1. Inscription à un cours
    2. Système de financement
    3. Catalogue des cours

Les interfaces externes des unités suivantes seront testées :

    1. PC locaux
    2. PC distants.

Les mesures de performance les plus critiques à tester sont :

    1. Temps de réponse de connexion à distance vers le système d'inscription aux cours.
    2. Temps de réponse d'accès au système de financement.
    3. Temps de réponse d'accès au sous-système du catalogue des cours.
    4. Temps de réponse participant lorsque 200 participants sont connectés au système.
    5. Temps de réponse participant lorsque 50 participants accèdent simultanément à la base de données du catalogue des cours.
1.3 Références

Les références applicables sont :

    1. Course Billing Interface Specification, WC93332, 1985, Wylie College Press.
    2. Course Catalog Database Specification, WC93422, 1985, Wylie College Press.
    3. Course Registration System Vision Document, WyIT387, V1.0, 1998, Wylie College IT.
    4. Course Registration System Glossary, WyIT406, V2.0, 1999, Wylie College IT.
    5. Course Registration System Use Case Spec - Close Registration, WyIT403, V2.0, 1999, Wylie College IT.
    6. Course Registration System Use Case Spec - Login, WyIT401, V2.0, 1999, Wylie College IT.
    7. Course Registration System Use Case Spec - Maintain Professor Info, WyIT407, Version 2.0, 1999, Wylie College IT.
    8. Course Registration System Use Case Spec - Register for Courses, WyIT402, Version 2.0, 1999, Wylie College IT.
    9. Course Registration System Use Case Spec - Select Courses to Teach, WyIT405, Version 2.0, 1999, Wylie College IT.
    10. Course Registration System Use Case Spec - Maintain Student Info, WyIT408, Version 2.0, 1999, Wylie College IT.
    11. Course Registration System Use Case Spec - Submit Grades, WyIT409, Version 2.0, 1999, Wylie College IT.
    12. Course Registration System Use Case Spec - View Report Card, WyIT410, Version 2.0, 1999, Wylie College IT.
    13. Course Registration System Software Development Plan, WyIT418, V1.0, 1999, Wylie College IT.
    14. Course Registration System Iteration Plan, Elaboration Iteration #E1, WyIT420, V1.0, 1999, Wylie College IT.
    15. Course Registration System Software Architecture Document, WyIT431, V1.0, 1999, Wylie College IT.
    16. Course Registration System Integration Build Plan for the Architectural Prototype, WyIT430, V1.0, 1999, Wylie College IT.
    17. Course Registration System Requirements Attributes Guidelines, WyIT404, V1.0, 1999, Wylie College IT.
2.    Exigences du test 

    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.

3.    Stratégie de test

    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 test

3.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 :
  • Appelez chaque processus et méthode d'accès à la base de données, en affectant à chacun des données valides et non valides (ou des demandes de données).
  • Inspectez la base de données afin de vous assurer que les données ont été affectées comme prévu, que tous les événements de base de données se sont déroulés correctement ou examinez les données renvoyées pour vous assurer que les données correctes ont été récupérées (pour les bonnes raisons)
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 :
  • Il est possible que le test nécessite un environnement de développement SGBD ou des pilotes pour entrer et modifier directement des données dans les bases de données.
  • Les processus doivent être appelés manuellement.
  • Les petites bases de données ou les bases de données réduites à une taille minimale (nombre limité d'enregistrements) devraient être utilisées pour accroître la visibilité d'événements non acceptables.

 

 

3.1.2 Test de fonction

Le 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 :
  • Exécutez chaque cas d'utilisation, flux de cas d'utilisation ou fonction en utilisant des données valides et non valides afin de vérifier les points suivants :
  • Les résultats attendus se produisent lorsque des données valides sont utilisées.
  • Les messages d'avertissement / erreur appropriés sont affichés lorsque des données non valides sont utilisées.
  • Chaque règle métier est correctement appliquée.
Critères d'achèvement :
  • Tous les tests prévus ont été exécutés.
  • Toutes les anomalies identifiées ont été traitées.
Considérations spéciales :
  • L'accès au serveur UNIX du Wylie College, au système du catalogue des cours existant et au système de facturation est nécessaire pour exécuter certains tests système identifiés sur le prototype.
 

3.1.3 Test du cycle métier

Cette section ne s'applique pas au test du prototype architectural.

3.1.4 Test de l'interface utilisateur

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 :
  • La navigation au sein de l'application reflète les exigences et fonctions métier de manière appropriée, y compris la correspondance des fenêtres et des zones ainsi que l'utilisation des méthodes d'accès (touches de tabulation, mouvements de la souris et touches de raccourci)
  • Les objets et caractéristiques de la fenêtre, tels que les menus, la taille, la position, l'état et la mise en évidence sont conformes aux normes.
Technique :
  • Créez / modifiez des tests pour chaque fenêtre afin de vérifier la navigation et les états d'objet pour chaque objet et fenêtre d'application.
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 :
  • Il n'est pas possible d'accéder à toutes les propriétés des objets tiers ou personnalisés.
 

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 :
  • Utilisez des scripts de test développés pour le test du modèle métier (test système).
  • Modifiez les fichiers données (pour accroître le nombre de transactions) ou modifiez les scripts pour augmenter le nombre d'itérations pour chaque transaction.
  • Les scripts doivent être exécutés sur une machine (évaluer les performances d'un utilisateur unique, transaction unique) et répétés sur plusieurs clients (virtuels ou réels, voir les considérations spéciales ci-dessous).
Critères d'achèvement :
  • Transaction unique / utilisateur unique : achèvement réussi des scripts de test sans échecs et dans le cadre du temps attendu / requis (par transaction)
  • Transactions multiples / utilisateurs multiples : achèvement réussi des scripts de test sans échecs et dans un cadre temporel acceptable.
Considérations spéciales :
  • Un test de performance complet implique l'existence d'une charge "d'arrière-plan" sur le serveur. Plusieurs méthodes peuvent être utilisées :
    • "Pilotez les transactions" directement vers le serveur, généralement sous la forme d'appels SQL.
    • Créez une charge utilisateur "virtuelle" afin de simuler de nombreux clients (généralement plusieurs centaines). Des outils d'émulation d'un terminal distant sont utilisés pour créer cette charge. Cette technique peut également être utilisée pour charger le réseau avec du "trafic".
    • Utilisez plusieurs clients physiques, chacun exécutant des scripts de test pour placer une charge sur le système.
  • Le test de performance doit être effectué sur une machine dédiée ou à un moment dédié. Cela permet un contrôle complet et des mesures précises.
  • Les bases de données utilisées pour le test de performance doivent être de taille réelle ou dimensionnées de manière égale.

 

3.1.6 Test de charge

Les 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 :
  • Utilisez les tests développés pour le test du cycle métier.
  • Modifiez les fichiers données (pour accroître le nombre de transactions) ou modifiez les tests pour augmenter le nombre d'occurrences de chaque transaction.
Critères d'achèvement :
  • Transactions multiples / utilisateurs multiples : achèvement réussi des tests sans échecs et dans un cadre temporel acceptable.
Considérations spéciales :
  • Le test de charge doit être effectué sur une machine dédiée ou à un moment dédié. Cela permet un contrôle complet et des mesures précises.
  • Les bases de données utilisées pour le test de charge doivent être de taille réelle ou dimensionnées de manière égale.
 

3.1.7 Test sous contraintes

Cette section ne s'applique pas au test du prototype architectural.

3.1.8 Test de volume

Cette section ne s'applique pas au test du prototype architectural.

3.1.9 Test de contrôle d'accès et de sécurité

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 :
  • Sécurité fonctions / données : identifiez et recensez chaque type d'utilisateur et les fonctions / données auxquelles chaque type d'utilisateur est autorisé à accéder.
  • Créez des tests pour chaque type d'utilisateur et vérifiez les droits d'accès en créant des transactions spécifiques à chaque type d'utilisateur.
  • Modifiez le type d'utilisateur et relancez les tests pour les mêmes utilisateurs. Dans chaque cas, vérifiez que l'accès aux fonctions / données supplémentaires est correctement accordé ou refusé.
  • Accès système (voir les considérations spéciales ci-dessous)
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 :
  • L'accès au système doit être examiné / traité avec l'administrateur système ou réseau. Il est possible que ce test ne soit pas nécessaire dans la mesure où il peut s'agir d'une fonction de l'administration système ou réseau.
 

3.1.10 Test de reprise en ligne et reprise sur incident

Cette section ne s'applique pas au test du prototype architectural.

3.1.11 Test de configuration

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 :
  • Utilisez des scripts de test système et d'intégration
  • Ouvrez / fermez les différentes applications PC, dans le cadre du test ou avant le démarrage du test.
  • Exécutez les transactions sélectionnées pour simuler les activités utilisateur à l'intérieur et à l'extérieur des différentes applications PC.
  • Répétez le processus ci-dessus, en minimisant la mémoire conventionnelle disponible sur le client.
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 :
  • Quelles sont les applications PC disponibles, accessibles sur les clients ?
  • Quelles sont les applications généralement utilisées ?
  • Quelles sont les données exécutées par les applications (par un exemple un tableur ouvert dans Excel, un document de 100 pages dans Word).
  • L'ensemble des systèmes, serveurs réseau et bases de données, etc., doit également être documenté dans le cadre de ce test.

 

3.1.12 Test d'installation

Cette section ne s'applique pas au test du prototype architectural du système d'inscription aux cours.

3.2 Outils

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ôles

Ce 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 :

  • Fournir une direction technique
  • Acquérir des ressources appropriées
  • Etablir des rapports de gestion
Concepteur de test Margaret Cox

Carol Smith

Identifie, priorise et implémente les jeux d'essai

Responsabilités :

  • Générer le plan de test
  • Générer la suite de tests
  • Evaluer l'efficacité de l'effort de test
Testeur système Carol Smith Exécute les tests

Responsabilités :

  • Exécuter les tests
  • Enregistrer les résultats
  • Effectuer une reprise après des erreurs
  • Documenter les incidents
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 :

  • Administrer le système de gestion de test
  • Installer / gérer l'accès des personnes aux systèmes de test
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 :

  • Administrer les données de test (base de données)
Concepteur Margaret Cox Identifie et définit les opérations, attributs et associations des classes de test

Responsabilités :

  • Identifier et définir la (les) classe(s) de test
  • Identifier et définir les packages de test
Implémenteur Margaret Cox Implémente et teste de manière unitaire les classes de test et packages de test

Responsabilités :

  • Créer les packages et classes de test implémentés dans la suite de tests.
 

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

 

 

 5.    Dates limite du projet

    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

     

6.   Produits

    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 tests

La 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 tests

Il 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] :

Il 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'incidents

Rational ClearQuest doit être utilisé pour la journalisation et le suivi des différents incidents.

7.    Tâches du projet

Voici les tâches ayant trait au test pour le test du prototype d'architecture d'inscription aux cours :

Planifier le test

Identifier les exigences du test

Evaluer les risques

Développer la stratégie de test

Identifier les ressources du test

Créer un planning

Générer un plan de test

Concevoir le test

Analyser la charge de travail (non applicable au prototype)

Développer la suite de tests

Identifier et décrire les jeux d'essai

Identifier et structurer les scripts de test

Réviser et accéder à la couverture de test

Implémenter le test

Configurer l'environnement de test

Enregistrer ou programmer les scripts de test

Développer des modules de remplacement de test et des pilotes

Identifier des fonctionnalités spécifiques au test dans la conception et le modèle d'implémentation

Etablir les ensembles de données externes

Exécuter le test

Exécuter le script du test

Evaluer l'exécution du test

Effectuer une reprise après l'arrêt du test

Vérifier les résultats

Analyser les résultats imprévus

Enregistrer les incidents

Evaluer le test

Evaluer la couverture du jeu d'essai

Evaluer la couverture de code

Analyser les incidents

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
Version 2001.03