Tester de manière anticipée et fréquente

L'interception des défauts le plus tôt possible représente le moyen le plus économique de s'assurer de la qualité d'un logiciel. Kent Beck et Cynthia Andrés ont écrit « Voici le dilemme du développement de logiciel : les défauts coûtent chers, mais les éliminer coûtent également cher. Toutefois, la plupart des défauts finissent par coûter plus chers que leur prévention ». (Pour plus d'informations, consultez la page Web suivante : Extreme Programming Explained: Embrace Change.) Les meilleures pratiques et les outils peuvent aider votre équipe à réduire le coût de la prévention et de la résolution des défauts en préservant la qualité de votre projet tout au long de son cycle de vie.

Votre équipe peut évaluer avec plus de précision la qualité de votre projet à tout moment si vous recherchez les défauts, les résolvez et vérifiez les correctifs. En effectuant souvent des tests, votre équipe et les parties prenantes restent informées de l'état actuel du code et prennent des décisions avisées pendant tout le projet. En définitive, vous devriez pouvoir répondre à la question « pouvons-nous publier ?» tout en ayant connaissance des implications pour les utilisateurs du logiciel.

Cette rubrique recommande les pratiques suivantes :

• Créer un ensemble de tests unitaires automatisés pour chaque classe et pour l'API de chaque composant principal. L'écriture de tests unitaires doit occuper environ 40 % du temps des membres de l'équipe. Pour plus d'informations, consultez Création de tests automatisés.

• Créer des tests pour chaque récit utilisateur. De préférence, ceux-ci doivent être automatisés. Pour plus d'informations, consultez Création d'un plan de test à partir de spécifications ou de récits utilisateur.

• Créer des stratégies d'archivage qui rappellent aux membres de l'équipe d'exécuter des tests unitaires avant d'archiver le code. Pour plus d'informations, consultez Ajouter des stratégies d'archivage.

• Configurer une build continue ou nocturne qui exécute l'ensemble des tests.

• Surveiller la couverture de test pour s'assurer que tout votre code est testé. Visez une couverture d'au moins 70 %. Pour plus d'informations, consultez Intervalles de test, rapport Excel (Agile).

• Exécuter des tests manuels près de la fin de chaque sprint.

Votre équipe peut gérer et mettre à l'échelle ces activités de test tôt dans votre projet en utilisant l'intégration entre Gestionnaire de tests Microsoft, Visual Studio Application Lifecycle Management (ALM) et Visual Studio Team Foundation Server. Pour plus d'informations, consultez Test de l'application.

Dans cette rubrique

• Stratégie de test

• Planification du test

• Test d'acceptation

• Test unitaire

• Développement piloté par les tests et tests précoces

• Test manuel ou test automatisé

• Création des rapports des résultats de test

Stratégie de test

La réussite de votre équipe en matière de test dépend de plusieurs facteurs, notamment la taille de votre équipe, les méthodes de votre équipe et les outils d'administration de votre équipe. Vous pouvez utiliser des méthodes agiles pour améliorer constamment les résultats de test. En suivant cette méthode, vous pouvez non seulement commencer à tester avec des ressources très limitées en appliquant cette méthode, mais vous pouvez aussi adapter votre approche selon vos besoins au cours du projet.

Éléments à prendre en compte lors de l'introduction du test agile

Lors de l'introduction du test agile dans une application existante, votre équipe peut commencer par réfléchir à votre stratégie de test au niveau du sprint et au niveau du projet. Au niveau du sprint, vous pouvez inclure un jeu de tests d'acceptation pour couvrir chaque récit utilisateur du sprint actuel. Au niveau du projet, vous pouvez avoir des tests qui couvrent le projet dans son ensemble, tel que les tests de bout en bout. Cela est utile si vous souhaitez vérifier des fonctionnalités qui couvrent deux ou plusieurs sprints. Vous pouvez créer tous les genres de tests pendant que votre équipe crée le code au cours d'un sprint. Ces tests incluent des tests unitaires, des tests d'acceptation et des tests non fonctionnels, tels que les tests de performances, les tests de sécurité et les tests d'utilisation.

Pour appliquer des méthodes de test agile, vous devez d'abord considérer l'historique de votre application et le système que votre équipe utilise. Vous pouvez appliquer des méthodes de test agile aux applications nouvelles et existantes. Vous pouvez utiliser Gestionnaire de tests Microsoft pour créer un plan de test pour votre projet entier et un plan de test pour chaque sprint dans votre projet. Ces plans de test permettent à votre équipe d'organiser des cas de test en suites de tests afin de classer par ordre de priorité l'exécution des tests et d'interpréter les résultats des tests. Pour plus d'informations, consultez Création d'un plan de test à partir de spécifications ou de récits utilisateur. Votre équipe peut utiliserVisual Studio ALM pour grouper des cas de test en suites de tests via plusieurs méthodes :

