T (Glossaire de Visual Studio Team System)

Mise à jour : novembre 2007

Ce glossaire définit les termes clés utilisés dans l'aide de Visual Studio Team System.

• tâche [task]
  Type d'élément de travail qui enregistre une tâche de développement ou une tâche de test.

• tâche de développement [development task]
  Unité de travail de développement assignée qui est habituellement créée pour générer une partie de scénario ou de spécification de qualité de service. La tâche de développement décrit l'objectif du développeur dans le contexte d'une itération.

• tâche de test [test task]
  Assignation pour créer des scénarios de test et tester une zone spécifique du produit, généralement dans le contexte d'un scénario ou d'une spécification de qualité de service.

• TDS (Tabular Data Stream) [tabular data stream (TDS)]
  Protocole interne pour transférer des données entre un client et un serveur qui exécute Microsoft SQL Server. TDS permet aux produits du client et du serveur de communiquer, quels que soient le système d'exploitation, la version du serveur ou le protocole réseau.

• Team Dev
  Partie de Visual Studio Team System qui cible de manière spécifique les membres de l'équipe qui jouent le rôle de développeur.

• Team Foundation Server
  Ensemble d'outils et de technologies permettant à une équipe de collaborer et de coordonner ses efforts afin de générer un produit ou d'exécuter d'un projet. Ces outils englobent le contrôle de code source, le suivi des éléments de travail, la génération (build), le portail de projet d'équipe, la création de rapports et la gestion de projets.

• Team Test
  Assembly de code responsable du chargement d'un type de test particulier.

• temps de réflexion [think time]
  Durée écoulée entre la réception d'une réponse à une requête et la soumission de la requête suivante. Par exemple, s'il faut environ 60 secondes à un utilisateur pour entrer toutes les informations requises pour un formulaire d'entrée de temps basé sur le Web, 60 secondes est le temps de réflexion pour ce scénario.

• temps du noyau [kernel time]
  Temps passé à l'exécution en mode noyau lors de l'exécution d'une application en mode utilisateur. Comprend le temps passé en E/S disque et en attente d'événements de synchronisation. Le temps du noyau est toujours approximatif dans notre profileur.

• temps exclusif [exclusive time]
  Temps total passé dans cette fonction ou ce module, à l'exception du temps passé dans les fonctions ou modules appelés à partir de cette fonction.

• temps exclusif d'application [application exclusive time]
  Temps passé dans la fonction en mode noyau et les sondes des outils d'analyse des performances, à l'exception du temps passé dans les éléments appelés et dans les transitions.

• temps exclusif écoulé [elapsed exclusive time]
  Temps passé dans la fonction, à l'exception du temps passé dans les éléments appelés. Voir aussi : temps inclusif écoulé

• temps inclusif [inclusive time]
  Temps total passé dans cette fonction ou ce module, y compris le temps passé dans les fonctions ou modules appelés à partir de cette fonction.

• temps inclusif d'application [application inclusive time]
  Temps passé dans la fonction et les éléments appelés, à l'exception du temps passé dans les transitions en mode noyau et les sondes des outils d'analyse des performances.

• temps inclusif écoulé [elapsed inclusive time]
  Temps passé dans la fonction et les éléments appelés. Voir aussi : temps exclusif écoulé

• temps pour la résolution de bogues [bug allotment]
  Période de développement allouée à la résolution des bogues. Un temps pour la résolution de bogues est créé en laissant des périodes creuses dans le plan d'itération.

• test automatisé [automated test]
  Ensemble d'étapes qu'un ordinateur peut effectuer par programme pour tester la fonctionnalité du système.

• test boîte noire [black box test]
  Test basé sur le comportement réel d'un composant sans tenir compte de son implémentation.

• test d'acceptation [acceptance testing]
  Test formel effectué pour permettre à un utilisateur, un client ou toute autre entité autorisée de déterminer s'il convient d'accepter un produit ou composant de produit.

• test d'acceptation de build [build acceptance test]
  Voir test de vérification de build

• test de charge [load test]
  Type de test qui contient d'autres types de tests et les applique avec des paramètres utilisateur simulés pour réaliser un scénario de charge prédéfini.

• test de contrainte [stress test]
  (1) Test conçu pour déterminer la réponse d'un système en conditions de charge. (2) Pour MSF Agile : test qui détermine les points de rupture d'une application et pousse l'application au-delà de ses limites supérieures à mesure que les ressources sont saturées.

• test de performances [performance test]
  Test qui garantit que la spécification de qualité de service concernant les performances est satisfaite. Un test de performances vérifie non seulement que les fonctions sont opérationnelles, mais également la durée nécessaire à l'exécution de ces fonctions.

• test de régression [regression test]
  Test exécuté après la build diurne pour vérifier que la compilation du code source a été effectuée avec succès.

