Instructions: Plan de test
Un plan de test doit couvrir les exigences, les risques, la priorité, la stratégie et les critères d'achèvement. Ces instructions décrivent en détail l'objectif et le contenu d'un plan de test.
Relations
Eléments connexes
Description principale

Généralités

L'objectif d'un plan de test est de communiquer l'intention des tâches de test. Il est essentiel que ce document soit créé le plus tôt possible. Il est en effet bienvenu d'établir cet artefact dès les premières itérations de la phase d'élaboration. Il est éventuellement souhaitable de développer le plan de test de façon itérative en ajoutant des sections au fur et à mesure que des informations sont disponibles.

Prenez soin d'expliquer clairement la portée du test, ainsi que ses exigences, ses stratégies et les besoins en ressources. Ces informations déterminent l'objectif et les limites de l'effort de test, ce qui sera testé, comme sera effectué le test et quelles ressources sont requises pour ce faire. Grâce à des informations précises, la revue, l'analyse et l'approbation de l'effort de test gagneront en rapidité.

En début de projet doit être créé un plan de test qui identifie l'ensemble du test à réaliser : il s'agit du plan de test maître. Comme chaque itération est planifiée, un plan de test d'itération plus précis est aussi créé (ou bien plusieurs plans de test organisés par type) et contient uniquement les données (exigences, stratégies, ressources, etc.) correspondant à l'itération en question. De la même façon, ces informations peuvent faire partie du plan d'itération si elles ne le rendent pas trop difficile à gérer ou à utiliser. 

Ci-après quelques instructions pour identifier et communiquer au mieux les exigences du test, les risques et priorités qu'il inclut, ainsi que ses stratégies.

Identification des exigences pour le test

Les exigences pour le test identifient ce qui sera testé. Elles sont donc spécifiques à la cible de test. Il existe des règles générales à appliquer lors de l'identification d'exigences pour un test :

  • L'exigence d'un test doit correspondre à un comportement observable et mesurable. Si tel n'est pas le cas, elle ne peut pas non plus être analysée pour savoir si elle a été satisfaite.
  • Il n'existe pas de relation un-à-un entre chaque cas d'utilisation ou exigence supplémentaire d'un système et une exigence de test. Les cas d'utilisation possèdent généralement plusieurs exigences de test, alors que certaines exigences supplémentaires donnent une ou plusieurs exigences de test et d'autres aucune (comme les exigences de marketing ou de packaging).

Les exigences de test proviennent de nombreuses sources, dont des cas d'utilisation, des modèles de cas d'utilisation, des spécifications supplémentaires, des exigences de conception, des études de rentabilité, des questionnaires soumis à des utilisateurs et le document d'architecture logicielle. Tous ces éléments doivent être consultés pour rassembler des informations servant à identifier les exigences de test.

Exigences pour des tests fonctionnels

Les exigences fonctionnelles sont, comme leur nom l'indique, issues de descriptions des comportements fonctionnels de la cible de test. Chaque cas d'utilisation doit au moins donner une exigence de test. Une liste plus détaillée d'exigences doit inclure au moins une exigence pour chaque flux d'événements du cas d'utilisation.

Exigences pour des tests de performances

Les exigences de performances s'inspirent des comportements de performances spécifiés pour la cible de test. En général, les performances sont indiquées comme une mesure du temps de réponse et/ou de l'utilisation des ressources dans plusieurs conditions, dont :

  • différentes charges de travail et/ou conditions système,
  • différents cas d'utilisation,
  • différentes configurations.

Les exigences de performances sont décrites dans les spécifications supplémentaires. Révisez ces données en prêtant notamment attention aux instructions qui incluent ce qui suit :

  • instructions de temps, comme le temps de réponse ou des profils temporels,
  • instructions indiquant un nombre d'événements ou de cas d'utilisation pouvant se produire dans une période de temps donnée,
  • instructions comparant le comportement d'un élément à celui d'un autre,
  • instructions comparant le comportement de l'application sur une configuration à celui d'une autre,
  • fiabilité opérationnelle (temps moyen pour un échec ou MTTF) sur une période de temps,
  • configurations ou contraintes.

