Internet Data Center : Élaboration de vos procédures de test
Sur cette page
.gif){kind=icon}
Microsoft Internet Data Center : Élaboration de vos procédures de test
Résumé
Introduction
À qui s'adresse ce chapitre ?
Méthodologie de test Internet Data Center
Présentation du cycle de test
Étape 1 : Création du plan de référence de test
Étape 2 : Plans détaillés de test de conception
Étape 3 : Scénarios détaillés de tests de conception
Étape 4 : Versionnement
Étape 5 : Exécution des tests de conception
Étape 6 : Tri
Étape 7 : Résolution des bogues de conception
Étape 8 : Génération des rapports de test
Étape 9 : Révision de publication
Types de test
Rôles et responsabilités
Gestion du processus de test
Planification de projet
Listage des dépendances
Attribution de priorités
Surveillance des tendances des bogues
Affectation de niveaux de gravité aux bogues
Évaluation des risques liés au projet
Outils
Élaboration des plans et des scénarios de test
Création d'un plan de référence de test
Création d'un plan détaillé de test
Élaboration des scénarios détaillés de tests
Création du plan Versionnement et tri
Processus de suivi des bogues
Processus de tri
Processus de contrôle des modifications
Création du planning de test
Processus de rapports et de publication
Rapports de résultats
Publication pour production
Critères de réussite/échec aux tests
Critères de suspension de test pour l'échec du Test d'acceptation de version et de l'exécution des tests
Exigences pour les reprise des tests
Critères de publication pour production
Résumé
Microsoft Internet Data Center : Élaboration de vos procédures de test
Cet article est tiré du Guide de référence Internet Data Center
Résumé
Ce chapitre décrit les procédures à suivre lors des tests d'une implémentation de Microsoft® Internet Data Center. Il décrit également comment gérer le processus de test et vous propose des critères de publication, des outils et des documents clés à utiliser pour vos tests.
Introduction
Ce chapitre traite de la stratégie proposée pour tester une implémentation de la conception de Microsoft® Internet Data Center. Il commence par une présentation des objectifs des tests et des critères de publication proposés. Il présente également la méthodologie et les procédures de test génériques pouvant être appliquées pour tester l'implémentation.
À qui s'adresse ce chapitre ?
Ce chapitre est destiné aux personnes chargées de tester le déploiement, notamment le responsable des tests et les ingénieurs de tests. Il ne doit cependant pas être utilisé pour remplacer un responsable de test expérimenté. Il est essentiel que le test soit effectué par des professionnels avertis.
Méthodologie de test Internet Data Center
Le but du test de l'implémentation Internet Data Center est de prévoir dans quelle mesure l'architecture remplira vos objectifs de haute disponibilité, de sécurité, d'évolutivité et de gestion dans des conditions de production. Cette section présente une méthodologie utile pour vérifier une implémentation spécifique de l'architecture Internet Data Center. Vous ne pourrez déterminer si l'architecture satisfait à tous vos objectifs de conception qu'après avoir effectué soigneusement les tests et après en avoir analysé les résultats, conformément aux plannings de test.
Présentation du cycle de test
Le cycle de test consiste en différentes étapes, comme indiqué à la Figure 1.
.gif)
Figure 1. Étapes du cycle de test
Les sections suivantes décrivent les différentes étapes de test décrites dans le diagramme.
Étape 1 : Création du plan de référence de test
Cette première étape consiste à définir et à documenter les objectifs des tests dans un Plan de référence (PR). Ce plan de référence documente les éléments suivants :
Suppositions avancées pour les tests
Étendue des tests
Priorités des tests
Niveau de test à exécuter
Rôles et responsabilités
Ressources nécessaires
Estimation des délais
Dépendances
Attentes
Risques et compromis
Plan de contrôle de modifications
Le PR évolue tout au long du cycle de test. Le contenu de ce document est créé à partir du document de spécifications fonctionnelles et du planning de publication finale.
À ce stade, un plan Versionnement et tri est également généré. Celui-ci documente le processus de création, le processus de tri, les personnes impliquées dans ces processus, ainsi que leurs rôles et leurs responsabilités.
Pour plus d'informations, reportez-vous à la section "Création du Plan de versionnement et de tri" plus loin dans ce chapitre.
Étape 2 : Plans détaillés de test de conception
Pour les projets à grande échelle ou les projets complexes, des plans détaillés de test (PDT) sont créés à partir du plan de référence pour les différents domaines devant faire l'objet de tests. Pour les projets de moindre envergure, ces PDT peuvent être inclus dans le plan de référence.
Les plans détaillés de test, tout comme le plan de référence, se basent sur les spécifications fonctionnelles et autres documents de conception de haut niveau. À chaque scénario, d'un PDT est attribuée une priorité définie en fonction de la probabilité du scénario et de ses conséquences pour l'entreprise. Les différentes parties des PDT reflètent l'organisation du groupe de test, le niveau de disponibilité des différents composants du système ou le domaine d'application.
Les domaines suivants ont été identifiés pour le test de l'architecture Internet Data Center :
Réseau
Gestion
Disponibilité
Évolutivité
Sécurité
Performances
Étape 3 : Scénarios détaillés de tests de conception
Chacun des tests présents dans les Plans détaillés de test est converti en un scénario de test, ou plus, afin de créer des documents Scénarios détaillés de test (SDT). Ces scénarios de test répertorient les étapes détaillées, les données requises pour procéder aux tests, les résultats attendus et les méthodes d'enregistrement des résultats des tests.
Pour plus d'informations sur les scénarios de test, reportez-vous à "Élaboration des plans et des scénarios de test" plus loin dans ce chapitre.
Étape 4 : Versionnement
Une fois que la conception est terminée et que l'application ou l'infrastructure est prête à être testée, l'ingénieur système commence le processus de versionnement. Il crée une version basée sur la conception de l'architecture et la transmet à l'équipe de test. Le processus de versionnement comprend le déploiement de la conception en suivant, étape par étape, tous les documents d'implémentation. Il n'est pas rare qu'un ingénieur de test travaille avec l'ingénieur système pour documenter les problèmes susceptibles d'apparaître lors d'un déploiement. C'est là une bonne opportunité de découvrir des scénarios de test qui n'ont pas été inclus dans le plan de test initial.
Pour l'architecture Internet Data Center, les tests peuvent être approximativement divisés en deux types :
Tests d'implémentation
Tests de conception
Les tests d'implémentation sont effectués lors du déploiement sur l'environnement en se conformant aux guides de procédures. Toutes les erreurs possibles, étapes manquantes et exceptions détectées au cours du déploiement en labo sont identifiés et enregistrés. À la fin des tests d'implémentation, une version est considérée comme étant prête à passer les tests de conception.
Les tests de conception ne commencent que lorsqu'une version est prête et que l'environnement est déployé. Ils ont pour objectif de démontrer les capacités de l'ensemble de l'architecture du système. Ils comprennent les tests de performances et de gestion, ce qui implique l'observation, de bout en bout, des réponses du système à différents modèles d'usage extrême. Cet ensemble de tests est essentiel pour comprendre les caractéristiques du système actuellement utilisé de manière à pouvoir concevoir les processus de gestion les plus efficaces pour supporter cette implémentation spécifique.
Étape 5 : Exécution des tests de conception
À la fin du processus de versionnement, un Test de vérification de version (BVT) est exécuté avant de transmettre la version pour qu'elle soit testée. Une fois le BVT réussi, l'équipe de test procède à un Test d'acceptation de version (BAT), ou test du feu, afin de vérifier que la version est assez stable pour poursuivre les tests. Ces deux tests sont souvent combinés en une seule opération.
Si les tests BAT sont positifs, l'équipe de test accepte la version et commence les tests de conception.
Les tests de conception commencent par les différents tests documentés dans les DTC. Ces tests sont exécutés sur chaque version principale et les résultats sont enregistrés et vérifiés. Tout écart avec les résultats attendus est documenté et suivi à l'aide d'un outil de suivi des bogues.
Étape 6 : Tri
Des réunions de tri sont régulièrement tenues afin d'étudier les bogues signalés par l'équipe de test. Pendant cette vérification, chaque bogue reçoit une priorité et est attribué à un membre de l'équipe de développement. L'équipe discute ensuite des solutions possibles à chaque bogue.
Étape 7 : Résolution des bogues de conception
L'équipe de développement résout les bogues de conception signalés par l'équipe de test. Une fois que l'équipe de développement a résolu ces bogues, ils sont retournés au membre de l'équipe de test qui les a ouverts. L'équipe de test effectue ensuite de nouveaux tests de l'implémentation et ferme chaque bogue résolu par l'équipe de développement. Une fois que tous les bogues sont résolus, une nouvelle version est créée et sera retestée.
Pour plus d'informations sur la résolution des problèmes, reportez-vous à la section "Création du Plan de versionnement et de tri" plus loin dans ce chapitre.
Étape 8 : Génération des rapports de test
Une fois que l'équipe de test a terminé les tests, un rapport de test est préparé afin de répertorier des bogues ouverts et de résumer les performances du système, les éléments découverts en matière de gestion de système et les procédures suggérées. Les bogues sont listés en fonction de leur priorité. Ce rapport de test met également en valeur les conséquences pour l'entreprise si les bogues ne sont pas résolus et l'équipe de test donne son avis quant au passage ou non à l'étape de production.
Pour plus d'informations sur les rapports de test, reportez-vous à "Processus de rapports et de publication" plus loin dans ce chapitre.
Étape 9 : Révision de publication
Lors de la Révision de publication, les équipes de développement, de test et de programmation se concertent pour savoir si l'implémentation doit être publiée. Si cette révision réussit, le produit est mis en production. Dans le cas contraire, les problèmes restants sont revus et résolus.
Pour plus d'informations sur la révision de publication, reportez-vous à "Processus de rapports et de publication" plus loin dans ce chapitre.
Types de test
L'équipe de test effectue les types de test suivants :
Test de sécurité.Les tests de sécurité de l'application sont effectués afin de garantir que seuls les utilisateurs possédant les droit appropriés peuvent utiliser les fonctions applicables du système. L'ingénieur du système met en place différents paramètres de sécurité pour chaque utilisateur de l'environnement de test. Les tests de sécurité réseau sont effectués afin de garantir que le réseau est sûr et sécurisé par rapport aux utilisateurs non autorisés. Le responsable des tests doit prendre en compte les compétences du personnel de test en matière de piratage et se demander si son équipe est capable de répondre à un certain nombre de défis. Il est souvent recommandé de faire appel à des spécialistes externes de test de sécurité, dont la spécialité est les tests de sécurité complets.
Test d'installation ou de mise à niveau. Les tests d'installation ou de mise à niveau implique le test de la routine d'installation ou de mise à niveau pour garantir que le produit peut être créé. L'équipe de test décide s'il faut implémenter des versions complètes ou incrémentielles. Le processus de versionnement assure généralement la réussite des tests d'installation ou de mise à niveau.
Test du réseau. Les tests de réseau déterminent le comportement de l'ensemble de l'infrastructure réseau en cas d'application de divers temps de latence réseau. De tels tests peuvent permettre de découvrir des problèmes de liaisons réseau lentes, etc. Les éléments d'infrastructure suivants peuvent être testés pendant les tests de réseau dans l'architecture Internet Data Center :
disponibilité du réseau ;
redondance de l'équipement ;
basculement de cluster ;
topologie incorporée ;
fonction NIC Teaming ;
fonctionnalité double port.
Test de sauvegarde et restauration. Ce test est exécuté pour aider le support de production à garantir que les procédures adéquates sont en place pour restaurer le système en cas de problème grave.
Test de la mémoire. Ce test est effectué pour assurer que l'application s'exécutera en utilisant la quantité de mémoire spécifiée dans la documentation technique. Il doit aussi détecter les fuites de mémoire consécutives aux démarrages et aux arrêts fréquents de l'application.
Tests de performances. Ce test est nécessaire à toute implémentation Internet Data Center commerciale pour comprendre les capacités du système et son comportement en situation de surcharge. Une fois que les capacités de chaque serveur sont connues, l'architecte peut prendre les décisions finales sur le nombre de serveurs de chaque type effectivement nécessaire pour supporter la charge. Comprendre le comportement du système dans des conditions de charge anormales permet à l'architecte de décider s'il est plus important de créer un système permettant de supporter des augmentations de trafic fortes et temporaires ou s'il est préférable de prendre des mesures administratives.
Test d'évolutivité.L'évolutivité mesure la facilité de l'extension de l'infrastructure. Ces tests permettent de garantir que l'infrastructure est évolutive sous différentes conditions et qu'elle est conçue pour répondre aux besoins de croissance d'un site. Les tests d'évolutivité doivent être effectués sur l'architecture IDC afin d'assurer que les serveurs Web frontaux, l'infrastructure et les composants de données peuvent être mis à l'échelle.
Test de disponibilité.Ces tests permettent d'assurer que les clusters Network Load Balancing et Microsoft SQL Server™ sont disponibles à l'utilisateur dans différentes conditions. Les tests de disponibilité doivent être exécutés sur l'architecture Internet Data Center pour garantir que les clusters de serveurs Network Load Balancing et le cluster SQL Server du réseau VLAN de données sont disponibles dans différentes conditions
Test de stabilité. Ce test a pour but de garantir que le système est stable lorsqu'il subit des tests de charge prolongés.
Test de gestion.Ce test est effectué pour démontrer que le réseau peut être géré pour l'utilisation des mécanismes de surveillance et d'alertes et pour la gestion de contenu. Lors des tests de l'architecture IDC, les procédures suivantes sont testées :
Surveillance de tous les ordinateurs Microsoft Internet Information Services (IIS), COM, Active Directory™ directory service et SQL Server
Surveillance des informations de matériel sur différents serveurs de l'architecture
Surveillance de l'usage de l'UC et de la mémoire
Surveillance des connexions aux groupes de serveurs Web sur le réseau VLAN de la zone DMZ
Surveillance des connexions aux réseaux VLAN du groupe de stockage
Surveillance des authentifications effectuées sur les serveurs Active Directory
Surveillance de la disponibilité des nœuds sur le cluster SQL Server
Surveillance de l'utilisation du réseau au niveau de la carte réseau (NIC)
Alertes en cas de dépassement de l'un des seuils sur l'un des éléments susmentionnés
Déploiement du contenu Web
Déploiement des composants COM et des applications
Déploiement dans les réseaux VLAN du groupe de stockage
Seuls certains tests spécifiques ont été répertoriés ici. L'équipe de test doit documenter tous les cas de test spécifiques à l'application déployée sur l'architecture Internet Data Center.
Elle doit décider du niveau de test requis dans chacun de ces domaines. Chaque domaine peut être classé en fonction des niveaux suivants d'importance :
Élevée : domaine très important, devant être testé de manière approfondie
Moyenne : tests standard requis
Faible : test si le temps le permet
Rôles et responsabilités
Les rôles courants pouvant être requis dans une équipe de test d'architecture Internet Data Center, sont décrits dans le tableau ci-dessous, ainsi que les responsabilités correspondantes :
Rôle |
Responsabilité |
Responsable |
|
Ingénieur de test |
|
Ingénieur système |
|
Tableau 1. Rôles et responsabilités
Remarque : Dans la plupart des entreprises, l'ingénieur système est membre de l'équipe de développement ou de support produit plutôt que de l'équipe de test.
Gestion du processus de test
Cette section étudie certains des éléments requis pour réussir la gestion du processus de test.
Planification de projet
Le planning global de test est créé en fonction des tests planifiés et de l'effort requis.
Listage des dépendances
Certains des facteurs susceptibles d'affecter l'effort de test comprennent :
Spécifications fonctionnelles
Diagrammes d'architecture
Documents de conception
Dates des versions
Ressources en matériel et en personnel
Modifications de la portée fonctionnelle
Il est essentiel d'identifier et de répertorier toutes les dépendances afin d'assurer un test correct et dans les délais de l'application et de l'architecture.
Attribution de priorités
Les plans de test et les scénarios de test doivent être classifiés comme étant d'importance haute, moyenne ou faible. Dans le cas de délais courts pour l'exécution des tests, cela permet de décider quel tests scénarios de test doivent être exécutés et lesquels peuvent être ignorés.
Surveillance des tendances des bogues
Il est important de surveiller les tendances des bogues lorsque vous commencez les tests. Dans le meilleur des cas, le nombre de bogues doit baisser avec chaque nouvelle version Lorsque le nombre de bogues ouverts est suffisamment bas et que tous les bogues graves ont été résolus, il est temps de déterminer si l'application/infrastructure peut passer à l'étape marché/production (voir "Critères de publication en production" plus loin dans ce chapitre).
Affectation de niveaux de gravité aux bogues
Le tableau suivant répertorie les directives à suivre pour attribuer un niveau de gravité aux bogues.
Gravité |
Types les plus courants |
Conditions requises |
1 |
|
Le système ne fonctionne pas. L'utilisateur ne peut même pas utiliser les principaux éléments du système. |
2 |
|
La gravité est 2 si les conditions suivantes sont vraies :
La gravité est 3 si ces conditions ne sont pas respectées. |
3 |
|
La gravité est 3 si les conditions suivantes sont vraies :
La gravité est 2 si ces conditions ne sont pas respectées. |
4 |
|
À l'évidence, pas de bogue de produit pour cette version. |
Tableau 2. Directives en matière de gravité
Évaluation des risques liés au projet
Un risque est la probabilité d'un événement susceptible de mettre le système en péril. Pour évaluer les risques, l'équipe de test peut préparer une matrice identifiant les risques et affecter l'un des facteurs d'exposition suivants à chaque risque :
Probabilité de perte. La probabilité du risque. En général, trois niveaux de probabilité suffisent. Par exemple, "Peu probable" (moins de 50%), "Possible" (50%) et "Très probable" (plus de 50%).
Volume de perte. L'impact sur le planning du projet lorsque l'événement associé au risque se produit. Ici encore, trois niveaux sont suffisants : "Négligeable", "Menace pour les délais" et "Conséquences graves pour les délais".
Plan de contingence. Plan de réaction en fonction des circonstances du risque. Il peut s'agir d'ajouter des jours au planning pour atteindre les objectifs, d'ajouter du personnel et des ressources ou de modifier le produit final.
Le tableau suivant répertorie certains des risques rencontrés lors des tests de projet et les plans de contingence possibles.
Risque |
Plan de contingence |
Retard dans la phase de développement. |
Déterminer vos capacités à commencer les premiers tests en parallèle aux dernières étapes du développement et ajouter des ressources aux équipes de test et de développement. |
Les testeurs connaissent mal l'application. |
Ajouter des jours au planning afin de former les testeurs de l'application. |
Les applications se basent sur des technologies nouvelles. |
Il peut y avoir des retards inattendus pour cette raison. Le planning doit être flexible. |
De nouvelles exigences apparaissent. |
L'étendue du projet peut augmenter de manière imprévue en raison de l'évolution de ces exigences. Le planning doit être flexible pour faire face à ces risques. |
Table 3. Risques courants et plans de contingence
Outils
Les outils suivants doivent être utilisés dans le processus de gestion des tests :
Outil de suivi des bogues. Un bon outil de suivi des bogues doit être utilisé pour enregistrer des informations sur les bogues découverts lors des tests. Il doit permettre d'affecter le bogue à une personne et fournir un mécanisme de workflow pour le résoudre et le fermer.
Outil de gestion de scénario de test. Un outil de gestion de scénario de test sert à documenter les scénarios de test, à regrouper des scénarios de test réussis, à enregistrer les résultats de chaque réussite et à tenir à jour un historique des scénarios de test.
Outil de test automatique. Les outils de tests automatiques sont utilisés pour enregistrer les séquences de test et les reconstituer pour déterminer les raison de leur échec ou de leur réussite.
Élaboration des plans et des scénarios de test
Cette section décrit les différents plans et scénarios de test qui doivent être créés lors des tests de l'architecture Internet Data Center.
Création d'un plan de référence de test
Comme nous l'avons vu dans "Présentation du cycle de test" précédemment dans ce chapitre, un Plan de référence de test comprenant tous les domaines requis pour les tests est indispensable.
Création d'un plan détaillé de test
L'un des objectifs de l'équipe de test est de créer des Plans détaillés de test couvrant les principaux domaines requis pour tester l'application et l'architecture IDC sur laquelle elle doit fonctionner. Tout document de plan détaillé de test doit généralement comprendre les objectifs du scénario, la description du scénario, son niveau de priorité et la référence au document associé au scénario. Dans de nombreux projets, le contenu des PDT peut être ajouté au MTP afin d'obtenir un document unique, plus simple à gérer.
Élaboration des scénarios détaillés de tests
Les éléments devant être entrés dans un document Scénarios détaillés de tests sont notamment : le numéro de référence unique du scénario dans le DTP, sa priorité, la description du cas à tester, les détails de l'exécution, les données nécessaires pour effectuer le test, les résultats attendus, les résultats réels et l'état du test. Si les testeurs manquent d'expérience, il est essentiel que les scénarios soient assez détaillés pour leur permettre de mener leurs tâches à bien. Si les testeurs sont expérimentés, il est possible de simplifier les détails d'exécution des scénarios de tests.
Création du plan Versionnement et tri
Cette section décrit le contenu du plan de tests Versionnement et tri. Le principal objectif de cette section est de définir le processus de suivi des bogues utilisé pour faciliter les rapports de bogues et pour établir un plan pour les réunions de tri et le processus de contrôle des modifications pour l'architecture IDC. Cette section se concentre sur les éléments suivants :
Processus de suivi des bogues
Processus de tri
Processus de contrôle des modifications
Processus de modification des documents
La dernière section traite des éléments qui régissent la création d'un planning de test.
Processus de suivi des bogues
Vous pouvez utiliser tout outil de suivi des bogues pour enregistrer les bogues pendant la phase d'implémentation. Des autorisations spécifiques d'accès à l'outil de suivi doivent être fournis à chaque membre de l'équipe de test. Durant les tests, chaque membre de l'équipe doit pouvoir enregistrer les bogues qu'il découvre. Pour maintenir un bon niveau de contrôle sur l'état des bogues, seuls le responsable de test, l'équipe de test ou les chefs de projet doivent posséder les droits permettant de les fermer.
Les bogues peuvent se trouver dans la documentation, les procédures et d'autres domaines en plus du système lui-même. Tous les problèmes de système ou d'infrastructure de support doivent être consignés dans le système de suivi des bogues pour être résolus. Le système de suivi des bogues devient la "Liste des tâches" de l'équipe et peut être utilisé pour estimer rapidement l'état du projet.
Un testeur enregistre les bogues dans le système de suivi avec une description distinctive et des informations claires. Tous les bogues doivent contenir au minimum les informations suivantes :
les messages d'erreur (consignés tels qu'ils apparaissent à l'écran ou dans les fichiers journaux) ;
le numéro de la version où le bogue a été trouvé ;
les étapes exactes, permettant de reproduire le bogue ;
un résumé de la configuration spécifique ou des facteurs environnementaux lors du test.
Il est également possible d'ajouter une proposition de résolution si le testeur connaît une solution possible.
Après que les développeurs ont résolu un bogue, ils changent son état de Ouvert à Résolu. S'ils ne pensent pas qu'un bogue doit être résolu, ils changent son état en Double, Voulu, Pas de repro ou Pas de réso. Les bogues qui ne sont plus répertoriés en tant que Ouvert ou Actif doivent recevoir une résolution finale par l'équipe de test. La liste suivante donne des exemples de résolution d'un bogue par l'équipe de test à l'aide de l'outil de suivi :
Les bogues dont le champ de Résolution contient la mention Résolu sont retournés à la personne qui les a détectés afin qu'elle effectue un test régressif sur la nouvelle version.
Les bogues dont le champ de Résolution contient la mention Double, Voulu, Pas de repro ou Pas de réso (ce qui signifie qu'ils ne nécessitent pas de correction) sont fermés par l'équipe de test si elle est d'accord avec cette résolution.
Si l'équipe de test n'accepte pas la résolution, elle passe le champ Affecter à à Actif et décide de réactiver ou non le bogue lors de la réunion de tri. Si le test régressif du bogue échoue, le bogue est réactivé en changeant son État à Actif. Tous les bogues actifs sont revus lors de la réunion de tri.
Processus de tri
Le responsable des tests planifie et prépare la réunion de tri. Cette réunion doit avoir lieu régulièrement, généralement trois fois par semaine, lors de la première étape puis chaque jour au fur et à mesure de l'approche du délai imparti pour les tests. Tous les bogues actifs dans le système de suivi sont examinés pendant la réunion de tri et sont affectés à un membre compétent du groupe pour qu'il le traite. En général, une réunion de tri comprend les personnes suivantes :
Chef de projet
Responsable de test
Responsable de développement
D'autres membres des équipes peuvent assister à la réunion afin de discuter de différents problèmes techniques, le cas échéant.
Les étapes typiques lors d'une réunion de tri et après la réunion sont :
Le responsable de test discute de chaque nouveau bogue enregistré dans le système de suivi.
Le responsable de test décrit le bogue enregistré.
Les membres du groupe s'accordent sur une description du problème.
La gravité du bogue est examinée. Étant donné que la gravité du bogue est liée à la fonctionnalité fourni par le système, elle ne doit pas être redéfinie lors des réunions de tri, à moins qu'un groupe de décision se rassemble pour définir des modifications de la fonctionnalité fournie par le système.
Une priorité est attribuée au bogue (haute/moyenne/basse) en fonction de la gravité, de la disponibilité des développeurs et d'autres facteurs.
Le bogue et un plan d'action conçu pour faciliter sa résolution sont affectés à la personne compétente pour résoudre le bogue.
Le responsable de test met à jour le système de suivi en fonction des décisions prises pendantla réunion de tri.
La personne à laquelle le bogue a été affecté travaille à sa résolution et met à jour les détails de la résolution dans le système de suivi des bogues.
Les testeurs effectuent une procédure de régression sur les bogues résolus.
Si le test est réussi, les documents sont mis à jour en fonction du processus de contrôle des modifications et le bogue est fermé. Sinon, il est réactivé pour être de nouveau traité.
Processus de contrôle des modifications
Il est essentiel d'établir un processus de contrôle des modifications afin de suivre les modifications dans la documentation des directives. Pendant la préparation des tests, l'équipe de test met au point les scénarios de test en fonction des directives prescrites. Toute déviation des directives est suivie par le processus de contrôle des modifications.
Le processus de contrôle des modifications comprend les étapes suivantes :
Toute personne peut émettre une demande de modification. La demande de modification comprend les informations suivantes :
Description de la modification
Justification de la modification
Effort requis pour effectuer la modification (temps et ressources)
Toute demande de modification est consignée dans le système de suivi des bogues et discutée dans les réunions de tri.
Si une demande de modification est acceptée, elle reçoit une priorité et est assignée à une personne pour analyse de ses conséquences.
En fonction de l'analyse de ses conséquences, la demande de modification est approuvée ou rejetée, le planning du projet est actualisé et la tâche est affectée au personnel compétent.
Le processus de modification de document est ensuite suivi afin d'intégrer la demande de modification.
Création du planning de test
Le planning de test décrit la séquence des tâches que l'équipe de test doit suivre pour accomplir les tâches de test identifiées. Il fait généralement partie du document du plan de test (plan de référence, plan détaillé ou les deux) ou est ajouté au planning et référencé dans le document du plan de test. Le planning définit aussi clairement les tâches et les affectent au personnel compétent. Le planning de test est revu et les jalons du projet suivis lors des réunions de test hebdomadaires. Toute déviation du planning nécessite une concertation immédiate, pendant laquelle le responsable de test présente les choix possibles pour résoudre le problème.
Processus de rapports et de publication
Cette section traite les détails des deux dernières phases du processus de test : les rapports et la publication pour production.
Rapports de résultats
Une fois que l'équipe de test a terminé, avec succès, les scénarios de test requis, un rapport de test est rédigé afin de répertorier les bogues encore ouverts. Le rapport de test final est appelé rapport de "Publication pour production." Il décrit les domaines qui ont été testés et fournit un résumé des résultats des tests. Il répertorie également les bogues ou les problèmes devant être résolus dans les futures versions. Ce rapport indique également les conséquences pour l'entreprise, si les bogues restants ne sont pas corrigés ainsi que des recommandations quant à la poursuite ou non du processus de production. Ce rapport est enfin présenté à l'équipe de gestion du projet pour qu'elle puisse déterminer si le produit peut être publié pour production ou si le produit doit être corrigé.
Publication pour production
Une fois que l'équipe de gestion du projet a reçu le rapport Publication pour production, les parties concernées (équipes de développement, de test et de gestion de programme) se concertent afin de décider si le projet doit passer à l'étape de production.
Si les équipes déterminent que le produit remplit toutes les exigences du projet, il peut être publié pour production. Dans le cas contraire, les problèmes identifiés sont revus et corrigés suivant le processus de tri et de résolution décrit précédemment.
La liste suivante décrit différents critères devant être pris en compte afin de décider si l'implémentation peut être publiée.
Critères de réussite/échec aux tests
Un scénario de test est réussi si les résultats effectifs correspondent aux résultats attendus. Si les résultats effectifs ne correspondent pas aux résultats attendus, le scénario test est considéré comme ayant échoué.
Dans ce cas, la fonction n'est cependant pas considérée comme défectueuse. Par exemple, une mauvaise interprétation de la documentation du projet, un oubli ou une erreur dans la documentation peuvent provoquer des échecs. Chaque échec est analysé afin de déterminer sa cause, en se basant sur les résultats effectifs et les résultats décrits dans la documentation du projet.
Les critères de réussite sont :
Tous les processus ont été exécutés sans erreur inattendue.
Tous les processus sont exécutés dans un laps de temps acceptable, selon les critères de réussite définis dans les spécifications fonctionnelles.
Les tests de charge indiquent un niveau satisfaisant de capacités et que les procédures adéquates de mise à l'échelle du système peuvent être entreprises dès que nécessaire.
Critères de suspension de test pour l'échec du Test d'acceptation de version et de l'exécution des tests
L'équipe de test peut suspendre partiellement ou complètement les activités de test dans l'une des situations suivantes :
L'ingénieur système ne parvient pas à installer la nouvelle version ou un composant.
L'ingénieur système ne parvient pas à configurer la nouvelle version ou un composant.
Une fonction majeure présente un défaut empêchant de tester un domaine important du système.
L'environnement de test n'est pas assez stable pour que les résultats des tests soient fiables.
L'environnement de test est très différent le l'environnement de production prévu et les résultats des tests ne peuvent être considérés comme fiables.
Exigences pour les reprise des tests
L'équipe de test peut reprendre les tests si :
Le problème ayant provoqué la suspension des tests a été corrigé.
Les équipes de développement et de test décident qu'il n'est pas nécessaire de résoudre le bogue immédiatement et qu'il pourra être repris dans la version suivante.
Critères de publication pour production
Les critères de publication dépendent de la gravité des bogues ouverts. Comme nous l'avons vu précédemment, ces critères sont répartis sur une échelle de 1 à 4, le niveau de gravité 1 étant le plus élevé et le niveau 4 le plus bas.
Vous trouverez ci-après des critères de publication possibles pour décider de transmettre le système à la production :
Il ne reste aucun bogue de gravité 1 ou 2.
Les scénarios de test prévus pour les phases d'intégration et de test de système ont été exécutés avec succès (en particulier les scénarios de test concernant des fonctionnalités importantes ou des tests dont la priorité est haute ou moyenne).
Le test final de régression a réussi.
Remarque : les critères de publication varient non seulement en fonction de l'architecture mais aussi en fonction de la nature de l'application exécutée sur l'architecture Internet Data Center.
Résumé
Ce chapitre a présenté les stratégies de test d'une implémentation de l'architecture IDC, y compris les objectifs des tests, les critères de publication, les procédures de test génériques et les méthodologies. Nous avons voulu que ces informations restent générales et orientées sur les processus afin que vous puissiez les appliquer à vos propres scénarios.
Les informations contenues dans ce document représentent l'opinion actuelle de Microsoft Corporation sur les points soulevés au moment de la publication. Microsoft s'adapte aux conditions fluctuantes du marché et cette opinion ne doit pas être interprétée comme un engagement de la part de Microsoft ; de plus, Microsoft ne peut pas garantir la véracité de toute information présentée après la date de publication.
Ce livre blanc est fourni pour information uniquement. MICROSOFT N'OFFRE AUCUNE GARANTIE, EXPRESSE OU IMPLICITE, QUANT AUX INFORMATIONS CONTENUES DANS CE DOCUMENT.
L'utilisateur est tenu d'observer les réglementations relatives aux droits d'auteur applicables dans son pays. Sans restriction des droits dérivés des droits d'auteur, aucune partie de ce document ne peut être reproduite, stockée ou introduite dans un système de récupération de données ou transmise à quelque fin ou par quelque moyen que ce soit (électronique, mécanique, photocopie, enregistrement ou autre) ou dans quelque but que ce soit sans la permission expresse et écrite de Microsoft Corporation.
Les produits mentionnés dans ce document peuvent être couverts par des brevets, des dépôts de brevets en cours, des marques, des droits d'auteur ou d'autres droits de propriété intellectuelle et industrielle de Microsoft. Sauf indication expresse figurant dans un contrat de licence écrit émanant de Microsoft, la fourniture de ce document ne vous concède aucune licence sur ces brevets, marques, droits d'auteur ou autres droits de propriété intellectuelle.
Sauf mention contraire, les exemples de sociétés, organisations, produits, noms de domaines, adresses électroniques, logos, personnes et événements décrits ici relèvent de la fiction, et aucun lien avec une société, organisation, produit, nom de domaine, adresse électronique, logo, personne ou événement réel n'en peut être déduit.
Microsoft, Windows, Active Directory et BizTalk sont soit des marques de Microsoft Corporation, soit des marques déposées de Microsoft Corporation aux États-Unis d'Amérique et/ou dans d'autres pays.
Les noms de sociétés et de produits mentionnés sont des marques de leurs propriétaires respectifs.
Dernière mise à jour le vendredi 1 mars 2002
Pour en savoir plus