• test de sécurité [security test]
  Collection d'utilisateurs, d'ordinateurs, de contacts et d'autres groupes utilisée pour accorder l'accès aux ressources.

• test de validation [validation test]
  Test qui garantit que la fonctionnalité requise dans un scénario ou une spécification de qualité de service fonctionne.

• test de vérification [check-in test]
  Test exécuté par un développeur pour déterminer si son code a affecté la stabilité globale du produit.

• test de vérification de build [build verification test (BVT)]
  Également connu sous le nom de test de détection de fumée (smoke test). Groupe de tests utilisés pour déterminer l'état global d'une build. Ces tests vérifient en général les fonctionnalités principales afin d'aider les membres de l'équipe à déterminer si des tests plus approfondis valent la peine d'être effectués. Ils sont exécutés après la build diurne pour vérifier que la compilation du code source a été effectuée avec succès et est disponible pour des tests plus approfondis.

• test en attente [pending test]
  Test sélectionné pour être exécuté, mais pas encore en cours d'exécution. Les tests en attente peuvent être consultés dans la fenêtre Résultats des tests.

• test générique [generic test]
  Type de test Visual Studio connu qui encapsule un test ou outil inconnu, et permet à Visual Studio de le traiter comme un type connu.

• test manuel [manual test]
  Test exécuté par un être humain, généralement capturé dans un document texte ou Word qui répertorie les étapes.

• test partenaire [Partner Test]
  Test, écrit par un partenaire de Microsoft, qui utilise les interfaces d'extensibilité de l'infrastructure de test.

• test unitaire [unit test]
  Test qui confirme les fonctions et performances de modules et comportements spécifiques du code. Souvent, un sous-ensemble de tests unitaires est utilisé comme tests de vérification pour détecter les bogues avant une génération.

• test unitaire de base de données [database unit test]
  Test unitaire qui valide le fonctionnement attendu d'un certain aspect de votre base de données.

• test Web [Web test]
  Type de test qui cible la validation des pages Web et requêtes HTTP.

• test Web codé [coded Web test]
  Type de test créé en règle générale en convertissant un test Web enregistré existant en code C# ou Visual Basic.

• test
  Programme, script (manuel ou automatique), série d'étapes spécifique ou instructions générales qui peuvent être exécutés de façon répétée sur un logiciel à tester, et qui génèrent un résultat de test, tel que réussite, échec ou d'autres résultats qui sont convertis en réussite ou échec, par exemple non concluant.

• tests aléatoires [fuzz testing]
  Fournissent des entrées structurées, mais non valides à des interfaces de programmation d'application (API) logicielles et à des interfaces réseau de façon à optimiser la probabilité de détection d'erreurs pouvant mener à des vulnérabilités logicielles.

• tests de détection de fumée [smoke tests]
  Voir : tests de vérification de build

• tests déclaratifs [declarative tests]
  Tests Web ordinaires qui sont générés à l'aide de l'enregistreur de test Web qui est lancé lorsqu'un test Web est créé.

• tests d'itération [iteration tests]
  Ensemble de tests exécutés après les tests de vérification de build. Ces tests vérifient les fonctionnalités requises dans le plan d'itération.

• tests exploratoires [exploratory testing]
  Tests d'un produit sans qu'un ensemble de tests n'aient été définis au préalable. Les testeurs qui exécutent des tests exploratoires prennent l'identité d'un personnage et effectuent les tâches que ce personnage effectuerait.

• tests ordonnés [ordered tests]
  Transactions de tests qui exécutent un ensemble de tests dans un ordre défini et peuvent échouer si un seul test contenu échoue.

• transaction
  Mécanisme de gestion des changements dans lequel chaque groupe de modifications apportées à un modèle peut être validé ou annulé en une même opération. Vous pouvez effectuer des modifications à l'aide du concepteur de langage spécifique au domaine ou en écrivant du code personnalisé.

• transitions exclusives [exclusive transitions]
  Nombre de transitions entre le mode utilisateur (anneau 3) et le mode noyau (anneau 0) dans une fonction, à l'exception des transitions dans les éléments qu'elle appelle.

• transitions inclusives [inclusive transitions]
  Nombre de transitions entre le mode utilisateur (anneau 3) et le mode noyau (anneau 0) dans une fonction et les éléments qu'elle appelle.

• triage
  Processus utilisé pour passer en revue les bogues nouvellement signalés ou rouverts et pour leur assigner une priorité et une itération.

• type de test [test type]
  Ensemble de fonctions et/ou modèle permettant d'exposer des parties de l'infrastructure de test Visual Studio sous-jacente.

• type d'élément de travail [work item type]
  Définition nommée associée à un projet dans Team Foundation Server. Les types sont constitués de champs, d'un formulaire et d'un flux de travail. Ils sont définis à l'aide de XML. Les définitions sont portables entre serveurs Team Foundation Server.