Vous devez créer au moins une exigence de test pour chaque instruction dans la spécification qui mentionne des informations comme celles citées ci-dessus.

Exigences pour des tests de fiabilité

Les exigences de fiabilité proviennent de plusieurs sources généralement décrites dans les spécifications supplémentaires, les instructions sur l'interface utilisateur, les instructions de conception et les instructions de programmation.

Révisez ces produits et prêtez notamment attention aux instructions incluant ce qui suit :

  • instructions de fiabilité pour les échecs et les erreurs d'exécution (par exemple, fuites de mémoire),
  • instructions indiquant l'intégrité et la structure du code (respect du langage et de la syntaxe),
  • instructions par rapport à l'utilisation des ressources.

Vous devez créer au moins une exigence de test pour chaque instruction dans les produits qui mentionnent les informations citées ci-dessus.

Pour qu'un test aboutisse, l'effort de test doit assurer l'équilibre entre des facteurs comme les contraintes et les risques liés aux ressources. Pour ce faire, accordez la priorité à l'effort de test afin que les composants ou les cas d'utilisation les plus risqués ou pertinents soient testés en premier. Pour donner la priorité à l'effort de test, vous devez évaluer les risques et établir un profil opérationnel, puis vous servir de ces données comme base pour la priorité de test.

Les sections suivantes expliquent comment établir la priorité de test.

Evaluation des risques et définition des priorités de test

L'identification des exigences de test n'est qu'une partie de la définition de la cible de test. Vous devez également accorder des priorités à ce qui sera testé et fixer l'ordre dans lequel le faire. Cette étape a lieu pour diverses raisons, dont celles ci-après :

  • vérifier que les efforts de test sont centrés sur les exigences les plus appropriées pour le test,
  • vérifier que les exigences les plus déterminantes ou risquées sont traitées le plus tôt possible,
  • vérifier que toutes les dépendances, comme une séquence ou des données, sont testées.

La procédure d'évaluation des risques et de définition des priorités de test comporte trois étapes :

Vous trouverez ci-après des instructions pour chaque étape.

Evaluer le risque

La définition de la priorité de test passe d'abord par l'évaluation du risque. Les cas d'utilisation et les composants supposant un risque majeur en raison d'un échec ou risquant d'échouer doivent faire partie des premiers testés.

Commencez par identifier et décrire les indicateurs de l'ampleur du risque qui seront utilisés, comme suit :

  • E - risque élevé et intolérable. Exposition externe grave. L'entreprise subira d'importantes pertes financières, endossera des responsabilités ou connaîtra une atteinte irrémédiable à sa réputation.
  • M - risque moyen, tolérable mais non souhaitable. Exposition externe minimale. L'entreprise peut connaître des pertes financières, mais sa responsabilité est limitée, tout comme l'atteinte à sa réputation.
  • F - risque faible et tolérable. Peu ou pas d'exposition externe. L'entreprise connaît peu ou pas de pertes financières, pas plus que des responsabilités. Sa réputation n'est pas altérée.

Après avoir identifié les indicateurs de l'ampleur du risque, répertoriez chaque cas d'utilisation ou composant dans la cible de test. Pour chaque entrée de la liste, identifiez un indicateur de l'ampleur du risque et justifiez la valeur choisie (brève instruction).

Il existe trois perspectives pouvant servir à évaluer un risque :

  • Effet - impact ou conséquence d'un cas d'utilisation précis (exigence, etc.) qui échoue.
  • Cause - résultat indésirable produit par l'échec d'un cas d'utilisation et examen des causes possibles
  • Probabilité - probabilité d'échec d'un cas d'utilisation.

Sélectionnez une perspective, identifiez un indicateur de l'ampleur du risque et justifiez votre choix. Il est inutile d'identifier un indicateur pour chaque perspective de risque. Toutefois, dans le cas d'un indicateur de risque faible, il est conseillé d'évaluer l'élément depuis une autre perspective pour s'assurer que le risque est vraiment faible.