• Création et gestion d'un groupe statique de cas de test.

• Utilisation d'une requête pour créer et gérer un groupe dynamique de cas de test (c'est à dire, rechercher des cas de test par priorité).

• Ajout d'un récit utilisateur ou d'une spécification à un plan de test, où les cas de test ont un lien vers la spécification.

• Copie d'une suite de tests existante depuis un autre plan de test.

Pour plus d'informations, consultez Organisation de cas de test à l'aide de suites de tests.

Deuxièmement, vous devez considérer la testabilité de votre code. Pour en savoir plus, vous devez comprendre l'architecture et les modèles de votre application. Si vous utilisez des modèles tels que le contrôleur de la vue du modèle (MVC), le modèle MVVM (Model View ViewModel), ou le présentateur MVP (Model View Presenter), vous pouvez isoler certaines fonctions et exécuter des tests fonctionnels sans incidence négative sur le test de l'interface utilisateur. Toutefois, il ne s'agit pas toujours d'un cas grandeur nature. Par exemple, vous ne pouvez pas isoler de fonctionnalités pour les parties de refactorisation de votre application, et vous ne pouvez atteindre certaines zones de code que par l'intermédiaire de l'interface utilisateur ou des gestionnaires d'événements de mise en réseau. Par conséquent, vous devez augmenter le pourcentage de code testable si vous souhaitez améliorer nettement la qualité du test. Pour plus d'informations sur ces modèles, consultez ASP.NET MVC 2.

Troisièmement, vous devez considérer les fonctions de votre équipe avant d'implémenter le test agile. Des membres de l'équipe doivent pouvoir créer des tests unitaires lorsque vous implémentez des fonctionnalités. Ils doivent pouvoir créer et définir des cas d'usage manuels et des tests du flux de travail s'ils sont familiers avec les règles métier de votre application. En outre, s'ils ont les compétences techniques nécessaires, les autres membres de l'équipe doivent pouvoir créer des tests automatisés et plus détaillés basés sur ces tests manuels.

Comment gérer le cycle de vie de test

Les tests représentent un processus itératif tout au long du projet. Reportez-vous aux étapes suivantes :

1. Définissez des objectifs de test clairs et assurez-vous que toute votre équipe les accepte. Selon ces objectifs, déterminez votre stratégie de test. Par exemple, votre stratégie peut être « Les tests seront exécutés avant chaque archivage, les tests unitaires atteindront 70 % de la couverture du code et chaque récit utilisateur possédera au moins un test automatisé ».

2. Définissez votre plan de test selon les récits utilisateur du projet, les hypothèses de conception et les spécifications non fonctionnelles dans le sprint actuel.

   1. Vous pouvez ajouter des récits utilisateur au journal des travaux en souffrance et les planifier pour les futurs sprints. Vous devez mapper chaque plan de test à au moins un sprint et, par conséquent, vous devez avoir des cas de test pour tous les récits utilisateur dans le sprint.

3. Définissez et générez des cas de test, tels que les tests d'acceptation, tests unitaires, tests fonctionnels et tests de performance.

4. Groupez les cas de test en suites de tests. Vous pouvez intégrer ces suites de tests dans des plans de test définis afin de guider votre effort de test.

5. Répétez l'exécution des suites de tests et des cas de test contenus dans un sprint. Commencez à exécuter des tests précocement dans un sprint et continuez à ajouter des cas de test aux suites de tests. Si vous souhaitez identifier des conditions et des situations de test importantes, vous pouvez appliquer des tests exploratoires et avoir des conversations fréquentes au sein de votre équipe.

6. Assurez-vous que tous les tests d'acceptation d'un récit utilisateur ont réussi avant d'affecter à son état la valeur Terminé.

Même s'il est possible de mieux détailler le flux de travail selon la répartition des composants du logiciel, l'illustration précédente résume l'esprit d'un flux de travail pour les composants principaux.

• Le code génère des builds.

• Le code est influencé par le travail, les plans de test et la qualité des builds définis.

• Les plans de test, suites de tests et cas de test sont influencés par les objectifs prévus et les autres aspects du projet qui n'apparaissent pas sur cette illustration.

• Les modifications apportées au code peuvent affecter des cas de test.

Résolution de bogues

1. Vous devez gérer les bogues le plus rapidement possible. Un bogue grave signifie que les récits utilisateur qu'il affecte n'ont pas été effectués.

2. Créez des éléments de travail Bogue pour les bogues trouvés par le biais de tests ou d'autres activités. Spécifiez la gravité du bogue pour indiquer son niveau d'affectation des récits utilisateur. Une gravité élevée, telle que 0 ou 1, indique que les récits utilisateur importants ne sont pas implémentés ou que les utilisateurs doivent mettre en œuvre des solutions alternatives significatives pour terminer le récit. Un niveau de gravité faible, tel que 3, indique que les utilisateurs peuvent toujours atteindre leurs principaux objectifs sans travail supplémentaire.

