Système d'informations sportives par messagerie de poche

Plan de test

Version 1.0

Historique de révision

Date

Version Description Auteur
26 octobre 1999 1.0 Version initiale Context Integration
Sommaire

Introduction Début de page

Objet

Le plan de test du système d'informations sportives par messagerie de poche permet d'atteindre les objectifs suivants :

  1. Identification des informations de projet existantes et des composants logiciels à tester
  2. Elaboration de la liste des exigences de test recommandées (niveau supérieur)
  3. Recommandation et description des stratégies de test à employer
  4. Identification des ressources requises et proposition d'une estimation des efforts de test
  5. Elaboration de la liste des éléments livrables pour le projet de test

Contexte

Le système d'informations sportives par messagerie de poche fournit à des abonnés un système de messagerie de poche alphanumérique qui les informe d'événements sportifs en rapport avec des disciplines pour lesquelles ils ont souscrit un abonnement. Les abonnés peuvent alors se connecter à un site Web personnalisé, à partir duquel ils peuvent consulter les communiqués sur lesquels ils ont été informés et d'autres informations sportives.

Le système comprend trois sous-systèmes principaux, qui sont hébergés sur un serveur Web d'application, et interagit avec le site Web ActuWebEnligne, existant ainsi qu'avec les passerelles de messagerie de poche. Ces sous-systèmes sont les suivants :

  • Gestion du contenu : ce sous-système accepte le contenu, définit la catégorie du contenu et affiche les titres que consulteront les abonnés. Il gère également le contenu publicitaire destiné spécifiquement à des groupes donnés d'abonnés (en fonction des profils d'abonnement).
  • Messagerie de poche : ce sous-système devient actif lorsqu'un nouveau contenu est chargé dans le système. Par ailleurs, il détermine également les abonnés qui doivent être informés par la messagerie de poche et envoie des messages aux passerelles de la messagerie de poche.
  • Génération de rapports : ce sous-système effectue le suivi des publicités consultées et génère des rapports sur la consultation de ces publicités.

L'architecture du système peut être décrite de la manière suivante :

Diagramme de l'architecture du système

 

Portée

Le système d'informations sportives par messagerie de poche sera soumis à des tests unitaires et à un test système. Les tests unitaires portent sur la qualité fonctionnelle, alors que le test système concerne les problèmes d'évolutivité et de performances.

L'interaction des sous-systèmes sera testée de la manière suivante :

    1. Gestion du contenu pour la messagerie de poche
    2. Gestion du contenu pour la génération de rapports

Les interfaces des systèmes suivantes seront testées :

    1. Système d'informations sportives par messagerie de poche avec le serveur Web ActuWebEnligne existant
    2. Système d'informations sportives par messagerie de poche avec les passerelles de messagerie de poche

Les tests le plus importants concernent la charge et les performances. Ces tests sont conçus de la manière suivante :

  1. Nous créerons un scénario de test qui générera un nombre croissant de pages jusqu'à 200 000 pages.
  2. Nous créerons également un scénario de test avec un nouveau contenu parvenant au système à la vitesse d'un élément toutes les 20 secondes.
  3. Enfin, nous stimulerons des charges d'abonnés concurrents croissantes jusqu'à 200 000 abonnés.

Identification du projet

Le tableau ci-dessous identifie les différents documents utilisés pour établir le plan de test, ainsi que leur disponibilité :

Document
(y compris la version et la date)
Créé ou disponible Reçu ou révisé Auteur ou ressources Notes
Document Vision Oui Oui Context Integration  
Spécification supplémentaire Oui Oui Context Integration  
Rapports de cas d'utilisation Oui Oui Context Integration  
Planning de projet Oui Oui Context Integration  
Spécifications de conception Non Non    
Prototype Oui Oui Context Integration  
Evaluation des risques métier/projet Oui Oui Context Integration  

Exigences de test Début du page