Ci-après plus de détails sur l'évaluation du risque selon ces trois perspectives.

Effet

Pour évaluer un risque par rapport à l'effet, identifiez une condition, un événement ou une action et tentez de déterminer son impact. Demandez-vous :

"Que se passe-t-il si ___________ ?"

Par exemple :

  • "Que se passe-t-il si l'espace disque est insuffisant au moment d'installer le nouveau logiciel ?"
  • "Que se passe-t-il si la connexion à Internet s'interrompt lors d'une transaction d'interrogation ?"
  • "Que se passe-t-il si la connexion à Internet s'interrompt lors d'une transaction d'achat ?"
  • "Que se passe-t-il si l'utilisateur entre une valeur inattendue ?"

Ci-après un exemple de matrice de justification pour ces éléments :

Description Facteur de limitation des risques Justification
Espace disque insuffisant au moment de l'installation E L'installation du logiciel procure à l'utilisateur la première impression sur le produit. Tout résultat indésirable comme ceux répertoriés ci-dessous altère le système de l'utilisateur et le logiciel installé, et crée une impression négative chez l'utilisateur :
  • le logiciel est partiellement installé (certains fichiers, certaines entrées du registre), ce qui le rend impossible à utiliser ;
  • l'installation s'arrête en laissant le système inutilisable.
Connexion à Internet perdue pendant l'interrogation F Les données et la base de données ne sont pas endommagées si la connexion est interrompue. Il est prouvé qu'une connexion perdue peut donner une impression négative à l'utilisateur.
Connexion à Internet perdue pendant l'achat E Toutes les connexions ou transactions perdues et entraînant les résultats ci-dessous sont inacceptables car elles supposent des coûts supplémentaires et une baisse des bénéfices :
  • base de données corrompue
  • commande partielle
  • données ou commandes partielles
  • commande multiples (répliquées)
Valeur imprévue entrée E Toutes les transactions entraînant les résultats ci-après sont inacceptables :
  • base de données corrompue
  • données erronées

Cause

L'évaluation du risque par rapport à la cause est l'opposé de celle reposant sur l'effet. Commencez par prendre un événement ou une condition inacceptable et identifiez la série d'événements ayant pu conduire à cette condition. Demandez-vous :

"Pourquoi ___________ s'est produit ?

Par exemple :

  • "Pourquoi quelques fichiers seulement ont-ils pu être copiés sur le système et que toutes les entrées du registre ne sont pas présentes ?"
  • "Pourquoi une transaction n'est-elle pas reflétée correctement dans la base de données centrale ?"
  • "Pourquoi l'instruction du cycle de facturation reflète-t-elle seulement quelques enregistrements dans la base de données répondant aux critères souhaités ?"

Ci-après un exemple de matrice de justification pour ces éléments :

Description Facteur de limitation des risques Justification
Fichiers d'application et entrées du registre manquants E L'application est inutilisable, ainsi que le système éventuellement. L'installation est la première chose que les utilisateurs voient d'une application. Si l'installation échoue pour une raison, l'opinion de l'utilisateur envers le logiciel n'est pas positive.

Causes possibles de cette condition :

  • le processus d'installation n'a pas installé tous les fichiers et mis correctement à jour le registre ;
  • le processus d'installation s'est arrêté suite à une intervention de l'utilisateur (annulation ou sortie) ;
  • le processus d'installation s'est arrêté pour une raison logicielle/matérielle (espace disque insuffisant, configuration non prise en charge, etc.) ;
  • le processus d'installation s'est arrêté en raison de conditions inconnues ;
  • l'utilisateur a supprimé des fichiers/des entrées du registre.

Parmi ces causes, seule la dernière ne peut être détectée et gérée par le processus d'installation.

Commande partielle E Les commandes partielles ne peuvent pas être exécutées, ce qui entraîne des gains moindres et la perte de clients.

