Partager via

Dépannage de l'exécution de tests

  • Article

Mise à jour : novembre 2007

Si un test ne s'exécute pas, vous pouvez analyser l'échec en vérifiant l'environnement de test, y compris la manière dont le test est configuré et les paramètres de la configuration de série de tests active. Dans certains cas, tels que ceux en rapport avec le déploiement, les échecs sont indépendants du type de test. Dans d'autres cas, le type de test détermine les éléments à étudier et la manière à employer. Pour obtenir des conseils d'investigation par type de test, consultez Détails par type de test.

Les erreurs qui impliquent des tests vous sont signalées à l'un des deux niveaux suivants :

  • Erreurs de niveau test. Dans la fenêtre des résultats du test, vous pouvez double-cliquer sur le résultat du test ou cliquer avec le bouton droit sur le résultat du test, puis sélectionner Afficher les détails des résultats des tests. Cela affiche une page [Détails] de test qui affiche des messages d'erreur et d'autres détails, selon le type de test, tels que des informations de trace de la pile pour les tests unitaires. Une erreur de délai d'attente de test constitue un exemple d'erreur de niveau test ; elle se produit si la limite de délai d'attente du test est atteinte.

  • Erreurs de niveau d'exécution. Les erreurs de niveau d'exécution, qui incluent les erreurs de configuration de séries de tests, sont signalées par le biais de la fenêtre Résultats des tests. Lorsqu'une erreur de niveau d'exécution se produit, un lien apparaît sur la barre d'état de la fenêtre Résultats des tests. Un clic sur ce lien permet d'afficher davantage de détails à propos de l'erreur sur la page Série de tests [Détails]. Vous pouvez également afficher la page Série de tests [Détails] en cliquant sur Détails de l'exécution dans la barre d'outils de la fenêtre Résultats des tests. Une erreur de délai d'attente d'exécution constitue un exemple d'erreur de niveau d'exécution ; elle se produit si la limite de délai d'attente d'exécution est atteinte.

Tous les problèmes n'entraînent pas l'échec d'exécution d'un test. Une fois que vous avez choisi d'obtenir des données de couverture du code, l'exécution des tests peut générer un avertissement si certains paramètres de génération ont été sélectionnés pour votre projet. Pour plus d'informations, consultez Utilisation du paramètre de génération AnyCPU lors de l'obtention de données de couverture du code.

Erreurs de déploiement

Certaines erreurs peuvent être rencontrées pour tout test qui peut s'exécuter automatiquement, ce qui signifie tout type de test autre que les tests manuels. Ces erreurs sont souvent liées au déploiement de tests. Lorsqu'un test est déployé, le fichier qui le contient est copié dans un autre dossier, à un emplacement sur l'ordinateur local ou un ordinateur distant. Pour plus d'informations, consultez Déploiement de test.

Pour les tests unitaires, par exemple, le fichier .dll qui a été généré à partir du projet de test est le fichier qui doit être déployé. Si ce fichier binaire ne peut pas être déployé, tout test unitaire qu'il contient est marqué immédiatement comme Échec dans la fenêtre Résultats des tests lorsque vous l'exécutez.

Pour corriger cette erreur, vérifiez que les fichiers sont disponibles sur votre ordinateur local et qu'il n'y a pas eu d'erreurs de génération la dernière fois que vous avez régénéré vos binaires de test.

Il n'y a pas que les fichiers binaires qui peuvent être déployés. Vous pouvez spécifier qu'un fichier particulier, tel qu'un fichier de données, est requis par un test et doit par conséquent être déployé avec le test. Au moment du déploiement, si ce fichier est introuvable car il a été déplacé ou supprimé, le test ne peut pas s'exécuter correctement et une erreur se produit. Consultez également Détails par type de test pour plus d'informations sur cette erreur quant aux tests génériques.

Pour étudier cette erreur, notez d'abord les fichiers et dossiers spécifiés sur la page Déploiement de la boîte de dialogue utilisée pour modifier les configurations de série de tests. Pour plus d'informations, consultez Comment : spécifier la configuration d'une série de tests. Vérifiez ensuite ces fichiers et dossiers sur le disque afin de vous assurer qu'ils sont présents et que leurs noms sont identiques.

Votre solution peut avoir plusieurs fichiers de configuration de série de tests. Si c'est le cas, veillez à examiner la configuration de série de tests qui était active lorsque l'erreur de test s'est produite. Pour déterminer la configuration de série de tests qui était active, recherchez cette série de tests sur la page Détails de la série de tests. Pour plus d'informations, consultez la section « Page Détails de la série de tests » dans Résultats de tests rapportés.