La liste ci-dessous identifie les éléments (cas d'utilisation, exigences fonctionnelles et non fonctionnelles) qui ont été identifiés comme cibles des tests. Cette liste représente les éléments qui seront testés.

Test de la base de données

    Vérifier que les informations relatives aux abonnés peuvent être entrées et récupérées.

    Vérifier que le contenu et les catégories peuvent être insérés et affichés.

    Vérifier que les profils des publicitaires et les informations de compte peuvent être entrés et affichés.

    Vérifier qu'un suivi des informations d'utilisation spécifiques aux abonnés est effectué.

Test fonctionnel

    Vérifier que les abonnés voient apparaître les informations pour lesquelles ils ont demandé à être informé par messagerie de poche.

    Vérifier que les pages sont transférées aux abonnés à l'arrivée de contenu.

    Vérifier que l'insertion de contenu automatique fonctionne.

    Vérifier que l'autorisation de l'éditeur entraîne l'insertion de contenu non automatique.

    Vérifier que les abonnés dont l'abonnement est arrivé à expiration ne reçoivent aucun page.

    Vérifier que le contenu marqué comme archivé n'est pas visible par les abonnés.

    Vérifier que le contenu obsolète est supprimé.

    Vérifier que les rapports des publicitaires sont précis.

    Vérifier que les rapports des publicitaires peuvent être reçus au format Microsoft® Word®, Microsoft® Excel ® ou HTML.

Test du cycle métier

    Aucun.

Test de l'interface utilisateur

    Naviguer entre tous les cas d'utilisation, en vérifiant que chaque panneau peut être compris facilement.

    Vérifier toutes les fonctions d'aide en ligne

    Vérifier que tous les écrans sont conformes aux normes d'ActuWebEnligne.

Définition du profil des performances

    Vérifier le temps de réponse de l'interface vis-à-vis du système de passerelles du messager de poche.

    Vérifier le temps de réponse de l'interface à partir du serveur Web ActuWebEnligne existant.

    Vérifier le temps de réponse avec une connexion via un modem à 56 kb/s.

    Vérifier le temps de réponse avec une connexion en local (sur le même réseau LAN).

Test de charge

    Vérifier la réponse du système avec 200 abonnés concurrents.

    Vérifier la réponse du système avec 500 abonnés concurrents.

    Vérifier la réponse du système avec 1 000 abonnés concurrents.

    Vérifier la réponse du système avec 5 000 abonnés concurrents.

    Vérifier la réponse du système avec 10 000 abonnés concurrents.

    Vérifier la réponse du système avec 50 000 abonnés concurrents.

    Vérifier la réponse du système avec 100 000 abonnés concurrents.

    Vérifier la réponse du système avec 200 000 abonnés concurrents.

Test des contraintes

    Aucun.

Test du volume

    Vérifier les pages envoyées sur une période de 5 minutes, lorsqu'un élément de contenu unique arrive.

    Vérifier les pages envoyées sur une période de 5 minutes, lorsque du contenu arrive toutes les 20 secondes.

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

    Vérifier que les personnes qui ne sont pas abonnées ne peuvent pas accéder à des informations accessibles aux abonnés.

    Vérifier que les non éditeurs ne peuvent pas autoriser le contenu.

    Vérifier que les publicitaires voient uniquement leur propre contenu publicitaire.

Test de panne/reprise

    Aucun.

Test de la configuration

    Vérifier le fonctionnement avec le navigateur Netscape v.4.x.

    Vérifier le fonctionnement avec le navigateur Microsoft® Internet Explorer® v.5.x

Test de l'installation

    Aucun.

Stratégies de testDébut de page

Types de test

Test de l'intégrité de la base de données et des données
Objectif du test : Garantir le bon fonctionnement des méthodes et des processus d'accès, sans corruption de données.
Stratégie :
  • Appeler chaque processus et chaque méthode d'accès, en fournissant à chacun de ces processus et méthodes des données (ou demande de données) valides et non valides.
  • Inspecter la base de données pour garantir que les données ont été fournies comme prévu, que tous les événements de la base de données ont eu lieu correctement ou revoir les données renvoyées pour s'assurer que les données appropriées ont été récupérées (pour les bonnes raisons)
Critères de fin de test : Tous les processus et méthodes d'accès à la base de données fonctionnent comme prévu, sans corruption de données.
Remarques particulières :
  • Les processus doivent être appelés manuellement.
  • Les petites bases de données ou les bases de données de taille minimale (limitées en nombre d'enregistrements) doivent être utilisées pour accroître la visibilité des événements non acceptables.
Test fonctionnel
Objectif du test : Garantir que les fonctionnalités ciblées dans le cadre du test, y compris la navigation, ainsi que l'entrée, le traitement et la récupération de données, sont opérationnelles.
Stratégie : Exécuter chaque cas d'utilisation, chaque flux de cas d'utilisation ou fonction, à l'aide de données valides et non valides, afin de vérifier les points suivants :
  • Les résultats attendus sont obtenus avec des données valides.
  • Les messages d'avertissement et d'erreur appropriés apparaissent avec des données non valides.
  • Chaque règle métier est correctement appliquée.
Critères de fin de test :
  • Tous les tests planifiés ont été exécutés.
  • Tous les défauts identifiés ont été traités.
Remarques particulières : Aucune.
Test de l'interface utilisateur
Objectif du test : Vérifier les points suivants :
  • La navigation dans la cible de test reflète bien les fonctions et exigences métier, y compris la navigation d'une fenêtre à une autre et d'une zone à une autre, et l'utilisation des modes d'accès (touches de tabulation, mouvements de la souris, touches de raccourci)
  • Les objets et caractéristiques Web, tels que les menus, la taille, la position, l'état et le sujet, sont conformes aux normes.
Stratégie : Créer ou modifier les tests pour chaque fenêtre, afin de vérifier que la navigation se déroule correctement et pour vérifier l'état des objets pour chaque fenêtre et objet de l'application.
Critères de fin de test : Chaque fenêtre a été vérifiée comme cohérente avec la version de test des performances ou avec les normes acceptables
Remarques particulières : Il est impossible d'accéder à l'ensemble des propriétés des objets tiers et personnalisés.
Définition du profil des performances
Objectif du test : Vérifier dans les conditions suivantes les comportements des performances pour les transactions ou fonctions métier conçues :
  • Charge de travail normale anticipée
  • Charge de travail du cas le plus défavorable anticipée
Stratégie : Utiliser les procédures de test élaborées pour le test fonctionnel et le test du cycle métier.

Modifier les fichiers de données (afin d'augmenter le nombre de transactions) ou les scripts afin d'augmenter le nombre d'itérations de chaque transaction.

Les scripts doivent être exécutés sur une seule machine (cas le plus favorable pour tester les performances pour un utilisateur unique ou une transaction unique) et répétés avec plusieurs clients (virtuels ou réels : se reporter aux remarques particulières ci-après).

Critères de fin de test : Transaction unique ou utilisateur unique : fin des scripts de test sans arrêt anormal et dans le laps de temps attendu ou requis (pour chaque transaction)

Transactions multiples ou utilisateurs multiples : fin des scripts de test sans arrêt anormal, dans un laps de temps acceptable.

Remarques particulières : Un test complet des performances implique qu'une charge de travail est exécutée "en arrière-plan" sur le serveur.

Plusieurs méthodes permettent d'obtenir ce résultat, à savoir :

  • "Diriger les transactions" directement vers le serveur, généralement sous la forme d'appels SQL.
  • Créer une charge d'utilisateurs "virtuelle" pour stimuler plusieurs clients (plusieurs centaines, en règle générale). Les outils d'émulation de terminal à distance permettent d'obtenir cette charge. Cette méthode peut également être utilisée pour charger le réseau avec un certain "trafic."
  • Utiliser plusieurs clients physiques, chacun exécutant des scripts de test qui placent une charge sur le système.

Le test des performances doit être effectué sur une machine dédiée spécialement à ce test ou pendant une période réservée pour ce test, afin que les mesures soient précises et parfaitement contrôlées.

La taille des bases de données utilisées pour le test des performances doit être conforme à la réalité ou les bases de données doivent être dimensionnées de manière égale.

Test de charge
Objectif du test : Vérifier dans différentes conditions de charge de travail la durée des comportements des performances pour les transactions ou fonctions métier conçues.
Stratégie : Utiliser les tests élaborés pour le test fonctionnel et le test du cycle métier.

Modifier les fichiers de données (afin d'augmenter le nombre de transactions) ou les tests afin d'augmenter le nombre d'itérations de chaque transaction.

Critères de fin de test : Transactions multiples ou utilisateurs multiples : fin des scripts de test sans arrêt anormal, dans un laps de temps acceptable.
Remarques particulières : Le test des performances doit être effectué sur une machine dédiée spécialement à ce test ou pendant une période réservée pour ce test, afin que les mesures soient précises et parfaitement contrôlées.

La taille des bases de données utilisées pour le test des performances doit être conforme à la réalité ou les bases de données doivent être dimensionnées de manière égale.

Test du volume
Objectif du test : Vérifier que la cible de test fonctionne correctement avec les scénarios suivants mettant en jeu des volumes importants :
  • Nombre maximal de clients (nombre de clients réel ou nombre de clients physiquement capables) connectés (ou pour lesquels la connexion est simulée) exécutant tous la même fonction métier (performances) du cas le plus défavorable pendant une longue période.
  • La taille de base de données maximale a été atteinte (réelle ou dimensionnée) et plusieurs transactions de demande et de rapport sont exécutées simultanément.
Stratégie : Utiliser les tests élaborés pour la définition du profil des performances ou le test de charge.

Afin de générer un volume de transactions dans le cas le plus défavorable, plusieurs clients exécutant les mêmes tests ou des tests complémentaires doivent être utilisés.

La taille maximale de base de données (réelle, dimensionnée ou renseignée avec des données représentatives) est créée et plusieurs clients ont été utilisés simultanément pour exécuter des transactions de demande et de rapport sur de longues périodes.

Critères de fin de test : 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 arrêt anormal du logiciel.
Remarques particulières : Quelle durée doit être considérée comme acceptable dans des conditions impliquant des volumes importants (comme indiqué ci-avant) ?
Test du contrôle d'accès et de la sécurité
Objectif du test : Sécurité au niveau de l'application : vérifier qu'un acteur peut accéder uniquement aux fonctions et données pour lesquels le type d'utilisateur dont il relève dispose des droits requis.

Sécurité au niveau du système : vérifier que seuls les acteurs disposant de droits d'accès au système et aux applications sont autorisés à y accéder.

Stratégie : Au niveau de l'application : identifier et répertorier chaque type d'acteur et les fonctions ou données pour lesquelles ce type d'acteur dispose de droits d'accès.

Créer des tests pour chaque type d'acteur et vérifier chaque droit d'accès en créant des transactions spécifiques à chaque acteur utilisateur.

Modifier le type d'utilisateur et réexécuter les tests pour les mêmes utilisateurs. Dans chaque cas, vérifier les fonctions et données qui sont disponibles ou rejetées.

Accès au niveau du système (se reporter aux remarques particulières ci-après)

Critères de fin de test : Pour chaque type d'acteur connu, les fonctions et données appropriées sont disponibles et toutes les transactions fonctionnent comme prévu et sont exécutées avant les tests fonctionnels.
Remarques particulières : L'accès au système doit être révisé ou traité avec l'administrateur système ou réseau approprié. Etant donné que ce test peut faire partie de l'administration système ou réseau, il peut s'avérer inutile de l'exécuter.
Test de la configuration
Objectif du test :

Vérifier que la cible de test fonctionne correctement avec les configurations matérielles et logicielles requises.

Stratégie :

Utiliser les scripts de test fonctionnel.

Pendant le test ou avant le début du test, ouvrir ou fermer les logiciels non ciblés dans le cadre de ce test, tels que les applications Microsoft Excel® et Word®.

Exécuter les transactions sélectionnées pour simuler les interactions entre les acteurs et les logiciels ciblés et non ciblés dans le cadre du test.

Répéter le processus ci-dessus, en réduisant la mémoire généralement disponible sur le client.

Critères de fin de test :

Pour chaque combinaison de logiciels ciblés et non ciblés dans le cadre de test, toutes les transactions se sont déroulées sans arrêt anormal.

Remarques particulières :

Quels logiciels non ciblés dans le cadre du test sont requis, disponibles et accessibles sur le bureau ?

Quelles sont les applications généralement utilisées ?

Quelles sont les données exécutées dans les applications (grande feuille de calcul dans Excel, document de 100 pages dans Word)?

Les systèmes, les éléments réseau, les serveurs réseau, les bases de données, etc. doivent également être documentés dans le cadre du test.

Outils

Les outils suivants seront utilisés pour ce projet :

 

Outil

Version

Suivi des incidents

Project HomePage

 
Gestion de projet

Microsoft® Project®

 


Ressources Début de page

Cette section présente les ressources dont il est recommandé de disposer pour les efforts de test du système d'informations sportives par messagerie de poche, ainsi que les principales responsabilités et les connaissances ou compétences de ces ressources.

Membres du projet

Ce tableau présente les personnes pressenties pour participer au projet.

Ressources humaines
Membre du projet Ressources minimales recommandées Responsabilités spécifiques et commentaires
Responsable de test,
responsable de projet de test
1 (responsable du projet Système d'informations sportives par messagerie de poche) Offre une vision du projet en termes de gestion.

Responsabilités :

  • Apporter une orientation technique
  • Acquérir les ressources appropriées
  • Produire les rapports de gestion
Concepteur de test 1 Identifie, donne une priorité et implémente les cas de test.

Responsabilités :

  • Générer le plan de test
  • Générer le modèle de test
  • Evaluer l'efficacité des efforts de test
Testeur 4 (fournis par ActuWebEnligne) Exécute les tests.

Responsabilités :

  • Exécuter les tests
  • Consigner les résultats
  • Réparer les erreurs
  • Documenter les demandes de changement
Administrateur système de test 1 Garantit que l'environnement de test et les ressources sont gérées et conservées.

Responsabilités :

  • Administrer le système de gestion de test
  • Installer et gérer l'accès des membres du projet aux systèmes de test
Responsable de la base de données/de l'administration de la base de données 1 (fourni par ActuWebEnligne) Garantit que l'environnement de test (base de données) et les ressources sont gérées et conservées.

Responsabilités :

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

Responsabilités :

  • Identifier et définir la (les) classe(s) de test
  • Identifier et définir les packages de test
Implémenteur 4 Implémente et procède au test unitaire des classes de test et des packages de test.

Responsabilités :

  • Créer les classes et les packages de test implémentés dans le modèle de test

Système

Le tableau suivant indique les ressources système pour le projet de test.

Les éléments spécifiques du système de test ne sont pas entièrement connus à ce stade. Il est recommandé que le système simule l'environnement de production, en réduisant les accès et les tailles de base de donnés, le cas échéant et à l'endroit approprié.

Ressources système
Ressource Nom de la ressource et type de ressource
Serveur de base de données  
Réseau/Sous-réseau A déterminer
Nom de serveur A déterminer
Nom de la base de données A déterminer
PC de test client  
Inclure une configuration spéciale
-exigences
A déterminer
Référentiel de test  
Réseau/Sous-réseau A déterminer
Nom de serveur A déterminer
PC de développement de test A déterminer

Jalons du projetDébut de page

  Tâche de jalon   Effort Date de début Date de fin
  Planification du test        
  Conception du test        
  Implémentation du test        
  Exécution du test        
  Evaluation du test        

Livrables Début de  page

Modèle de test

Pour chaque test exécuté, un formulaire de résultat de test sera créé. Il indiquera le nom ou l'ID du test, le cas d'utilisation ou la spécification supplémentaire auquel (à laquelle) le test se réfère, la date du test, l'ID du testeur, les conditions de prétest requises et les résultats du test.

Journaux de test

Le logiciel Microsoft Word sera utilisé pour enregistrer et générer les résultats de test.

Rapports sur les incidents

Les incidents seront enregistrés via le Web, avec le logiciel Project HomePage.

Annexe A : tâches du projetDébut de page

Le tableau suivant répertorie les tâches de test associées.

Planification du test
Identification des exigences de test
Evaluation des risques
Elaboration de la stratégie de test
Identification des ressources de test
Création du calendrier
Génération du plan de test
Conception du test
Analyse de la charge de travail
Identification et description des cas de test
Identification et structuration des procédures de test
Revue et accès à la couverture de test
Implémentation du test
Enregistrement et programmation des scripts de test
Identification des fonctionnalités spécifiques au test dans les modèles de conception et d'implémentation
Définition des ensembles de données externes
Exécution du test
Exécution des procédures de test
Evaluation de l'exécution du test
Récupération après l'arrêt du test
Vérification des résultats
Analyse des résultats inattendus
Consignation des incidents
Evaluation du test
Evaluation de la couverture des cas d'essai
Evaluation de la couverture du code
Analyse des incidents
Détermination si les critères de fin de test et de réussite sont satisfaits

 

 

Copyright  1987 - 2003 Rational Software Corporation