Causes possibles :

  • connexion à Internet perdue en raison d'une action de l'utilisateur (déconnexion du modem, arrêt du PC, etc.) ;
  • connexion à Internet perdue en raison d'une erreur d'IP ;
  • connexion à Internet perdue en raison d'une action d'un employé (déconnexion du modem, arrêt des serveurs, etc.)
Corruption des données/de la base de données E Les données corrompues ne sont jamais tolérables.

Causes possibles :

  • la transaction écrivant dans la base de données ne s'est pas terminée ou n'a pas été validée en raison d'une intervention de l'utilisateur ;
  • la transaction écrivant dans la base de données ne s'est pas terminée ou n'a pas été validée en raison de l'interruption de la connexion à Internet ;
  • l'utilisateur entre des données non valides dans la transaction ;
  • les méthodes/utilitaires d'accès à la base de données ne fonctionnent pas ;
  • la base de données n'est pas correctement remplie (à son instanciation initiale).
Commandes en double E Les commandes en double augmentent la surcharge de l'entreprise et réduisent les bénéfices en raison des coûts associés à la livraison, à la manutention et au nouveau stockage.

Causes possibles :

  • la transaction écrivant la commande dans la base de données est en double en raison d'une intervention de l'utilisateur (il a passé deux fois la commande, pas de confirmation d'entrée) ;
  • la transaction écrivant la commande dans la base de données est en double en raison d'une intervention étrangère à l'utilisateur (processus de reprise après une connexion à Internet perdue, restauration de la base de données).
Données inexactes pour une commande E Toutes les commandes ne pouvant pas être exécutées ou entraînant des coûts supplémentaires sont inacceptables.

Causes possibles :

  • la transaction de commande ne s'est pas terminée ou n'a pas été validée en raison d'une intervention de l'utilisateur ;
  • la transaction de commande ne s'est pas terminée ou n'a pas été validée en raison de l'interruption de la connexion à Internet ;
  • l'utilisateur entre des données non valides.
Nombre incorrect d'enregistrements dans l'instruction E Les décisions commerciales et les comptes clients dépendent de la précision de ces rapports.

Causes possibles :

  • critères de recherche/sélection incorrects
  • instruction SQL incorrecte
  • données corrompues dans la base de données
  • données erronées dans la base de données

Probabilité

L'évaluation du risque par rapport à la probabilité consiste à déterminer la probabilité d'échec d'un cas d'utilisation ou d'un composant implémentant un cas d'utilisation. La probabilité repose généralement sur des facteurs externes comme suit :

  • taux d'échec
  • taux de modification
  • complexité
  • origine/auteur

Lorsque vous utilisez une perspective de risque, sachez que les indicateurs de l'ampleur du risque sont liés à la probabilité d'un échec, et non à l'effet ou à l'impact que l'échec peut avoir sur l'organisation, comme tel était le cas pour une évaluation en fonction de l'effet ou de la cause.

Il existe des corrélations entre ces facteurs et la probabilité d'un échec, comme ci-après :

Facteur externe Probabilité
Taux de découverte d'incidents
La probabilité d'un incident augmente avec la densité ou le taux de découverte d'incidents. Les incidents ont donc tendance à se cumuler : comme le taux de découverte ou le nombre d'incidents (densité) augmentent dans un cas d'utilisation ou un composant, la probabilité de trouver un autre incident augmente aussi. Les taux de découverte et la densité de versions antérieures doivent également être pris en compte lors de l'évaluation du risque selon ce facteur, sachant que les anciens taux de découverte et densités élevés révèlent une forte probabilité d'incidents supplémentaires.
Taux de modification La probabilité d'un incident augmente avec le taux de modification d'un cas d'utilisation ou d'un composant. Par conséquent, comme le nombre de changements augmente, la probabilité qu'une erreur ait été introduite est aussi supérieure. Chaque fois qu'une modification est apportée au code, il existe le risque d'introduction d'une autre erreur.
Complexité La probabilité d'un incident augmente avec la mesure de la complexité d'un cas d'utilisation ou d'un composant.
Origine/auteur Le fait de savoir d'où vient le code et qui l'a rédigé augmente ou réduit la probabilité d'un incident.
L'utilisation de composants tiers réduit en général la probabilité d'un incident. Toutefois, ce principe se vérifie uniquement si le composant tiers a été certifié (il répond à vos exigences, soit via un test formel, soit par la pratique).
La probabilité d'un incident diminue en général avec le savoir et les compétences accrues de l'implémenteur. Des facteurs comme l'utilisation de nouveaux outils, de nouvelles technologies ou le fait d'assumer plusieurs rôles peuvent cependant augmenter la probabilité d'un incident, même si les meilleurs membres d'une équipe sont impliqués.



Par exemple :

  • Installation du nouveau logiciel
  • "Nous avons généralement trouvé de nombreuses erreurs dans les composants employés pour implémenter les cas d'utilisation 1, 10 et 12 ; nos clients ont demandé un grand nombre de modifications pour les cas d'utilisation 14 et 19."

Ci-après un exemple de matrice de justification pour ces éléments :

Description Facteur de limitation des risques Justification
Installation du nouveau logiciel E Nous écrivons notre propre utilitaire d'installation.

L'application devient inutilisable. L'installation est la première chose que les utilisateurs voient d'une application. Si l'installation échoue pour une raison, l'opinion de l'utilisateur envers le logiciel n'est pas positive.

Installation du nouveau logiciel F Nous utilisons un utilitaire d'installation ayant fait ses preuves sur le marché.

Alors qu'une installation qui échoue rend l'application inutilisable, l'utilitaire d'installation sélectionné est celui d'un fournisseur ayant atteint la meilleure part de marché avec son produit et avec plus de quatre ans d'expérience. Notre évaluation indique que le produit répond à nos besoins et que les clients sont satisfaits du produit, du fournisseur et du niveau de service et de prise en charge.

Taux de découverte/densité d'incidents élevés dans les cas d'utilisation 1, 10 et 12. E En raison des taux de découverte et de la densité d'incidents élevés dans les cas d'utilisation 1, 10 et 12, ces cas sont considérés très risqués.
Demandes de changement pour les cas d'utilisation 14 et 19. E Un nombre important de changements dans ces cas d'utilisation augmente la probabilité d'introduire des erreurs dans le code.

Etablir le profil opérationnel

L'étape suivante pour évaluer le risque et définir la priorité du test consiste à déterminer le profil opérationnel de la cible de test.

Commencez par identifier et décrire les indicateurs de l'ampleur du profil opérationnel qui seront utilisés, comme suit :

  • E - utilisé assez fréquemment, souvent pendant une période de temps ou par de nombreux acteurs ou cas d'utilisation.
  • M - utilisé fréquemment, plusieurs fois pendant une période de temps ou par plusieurs acteurs ou cas d'utilisation.
  • L - utilisé rarement ou par quelques acteurs ou cas d'utilisation seulement.

L'indicateur de profil opérationnel sélectionné doit se baser sur la fréquence d'exécution d'un cas d'utilisation ou d'un composant, dont :

  • le nombre de fois qu'UN acteur (ou un cas d'utilisation) exécute le cas d'utilisation (ou le composant) dans une période de temps donnée ;
  • le nombre d'ACTEURS (ou de cas d'utilisation) qui exécutent le cas d'utilisation (ou composant).