Pour plus d'informations sur les fichiers de configuration de série de tests active, consultez Comment : appliquer une configuration de série de tests.  

Erreurs dans le signalement des résultats de tests distants

Lorsque vous exécutez des tests à distance, les résultats des tests peuvent ne pas s'afficher. Cette erreur est probablement liée à la nature distante de la série de tests.

Tout comme les résultats des séries de tests locales, les résultats des séries de tests distantes vous sont signalés localement. Le signalement de certains résultats de tests distants dépend de la capacité de Visual Studio Team System Test Edition à copier les fichiers de résultats de tests générés de l'ordinateur de test distant vers votre ordinateur local.

Si des erreurs se produisent avec les résultats de tests distants, commencez par déterminer si la connexion réseau entre l'ordinateur distant et l'ordinateur sur lequel vous exécutez Visual Studio a été interrompue.

Pour plus d'informations, consultez Dépannage des contrôleurs, agents et plateformes de test.

Erreurs d'instrumentation

Pour activer la création de rapport de couverture du code, les fichiers binaires qui sont testés doivent être instrumentés puis déployés avant que des tests soient exécutés sur eux.

La non-instrumentation du fichier binaire provoque l'échec de la création de rapport de couverture du code. Une fois la série de tests terminée, la page Détails de la série de tests affiche un message d'erreur qui signale que la couverture du code n'a pas pu être rapportée et qui stipule également la cause de l'échec.

Les causes possibles de l'échec d'instrumentation d'un fichier binaire sur place sont son marquage en lecture seule ou son utilisation actuelle par un autre processus. Pour corriger l'erreur liée à un fichier binaire en lecture seule, examinez d'abord les attributs du fichier binaire afin de vous assurer qu'il est accessible en écriture. Pour savoir quels fichiers binaires vérifier, ouvrez la page Couverture du code de la configuration de série de tests active ; c'est à cet endroit que vous avez spécifié les fichiers pour l'instrumentation. Pour plus d'informations, consultez Comment : obtenir des données de couverture du code.

Une autre cause d'échec de couverture du code lors du recours à une instrumentation sur place peut se produire lorsque vous utilisez un ou plusieurs tests unitaires avec un test manuel. Pendant le test manuel, le testeur exécute le code de production qui est testé. Si le testeur appuie sur F5 ou CTRL+F5 pour démarrer ou déboguer le code, le fichier exécutable du projet est régénéré, ce qui supprime l'instrumentation.

Assurez-vous également qu'aucun autre processus n'utilise le fichier binaire. Par exemple, assurez-vous que le fichier n'est pas ouvert dans une autre instance de Visual Studio.

Lorsque vous instrumentez un Assemblys avec nom fort, vous pouvez rencontrer d'autres erreurs liées à la nouvelle signature de l'assembly. Pour plus d'informations, consultez Instrumentation et nouvelle signature d'assemblys.

Fermer les résultats des tests pour améliorer les performances

Pour améliorer les performances de Visual Studio, fermez les résultats des tests anciens.

Lorsque vous effectuez des tests, Visual Studio conserve les séries et les résultats des tests en mémoire. Plus les séries et les résultats de tests s'accumulent, plus la mémoire allouée est importante. Vous pouvez supprimer des séries de tests de la mémoire en cliquant sur Fermer les résultats dans la barre d'outils de la fenêtre Résultats des tests. Cette opération supprime des objets de résultats des tests, mais n'appelle pas explicitement le garbage collector. Ainsi, la mémoire se libère, mais pas nécessairement immédiatement.

Vous pouvez également définir le nombre maximal de séries de tests à conserver en mémoire. Pour plus d'informations, consultez Comment : limiter le nombre de séries de tests stockées.

Utilisation du paramètre de génération AnyCPU lors de l'obtention de données de couverture du code

Vous ne pouvez obtenir des données de couverture du code que lorsque vous testez du code dans des assemblys 32 bits. Pour garantir cette condition, définissez une propriété de génération particulière :

Remarque :

Cet avertissement ne s'applique pas aux projets C++, car AnyCPU n'est pas un choix de plateforme pour ces projets.

Si vous générez votre projet avec la valeur AnyCPU, les tests exécutés sur l'assembly obtenu produisent des données de couverture du code, mais la série de tests génère également un avertissement. Vous pouvez consulter le texte de l'avertissement sur la page Détails de la série de tests :

Warning VSP2013 : Instrumenting this image requires it to run as a 32-bit process.  The CLR header flags have been updated to reflect this.

Cet avertissement signifie que l'assembly a été recompilé avec la propriété x86 appliquée pour obtenir des données de couverture du code pendant cette série de tests. Pour éviter cet avertissement, compilez les assemblys pour lesquels vous souhaitez des données de couverture du code avec le paramètre x86.