3. Collaborez avec les membres de votre équipe pour choisir un plan d'action pour chaque bogue.

4. Résolvez les bogues dès que vous les corrigez. Ils doivent être assignés à une autre personne qui vérifie leur correction. Vérifiez et fermez les bogues dès que possible.

5. Effectuez le suivi de l'état des bogues. Au cours de la réunion de rétrospective qui a lieu à la fin de chaque itération, étudiez le rapport Tendances des bogues et discutez des raisons expliquant une éventuelle augmentation inhabituelle des bogues. Pour plus d'informations, consultez Tendances des bogues, rapport.

Planification du test

La planification du test est le processus qui permet à votre équipe de saisir votre projet dans son ensemble ainsi que le processus de préparation de votre équipe pour tous les genres de tests. Le test agile démarre au niveau du sprint. Dans chaque sprint, votre équipe crée des tests pour vérifier les récits utilisateur élaborés au cours de ce sprint. Elle exécute les tests créés à la fois dans le sprint actuel et les précédents. Tout au long du projet, un grand nombre de tests sont créés pour couvrir toutes les fonctionnalités. L'illustration suivante montre un modèle pour les plans de test dans votre projet.

Créer un plan de test pour chaque sprint et pour le projet

Grâce aux fonctionnalités de test de Visual Studio ALM, votre équipe peut planifier, organiser, exécuter et signaler les tests de façon incrémentielle. Votre équipe peut créer un modèle pour les plans de test, et les membres de l'équipe peuvent remplir des suites de tests. Dans un plan de test, votre équipe peut déterminer à quel moment vous devez utiliser des cas de test automatisé ou manuel.

Pour chaque sprint dans votre projet, vous pouvez commencer à créer un plan de test. En utilisant ce plan, votre équipe peut se concentrer sur la vérification des fonctionnalités dans le sprint actuel. Même si le plan est vide initialement, vous pouvez l'utiliser comme espace réservé pour les suites de tests. Vous pouvez ensuite organiser les cas de test en suites de tests appropriés. Vous devez créer ces cas de test le plus tôt possible et partout dans un sprint pour obtenir les commentaires opportuns des parties prenantes du projet.

Vous pouvez également créer un plan de test qui couvre l'ensemble de votre projet. Vous pouvez utiliser les plans de test du projet pour fusionner des tests des précédents sprints et organiser des suites de tests qui s'appliquent au projet entier. Vous devez continuer à exécuter des suites de tests de régression en raison de l'importance de maintenir la stabilité et les flux dans le cadre de la création de projets plus importants par votre équipe. En particulier si vous travaillez avec des équipes distribuées et plus importantes qui manquent de proximité, les suites de tests de régression peuvent intercepter des erreurs basées sur des modifications ayant des conséquences en cascade. Sans la mise en place de mesures correctes, ces erreurs sont très difficile à intercepter et risque d'être interceptées tardivement dans le cycle ou après la livraison.

Des équipes peuvent définir un plan de test qui couvre le projet dans son ensemble. Ces genres de plans de test peuvent vérifier les fonctionnalités connexes dans plusieurs sprints et contenir des suites de tests qui s'exécutent dans tout le projet. Par exemple, vous pouvez tester une fonctionnalité qui couvre les récits utilisateur dans les sprints uniquement lorsque l'intégralité de la fonctionnalité est terminée.

Définir des tests d'acceptation avant un sprint

Vous devez définir des tests d'acceptation avant un sprint. Ces tests d'acceptation peuvent vous aider à déterminer si un récit utilisateur est terminé. Vous pouvez suivre les cas de test d'acceptation si vous créez une suite de tests nommée Tests d'acceptation dans un plan de test pour chaque sprint. Pour plus d'informations, consultez Test d'acceptation plus loin dans cette rubrique.

Créer des tests unitaires pendant un sprint

Votre équipe doit générer des tests unitaires pendant un sprint. Les tests unitaires peuvent vérifier la performance du code, par exemple le coût horaire et les ressources utilisées pour exécuter le code. D'autres types de tests, tels que les tests non fonctionnels (autrement dit, les tests de performance et les tests de sécurité) doivent être élaborés et ajoutés aux suites de tests appropriées. Vous devez organiser ces suites de tests pour identifier facilement leur coût.

Concentrer les tests sur les zones les plus utilisées

Connaître où se trouve la variabilité élevée dans votre logiciel détermine l'emplacement possible des zones réactives. Les entrées d'utilisateur, l'environnement d'exécution du logiciel, le réseau et le matériel sont des exemples de variables de configuration qui permettent à votre équipe de déterminer les zones réactives du logiciel. Si une condition se produit rarement ou qu'il existe un nombre complexe de conditions qui peuvent se produire pendant un test, la valeur du test diminue sauf que l'impact potentiel d'un défaut est très élevé. En général, l'isolement des fonctionnalités est souhaitable s'il est possible. Le test des situations présentant un impact élevé est également important. Pour plus d'informations sur la gestion des configuration à l'aide d'Gestionnaire de tests Microsoft, consultez Définition de votre matrice de test à l'aide des configurations de test.

