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
- Objectifs
- Portée
- Références
- Exigences de test
- Stratégie de test
- Types de test
- Test d'intégrité des données et de la base de données
- Test système
- Test du cycle métier
- Test de l'interface utilisateur
- Test de performance
- Test de charge
- Test sous contraintes
- Test de volume
- Test de sécurité et de contrôle d'accès
- Test de reprise en ligne / reprise sur incident
- Test de configuration
- Test d'installation
- Outils
- Ressources
- Agents
- Système
- Jalons du projet
- Produits
- Ensemble de tests
- Journaux de tests
- Rapports d'anomalie
- 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 :
- Course Billing Interface Specification, WC93332, 1985, Wylie College
Press.
- Course Catalog Database Specification, WC93422, 1985, Wylie College
Press.
- Course Registration System Vision Document, WyIT387, V1.0, 1998, Wylie College IT.
- Course Registration System Glossary, WyIT406, V2.0, 1999, Wylie College IT.
- Course Registration System Use Case Spec - Close Registration, WyIT403, V2.0, 1999, Wylie College
IT.
- Course Registration System Use Case Spec - Login, WyIT401, V2.0, 1999, Wylie College IT.
- Course Registration System Use Case Spec - Maintain Professor Info, WyIT407, Version 2.0, 1999,
Wylie College IT.
- Course Registration System Use Case Spec - Register for Courses, WyIT402, Version 2.0, 1999, Wylie
College IT.
- Course Registration System Use Case Spec - Select Courses to Teach, WyIT405, Version 2.0, 1999,
Wylie College IT.
- Course Registration System Use Case Spec - Maintain Student Info, WyIT408, Version 2.0, 1999, Wylie
College IT.
- Course Registration System Use Case Spec - Submit Grades, WyIT409, Version 2.0, 1999, Wylie College
IT.
- Course Registration System Use Case Spec - View Report Card, WyIT410, Version 2.0, 1999, Wylie
College IT.
- Course Registration System Supplementary Specification,
WyIT400, V1.0, 1999, Wylie College IT.
- Course Registration System Software Development Plan, WyIT418, V2.0, 1999, Wylie College IT.
- Course Registration System Software Architecture Document,
WyIT431, V1.0, 1999, Wylie College IT.
- Course Registration System Requirements Attributes Guidelines,
WyIT404, V1.0, 1999, Wylie College IT.
- 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.
- 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.
-
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
|
|