Système d'inscription aux cours

Plan de test

 

Version 1.0

Historique des révisions

Date

Version

Description

Auteur

27/mars/1999 1.0 Plan de test pour l'édition 1 et 2 K. Stone
 
 
 
 
 
 
 
 
 
 
 
 

 

 

Sommaire

  1. Objectifs
  2. Portée
  3. Références
  4. Exigences de test
  5. Stratégie de test
    1. Types de test
      1. Test d'intégrité des données et de la base de données
      2. Test système
      3. Test du cycle métier
      4. Test de l'interface utilisateur
      5. Test de performance
      6. Test de charge
      7. Test sous contraintes
      8. Test de volume
      9. Test de sécurité et de contrôle d'accès
      10. Test de reprise en ligne / reprise sur incident
      11. Test de configuration
      12. Test d'installation
    2. Outils
  6. Ressources
    1. Agents
    2. Système
  7. Jalons du projet
  8. Produits
    1. Ensemble de tests
    2. Journaux de tests
    3. Rapports d'anomalie
  9. Tâches projet

Plan de test

 

1. Objectifs

Ce document décrit le plan de test du système d'inscription aux cours. Ce document relatif au plan de test a les objectifs suivants :

    • Identifier les informations relatives au projet existant et les composants logiciels devant être testés.
    • Recenser les exigences de test recommandées (haut niveau).
    • Recommander et décrire les stratégies de test à employer.
    • Identifier les ressources requises et fournir une évaluation des efforts de test.
    • Recenser les éléments relatifs au produit des tâches de test.

2. Portée

    Ce plan de test s'applique aux tests d'intégration et aux tests système qui seront effectués sur le système d'inscription aux cours éditions 1 et 2. Il est à noter qu'il existe un plan de test distinct [17] qui décrit la stratégie de test pour le prototype architectural.

    Il est considéré comme acquis que le test d'unité a déjà assuré un test fonctionnel approfondi par une couverture étendue du code source et un test poussé de toutes les interfaces des modules.

    Ce plan de test s'applique au test de toutes les exigences du système d'inscription aux cours définies dans le document Vision [3], les spécifications de cas d'utilisation [5-12] et les spécifications supplémentaires [13].

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 Supplementary Specification, WyIT400, V1.0, 1999, Wylie College IT.
    14. Course Registration System Software Development Plan, WyIT418, V2.0, 1999, Wylie College IT.
    15. Course Registration System Software Architecture Document, WyIT431, V1.0, 1999, Wylie College IT.
    16. Course Registration System Requirements Attributes Guidelines, WyIT404, V1.0, 1999, Wylie College IT.
    17. Course Registration System Test Plan for the Architectural Prototype, WyIT432, V1.0, 1999, Wylie College IT.