Pour les projets existants, surveillez les zones ayant le nombre de défaut le plus élevé et déterminez pourquoi les défauts existent. Surveillez aussi l'évolution du code parce que cette zone peut négliger des hypothèses sous-jacentes. Parmi les raisons qui expliquent les erreurs de code se trouvent la difficulté de gérer non seulement les états (par exemple, le réseau et l'interface utilisateur) mais également le code.

Séparer les tests de traitement et de stockage des données

Le code qui utilise une base de données sépare en général le traitement des données de leur stockage. Vous pouvez tester le traitement des données en exécutant des tests unitaires, et vous pouvez tester directement le stockage des données au niveau de la couche de la base de données. Visual Studio Test Professional 2010 fournit les fonctionnalités pour le test des procédures stockées de base de données. Vous devez organiser ces tests dans leur propre suite de tests. Pour plus d'informations, consultez Création et définition de tests unitaires de base de données.

Gestionnaire de tests Microsoft peut servir à créer des instantanés d'images d'ordinateur et à les utiliser comme un moyen de rétablir un état connu après avoir exécuté des tests qui dépendent des données (ou un autre aspect de l'état). Ces tests sont très précieux et prennent généralement beaucoup de temps.

Test d'acceptation

Les tests d'acceptation vérifient les récits utilisateur. Ces tests peuvent non seulement vous permettre de répondre aux besoins de vos clients durant tout le cycle de vie de votre projet mais également établir la confiance de ces derniers et afficher les responsabilités que vous assumez. Pour plus d'informations, consultez la page Web suivante : Acceptance Test Engineering Guide (page éventuellement en anglais).

Comment démarrer avec les tests d'acceptation

Ouvrez Gestionnaire de tests Microsoft, puis créez une suite de tests nommée Tests d'acceptation dans votre plan de test. Votre équipe doit avoir au moins une suite de tests qui groupe des tests d'acceptation pour chaque sprint. Pour plus d'informations, consultez Définition de votre effort de test à l'aide de plans de test.

Passer de tests manuels à des tests automatisés

Les tests manuels sont plus faciles à définir que les tests automatisés mais plus chers à exécuter. Une bonne stratégie consiste par conséquent à commencer par des tests manuels et à remplacer progressivement les tests les plus importants par des tests automatisés.

En premier lieu, commencez par générer un jeu des cas de test manuel qui vérifient chaque récit utilisateur défini pour le sprint. Étant donné qu'il n'y a aucun code au démarrage d'un sprint, un cas de test doit définir les actions génériques qui mappent aux parties d'un récit utilisateur. Par exemple, une étape dans un cas de test peut être « En tant qu'utilisateur authentifié, veuillez ». Commencer par un cas de test manuel permet à votre équipe de définir rapidement des tests d'acceptation optimaux avant le démarrage d'un sprint.

Deuxièmement, révisez et mettez à jour des tests d'acceptation pour refléter des expériences utilisateur spécifiques lorsque le code produit par votre équipe implémente des récits utilisateur dans un sprint. Toutefois, si votre équipe ne souhaite pas modifier le jeu existant de tests d'acceptation, vous pouvez importer les tests dans une nouvelle suite de tests pour disposer d'un point de départ pour des tests plus détaillés. Par exemple, une étape dans un cas de test plus détaillé peut être « Tapez un nom dans la zone de texte Nom d'utilisateur et cliquez sur le bouton de connexion pour vous connecter au compte bancaire ».

Troisièmement, selon vos tests d'acceptation, créez les tests d'interface utilisateur codés à l'aide d'un enregistrement des actions. Pour plus d'informations, consultez Comment : générer un test codé de l'interface utilisateur à partir d'un enregistrement des actions. Les tests d'interface utilisateur codés peuvent générer un meilleur code si vous créez des étapes qui isolent les fonctionnalités. Vous pouvez exécuter des tests automatisés à partir de votre plan de test si vous joignez le test codé de l'interface utilisateur aux cas de test manuel (Pour plus d'informations, consultez Comment : associer un test automatisé à un cas de test.)

Les tests manuels définis au début d'un sprint peuvent vous aider à créer des tests automatisés. Il y a un coût associé à la fois aux tests manuels et automatisés parce que les tests manuels doivent être exécutés par une personne et les tests automatisés doivent être mis à jour si le code ou l'expérience utilisateur change. Pour plus d'informations, consultez ultérieurement Test manuel ou test automatisé dans cette rubrique.

Qui exécute les cas de test d'acceptation ?

