Tâche: Définition des éléments de testabilité
Cette tâche décrit la manière d'identifier les éléments qui seront nécessaires au test.
Disciplines: Test
Objet

Les objectifs de cette tâche sont les suivants :

  • Identifier les éléments nécessaires aux éléments de test cible
  • Identifier les éléments physiques de l'infrastructure d'implémentation de test requise pour l'exécution des tests dans chaque configuration d'environnement de test
  • Définir les exigences de conception logicielle à satisfaire pour que des tests puissent physiquement être exécutés sur le logiciel
Relations
Etapes
Pour chaque élément de test cible requis, identifier les relations avec les mécanismes de test
Objet :  Comprendre les mécanismes de test requis pour les éléments de test cible.

Pour chaque élément de test cible, examinez la liste des mécanismes de test et identifiez ceux qui pourraient être appropriés. Analysez leur capacité à se rapprocher d'une solution de test complète et l'effort d'adaptation requis. Si aucun mécanisme n'est approprié ou si l'effort d'adaptation est trop lourd, définissez de nouveaux mécanismes de test et tentez de trouver un équilibre entre spécificité et capacité de réutilisation.

Identifier les événements et les éléments dynamiques du système
Objet :  Comprendre les aspects dynamiques et le contexte d'exécution du système. 

A l'aide des exigences logicielles disponibles et des informations de conception, identifiez les éléments dynamiques et les événements du système. Servez-vous des modèles de cas d'utilisation, de conception, d'implémentation et de déploiement pour identifier des éléments tels que les classes de contrôle, les processus, les unités d'exécution et les événements. Pour commencer votre recherche, servez-vous des classes de <<contrôle>>, des réalisations de cas d'utilisation et des éléments décrits dans la vue d'architecture ou dans le modèle d'implémentation (<<processus>> ou <<unité d'exécution>>).

En fonction des contraintes imposées par l'environnement de test, définissez les exigences physiques

Identifier les interfaces et les limites du système
Objet :  Comprendre les responsabilités du système du point de vue du fournisseur de services et les dépendances du système du point de vue du client. 

Vous devez également examiner un autre groupe d'éléments : les interfaces du système, et surtout celles qui ont trait aux acteurs externes. A l'aide des modèles de conception et d'implémentation, recherchez les éléments définis contenus dans <<interface>>. Recherchez également dans les modèles les classes de type <<limite>>.

En tant que testeur, il est utile d'explorer ces limites pour bien comprendre les exigences des systèmes liés (client et fournisseurs de services). Cela vous permettra d'évaluer les besoins en termes de validation des interfaces,d'infrastructure de test requise et de simulation de ces interfaces.

Identifier les éléments de l'infrastructure de test
Objet :  Identifier les principaux éléments de l'effort de test qui permettront d'effectuer les tests requis. 

Pour qu'un effort de test itératif soit effectué avec succès, il est important d'identifier et de gérer une infrastructure appropriée. Sans infrastructure pour aider à le gérer, l'effort de test peut rapidement devenir ingérable et inutilisable. L'infrastructure de test s'applique davantage à l'effort de test automatisé, mais elle est importante également pour l'effort de test manuel.

Examinez les éléments dynamiques et les événements du système : quelles dépendances placent-ils sur l'implémentation de tests ? Recherchez les occasions de dissocier les dépendances entre tests et gérez-les via des points de contrôle communs fournissant une couche d'adressage indirect. Recherchez les dépendances dans les tests, dans les données de test et dans les modifications de l'état du système.

En vous servant des informations recueillies, déterminez les exigences de l'infrastructure de test et les éléments qui faciliteront l'approche de test.

Sous-rubriques :

Faciliter les scénarios de test communs Haut de la page

Certains tests ont une structure commune de scénario ou de procédure suivie lors de leur exécution, mais la même procédure doit être exécutée plusieurs fois pour différents éléments de test cible. Dans le cas des tests automatisés, il peut être utile de créer des scripts de tests communs ou des fonctions d'utilitaires pouvant être réutilisées dans des contextes différents afin d'utiliser ces scénarios de manière efficace. Cela fournit un point central de modification si le scénario de test doit être modifié. Par exemple, cela inclut la conduite de tests standard sur des classes appropriées d'éléments d'interface et la validation de la conformité d'éléments d'interface aux normes de conception applicables.

Faciliter les dépendances des données de test Haut de la page

