Les bases de données et les processus de bases de données doivent être testés comme sous-système indépendant. Ce test
doit évaluer les sous-systèmes sans que l'interface utilisateur de la cible de test soit l'interface vers les données.
Des recherches supplémentaires dans le système de gestion de base de données (DBMS) doivent être effectuées pour
identifier les outils et les techniques qui peuvent exister afin de prendre en charge le test indiqué dans le tableau
suivant.
Objectif de la technique :
|
Exercez les méthodes d'accès et les traitements des bases de données indépendants de l'IU, de façon à
ce que vous puissiez observer et journaliser un comportement cible défaillant ou la corruption de
données.
|
Technique :
|
Appelez chaque méthode d'accès et traitement de base de données, en recherchant les données valides et
invalides ou les demandes de données dans chacune d'elles.
Inspectez la base de données pour vous assurer que les données ont été renseignées comme prévu et que
tous les événements de base de données se sont produits correctement, ou examinez les données
retournées pour vous assurer que les données correctes ont été récupérées pour les bonnes raisons.
|
Oracles :
|
Exposez une ou plusieurs stratégies qui peuvent être utilisées par la technique pour observer de façon
précise les résultats du test. L'oracle combine des éléments de la méthode par laquelle l'observation
peut se faire ainsi que des caractéristiques du résultat spécifique qui indiquent une réussite ou un
échec probable. Dans l'idéal, les oracles s'auto-vérifieront, permettant aux tests automatisés de faire
une première évaluation de la réussite ou de l'échec du test ; cependant, veillez à mitiger les risques
inhérents à la détermination des résultats automatisée.
|
Outils nécessaires :
|
La technique nécessite les outils suivants :
Outil d'automatisation des scripts de test
Système d'imagerie et de restauration de la configuration de la base
Outils de sauvegarde et de récupération
Outils de surveillance de l'installation (registre, disque dur, UC, mémoire, etc.)
Utilitaires et outils SQL de base de données
Outils de génération de données
|
Critères de réussite :
|
La technique prend en charge le test de toutes les méthodes d'accès et tous les traitements de bases de
données clés.
|
Considérations particulières :
|
Le test peut nécessiter un environnement de développement de système de gestion de base de données
(DBMS) ou des lecteurs pour entrer ou modifier des données directement dans la base de données.
Les traitements doivent être appelés manuellement.
Les bases de données de petite taille ou de taille minimale (avec un nombre d'entrées limité) doivent
être utilisées pour augmenter la visibilité de tout événement non acceptable.
|
Le test des fonctions de la cible de test doit se concentrer sur toute exigence de test qui peut être tracée
directement vers des cas d'utilisation ou des fonctions commerciales et des règles métier. Les objectifs de ces tests
sont de vérifier une acceptation, un traitement et une récupération corrects des données, ainsi qu'une implémentation
appropriée des règles métier. Ce type de test est basé sur des techniques de boîte noire ; à savoir, vérifier
l'application et ses traitements internes en agissant avec l'application via l'interface graphique et en analysant les
résultats. Le tableau suivant donne un aperçu du test recommandé pour chaque application.
Objectif de la technique :
|
Exercez la fonctionnalité de la cible de test, y compris la navigation, l'entrée de données, le
traitement et la récupération pour observer et journaliser le comportement cible.
|
Technique :
|
Exercez les flux ou fonctions et caractéristiques des cas d'utilisation individuels du scénario de
chaque cas d'utilisation, en utilisant des données valides et invalides, afin de vérifier que :
les résultats attendus se produisent lorsque des données valides sont utilisées
les messages d'erreur ou d'avertissement appropriés s'affichent lorsque des données invalides sont
utilisées
chaque règle métier est appliquée correctement
|
Oracles :
|
Exposez une ou plusieurs stratégies qui peuvent être utilisées par la technique pour observer de façon
précise les résultats du test. L'oracle combine des éléments de la méthode par laquelle l'observation
peut se faire ainsi que des caractéristiques du résultat spécifique qui indiquent une réussite ou un
échec probable. Dans l'idéal, les oracles s'auto-vérifieront, permettant aux tests automatisés de faire
une première évaluation de la réussite ou de l'échec du test ; cependant, veillez à mitiger les risques
inhérents à la détermination des résultats automatisée.
|
Outils nécessaires :
|
La technique nécessite les outils suivants :
Outil d'automatisation des scripts de test
Système d'imagerie et de restauration de la configuration de la base
Outils de sauvegarde et de récupération
Outils de surveillance de l'installation (registre, disque dur, UC, mémoire, etc.)
Outils de génération de données
|
Critères de réussite :
|
La technique prend en charge le test de :
tous les scénarios de cas d'utilisation clés
toutes les fonctions clés
|
Considérations particulières :
|
Identifiez ou décrivez les éléments ou problèmes (internes ou externes) qui ont un impact sur la mise
en oeuvre et l'exécution du test des fonctions.
|
Le test du cycle de travail doit émuler les tâches effectuées sur le <Nom du projet> au fil du temps. Une période
doit être identifiée, par exemple un an, et des transactions et tâches qui auraient lieu lors de cette période d'un an
doivent être exécutées. Ceci comprend tous les cycles quotidiens, hebdomadaires et mensuels, ainsi que les événements
qui changent en fonction de la date, comme les aide-mémoire.
Objectif de la technique :
|
Exercez des processus de cible de test et d'arrière-plan selon les modèles de travail et les
calendriers nécessaires afin d'observer et de journaliser le comportement cible.
|
Technique :
|
Le test simulera plusieurs cycles de travail en exécutant ce qui suit :
Les tests utilisés pour la fonction de cible de test seront modifiés ou améliorés afin d'augmenter le
nombre d'exécutions de chaque fonction pour simuler différents utilisateurs au cours d'une période
spécifique.
Toutes les fonctions qui changent selon l'heure ou la date seront exécutées en utilisant des dates ou
des périodes valides et invalides.
Toutes les fonctions se produisant régulièrement seront exécutées ou lancées au moment approprié.
Le test comprendra l'utilisation de données valides et invalides pour vérifier ce qui suit :
Les résultats attendus se produisent lorsque des données valides sont utilisées.
Les messages d'erreur ou d'avertissement appropriés s'affichent lorsque des données invalides sont
utilisées.
Chaque règle métier est appliquée correctement.
|
Oracles :
|
Exposez une ou plusieurs stratégies qui peuvent être utilisées par la technique pour observer de façon
précise les résultats du test. L'oracle combine des éléments de la méthode par laquelle l'observation
peut se faire ainsi que des caractéristiques du résultat spécifique qui indiquent une réussite ou un
échec probable. Dans l'idéal, les oracles s'auto-vérifieront, permettant aux tests automatisés de faire
une première évaluation de la réussite ou de l'échec du test ; cependant, veillez à mitiger les risques
inhérents à la détermination des résultats automatisée.
|
Outils nécessaires :
|
La technique nécessite les outils suivants :
Outil d'automatisation des scripts de test
Système d'imagerie et de restauration de la configuration de la base
Outils de sauvegarde et de récupération
Outils de génération de données
|
Critères de réussite :
|
La technique prend en charge le test de tous les cycles de travail essentiels.
|
Considérations particulières :
|
Les dates et les événements du système peuvent nécessiter des tâches de support particulières.
Un modèle commercial est nécessaire pour identifier les exigences et procédures de test appropriées.
|
Le test de l'interface permet de vérifier l'interaction d'un utilisateur avec le logiciel. L'objectif du test de
l'interface utilisateur est d'assurer que l'interface fournit l'accès et la navigation appropriés à l'utilisateur,
grâce aux fonctions de la cible de test. De plus, ce test 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é.
Objectif de la technique :
|
Exercez ce qui suit pour observer et journaliser la conformité aux normes et le comportement cible :
Navigation dans la cible de test reflétant les fonctions et exigences commerciales, y compris le
fenêtre-à-fenêtre, le champ-à-champ et l'utilisation des méthodes d'accès (touches de tabulation,
mouvements de la souris, les raccourcis-clavier).
Les objets et caractéristiques des fenêtres peuvent être utilisés comme les menus, la taille, la
position, l'état et la cible.
|
Technique :
|
Créez ou modifiez des tests pour chaque fenêtre afin de vérifier la bonne navigation et les états des
objets pour chaque fenêtre d'application et chaque objet.
|
Oracles :
|
Exposez une ou plusieurs stratégies qui peuvent être utilisées par la technique pour observer de façon
précise les résultats du test. L'oracle combine des éléments de la méthode par laquelle l'observation
peut se faire ainsi que des caractéristiques du résultat spécifique qui indiquent une réussite ou un
échec probable. Dans l'idéal, les oracles s'auto-vérifieront, permettant aux tests automatisés de faire
une première évaluation de la réussite ou de l'échec du test ; cependant, veillez à mitiger les risques
inhérents à la détermination des résultats automatisée.
|
Outils nécessaires :
|
La technique nécessite l'outil d'automatisation du script de test.
|
Critères de réussite :
|
La technique prend en charge le test de chaque écran ou fenêtre majeur(e) qui sera utilisé(e) de façon
extensive par l'utilisateur.
|
Considérations particulières :
|
Toutes les propriétés de personnalisation et tous les objets tiers ne sont pas accessibles.
|
Le profilage des performances est un test des performances dans lequel les temps de réponse, les taux de transaction et
autres exigences qui changent en fonction de la date sont mesurés et évalués. L'objectif du profilage des performances
est de vérifier que les exigences de performance ont été satisfaites. Le profilage des performances est mis en oeuvre
et exécuté afin d'établir le profil et d'accorder le comportement de la cible de test en matière de performance comme
fonction de conditions, tel que les configurations de charge de travail ou de matériel.
Remarque: les transactions du tableau suivant font référence à des "transactions commerciales logiques". Ces
transactions se définissent comme des cas d'utilisation spécifiques qu'un acteur du système doit exécuter en utilisant
la cible de test, comme par exemple ajouter ou modifier un contrat donné.
Objectif de la technique :
|
Exercez des comportements pour des transactions fonctionnelles désignées ou des fonctions commerciales
selon les conditions suivantes afin d'observer et de journaliser un comportement cible et des données
sur la performance d'une application :
charge de travail normale prévue
charge de travail maximale prévue
|
Technique :
|
Utilisez les procédures de test élaborées pour le test de fonction ou de cycle de travail.
Modifiez les fichiers de données pour augmenter le nombre de transactions ou les scripts pour augmenter
le nombre d'itérations qui se produisent dans chaque transaction.
Les scripts doivent être exécutés sur une seule machine (le mieux est d'évaluer les performances d'un
seul utilisateur, une seule transaction) et doivent être répétés avec plusieurs clients (virtuels ou
réels, voir les Conditions particulières ci-dessous).
|
Oracles :
|
Exposez une ou plusieurs stratégies qui peuvent être utilisées par la technique pour observer de façon
précise les résultats du test. L'oracle combine des éléments de la méthode par laquelle l'observation
peut se faire ainsi que des caractéristiques du résultat spécifique qui indiquent une réussite ou un
échec probable. Dans l'idéal, les oracles s'auto-vérifieront, permettant aux tests automatisés de faire
une première évaluation de la réussite ou de l'échec du test ; cependant, veillez à mitiger les risques
inhérents à la détermination des résultats automatisée.
|
Outils nécessaires :
|
La technique nécessite les outils suivants :
Outil d'automatisation des scripts de test
Un outil de profilage des performances de l'application, comme par exemple Rational Quantify
Outils de surveillance de l'installation (registre, disque dur, UC, mémoire, etc.)
Outils de restriction de ressources ; par exemple, Canned Heat
|
Critères de réussite :
|
La technique prend en charge le test de :
Transaction simple ou utilisateur simple : Emulation réussie des scripts de transaction sans échec en
raison de problèmes de mise en oeuvre du test.
Transactions multiples ou utilisateurs multiples : Emulation réussie de la charge de travail sans échec
en raison de problèmes de mise en oeuvre du test.
|
Considérations particulières :
|
Le test complet des performances implique d'avoir une charge de travail en arrière-plan sur le serveur.
Plusieurs méthodes peuvent être utilisées pour effectuer ceci, dont :
"Effectuer les transactions" directement vers le serveur, en général sous forme d'appels en langage SQL
(Structured Query Language).
Créez une charge utilisateur "virtuelle" pour simuler de nombreux clients, en général plusieurs
centaines. Les outils d'émulation de terminal distant sont utilisés pour accomplir cette charge. Cette
technique peut également être utilisée pour charger le réseau de "trafic".
Utilisez plusieurs clients physiques, chacun exécutant des scripts de test, pour placer une charge sur
le système.
Le test des performances doit être effectué sur une machine donnée ou à un moment donné. Ceci permet un
contrôle total et une mesure précise.
Les bases de données utilisées pour le test des performances doivent être de taille réelle ou à une
échelle égale.
|
Le test de la charge est un test des performances qui soumet la cible de test à diverses charges de travail afin de
mesurer et d'évaluer les comportements et les capacités en matière de performance de la cible de test pour continuer à
fonctionner correctement selon ces différentes charges de travail. L'objectif du test de la charge est de déterminer si
et d'assurer que le système fonctionne correctement au-delà de la charge de travail maximale prévue. De plus, le test
de la charge évalue les caractéristiques de performance, telles que les temps de réponse, les taux de transaction et
d'autres questions qui varient en fonction du temps.
Remarque: les transactions du tableau suivant font référence à des "transactions commerciales logiques". Ces
transactions se définissent comme des fonctions spécifiques qu'un utilisateur du système doit exécuter en utilisant
l'application, comme par exemple ajouter ou modifier un contrat donné.
Objectif de la technique :
|
Exercez des transactions désignées ou des études de rentabilité sous diverses conditions de charge de
travail afin d'observer et de journaliser le comportement cible et les données de performance du
système.
|
Technique :
|
Utilisez les scripts de test de transaction élaborés pour le test des fonctions ou des cycles de
travail comme base, mais n'oubliez pas de retirer les interactions et délais non nécessaires.
Modifiez les fichiers de données pour augmenter le nombre de transactions ou les tests pour augmenter
le nombre d'occurrences de chaque transaction.
Les charges de travail doivent inclure - par exemple, des charges quotidiennes, hebdomadaires et
mensuelles.
Les charges de travail doivent représenter les charges moyenne et maximale.
Les charges de travail doivent représenter les périodes de pointe instantanées et soutenues.
Les charges de travail doivent être exécutées sous différentes configurations d'environnement de test.
|
Oracles :
|
Exposez une ou plusieurs stratégies qui peuvent être utilisées par la technique pour observer de façon
précise les résultats du test. L'oracle combine des éléments de la méthode par laquelle l'observation
peut se faire ainsi que des caractéristiques du résultat spécifique qui indiquent une réussite ou un
échec probable. Dans l'idéal, les oracles s'auto-vérifieront, permettant aux tests automatisés de faire
une première évaluation de la réussite ou de l'échec du test ; cependant, veillez à mitiger les risques
inhérents à la détermination des résultats automatisée.
|
Outils nécessaires :
|
La technique nécessite les outils suivants :
Outil d'automatisation des scripts de test
Outil de contrôle et de programmation de la charge de transactions
Outils de surveillance de l'installation (registre, disque dur, UC, mémoire, etc.)
Outils de restriction de ressources ; par exemple, Canned Heat
Outils de génération de données
|
Critères de réussite :
|
La technique prend en charge le test de l'émulation de la charge de travail, qui est l'émulation
réussie de la charge de travail sans échec en raison de problèmes de mise en oeuvre du test.
|
Considérations particulières :
|
Le test de la charge doit être effectué sur une machine donnée ou à un moment donné. Ceci permet un
contrôle total et une mesure précise.
Les bases de données utilisées pour le test de la charge doivent être de taille réelle ou à une échelle
égale.
|
Le test sous contraintes est un type de test des performances mis en oeuvre et exécuté afin de comprendre les échecs
d'un système en raison de conditions à la limite ou en dehors des tolérances prévues. Ceci implique généralement de
faibles ressources ou une concurrence des ressources. Les conditions de faibles ressources révèlent les échecs de la
cible de test, ce qui n'est pas apparent dans des conditions normales. D'autres défauts peuvent se produire suite à la
concurrence entre les ressources partagées, comme des verrouillages de bases de données ou une bande passante de
réseau, bien que certains de ces tests soient généralement traités sous les tests fonctionnels et de charge.
Remarque: les références aux transactions dans le tableau suivant concernent des transactions commerciales
logiques.
Objectif de la technique :
|
Exercez les fonctions de la cible de test conformément aux conditions de test sous contraintes
suivantes afin d'observer et de journaliser le comportement cible qui identifie et documente les
conditions sous lesquelles le système échoue et ne continue pas à fonctionner correctement :
peu ou pas de mémoire disponible sur le serveur (espace de stockage RAM et permanent)
nombre maximal réel ou physiquement possible de clients connectés ou simulés
utilisateurs multiples effectuant les mêmes transactions par rapport aux mêmes données ou comptes
volume de transaction "de surcharge" ou combinaison (voir Profilage des performances ci-dessus)
|
Technique :
|
Utilisez les tests élaborés pour le profilage des performances ou le test de la charge.
Pour évaluer des ressources limitées, les tests doivent être effectués sur une seule machine et
l'espace de stockage RAM et permanent sur le serveur doit être réduit ou limité.
Pour les tests sous contraintes restant, utilisez plusieurs clients, soit sur les mêmes tests soit sur
des tests complémentaires afin de produire le volume ou la combinaison de transactions reflétant le
pire cas.
|
Oracles :
|
Exposez une ou plusieurs stratégies qui peuvent être utilisées par la technique pour observer de façon
précise les résultats du test. L'oracle combine des éléments de la méthode par laquelle l'observation
peut se faire ainsi que des caractéristiques du résultat spécifique qui indiquent une réussite ou un
échec probable. Dans l'idéal, les oracles s'auto-vérifieront, permettant aux tests automatisés de faire
une première évaluation de la réussite ou de l'échec du test ; cependant, veillez à mitiger les risques
inhérents à la détermination des résultats automatisée.
|
Outils nécessaires :
|
La technique nécessite les outils suivants :
Outil d'automatisation des scripts de test
Outil de contrôle et de programmation de la charge de transactions
Outils de surveillance de l'installation (registre, disque dur, UC, mémoire, etc.)
Outils de restriction de ressources ; par exemple, Canned Heat
Outils de génération de données
|
Critères de réussite :
|
La technique prend en charge le test de l'émulation sous contraintes. Le système peut être émulé dans
une ou plusieurs conditions définies comme conditions de contrainte, et une observation de l'état du
système en conséquence, pendant et une fois que la condition a été émulée, peut être capturée.
|
Considérations particulières :
|
Insister sur le réseau peut nécessiter des outils réseau pour charger des messages ou paquets sur le
réseau.
Le stockage permanent utilisé pour le système doit être temporairement réduit pour restreindre l'espace
disponible afin de permettre à la base de données de s'agrandir.
Synchronisez l'accès des clients simultanés aux mêmes enregistrements ou comptes de données.
|
Le test du volume soumet la cible de test à grandes quantités de données pour déterminer si les limites sont atteintes
et provoqueront l'échec du logiciel. Le test du volume permet également d'identifier la charge ou le volume maximum
continu que la cible de test peut gérer sur une période donnée. Par exemple, si la cible de test traite un ensemble
d'entrées de base de données afin de générer un rapport, un test de volume utilisera une base de données de test
importante, puis vérifiera que le logiciel s'est comporté normalement et a généré le bon rapport.
Objectif de la technique :
|
Exercez les fonctions de la cible de test conformément aux scénarios de volume important suivants afin
d'observer et de journaliser le comportement cible :
Nombre maximal (réel ou physiquement possible) de clients connectés, ou simulés, exécutant tous la même
fonction commerciale (en matière de performance) dans le pire cas sur une période prolongée.
La taille maximale de la base de données a été atteinte (réelle ou à l'échelle) et plusieurs requêtes
ou transactions de rapport sont exécutées simultanément.
|
Technique :
|
Utilisez les tests élaborés pour le profilage des performances ou le test de la charge.
Utilisez plusieurs clients, soit sur les mêmes tests soit sur des tests complémentaires, afin de
produire le volume ou la combinaison de transactions reflétant le pire cas (voir Test sous contraintes)
sur une période prolongée.
Une taille maximale de base de données est créée (réelle, à l'échelle ou remplie de données
représentatives) et plusieurs clients sont utilisés afin d'exécuter des requêtes et des transactions de
rapport simultanément sur des périodes prolongées.
|
Oracles :
|
Exposez une ou plusieurs stratégies qui peuvent être utilisées par la technique pour observer de façon
précise les résultats du test. L'oracle combine des éléments de la méthode par laquelle l'observation
peut se faire ainsi que des caractéristiques du résultat spécifique qui indiquent une réussite ou un
échec probable. Dans l'idéal, les oracles s'auto-vérifieront, permettant aux tests automatisés de faire
une première évaluation de la réussite ou de l'échec du test ; cependant, veillez à mitiger les risques
inhérents à la détermination des résultats automatisée.
|
Outils nécessaires :
|
La technique nécessite les outils suivants :
Outil d'automatisation des scripts de test
Outil de contrôle et de programmation de la charge de transactions
Outils de surveillance de l'installation (registre, disque dur, UC, mémoire, etc.)
Outils de restriction de ressources ; par exemple, Canned Heat
Outils de génération de données
|
Critères de réussite :
|
La technique prend en charge le test de l'émulation de volume. De grandes quantités d'utilisateurs, de
données, de transactions ou d'autres aspects l'utilisation du système suivant le volume peuvent être
émulés, et une observation des changements d'état du système sur la durée du test du volume peut être
capturée.
|
Considérations particulières :
|
Quelle période serait considérée comme étant acceptable pour des conditions de volume important, tel
que décrit ci-dessus?
|
Le test de sécurité et du contrôle de l'accès se concentre sur deux domaines clés de la sécurité :
La sécurité au niveau de l'application, dont l'accès aux données ou fonctions commerciales
La sécurité au niveau du système, dont la connexion ou l'accès à distance au système
Selon la sécurité désirée, la sécurité au niveau de l'application assure que les acteurs sont restreints à des
fonctions ou cas d'utilisation spécifiques, ou les données qui leur sont disponibles sont limitées. Par exemple, tout
le monde peut être autorisé à entrer des données et créer de nouveaux comptes, mais seuls les managers peuvent les
supprimer. S'il y a une sécurité au niveau des données, le test assure que le "type d'utilisateur un" peut voir toutes
les informations relatives au client, y compris les données financières, cependant, le "type d'utilisateur deux" verra
uniquement les données démographiques pour le même client.
La sécurité au niveau du système assure que seuls les utilisateurs qui ont un droit d'accès au système peuvent accéder
aux applications et ceci uniquement par les portes appropriées.
Objectif de la technique :
|
Exercez la cible de test sous les conditions suivantes afin d'observer et de journaliser le
comportement cible :
La sécurité au niveau de l'application : un acteur peut accéder uniquement aux fonctions ou données
pour lesquelles son type d'utilisateur a l'autorisation.
La sécurité au niveau du système : seuls les acteurs qui ont accès au système et aux applications sont
autorisés à y accéder.
|
Technique :
|
Sécurité au niveau de l'application : Identifiez et dressez la liste de chaque type d'utilisateur et
des fonctions ou données pour lesquelles chaque type a les autorisations.
Créez des tests pour chaque type et vérifiez chaque autorisation en créant des transactions spécifiques
à chaque type d'utilisateur.
Modifiez un type d'utilisateur et exécutez à nouveau les tests pour les mêmes utilisateurs. Dans chaque
cas, vérifiez si ces fonctions ou données supplémentaires sont disponibles ou refusées.
Accès au niveau du système : voir les Considérations particulières ci-dessous.
|
Oracles :
|
Exposez une ou plusieurs stratégies qui peuvent être utilisées par la technique pour observer de façon
précise les résultats du test. L'oracle combine des éléments de la méthode par laquelle l'observation
peut se faire ainsi que des caractéristiques du résultat spécifique qui indiquent une réussite ou un
échec probable. Dans l'idéal, les oracles s'auto-vérifieront, permettant aux tests automatisés de faire
une première évaluation de la réussite ou de l'échec du test ; cependant, veillez à mitiger les risques
inhérents à la détermination des résultats automatisée.
|
Outils nécessaires :
|
La technique nécessite les outils suivants :
Outil d'automatisation des scripts de test
Outils d'enquête et de violation de sécurité "pirate"
Outils d'administration de la sécurité du SE
|
Critères de réussite :
|
La technique prend en charge le test des fonctions ou données appropriées affectées par des paramètres
de sécurité qui peuvent être testés pour chaque type d'acteur connu.
|
Considérations particulières :
|
L'accès au système doit être examiné ou discuté avec l'administrateur système ou réseau approprié. Ce
test ne sera peut-être pas nécessaire car ce peut être une fonction de l'administration du réseau ou
des systèmes.
|
Le test de basculement et de récupération assure que la cible de test peut subir un basculement et une récupération
réussis suite à des défaillances du matériel, du logiciel ou du réseau avec une perte importante de données ou de
l'intégrité des données.
Pour les systèmes qui doivent continuer de fonctionner, le test de basculement assure qu'en cas de condition de
basculement, les systèmes alternatifs ou de sauvegarde "remplacent" correctement le système en échec sans perte de
données ni de transactions.
Le test de récupération est un processus de test antagoniste dans lequel l'application ou le système est exposé(e) à
des conditions extrêmes ou des conditions simulées, pour provoquer un échec, tel que des échecs d'entrée/sortie (E/I)
de périphérique ou des pointeurs et clés de base de données invalides. Les processus de récupération sont appelés, et
l'application ou le système est surveillé et inspecté afin de vérifier que l'application ou le système fonctionne
correctement et que la récupération des données a réussi.
Objectif de la technique :
|
Simulez les conditions d'échec et exercez les processus de récupération (manuelle et automatisée) pour
restaurer la base de données, les applications et le système à un état connu et désiré. Les types de
conditions suivants sont compris dans le test afin d'observer et de journaliser le comportement après
la récupération :
interruption de courant sur le client
interruption de courant sur le serveur
interruption de communication via les serveurs du réseau
interruption, communication, ou perte de courant sur une unité de stockage à accès direct et sur les
contrôleurs d'unité de stockage à accès direct
cycles incomplets (processus de filtrage des données interrompus, processus de synchronisation des
données interrompu)
pointeurs ou clés de la base de données invalides
éléments de données invalides ou endommagés dans la base de données
|
Technique :
|
Les tests déjà créés pour le test des fonctions et des cycles de travail peuvent être utilisés comme
base pour la création d'une série de transactions afin de prendre en charge le test de basculement et
de récupération, principalement pour définir les tests à exécuter pour vérifier que la récupération a
réussi.
Interrupteur de courant sur le client : coupez l'alimentation du PC.
Interruption de courant sur le serveur : simulez ou initiez les procédures de coupure d'alimentation
pour le serveur.
Interruption via les serveurs du réseau : simulez ou initiez une perte de communication avec le réseau
(déconnectez physiquement les câbles de communication ou coupez l'alimentation des serveurs du réseau
ou des routeurs).
Interruption, communication, ou perte de courant sur une unité de stockage à accès direct et sur les
contrôleurs d'unité de stockage à accès direct : simulez ou éliminez physiquement la communication avec
un(e) ou plusieurs unités ou contrôleurs d'unités de stockage à accès direct.
Une fois que les conditions ci-dessus ou les conditions simulées sont achevées, des transactions
supplémentaires doivent être exécutées ; une fois ce deuxième état de point de test atteint, les
procédures de récupération doivent être appelées.
Le test des cycles incomplets utilise la même technique que celle expliquée ci-dessus, sauf que les
traitements de bases de données eux-mêmes doivent être abandonnés ou interrompus prématurément.
Le test des conditions suivantes nécessite qu'un état connu de base de données soit atteint. Plusieurs
champs, pointeurs et clés de base de données doivent être endommagés manuellement et directement dans
la base de données (via les outils de base de données). Des transactions supplémentaires doivent être
exécutées en utilisant les tests des fonctions d'application et des cycles de travail et des cycles
complets doivent être exécutés.
|
Oracles :
|
Exposez une ou plusieurs stratégies qui peuvent être utilisées par la technique pour observer de façon
précise les résultats du test. L'oracle combine des éléments de la méthode par laquelle l'observation
peut se faire ainsi que des caractéristiques du résultat spécifique qui indiquent une réussite ou un
échec probable. Dans l'idéal, les oracles s'auto-vérifieront, permettant aux tests automatisés de faire
une première évaluation de la réussite ou de l'échec du test ; cependant, veillez à mitiger les risques
inhérents à la détermination des résultats automatisée.
|
Outils nécessaires :
|
La technique nécessite les outils suivants :
Système d'imagerie et de restauration de la configuration de la base
Outils de surveillance de l'installation (registre, disque dur, UC, mémoire, etc.)
Outils de sauvegarde et de récupération
|
Critères de réussite :
|
La technique prend en charge le test de :
Un ou plusieurs incidents majeurs simulés impliquant une ou plusieurs combinaisons de l'application, de
la base de données ou du système.
Une ou plusieurs récupérations simulées impliquant une ou plusieurs combinaisons de l'application, de
la base de données et du système vers un état connu et désiré.
|
Considérations particulières :
|
Le test de récupération est très intrusif. Les procédures de déconnexion du câblage (en simulant une
perte de courant ou de communication) peuvent ne pas être désirables ou possibles. D'autres méthodes
peuvent être nécessaires, comme par exemple les outils logiciels de diagnostic.
Des ressources pour les systèmes (ou opérations informatiques), la base de données et les groupes de
réseau sont nécessaires.
Ces tests doivent être exécutés en dehors des heures de travail ou sur une machine isolée.
|
Le test de la configuration permet de vérifier le fonctionnement de la cible de test selon différentes configurations
de logiciel et de matériel. Dans la plupart des environnements de production, les spécifications particulières de
matériel pour les stations de travail clientes, les connexions au réseau et les serveurs de bases de données varient.
Les stations de travail clientes peuvent avoir différents logiciels installés (par exemple, des applications, des
lecteurs, etc.) et à tout moment, plusieurs combinaisons différentes peuvent être actives en utilisant différentes
ressources.
Objectif de la technique :
|
Exercez la cible de test sur les configurations de matériel et logiciel obligatoires afin d'observer et
de journaliser le comportement cible selon différentes configurations et identifier les changements
d'état de la configuration.
|
Technique :
|
Utilisez des scripts de test des fonctions.
Ouvrez et fermez plusieurs logiciels associés qui ne sont pas la cible de test, comme par exemple les
applications Microsoft® Excel® et Microsoft® Word®, dans le cadre du test ou avant de commencer le
test.
Exécutez les transactions sélectionnées pour simuler des acteurs agissant avec les logiciels de la
cible de test et ceux qui ne sont pas la cible de test.
Répétez le processus ci-dessus, en minimisant la mémoire traditionnelle disponible sur la station de
travail cliente.
|
Oracles :
|
Exposez une ou plusieurs stratégies qui peuvent être utilisées par la technique pour observer de façon
précise les résultats du test. L'oracle combine des éléments de la méthode par laquelle l'observation
peut se faire ainsi que des caractéristiques du résultat spécifique qui indiquent une réussite ou un
échec probable. Dans l'idéal, les oracles s'auto-vérifieront, permettant aux tests automatisés de faire
une première évaluation de la réussite ou de l'échec du test ; cependant, veillez à mitiger les risques
inhérents à la détermination des résultats automatisée.
|
Outils nécessaires :
|
La technique nécessite les outils suivants :
Système d'imagerie et de restauration de la configuration de la base
Outils de surveillance de l'installation (registre, disque dur, UC, mémoire, etc.)
|
Critères de réussite :
|
La technique prend en charge le test d'une ou plusieurs combinaisons des éléments du test cible qui
fonctionnent dans des environnements de déploiement prévus et pris en charge.
|
Considérations particulières :
|
Quel logiciel non cible de test est nécessaire, disponible et accessible sur le bureau ?
Quelles applications sont généralement utilisées ?
Quelles données les applications exécutent-elles ; par exemple, une grande feuille de calcul ouverte
dans Excel ou un document de 100 pages dans Word ?
L'ensemble du répertoire NDS, des serveurs du réseau, des bases de données, etc. doivent également être
documentés dans le cadre de ce test.
|
Le test de l'installation a deux objectifs. Le premier est d'assurer que le logiciel peut être installé sous
différentes conditions (comme par exemple une nouvelle installation, une mise à niveau et une installation complète ou
personnalisée) dans des conditions normales et anormales. Les conditions anormales comprennent un espace disque
insuffisant, un manque de privilège pour créer des répertoires, etc. Le deuxième objectif est de vérifier qu'une fois
installé, le logiciel fonctionne correctement. Ceci implique en général d'exécuter un certain nombre de tests élaborés
pour tester les fonctions.
Objectif de la technique :
|
Exercez l'installation de la cible de test sur chaque configuration matérielle nécessaire sous les
conditions suivantes afin d'observer et de journaliser les modifications de comportement et de l'état
de la configuration :
nouvelle installation : une nouvelle machine, sur laquelle <Nom du projet> n'a jamais été
installé
mise à jour : une machine sur laquelle <Nom du projet> a déjà été installé, même version
mise à jour : une machine sur laquelle <Nom du projet> a déjà été installé, une version
antérieure
|
Technique :
|
Développez des scripts automatisés ou manuels pour valider la condition de la machine cible.
nouveau : <Nom du projet> jamais installé
<Nom du projet> version identique ou antérieure déjà installée
Lancez ou exécutez l'installation.
En utilisant un sous-ensemble prédéterminé de scripts de test des fonctions, exécutez les transactions.
|
Oracles :
|
Exposez une ou plusieurs stratégies qui peuvent être utilisées par la technique pour observer de façon
précise les résultats du test. L'oracle combine des éléments de la méthode par laquelle l'observation
peut se faire ainsi que des caractéristiques du résultat spécifique qui indiquent une réussite ou un
échec probable. Dans l'idéal, les oracles s'auto-vérifieront, permettant aux tests automatisés de faire
une première évaluation de la réussite ou de l'échec du test ; cependant, veillez à mitiger les risques
inhérents à la détermination des résultats automatisée.
|
Outils nécessaires :
|
La technique nécessite les outils suivants :
Système d'imagerie et de restauration de la configuration de la base
Outils de surveillance de l'installation (registre, disque dur, UC, mémoire, etc.)
|
Critères de réussite :
|
La technique prend en charge le test de l'installation du produit développé dans une ou plusieurs
configurations d'installation.
|
Considérations particulières :
|
Quelles transactions <Nom du projet> doivent être sélectionnées pour comprendre un test de
confiance indiquant que l'application <Nom du projet> a bien été installée et qu'aucun composant
logiciel majeur ne manque ?
|
|