Votre équipe, votre propriétaire de produit et vos clients peuvent exécuter des cas de test d'acceptation. Votre équipe doit les exécuter aussi souvent que possible pour fournir une ligne de base sur le jeu des tests qui doivent passer dans un sprint. Le propriétaire de produit et le client peuvent également exécuter les tests d'acceptation et peuvent exiger la vérification pour terminer le sprint avec succès.

Votre équipe peut utiliser Gestionnaire de tests Microsoft pour exécuter chaque cas de test d'acceptation et enregistrer une capture d'écran vidéo des résultats des tests. De cette façon, vous pouvez obtenir un enregistrement en texte clair des résultats des tests et pouvez également partager les résultats avec vos clients. Cela est utile lorsqu'il est difficile de créer des configurations obligatoires (par exemple, des configurations multi-serveur).

Définir des cas de test d'acceptation avec des récits utilisateur

Vous pouvez définir les critères d'acceptation après avoir défini des récits utilisateur. En définissant des tests d'acceptation, vous pouvez permettre à votre équipe de comprendre les critères d'acceptation du sprint actuel issus du propriétaire du produit et du client. Étant donné que le client doit accepter les tests d'acceptation, il est conseillé de créer les cas de test d'acceptation avant le début du sprint.

Test unitaire

Les tests unitaires sont des tests automatisés qui vérifient les fonctionnalités au niveau du composant, de la classe, de la méthode ou de la propriété. Les tests unitaires sont la base du test automatisé et du test de régression qui fournissent une stabilité à long terme et la maintenance future du projet.

Comment est-ce que les tests unitaires permettent de faire évoluer la conception de mon application ?

Le processus de création des tests unitaires au cours de la génération du code testé permet de définir la forme du code. Vous pouvez créer du code qui est testable à l'aide des tests unitaires. La difficulté de créer des tests unitaires pour le code est un signe que le code doit être refactorisé.

Comment faire pour organiser mes tests unitaires ?

Chaque membre de l'équipe chargé d'écrire le code doit créer des tests unitaires pour les composants qu'il génère et archiver le code de test unitaire dans le contrôle de version au sein d'un projet Visual Studio. Classez les éléments de travail du cas de test dans une suite de tests de vérification de build qui sera exécutée au cours de chaque build dans le cadre de l'intégration continue et également au sein de la suite de tests qui vérifie le récit utilisateur correspondant.

Comment faire pour gérer la variation des tests unitaires sans devoir modifier le code de test ?

La variation dans les entrées de test définit la ressemblance ou les différences entre les tests au cours de la vérification des fonctionnalités dans le code de projet. Par exemple, lors du test du composant d'ouverture de session d'une application Web, vous pouvez fournir plusieurs types de mots de passe pour créer un compte d'utilisateur. Le système peut avoir des règles pour l'ordre et la combinaison des types de caractères utilisés.

Visual Studio Test Professional 2010 fournit des fonctions pour l'écriture des tests unitaires pilotés par les données et des tests codés de l'interface utilisateur. Pour plus d'informations, consultez Comment : créer un test unitaire piloté par des données et Comment : créer un test codé de l'interface utilisateur piloté par des données.

Développement piloté par les tests et tests précoces

Le développement piloté par les tests est une discipline de conception et de programmation dans laquelle chaque ligne de code est écrite en réponse à un test que le programmeur écrit juste avant de coder. L'idée de devenir le consommateur du code que vous souhaitez implémenter est très puissante et permet d'entretenir une attente réaliste concernant l'élaboration et l'utilisation du code.

Dans le cadre du développement piloté par les tests, le développeur travaille dans de nombreux petits incréments. Le développement de chaque petit incrément dure entre quelques minutes et quelques heures. En général, ces nombreux incréments composent un récit utilisateur. Le développeur archive les tests et le code lorsque le récit utilisateur fonctionne. Le développeur travaille avec le cycle suivant :

1. Il écrit un test automatisé qui doit réussir lorsque l'incrément est écrit.

2. Il vérifie que le nouveau test échoue pour s'assurer que le test fonctionne.

3. Il écrit du code qui fera réussir le test.

4. Il exécute le test pour vérifier qu'il réussit.

5. Il exécute également tous les autres tests dans la même zone pour s'assurer qu'aucun bogue n'a été introduit.

6. Il refactorise le code, si nécessaire, pour améliorer sa structure sans ajouter de comportement. Il relance les tests pour s'assurer que le code fonctionne toujours.

7. Il répète toutes ces étapes jusqu'à ce qu'un récit utilisateur complet soit implémenté. À mesure que les incréments précédents sont intégrés dans un récit complet, il ajoute des tests qui vérifient l'ensemble du récit.

8. Il archive le code d'implémentation et les tests unitaires.