Lorsque des tests doivent être effectués dans une configuration d'environnement de test donnée, des conflits peuvent survenir entre les valeurs de données de test utilisées. Ce problème est amplifié lorsque l'environnement est partagé par plusieurs membres de l'équipe de test. Envisagez d'utiliser une approche permettant de dissocier les valeurs de données de test des scripts de test qui utilisent ces valeurs et incluez un point central de collecte et de modification des données de test. Cela présente deux avantages : une bonne visibilité des données de test pour tous les membres de l'équipe de test qui leur permet d'éviter les conflits potentiels lors de l'utilisation des données de test, et la présence d'un point central de modification pour la mise à jour des données.

Faciliter les dépendances des états de test Haut de la page

Pour l'exécution de la plupart des tests, le système doit adopter un état spécifique et doit ensuite rétablir un état connu une fois l'exécution terminée. Les dépendances impliquent des droits de sécurité (fonction ou données), des données dynamiques ou sensibles (dates système, numéros de commande, préférences d'ID utilisateur, par exemple),des cycles d'expiration des données (mots de passe de sécurité, expiration des produits, etc.). Certains tests dépendent fortement les uns des autres ; par exemple, un test peut créer un numéro de commande unique et un test ultérieur peut avoir besoin d'affecter le même numéro de commande.

Une solution consiste à utiliser des séries de tests pour établir une séquence des tests dépendants dans l'ordre correct d'état système. Les séries de tests peuvent ensuite être couplées avec les utilitaires appropriés de reprise système et de configuration. Pour les tests automatisés, certaines solutions peuvent inclure le stockage centralisé des données système dynamiques et l'utilisation de variables dans les scripts de tests qui font référence aux informations centralisées.

Faciliter les valeurs de données de test dérivées Haut de la page

Il arrive parfois que certains tests incluent le calcul de valeurs provenant d'un ou de plusieurs aspects de l'état système. Cela s'applique aux valeurs de données de test tant au niveau de l'entrée que des résultats escomptés. Développez éventuellement des utilitaires qui calculent ces valeurs dérivées, afin de simplifier l'exécution des tests et d'éliminer les imprécisions potentielles introduites par suite d'une erreur humaine. Lorsque vous le pouvez, développez ces utilitaires de telle sorte qu'ils puissent être utilisés pour les efforts de test manuels et automatisés.

Faciliter les chemins de navigation de test communs Haut de la page

Pour l'automatisation des tests, vous devez isoler les séquences de navigation communes et les implémenter à l'aide de fonctions centralisées d'utilitaires ou de scripts de tests. Ces séquences de navigation communes peuvent ensuite être réutilisées, constituant ainsi un point de modification en cas de changement ultérieur de la navigation. Ces aides à la navigation permettent simplement de passer d'un point à un autre ; elles n'effectuent généralement pas d'autre test que la vérification de l'état de début et de fin.

Identifier les besoins de conception spécifiques au test
Objet :  Identifier les exigences de test qui placent des contraintes potentielles au niveau du processus de génie logiciel, de l'architecture logicielle et de la conception et de l'implémentation correspondantes. 

Pour les tests automatisés tout particulièrement, il est probable que les exigences en matière d'implémentation et d'évaluation de test placent quelques contraintes sur le processus de génie logiciel et sur l'architecture et la conception du logiciel. Il est important que l'équipe de développement ne soit pas entravée dans ses travaux de développement et que l'équipe de test puisse effectuer les tests requis. Voir Tâche : Obtenir un engagement de testabilité pour plus d'informations sur la présentation des exigences de l'équipe de test à l'équipe de développement et sur la recherche de solutions satisfaisantes pour toutes les disciplines.

A l'aide des informations rassemblées, déterminez les exigences que l'effort de test place sur l'effort de développement.

Sous-rubriques :

Identifier les interfaces de test Haut de la page

Examinez les interfaces identifiées : existe-t-il des exigences supplémentaires que l'effort de test nécessite d'inclure dans la conception du logiciel et qui seront exposées lors de l'implémentation ? Dans certains cas, des interfaces supplémentaires seront spécialement requises pour l'effort de test, ou des interfaces existantes devront inclure des modes de fonctionnement supplémentaires ou des signatures de messages différentes (modification des entrées et paramètres de retour).

Dans les environnements de déploiement cible (figurant dans les configurations d'environnements de test) et dans le planning de développement lui-même, identifiez les contraintes et les dépendances placées sur l'effort de test. Ces dépendances peuvent nécessiter des raccords pour simuler des éléments de l'environnement qui ne sont pas disponibles ou qui demandent trop de ressources pour l'exécution de tests, ou encore nécessiter de tester certains composants du système.

Identifier les fonctions de test intégrées Haut de la page

Certains tests sont potentiellement intéressants mais trop chers à implémenter comme tests de contrôle. Par ailleurs, dans les environnements à fiabilité élevée, il est important de pouvoir tester et isoler le plus rapidement possible les défaillances, afin de garantir leur résolution dans les meilleurs délais. Dans ce cas, il peut s'avérer utile d'élaborer des tests directement dans le logiciel exécutable.

Différentes approches permettent d'y parvenir : deux d'entre elles impliquent la présence d'auto-tests intégrés et l'utilisation par le logiciel de cycles de traitement redondants pour l'exécution de tests d'intégrité ; des sous-programmes de diagnostic peuvent également être utilisées lorsque le logiciel reçoit un message de diagnostic ou lorsque le système est configuré en vue d'une exécution avec sous-programmes de diagnostic.

Identifier les contraintes de conception de test Haut de la page

Certains choix de l'équipe de développement en matière de conception et d'implémentation activent ou freinent l'effort de test. Alors que certains de ces choix ne peuvent être évités, d'autres décisions (au niveau de l'implémentation notamment) ont un impact minimal sur l'équipe de développement mais un impact significatif sur l'équipe de test.

Les zones à examiner sont les suivantes : utilisation de protocoles de communication standard et reconnus ; utilisation de composants d'implémentation d'interface utilisateur pouvant être reconnus par les outils d'automatisation de tests ; conformité aux règles de conception d'interfaces utilisateur incluant l'affectation de noms aux éléments des interfaces et l'utilisation cohérente des conventions de navigation dans les interfaces utilisateur.

Définir les exigences de testabilité du système
Objet :  Spécifier les exigences applicables aux fonctions logicielles requises pour le support de l'implémentation et de l'exécution des tests. 

En vous servant des travaux précédemment effectués pour cette tâche, définissez les exigences de test et les contraintes qui doivent être envisagées lors de la conception et de l'implémentation du logiciel.

Il est important d'expliquer clairement à l'équipe de développement les raisons pour lesquelles des fonctions spécifiques sont à intégrer dans le logiciel. Les principales raisons feront généralement partie des domaines suivants :

  • Activation des tests (manuels et automatisés) à implémenter via une interface entre l'élément de test cible et le test manuel ou automatisé. Cela permet de dépasser les limitations des outils d'automatisation de tests en accédant à l'application pour les entrées et les sorties d'informations.
  • Activation des auto-tests intégrés en vue de leur exécution par le logiciel développé lui-même.
  • Activation des éléments de test cible en vue de leur isolation du reste du système développé et de leur test.

Les fonctions spécifiques aux tests intégrées au logiciel doivent trouver un équilibre entre la valeur de la fonction et l'effort nécessaire d'implémentation et de test. A titre d'exemple, les fonctions de test intégrées incluent la production de journaux d'audit, les fonctions d'auto-diagnostic et les interfaces d'interrogation de la valeur de variables internes.

Une autre utilisation courante des fonctionnalités spécifiques aux tests réside dans l'intégration, qui a recours aux modules de remplacement pour les composants ou les systèmes qui ne sont pas encore implémentés ou incorporés. Deux styles d'implémentation sont principalement utilisés pour les modules de remplacement :

  • Les modules de remplacement et les pilotes qui sont simplement des "maquettes" ne présentant aucune autre fonction que la fourniture de valeurs spécifiques en entrée ou en sortie.
  • Les modules de remplacements et les pilotes qui sont plus intelligents et qui peuvent "simuler" ou se rapprocher de comportements plus complexes.

Le deuxième style de raccord fournit également un moyen puissant d'isolation des composants ou des groupes de composants du reste du système, ce qui augmente la souplesse de l'implémentation et de l'exécution des tests. Comme pour les fonctions décrites précédemment, ces fonctions spécifiques doivent trouver un équilibre entre la valeur d'un raccord complexe et l'effort nécessaire d'implémentation et de test. Utilisez ce deuxième style de raccord avec prudence, pour les deux raisons suivantes : tout d'abord parce qu'il utilise davantage de ressources pour l'implémentation, et deuxièmement parce qu'il est plus facile de passer outre l'existence du raccord que d'oublier de le retirer.

Enregistrez vos exigences directement dans des modèles de conception et d'implémentation ou à l'aide de spécifications d'interface de test.

Définir l'infrastructure de test
Objet :  Spécifier les exigences d'infrastructure de test requises pour le support de l'implémentation et de l'exécution de tests. 

En vous servant des travaux précédemment effectués pour cette tâche, définissez l'infrastructure de test requise pour le support de l'implémentation et de l'exécution des tests.

Souvenez-vous que vous définissez les fonctions d'implémentation de l'infrastructure : l'objectif principal consiste à définir les différentes parties de la solution qui permettra d'implémenter cette infrastructure.

Sous-rubriques :

Eléments d'automatisation de test Haut de la page

Les exigences ou fonctions clés de l'infrastructure de tests automatisés incluent :

  • Modèle de navigation : les approches fréquemment rencontrées sont les approches aller-retour, segmentées ou hybrides. Les autres possibilités incluent l'utilisation d'un cadre d'action ou de tables de navigation
  • Accès externe aux données : méthode d'accès externe aux données à partir d'instructions de test
  • Rapports d'erreurs et reprise : programmes de gestion des erreurs et d'exécution de reprise de séries de tests
  • Profils d'accès et de sécurité : ID utilisateur d'exécution de tests automatisés
  • Capacité du logiciel à exécuter des auto-tests

Enregistrez vos décisions sous forme de définitions dans les sections d'implémentation de l'architecture de tests automatisés, de conseils de processus ou encore sous forme d'instructions de test, de scripts de tests, de séries de tests ou de sous-programmes utilitaires de bibliothèques de tests. Voir Produit : Architecture d'automatisation des tests pour d'autres suggestions.

Eléments de test manuel Haut de la page

Les exigences ou fonctions clés de l'infrastructure de tests manuels incluent :

  • Référentiel de données de test : référentiel commun pour la définition des données de test.
  • Restauration et reprise : méthode permettant d'effectuer la restauration ou la reprise de l'état connu de la configuration de l'environnement de test.
  • Activation des éléments de test cible en vue de leur isolation du reste du système développé et de leur test.

Enregistrez vos décisions en tant que conseils sur le processus dans un ou plusieurs documents Produit : Instructions relatives au projet.

Evaluer et vérifier vos résultats
Objet :  Vérifier que la tâche a été correctement réalisée et que les produits qui en résultent sont acceptables. 

Maintenant que vous avez achevé le travail, il serait utile de vérifier que ce travail a suffisamment de valeur et que vous n'avez pas simplement consommé de grandes quantités de papier. Vous devez déterminer si votre travail est d'une qualité correcte et s'il est suffisamment complet pour que les membres de l'équipe puissent l'utiliser comme entrée pour leur propre travail. A chaque fois que cela est possible, utilisez les listes de contrôle fournies dans RUP pour vérifier que la qualité et l'achèvement sont "acceptables".

Faites en sorte que les personnes qui effectuent des tâches en aval et qui se fondent sur votre travail en tant qu'entrée prennent part à la revue de votre travail intermédiaire. Effectuez cette revue pendant que vous avez encore du temps disponible pour prendre les mesures qui répondent à leurs préoccupations. Vous devez également évaluer votre travail par rapport aux principaux produits d'entrée pour vous assurer que vous les avez précisément et suffisamment représentés. Il peut être utile que l'auteur du produit d'entrée révise votre travail sur cette base.

Gardez à l'esprit que le processus RUP est un processus itératif de livraison et que, dans la plupart des cas, les produits évoluent avec le temps. A ce titre, il n'est pas habituellement nécessaire, et même souvent contre-productif, de concevoir complètement un produit qui ne sera que partiellement utilisé ou ne sera pas du tout utilisé dans l'immédiat. Cela vient du fait qu'il existe une grande probabilité pour que la situation qui entoure le produit change et que les hypothèses émises lors de la création du produit s'avèrent incorrectes, avant même l'utilisation du produit, occasionnant une perte d'efforts et un retravail coûteux. Evitez également le piège consistant à utiliser trop de cycles pour la présentation au détriment de la valeur du contenu. Dans les environnements de projet où la présentation a une importance et une valeur économique en tant que livrable du projet, vous pouvez envisager d'utiliser des ressources administratives pour réaliser les tâches de présentation.



Plus d'informations