4. Exigences de 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é. Les détails concernant chaque test seront définis ultérieurement lorsque les jeux d'essai seront identifiés et les scripts de test développés.

    (Remarque : il est possible que la prochaine édition du plan de test utilise Rational RequisitePro pour lier directement vers les exigences dans le document de vision, dans les documents de cas d'utilisation et dans la spécification supplémentaire.)

    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.

    Test système (test fonctionnel)

    Vérifier le cas d'utilisation Ouverture de session [6]

    Vérifier le cas d'utilisation Fermer inscription [5]

    Vérifier le cas d'utilisation Gérer les informations relatives aux participants [10]

    Vérifier le cas d'utilisation Gérer les informations relatives aux professeurs [7]

    Vérifier le cas d'utilisation Transmettre les notes [11]

    Vérifier le cas d'utilisation Visualiser les relevés de notes [12]

    Vérifier le cas d'utilisation Inscription aux cours [8]

    Vérifier le cas d'utilisation Sélectionner les cours à enseigner [9]

    Spécification supplémentaire, section 4.1 : "toutes les erreurs système sont enregistrées. Les erreurs fatales du système engendreront un arrêt méthodique du système."

    Spécification supplémentaire, section 4.1 : "les messages d'erreur système comprennent une description sous forme de texte de l'erreur, le code d'erreur du système d'exploitation (le cas échéant), le module détectant le cas d'erreur et un horodatage. Toutes les erreurs système sont conservées dans la base de données du journal des erreurs."

    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é au minimum d'un microprocesseur 486."

    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 MainFrame."

    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 MainFrame."

    Test du cycle métier

Vérifier le fonctionnement après le téléchargement d'un nouveau catalogue des cours.

Vérifier le fonctionnement sur plusieurs semestres et plusieurs années.

Vérifier le fonctionnement lorsque le semestre est à cheval sur deux années calendaires.

    Test d'interface utilisateur

    Vérifier le confort de navigation dans un échantillon d'écrans.

    Vérifier que les exemples d'écrans sont conformes aux standards d'interface graphique.

    Document Vision, section 10 : "Le système doit être facile à utiliser et être adapté au marché cible des étudiants et professeurs maîtrisant 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."

    Spécification supplémentaire, section 5.3 : "Chaque fonction du système d'inscription aux cours doit être doté d'une aide en ligne intégrée destinée à l'utilisateur. Cette Aide en ligne doit contenir des instructions pas à pas portant sur l'utilisation du système, ainsi que la définition des termes et acronymes."

    Tests de performance

    Vérifier le temps de réponse pour l'accès au système de financement externe.

    Vérifier le temps de réponse pour l'accès au sous-système de catalogue des cours externe.

    Vérifier le temps de réponse pour les connexions à distance.

    Vérifier le temps de réponse pour la transmission distante d'une inscription à un cours.

    Document Vision, section 12.3 : "Le système doit fournir l'accès à la base de données Catalogue des cours existante avec une latence de 10 secondes ou moins."

    Spécification supplémentaire, section 7.2 : "Le système doit fournir l'accès à la base de données Catalogue des cours existante avec une latence de 10 secondes ou moins."

    Test de chargement

    Vérifier le temps de réponse système lorsque 200 participants connectés.

    Vérifier le temps de réponse système lorsque 50 participants accèdent simultanément au catalogue des cours.

    Spécification supplémentaire, section 7.1 : "Le système doit, à tout moment, prendre en charge 2 000 utilisateurs simultanés sur la base de données et jusqu'à 500 utilisateurs simultanés sur les serveurs locaux."

    Test de charge

    Vérifier le temps de réponse système lors des créneaux horaires où le serveur UNIX est le plus sollicité.

    Vérifier le temps de réponse système lorsque le nombre de participants connectés est à son maximum.

    Test de volume

    V2rifier le temps de réponse système lorsque la base de données Catalogue des cours atteint 90 % de sa capacité.

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

    Vérifier la connexion depuis un PC local.

    Vérifier la connexion depuis un PC distant.

    Vérifier la sécurité à la connexion via les dispositifs de nom et de mot de passe.

    Spécification supplémentaire, section 4.2 : "Toutes les fonctionnalités doivent être disponibles à distance par l'intermédiaire d'une connexion Internet."

    Test de reprise en ligne/reprise sur incident

    Spécification supplémentaire, section 6.1 : "Le système d'inscription aux cours est disponible 24/24h et 7/7j. Les temps d'arrêt ne dépasseront pas 4 %."

    Spécification supplémentaire, section 6.2 : "La moyenne des temps de bon fonctionnement doit dépasser 300 heures."

    Test de configuration

    Document Vision, section 12.2 : "Le composant client du système doit s'exécuter 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 Web doit être compatible avec l'environnement d'exécution Java 1.1 VM.

    Test d'installation

    Spécification supplémentaire, section 8.1 : "Les mises à niveau vers la partie client PC du système d'inscription aux cours sont téléchargeables à partir du serveur UNIX via Internet."

    Vérifier l'installation de la partie serveur.

    Vérifier l'installation de la partie client.

5. Stratégie de test

    La stratégie de test propose l'approche recommandée pour 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 principales préoccupations concernant la stratégie de test sont les techniques à utiliser et le critère qui permet de savoir quand le test est terminé.

    Outre les préoccupations fournies pour chaque test ci-dessous, le test ne doit être exécuté qu'à l'aide de base de données connues, contrôlées et fonctionnant sous des environnements sécurisés.

    La stratégie de test suivante est du type générique et doit s'appliquer aux exigences énumérées dans la section 4 de ce document.

    1. Types de tests

1. Test d'intégrité des données et de la base de données

Les bases de données et processus de base de données doivent être testés comme des systèmes distincts. 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 : Vérifier que les processus et méthodes d'accès à la base de données fonctionnent correctement et sans corruption des données.
Technique :
  • Appeler chaque processus et méthode d'accès à la base de données, en truffant chacun(e) de données valides et non valides (ou de demandes de données).
  • Inspecter la base de données afin de vérifier que les données ont bien été transmises comme prévu, que tous les événements de base de données se sont produits correctement, ou révisez les données renvoyées pour vous assurer que les bonnes données ont été récupérées (pour les bonnes raisons)
Critère d'exécution : Tous les processus et toutes les méthodes d'accès à la base de données fonctionnent comme souhaité et sans corruption des données.
Considérations spéciales :
  • Le test peut nécessiter un environnement de développement de système de gestion de base de données ou des pilotes pour saisir ou modifier les données directement dans les bases de données.
  • Les processus doivent être appelés manuellement.
  • Les bases de données petites ou de taille réduite (nombre d'entrées limitées) doivent être utilisées pour augmenter la visibilité de tout événement non acceptable.

2. Test système

Le test de l'application doit se concentrer sur toute exigence cible pouvant être tracée directement aux cas d'utilisation (ou fonctions métier) et règles métier. L'objectif de ces tests est de vérifier que l'acceptation, le traitement et la récupération des données s'effectuent correctement, de même que l'implémentation des règles métier. Ce type de test repose sur des techniques fonctionnelles, c'est à dire des techniques qui contrôlent l'application (et ses processus internes) en interagissant avec l'application via l'interface graphique et en analysant la sortie (résultats). Vous trouverez ci-dessous une description du test recommandé pour chaque application :

 

Objectif du test : Vérifier que la navigation dans l'application ainsi que la saisie, le traitement et la récupération des données s'effectuent correctement.
Technique :
  • Exécuter 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 éléments suivants :
  • Les résultats prévus sont obtenus lorsque des données valides sont utilisées.
  • Les messages d'erreur ou d'avertissement appropriés s'affichent lorsque des données non valides sont utilisées.
  • Chaque règle métier est bien appliquée.
Critère d'exécution :
  • Tous les tests prévus ont été exécutés.
  • Tous les incidents identifiés ont été traités.
Considérations spéciales :
  • Il est nécessaire d'avoir accès au serveur UNIX de Wylie College ainsi qu'au système de catalogue des cours et au système de facturation existants.

3. Test du cycle métier

Le test du cycle métier doit émuler les activités effectuées sur le système au fil du temps. Il convient de définir une période (un an, par exemple) et d'exécuter les transactions et activités qui se produisent généralement au cours de cette période. Ceci comprend tous les cycles quotidiens, hebdomadaires et mensuels ainsi que les événements assujettis aux dates (fichiers mémo, par exemple).

 

Objectif du test Vérifier que les processus applicatifs et d'arrière-plan fonctionnent conformément aux modèles de gestion et calendriers requis.
Technique :
  • Le test doit simuler plusieurs cycles métier en réalisant les opérations suivantes :
  • Les tests utilisés pour tester les fonctions d'application seront modifiés/optimisés pour augmenter le nombre de fois où chaque fonction est exécutée afin de simuler plusieurs utilisateurs différents au cours d'une période définie.
  • Toutes les fonctions assujetties aux dates ou aux heures seront exécutées en utilisant des dates ou des créneaux valides et non valides.
  • Toutes les fonctions qui se produisent sur la base d'un planning périodique seront exécutées/lancées au moment qui convient.
  • Le test fera appel à des données valides et non valides, afin de vérifier les éléments suivants :
  • Les résultats prévus sont obtenus lorsque des données valides sont utilisées.
  • Les messages d'erreur ou d'avertissement appropriés s'affichent lorsque des données non valides sont utilisées.
  • Chaque règle métier est bien appliquée.
Critère d'exécution :
  • Tous les tests prévus ont été exécutés.
  • Tous les incidents identifiés ont été traités.
Considérations spéciales :
  • Les dates et événements système peuvent nécessiter des activités de support spéciales
  • Le modèle de gestion est nécessaire pour identifier les procédures et exigences de test appropriées.

4. Test de l'interface utilisateur

Le test de l'interface utilisateur vérifie l'interaction d'un utilisateur avec le logiciel. Le test de l'interface utilisateur a pour objectif de vérifier que cette dernière permet bien à l'utilisateur d'accéder aux différentes fonctions des applications et de naviguer entre elles. En outre, le test de l'interface utilisateur garantit que les objets de l'interface utilisateur fonctionnent comme prévu et sont conformes aux normes de l'entreprise ou du secteur d'activités.

 

Objectif du test : Vérifier les éléments suivants :
  • La navigation dans l'application reflète correctement les fonctions et exigences métier, y compris la navigation d'une fenêtre à une autre, d'une zone à une autre et l'utilisation de méthodes d'accès (touches de tabulation, déplacements de la souris, touches de raccourci)
  • Les objets et les caractéristiques des fenêtres tels que le menu, la taille, la position, l'état et la mise en évidence fonctionnent conformément aux standards en vigueur.
Technique :
  • Créer/modifier des tests pour chaque fenêtre afin de vérifier que la navigation et les états d'objets sont corrects pour chaque fenêtre d'application et chaque objet.
Critère d'exécution : Chaque fenêtre vérifiée avec succès afin de rester cohérente avec version étalon ou conforme au standard acceptable
Considérations spéciales :
  • Il n'est pas possible d'accéder à toutes les propriétés des objets personnalisés ou tiers.

5. Test de performance

Le test de performance mesure les temps de réponse, débit des transactions et autres exigences liées au temps. Le test de performance a pour objectif de vérifier et de valider le respect des exigences de performance. Le test de performance est généralement exécuté plusieurs fois, en utilisant à chaque fois une "charge d'arrière-plan" sur le système différente. Le premier test doit être réalisé avec une charge "nominale", semblable à la charge normale appliquée (ou prévue) pour le système cible. Un second test de performance doit être exécuté à l'aide d'une charge maximale.

Les tests de performance peuvent également permettre de profiler et ajuster les performances d'un système en fonction des conditions telles que la charge de travail ou la configuration matérielle.

REMARQUE : les transactions ci-dessous font référence à des "transactions commerciales logiques." Ces transactions sont définies en tant que fonctions spécifiques qu'un utilisateur du système est censé réaliser à l'aide de l'application, comme par exemple ajouter ou modifier un contrat donné.

 

Objectif du test : Valider le temps de réponse système pour les transactions ou fonctions métier désignées dans les deux conditions suivantes :

- volume normal prévu

- volume correspondant au pire cas prévu

Technique :
  • Utiliser les scripts de test développés pour le test du modèle de gestion (test système).
  • Modifier les fichiers de données (afin d'augmenter le nombre de transactions) ou modifier les scripts pour accroître le nombre d'itérations qu'entraîne chaque transaction.
  • Les scripts doivent être exécutés sur une machine (configuration idéale pour faire un test de performances sur un utilisateur unique et une transaction unique) et être répétés avec des clients multiples (virtuels ou réels, voir les considérations spéciales ci-dessous).
Critère d'exécution :
  • Transaction unique/utilisateur unique : exécution réussie des scripts de test sans aucun échec et dans les délais requis/prévus (par transaction)
  • Transactions multiples/utilisateurs multiples : exécution réussie des scripts de test sans aucun échec et dans des délais acceptables.
Considérations spéciales :
  • Réaliser un test de performance exhaustif implique de soumettre le serveur à une charge "d'arrière-plan". Plusieurs méthodes permettent de réaliser cette opération, parmi lesquelles :
    • "Diriger les transactions" directement vers le serveur, généralement sous la forme d'appels SQL.
    • Créer une charge utilisateur "virtuelle" afin de simuler de nombreux clients (généralement plusieurs centaines). Des outils d'émulation de terminal distant sont utilisés pour générer cette charge. Cette technique peut également permettre de créer du "trafic" qui constituera une charge appliquée réseau.
    • Utiliser des clients physiques multiples, qui exécutent tous des scripts de test afin d'appliquer une charge au système.
  • Les tests de performance doivent être réalisés sur une machine dédiée ou à un moment dédié, ce qui permet de profiter d'un contrôle total et d'une précision dans les mesures.
  • Les bases de données utilisées pour les tests de performance doivent avoir leur taille réelle ou doivent être ajustées afin d'avoir la même taille.

6. Test de charge

Le test de charge soumet le système testé à des charges variables afin de mesurer sa capacité à continuer de fonctionner correctement lorsqu'il est soumis à ces différentes charges. Le test de charge a pour objectif de vérifier et de garantir que le système fonctionne correctement au-delà de la charge maximale prévue. Ce test évalue également les performances (temps de réponse, débit des transactions et autres paramètres liés au temps).

REMARQUE : les transactions ci-dessous font référence à des "transactions commerciales logiques." Ces transactions sont définies en tant que fonctions spécifiques qu'un utilisateur du système est censé réaliser à l'aide de l'application, comme par exemple ajouter ou modifier un contrat donné.

Objectif du test : Vérifier le temps de réponse système pour les transactions ou études de rentabilité désignés face à des conditions de charge variables.
Technique :
  • Utiliser les tests développés pour le test du cycle métier.
  • Modifier les fichiers de données (afin d'augmenter le nombre de transactions) ou les tests pour accroître le nombre de fois où chaque transaction se produit.
Critère d'exécution :
  • Transactions multiples/utilisateurs multiples : exécution réussie des tests sans aucun échec et dans des délais acceptables.
Considérations spéciales :
  • Les tests de charge doivent être réalisés sur une machine dédiée ou à un moment dédié, ce qui permet de profiter d'un contrôle total et d'une précision dans les mesures.
  • Les bases de données utilisées pour les tests de charge doivent avoir leur taille réelle ou doivent être ajustées afin d'avoir la même taille.

7. Test sous contraintes

Le test sous contraintes a pour objectif de détecter les erreurs liées à un niveau de ressources insuffisant ou à une concurrence pour l'accès aux ressources. Un niveau de mémoire ou un espace disque insuffisants peuvent révéler des incidents logiciels qui ne sont pas visibles dans des conditions normales. D'autres incidents peuvent découler de la concurrence pour l'accès à des ressources partagées telles que les verrous de base de données ou la bande passante réseau. Le test sous contraintes identifie la charge maximale que le système peut prendre gérer.

REMARQUE : les références aux transactions ci-dessous renvoient à des transactions commerciales logiques.

Objectif du test : Vérifier que le système et le logiciel fonctionnent correctement et sans erreur lorsqu'ils sont soumis aux contraintes suivantes :
  • peu ou pas de mémoire disponible sur le serveur (RAM et unité de stockage à accès direct)
  • nombre maximal de clients (réels ou physiquement capables) connectés ou simulés
  • utilisateurs multiples réalisant les mêmes transactions sur les mêmes données/comptes
  • volume/mélange de transactions correspondant au pire cas possible (voir le test de performance ci-dessus).

REMARQUES : l'objectif du test sous contraintes peut également être défini comme étant d'identifier et de documenter les conditions dans lesquelles le système NE PARVIENT PLUS à fonctionner correctement.

Technique :
  • Utiliser les tests développés pour le test de performance.
  • Pour tester des ressources limitées, les tests doivent être exécutés sur une machine unique et la mémoire vive et l'unité de stockage à accès direct du serveur doivent être réduites (ou limitées).
  • Pour les tests sous contraintes restants, il convient d'utiliser des clients multiples, qui exécutent les mêmes tests ou bien des tests complémentaires pour produire le volume/mélange de transactions correspondant au pire cas de figure.
Critère d'exécution : Tous les tests planifiés sont exécutés et les limites système spécifiées sont atteintes ou dépassées sans provoquer de panne du système ou du logiciel (ou les conditions dans lesquelles survient la panne du système sont hors du cadre des conditions spécifiées).
Considérations spéciales :
  • Appliquer des contraintes au réseau peut nécessiter des outils réseau pour charger ce dernier avec des messages ou des paquets.
  • Il convient de réduire temporairement l'unité de stockage à accès direct utilisée pour le système afin de réserver l'espace libre à la croissance de la base de données.
  • Synchronisation des clients accédant simultanément aux mêmes enregistrements ou comptes de données.

8. Test de volume

Le test de volume soumet le logiciel à de grandes quantités de données afin d'établir si les limites au-delà desquelles le logiciel tombe en panne sont atteintes. Le test de volume identifie également la charge ou le volume maximal(e) continu(e) que le système peut gérer pendant un laps de temps donné. Par exemple, si le logiciel traite un jeu d'enregistrements de base de données afin de générer un rapport, un test de volume utiliserait une grande base de données de test et vérifierait que le logiciel s'est comporté normalement et a produit le bon rapport.

Objectif du test : Vérifier que l'application/le système fonctionne correctement dans les scénarios de volume élevé suivants :
  • nombre maximal de clients (réels ou physiquement capables) connectés (ou simulés) et réalisant tous pendant une période prolongée la même fonction métier correspondant au pire cas de figure (performances).
  • la taille maximale de la base de données a été atteinte (réelle ou ajustée) et plusieurs requêtes/transactions de rapport sont exécutées simultanément.
Technique :
  • Utiliser les tests développés pour le test de performance.
  • Il convient d'utiliser des clients multiples, qui exécutent les mêmes tests ou bien des tests complémentaires pour produire le volume/mélange de transactions correspondant au pire cas de figure pendant une période prolongée (voir le test sous contraintes ci-dessus).
  • La base de données de taille maximale est créée (réelle, ajustée ou remplie de données représentatives) et plusieurs clients sont utilisés pour exécuter simultanément des requêtes/transactions de rapport pendant des périodes prolongées.
Critère d'exécution : Tous les tests planifiés ont été exécutés et les limites système spécifiées ont été atteintes ou dépassées sans provoquer de panne du système ou du logiciel.
Considérations spéciales :
  • Quelle durée serait considérée comme acceptable pour des conditions de volume élevé (comme indiqué plus haut) ?

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

Le test de sécurité et de contrôle d'accès se concentre sur deux domaines clés de la sécurité :

Sécurité de l'application, y compris l'accès aux données et fonctions métier.
Sécurité du système, y compris la connexion et l'accès distant au système.

La sécurité de l'application vérifie que, conformément au niveau de sécurité souhaité, les utilisateurs sont cantonnés à des fonctions spécifiques ou aux données auxquelles ils sont autorisés. Par exemple, tous les utilisateurs peuvent être autorisés à saisir des données et à créer de nouveaux comptes, mais seuls les responsables peuvent les supprimer. S'il existe des mesures de sécurité au niveau des données, le test vérifie que le "type" d'utilisateur un peut visualiser toutes les informations client, y compris les données financières, tandis que l'utilisateur deux ne peut voir que les données démographiques de ce même client.

La sécurité du système garantit que seuls les utilisateurs jouissant de droits d'accès au système sont en mesure d'accéder aux applications et qu'ils ne le font que via les passerelles appropriées.

Objectif du test : Sécurité des fonctions/données : vérifiez que l'utilisateur ne peut accéder qu'aux fonctions/données pour lesquelles son type est autorisé.

Sécurité du système : vérifiez que seuls les utilisateurs autorisés accèdent au système et aux applications.

Technique :
  • Sécurité des fonctions/données : identifier et répertorier chaque type d'utilisateur ainsi que les fonctions/données auxquelles chacun de ses types est autorisé à accéder.
  • Créer des tests pour chaque type d'utilisateur et vérifier les autorisations en créant des transactions spécifiques à chaque type d'utilisateur.
  • Modifier le type d'utilisateur et relancer les tests pour les mêmes utilisateurs. Vérifier dans chaque cas que l'accès aux fonctions/données supplémentaires est bien accordé ou refusé.
  • Accès au système (voir les considérations spéciales ci-dessous)
Critère d'exécution : Pour chaque type d'utilisateur connu, les fonctions/données appropriées sont disponibles et toutes les transactions fonctionnent comme prévu et s'exécutent avant les tests de fonction d'applications
Considérations spéciales :
  • L'accès au système doit être révisé/discuté avec l'administrateur réseau ou système, selon les cas. Ce test peut ne pas être obligatoire car il peut constituer une fonction d'administration réseau ou système.

10. Test de reprise en ligne/reprise sur incident

Le test de reprise en ligne/reprise sur incident garantit qu'une application ou un système complet peut réaliser correctement une reprise en ligne ou une reprise sur incident suite à des dysfonctionnements matériels, logiciels ou réseau divers, ceci sans perte excessive de données ou dommages à l'intégrité des données.

Le test de reprise en ligne garantit, pour les systèmes qui doivent fonctionner en permanence et lorsque survient une condition de reprise en ligne, que les systèmes de remplacement ou de secours "se substituent" bien au système en panne sans perte de données ou de transactions.

Le test de reprise sur incident est un processus de test antagoniste dans lequel l'application ou le système est soumis à des conditions extrêmes (ou à des conditions simulées) telles que des pannes d'E/S de périphérique ou des clés/pointeurs de base de données non valides. Les processus de reprise sur incident sont appelés et l'application/le système est suivi(e) et/ou inspecté(e) afin de vérifier que la reprise a réussi au niveau de l'application, du système ou des données.

Objectif du test : Vérifier que les processus de reprise sur incident (manuels ou automatisés) restaurent bien la base de données, les applications et le système dans l'état connu souhaité. Les types de conditions suivants doivent être inclus dans le test :
  • Coupure de courant au niveau du client
  • Coupure de courant au niveau du serveur
  • Interruption des communications transitant via le(s) serveur(s) réseau
  • Coupure d'alimentation ou interruption des communications vers l'unité de stockage à accès direct et/ou ses contrôleurs
  • Cycles incomplets (processus de filtre de données ou processus de synchronisation de données interrompus).
  • Clés/pointeur de base de données non valides
  • Elément de données non valide/corrompu dans la base de données
Technique : Les tests créés pour le test de la fonction d'application et le test du cycle métier doivent être utilisés pour créer une série de transactions. Une fois atteint le point de départ souhaité du test, il convient de réaliser (ou de simuler) les actions suivantes individuellement :
  • Coupure de courant au niveau du client : couper l'alimentation au niveau du PC
  • Coupure de courant au niveau du serveur : simuler ou initier des procédure de coupure d'alimentation pour le serveur
  • Interruption via les serveurs réseau : simuler ou initier des coupures de communication avec le réseau (déconnecter physiquement les câbles de communication ou mettre hors tension les serveurs/routeurs réseau).
  • Coupure d'alimentation ou interruption des communications vers l'unité de stockage à accès direct et/ou ses contrôleurs : simuler ou éliminer physiquement la communication avec un ou plusieurs contrôleurs ou périphériques de l'unité de stockage à accès direct.

Une fois les conditions/conditions simulées ci-dessus réunies, il convient d'exécuter des transactions supplémentaires. C'est une fois ce second état de test atteint que les procédures de reprise sur incident doivent être appelées.

Le test destiné à identifier les cycles incomplets utilise la même technique que celle décrite ci-dessus, à cette exception que les processus de base de données doivent être abandonnés ou terminés de manière prématurée.

Le test des conditions suivantes nécessite d'atteindre un état de base de données connu. Plusieurs zones base de données, pointeurs et clés doivent être corrompus manuellement et directement au sein de la base de données (à l'aide des outils de base de données). Les transactions supplémentaires doivent être exécutées à l'aide des tests provenant des tests de fonction d'application et des tests du cycle métier et les cycles complets doivent être exécutés.

Critère d'exécution : Dans tous les cas ci-dessus, l'application, la base de données et le système doivent, une fois les procédures de reprise sur incident exécutées, retourner à un état connu souhaité. Cet état inclut la corruption des données limitée aux zones, pointeurs/clés connus ainsi que les rapports indiquant quels processus ou transactions n'ont pas été réalisés totalement du fait des interruptions.
Considérations spéciales :
  • Le test de reprise sur incident s'avère particulièrement intrusif. Les procédures prévoyant la déconnexion de câbles (afin de simuler une perte des communications ou une mise hors tension) peuvent ne pas être souhaitables ou même réalisables. Il peut être nécessaire de recourir à des méthodes alternatives, tels que les outils logiciels de diagnostic.
  • Des ressources provenant des systèmes (ou opérations informatiques), de la base de données et des groupes de réseau sont nécessaires.
  • Ces tests doivent être exécutés en dehors de heures de bureau ou sur une ou plusieurs machine(s) isolée(s).

11. Test de configuration

Le test de configuration vérifie le fonctionnement du logiciel sur différentes configurations logicielles et matérielles. Dans la plupart des environnements de production, les spécifications matérielles des postes de travail client, des connexions réseau et des serveurs de la base de données varient. Les postes de travail client peuvent disposer de logiciels différents (applications, pilotes, etc). A tout moment, de nombreuses combinaisons différentes peuvent être actives.

 

Objectif du test : Valider et vérifier que les applications client fonctionnent correctement sur les postes de travail client indiqués.
Technique :
  • Utiliser les scripts de test de système et d'intégration
  • Ouvrir/fermer diverses applications sur le PC, soit dans le cadre du test ou avant son lancement.
  • Exécuter les transactions sélectionnées pour simuler des activités d'utilisateur au sein et en dehors de diverses applications pour PC.
  • Répéter le processus ci-dessus, en réduisant la mémoire de base disponible sur le client.
Critère d'exécution : Pour chaque combinaison, les transactions sont effectuées avec succès sans incident.
Considérations spéciales :
  • Quelles applications pour PC sont disponibles, accessibles sur les clients ?
  • Quelles applications sont généralement utilisées ?
  • Quelles données les applications exécutent-elles (grande feuille de calcul ouverte sous Excel, document de 100 pages sous Word, par exemple).
  • Les systèmes, serveurs de réseau, bases de données et autres doivent également être documentés intégralement dans le cadre de ce test.

12. Test d'installation

Le test d'installation a deux objectifs. Le premier est de garantir que le logiciel peut être installé sur toutes les configurations possibles, comme par exemple une nouvelle installation, une mise à niveau et une installation intégrale ou personnalisée, dans des conditions normales et anormales. Parmi les conditions anormales, citons une insuffisance d'espace disque, une absence d'autorisation pour la création de répertoires, etc. Le second objectif est de vérifier que, une fois installé, le logiciel fonctionne correctement. Ceci implique généralement d'exécuter un certain nombre de tests qui ont été développés pour le test de fonctions.

 

Objectif du test : Vérifier et valider le fait que le logiciel client s'installe correctement sur chaque client dans les conditions suivantes :
  • Nouvelle installation, nouvelle machine, jamais installé.
  • Machine mise à niveau sur laquelle était installée la même version
  • Machine mise à niveau sur laquelle était installée une version antérieure
Technique :
  • Développer manuellement ou automatiquement des scripts pour valider la condition de la machine cible (nouvelle - jamais installé, même version ou version antérieure déjà installée).
  • Lancer/effectuer l'installation.
  • A l'aide d'un sous-ensemble prédéfini de scripts de test d'intégration ou de système, exécutez les transactions.
Critère d'exécution : Les transactions s'exécutent correctement sans incident.
Considérations spéciales :
  • Quelles transactions doivent être sélectionnées pour comprendre un test de fiabilité vérifiant que l'application s'est installée avec succès et qu'aucun composant logiciel ne manque ?

2. Outils

Il convient d'utiliser les outils suivants pour tester le système :

 

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

6. Ressources

    Cette section présente les ressources recommandées pour le test du système d'inscription aux cours, leurs responsabilités principales ainsi que l'ensemble de leurs connaissances ou compétences.

    1. Agents

Le tableau ci-dessous montre les affectations de personnel présumées pour les tâches liées au test.

Ressources humaines

Agent

Ressources minimales recommandées

(nombre d'agents affectés à temps complet)

Commentaires/responsabilités spécifiques

Responsable des tests 1 - Kerry Stone Supervise l'ensemble des opérations

Responsabilités :

  • Fournir des directives techniques
  • Acquérir les ressources appropriées
  • Rendre des comptes à la direction
Concepteur de test Margaret Cox

Carol Smith

Sophie King

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é du travail de test
Testeur de système Carol Smith

Sophie King

Adrian Harmsen

Exécute les tests

Responsabilités :

  • Exécuter les tests
  • Journaliser les résultats
  • Effectuer une reprise après des erreurs
  • Documenter les incidents
Administrateur de système de test Simon Jones S'assure que l'environnement de test et les ressources sont gérés et maintenus.

Responsabilités :

  • Administrer le système de gestion du test
  • Installer/gérer les accès agent aux systèmes de test
Administration de base de données/Responsable de la base de données Margaret Cox S'assure que les ressources et l'environnement de données de test (base de données) sont gérés et maintenus.

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 :

  • Identifie et définit la(les) classe(s) de test
  • Identifie et définit les packages de test
Implémenteur Margaret Cox

Adrian Harmsen

Implémente et teste de manière unitaire les classes de test et packages de test

Responsabilités :

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

2. Système

Le tableau suivant présente les ressources système pour le test du système d'inscription aux cours.

Ressources système

Ressource

Nom / Type / N° de série

Serveur de 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 du client de test
 
  10 PC distants (avec accès à Internet) N° de série : A8339223

N° de série : B9334022

N° de série : B9332544

<7 A venir>

  6 PC locaux (reliés par un réseau local) N° de série : R3322411 (appartient au Responsable des inscriptions)

N° de série : A8832234 (Labo informatique)

N° de série : W4592233 (Labo informatique)

N° de série : X3333411 (Bureau des professeurs)

N° de série : A987344 (Labo des sciences)

N° de série : X9834000 (Association des étudiants)

Référentiel de test
 
  Serveur de 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

Simulateur de charge N° de série : ABC-123

 

 

7. Jalons du projet

    Les activités et jalons de test dépendent fortement des itérations de développement. La phase de construction doit être divisée en 3 itérations. Chacune d'entre elle contient un cycle de test complet qui prévoit la planification, la conception, le développement, l'exécution et l'évaluation du test.

    Reportez-vous au plan de développement logiciel [14] ainsi qu'aux plans d'itération pour le calendrier principal ainsi qu'au plan de la phase de construction qui montre les itérations de développement.

    Le tableau ci-dessous répertorie les jalons du test. L'effort, la date de début et la date de fin peuvent être complétés lors de la planification du contenu de l'itération.

    Tâche jalon Effort (jours) Date de début Date de fin
    Itération C1 : Edition Bêta

    Planification du test

    Conception du test

    Développement du test

    Exécution du test

    Evaluation du test

    A venir 15 mars 12 avril
    Itération C2 : Edition R1.0

    Planification du test

    Conception du test

    Développement du test

    Exécution du test

    Evaluation du test

    A venir 13 avril 14 mai
    Itération C3 : Edition R2.0

    Planification du test

    Conception du test

    Développement du test

    Exécution du test

    Evaluation du test

    A venir 15 mai 17 juin

     

8. Produits

    Les produits des tâches de test définies dans ce plan de test sont décrits dans le tableau ci-dessous.

    Il est noter que certains de ces produits sont produits plusieurs fois ; une fois par cycle de test ou itération. Les autres produits, comme par exemple le plan de test, sont mis à jour à chaque itération de développement.

    Produits Propriétaire Revue/Distribution Date limite
    Plan de test K. Stone Equipe de gestion de projet sénior 28 mars
    Environnement de test S. Jones - 28 mars
    Suite de tests C. Smith et M. Cox Revue interne par un pair 28 mars
    Jeux d'essai M. Cox Revue interne par un pair 31 mars
    Scripts de test M. Cox - 2 avril
    Modules de remplacement de test, pilotes M. Cox - 4 avril
    Rapports sur les incidents de test C. Smith Equipe de gestion de projet sénior A venir
    Résultats des tests C. Smith Responsable des tests A venir
    Rapport d'évaluation du test C. Smith Equipe de gestion de projet sénior A venir

     

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.

2. Journaux de test

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

    • Statut du test
    • Numéro de construction
    • Testé par
    • Testé le
    • Notes de test

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.

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

9. Tâches projet

Voici les tâches ayant trait au test pour le test du système d'inscription aux cours :

 

Planifier le test

Identifier les exigences du test

Evaluer les risques

Développer une stratégie de test

Identifier les ressources de test

Créer un calendrier

Générer un plan de test

Concevoir le test

Analyser la charge de travail

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 des 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 de 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