Si vous êtes intéressé par les avantages offerts par les méthodes des tests anticipés, vous pouvez commencer par créer des tests manuels (ou d'acceptation manuelle). Ces tests manuels peuvent être automatisés en créant un test codé de l'interface utilisateur. (Pour plus d'informations, consultez Comment : générer un test codé de l'interface utilisateur en enregistrant l'application testée.) Les tests d'intégration qui utilisent l'infrastructure de test unitaire dans Visual Studio ALM peuvent également être créés pour vérifier l'implémentation de fonctionnalités. Les groupes des cas de test créés précocement dans l'itération sont exécutés plus tôt dans l'itération pour tenter de vérifier à la fois les fonctionnalités et détecter des bogues. Ces suites de tests et cas de test peuvent être exécutés continuellement comme tests de régression durant la vie du projet. En continuant à exécuter ces tests, vous pouvez vérifier que les bogues trouvés et les fonctionnalités vérifiées tôt dans l'itération ne sont pas affectés ultérieurement par des modifications dans le projet.

Utiliser les tests unitaires pour l'intégration continue

Les tests unitaires créés grâce à la pratique des tests précoces doivent être organisés au sein de la suite de tests pour le sprint et le récit utilisateur en cours. Ces tests unitaires peuvent être encouragés dans le plan de test au niveau du projet et exécutés périodiquement par l'équipe et au sein du cycle d'intégration continue. Les tests unitaires peuvent également servir de base pour l'intégration, la charge et le test des performances.

Les tests unitaires créés au démarrage peuvent être utilisés dans le cadre de l'intégration continue. Pour plus d'informations sur la manière d'exécuter des tests durant une build, consultez TestToolsTask, tâche.

Utiliser la virtualisation pour gérer les configurations de test

Pour exécuter des tests unitaires, vous pouvez créer un ensemble d'environnements qui sont des images Hyper-V managées dans Gestionnaire de tests Microsoft. Pour plus d'informations sur l'exécution de tests automatisés depuis un plan de test à l'aide de Gestionnaire de tests Microsoft, consultez TestToolsTask, tâche.

Test manuel ou test automatisé

Les cas de test automatisé et manuel sont complémentaires. Les équipes agiles s'efforcent d'avoir plus de cas de test automatisé parce qu'elles encouragent des séries de tests fréquentes ou continues. Pour exécuter des tests en continu, elles doivent procéder rapidement et fréquemment, ce qui est difficile avec des tests manuels.

Il y a plusieurs considérations à prendre en compte lorsque vous décidez de la répartition entre les cas de test manuel et automatisé.

Comment est-ce que les compétences dans votre organisation influencent votre répartition des types de tests ?

Le propriétaire de produit définit les récits utilisateur du projet et doit également contribuer à la création des tests d'acceptation. Le propriétaire de produit ne produira sans doute pas de tests codés mais aura une connaissance significative du domaine d'activité. Les cas de test définis par le propriétaire de produit seront par conséquent au niveau du vocabulaire d'entreprise et des règles métier. Par exemple, un propriétaire de produit dans une société d'expédition spécifiera différents moyens de transport que l'entreprise prend en charge (par exemple, route, rail, air, mer ou une combinaison). Le propriétaire de produit peut définir ensuite plusieurs cas de test qui testent les différentes possibilités. Pour ces tests manuels, il est important de spécifier le nombre minimal de tests qui teste les différentes options (dans ce cas, les modes d'expédition).

Les membres de l'équipe qui produisent le code peuvent générer des tests codés de l'interface utilisateur qui peuvent être basés sur les tests manuels ou indépendant de tout autre test. (Pour plus d'informations, consultez How to: Generate a Coded UI Test by Recording the Application Under Test). Les tests codés de l'interface utilisateur doivent être pris en charge par les membres de l'équipe qui ont la capacité de gérer et développer le code du projet.

Quand est-ce que vous devez convertir les tests manuels en tests automatisés ou créer des tests automatisés dès le début ?

Vous pouvez créer des tests automatisés lorsque vous vous attendez à répéter des tests pour maintenir la stabilité de votre code. Il est important de prendre en considération l'effort de création des tests automatisés car l'investissement dans l'automatisation affecte les ressources de votre équipe. Créer des tests automatisés lorsque le code connait une évolution réduite offre un meilleur retour sur investissement en raison d'une faible évolution du test. Toutefois, la création de l'automatisation précoce offre un avantage car elle permet de découvrir des problèmes à la fois dans la logique et la conception. Dans les deux cas, les ressources obligatoires pour prendre en charge du code de test automatisé doivent être prises en compte.

Après avoir décidé qu'un jeu de tests doit être automatisé, passez à l'achèvement de l'automatisation le plus rapidement possible pour profiter des avantages qu'elle offre dans la gestion de la stabilité du code. La stabilité et nombre des défauts recherchés comme l'automatisation est écrite affectera l'effort qui est obligatoire pour compléter l'automatisation. Finalement, l'équilibre entre les tests automatisés et les tests manuels repose sur l'ordre des priorités entre les genres des tests qui doivent être construits et exécutés pendant la vie du projet.

Quels types de tests sont automatisés ?

Tests unitaires

Les tests unitaires vérifient les fonctionnalités dans le code ou via un processus tel que le développement piloté par les tests. Les tests unitaires sont importants parce qu'ils aident à maintenir la stabilité et les dépendances au sein du code. Le développement piloté par les tests a tendance également à produire une meilleure conception avec des dépendances et une bonne définition de couche parce qu'il vous aide à comprendre la conception du point de vue du consommateur du code.

Tests de charge

Vous pouvez créer des tests de charge basés sur les cas de test automatisé existants ou vous pouvez créer des tests qui génèrent des types spécifiques de charges sur les applications ou les services. Pour plus d'informations sur l'utilisation des contrôleurs d'agent de test et des agents de test pour générer des charges de test simulées, consultez Comment : exécuter un test à l'aide des contrôleurs de test et des agents de test.

Pour plus d'informations sur le test de charge à l'aide de Visual Studio ALM, consultez la page suivante sur le site Web Microsoft : Fonctionnement des tests de charge.

Tests d'intégration continue

Vous pouvez utiliser l'intégration continue avec Visual Studio ALM pour vous assurer que chaque fois que du code est développé et archivé, il fonctionne correctement avec le code existant. L'intégration continue est critique au fur et à mesure de l'évolution de l'équipe et de la base de code. Vous pouvez définir un type de build qui inclut des paramètres de test et spécifier les tests à exécuter au terme de la build. Pour plus d'informations sur la définition d'une build qui exécute des tests, consultez Définir une build à l'aide du modèle par défaut.

Quels types de tests peuvent être automatisés ?

Test de configuration

Tester des environnements multiples installés peut être une tâche très laborieuse. Gestionnaire de tests Microsoft fournit des fonctions d'exécution de suites de tests sur différentes configurations à l'aide d'ordinateurs virtuels ou d'ordinateurs physiques. Pour plus d'informations sur l'exécution des tests et la collecte des données dans des environnements multiples, consultez Configuration d'ordinateurs de test pour exécuter des tests ou collecter des données.

Tests d'interface utilisateur

Visual Studio ALM a des fonctions permettant de créer directement des tests automatisés pour l'interface utilisateur. Pour plus d'informations sur la création de tests d'interface utilisateur codés, consultez Comment : créer un test codé de l'interface utilisateur.

Tests d'installation

Vous pouvez utiliser les fonctions de laboratoire de Gestionnaire de tests Microsoft pour configurer un groupe de configurations que vous pouvez utiliser pour vérifier si les programmes d'installation de vos applications fonctionnent comme prévu.

Quels sont les freins à l'automatisation ?

Compétences de l'équipe

La création de l'automatisation nécessite l'apprentissage de l'écriture du code par un sous-ensemble de l'équipe des tests. Intégrez à votre plan la durée d'apprentissage de la création de l'automatisation et la conception du code de test. Semblable au code de production, l'élaboration du code d'automation doit répondre à vos objectifs, tels que la facilité de maintenance, la simplicité de composition, et la longévité.

Pour plus d'informations sur la création de tests automatisés à l'aide de Visual Studio Test Professional 2010, consultez Création de tests automatisés.

Évolution du code

Le code qui change fréquemment est une cible en mouvement et aura des effets en cascade dans le code d'automation de test parce qu'il devra également être changé. Évitez ces effets en cascade en créant un code d'automation de test pour les composants et les interfaces qui sont moins susceptibles de changer.

Conception du code

Codez les infrastructures telles qu'ASP.NET MVC et MVVM guident les membres de l'équipe à écrire du code qui possède l'isolement nécessaire pour vérifier les parties différentes du code. Le code lié étroitement à l'interface utilisateur est difficile à tester parce qu'il peut nécessiter l'interaction de l'utilisateur avec les contrôles de l'interface utilisateur.

Quels sont les avantages des cas de test manuel ?

Les cas de test manuel offrent les avantages suivants :

• Les tests manuels permettent à l'équipe de détecter les bogues au cours du processus d'exploration.

• Les cas de test manuel sont faciles à définir parce que vous pouvez définir le jeu d'étapes à tout niveau d'abstraction et définir les critères de réussite et d'échec selon vos termes.

• Il est très facile de commencer à écrire des cas de test manuel précocement dans le projet avant l'écriture de tout code. Cela est important pendant le processus de la définition de tests d'acceptation.

• Si vous utilisez Visual Studio Test Professional 2010, les cas de test peuvent être composés d'étapes partagées, ce qui permet d'économiser du temps lors de la définition de tests semblables et permet à l'équipe de réutiliser une version unique d'un sous-ensemble du test. L'utilisation d'étapes partagées est aussi utile lors de la modification de cas de test parce qu'une modification apportée aux étapes partagées affecte automatiquement tous les cas de test qui utilisent les étapes partagées. Pour plus d'informations sur la création de diagrammes et l'utilisation des étapes partagées, consultez How to: Share Common Test Case Steps Using Shared Steps.

• Les cas de test manuel peuvent servir de moyen de communication tôt dans le projet ou le sprint.

• Les cas de test manuel peuvent servir de moyen de documentation d'un cas de test automatisé sans que quiconque examine le code.

• Si vous utilisez Visual Studio ALM, l'exécution de tests manuels peut rassembler des métriques de couverture du code.

Quels sont les désavantages des cas de test manuel ?

Les cas de test manuel ont les désavantages suivants :

• La définition des critères de réussite peut être compliquée parce qu'elle dépend de la perspective et du langage utilisés dans la définition du test. Certains langages peuvent être interprétés différemment, ce qui est source d'erreur possible.

• L'exécution des suites de tests qui incluent des cas de test manuel requiert qu'une personne suive physiquement les étapes de test et les résultats de rapport. Ce processus peut exiger beaucoup de temps et, par conséquent, peut nécessiter un nombre croissant de membres de l'équipe pour exécuter des tests ou un nombre accru d'heures pour exécuter la suite de tests. Avec Visual Studio Test Professional 2010, l'équipe peut utiliser « un test manuel en mode accéléré » dans lequel les actions sont enregistrées pendant le test pour être exécuté ensuite dans les futures séries de tests.

• Selon la stabilité du code, le temps et l'effort nécessaires à l'exécution des tests varient. Par conséquent, l'exécution de tests manuels peut affecter le flux dans l'équipe.

• Le désavantage le plus net est que les tests manuels pour détecter un bogue sont sujets à l'erreur humaine. Les testeurs peuvent avoir le bogue sous leurs yeux et ne pas le reconnaître.

Quels sont les avantages des cas de test automatisé ?

Les cas de test automatisé offrent les avantages suivants :

• Les tests automatisés aident à maintenir la stabilité et permettent de rechercher les régressions qui peuvent se produire à cause des modifications du code.

• Les tests automatisés peuvent être exécutés sans assistance.

• Les tests automatisés sont des logiciels et peuvent être conçus ou contenir d'autre code réutilisable. Cela les rend flexibles et faciles à maintenir.

• L'automatisation peut être exécutée sur plusieurs configurations au moyen de Gestionnaire de tests Microsoft.

• Les métriques de couverture du code peuvent être rassemblées lorsque les tests automatisés sont exécutés.

Quels sont les désavantages des cas de test automatisé ?

Les cas de test automatisé ont les désavantages suivants :

• Des conditions spéciales sont à prendre en compte et à implémenter à l'aide du code. Lorsque l'automatisation est créée et exécutée, les conditions supplémentaires seront implémentées lorsqu'elle apparaissent.

• Lorsque le code est changé ou refactorisé, il peut y avoir des effets de cascade qui nécessiteront un effort correspondant pour modifier les tests automatisés affectés.

• Il peut y avoir un impact psychologique sur votre équipe lorsque les modifications du code provoquent l'échec de nombreux tests. Si ces tests sont utilisés comme des indicateurs, l'équipe ne peut pas déclencher tous les indicateurs.

• Il peut y avoir un faux sentiment de sécurité lorsque tous les tests réussissent si les cas de test ne testent pas les conditions correctes. Il est important de maintenir les suites de tests et de s'assurer qu'elles vérifient les conditions et résultats corrects.

Création des rapports des résultats de test

Dans une perspective agile, la création de rapports et l'interrogation de Team Foundation Server sur l'état actuel de la qualité, à partir des bogues ou des métriques rassemblées, est la partie de la boucle des commentaires qui permet à l'équipe d'itérer et d'apporter des modifications au code, au plan de projet et au plan de test. Pour plus d'informations, consultez Progression du plan de test, rapport.

Quels niveaux du test doivent être signalés à votre équipe ?

Avec Visual Studio Test Professional 2010 et Team Foundation Server, votre équipe peut connaître l'état de la planification et l'exécution de tests. Team Foundation Server stocke vos plans de test, suites de tests, cas de test, résultats des tests et toutes les autres données connexes générées durant votre processus de test. Vous pouvez visualiser le processus du test et le contrôle qualité si vous associez Gestionnaire de tests Microsoft à la création de rapports et aux requêtes d'élément de travail dans Team Foundation Server. Vous pouvez utiliser Gestionnaire de tests Microsoft pour rechercher des bogues dans divers états. Les bogues marqués comme corrigés par d'autres membres de l'équipe doivent avoir l'état Résolu. Vous pouvez utiliser les builds suivantes pour vérifier les bogues corrigés. Pour plus d'informations sur la façon de vérifier si un bogue a été corrigé, consultez Comment : vérifier si un bogue est corrigé à l'aide du Gestionnaire de tests Microsoft.