Mise au point de tests à partir d'un modèle
Dans Microsoft Visual Studio Ultimate, vous pouvez utiliser des modèles d'impératifs et d'architectures pour organiser les tests de votre système et de ses composants. Cette pratique permet de vérifier que vous testez les spécifications importantes pour les utilisateurs et les autres parties prenantes ; elle vous permet également de mettre à jour les tests rapidement lorsque les spécifications sont modifiées. Si vous utilisez Microsoft Test Manager, vous pouvez également conserver des liens entre les modèles et les tests.
Test du système et du sous-système
Le test du système, également appelé test d'acceptation, désigne le test permettant de déterminer si les besoins des utilisateurs sont satisfaits. Les tests de ce type se concentrent sur le comportement extérieurement visible du système, et non sur sa conception interne.
Les tests de systèmes sont extrêmement utiles lors de l'extension ou de la reconception d'un système. Ils vous permettent d'éviter d'introduire des bogues lorsque vous modifiez le code.
Lorsque vous envisagez de modifier ou d'étendre un système, il est utile de démarrer avec un ensemble de tests de systèmes qui s'exécutent sur le système existant. Ensuite, vous pouvez étendre ou adapter les tests pour tester les nouveaux impératifs, apporter des modifications au code et réexécuter tous les tests de l'ensemble.
Lorsque vous développez un nouveau système, vous pouvez commencer à créer des tests dès le début du développement. En définissant des tests avant de développer chaque fonctionnalité, vous pouvez capturer les discussions d'impératifs d'une manière très spécifique.
Les tests de sous-systèmes appliquent les mêmes principes aux composants majeurs d'un système. Chaque composant est testé indépendamment des autres composants. Les tests de sous-systèmes se concentrent sur le comportement visible au niveau des interfaces utilisateur ou de l'API du composant.
Pour plus d'informations sur la façon d'exécuter des tests, consultez Test de l'application.
Dérivation de tests de systèmes à partir d'un modèle d'impératifs
Vous pouvez créer et conserver une relation entre des tests de systèmes et un modèle d'impératifs. Pour établir cette relation, vous écrivez des tests qui correspondent aux principaux éléments du modèle d'impératifs. Visual Studio Ultimate vous permet de conserver cette relation en vous laissant créer des liens entre les tests et les parties du modèle. Pour plus d'informations sur les modèles de spécifications, consultez Modélisation des besoins des utilisateurs.
Écriture de tests pour chaque cas d'usage
Si vous utilisez Microsoft Test Manager, vous pouvez créer un groupe de tests pour chaque cas d'usage que vous avez défini dans votre modèle d'impératifs. Par exemple, si vous disposez d'un cas d'usage Commande d'un repas, qui inclut Création d'une commande et Ajout d'un article à la commande, vous pouvez créer des tests pour les cas d'usage les plus généraux et les plus détaillés. Pour plus d'informations sur les cas d'usage, consultez Diagrammes de cas d'usage UML : indications.
Les indications suivantes peuvent être utiles :
Chaque cas d'usage doit disposer de plusieurs tests, pour les chemins principaux et les résultats exceptionnels.
Lorsque vous décrivez un cas d'usage dans le modèle d'impératifs, il est plus important de définir sa post-condition, autrement dit, l'objectif atteint, que de décrire de manière détaillée les procédures que suit l'utilisateur afin d'atteindre l'objectif. Par exemple, la post-condition Commande d'un repas peut être qu'un Restaurant prépare un repas pour un Client et que le Client a payé. La post-condition correspond aux critères que vos tests doivent vérifier.
Faites reposer les autres tests sur les autres clauses de la post-condition. Par exemple, créez d'autres tests pour informer le restaurant de la commande et pour recevoir le paiement du client. Cette séparation présente les avantages suivants :
Les modifications apportées aux différents aspects des impératifs interviennent souvent de manière indépendante. En séparant les tests en différents aspects de cette manière, vous simplifiez la mise à jour des tests lors de la modification des impératifs.
Si le plan de développement implémente un aspect du cas d'usage avant un autre, vous pouvez activer les tests séparément à mesure que le développement progresse.
Lorsque vous concevez les tests, séparez le choix de données de test du code ou du script qui détermine si la post-condition a été remplie. Par exemple, le test d'une fonction arithmétique simple peut se présenter comme suit : Entrée 4 et vérifiez que le résultat est 2. Concevez plutôt le script comme suit : choisissez une entrée, multipliez le résultat par lui-même et vérifiez qu'il correspond à l'entrée d'origine. Ce style vous permet de varier les tests d'entrée sans modifier leur corps principal.
Liaison de tests à des cas d'usage
Si vous utilisez Gestionnaire de tests pour concevoir et exécuter vos tests, vous pouvez organiser ces derniers sous des éléments de travail tels que les impératifs, les cas d'usage ou encore les récits utilisateur. Vous pouvez lier ces éléments de travail aux cas d'usage de votre modèle. Cela vous permet d'assurer un suivi rapide des modifications d'impératifs aux tests et de la progression de chaque cas d'usage.
Pour lier des tests à un cas d'usage
Dans Gestionnaire de tests, créez un impératif et faites reposer une suite de tests sur celui-ci. Pour savoir comment procéder, consultez (retirée) Création de tests pour des éléments du journal des travaux en souffrance (backlog) du produit, des récits utilisateur ou des spécifications.
L'impératif que vous créez est un élément de travail dans Team Foundation Server. Il peut s'agir d'un élément de travail de récit utilisateur, d'impératif ou de cas d'usage, selon le modèle de processus que votre projet utilise avec Team Foundation. Pour plus d'informations, consultez Suivre un travail avec Visual Studio ALM et TFS.
Liez l'élément de travail d'impératif à un ou plusieurs cas d'usage de votre modèle.
Dans un diagramme de cas d'usage, cliquez avec le bouton droit sur un cas d'usage et cliquez sur Lien vers l'élément de travail. Pour plus d'informations, consultez Lier des éléments de modèle et des éléments de travail.
Ajoutez à la suite de tests, des cas de test qui vérifient les cas d'usage.
Généralement, chaque élément de travail de récit utilisateur ou d'impératif est lié à plusieurs cas d'usage de votre modèle. Par ailleurs, chacun d'entre eux est lié à plusieurs récits utilisateur ou impératifs. Cela est dû au fait que chaque récit utilisateur ou impératif couvre un ensemble de tâches qui développent plusieurs cas d'usage. Par exemple, lors de l'une des premières itérations de votre projet, vous pouvez développer le récit utilisateur de base dans lequel un client peut sélectionner des éléments dans un catalogue et se les faire livrer. Dans une itération ultérieure, le récit peut indiquer que l'utilisateur paye une fois la commande exécutée et que le fournisseur reçoit la somme après avoir envoyé les marchandises. Chaque récit ajoute une clause à la post-condition du cas d'usage Commande de marchandises.
Vous pouvez créer des liens séparés entre des impératifs et des clauses de la post-condition en écrivant ces clauses dans des commentaires séparés dans le diagramme de cas d'usage. Vous pouvez lier chaque commentaire à un élément de travail d'impératif et le lier au cas d'usage dans le diagramme.
Tests de base sur les types d'impératifs
Les types (autrement dit, les classes, les interfaces et les énumérations) d'un modèle d'impératifs décrivent les concepts et les relations quant aux modes de pensée et de communication des utilisateurs concernant leur activité. Cela exclut les types concentrés exclusivement sur la conception interne du système.
Concevez vos tests par rapport à ces types d'impératifs. Cette pratique vous permet de vérifier que lors de l'évocation des modifications apportées aux impératifs, il est facile d'associer ces modifications à celles nécessaires dans les tests. Il permet d'évoquer les tests et leurs résultats prévus directement avec les utilisateurs finaux et les autres parties prenantes. Cela signifie que les besoins des utilisateurs peuvent être gérés hors du processus de développement. Cela permet également d'éviter la conception inattentive des tests autour des éventuels défauts de la conception.
Quant aux tests manuels, cette pratique implique le respect de la terminologie du modèle d'impératifs dans les scripts de test. Pour les tests automatisés, cette pratique implique l'utilisation de diagrammes de classes d'impératifs comme base pour votre code de test, de même que la création de fonctions d'accession et de mise à jour pour lier le modèle d'impératifs au code.
Par exemple, un modèle d'impératifs peut inclure des types Menu, Élément de menu, Commande et Associations entre eux. Ce modèle représente les informations stockées et gérées par le système de commande de repas, et non les complexités de son implémentation. Il se peut que le système de travail comprenne plusieurs réalisations différentes de chaque type, dans des bases de données, des interfaces utilisateur ou encore des API. Il est possible qu'un système distribué intègre plusieurs variantes de chaque instance stockées simultanément dans différentes parties du système.
Pour tester un cas d'usage comme Ajout d'un article à la commande, une méthode de test peut inclure un code semblable à celui-ci :
Order order = … ; // set up an order
// Store prior state:
int countBefore = order.MenuItems.Count;
// Perform use case:
MenuItem chosenItem = …; // choose an item
AddItemToOrder (chosenItem, order);
// Verify part of postcondition:
int countAfter = order.MenuItems.Count;
Assert (countAfter == countBefore = 1);
Notez que cette méthode de test utilise les classes du modèle d'impératifs. Les associations et les attributs sont réalisés comme des propriétés .NET.
Pour ce faire, les propriétés des classes doivent être définies comme des fonctions ou des accesseurs en lecture seule, qui permettent d'accéder au système afin d'extraire les informations concernant son état actuel. Les méthodes qui simulent des cas d'usage telles que AddItemToOrder (Ajout d'un article à la commande) doivent entraîner le système par le biais de son API ou d'une couche située sous son interface utilisateur. Les constructeurs d'objets de test tels que Commande et Élément de menu doivent également entraîner le système pour créer des articles correspondants dans le système.
De nombreuses fonctions d'accession et de mise à jour seront déjà disponibles par le biais de l'API normale de l'application. Cependant, certaines fonctions supplémentaires devront peut-être être écrites pour activer les tests. Ces fonctions supplémentaires d'accession et de mise à jour sont parfois appelées 'instrumentation de test.' Étant donné qu'ils dépendent de la conception interne du système, il est de la responsabilité des développeurs du système de les fournir, alors que les testeurs écrivent le code des tests à l'aide des termes du modèle d'impératifs.
Lorsque vous écrivez des tests automatisés, vous pouvez utiliser des tests génériques pour encapsuler les fonctions d'accession et de mise à jour. Pour plus d'informations, consultez Création d'un test automatisé qui lance un exécutable au moyen de tests génériques.
Tests de règles d'entreprise
Certains impératifs ne sont pas directement liés à un cas d'usage. Par exemple, l'entreprise DinnerNow permet aux clients d'effectuer leur sélection dans de nombreux Menus, mais exige que dans chaque Commande, tous les Éléments sélectionnés le soient dans un seul Menu. Cette règle d'entreprise peut être exprimée sous la forme d'un invariant relatif aux associations entre Commandes, Menus et Éléments dans le modèle de classes d'impératifs.
Une règle d'invariant de ce genre régit non seulement tous les cas d'usage actuellement définis, mais également tous les autres qui le seront ultérieurement. Par conséquent, il est utile de l'écrire séparément des cas d'usage et de la tester indépendamment de ceux-ci.
Vous pouvez écrire une règle métier d'invariant sous la forme d'un commentaire dans un diagramme de classes. Pour plus d'informations, consultez Diagrammes de classes UML : indications.
Vous pouvez lier des tests à une règle métier en liant le commentaire à un élément de travail d'impératif ou de récit utilisateur, que vous pouvez ensuite lier à une suite de tests dans Gestionnaire de tests. Pour plus d'informations, consultez Attachement de cas de test à des éléments de modèles.
Les performances et autres impératifs de qualité de service peuvent être notés dans les commentaires de diagrammes de cas d'usage, d'activités ou encore de séquence. Vous pouvez également les lier aux éléments de travail d'impératifs et à leurs suites de tests.
Diagrammes de séquence et d'activités pour les tests
Si vos impératifs ou modèles d'architecture incluent des diagrammes de séquence ou d'activités, vous pouvez écrire des tests qui suivent ces diagrammes directement.
Il est parfois utile de concevoir des tests qui sélectionnent dynamiquement différents chemins d'accès par l'intermédiaire des branches et des boucles du diagramme.
Tentez de vérifier l'état du système après chaque message ou action. Cela peut nécessiter une instrumentation supplémentaire.
Dérivation des tests de sous-systèmes à partir de modèles
Dans la conception globale d'un grand système, vous pouvez identifier des composants ou des sous-systèmes. Ils représentent des parties qui peuvent être conçues séparément, qui se trouvent sur différents ordinateurs ou encore qui sont des modules réutilisables qui peuvent être recombinés de plusieurs manières. Pour plus d'informations, consultez Diagrammes de composants UML : indications.
Vous pouvez appliquer à chaque composant principal, les mêmes principes que vous utilisez pour le système complet. Dans un grand projet, chaque composant peut disposer de son propre modèle d'impératifs. Dans les plus petits projets, un modèle d'architecture ou une conception globale peuvent être créés pour afficher les principaux composants et leurs interactions. Pour plus d'informations, consultez Modélisation de l'architecture d'un système logiciel.
Dans les deux cas, vous pouvez établir une relation entre les éléments de modèle et les tests de sous-systèmes de la même manière que vous le feriez entre le modèle d'impératifs et les tests de systèmes.
Isolement de composants à l'aide des interfaces fournies et requises
Il est particulièrement utile d'identifier toutes les dépendances dont un composant dispose dans d'autres parties de votre système ou des services externes, et de les représenter en tant qu'interfaces requises. Cet exercice donne généralement lieu à une reconception qui a pour effet de découpler bien davantage le composant et de facilement le séparer du reste de votre conception.
L'un des avantages de ce découplage est que le composant peut être exécuté pour le test en remplaçant les services qu'il utilise habituellement par des objets fictifs. Il s'agit de composants configurés à des fins de test. Un composant fictif fournit l'interface que nécessite votre composant, en répondant aux requêtes à l'aide de données simulées. Les composants fictifs font partie d'un atelier de test complet que vous pouvez connecter à toutes les interfaces du composant.
L'un des avantages que présente le test fictif est que vous pouvez développer votre composant pendant que les autres, dont les services qu'il utilisera, sont toujours en cours de développement.
Gestion des relations entre les tests et le modèle
Dans un projet typique qui exécute des itérations à quelques semaines d'intervalle, un passage en revue des impératifs intervient à peu près au début de chaque itération. Les fonctionnalités qui feront partie de la prochaine itération sont évoquées au cours de la réunion. Un modèle d'impératifs peut être utilisé pour évoquer les concepts, les scénarios et les séquences d'actions qui seront développés. Les parties prenantes professionnelles définissent des priorités, les développeurs réalisent des évaluations et les testeurs vérifient que le comportement attendu de chaque fonctionnalité est correctement capturé.
L'écriture de tests est la méthode la plus efficace pour définir un impératif et figure également comme un moyen efficace de garantir qu'une personne comprend clairement les éléments requis. Cependant, alors que l'écriture de tests demande trop de temps pendant un atelier de spécification, la création de modèles peut être exécutée bien plus rapidement.
Du point de vue des tests, un modèle d'impératifs peut être perçu comme une forme abrégée des tests. Par conséquent, il est important de gérer la relation entre les tests et le modèle sur l'ensemble du projet.
Attachement de cas de test à des éléments de modèles
Si votre projet utilise Gestionnaire de tests, vous pouvez lier des tests aux éléments de votre modèle. Cela vous permet de rechercher rapidement les tests affectés par une modification des impératifs et d'assurer le suivi de l'étendue à laquelle un impératif a été réalisé.
Vous pouvez lier des tests à tous les genres d'éléments. Voici quelques exemples :
Liez un cas d'usage aux tests qui l'utilisent.
Écrivez les clauses d'une post-condition de cas d'usage ou d'un objectif dans les commentaires liés au cas d'usage, puis liez les tests à chaque commentaire.
Écrivez des règles d'invariants dans les commentaires des diagrammes de classes ou des diagrammes d'activités, et liez-les aux tests.
Liez des tests à un diagramme d'activités ou encore à des activités individuelles.
Liez une suite de tests au composant ou au sous-système qu'elle teste.
Pour lier des tests à un élément de modèle ou à une relation
Dans Gestionnaire de tests, créez un impératif et faites reposer une suite de tests sur celui-ci. Pour savoir comment procéder, consultez (retirée) Création de tests pour des éléments du journal des travaux en souffrance (backlog) du produit, des récits utilisateur ou des spécifications.
L'impératif que vous créez est un élément de travail dans Team Foundation Server. Il peut s'agir d'un élément de travail de récit utilisateur, d'impératif ou de cas d'usage, selon le modèle de processus que votre projet utilise avec Team Foundation. Pour plus d'informations, consultez Suivre un travail avec Visual Studio ALM et TFS.
Liez l'élément de travail d'impératif à un ou plusieurs éléments de votre modèle.
Dans un diagramme de modélisation, cliquez avec le bouton droit sur un élément, un commentaire ou une relation, puis cliquez sur Lien vers l'élément de travail. Pour plus d'informations, consultez Lier des éléments de modèle et des éléments de travail.
Ajoutez à la suite de tests, des cas de test qui vérifient l'impératif exprimé dans l'élément de modèle.
Voir aussi
Concepts
Développement de modèles pour la conception logicielle
Modélisation des besoins des utilisateurs