En général, plus un cas d'utilisation ou un composant est souvent ajouté, plus l'indicateur de profil opérationnel est élevé.

Après avoir identifié les indicateurs de l'ampleur du profil opérationnel à utiliser, répertoriez chaque cas d'utilisation ou composant dans la cible de test. Choisissez un indicateur de profil opérationnel pour chaque élément de la liste et indiquez une justification pour la valeur de l'indicateur. Les informations du document d'analyse de la charge de travail (voir Produit : Document d'analyse de la charge de travail) peuvent être utilisées pour cette évaluation.

Exemples:

  • Installation du nouveau logiciel
  • Commandes d'articles dans le catalogue en ligne
  • Clients faisant le suivi de leur commande en ligne après l'avoir passée
  • Boîte de dialogue de sélection d'articles
Description Facteur de profil opérationnel Justification
Installation du nouveau logiciel E Une seule exécution (en général), mais de nombreux utilisateurs. Sans installation cependant, l'application est inutilisable.
Commande d'articles dans le catalogue E Il s'agit du cas d'utilisation le plus fréquent exécuté par les utilisateurs.
Clients faisant le suivi de leurs commandes F Quelques clients demandent des informations sur leurs commandes après les avoir effectuées.
Boîte de dialogue de sélection d'articles E Cette boîte de dialogue permet aux clients de passer des commandes et aux responsables du stock de réapprovisionner le stock.

Fixer la priorité de test

La dernière étape pour évaluer le risque et définir la priorité de test consiste à fixer cette priorité.

Commencez par identifier et décrire les indicateurs de l'ampleur de la priorité de test qui seront utilisés, comme suit :

  • E - à tester
  • M - doit être testé et le sera uniquement une fois tous les éléments E testés
  • L - peut être testé, mais pas tant que tous les éléments E et M ne l'ont pas été

Après avoir identifié les indicateurs de l'ampleur de la priorité de test à utiliser, répertoriez chaque cas d'utilisation ou composant dans la cible de test. Choisissez un indicateur de priorité de test pour chaque élément de la liste et indiquez une justification. Ci-après des instructions pour identifier un indicateur de priorité de test.

Prenez en compte ce qui suit au moment d'identifier les indicateurs de priorité de test pour chaque élément :

  • la valeur de l'indicateur de l'ampleur du risque identifiée plus tôt,
  • la valeur de l'ampleur du profil opérationnelle identifiée plus tôt,
  • les descriptions des acteurs (ont-ils de l'expérience ?, acceptent-ils les solutions de rechange ?, etc.)
  • obligations contractuelles (la cible de test sera-t-elle acceptable si un cas d'utilisation ou un composant n'est pas livré ?)

Stratégies possibles pour définir une priorité de test :

  • Prenez la valeur de facteur évaluée la plus élevée (risque, profil opérationnel, etc.) pour chaque élément comme priorité globale.
  • Identifiez un facteur évalué (risque, profil opérationnel ou autre) comme le plus pertinent et utilisez sa valeur comme priorité.
  • Utilisez une combinaison de facteurs évalués pour identifier la priorité.
  • Utilisez un schéma de pondération dans lequel des facteurs individuels sont pondérés et leurs valeurs et la priorité calculées en fonction du poids.

Exemples:

  • Installation du nouveau logiciel
  • Commandes d'articles dans le catalogue en ligne
  • Clients faisant le suivi de leur commande en ligne après l'avoir passée
  • Boîte de dialogue de sélection d'articles

Priorité lorsque la valeur évaluée la plus élevée est utilisée pour la définir :

Article Risque Profil opérationnel Acteur Contrat Priorité
Installation du nouveau logiciel E E F E E
Commande d'articles dans le catalogue E E E E E
Interrogations de clients F F F F F
Boîte de dialogue de sélection d'articles F E F F E

Priorité lorsque la valeur évaluée la plus élevée pour un facteur (risque) est utilisée pour la définir :

Article Risque Profil opérationnel Acteur Contrat Priorité
Installation du nouveau logiciel E E F E E
Commande d'articles dans le catalogue E E E E E
Interrogations de clients F F F F F
Boîte de dialogue de sélection d'articles F E F F F

Priorité lorsqu'une valeur de pondération est utilisée pour la calculer :

(Remarque : dans la matrice ci-dessous, E = 5, M = 3 et F = 1. Une valeur pondérée totale supérieure à 30 est une priorité élevée, des valeurs comprises entre 20 et 30 inclus correspondent à une priorité moyenne et des valeurs inférieures à 20 à une priorité faible).

Article Risque (x 3) Profil opérationnel (x 2) Acteur (x 1) Contrat (x 3) Valeur pondérée Priorité
Installation du nouveau logiciel 5 (15) 5 (10) 1 (1) 5 (15) 41 E (2)
Commande d'articles dans le catalogue 5 (15) 5 (10) 5 (5) 5 (15) 45 E (1)
Interrogations de clients 1 (3) 1 (2) 1 (1) 1 (3) 9 F (4)
Boîte de dialogue de sélection d'articles 1 (3) 5 (10) 1 (1) 1 (3) 17 F (3)

Stratégie de test

La stratégie de test décrit l'approche générale et les objectifs d'un effort de test spécifique.

Une bonne stratégie doit contenir les éléments suivants :

Type de test et objectif Haut de la page

Indiquez clairement le type de test à implémenter et son objectif. Cette précision explicite empêche la confusion et limite les malentendus (notamment car certains tests sont très similaires). L'objectif doit mentionner clairement pourquoi le test est exécuté.

Exemples:

"Test fonctionnel. Le test fonctionnel se centre sur l'exécution des cas d'utilisation suivants implémentés dans la cible de test à partir de l'interface utilisateur."

"Test de performances. Le test de performances pour le système s'attache à mesurer le temps de réponse pour les cas d'utilisation 2, 4 et 8 - 10. Pour ces tests, la charge de travail d'un acteur, exécutant ces cas d'utilisation sans autre charge de travail sur le système de test, sera employée."

"Test de configuration. Le test de configuration sera implémenté pour identifier et évaluer le comportement de la cible de test sur trois configurations distinctes, en comparant les caractéristiques des performances à notre configuration de référence."

Etape du test

Indiquez clairement l'étape à laquelle le test sera exécuté. Ci-après les étapes auxquelles des tests courants sont exécutés :

  Etape de test
Type de tests Unité Intégration Système Acceptation
Tests fonctionnels

(Configuration, Fonction, Installation, Sécurité, Volume)

X X X X
Tests de performances

(profils de performances de composants individuels)

X X (X)

facultatif ou quand les tests de performances du système révèlent des incidents

 
Tests de performances

(Charge, Sous contraintes, Contention)

    X X
Fiabilité

(Intégrité, Structure)

X X (X)

facultatif ou quand d'autres tests révèlent des incidents

 

Technique

La technique doit décrire comment le test sera implémenté et exécuté. Incluez ce qui sera testé, les principales actions à réaliser lors de l'exécution du test et la ou les méthodes employées pour évaluer les résultats.

Exemple :

Test fonctionnel :

  • Pour chaque flux d'événements du cas d'utilisation, un ensemble représentatif de transactions sera identifié, chacun illustrant les actions effectuées par l'acteur lorsque le cas d'utilisation est exécuté.
  • Au moins deux jeux d'essai seront développés pour chaque transaction : un pour refléter la condition positive et un autre pour refléter la condition négative (inacceptable).
  • Dans la première itération, les cas d'utilisation 1 - 4 et 12 seront testés comme suit :
    • Cas d'utilisation 1 :
      • Le cas d'utilisation 1 commence avec l'acteur déjà connecté dans l'application et dans la fenêtre principale ; il se termine lorsque l'utilisateur demande un enregistrement.
      • Chaque jeu d'essai sera implémenté et exécuté avec Rational Robot.
      • La vérification et l'évaluation de l'exécution de chaque jeu d'essai auront lieu avec les méthodes suivantes :
        • L'exécution du script de test : chaque test s'exécute-t-il avec succès et comme souhaité ?
        • Les méthodes de vérification de l'existence de fenêtre ou de données objet (implémentées dans les scripts de test) seront employées pour vérifier que les fenêtres clés s'affichent et que les données indiquées sont capturées/affichées par la cible de test lors de l'exécution.
        • La base de données de la cible de test (avec Microsoft Access) sera analysée avant le test et une autre fois après, afin de vérifier que les modifications apportées lors du test sont précisément reflétées dans les données.

Test de performances :

  • Pour chaque cas d'utilisation, un ensemble représentatif de transactions, tel qu'identifié dans le document d'analyse de la charge de travail, sera implémenté et exécuté avec Rational Suite PerformanceStudio (scripts vu) et Rational Robot (scripts de l'interface graphique).
  • Au moins trois charges de travail seront reflétées dans les scripts de test et les planifications d'exécution de tests, dont ce qui suit :
    • Charge de travail sous contraintes : 750 utilisateurs (15 % de responsables, 50 % d'employés de vente, 35 % d'employés en marketing)
    • Charge de travail maximum : 350 utilisateurs (10 % de responsables, 60 % d'employés des ventes, 30 % d'employés en marketing)
    • Charge de travail nominale : 150 utilisateurs (2 % de responsables, 75% d'employés des ventes, 23 % d'employés en marketing)
  • Les scripts de test utilisés pour exécuter chaque transaction incluront les temporisateurs appropriés pour capturer les temps de réponse, tels que le temps total de la transaction (comme défini dans le document d'analyse de la charge de travail) et la durée du processus ou de la tâche de transaction clé.
  • Les scripts de test exécuteront les charges de travail pendant une heure (sauf précision différente dans le document d'analyse de charge de travail).
  • La vérification et l'évaluation de l'exécution de chaque test (d'une charge de travail) comprennent ce qui suit :
    • L'exécution du test sera contrôlée à l'aide d'histogrammes d'état, pour vérifier que le test et les charges de travail s'exécutent comme prévu et souhaité.
    • L'exécution du script de test : chaque test s'exécute-t-il avec succès et comme souhaité ?
    • La capture et l'évaluation des temps de réponse identifiés à l'aide des rapports suivants :
      • Pourcentage de performances
      • Temps de réponse


Critères d'achèvement

Les critères d'achèvement sont précisés dans deux buts :

  • identifier la qualité acceptable pour le produit,
  • savoir quand l'effort de test a été implémenté avec succès.

La précision des critères d'achèvement doit inclure les éléments suivants :

  • fonction, comportement ou condition mesurés
  • méthode de mesure
  • critères ou degré de conformité à la mesure

Exemple 1

  • Tous les jeux d'essai planifiés ont été exécutés.
  • Tous les incidents identifiés ont été traités selon une résolution acceptée.
  • Tous les jeux d'essai ont été exécutés à nouveau et tous les incidents connus ont été traités comme convenu. Aucun autre incident n'a été découvert.

Exemple 2

  • Tous les jeux d'essai de priorité élevée ont été exécutés.
  • Tous les incidents identifiés ont été traités selon une résolution acceptée.
  • Tous les incidents de gravité 1 ou 2 ont été résolus (statut = corrigé ou différé).
  • Tous les jeux d'essai de priorité élevée ont été exécutés à nouveau et tous les incidents connus ont été traités comme convenu. Aucun autre incident n'a été découvert.

Exemple 3

  • Tous les jeux d'essai ont été exécutés.
  • Tous les incidents identifiés ont été traités selon une résolution acceptée.
  • Tous les incidents de gravité 1 ou 2 ont été résolus (statut = vérifié ou différé).
  • Tous les jeux d'essai de priorité élevée ont été exécutés à nouveau et tous les incidents connus ont été traités comme convenu. Aucun autre incident n'a été découvert.

Considérations spéciales

Cette section doit identifier les influences ou dépendances pouvant avoir une incidence ou une influence sur l'effort de test décrit dans la stratégie de test. Influences possibles :

  • ressources humaines (par exemple, disponibilité ou besoin de ressources autres que celles du test pour prendre en charge/participer au test)
  • contraintes (par exemple, limites ou disponibilité de l'équipement, besoin/manque d'équipement spécial)
  • exigences particulières, comme une planification de test ou l'accès aux systèmes

Exemples:

  • Les bases de données de test devront être prises en charge par le concepteur/l'administrateur de base de données afin de créer, de mettre à jour et de régénérer des données de test.
  • Les performances système utiliseront les serveurs sur le réseau existant (qui prend en charge le trafic non lié au test). Le test devra être planifié aux heures creuses pour que le trafic sur le réseau ne soit pas lié à lui.
  • La cible de test doit synchroniser le système en vigueur (ou la synchronisation simultanée) pour implémenter et exécuter un test fonctionnel complet.