Remarque :

Si votre application est destinée à s'exécuter sur des ordinateurs 32 bits et 64 bits, n'oubliez pas de la recompiler avec le paramètre AnyCPU une fois le test terminé.

L'exécution de tests unitaires peut verrouiller un assembly de test C++/CLI

Vous pouvez rencontrer une situation dans laquelle le moteur d'exécution de tests ouvre et verrouille un assembly dans votre projet de test. Lorsque cela arrive, vous ne pouvez pas, par exemple, enregistrer les modifications effectuées dans l'assembly. Ce problème peut se produire dans les situations suivantes :

  • Cas 1 : vous avez désactivé le déploiement de votre projet de test, ProjetTestA. ProjetTestA a été compilé en C++/CLI. Le code de ProjetTestA définit une classe d'attributs et cet attribut décore au moins l'une des méthodes de test de ProjetTestA. À ce stade, lorsque vous exécutez des tests unitaires dans ProjetTestA, le moteur d'exécution de tests ouvre ProjetTestA.DLL et peut le quitter dans un état verrouillé.

  • Cas 2 : votre projet de test, ProjetTest1, contient une DLL qui a été compilée à partir d'un deuxième projet de test, ProjetTest2. ProjetTest2 a été compilé en C++/CLI. Le code de ProjetTest2 définit une classe d'attributs et cet attribut décore au moins l'une des méthodes de test de ProjetTest2. À présent, lorsque vous exécutez des tests unitaires dans ProjetTest1, le moteur d'exécution de tests ouvre ProjetTest2.DLL et peut le quitter dans un état verrouillé.

Dans ces deux cas, la solution peut être composée de deux parties. En premier lieu, exécutez les étapes suivantes.

  1. Dans le menu Outils, sélectionnez Options.

    La boîte de dialogue Options s'ouvre.

  2. Développez Outils de test et cliquez sur Exécution de tests.

  3. Sous Performances, désactivez la case à cocher en regard de Maintenir le fonctionnement du moteur d'exécution des tests entre les séries de tests.

Après avoir effectué ces étapes, si le problème persiste, procédez comme suit :

Modifiez votre code afin que le projet de test compilé en C++/CLI n'ait pas à être chargé dans l'AppDomain par défaut. Une façon de faire ceci consiste à déplacer les définitions des attributs personnalisés que vous utilisez dans un assembly séparé implémenté en C#.

Détails par type de test

Certaines erreurs se produisent fréquemment ou principalement pendant que vous exécutez des types de tests particuliers, comme décrit dans cette section.

  • Tests manuels Les tests manuels ne peuvent pas être exécutés à distance. Lorsque vous essayez de démarrer une série de tests qui inclut un test manuel, Visual Studio Test Edition essaie de supprimer le test manuel de la série de tests. Lorsque cela se produit, vous en êtes alerté et invité à annuler la série de tests ou à la laisser se poursuivre sans le test manuel. Pour plus d'informations, consultez Boîtes de dialogue de Test Edition.

  • Tests ordonnés Les erreurs rencontrées avec les tests ordonnés impliquent souvent le déploiement de fichiers. Pour que le moteur de test puisse exécuter un test ordonné, il doit rechercher puis déployer tous les fichiers de test de tous les tests contenus, en plus de tous les autres fichiers requis. La non-exécution de cette opération pour tout test provoque une erreur.

  • Tests génériques Des erreurs de déploiement peuvent également se produire lorsque vous exécutez des tests génériques. Vous pouvez spécifier des fichiers à déployer de deux manières pour les tests génériques : sur la page Déploiement de la configuration de série de tests et sur la page de création du test générique lui-même. Le test peut échouer si vous négligez de répertorier tous les fichiers nécessaires ou si les Outils de test Team System ne peuvent pas trouver ces fichiers aux emplacements spécifiés.

    Ces deux manières différentes de déployer des fichiers provoquent l'apparition d'erreurs à différents niveaux. Si l'erreur de déploiement est liée à un fichier spécifié dans la page de création du test générique, elle fera surface au niveau du test. Si l'erreur de déploiement est liée à un fichier spécifié dans la configuration de série de tests, elle fera surface au niveau de la série de tests.

Voir aussi

Tâches

Comment : définir des limites de temps pour l'exécution des tests

Concepts

Boîtes de dialogue de Test Edition

Résultats de tests rapportés

Instrumentation et nouvelle signature d'assemblys

Tests unitaires et C++

Autres ressources

Déploiement de test

Configuration de l'exécution de tests