Guide de l utilisateur de TestDirector Synchronizer

Transcription

1 Guide de l utilisateur de TestDirector Synchronizer

2 Borland Software Corporation 100 Enterprise Way Scotts Valley, California Les applications mentionnées dans ce manuel sont brevetées, ou en attente de brevet, par Borland Software Corporation. Reportez-vous au CD ou à la boîte de dialogue A propos pour avoir la liste des brevets. Ce document ne donne aucun droit sur ces brevets. COPYRIGHT Borland Software Corporation. Tous droits réservés. Tous les noms de marques et de produits Borland sont des marques de fabrique ou des marques déposées de Borland Software Corporation aux Etats-Unis et dans d'autres pays. Tous les autres produits sont la propriété de leurs fabricants respectifs. Pour connaître les conditions et limites des fournisseurs tiers, lisez les Notes de mises à jour sur le CD du produit.

3 Table des matières Chapitre 1 Préface 1 Comment contacter les services de support Borland Conventions de la documentation Chapitre 2 Utilisation de TestDirector 3 Installation de TestDirector Synchronizer Synchronisation des applications Création de champs personnalisés Personnalisation des champs dans TestDirector. 6 Personnalisation des champs dans StarTeam... 7 Dépannage Définition de l indicateur de synchronisation Champs trop longs Champs mémo : Considérations particulières... 8 Utilisation des champs vides Mappage de champs de type énumération avec des champs texte Utilisation d une vue en lecture seule Chapitre 3 Présentation du fichier de propriétés de Synchronizer 11 Présentation des directives Spécification de synchronisations multiples Utilisation des directives StarTeam Utilisation des directives TestDirector Copie des pièces jointes Utilisation des directives de mappage Propriété (mode de fonctionnement des opérateurs) Exigences et limites associées aux mappages.. 18 Mise à jour des fichiers de propriétés Synchronizer Chapitre 4 Exécution de Synchronizer 21 Modification des fichiers batch Examen des fichiers journaux Chapitre 5 Champs Demande de modification 23 Chapitre 6 Champs Défaut TestDirector 37 Annexe A Fichier de propriétés initial de Synchronizer 45 Annexe B Fichiers batch initiaux de Synchronizer 51 run.bat (Windows server) run-again.bat (Windows server) Annexe C Configuration système 55 Configuration requise pour Synchronizer Autres conditions Index 57 i

4 ii

5 Chapitre 1 Chapitre 1Préface Important Ce manuel explique comment synchroniser deux applications qui réalisent le suivi des défauts : l édition Entreprise ou Entreprise Advantage de StarTeam et TestDirector. StarTeam TestDirector Synchronizer vous permet d enregistrer les défauts générés par TestDirector sous forme de demandes de modification StarTeam, et vice versa. Dans ce guide, toutes les références à StarTeam sont des références à l édition Entreprise ou Entreprise Advantage de StarTeam, car seules ces éditions vous permettent de créer les champs personnalisés requis par Synchronizer. De même, les références au serveur StarTeam sont des références à l édition Entreprise ou Entreprise Advantage du serveur. Le manuel en ligne est au format Adobe Portable Document Format (.pdf) et nécessite la version 4.0 (ou ultérieure) du logiciel Acrobat Reader pour être affiché. La version gratuite de ce logiciel est disponible sur le site Web d Adobe à l adresse : Comment contacter les services de support Borland Borland Software Corporation s est engagé à fournir des services de classe internationale dans le domaine du consulting et du support technique. Nous avons plus de 15 ans d expérience dans le support aux développeurs et aux entreprises. Nos ingénieurs qualifiés pour le support technique sont prêts à traiter vos besoins en support, au cas par cas ou dans le cadre d un partenariat permanent. Les services de support Borland sont présents dans le monde entier et garantissent le succès de tous nos clients en fournissant des réponses rapides et fiables. Pour de plus amples informations sur les services de support de Borland, visitez notre site Web à l adresse Depuis le site web, vous pouvez aussi accéder à de nombreux groupes de discussion où les utilisateurs échangent informations, astuces et techniques. Voyez à l adresse la dernière liste des groupes de discussion libres d accès. De plus, le site Borland Developer Network est disponible sur Internet à l adresse Borland Community donne accès à des informations spécifiques aux produits, à des articles, à des exemples de code et à des nouvelles. Chapitre 1 : Préface 1

6 Conventions de la documentation Avant de contacter le support, préparez des informations complètes sur votre environnement, la version du produit que vous utilisez et une description détaillée du problème. Pour avoir de l aide sur les outils tiers, ou leur documentation, contactez votre fournisseur. Conventions de la documentation La documentation utilise les conventions suivantes. Choisissez Fichier > Quitter Police à espacement fixe italique Gras Indique la sélection d un menu suivie par la sélection d un sous-menu. Le symbole supérieur (>) sépare les commandes à sélectionner dans les sous-menus successifs. Par exemple, Choisissez la commande Fichier > Quitter implique la sélection de Fichier dans la barre de menus, puis de Quitter dans le menu déroulant. Le texte apparaissant en police Courier représente les informations que vous devez taper et les messages provenant du système. La syntaxe apparaissant en italiques représente des informations que vous devez remplacer par les noms de vos fichiers véritables, des dossiers enfant, etc. Les italiques servent également aux noms des dialogues et des manuels, ainsi que pour attirer l attention. La syntaxe apparaissant en gras représente des informations que vous devez utiliser exactement telles qu elles sont indiquées (si vous les utilisez). [ ] Crochets pour entourer la syntaxe des options. Une barre verticale sépare les choix syntaxiques mutuellement exclusifs. Remarque Astuce Important Attention Identifie des informations supplémentaires. Identifie des informations sur des procédures alternatives ou d autres informations utiles mais pas essentielles. Identifie des informations essentielles à l accomplissement d une tâche. Identifie des actions susceptibles d entraîner des pertes de données ou des procédures à suivre pour s assurer que les données ne seront pas perdues. 2 Guide de l utilisateur de TestDirector Synchronizer

7 Chapitre 2 2Utilisation de TestDirector Chapitre TestDirector Synchronizer permet de s assurer que les mêmes données apparaissent dans Mercury TestDirector ou Quality Center et une base de données utilisée par le serveur StarTeam. L objectif de la synchronisation consiste à fournir un accès aux dernières informations sur les défauts, que ces défauts soient traités dans TestDirector ou StarTeam. TestDirector peut être utilisé pour ajouter des défauts, et StarTeam pour indiquer que ces défauts ont été corrigés (ou vice versa). Les membres de l équipe n ont pas besoin de savoir dans quelle application le défaut a été traité en dernier. Comme les bases de données sont fréquemment synchronisées, des données à jour sont en permanence disponibles. TestDirector Synchronizer utilise des pilotes ODBC pour accéder à la base de données relationnelle conforme SQL TestDirector. Il s appuie sur StarTeam Runtime pour accéder au serveur StarTeam qui, à son tour, accède à la base de données StarTeam. Synchronizer transmet les données relatives aux défauts TestDirector à la base de données StarTeam, et les informations sur les défauts StarTeam (appelés demandes de modification) à la base de données TestDirector. Installation de TestDirector Synchronizer Avant d installer Synchronizer, assurez-vous que votre système remplit les exigences décrites à la section Configuration système, page 55. Pour installer Synchronizer, exécutez le fichier ST_TD_Synchronizer.exe et suivez les instructions affichées à l écran. ST_TD_Synchronizer.exe est un fichier exécutable auto-extractable qui crée un dossier StarTeam_TestDirector_Synchronizer dans votre dossier Temp (sauf si vous avez sélectionné un autre emplacement). Il place les fichiers dans ce dossier, puis exécute setup.exe à partir de ce dossier. Setup.exe installe les fichiers d intégration et lance StarTeam-runtime.exe. StarTeam-runtime.exe est un fichier exécutable auto-extractable qui installe les fichiers activant l intégration pour accéder au serveur StarTeam. Si vous utilisez le serveur StarTeam Windows et réalisez l installation sur une version précédente de Synchronizer, le programme d installation remplace BugSync.ini par BugSync.000, run.bat par run.000 et run-again.bat par run-again.000 pour ne perdre aucune des modifications que vous avez apportées à ces fichiers. Chapitre 2 : Utilisation de TestDirector 3

8 Synchronisation des applications Remarque Le serveur StarTeam pour Solaris utilise run.sh à la place de run.bat. Synchronisation des applications Remarque La synchronisation des deux bases de données nécessite une préparation préalable. Vous devez apporter des modifications pour personnaliser les deux bases de données. Pour synchroniser les deux applications efficacement : 1 Déterminez les données relatives à chaque défaut et demande de modification auxquelles les deux applications doivent accéder. Ces données doivent être stockées dans les deux bases et synchronisées entre ces bases. Notez les champs qui stockent ces données et les valeurs qui peuvent ou doivent être stockées dans ces champs. 2 Comparez les champs d une application à ceux de l autre application. Le fichier de propriétés BugSync.ini de Synchronizer vous permet de désigner (c est-à-dire mapper) dans chaque programme les champs qui stockeront les mêmes données. En général, vous mappez des paires de champs, chaque paire se composant d un champ issu de chaque application. Synchronizer prend également en charge les mappages un à plusieurs. Par exemple, vous pouvez mapper un champ TestDirector avec plusieurs champs StarTeam ou un champ StarTeam avec plusieurs champs TestDirector. Synchronizer ne prend pas en charge les mappages plusieurs-à-un ni les mappages historiques entre TestDirector et StarTeam (ou vice versa). Dans certains cas, vous pouvez mapper un champ TestDirector existant avec un champ StarTeam existant (et vice versa). Voir Champs Défaut TestDirector, page 37, et Champs Demande de modification, page 23, pour des recommandations et des suggestions relatives aux mappages. 3 Créez des champs personnalisés dans les deux bases de données (en utilisant TestDirector et l édition Entreprise ou Entreprise Advantage de StarTeam), afin de stocker les données qui ne peuvent pas être mappées directement entre un champ existant et un autre. Voir Création de champs personnalisés, page 6, pour de plus amples informations. 4 Pour chaque application, créez un champ de synchronisation qui fait office d indicateur et contrôle les défauts qui sont (et ne sont pas) transférés vers la base de données de l autre application. Vous pouvez choisir de ne pas transférer certains défauts. Le fichier BugSync.ini initial utilise le champ personnalisé BG_USER_02 comme champ indicateur dans TestDirector et le champ personnalisé Usr_Sync dans StarTeam. Vous pouvez toutefois utiliser d autres champs chaîne/texte personnalisés. Dans TestDirector, vous pouvez créer un champ chaîne ou une liste personnalisée pour le champ de synchronisation. La liste personnalisée doit comporter les valeurs Oui et Non. Dans StarTeam, le champ personnalisé doit être un champ énumération ou un champ texte avec les valeurs Oui et Non. Dans Synchronizer, les valeurs Oui et Non ne doivent pas différencier majuscules et minuscules. Vous pouvez sélectionner Oui ou Non comme valeur par défaut. Quand un défaut a la valeur Oui dans ce champ, Synchronizer crée un défaut ou met à jour un défaut existant dans la base de données de l autre application. Si un défaut a la valeur Non dans ce champ ou si ce champ est vierge, Synchronizer ne modifie pas ce défaut et ne l ajoute pas à la base de données de l autre application. Voir Création de champs personnalisés, page 6, pour de plus amples informations. 4 Guide de l utilisateur de TestDirector Synchronizer

9 Synchronisation des applications 5 Créez un fichier de propriétés qui indique les champs à transférer et dans quelle direction. Voir le fichier de propriétés initial, BugSync.ini, dans Fichier de propriétés initial de Synchronizer, page 45. Utilisez BugSync.ini (fichier de propriétés initial du programme d installation) comme modèle. Nous vous recommandons de modifier une copie du fichier pour pouvoir revoir les paramètres d origine de BugSync.ini lors du débogage de votre propre fichier de propriétés. a b c Changez les paramètres vts_ et mtd_ pour indiquer la source des données de chaque application. Vérifiez que le mappage mtd_project1 contient une valeur correcte pour le champ Projet (BG_PROJECT). Si cette directive est décommentée, tous les projets stockés dans le conteneur sont synchronisés. Mappez d autres champs, si nécessaire. Voir Utilisation des directives de mappage, page 16, pour de plus amples informations. 6 Dans le répertoire d installation, modifiez le fichier run.bat pour le serveur Windows ou le fichier run.sh pour le serveur StarTeam pour Solaris de sorte qu il pointe sur l emplacement du fichier Runtime appelé starteamxx.jar. Pour de plus amples informations, voir Exécution de Synchronizer, page Faites un test pour vérifier que Synchronizer déplace correctement les demandes de modification entre StarTeam et TestDirector. a b c d Créez une demande de modification dans StarTeam. Définissez le champ de synchronisation dans TestDirector sur Oui. Exécutez Synchronizer. Actualisez TestDirector et vérifiez qu un défaut a été créé. 8 Faites un test pour vérifier que Synchronizer déplace correctement les défauts entre TestDirector et StarTeam. a b c d e Crée un nouveau défaut dans TestDirector. Définissez le champ de synchronisation dans TestDirector sur Oui. Définissez le champ Projet sur le nom de projet approprié. Ce champ et le paramètre mtd_project1 doivent avoir la même valeur. Exécutez Synchronizer. Actualisez StarTeam et vérifiez qu une demande de modification a été créée. 9 Exécutez le fichier batch de Synchronizer (run.bat ou run.sh) à intervalles réguliers pour que les deux bases de données soient aussi similaires que possible (la fréquence d exécution dépend de vos besoins). Pour savoir à quelle fréquence vous devez exécuter le fichier.bat, comparez l importance des mises à jour pour les utilisateurs aux effets possibles sur les performances des applications, susceptibles d être ralenties pendant le processus de synchronisation. Vous pouvez utiliser le fichier run-again.bat pour configurer un intervalle régulier, mais assurez-vous que cet intervalle est suffisamment long pour que Synchronizer puisse terminer la synchronisation avant qu elle ne soit relancée. Assurez-vous que les membres de l équipe comprennent les ramifications des décisions de synchronisation. Par exemple, les utilisateurs de StarTeam ne doivent pas modifier les champs dont TestDirector est propriétaire, car leurs données seront perdues pendant le processus de synchronisation. De même, les utilisateurs de TestDirector ne doivent pas modifier les champs dont StarTeam est propriétaire. Par exemple, vous pouvez demander aux testeurs de ne pas modifier le champ Commentaires R & D et aux développeurs de ne pas modifier le champ Résumé. Chapitre 2 : Utilisation de TestDirector 5

10 Création de champs personnalisés Il pourra s avérer nécessaire d écrire des procédures de gestion des défauts et demandes de modification dans chaque application pour réduire le risque d erreurs. Création de champs personnalisés TestDirector et l édition Entreprise ou Entreprise Advantage de StarTeam vous permettent de créer des champs personnalisés et de les rendre obligatoires. Certains champs personnalisés doivent apparaître dans les deux applications. Par exemple, vous devez créer un champ personnalisé dans chaque application pour les opérations de synchronisation. Voir Synchronisation des applications, page 4, pour de plus amples informations. Il est recommandé que les champs personnalisés soient de même type que les champs auxquels ils sont mappés. Personnalisation des champs dans TestDirector Les types de champs TestDirector sont : nombre, chaîne, date, liste d utilisateurs ou liste de référence. Pour une liste, vous pouvez cocher la case Verify Value pour limiter le champ aux valeurs de la liste. Nombres Les champs TestDirector de type nombre peuvent être mappés avec des types entier StarTeam. Chaînes Les champs TestDirector de type chaîne peuvent être mappés avec des champs StarTeam de type texte. Dates Les champs TestDirector de type date peuvent être mappés avec des champs StarTeam de type date/heure. En revanche, toutes les informations d heure provenant de StarTeam sont perdues dans TestDirector. Toutes les informations de date provenant de TestDirector ont la valeur minuit (00:00:00) dans StarTeam. Listes d utilisateurs Les champs TestDirector de type liste d utilisateurs peuvent être mappés avec des champs StarTeam de type ID utilisateur. Listes de référence Les champs TestDirector de type liste de référence peuvent être mappés avec des champs StarTeam de type énumération (à condition que les valeurs énumérées soient identiques). Ils n ont pas besoin d être dans le même ordre. Si TestDirector possède un champ liste de référence, vous pouvez le mapper avec un champ personnalisé StarTeam de type énumération ou texte. Pour une synchronisation unidirectionnelle, il suffit d associer un champ liste TestDirector à un champ texte StarTeam ; en revanche, pour une synchronisation bidirectionnelle, il est recommandé de mapper un champ liste de référence TestDirector avec un champ StarTeam de type énumération. Pour de plus amples informations sur la personnalisation des champs, reportez-vous à la documentation et à l aide TestDirector. 6 Guide de l utilisateur de TestDirector Synchronizer

11 Dépannage Personnalisation des champs dans StarTeam Dates/Heures Les champs StarTeam de type date/heure peuvent être associés à des champs TestDirector de type date. Ces formats sont définis dans la boîte de dialogue Options régionales du Panneau de configuration. Sachez toutefois que les informations d heure seront absentes de TestDirector et seront perdues si StarTeam ne possède pas le champ en question. Texte Les champs StarTeam de type texte peuvent être mappés avec des champs TestDirector de type chaîne. Les limites de longueur associées aux champs de type chaîne et éléments de listes TestDirector dépendent de la base de données. Pour de plus amples informations, reportez-vous au TestDirector Administrator s Guide. Les champs StarTeam de type texte doivent avoir les mêmes limites ou TestDirector doit posséder le champ. Entiers et nombres réels TestDirector n a pas de champ de type réel. Le composant demande de modification StarTeam n en a pas non plus, sauf si un champ personnalisé de ce type a été créé. Si nécessaire, les champs StarTeam qui contiennent des nombres réels peuvent être associés à un champ texte TestDirector. Les champs StarTeam de type entier peuvent être mappés avec un type nombre TestDirector. Enumérations Les champs StarTeam de type énumération peuvent être mappés avec un champ TestDirector de type liste de référence. Dans TestDirector, les valeurs énumérées sont représentées par des chaînes. Les limites de longueur de ces champs dépendent de la base de données utilisée pour TestDirector. Pour mapper un champ StarTeam de type énumération avec un nom plus long que la limite TestDirector, vous devez modifier le champ pour que sa longueur soit inférieure ou égale à cette limite. Vous devez ensuite utiliser les mêmes valeurs pour le champ liste de référence TestDirector mappé. Supposons par exemple que la limite du champ TestDirector est de 20 caractères. ID utilisateur Les champs StarTeam de type ID utilisateur peuvent être mappés à un champ TestDirector de type liste d utilisateurs, à condition que la liste corresponde aux noms de connexion des utilisateurs StarTeam. Pour de plus amples informations sur la personnalisation des champs, voir le Guide de l administrateur de StarTeam et l aide en ligne de StarTeam. Dépannage Cette section contient diverses informations dont vous devez tenir compte lorsque vous utilisez Synchronizer. Définition de l indicateur de synchronisation Si vous utilisez une base de données TestDirector existante (comme la base de données TestDirector_Demo installée avec TestDirector), aucun défaut TestDirector n apparaît dans StarTeam si l indicateur de synchronisation TestDirector de ces défauts n est pas défini sur Oui. Chapitre 2 : Utilisation de TestDirector 7

12 Dépannage L inverse est vrai dans les bases de données StarTeam si le champ de synchronisation a par défaut la valeur Oui. Toutes les demandes de modification apparaissent dans TestDirector, sauf si le champ a pour valeur Non. Notez que les demandes de modification ne sont pas supprimées, mais qu elles ne sont plus mises à jour. Champs trop longs En général, les champs texte StarTeam peuvent contenir davantage de caractères que les champs TestDirector. Les limites de longueur des champs TestDirector dépendent de la base de données sélectionnée. Pour de plus amples informations sur la longueur des champs, voir le TestDirector Administrator s Guide. Quand les données d un champ StarTeam dépassent la limite de longueur du champ TestDirector recevant ces données, un avertissement est consigné dans les fichiers mtdsync.err et mtdsync.log, et la valeur du champ est tronquée lorsqu elle est ajoutée à TestDirector. Synchronizer ne définit aucun niveau d erreur détectable par le fichier batch. Synchronizer lit la longueur des champs TestDirector chaque fois qu il est exécuté. Les versions récentes de TestDirector sont suffisamment souples pour fonctionner sur des tables dont la taille des colonnes augmente grâce à l accès direct à la base de données. Synchronizer reconnaît les nouveaux champs et en ajuste la taille en conséquence. Si les données d un champ TestDirector dépassent les limites de longueur du champ StarTeam, la valeur de ce champ est tronquée et une exception de base de données StarTeam est enregistrée. Un avertissement avec une valeur d erreur est renvoyé au fichier batch, et le suivi de pile de l exception est enregistré dans les fichiers mtdsync.err et mtdsync.log. Dans le fichier mtdsync.err, tous les messages d avertissement indiquent le numéro des défauts TestDirector et StarTeam en cours de traitement. Dans l exemple suivant, un champ texte StarTeam contenant 47 caractères est réduit à 4 caractères. Error Report: 1. TD Bug:72 ST Bug:46 MTD column BG_USER_05 has been truncated from 47 to 40 characters. Champs mémo : Considérations particulières Les champs mémo (champs très longs de type chaîne) tels que Description et Commentaire R & D dans TestDirector ou Description, Corriger et Palliatif dans StarTeam peuvent poser des problèmes. Ces champs peuvent contenir entre et caractères. Leur longueur dépendant de la base de données utilisée, le nombre exact de caractères peut différer dans TestDirector et StarTeam. Supposons que Synchronizer essaie d effectuer l une des opérations suivantes : Créer un défaut TestDirector Si Synchronizer crée un défaut TestDirector alors qu un champ mémo dépasse 250 caractères, le défaut créé par ce champ reste vide. Cette situation est due à une limite SQL. Aucun message d avertissement n est consigné dans le fichier journal car le champ pourra probablement être rempli lors de la prochaine mise à jour du défaut. Mettre à jour un défaut TestDirector Si Synchronizer tente de mettre à jour un défaut TestDirector existant alors que le champ mémo dépasse les limites de longueur de la base de données TestDirector, le champ est tronqué et l action est consignée dans le fichier mtdsync.log. 8 Guide de l utilisateur de TestDirector Synchronizer

13 Dépannage Créer ou mettre à jour une demande de modification StarTeam Si un champ mémo destiné à une demande de modification StarTeam dépasse les limites de longueur de la base de données TestDirector, un message d avertissement est consigné dans le fichier journal et le champ demande de modification concerné n est pas mis à jour. Si la longueur des champs ne s approche jamais des limites de la base de données, aucun problème ne se produit. Si les deux applications utilisent la même version de la base de données, elles doivent toutes deux avoir la même limite de longueur pour les champs. Utilisation des champs vides Synchronizer peut transférer des données entre un champ vide et un champ comportant une valeur. StarTeam gère les champs vides, et les champs liste TestDirector acceptent les valeurs vierges (sauf si l option Verify Value est sélectionnée). Supposons le mappage suivant pour votre fichier de propriétés : map.bg_detection_date>usr_tddetectiondate Cela signifie que le champ TestDirector Détecté le (BG_DETECTION_DATE) est associé à un champ personnalisé StarTeam appelé Usr_TDDetectionDate. Si le champ Détecté le est initialement défini à 1/1/00 dans TestDirector, l exécution du Synchronizer entraîne le transfert de cette valeur dans StarTeam. Plus tard, si vous supprimez cette valeur de TestDirector (ce qui vide le champ Détecté le), le champ StarTeam devient également vierge quand vous exécutez Synchronizer. Mappage de champs de type énumération avec des champs texte En prenant certaines précautions, vous pouvez associer des champs de type énumération à des champs texte. Par exemple, l application dans laquelle réside le champ énumération doit posséder le mappage. Cela est dû au fait que les champs texte peuvent contenir des données qui ne correspondent pas aux valeurs énumérées disponibles dans le champ qui reçoit les données. Par exemple, le texte peut être mal orthographié, comporter trop de caractères ou simplement ne pas apparaître dans les valeurs énumérées. Utilisation d une vue en lecture seule N utilisez pas une vue StarTeam en lecture seule. Dans le fichier de propriétés, si vous spécifiez une telle vue pour la directive vts_viewx (où x est un entier, par exemple 1), le message d erreur suivant apparaît dans le fichier mtdsync.err quand vous vous connectez au serveur StarTeam : java.net.connectexception: Connexion refusée java.lang.runtimeexception: java.net.connectexception: Connexion refusée Chapitre 2 : Utilisation de TestDirector 9

14 10 Guide de l utilisateur de TestDirector Synchronizer

15 Chapitre 3 3Présentation du fichier de propriétés Chapitre de Synchronizer Présentation des directives Ce chapitre décrit le fichier de propriétés (BugSync.ini) de TestDirector Synchronizer. Ce fichier est installé en même temps que Synchronizer. Remarque Votre fichier de propriétés contient une série de directives qui effectuent l une des opérations suivantes : Identification des valeurs StarTeam. Ces directives commencent par vts (pour VirtualTeam Server, nom des versions précédentes de StarTeam Server). Identification des valeurs TestDirector. Ces directives commencent par mqc (représentant TestDirector). Mappage de champs TestDirector avec des champs StarTeam (et vice versa). Ces directives commencent par map. (Facultatif) Mappage des valeurs des champs entre TestDirector et StarTeam (et vice versa). Ces directives commencent par valuemap. Les champs valuemap requièrent une valeur de mappage pour le champ lui-même. Exemple : map.bg_severity>severity Valuemap.Bg_Severity.1-Low=Severity.low Même lorsqu un champ est mappé entre deux applications, le mappage de ses valeurs n est pas obligatoire. Les commentaires du fichier BugSync.ini fournissent des explications sur l utilisation des directives. Voici les formats possibles pour les directives : clé(n)=valeur où clé représente le nom de la directive plus la valeur d itération (n) et valeur représente son paramétrage. L utilisation d une valeur d itération est obligatoire ; voir Spécification de synchronisations multiples, page 12, pour plus d informations. Chapitre 3 : Présentation du fichier de propriétés de Synchronizer 11

16 Spécification de synchronisations multiples Par exemple : vts_server1=localhost map. TestDirectorField[> = <]StarTeamField où TestDirectorField et StarTeamField représentent une paire de champs entre lesquels les données seront transférées par Synchronizer, et où l opérateur est supérieur à, égale à ou inférieur à ( >, =, ou< ), selon la façon dont le mappage est contrôlé. Pour de plus amples informations, voir Utilisation des directives de mappage, page 16. Par exemple : map.bg_reproducible>usr_tdreproducible valuemap. TestDirectorField.value=StarTeamField.value où la valeur du champ TestDirector est mappée à StarTeamField.value. Pour inclure des caractères spéciaux, des espaces, des opérateurs, etc., la valeur doit être délimitée. Exemple : TestDirectorField.( value )=StarTeamField.( value ) Comme le fichier de propriétés doit contenir les noms d utilisateur et mots de passe pour la base de données TestDirector et le serveur StarTeam, vous pouvez en interdire l accès aux autres utilisateurs. Par exemple, vous pouvez décider de ne pas partager le lecteur sur lequel il se trouve. Si vous travaillez sous Windows, vous pouvez masquer le dossier qui contient le fichier de propriétés en limitant les autorisations de ce dossier à un groupe spécifique d utilisateurs Windows. Spécification de synchronisations multiples Attention Le fichier de propriétés initial indique comment synchroniser un dossier StarTeam avec un projet TestDirector. Vous pouvez toutefois synchroniser des dossiers StarTeam supplémentaires avec des projets TestDirector supplémentaires. Comme nous l avons vu précédemment, clé(n)=valeur où clé représente le nom de la directive plus la valeur d itération (n) et valeur représente son paramétrage. Pour identifier la première synchronisation, vous devez utiliser des directives qui se terminent par 1, par exemple vts_project1, vts_folder1, mtd_driver1, etc. Identifiez la seconde avec des directives qui se terminent par 2, par exemple vts_project2. Les directives du premier dossier StarTeam doivent se terminer par 1 ; celles du second doivent se terminer par 2, etc. Synchronizer recherche ces chiffres dans l ordre et s arrête si un chiffre manque. Les directives qui ne se terminent pas par un chiffre sont utilisées pour toutes les synchronisations spécifiées dans le fichier de propriétés. Les mappages de champs tels que : map.bg_dev_comments<fix+workaround et certaines autres directives ne se terminent pas par un chiffre ; ils s appliquent à toutes les synchronisations qui utilisent le même fichier de propriétés. Si vous devez mapper des champs différemment ou utiliser des directives différentes, utilisez plusieurs fichiers de propriétés plutôt que plusieurs synchronisations. Il est possible de synchroniser accidentellement les défauts du même dossier StarTeam plusieurs fois. Supposons par exemple que deux synchronisations utilisent les mêmes projet et vue StarTeam, et que la directive de récursion est définie sur oui pour les deux synchronisations. Si les synchronisations utilisent le même fichier de propriétés, vous pouvez voir : vts_recurse_children1=yes vts_recurse_children2=yes 12 Guide de l utilisateur de TestDirector Synchronizer

17 Utilisation des directives StarTeam Si le dossier StarTeam spécifié pour une synchronisation est un enfant du dossier StarTeam spécifié pour l autre, la hiérarchie du premier dossier sera passée en revue deux fois, et les données apparaîtront peut-être plusieurs fois dans les deux bases de données. Un problème identique peut se produire si des dossiers sont partagés entre les deux emplacements de synchronisation. Avec les synchronisations multiples, vous pouvez également utiliser la directive iterations pour spécifier le nombre de synchronisations dans un fichier de propriétés. Cette directive vous permet de ne définir que les champs obligatoires qui diffèrent de la synchronisation précédente (portant un chiffre inférieur). Utilisation des directives StarTeam Utilisez les directives du tableau ci-dessous pour identifier le serveur, le projet, etc. StarTeam. Il s agit du premier ensemble de directives qui apparaît dans le fichier de propriétés. Dans le tableau suivant, elles sont répertoriées dans l ordre dans lequel elles apparaissent dans le fichier de propriétés initial (BugSync.ini). Vous y découvrirez également comment la plupart sont initialement utilisées dans ce fichier. Tableau 3.1 Directive StarTeam vts_server(n) vts_port(n) vts_project(n) vts_username(n) vts_password(n) vts_view(n) Directives StarTeam Description Nom ou adresse IP de l ordinateur qui exécute une configuration de StarTeam Server. vts_server1=localhost Numéro du port utilisé par le protocole TCP/IP (sockets) pour cette configuration serveur StarTeam. Le fichier BugSync.ini initial utilise par défaut le port vts_port1=49201 Nom du projet StarTeam à synchroniser. Le fichier BugSync.ini initial utilise Mercury, c est-à-dire le nom d un projet StarTeam utilisé pour les tests avec TestDirector. vts_project1=mercury Nom de l utilisateur que Synchronizer utilise pour se connecter à StarTeam. Il s agit du nom de connexion de l utilisateur, pas du nom complet. Par exemple, jfoulkes peut être le nom de connexion d une utilisatrice dont le nom complet est Jessica Foulkes. L utilisateur doit disposer du droit de voir le projet, la vue et le dossier. Cet utilisateur doit également avoir les droits d accès suivants : Le droit de voir, créer et modifier les demandes de modification stockées dans ce dossier Le fichier BugSync.ini initial utilise le nom d utilisateur générique Administrator. vts_username1=administrator Mot de passe de l utilisateur vts_username(n). Le fichier BugSync.ini initial utilise Administrator car il s agit du mot de passe du nom de connexion Administrator dans le projet exemple. vts_password1=administrator Nom de la vue StarTeam qui stocke ou stockera les demandes de modification synchronisées. Vérifiez que cette vue n est pas en lecture seule. Pour utiliser la vue racine (ou par défaut) du projet, laissez la directive vts_view(n) vierge. Le fichier BugSync.ini initial laisse cette clé vide. vts_view1= Chapitre 3 : Présentation du fichier de propriétés de Synchronizer 13

18 Utilisation des directives TestDirector Tableau 3.1 Directive StarTeam vts_folder(n) vts_recurse_ children(n) vts_send_to_mtd vts_create_custom _fields Directives StarTeam (suite) Description Chemin d accès au dossier StarTeam (dans la vue StarTeam) dans lequel la synchronisation doit commencer. Pour utiliser le dossier racine de la vue, laissez la clé vts_folder(n) vierge. Si vous utilisez un enfant du dossier racine, indiquez le chemin de ce dossier, en supprimant le dossier racine. vts_folder(n) ne doit jamais inclure le dossier racine. Utilisez une barre oblique (/) comme délimiteur de tous les autres noms de dossiers. Par exemple, si le dossier racine de la vue est StarDraw et si le chemin d accès au dossier à synchroniser est StarDraw/SourceCode/Client, utilisez uniquement SourceCode/Client. Le fichier BugSync.ini initial laisse cette clé vide pour pouvoir utiliser le dossier racine de la vue. vts_folder1= Notez que Synchronizer ne peut conserver la trace des demandes de modification qui ont été déplacées entre des dossiers StarTeam que si la directive vts_recurse_childrenx a la valeur oui et si les deux dossiers se trouvent dans la hiérarchie du dossier spécifié dans la directive vts_folderx. Si ces conditions ne sont pas remplies, de nouvelles demandes de modification sont créées (au lieu de déplacer les demandes d origine). Passe en revue tous les enfants de vts_folder(n). A pour valeur yes ou no. Le fichier BugSync.ini initial utilise la valeur yes. vts_recurse_children1=yes Nom du champ StarTeam personnalisé utilisé comme indicateur de synchronisation. Ce champ doit être de type énumération et comporter la valeur Oui ou Non (différenciant les majuscules et minuscules). Le fichier BugSync.ini initial utilise le champ Usr_Sync. vts_send_to_mtd=usr_sync Indique si Synchronizer doit essayer de créer automatiquement un champ personnalisé dans StarTeam quand le mappage d un champ TestDirector pointe sur un champ personnalisé StarTeam qui n existe pas. A pour valeur Yes ou Non. Le champ personnalisé StarTeam créé automatiquement aura le nom spécifié dans la directive de mappage, et ses données seront dérivées du champ TestDirector spécifié. vts_create_custom_fields=yes Cette directive est décommentée dans le fichier BugSync.ini initial. Le fait de la décommenter revient à lui attribuer la valeur No. Utilisation des directives TestDirector Utilisez les directives du tableau ci-dessous pour identifier la base de données, le projet, etc. TestDirector. Ces directives correspondent au second ensemble qui apparaît dans le fichier de propriétés. Dans le tableau suivant, elles sont répertoriées dans l ordre dans lequel elles apparaissent dans le fichier de propriétés initial (BugSync.ini). Vous y découvrirez également comment la plupart sont initialement utilisées dans ce fichier. Remarque Si vous utilisez une base de données Oracle pour vos projets TestDirector, ces derniers peuvent contenir des champs CLOB (Character Large Object). Pour prendre en charge ces champs, vous devez modifier les directives mtd_driver(n) et mtd_dataurl(n) pour qu elles pointent sur les pilotes JDBC Oracle correspondants. 14 Guide de l utilisateur de TestDirector Synchronizer

19 Utilisation des directives TestDirector Tableau 3.2 Directive TestDirector mtd_driver(n) mtd_dataurl(n) mtd_ username(n) mtd_ password(n) mtd_project(n) mtd_send_to_ vts Directives TestDirector Description Nom du pilote ODBC ou JDBC Oracle utilisé pour accéder à la base de données TestDirector. Cette directive doit être spécifiée pour chaque synchronisation, même si la directive iterations est utilisée. Pour ODBC, le fichier BugSync.ini initial utilise : mtd_driver1=sun.jdbc.odbc.jdbcodbcdriver Pour JDBC Oracle, le fichier BugSync.ini initial utilise : mtd_driver1=oracle.jdbc.driver.oracledriver Si vous choisissez le pilote JDBC Oracle, vous devez également utiliser l URL JDBC Oracle correspondante. DSN ODBC ou URL JDBC Oracle de la base de données TestDirector à synchroniser. Pour ODBC, le fichier BugSync.ini initial utilise : mtd_dataurl1=jdbc:odbc:testdirector_demo Identifie la base de données de démonstration installée avec TestDirector. Si vous créez votre propre base de données TestDirector, vous devrez peut-être créer un DSN pour cette base. Pour JDBC Oracle, utilisez l un des deux choix du fichier BugSync.ini initial : mtd_dataurl1=jdbc:oracle:thin:@localhost: 1521:ORCL mtd_dataurl1:jdbc:oracle:oci8:@tdoraserver Si vous choisissez le pilote JDBC Oracle, vous devez également utiliser le pilote JDBC Oracle correspondant. Nom de l utilisateur utilisé par Synchronizer pour accéder à la base de données TestDirector. Le fichier BugSync.ini initial utilise admin car cet utilisateur peut accéder à la base de données de démonstration TestDirector. mtd_username1=admin Avec une base de données Microsoft SQL, mtd_username1 devra peut-être avoir la valeur td (nom d utilisateur par défaut que TestDirector affecte à toutes les bases de données nouvellement créées). Définissez mtd_password sur tdtdtd (mot de passe utilisé pour accéder à cette base de données à partir de TestDirector). Avec une base de données Oracle, le nom d utilisateur dépend de la version, mais le mot de passe par défaut est toujours tdtdtd. mtd_username1=td (valeur par défaut ; voir ci-dessus) Mot de passe de l utilisateur mtd_username(n). Le fichier BugSync.ini initial laisse cette directive vide car admin n a pas de mot de passe dans la base de données de démonstration. mtd_password1= Valeur du champ BG_PROJECT dans TestDirector pour les défauts à synchroniser.cette valeur différencie les majuscules et les minuscules. mtd_project1=project 1 Pour synchroniser tous les projets TestDirector afin d indiquer toutes les valeurs, utilisez le format suivant : mtd_project(n)=<all Projects> Pour synchroniser un projet nommé <All Projects>, utilisez le format suivant : mtd_project(n)=\<all Projects>\> Si vous décommentez la directive, tous les projets du conteneur seront synchronisés. Nom du champ TestDirector personnalisé utilisé comme indicateur de synchronisation. Il doit s agir d une liste de référence qui doit contenir les valeurs Yes et No (qui ne différencient pas les majuscules et minuscules). Le fichier BugSync.ini initial utilise le champ BG_USER_02. mtd_send_to_vts=bg_user_02 Chapitre 3 : Présentation du fichier de propriétés de Synchronizer 15

20 Utilisation des directives de mappage Copie des pièces jointes Vous disposez de deux méthodes pour copier des pièces jointes entre TestDirector et StarTeam. Si le répertoire du serveur TestDirector est accessible depuis Synchronizer, vous pouvez utiliser la directive mtd_attachment_dir(n) pour spécifier le répertoire destiné aux pièces jointes. Aucune autre directive n est nécessaire. Cette méthode garantit un niveau de performance optimal. Si le répertoire du serveur TestDirector n est pas accessible à partir de Synchronizer, vous devez utiliser des directives pour identifier l ordinateur sur lequel le serveur TestDirector est exécuté, le projet TestDirector contenant les pièces jointes, ainsi que le nom d utilisateur et le mot de passe utilisés pour se connecter à ce projet. Si la directive mtd_hostname(n), mtd_app_project(n) ou mtd_appusername(n) est absente, aucune pièce jointe n est copiée. Si un mot de passe est associé au nom d utilisateur, vous devez également utiliser la directive mtd_app_password(n). Le tableau suivant contient les directives permettant de copier des pièces jointes : Tableau 3.3 Directive TestDirector mtd_attachment_dir(n) mtd_ hostname(n) mtd_app_ project(n) mtd_app_ username(n) mtd_app_ password(n) Copie de pièces jointes TestDirector Description Nom du répertoire du serveur TestDirector destiné aux pièces jointes. Directive utilisée uniquement quand le répertoire est accessible à partir de Synchronizer. Nom ou adresse IP du serveur TestDirector (l ordinateur IIS). Directive utilisée par Synchronizer pour se connecter à TestDirector et copier des pièces jointes entre TestDirector et StarTeam. Ignorée si mtd_attachment_dir(n) est définie. Nom du projet TestDirector qui contient les défauts dont les pièces jointes doivent être copiées dans StarTeam. Cette directive est ignorée si mtd_attachment_dir(n) est définie. Nom d utilisateur utilisé pour se connecter au projet TestDirector. Cette directive est ignorée si mtd_attachment_dir(n) est définie. Mot de passe de l utilisateur identifié dans mtd_app_username(n). Cette directive est ignorée si mtd_attachment_dir(n) est définie. Attention Supposons que vous créez un défaut dans TestDirector avec une pièce jointe. Une fois TestDirector et StarTeam synchronisés, le nouveau défaut et sa pièce jointe apparaissent dans StarTeam. Supposons maintenant que vous consultez à nouveau le défaut dans TestDirector et décidez que la capture d écran jointe ne représente pas le problème expliqué très clairement dans le défaut. Vous remplacez alors la pièce jointe d origine par une autre plus claire. Lors de la synchronisation suivante, l une des situations suivantes se produit : Si la nouvelle pièce jointe a le même nom que celle d origine, Synchronizer ne copie pas la nouvelle dans StarTeam. Il identifie la pièce jointe comme une pièce précédemment copiée dans StarTeam et ne détecte pas qu elle a changé. Si la nouvelle pièce jointe a un nom différent, la demande de modification dans StarTeam contient les deux pièces jointes. Synchronizer ne supprime pas les pièces jointes. Utilisation des directives de mappage Quand Synchronizer transfère les informations sur les défauts entre les deux bases de données, il copie les données d un champ d une application vers un champ de l autre application. Le fichier de propriétés contient des directives de mappage, chacune 16 Guide de l utilisateur de TestDirector Synchronizer

21 Utilisation des directives de mappage spécifiant une paire de champs (un provenant de TestDirector et un autre de StarTeam) qui contiendront les mêmes données après la synchronisation. Une directive de mappage : Commence par map ou valuemap. Identifie le champ TestDirector par son identificateur interne. Pour un champ TestDirector, l identificateur interne est le nom indiqué dans la table de la base de données TestDirector. Identifie le champ StarTeam par son identificateur interne. Pour un champ StarTeam, l identificateur interne est le nom par lequel StarTeam Server et StarTeam Runtime reconnaissent le champs. Sépare les champs avec l un des opérateurs suivants pour indiquer la direction du flux de données. > représente un mappage entre TestDirector et StarTeam, dans lequel TestDirector possède la paire de champs mappés (opérateur utilisé uniquement avec les directives de mappage). < représente un mappage entre StarTeam et TestDirector, dans lequel StarTeam possède la paire de champs mappés (opérateur utilisé uniquement avec les directives de mappage). = indique que Synchronizer utilise les dates des historiques pour un ensemble de champs appariés pour déterminer quelle valeur mettre dans les deux champs. Pour que l opérateur fonctionne, l historique TestDirector doit être activé sur la paire. Le fichier de propriétés initial BugSync.ini inclus avec l installation est illustré à la section Fichier de propriétés initial de Synchronizer, page 45. Toutes les actions suivantes sont recommandées : Faites une copie de BugSync.ini. Renommez le fichier. Modifiez le fichier en fonction de vos besoins. Si nécessaire, supprimez les symboles de commentaire (#) pour activer les directives de mappage. Synchronizer utilise l historique des propriétés ou champs pour déterminer les données qui sont copiées dans chaque base de données. Propriété (mode de fonctionnement des opérateurs) Quand une application (TestDirector ou StarTeam) possède la paire de champs mappés, ces champs sont toujours synchronisés pour qu ils correspondent à la valeur du champ dans l application qui possède la paire. Dans la directive de mappage, la propriété est indiquée par un opérateur supérieur à ou inférieur à entre l identificateur interne des champs. L exemple suivant illustre le champ BG_DESCRIPTION de TestDirector mappé avec le champ Description de StarTeam. L opérateur > indique que TestDirector possède la paire de champs mappés, c est-à-dire que la valeur du champ TestDirector peut être copiée dans le champ StarTeam au cours de la synchronisation mais que la valeur StarTeam ne sera jamais copiée dans TestDirector. map.bg_description>description Chapitre 3 : Présentation du fichier de propriétés de Synchronizer 17

22 Utilisation des directives de mappage Au cours de la synchronisation, toutes les modifications apportées au champ Description de TestDirector sont transférées vers le champ Description de StarTeam. Toutes les modifications apportées au champ Description de StarTeam depuis la dernière synchronisation sont remplacées. Entre les synchronisations, les deux champs peuvent contenir des données différentes mais, après la synchronisation, ils contiennent tous deux les données du champ Description de TestDirector. L exemple suivant illustre le champ BG_DEV_COMMENTS de TestDirector mappé avec le champ Corriger de StarTeam. L opérateur < indique que StarTeam possède la paire de champs mappés, c est-à-dire que la valeur du champ StarTeam peut être copiée dans le champ TestDirector au cours de la synchronisation mais que la valeur TestDirector ne sera jamais copiée dans StarTeam. map.bg_dev_comments<fix Les champs mappés peuvent être mis à jour en fonction de l heure de la dernière mise à jour des données. Synchronizer utilise l historique de chaque champ pour déterminer la direction des données. Si, dans la directive de mappage, un signe égale (=) sépare l identificateur interne de chaque champ, l historique des champs est utilisé. En d autres termes, la valeur du champ TestDirector peut être copiée dans le champ StarTeam au cours de la synchronisation, ou vice versa selon la valeur la plus récente. L exemple suivant illustre le champ BG_RESPONSIBLE de TestDirector mappé avec le champ personnalisé Usr_TDResponsible de StarTeam. map.bg_responsible=usr_tdresponsible Pour pouvoir utiliser les données historiques, l option Historique doit être sélectionnée pour le champ TestDirector. StarTeam stocke automatiquement les données historiques de chaque champ, de sorte que vous n ayez rien à modifier dans StarTeam. Si vous utilisez l historique pour contrôler les échanges de données, l horloge de tous les ordinateurs qui exécutent TestDirector et StarTeam doit impérativement être synchronisée (les serveurs et stations de travail exécutant les applications StarTeam doivent déjà être synchronisés). Si, dans le fichier de propriétés, l opérateur = sépare le nom de deux champs mappés, leur historique est utilisé pour déterminer la valeur qui apparaît dans ce champ pour chaque application. Comme l option Historique n est pas gérée pour les champs Description et Commentaires R & D de TestDirector, ces deux champs doivent utiliser la propriété quand ils sont mappés. Exigences et limites associées aux mappages Certains mappages sont obligatoires : Mappez le champ ID défaut de TestDirector avec le champ Référence externe de StarTeam avec TestDirector comme propriétaire. Ce mappage apparaît sous la forme suivante dans le fichier de propriétés : map.bg_bug_id>externalreference Certains mappages sont recommandés : Si vous transférez des défauts entre TestDirector et StarTeam, il est recommandé de mapper le champ Résumé de TestDirector avec le champ Synopsis de StarTeam, avec TestDirector comme propriétaire. Ce mappage apparaît sous la forme suivante dans le fichier de propriétés : map.bg_summary>synopsis Si vous transférez des défauts entre TestDirector et StarTeam, il est recommandé de mapper le champ Description de TestDirector avec le champ Description de StarTeam, avec TestDirector comme propriétaire. Ce mappage apparaît sous la 18 Guide de l utilisateur de TestDirector Synchronizer

23 Utilisation des directives de mappage forme suivante dans le fichier de propriétés : map.bg_description>description N utilisez pas l opérateur = dans ce mappage car TestDirector ne peut pas stocker l historique de son champ Description. Nous vous suggérons de mapper le champ Commentaires R & D de TestDirector avec le champ Corriger ou Palliatif de StarTeam (ou les deux), avec StarTeam comme propriétaire. Ce mappage apparaît sous l une des formes suivantes dans le fichier de propriétés : map.bg_dev_comments<fix map.bg_dev_comments<workaround map.bg_dev_comments<fix+workaround N utilisez pas l opérateur = dans ce mappage car TestDirector ne peut pas stocker l historique de son champ Commentaires R & D. Certains mappages sont limités : Ne mappez les champs StarTeam suivants que si StarTeam possède la paire de champs mappés. Ces champs sont indiqués dans l ordre alphabétique des ID. Leur identificateur interne se trouve dans la seconde colonne. Traitée par AddressedBy Traitée dans la version AddressedIn Créer branche si modification BranchOnChange Etat de la branche BranchState N de demande de modification ChangeNumber ID commentaire CommentID Heure de création CreatedTime (utilisé occasionnellement) Créée par CreatedUserID (utilisé occasionnellement) Notation par points DotNotation ID notation par points DotNotationID Heure de fin de modification EndModifiedTime Entrée par EnteredBy Entrée le EnteredOn ID objet ID Dernière version testée LastBuildTested Heure de modification ModifiedTime (utilisé occasionnellement) Modifiée par ModifiedUserID (utilisé occasionnellement) ID parent ParentObjectID Révision de branche mère ParentRevision Révision mère PathRevision Lecture seule ReadOnly Résolue le ResolvedOn Version RevisionNumber ID objet racine RootObjectID Etat de partage ShareState Vérifiée le VerifiedOn Chapitre 3 : Présentation du fichier de propriétés de Synchronizer 19

24 Mise à jour des fichiers de propriétés Synchronizer 5.1 Ne mappez les champs TestDirector suivants que si TestDirector possède la paire de champs mappés. ID défaut BG_BUG_ID Reproductible BG_REPRODUCIBLE Objet BG_SUBJECT Test Set BG_CYCLE_REFERENCE Mappages que vous ne voulez pas commenter ni omettre. Mise à jour des fichiers de propriétés Synchronizer 5.1 Les propriétés de Synchronizer 6.0 diffèrent quelque peu des fichiers de la version 5.1. Si vous continuez à utiliser des fichiers de propriétés 5.1, tenez compte des changements suivants : sync_newfromstarteam a été supprimé. Retirez-le de votre fichier de propriétés. sync_newfrommercury a été supprimé. Retirez-le de votre fichier de propriétés. mtd_send_to_starteam1 a été renommé mtd_send_to_vts. Indiquez le nouveau nom dans votre fichier. mtd_send_to_mtd1 a été renommé vts_send_to_mtd. Indiquez le nouveau nom dans votre fichier. Le mappage suivant a été supprimé : map.bg_user_02=usr_synch Retirez-le de votre fichier de propriétés. Les directives mtd_send_to_vts et vts_send_to_mtd sont définies sur des champs personnalisés comme BG_USER_02 et Usr_Sync (anciennement Usr_Synch) utilisés pour indiquer ce qui doit être synchronisé. Cela rend le mappage redondant. Dans une version précédente de BugSync.ini, Usr_Synch était utilisé dans StarTeam comme nom du champ personnalisé qui servait d indicateur de synchronisation. Usr_Synch était un exemple, mais vous avez peut-être créé un champ avec ce même nom. Le nouveau fichier de propriétés utilise le nom exemple Usr_Sync. Si vous fondez votre fichier de propriétés sur le nouveau fichier Bug.ini mais avez créé un champ personnalisé avec le nom utilisé dans le fichier Bug.ini précédent, remplacez Usr_Sync par Usr_Synch dans le nouveau fichier (ou remplacez le nom du champ StarTeam Usr_Synch par Usr_Sync). Si vous avez mappé les champs StarTeam LastBuildTested et AddressedIn, StarTeam doit posséder le mappage. 20 Guide de l utilisateur de TestDirector Synchronizer

25 Chapitre 4 Modification des fichiers batch 4Exécution de Synchronizer Chapitre Si vous utilisez StarTeam Windows Server, l installation de Synchronizer inclut les fichiers run.bat et run-again.bat. Le serveur StarTeam utilise un fichier run.sh file à la place d un fichier run.bat. Le fichier run.bat ou run.sh permet d exécuter Synchronizer à tout moment. Le fichier run-again.bat permet d exécuter Synchronizer à intervalles réguliers en définissant le nombre de secondes à attendre. Le paramètre d attente se trouve à la fin du fichier run-again.bat. Vous devrez peut-être modifier les fichiers.bat d origine afin qu ils pointent sur les emplacements que votre entreprise utilise pour : L installation de StarTeam. Les fichiers batch initiaux incluent la ligne suivante : SET STARTEAM_Path=C\Program Files\Borland L installation du SDK StarTeam. Les fichiers batch initiaux incluent la ligne suivante : SET STARTEAM_SDK_PATH=%STARTEAM_PATH%\StarTeam SDK xx\ La bibliothèque du SDK StarTeam. Les fichiers batch initiaux incluent la ligne suivante : SET SDK_JAR=%STARTEAM_SDK_PATH%\Lib\StarTeamxx.jar L installation du client Oracle. Les fichiers batch initiaux incluent la ligne suivante : SET ORACLE_PATH=C:\oracle\ora92 La bibliothèque JDBC Oracle. Si vous utilisez une base de données Oracle pour vos projets TestDirector, ces derniers peuvent contenir des champs CLOB. La prise en charge de ces champs exige la spécification correcte de ce chemin. Vous devez en outre modifier les directives mtd_driver(n) et mtd_dataurl(n) pour qu elles pointent sur les pilotes JDBC Oracle correspondants. Les fichiers batch initiaux incluent la ligne suivante : SET ORACLE_CLASSPATH=%ORACLE_PATH%\jdbc\lib\classes12.zip Chapitre 4 : Exécution de Synchronizer 21

26 Examen des fichiers journaux Le chemin d accès à la bibliothèque Java. Les fichiers batch initiaux incluent la ligne suivante : SET _JAVA_LIB_PATH=%STARTEAM_SDK_PATH%\Lib;%Oracle_Path%\bin L environnement d exécution Java installé pour le SDK StarTeam. Les fichiers batch initiaux incluent la ligne suivante : SET JAVA= %STARTEAM_PATH%\Java\Sun1.4.2_01\bin\java.exe Pour visualiser le contenu des fichier batch, reportez-vous à la section Fichiers batch initiaux de Synchronizer, page 51. Examen des fichiers journaux Synchronizer consigne les erreurs et d autres informations dans le fichier mtdsync.log et/ou mtdsync.err. Par exemple, mtdsync.log contient des informations sur le moment où vous avez lancé run.bat (serveur Windows uniquement) ou run.sh (serveur Solaris uniquement), et mtdsync.err vous permet de savoir quand les données ont été tronquées. 22 Guide de l utilisateur de TestDirector Synchronizer

27 Chapitre 5 5Champs Demande de modification Chapitre Cette section explique les champs spécifiques aux demandes de modification et suggère des mappages entre ces champs et des champs Défaut de TestDirector (les demandes de modification étant l équivalent des défauts TestDirector). Les demandes de modification sont ajoutées manuellement via la boîte de dialogue Nouvelle demande de modification dans StarTeam. La liste suivante présente les champs visibles par l utilisateur et les champs internes spécifiques aux demandes de modification pouvant être affichés dans la fenêtre principale de StarTeam. Les champs visibles par l utilisateur font partie de l interface utilisateur standard des demandes de modification. Ces champs sont répertoriés dans l ordre alphabétique de leur ID. Les champs StarTeam avancés sont signalés par le terme (Avancé) après leur nom. Les champs avancés sont répertoriés pour fournir un panorama complet, au cas où vous auriez besoin de les utiliser. Néanmoins, la plupart des utilisateurs de StarTeam TestDirector Synchronizer les emploient rarement. Les champs concernant les verrous (Verrouillé par, Verrouillage et Auteurs de verrous non exclusifs) ont été omis de cette liste car les demandes de modification ne peuvent pas être verrouillées. Traitée par Type : ID utilisateur Valeur : Sélection d une liste d utilisateurs ou <Aucun> Identificateur interne : AddressedBy Indique le nom de l utilisateur qui a résolu la demande de modification. Les demandes de modification ayant l un des états suivants sont considérées comme étant résolues : Impossible à reproduire, Conçu ainsi, Corrigé, Documentation et Est un double. Vous pouvez mapper ce champ avec un champ Liste d utilisateurs TestDirector si le champ TestDirector utilise une liste qui correspond aux noms de connexion dans StarTeam et exige la vérification. En revanche, la longueur des noms d utilisateur dans TestDirector dépend de la base de données, tandis que StarTeam autorise jusqu à 63 caractères. StarTeam doit posséder ce mappage. Traitée dans la version Type : Enumération Valeur : Sélection d une liste d étiquettes de vue ou <Aucun> Chapitre 5 : Champs Demande de modification 23

28 Champs Demande de modification Identificateur interne : AddressedIn Prochaine étiquette de version créée et appliquée à la vue après la résolution d une demande de modification. Vous pouvez mapper ce champ avec un champ chaîne TestDirector ou un champ liste de référence TestDirector qui correspond aux étiquettes StarTeam et exige la vérification. StarTeam doit posséder ce mappage. Traitée dans la vue Type : Enumération Valeur : Sélection d une liste de vues ou <Aucun> Identificateur interne : AddressedInView Indique la vue dans laquelle la demande de modification a été résolue. Ce champ est important pour les demandes de modification partagées et déplacées. Si StarTeam possède le mappage (<), ce champ peut être mappé avec un champ chaîne ou liste de référence TestDirector. Si le mappage est une synchronisation bidirectionnelle (=), ce champ doit être mappé avec un champ liste de référence TestDirector ayant une liste de valeurs correspondante. Nombre de pièces jointes Type : Entier Valeur : Dépend de la base de données Identificateur interne : AttachmentCount Le nombre de fichiers attachés à une demande de modification. Vous pouvez mapper ce champ avec un champ entier dans TestDirector. ID de pièces jointes (Avancé) Type : Texte Valeur : tableau d octets ; affiché sous la forme d une série de nombres hexadécimaux délimitée par des crochets. Par exemple, [ ] indique deux pièces jointes spécifiques. Identificateur interne : AttachmentIDs Les numéros d ID affectés aux pièces jointes. Ne mappez pas ce champ car les fichiers joints ne peuvent pas être déplacés entre deux systèmes. Noms des pièces jointes Type : Texte Valeur : noms de fichiers séparés par des espaces Identificateur interne : AttachmentNames Liste le nom des fichiers attachés à une demande de modification. Les éléments de la liste sont séparés par des espaces. Ne mappez pas ce champ car les fichiers joints ne peuvent pas être déplacés entre deux systèmes. Créer branche si modification (Avancé) Type : Enumération Valeur : Non ou Oui Identificateur interne : BranchOnChange 24 Guide de l utilisateur de TestDirector Synchronizer

29 Champs Demande de modification Remarque Indique si une demande de modification est branchée quand elle est modifiée. Avec la valeur Non, le comportement de la demande de modification n est pas défini sur Créer branche si modification. Les raisons sont les suivantes : La demande de modification réside dans la racine ou une vue référence et la fonctionnalité Créer branche si modification est désactivée. La demande de modification réside dans une vue de branchement mais une branche a déjà été créée à la suite d une modification. Cet événement désactive la fonction Créer branche si modification. La demande de modification réside dans une vue de branchement, mais son comportement ne permet pas actuellement de créer une branche en cas de modification. Les modifications sont donc archivées dans la vue parent. Si la valeur est Non, la valeur de Etat de la branche explique pourquoi. La valeur Oui indique que la demande de modification réside dans une vue de branchement, que son comportement est défini sur Créer branche si modification, mais qu elle doit encore être modifiée. Vous pouvez mapper ce champ avec un champ chaîne TestDirector ou un champ liste de référence TestDirector qui a les valeurs Non et Oui et exige la vérification. StarTeam doit posséder ce mappage. Etat de la branche (Avancé) Type : Enumération Valeur : Branche créée, Pas de branche créée ou Racine. Identificateur interne : BranchState Indique si une demande de modification a été branchée dans la vue enfant, si elle est toujours non branchée (et est donc une partie de la vue parent) ou a été créée dans la vue dans laquelle elle réside. Les valeurs Branche créée et Pas de branche créée s appliquent aux demandes de modification dans les vues de branchement. La valeur Racine s applique aux fichiers créés dans la vue dans laquelle la demande de modification réside actuellement. Si la vue est une vue référence, elle reflète l état de la demande de modification dans le parent de la vue référence. Vous pouvez mapper ce champ avec un champ chaîne TestDirector ou un champ liste de référence TestDirector qui a les valeurs Branche créée, Pas de branche créée et Racine et exige la vérification. StarTeam doit posséder ce mappage. Category Type : Texte Valeur : Jusqu à 64 caractères Identificateur interne : Category Texte identifiant le sous-composant dans lequel le défaut a eu lieu. Il est généralement utilisé avec le champ Composant. Vous pouvez mapper ce champ avec un champ chaîne TestDirector personnalisé. En revanche, comme la valeur maximale des champs chaîne TestDirector dépend de la base de données, TestDirector doit posséder ce champ pour empêcher la perte des données. Terminé le Type : Date/heure Valeur : Date et heure Identificateur interne : ClosedOn Chapitre 5 : Champs Demande de modification 25

30 Champs Demande de modification La date et l heure sur lesquelles une demande de modification a été fermée. (StarTeam remplit automatiquement ce champ quand la demande de modification prend l état fermé.) Vous pouvez mapper ce champ avec un champ date TestDirector si StarTeam possède la paire de champs mappés ; en revanche, l heure sera perdue. Commentaire Type : Mémo (champ chaîne très long) Valeur : Un nombre très élevé de caractères texte Identificateur interne : Comment Contient le texte complet du commentaire de révision, qui doit expliquer la raison de la modification des propriétés d une demande de modification. (Les premiers caractères du commentaire de révision sont stockés dans le champ Commentaire bref.) Notez que la modification des propriétés entraîne la création d une nouvelle révision par StarTeam. Vous pouvez mapper ce champ avec un champ chaîne TestDirector. Les données peuvent cependant être tronquées lorsqu elles sont transférées dans TestDirector, car la longueur maximale des champs chaîne TestDirector dépend de la base de données. ID commentaire (Avancé) Type : Entier Valeur : Dépend de la base de données Identificateur interne : CommentID Le numéro d ID affecté à un commentaire de révision. Ce champ affiche -1 si aucun commentaire de révision n a été fourni. Vous pouvez mapper ce champ avec un champ chaîne TestDirector si StarTeam possède la paire de champs mappés. Composant Type : Texte Valeur : Jusqu à 64 caractères Identificateur interne : Component Texte identifiant le composant dans lequel le défaut a eu lieu. Il est souvent utilisé avec le champ Catégorie pour réduire cette identification à un sous-composant. Vous pouvez mapper ce champ avec un champ chaîne TestDirector personnalisé. En revanche, comme la valeur maximale des champs chaîne TestDirector dépend de la base de données, TestDirector doit posséder ce champ pour empêcher la perte des données. Heure de configuration Type : Date/heure Valeur : Date et heure Identificateur interne : ConfigurationTime Indique la date et l heure de la configuration d une demande de configuration. Si vous configurez une demande de configuration par une heure spécifique, ce champ contient cette heure. Si vous configurez une demande de configuration par une étiquette ou un état de promotion, ce champ affiche l heure de création de l étiquette ou l heure de création de l étiquette associée à l état de promotion. Vous pouvez mapper ce champ avec un champ date TestDirector si StarTeam possède la paire de champs mappés ; en revanche, l heure sera perdue. 26 Guide de l utilisateur de TestDirector Synchronizer

31 Champs Demande de modification N de demande de modification Type : Entier Valeur : Dépend de la base de données Identificateur interne : ChangeNumber Le numéro affecté à une demande de modification. (Par exemple, si l ID objet est 0, le numéro de la demande de modification est 1. Ce champ est contrôlé par StarTeam. Vous pouvez le mapper avec un champ nombre TestDirector, mais uniquement si StarTeam possède la paire de champs mappés. Créée par (Avancé) Type : ID utilisateur Valeur : Sélection d une liste d utilisateurs ou <Aucun> Identificateur interne : CreatedUserID Le nom de l utilisateur qui a créé la première révision dans la vue. Il s agit de l utilisateur qui a initié la demande de modification ou de celui qui a modifié la révision ayant créé une branche. Vous pouvez mapper ce champ avec un champ Liste d utilisateurs TestDirector si le champ TestDirector utilise une liste qui correspond aux noms de connexion dans StarTeam et exige la vérification. En revanche, la longueur des noms d utilisateur dans TestDirector dépend de la base de données, tandis que StarTeam autorise jusqu à 63 caractères. StarTeam doit posséder ce mappage. Heure de création (Avancé) Type : Date/heure Valeur : Date et heure Identificateur interne : CreatedTime La date et l heure de création de la première révision dans la vue. Vous pouvez mapper ce champ avec un champ date TestDirector si StarTeam possède la paire de champs mappés ; en revanche, l heure sera perdue. Supprimé par Type : ID utilisateur Valeur : Sélection d une liste d utilisateurs ou <Aucun> Identificateur interne : DeletedUserID Le nom de l utilisateur qui a supprimé une demande de modification. Puisque les demandes de modification supprimées n apparaissent pas dans la liste, cette information n est pas disponible pour les utilisateurs. Champ non disponible pour le mappage. Heure de suppression (Avancé) Type : Date/heure Valeur : Date et heure Identificateur interne : DeletedTime La date et l heure de suppression d une demande de modification. Puisque les demandes de modification supprimées n apparaissent pas dans la liste, cette information n est pas disponible pour les utilisateurs. Champ non disponible pour le mappage. Chapitre 5 : Champs Demande de modification 27

32 Champs Demande de modification Description Type : Mémo (champ chaîne très long) Valeur : Un nombre très élevé de caractères texte Identificateur interne : Description Description du problème, y compris les étapes nécessaires à sa reproduction. Vous pouvez mapper le champ Description TestDirector au champ Description StarTeam, avec TestDirector comme propriétaire de la paire. Notation par points Type : Texte Valeur : Numéro de révision de branche Identificateur interne : DotNotation Le numéro de révision de la branche, par exemple Vous pouvez mapper ce champ avec un champ chaîne TestDirector si StarTeam possède la paire de champs mappés. ID notation par points (Avancé) Type : Entier Valeur : Dépend de la base de données Identificateur interne : DotNotationID L ID affecté à un numéro de révision de branche particulier. Par exemple, si une demande de modification a été ajoutée à la vue en cours (par opposition à héritée par la vue en cours), son numéro de révision de branche est 1.x et son ID de révision de branche est 0. Si une demande de modification a été branchée dans la vue en cours, son ID de révision de branche dépend du numéro de révision dans la vue parent et du numéro de révision de branche des ID déjà affectés dans la vue en cours. Par exemple, si le numéro de révision d une demande de modification dans la vue parent est 1.7 au moment de la création de la branche, et qu une autre demande de modification ayant ce même numéro de révision parent se voit affecté l ID 6 de révision de branche, cette demande de modification se verra aussi affecté l ID 6 de révision de branche. Vous pouvez mapper ce champ avec un champ nombre TestDirector, mais uniquement si StarTeam possède la paire de champs mappés. Heure de fin de modification (Avancé) Type : Date/heure Valeur : Date et heure Identificateur interne : EndModifiedTime La date et l heure auxquelles une révision a cessé d être la dernière révision. Bien que ce champ puisse être affiché dans le volet supérieur d un client StarTeam, sa valeur est toujours vide. En effet, à n importe quelle heure de configuration donnée, l élément est encore la dernière révision. Vous pouvez mapper ce champ avec un champ date TestDirector si StarTeam possède la paire de champs mappés ; en revanche, l heure sera perdue. Entrée par Type : ID utilisateur Valeur : Sélection d une liste d utilisateurs ou <Aucun> Identificateur interne : EnteredBy Le nom de l utilisateur qui a créé cette demande de modification. 28 Guide de l utilisateur de TestDirector Synchronizer

33 Champs Demande de modification Vous pouvez mapper ce champ avec un champ Liste d utilisateurs TestDirector si le champ TestDirector utilise une liste qui correspond aux noms de connexion dans StarTeam et exige la vérification. En revanche, la longueur des noms d utilisateur dans TestDirector dépend de la base de données, tandis que StarTeam autorise jusqu à 63 caractères. StarTeam doit posséder ce mappage. Entrée le Type : Date/heure Valeur : Date et heure Identificateur interne : EnteredOn La date et l heure de création de cette demande de modification. Vous pouvez mapper ce champ avec un champ date TestDirector si StarTeam possède la paire de champs mappés ; en revanche, l heure sera perdue. Référence externe Type : Texte Valeur : Jusqu à 64 caractères Identificateur interne : ExternalReference Texte généralement utilisé pour indiquer un client ou une autre source externe ayant fourni les données pour cette demande de modification. Ce champ doit être mappé avec le champ ID défaut TestDirector (BG_BUG_ID) et TestDirector doit posséder le mappage. Corriger Type : Mémo (champ chaîne très long) Valeur : Un nombre très élevé de caractères texte Identificateur interne : Fix Permet d expliquer la correction exacte implémentée pour le problème enregistré dans cette demande de modification. Ce champ est mappé avec les Commentaires R & D dans le fichiers de propriétés initial ; il est possédé par StarTeam. Vous pouvez mapper les commentaires R & D avec les champs Corriger et Palliatif. Voir R & D Comments, page 40. Indicateur Type : Enumération Valeur : Non ou Oui Identificateur interne : Flag Un indicateur marque ou identifie les demandes de modification dans la liste des demandes. Vous pouvez marquer un élément pour vous rappeler qu il faut suivre la demande d un client. Le champ Indicateur affiche Oui (avec un drapeau bleu pour indiquer que l élément est marqué) ou Non (pour indiquer que l élément n est pas marqué). Comme ce champ dépend de l utilisateur et donc du nom de connexion StarTeam indiqué dans le fichier de propriétés, son mappage ne s avérera peut-être pas très utile. Vous pouvez mapper ce champ avec un champ chaîne TestDirector ou un champ liste de référence TestDirector qui a les valeurs Non et Oui et exige une vérification. Chapitre 5 : Champs Demande de modification 29

34 Champs Demande de modification Marquer liste utilisateur (Avancé) Valeur : tableau d octets ; affiché sous la forme d une série de nombres hexadécimaux délimitée par des crochets. Par exemple, [ ] indique un utilisateur spécifique. Identificateur interne : FlagUserList A usage interne seulement. Identifie les utilisateurs ayant défini des indicateurs sur un élément donné. Ne mappez pas ce champ. Dossier Type : Texte Valeur : Jusqu à 254 caractères Identificateur interne : Folder Le nom du dossier StarTeam qui stocke la demande de modification. Vous pouvez mapper ce champ avec un champ chaîne TestDirector. Le nom des dossiers est tronqué, sauf s il respecte les limites de caractères définies pour les champs chaîne dans TestDirector. Pour limiter les erreurs, utilisez une liste contenant le nom des dossiers et exigeant une vérification. Chemin du dossier Type : Texte Valeur : Jusqu à 254 caractères Identificateur interne : Folder path (inclut un espace) Le chemin du dossier StarTeam qui stocke la demande de modification. Vous pouvez mapper ce champ avec un champ chaîne TestDirector. En revanche, les chemins de dossiers sont tronqués s ils dépassent les limites de caractères définies dans TestDirector pour les champs chaîne. Dans la mesure où il est probable que les champs excèdent les limites TestDirector, le mappage de ce champ n est pas recommandé. Dernière version testée Type : Enumération Valeur : Sélection d une liste d étiquettes de version dans la vue ou <Aucun> Identificateur interne : LastBuildTested L étiquette de build sélectionnée par un utilisateur pour représenter le dernier build dans lequel une demande de modification a été testée. Vous pouvez mapper ce champ avec un champ chaîne TestDirector ou un champ liste de référence TestDirector qui correspond aux étiquettes de version StarTeam et exige une vérification. StarTeam doit posséder ce mappage. Modifié par Type : ID utilisateur Valeur : Sélection d une liste d utilisateurs ou <Aucun> Identificateur interne : ModifiedUserID Le nom du dernier utilisateur qui a modifié une demande de modification. Vous pouvez mapper ce champ avec un champ Liste d utilisateurs TestDirector si le champ TestDirector utilise une liste qui correspond aux noms de connexion dans StarTeam et exige la vérification. En revanche, la longueur des noms d utilisateur dans TestDirector dépend de la base de données, tandis que StarTeam autorise jusqu à 63 caractères. StarTeam doit posséder ce mappage. 30 Guide de l utilisateur de TestDirector Synchronizer

35 Champs Demande de modification Heure de modification Type : Date/heure Valeur : Date et heure Identificateur interne : ModifiedTime Date et heure de la dernière modification d une demande de modification. Vous pouvez mapper ce champ avec un champ date TestDirector si StarTeam possède la paire de champs mappés ; en revanche, l heure sera perdue. Commentaire de la nouvelle révision (Avancé) Type : Texte Valeurs : texte Identificateur interne : New Revision Comment (inclut des espaces) A usage interne seulement. Le client StarTeam utilise cette valeur pendant le processus de mise à jour de l élément. Le champ apparaît toujours vide s il est ajouté au volet supérieur du client StarTeam. Ne mappez pas ce champ. ID objet (Avancé) Type : Entier Valeur : Dépend de la base de données Identificateur interne : ID Un ID objet est attribué à chaque demande de modification lors de son ajout à une vue. Quand la demande de modification est branchée dans une vue enfant, un autre ID objet lui est affecté. L ID d origine appartient à la demande de modification de la vue parent. Vous pouvez mapper ce champ avec un champ nombre TestDirector, si StarTeam possède la paire de champs mappés. Révision de branche mère (Avancé) Type : Nombre Valeur : -1, 0 ou entier positif Identificateur interne : ParentRevision Le dernier chiffre du numéro de révision de branche avant qu une demande de modification ne soit branchée. Par exemple, si ce numéro est 7, la révision de branche était 1.7 lors du branchement de la demande de modification (devenant , comme affiché dans l historique de la demande de modification). Ce numéro est -1 si une demande de modification n est pas héritée de la vue parent. Vous pouvez mapper ce champ avec un champ nombre TestDirector, si StarTeam possède la paire de champs mappés. ID parent (Avancé) Type : Entier Valeur : Dépend de la base de données Identificateur interne : ParentObjectID Numéro d identification de l objet d une demande de modification dans la vue parent. L ID parent est -1 si cette vue n a pas de vue parent. Vous pouvez mapper ce champ avec un champ nombre TestDirector, si StarTeam possède la paire de champs mappés. Chapitre 5 : Champs Demande de modification 31

36 Champs Demande de modification Révision mère (Avancé) Type : Entier Valeur : Dépend de la base de données Identificateur interne : PathRevision Numéro de la révision au moment auquel une demande de modification a été branchée. Par exemple, si ce numéro est 8, le numéro de révision de la demande de modification dans la vue parent était 8 lors du branchement de la demande de modification. L historique devrait indiquer que la révision 9 est la première révision de la vue en cours. Ce numéro est 0 si cette demande de modification n est pas héritée de la vue parent. Vous pouvez mapper ce champ avec un champ nombre TestDirector, si StarTeam possède la paire de champs mappés. Plate-forme Type : Enumération Valeur : Tous, MacOS, Autre, Unix, Windows 2000, Windows 95, Windows 98, Windows NT, Windows XP. La valeur par défaut est Tous. Identificateur interne : Platform Système d exploitation sur lequel le problème est survenu. Dans StarTeam, ce champ ne peut pas être obligatoire, son nom peut être changé, et vous pouvez ajouter des valeurs à la liste d énumération des systèmes d exploitation ou changer le nom des valeurs existantes. Vous pouvez mapper ce champ avec un champ liste de référence TestDirector qui a une liste des valeurs du champ Plate-forme StarTeam. Priorité Type : Enumération Valeur : Non ou Oui Identificateur interne : Priority Valeur du champ Priorité, qui doit indiquer l importance du problème. Dans StarTeam, ce champ ne peut pas être obligatoire, son nom peut être changé, et vous pouvez ajouter des valeurs à la liste d énumération ou changer le nom des valeurs existantes. La plupart des personnes utilisent la personnalisation du référentiel pour étendre ce champ afin d inclure d autres valeurs car les booléens sont traités dans StarTeam comme des types énumération. Par exemple, Non est 0 et Oui est 1. Un administrateur pourrait changer Non en Pas une priorité, Oui en Priorité 1, et ajouter des priorités allant de 2 à 10. Vous pouvez mapper ce champ avec un champ Priorité TestDirector. Les choix proposés dans ces deux champs correspondants doivent être identiques. Vous pouvez également mapper ce champ avec un champ liste de référence TestDirector qui a une liste des valeurs du champ Priorité StarTeam et exige une vérification. Lecture seule (Avancé Type : Enumération Valeur : Non ou Oui Identificateur interne : ReadOnly Indique si la configuration de la demande de modification est en lecture seule (comme dans la configuration de restauration d une vue) et/ou si son comportement ne lui permet pas de créer une branche lors d une modification. 32 Guide de l utilisateur de TestDirector Synchronizer

37 Champs Demande de modification Vous pouvez mapper ce champ avec un champ chaîne TestDirector ou un champ liste de référence TestDirector qui a les valeurs Non et Oui et exige la vérification. StarTeam doit posséder ce mappage. Etat A lire Type : Enumération Valeur : Lu ou non lu Identificateur interne : Read Status (inclut un espace) Indique si une demande de modification est considérée comme lue ou non lue. Comme ce champ dépend de l utilisateur et donc du nom de connexion StarTeam indiqué dans le fichier de propriétés, son mappage ne s avérera peut-être pas utile. Vous pouvez mapper ce champ avec un champ chaîne TestDirector ou un champ liste de référence TestDirector qui a les valeurs Lu et Non lu et exige une vérification. Liste des utilisateurs avec état A lire Valeur : tableau d octets ; affiché sous la forme d une série de nombres hexadécimaux délimitée par des crochets. Par exemple, [ ] indique un utilisateur spécifique. Identificateur interne : ReadStatusUserList A usage interne seulement. Identifie les utilisateurs dont l état d un élément donné est non lu. Ne mappez pas ce champ. Résolue le Type : Date/heure Valeur : Date et heure Identificateur interne : ResolvedOn Date et heure de résolution d une demande de modification. StarTeam complète automatiquement ce champ lorsque le statut d une demande de modification passe à Résolu. Les résolutions peuvent avoir l un des états suivants : Impossible à reproduire, Conçu ainsi, Corrigé, Documentation et Est un double. Vous pouvez mapper ce champ avec un champ date TestDirector si StarTeam possède la paire de champs mappés ; en revanche, l heure sera perdue. Responsabilité Type : ID utilisateur Valeur : Sélection d une liste d utilisateurs ou <Aucun> Identificateur interne : Responsibility Nom de l utilisateur actuellement responsable de cette demande de modification. Vous pouvez mapper ce champ avec un champ Liste d utilisateurs TestDirector personnalisé associé à la liste des utilisateurs. Si vous procédez à ce mappage, sachez toutefois que la liste des utilisateurs doit correspondre aux noms de connexion StarTeam en longueur. La longueur des noms d utilisateur dans TestDirector dépend de la base de données, tandis que StarTeam autorise jusqu à 63 caractères. Indicateurs de révision (Avancé) Valeurs : 0 Identificateur interne : RevisionFlags A usage interne seulement. Chapitre 5 : Champs Demande de modification 33

38 Champs Demande de modification Ne mappez pas ce champ. ID objet racine (Avancé) Type : Entier Valeur : Dépend de la base de données Identificateur interne : RootObjectID ID d objet du plus ancien ancêtre d une demande de modification. Par exemple, si une demande de modification n est pas héritée d une vue parent, l ID d objet racine est le même que son ID d objet. Si elle est héritée d une vue parent, l ID d objet racine est l ID Parent ou l ID Parent du parent. Vous pouvez mapper ce champ avec un champ nombre TestDirector, si StarTeam possède la paire de champs mappés. Gravité Type : Enumération Valeur : Elevée, Faible (valeur par défaut) ou Moyenne Identificateur interne : Severity Impact du problème sur le produit. Dans StarTeam, ce champ ne peut pas être obligatoire, son nom peut être changé, et vous pouvez ajouter des valeurs à la liste d énumération ou changer le nom des valeurs existantes. Vous pouvez mapper ce champ avec un Gravité TestDirector, si les choix proposés dans ces deux champs correspondants sont les mêmes. Vous pouvez également mapper ce champ avec un champ liste de référence TestDirector qui a une liste des valeurs du champ Gravité StarTeam et exige une vérification. Etat de partage Type : Enumération Valeur : Dérivé partagé, Non partagé ou Partage racine Identificateur interne : ShareState Indique si cet élément est partagé. Partage racine signifie que l élément est partagé et qu il est la référence d origine (ou racine). Dérivé partagé signifie que l élément est partagé, mais qu il n est pas la référence d origine (ou racine). La signification de Non partagé est évidente. Vous pouvez mapper ce champ avec un champ chaîne TestDirector ou un champ liste de référence TestDirector qui a les valeurs correctes et exige une vérification. StarTeam doit posséder ce mappage. Commentaire bref Type : Mémo (champ chaîne très long) Valeur : Les premiers caractères du commentaire de révision Identificateur interne : ShortComment Contient les premiers caractères du commentaire de révision, qui explique généralement la raison de la modification des propriétés de la demande de modification. (Le texte complet est stocké dans le champ Commentaire.) Notez que la modification des propriétés entraîne la création d une nouvelle révision par StarTeam. Vous pouvez mapper ce champ avec un champ chaîne TestDirector. Les données peuvent cependant être tronquées lorsqu elles sont transférées dans TestDirector, car la longueur maximale des champs chaîne TestDirector dépend de la base de données. 34 Guide de l utilisateur de TestDirector Synchronizer

39 Champs Demande de modification Etat Type : Enumération Valeur : Nouveau, Ouvert, En cours, Différé, Impossible à reproduire, Conçu ainsi, Corrigé, Documentation, Est un double, Vérifié : Différé, Vérifié : Impossible à reproduire, Vérifié : Conçu ainsi, Vérifié : Corrigé, Vérifié : Documentation, Vérifié : Est un double, Fermé : Différé, Fermé : Impossible à reproduire, Fermé : Conçu ainsi, Fermé : Corrigé, Fermé : Documentation, Fermé : Est un double. La valeur par défaut est Nouveau. Identificateur interne : Status Etat de la demande de modification. Dans StarTeam, ce champ ne peut pas être obligatoire et son nom peut être changé. Aucune autre personnalisation n est possible dans StarTeam. Vous pouvez mapper ce champ avec un champ chaîne TestDirector ou un champ liste de référence TestDirector qui a les valeurs correctes et exige une vérification. Synopsis Type : Mémo (champ chaîne très long) Valeur : Un nombre très élevé de caractères texte Identificateur interne : Synopsis Résumé du problème. Vous pouvez mapper ce champ avec un champ Résumé TestDirector. Cependant, comme le champ Résumé TestDirector peut contenir au maximum 70 caractères, TestDirector doit posséder ce champ. Commande de test Type : Texte Valeur : Jusqu à 254 caractères Identificateur interne : TestCommand Chemin d accès à un programme qui teste le problème couvert par cette demande de modification. Vous pouvez mapper ce champ avec un champ chaîne dans TestDirector. En revanche, la longueur maximale des champs chaîne dans TestDirector dépend de la base de données. Comme cette longueur ne suffira peut-être pas pour la plupart des chemins, ce champ n est généralement pas mappé. Type Type : Enumération Valeur : Défaut (valeur par défaut) ou Suggestion Identificateur interne : Type Type de la demande de modification. Dans StarTeam, ce champ ne peut pas être obligatoire, son nom peut être changé, et vous pouvez ajouter des valeurs à la liste d énumération ou changer le nom des valeurs existantes. Vous pouvez mapper ce champ avec un champ chaîne TestDirector ou un champ liste de référence TestDirector qui a les valeurs correctes et exige une vérification. Vérifiée le Type : Date/heure Valeur : Date et heure Chapitre 5 : Champs Demande de modification 35

40 Champs Demande de modification Identificateur interne : VerifiedOn Date et heure de vérification d une demande de modification. La résolution peut avoir l un des états suivants : Vérifié : Impossible à reproduire, Vérifié : Conçu ainsi, Vérifié : Corrigé, Vérifié : Documentation ou Vérifié : Est un double. StarTeam complète automatiquement ce champ lorsque le statut d une demande de modification passe à Vérifié. Vous pouvez mapper ce champ avec un champ date TestDirector si StarTeam possède la paire de champs mappés ; en revanche, l heure sera perdue. Version (Avancé) Type : Entier Valeur : Dépend de la base de données Identificateur interne : RevisionNumber Dernier numéro dans le numéro de révision de branche. Par exemple, si le numéro de révision de branche est , la version est 2. Vous pouvez mapper ce champ avec un champ nombre TestDirector, si StarTeam possède la paire de champs mappés. Vue Type : Enumération Valeur : Sélection d une liste de vues ou <Aucun> Identificateur interne : ViewID Nom de la vue dans laquelle la révision encours a été créée. Champ non disponible pour le mappage. Palliatif Type : Mémo (champ chaîne très long) Valeur : Un nombre très élevé de caractères texte Identificateur interne : WorkAround Description des solutions disponibles pour le problème enregistré dans cette demande de modification. Ce champ peut être mappé avec le champ Commentaires R & D, mais vous pouvez aussi mapper le champ Corriger au champ Commentaires R & D. Vous pouvez ensuite demander aux utilisateurs de StarTeam d ignorer le champ Palliatif et placer les solutions et palliatifs dans le champ Corriger. Vous pouvez également mapper le champ Commentaires R & D avec les champs Corriger et Palliatif. Voir R & D Comments, page Guide de l utilisateur de TestDirector Synchronizer

41 Chapitre 6 6Champs Défaut TestDirector Chapitre Cette section explique les champs Défaut TestDirector et suggère des mappages entre ces champs et des champs de demande de modification TestDirector Les défauts peuvent être ajouté à TestDirector automatiquement à partir des résultats des tests ou manuellement. Quand vous saisissez un défaut manuellement, la boîte de dialogue Add Defect s ouvre. Les champs obligatoires de cette boîte de dialogue sont affichés en rouge. TestDirector contient plusieurs champs prédéfinis. Dans cette section, ces champs sont répertoriés dans l ordre alphabétique. L administrateur TestDirector détermine les champs visibles, les champs obligatoires et l ordre d affichage des champs. Actual Fix Time Type : Nombre Valeur : Dépend de la base de données Identificateur interne : BG_ACTUAL_FIX_TIME Nombre réel d heures nécessaires à la correction. Vous pouvez mapper ce champ avec un champ numéro TestDirector personnalisé. Assigned To Type : Liste de référence Valeur : Limitée aux choix de la liste des utilisateurs, lorsque la vérification est nécessaire. Identificateur interne : BG_RESPONSIBLE Indique qui est actuellement responsable du défaut. Il est préférable d utiliser deux champs ici (un pour chaque application) au lieu de mapper ce champ avec le champ Responsabilité de StarTeam. Si le deux champs sont mappés, les noms d utilisateur doivent être limitée à la longueur maximale du champ TestDirector, qui dépend de la base de données. StarTeam autorise 63 caractères pour les noms d utilisateur. En outre, si l historique est utilise pour déterminer le contenu de cette paire de champs, le workflow associé au champ Etat de StarTeam affecte la valeur des champs. StarTeam remplace automatiquement le contenu du champ Responsabilité par le nom de connexion de l utilisateur qui a créé ma demande de Chapitre 6 : Champs Défaut TestDirector 37

42 Champs Défaut TestDirector modification. Dans TestDirector Synchronizer, le créateur de la demande de modification est l utilisateur dont le nom de connexion est utilisé par Synchronizer pour accéder au serveur StarTeam. Par exemple, le fichier BugSync.ini initial spécifie Administrator comme valeur de vts_username1 et, par conséquent, comme le nom d utilisateur utilisé pour les connexions. Attachment Type : Chaîne Valeur : O ou N Identificateur interne : BG_ATTACHMENT Champ qui indique si le défaut a ou pas une pièce jointe. Quand un défaut acquiert une demande de modification, la valeur N est remplacée par O. Ce champ peut être mappé à un champ énumération StarTeam personnalisé (ou un champ texte StarTeam, s il est possédé par TestDirector). Synchronizer peut déplacer des pièces jointes si vous utilisez les directives mtd_hostname(n) et mtd_database(n) dans le fichier de propriétés. Si vous devez transférer des pièces jointes TestDirector dans StarTeam (ou vice versa), prenez contact avec les services professionnels à l adresse Closed in Version Type : Chaîne Valeur : Limitée aux choix de la liste des versions, lorsque la vérification est nécessaire. Identificateur interne : BG_CLOSING_VERSION Version dans laquelle le défaut a été fermé. Vous pouvez mapper ce champ avec un champ énumération StarTeam personnalisé. Closing Date Type : Date Valeur : Chaîne de caractères identifiant une date Identificateur interne : BG_CLOSING_DATE Date à laquelle le défaut a été fermé dans TestDirector. Vous pouvez mapper ce champ avec un champ date/heure StarTeam personnalisé. Attention, quand l état Fermé apparaît dans le champ Etat StarTeam, StarTeam définit automatiquement ces date et heure comme valeur du champ StarTeam Terminé le. Defect ID Type : Nombre Valeur : Dépend de la base de données Identificateur interne : BG_BUG_ID Numéro unique identifiant le défaut. TestDirector incrémente ce défaut au fur et à mesure que de nouveaux défauts sont ajoutés. Le fichier de propriétés initial mappe le champ ID défaut avec le champ Référence externe de StarTeam. Ne modifiez pas ce mappage. Ce champ a la même signification que le champ N de demande de modification de StarTeam. Ne le mappez toutefois pas au champ N de demande de modification, car StarTeam gère lui-même la valeur de ce champ. Description Type : Mémo (champ chaîne très long) 38 Guide de l utilisateur de TestDirector Synchronizer

43 Champs Défaut TestDirector Valeur : Texte ; peut contenir d importants volumes de données. Les limites de taille dépendent du type de base de données utilisée. Identificateur interne : BG_DESCRIPTION Description complète du problème, avec en général les étapes nécessaires à sa reproduction. Vous pouvez mapper le champ Description TestDirector au champ Description StarTeam, avec TestDirector comme propriétaire de la paire. Le champ Description StarTeam est également un champ mémo. Detected By Type : Utilisateur Valeur : Limitée aux choix de la liste des utilisateurs lorsque la vérification est nécessaire. Ces noms d utilisateur doivent correspondre aux nom de connexion StarTeam. Identificateur interne : BG_DETECTED_BY Nom de l utilisateur qui a signalé le défaut. Ce champ ne peut pas être mappé au champ Entré par de StarTeam, car le champ Entré par contient automatiquement le nom de l utilisateur qui s est connecté lorsque le défaut a été créé dans StarTeam. Ce nom d utilisateur provient de Synchronizer. TestDirector est un exemple de nom d utilisateur. Detected in Version Type : Liste de référence Valeur : Limitée aux choix de la liste des versions Identificateur interne : BG_DETECTION_VERSION Version du produit dans laquelle le problème est survenu. Vous pouvez mapper ce champ au champ Dernière version testée de StarTeam, à condition que la liste des versions contienne le nom de toutes les étiquettes de version StarTeam (orthographiées exactement comme dans StarTeam). Ce mappage n est toutefois par recommandé par Borland car le champ Planned Closing Version de TestDirector utilise la même liste de versions. L utilisation du champ Planned Closing Version nécessiterait ainsi des étiquettes de version future et, par conséquent, une coordination importante entre les administrateurs TestDirector et StarTeam. Detected on Date Type : Date Valeur : Chaîne de caractères identifiant une date Identificateur interne : BG_DETECTION_DATE Date à laquelle le défaut a été signalé. Ce champ ne peut pas être mappé avec les champs Created Time et Entered On fields dans StarTeam, car StarTeam complète automatiquement ces champs. Vous pouvez le mapper avec un champ date/heure StarTeam personnalisé. Estimated Fix Time Type : Nombre Valeur : Dépend de la base de données Identificateur interne : BG_ESTIMATED_TIME_FIX Estimation du nombre d heures nécessaires à la correction. Vous pouvez mapper ce champ avec un champ numérique StarTeam personnalisé. Chapitre 6 : Champs Défaut TestDirector 39

44 Champs Défaut TestDirector Planned Closing Version Type : Liste de référence Valeur : Limitée aux choix de la liste des versions Identificateur interne : BG_PLANNED_CLOSING_VER Version du produit dans laquelle le problème doit être corrigé. Vous pouvez mapper ce champ avec un champ énumération StarTeam personnalisé (ou un champ texte StarTeam si ce champ est possédé par TestDirector). Voir Detected in Version, page 39, pour de plus amples informations. Priority Type : Liste de référence Valeur : Limitée aux choix de la liste Priorité quand la vérification est requise ; par défaut les valeurs sont 1-Faible, 2-Moyenne, 3-Elevée, 4-Très élevée et 5-Urgent. Vous pouvez modifier ou supprimer ces choix. Identificateur interne : BG_PRIORITY Importance de la correction du défaut sur le projet ou le produit. Vous pouvez mapper ce champ avec un champ Priorité StarTeam. Pour garantir une correspondance exacte des deux champs, vous pouvez personnaliser la liste Priorité dans TestDirector (par exemple, en ajoutant 0-Sans priorité) ou personnaliser le champ Priorité StarTeam (par exemple, en remplaçant 0 Non par 0-Sans priorité, 1 Oui par 1-Faible et en ajoutant 2-Moyenne, 3-Elevée, 4-Très élevée et 5-Urgent). Les choix proposés dans ces deux champs doivent être identiques. Project Type : Liste de référence Valeur : Limitée aux choix de la liste des projets, lorsque la vérification est nécessaire. Identificateur interne : BG_PROJECT Sert généralement à définir le produit ou composant dans lequel se trouve le problème. Le champ Projet peut être mappé au champ Composant de StarTeam. Sa longueur dépend de la base de données, tandis que le champ Composant de StarTeam peut contenir 64 caractères. TestDirector doit posséder ce champ pour empêcher la perte de données. Comme un développeur qui travaille dans StarTeam peut ne pas être au courant des choix dans la liste Projet de TestDirector, vous pouvez à la place mapper ce champ avec un champ énumération personnalisé. R & D Comments Type : Mémo (champ chaîne très long) Valeur : Texte ; peut contenir d importants volumes de données. Identificateur interne : BG_DEV_COMMENTS Informations communiquées par les développeurs aux testeurs. Dans une version précédente, ce champ était automatiquement mappé avec le champ Palliatif de StarTeam et le champ Corriger de StarTeam. Vous pouvez toujours appliquer ce mappage, mais il n est plus réalisé automatiquement. Incluez la directive suivante dans votre fichier de propriétés : map.bg_dev_comments<fix+workaround 40 Guide de l utilisateur de TestDirector Synchronizer

45 Champs Défaut TestDirector Dans ce cas, le champ Commentaires R & D (BG_DEV_COMMENTS) doit être possédé par StarTeam. Comme BG_DEV_COMMENTS est un champ mémo TestDirector, vous pouvez le mapper avec le champ Corriger, Palliatif ou les deux sans perdre de données. Dans la mesure où les informations historiques sur le champ Commentaires R & D ne peuvent pas être stockées dans TestDirector, ce champ doit être possédé par l une des applications. Par exemple, le champ Commentaires R & D de TestDirector peut être mappé avec le champ Corriger de StarTeam avec StarTeam comme propriétaire. Nous vous suggérons d utiliser Groupes dans TestDirector pour empêcher les utilisateurs d accéder à ce champ. La boîte de dialogue Permission Settings du <groupe> contient la case à cocher Add R & D Comments. Si vous décochez cette case, aucun membre du groupe ne peut modifier ce champ. Pour plus d informations, consultez la documentation ou l aide en ligne de TestDirector. Reproducible Type : Chaîne/Liste de référence Valeur : Sélectionné ou non sélectionné Identificateur interne : BG_REPRODUCIBLE Indique si un problème peut être reproduit. Vous pouvez mapper ce champ avec un champ texte StarTeam, s il est possédé par TestDirector. Run Reference Type : Nombre Valeur : Dépend de la base de données Identificateur interne : BG_RUN_REFERENCE Nombre d exécutions du test. Vous pouvez mapper ce champ avec un champ entier StarTeam personnalisé, le cas échéant. Severity Type : Liste de référence Valeur : Limitée aux choix de la liste Gravité quand la vérification est requise ; par défaut les valeurs sont 1-Faible, 2-Moyenne, 3-Elevée, 4-Très élevée et 5-Urgent. Vous pouvez modifier ou supprimer ces choix. Identificateur interne : BG_SEVERITY Impact du défaut sur le projet ou le produit. Vous pouvez mapper ce champ avec le champ Gravité de StarTeam ou un champ énumération StarTeam personnalisé. Vous pouvez le mapper avec un champ texte si TestDirector possède la paire de champs mappés. Pour garantir une correspondance exacte des champs Gravité, vous pouvez soit personnaliser la liste Gravité dans TestDirector (par exemple, en supprimant 4-Très élevée et 5-Urgent) soit personnaliser la liste Gravité dans StarTeam (par exemple, en ajoutant Très élevée et Urgent). Les choix proposés dans ces deux champs doivent être identiques. Status Type : Chaîne/Liste de référence Valeur : Limitée aux choix de la liste Bug Status quand la vérification est requise ; par défaut les valeurs sont Nouveau, Ouvert, Corrigé, Fermé, Rouvert et Rejeté. Identificateur interne : BG_STATUS Indique l état du défaut, par exemple Ouvert ou Fermé. Chapitre 6 : Champs Défaut TestDirector 41

46 Champs Défaut TestDirector Les états Nouveau, Ouvert, Corrigé ou Fermé correspondent exactement aux états du champ Etat de StarTeam, mais vous pouvez créer de nombreux autres états qui ne s associent pas au champ Etat dans StarTeam. Nous vous suggérons d utiliser les champs Etat de TestDirector et StarTeam. Le fichier de propriétés initial mappe BG_STATUS avec un champ énumération personnalisé (mappage recommandé). Le champ énumération personnalisé de StarTeam doit avoir les mêmes états que le champ Etat de TestDirector. De même, un champ chaîne TestDirector personnalisé peut être associé à une liste qui correspond aux états du champ Etat de StarTeam. Dans la mesure où TestDirector doit posséder cette paire de champs mappés, vous pouvez mapper le champ Etat de TestDirector avec un champ chaîne StarTeam existant mais inutilisé. Dans TestDirector, les limites de longueur des valeurs énumérées dépendent de la base de données. Par conséquent, pour mapper un champ énumération StarTeam avec le champ Etat dans TestDirector, vous devez modifier le champ affichage StarTeam de sorte que sa longueur soit inférieure ou égale à la longueur maximale du champ TestDirector. Utilisez ensuite les mêmes valeurs pour les champs énumération TestDirector mappés. Step Reference Type : Nombre Valeur : Dépend de la base de données Identificateur interne : BG_STEP_REFERENCE Indique le nombre d étapes d un test. Vous pouvez mapper ce champ avec un champ entier StarTeam personnalisé, le cas échéant. Subject Type : Liste de référence Valeur : Limitée aux choix de la liste Objet, lorsque la vérification est nécessaire. Identificateur interne : BG_SUBJECT Sert généralement à définir la catégorie du produit ou composant dans lequel se trouve le problème. Le champ Catégorie de StarTeam (champ texte) a une fonction similaire. En revanche, la longueur du champ Objet de TestDirector dépend de la base de données, tandis celui de StarTeam peut contenir jusqu à 64 caractères. Si vous mappez ces deux champs, TestDirector doit posséder ce champ pour empêcher la perte de données. Comme un développeur qui travaille dans StarTeam peut ne pas être au courant des choix dans la liste Objet de TestDirector, une approche plus sûre consiste à mapper le champ Objet avec un champ énumération personnalisé. Summary Type : Chaîne Valeur : Jusqu à 70 caractères Identificateur interne : BG_SUMMARY Bref synopsis du problème à résoudre. Ce champ peut être mappé avec le champ Synopsis de StarTeam. En revanche, TestDirector doit posséder le champ Résumé car le champ Synopsis de StarTeam peut être beaucoup plus grand (il s agit d un champ mémo). Si le champ est mis à jour en fonction de son historique, seuls les 70 premiers caractères saisis dans StarTeam sont préservés. Le reste sera tronqué et perdu. 42 Guide de l utilisateur de TestDirector Synchronizer

47 Champs Défaut TestDirector Remarque Test Reference Type : Nombre Valeur : Dépend de la base de données Identificateur interne : BG_TEST_REFERENCE Numéro du test. Vous pouvez mapper ce champ avec un champ entier StarTeam personnalisé, le cas échéant. Test Set Type : Chaîne Valeur : Limitée aux choix de la liste des tests, lorsque la vérification est nécessaire. Identificateur interne : BG_CYCLE_REFERENCE Indique la batterie de tests qui a trouvé ou peut vérifier la correction d un défaut. Vous pouvez mapper ce champ avec un champ texte StarTeam personnalisé. La longueur du champ texte StarTeam personnalisé doit être inférieure ou égale à la longueur maximale du champ Test Set de TestDirector, lequel dépend de la base de données. TestDirector doit posséder ce champ pour que sa valeur proviennent vraiment de la liste Test Set. To Mail Type : Champ chaîne Valeur : O ou N. Ce champ est limité aux choix de la liste Oui Non ; par défaut, la vérification est requise. Identificateur interne : BG_TO_MAIL Indique si les informations sur les modifications apportées à un défaut doivent être transmises aux utilisateurs. Par défaut, ce champ a la valeur O, mais vous pouvez la remplacer manuellement par N (auquel cas les informations ne sont pas envoyées aux utilisateurs). Quand le champ contient un O, les utilisateurs sont avertis des modifications selon les conditions de notification définies pour ces utilisateurs. Vous pouvez mapper ce champ avec un champ énumération StarTeam personnalisé (ou un champ texte StarTeam si ce champ est possédé par TestDirector). Champs définis par l utilisateur (personnalisés) Type : Numéro, chaîne ou date. Valeur : Dépend du type, etc. Identificateur interne : BG_USER_01 à BG_USER_24 Il s agit de champs inutilisés pouvant être définis par les utilisateurs. Synchronizer ne prend pas en charge le mappage des champs personnalisés suivants : BG_USER_HR_01 à BG_USER_HR_06. Chapitre 6 : Champs Défaut TestDirector 43

48 44 Guide de l utilisateur de TestDirector Synchronizer

49 Annexe A AFichier de propriétés initial Annexe de Synchronizer Cette section montre le contenu du fichier BugSync.ini, le fichier de propriétés installé initialement avec Synchronizer. # A sample properties file for StarTeam / TestDirector Change Request Synchronizer ############################################################################# # This block identifies the projects to be synchronized. Each field on the left is # indexed with a number. The corresponding TestDirector (TD) and StarTeam (ST) # numbers will be synchronized. ############################################################################# vts_server1=localhost vts_port1=49201 vts_project1=mercury vts_username1=administrator vts_password1=administrator # If you have more than 1 set of fields ( e.g. vts_view1, vts_view2,.. ) # use the below field to indicate the number the of sets, then you only need # to enter those required fields which are different from the preceeding # ( lower numbered ) set. If you have only 1 set of fields this field is # not required. Leaving off the iteration value is equivalent to commenting it out. # iterations=1 # Name of ST view containing the CRs to be synchronized. # Leave view blank to use the project s root (or default) view vts_view1= # Folder path in ST view where the synchronization should start. # Leave blank to use the view s root folder. If you are using a child of the root Annexe A : Fichier de propriétés initial de Synchronizer 45

50 Fichier de propriétés initial de Synchronizer # folder, use the path to that child folder without the root folder. Use the forward # slash (/) as a separator for any other folder names. For example, if the root # folder of the view is StarDraw and the path to the folder you want to # synchronize is StarDraw/SourceCode/Client, set vts_folder1 to SourceCode/ Client. vts_folder1= # Recurse from the vts_folder through all of its children? vts_recurse_children1=yes # TD database to synchronize with #################################################### # One of the following driver/url combinations need to be selected. # These are not interchangable, if you select the odbc driver you need to # use the odbc url. Likewise if select the oracle jdbc driver you need to # select the oracle jdbc url. # The ODBC driver for use with the Demo database installed with TD, mtd_driver1=sun.jdbc.odbc.jdbcodbcdriver # The jdbc driver to take advantage of CLOB s in oracle #mtd_driver1=oracle.jdbc.driver.oracledriver # This is the ODBC url points to the DSN for the Demo database installed with TD, if you # create your own TD database, you will also have to create a DSN for it # jdbc:odbc:<dsn> where the <dsn> is specified by the ODBC administrator mtd_dataurl1=jdbc:odbc:testdirector_demo # The jdbc url should be specified as one of the following # jdbc:oracle:thin:@<servername>:<port>:<sid> or # jdbc:oracle:oci8@<net alias> #mtd_dataurl1=jdbc:oracle:thin:@localhost:1521:orcl #mtd_dataurl1=jdbc:oracle:oci8:@tdoraserver # Set the desired codepage, if not set the system will default to the System codepage. # The typical windows codepage Windows Latin-1 #mtd_character_encoding1=cp1252 # The codepage for Windows Hebrew #mtd_character_encoding1=cp1255 # With a Microsoft SQL database, mtd_username1 may need to be set to "td", the # default user name that TD assigns to any newly created database. # Then set mtd_password to "tdtdtd", the password used for this database # from TD. mtd_username1=admin mtd_password1= # These parameters are used to connect to TD in order to copy attachments # from TD to StarTeam. Attachment processing is not necessary to synchronize # other fields # If the TestDirector server directory is accessible, then use #the directive below to indicate the directory for those attachments. Replace # the given directory with the directory where the attachments are stored # mtd_attachment_dir1=c:\td_dir\default\demo_db\attach # If the TestDirector server directory is not accessible, then the synchronizer #uses a slower, external method to access the attachments. # The mtd_hostname is the name or IP address of the 46 Guide de l utilisateur de TestDirector Synchronizer

51 Fichier de propriétés initial de Synchronizer # TD Server ( the IIS machine ). The mtd_app_project, mtd_app_username and # mtd_app_password are the parameters used to log into TestDirector. NOTE that # these are different from the database logins specified above, and that these # parameters are only necessary if you wish to copy attachments and your # TestDirector server directory is not accessible mtd_hostname1=localhost #mtd_app_domain1=default mtd_app_project1=testdirector_demo mtd_app_username1=alec mtd_app_password1= # The value of the BG_PROJECT field in TD for the defects to be synchronized. # Commenting out this field will synchronize all defects in the TD Project container with ST. mtd_project1=project 1 ############################################################################# # The next two properties indicate the names of the fields in StarTeam and # TestDirector which hold the synchronization flags. These fields must have # either "Yes" or "No" as the value. If the value is other than "Yes" it will # be treated as "No". ############################################################################# # Name of custom field in ST containing the synchronization flag # This field must be an enumerated field with values "Yes" and "No". vts_send_to_mtd=usr_sync # Name of custom field in TD containing the synchronization flag. # This field must be a string field that is verified with a list that has the # values "Yes" and "No". mtd_send_to_vts=bg_user_02 #This property will ignore HTML tags in the BG_DESCRIPTION and BG_DEV_COMMENTS field. #Note: In a bidirectional mapping(=) html tags cannot be preserved in the where ST overwrites TD. #vts_remove_html=yes # The following property specifies whether the Synchronizer should automatically # create custom fields for TD fields that do not currently exist in ST. # Note: Custom fields in Star Team always prepend Usr_. #vts_create_custom_fields=yes ############################################################################# # The rest of the file below defines the field mapping use for all of the # TD/ST projects defined above. ############################################################################# # Mapping TD defect fields into ST change request (CR) fields # format: map.testdirectordefectfieldname<=>starteamcrfieldname # # < means that ST owns this mapping; ST s value for this field becomes # the value for both fields. # # = means that the history is used to determine the most recent value # and put that value in both fields # NOTE: To use =, the TD field must have history support enabled # # > means that TD owns this mapping; TD s value for this field becomes Annexe A : Fichier de propriétés initial de Synchronizer 47

52 Fichier de propriétés initial de Synchronizer # the value for both fields. # # # Field types must match, especially enumerated fields # # Do not map the following ST fields unless ST owns the field. # If some TD field seems to match one of these fields, # create an ST custom field as a substitute for this ST field # in the mapping. # ChangeNumber, CreatedTime, CreatedUserID, Status, # AddressedIn, LastBuildTested, and other system generated fields # Do not map the following TD fields unless TD owns the field. # If some ST field seems to match one of these fields, # use a TD custom field as a substitute for this TD field # in the mapping. # BG_SUBJECT, BG_PROJECT, BG_BUG_ID # # Mappings you don t want can be commented out or left out # The StarTeam field mapped to the BG_BUG_ID field in TD must be a string # field. The synchronizer will place a value ( such as "TD Bug #: 2") which # indicates the corresponding TD bug. TestDirector must own this mapping. map.bg_bug_id>externalreference # map.bg_status>usr_tdstatus # map.bg_responsible=usr_tdresponsible # map.bg_project>usr_tdproject # map.bg_subject>usr_tdsubject # map.bg_summary>synopsis # NOTE: TD doesn t support history for BG_DESCRIPTION or BG_DEV_COMMENTS. # Therefore, you cannot use = mapping for these fields. # map.bg_description>description # Workaround, Fix and Description are ST memo fields and will be truncated in TD # unless mapped to TD memo fields--either BG_DEV_COMMENTS or # BG_DESCRIPTION. "Fix+Workaround" when owned by ST( "<" ) can be used # to combine these two fields. # map.bg_dev_comments<fix+workaround # map.bg_reproducible>usr_tdreproducible #Multiple mappings are used to map one ST field to many TD fields or map #one TD field to many ST fields. Only mappings in the #one to many ( < or > ) direction will be supported. #map.bg_priority>priority::usr_tdpriority #map.bg_status::bg_user_09::bg_user_10<status # Valuemap fields are used to map ST values to TD values. # Valuemap fields require that a map value exists for that field (see example). # Ownership of the field will be determined from the map operator and the only supported # valuemap operator will be =. In the case of enumerated fields warnings are issued # when the value does not exist. # map.bg_severity>severity 48 Guide de l utilisateur de TestDirector Synchronizer

53 Fichier de propriétés initial de Synchronizer # valuemap.bg_severity.1-low=severity.low # valuemap.bg_severity.2-medium=severity.medium # valuemap.bg_severity.3-high=severity.high # valuemap.bg_severity.("4-very High")=Severity.High # valuemap.bg_severity.5-urgent=severity.high # map.bg_priority<priority # BG_DETECTED_BY must map to a custom field. # Do NOT map to ST s EnteredBy # map.bg_detected_by>usr_tddetectedby # map.bg_test_reference= # map.bg_cycle_reference= # map.bg_run_reference= # map.bg_step_reference= # map.bg_detection_date>usr_tddetectiondate # map.bg_detection_version>usr_tddetectionversion # map.bg_planned_closing_ver= # map.bg_estimated_fix_time= # map.bg_actual_fix_time= # Do NOT map this to the ClosedOn field in ST. It must map to a custom field. # map.bg_closing_date>usr_tdclosingdate # Do NOT map this to the AddressedIn field in ST. It must map to a custom field. # map.bg_closing_version=usr_tdclosingversion # map.bg_to_mail= # map.bg_attachment= # map.bg_user_01<platform # Remember not to use the synchronizing value in TD ( in this case BG_USER_02) for something else! # map.bg_user_03<changenumber # map.bg_user_04<status # map.bg_user_05<type # map.bg_user_06<addressedin # map.bg_user_07<lastbuildtested # map.bg_user_08<responsibility # map.bg_user_09= # map.bg_user_10= # map.bg_user_11= # map.bg_user_12= # map.bg_user_13= # map.bg_user_14= # map.bg_user_15= # map.bg_user_16= # map.bg_user_17= # map.bg_user_18= # map.bg_user_19= # map.bg_user_20= # map.bg_user_21= # map.bg_user_22= # map.bg_user_23= # map.bg_user_24= Annexe A : Fichier de propriétés initial de Synchronizer 49

54 Fichier de propriétés initial de Synchronizer # The Synchronizer does not support any mapping of the following fields: # map.bg_user_hr_01 # map.bg_user_hr_02 # map.bg_user_hr_03 # map.bg_user_hr_04 # map.bg_user_hr_05 # map.bg_user_hr_06= 50 Guide de l utilisateur de TestDirector Synchronizer

55 Annexe B BFichiers batch initiaux Annexe de Synchronizer run.bat (Windows off echo This process may take some time, please wait... REM - The path to StarTeam Installations should be verified. SET STARTEAM_PATH=C:\Program Files\Borland REM - The path to StarTeam SDK Installation should be verified. SET STARTEAM_SDK_PATH=%STARTEAM_PATH%\StarTeam SDK xx\ REM - The path to StarTeam SDK library should be verified. SET SDK_JAR=%STARTEAM_SDK_PATH%\Lib\StarTeamxx.jar REM - The path to Oracle client installation should be verified. SET ORACLE_PATH=C:\oracle\ora92\ REM - The path to Oracle JDBC library should be verified. SET ORACLE_CLASSPATH=%ORACLE_PATH%\jdbc\lib\classes12.zip REM - The java lib path should be verified. SET _JAVA_LIB_PATH=%STARTEAM_SDK_PATH%\Lib;%ORACLE_PATH%\bin; REM - The path to the StarTeam SDK installed Java Runtime Environment should be verified. SET JAVA="%STARTEAM_PATH%\Java\Sun1.4.2_01\bin\java.exe" SET _CLASSPATH=mtdsync.jar;spslib.jar;%SDK_JAR%;%ORACLE_CLASSPATH% REM - Call the synchronizer %JAVA% -Djava.library.path="%_JAVA_LIB_PATH%" -classpath "%_CLASSPATH%" com.starbase.mtdsync.app BugSync.ini Annexe B : Fichiers batch initiaux de Synchronizer 51

56 run-again.bat (Windows server) REM - The syntax below shows how to set the debug flag to generate a more detailed mtdsync.log file REM %JAVA% -Djava.library.path="%_JAVA_LIB_PATH%" -classpath "%_CLASSPATH%" com.starbase.mtdsync.app BugSync.ini debug REM - If you want to have the mtdsync.log and mtdsync.err files generated in a directory other than the REM - current directory use the log <dir> option: REM %JAVA% -Djava.library.path="%_JAVA_LIB_PATH%" -classpath "%_CLASSPATH%" com.starbase.mtdsync.app BugSync.ini log "c:\inetpub\wwwroot\tdlogs" if errorlevel 1 goto Failed goto Done :Failed echo. Errors occurred. Check mtdsync.log and/or mtdsync.err for further information. goto Bye :Done echo Done. Check mtdsync.log for further information. :Bye run-again.bat (Windows off REM - modified run.bat file to wait some number of seconds between synchronize calls REM- edit the parameter to wait.exe at the bottom of this file REM- type ^C to exit the batch file echo This process may take some time, please wait... REM - The path to StarTeam Installation should be verified. SET STARTEAM_PATH=C:\Program Files\Borland REM - The path to StarTeam SDK Installation should be verified. SET STARTEAM_SDK_PATH=%STARTEAM_PATH%\StarTeam SDK xx\ REM - The path to StarTeam SDK library should be verified. SET SDK_JAR=%STARTEAM_SDK_PATH%\Lib\StarTeamxx.jar REM - The path to Oracle client installation should be verified. SET ORACLE_PATH=C:\oracle\ora92\ REM - The path to Oracle JDBC library should be verified. SET ORACLE_CLASSPATH=%ORACLE_PATH%\jdbc\lib\classes12.zip REM - The java lib path should be verified. SET _JAVA_LIB_PATH=%STARTEAM_SDK_PATH%\Lib;%ORACLE_PATH%\bin; REM - The path to the StarTeam SDK installed Java Runtime Environment should be verified. SET JAVA="%STARTEAM_PATH%\Java\Sun1.4.2_01\bin\java.exe" SET _CLASSPATH=mtdsync.jar;spslib.jar;%SDK_JAR%;%ORACLE_CLASSPATH% :again 52 Guide de l utilisateur de TestDirector Synchronizer

57 run-again.bat (Windows server) REM - Call the synchronizer %JAVA% -Djava.library.path="%_JAVA_LIB_PATH%" -classpath "%_CLASSPATH%" com.starbase.mtdsync.app BugSync.ini REM - The syntax below shows how to set the debug flag to generate a more detailed mtdsync.log file REM %JAVA% -Djava.library.path="%_JAVA_LIB_PATH%" -classpath "%_CLASSPATH%" com.starbase.mtdsync.app BugSync.ini debug REM - If you want to have the mtdsync.log and mtdsync.err files generated in a directory other than the REM - current directory use the log <dir> option: REM %JAVA% -Djava.library.path="%_JAVA_LIB_PATH%" -classpath "%_CLASSPATH%" com.starbase.mtdsync.app BugSync.ini log "c:\inetpub\wwwroot\tdlogs" if errorlevel 1 goto Failed if exist mtdsync.err goto Failed goto Done :Failed type mtdsync.log >> all.log type mtdsync.err >> all.err echo. Errors occurred. Check mtdsync.log and/or mtdsync.err for further information. goto Bye :Done echo Done. Check mtdsync.log for further information. :Bye REM - The parameter to wait is the number of seconds. wait 600 goto again Annexe B : Fichiers batch initiaux de Synchronizer 53

58 54 Guide de l utilisateur de TestDirector Synchronizer

59 Annexe C Configuration requise pour Synchronizer Autres conditions CConfiguration système Annexe Synchronizer a été testé sous Windows 2000 et Windows 2003 (version 32 bits). Aucune configuration particulière n est requise. Vous devez avoir les logiciels suivants : L édition Entreprise ou Entreprise Advantage du client StarTeam L édition Entreprise ou Entreprise Advantage du serveur StarTeam Windows ou StarTeam for Solaris TestDirector 7.6 ou 8.0, Quality Center 8.2 for Windows ou Quality Center 8.2 for Solaris. Un environnement d exécution Java (JRE), version 1.4.1_02 ou ultérieure, ou la machine virtuelle Java Microsoft Ces logiciels ne doivent pas obligatoirement se trouver sur la même machine que TestDirector Synchronizer, qui peut, si vous le souhaitez, être installé sur une machine différente. Cependant, TestDirector Synchronizer doit disposer d un accès réseau à la base de données TestDirector et au serveur StarTeam. Si vous utilisez Microsoft SQL : Pour Synchronizer, toutes les tables doivent appartenir au même propriétaire (le dbo) et non à TestDirector ; vous devez par conséquent exécuter le script Microsoft SQL set-owner-to-dbo.sql dans l Analyseur de requêtes SQL Server. Vérifiez que l utilisateur identifié dans le pilote ODBC et dans le fichier de propriétés de Synchronizer est autorisé à mettre à jour les tables de la base de données. Annexe C : Configuration système 55

60 56 Guide de l utilisateur de TestDirector Synchronizer

61 Index A Actual Fix Time champ TestDirector 37 Assigned To champ TestDirector 37 Attachment champ TestDirector 38 B BG_ACTUAL_FIX_TIME champ TestDirector 37 BG_ATTACHMENT champ TestDirector 38 BG_BUG_ID champ TestDirector 38 BG_CLOSING_DATE champ TestDirector 38 BG_CLOSING_VERSION champ TestDirector 38 BG_CYCLE_REFERENCE champ TestDirector 43 BG_DESCRIPTION champ TestDirector 39 BG_DETECTED_BY champ TestDirector 39 BG_DETECTION_DATE champ TestDirector 39 BG_DETECTION_VERSION champ TestDirector 39 BG_DEV_COMMENTS champ TestDirector 40 BG_ESTIMATED_TIME_FIX champ TestDirector 39 BG_PLANNED_CLOSING_VER champ TestDirector 40 BG_PRIORITY champ TestDirector 40 BG_PROJECT champ TestDirector 40 BG_REPRODUCIBLE champ TestDirector 41 BG_RESPONSIBLE champ TestDirector 37 BG_RUN_REFERENCE champ TestDirector 41 BG_SEVERITY champ TestDirector 41 BG_STATUS champ TestDirector 41 BG_STEP_REFERENCE champ TestDirector 42 BG_SUBJECT champ TestDirector 42 BG_SUMMARY champ TestDirector 42 BG_TEST_REFERENCE champ TestDirector 43 BG_TO_MAIL champ TestDirector 43 BG_USER_HR_xx champ TestDirector 43 BG_USER_xx champ TestDirector 43 C Category champ StarTeam 25 chaînes dans TestDirector 6 champs mappage 17 réduction 8 StarTeam 23 TestDirector 37 vide 9 Champs définis par l utilisateur (personnalisés) TestDirector 43 champs personnalisés, création 6 champs vides 9 ChangeNumber champ StarTeam 27 Chemin du dossier champ StarTeam 30 Closed in Version champ TestDirector 38 Closing Date champ TestDirector 38 Commande de test champ StarTeam 35 Commentaire champ StarTeam 26 Commentaire bref champ StarTeam 34 Commentaire de la nouvelle révision champ StarTeam 31 Composant champ StarTeam 26 configuration de StarTeam pour l utiliser avec TestDirector Synchronizer 4 configuration de TestDirector pour l utiliser avec StarTeam 4 configuration système 55 convention de l utilisation de l espacement fixe 2 convention de l utilisation des barres verticales 2 convention de l utilisation des crochets 2 convention de l utilisation des italiques 2 convention de l utilisation du gras 2 convention des sélections de menus 2 conventions barres verticales 2 crochets 2 gras 2 italique 2 sélections des menus 2 type, espacement fixe 2 copie de pièces jointes entre TestDirector et StarTeam 16 Corriger champ StarTeam 29 CreatedUserID champ StarTeam 27 création de champs personnalisés 6 Créé par champ StarTeam 27 Index 57

62 Créer branche si modification champ StarTeam 24 D dates dans StarTeam 7 dates dans TestDirector 6 Defect ID champ TestDirector 38 DeletedUserID champ StarTeam 27 dépannage 7 Dernière version testée champ StarTeam 30 Description champ StarTeam 28 champ TestDirector 38 Description des champs TestDirector 37 Detected By champ TestDirector 39 Detected on Date champ TestDirector 39 directives de mappage 17 directives, présentation 11 Dossier champ StarTeam 30 E entiers dans StarTeam 7 Entrée le champ StarTeam 29 Entrée par champ StarTeam 28 énumérations dans StarTeam 7 mappage avec des champs texte 9 Estimated Fix Time champ TestDirector 39 Etat champ StarTeam 35 Etat A lire champ StarTeam 33 Etat de la branche champ StarTeam 25 Etat de partage champ StarTeam 34 F fichiers.ini 17 fichier de propriétés 17 propriétés 11 fichiers.ini 17 fichiers batch 21 fichiers de propriétés champs de mappage 17 compréhension 11 exemple 45 identification des valeurs StarTeam 13 Identification des valeurs TestDirector 14 mise à jour à partir de versions antérieures 20 G Gravité champ StarTeam 34 H Heure de configuration champ StarTeam 26 Heure de création champ StarTeam 27 Heure de fin de modification champ StarTeam 28 Heure de modification champ StarTeam 31 Heure de suppression champ StarTeam 27 heures dans StarTeam 7 historique, utilisé pour les synchronisations bidirectionnelles 18 I ID champ StarTeam 31 ID commentaire champ StarTeam 26 ID de pièces jointes champ StarTeam 24 ID notation par points champ StarTeam 28 ID objet champ StarTeam 31 ID objet racine champ StarTeam 34 ID parent champ StarTeam 31 ID utilisateur dans StarTeam 7 identification valeurs StarTeam 13 valeurs TestDirector 14 Indicateur champ StarTeam 29 indicateurs 7 Indicateurs de révision champ StarTeam 33 indicateurs de synchronisation 7 installation de TestDirector Synchronizer 3 iterations directive du fichier de propriétés 13 L Lecture seule champ StarTeam 32 limites associées au mappage 18 Liste des utilisateurs avec état A lire champ StarTeam 33 listes d utilisateurs dans TestDirector 6 listes de référence dans TestDirector 6 M mappage champs 17 exigences 18 limitations 18 recommandations 18 restrictions 19 mappages limités 19 mappages obligatoires Guide de l utilisateur de TestDirector Synchronizer

63 mappages recommandés 18 mappages, obligatoires 18 Marquer liste utilisateur champ StarTeam 30 modification du fichier run.bat 21 Modifié par champ StarTeam 30 ModifiedUserID champ StarTeam 30 mtd_database(n) directive du fichier de propriétés 16 mtd_dataurl(n) directive du fichier de propriétés 15 mtd_driver(n) directive du fichier de propriétés 15 mtd_hostname(n) directive du fichier de propriétés 16 mtd_password(n) directive du fichier de propriétés 15 mtd_project(n) directive du fichier de propriétés 15 mtd_send_to_vts directive du fichier de propriétés 15 mtd_username(n) directive du fichier de propriétés 15 N N de demande de modification champ StarTeam 27 Nombre de pièces jointes champ StarTeam 24 nombres réels dans StarTeam 7 nombres, types TestDirector nombres TestDirector 6 Noms des pièces jointes champ StarTeam 24 Notation par points champ StarTeam 28 numéros dans StarTeam 7 P Palliatif champ StarTeam 36 ParentObjectID champ StarTeam 31 ParentRevision champ StarTeam 31 PathRevision champ StarTeam 32 personnalisation champs TestDirector 6 pièces jointes, directives de copie entre TestDirector et StarTeam 16 Planned Closing Version champ TestDirector 40 Plate-forme champ StarTeam 32 présentation 3 Priorité champ StarTeam 32 Priority champ TestDirector 40 Project champ TestDirector 40 propriété, déterminée par les directives de mappage 17 R R & D Comments champ TestDirector 40 réduction champs 8 Référence externe champ StarTeam 29 Reproducible champ TestDirector 41 Résolue le champ StarTeam 33 Responsabilité champ StarTeam 33 Révision de branche mère champ StarTeam 31 Révision mère champ StarTeam 32 RevisionNumber champ StarTeam 36 Run Reference champ TestDirector 41 run.bat 21 S Severity champ TestDirector 41 StarTeam champs 23 identifiées dans le fichier de propriétés 13 Status champ TestDirector 41 Step Reference champ TestDirector 42 Subject champ TestDirector 42 Summary champ TestDirector 42 support 1 support technique 1 support, développeurs 1 support, produits 1 Supprimé par champ StarTeam 27 Synopsis champ StarTeam 35 T Terminé le champ StarTeam 25 Test Reference champ TestDirector 43 Test Set champ TestDirector 43 TestDirector champs 37 identifiées dans le fichier de propriétés 14 texte dans StarTeam 7 To Mail champ TestDirector 43 Index 59

64 Traitée dans champ StarTeam 23 Traitée dans la vue champ StarTeam 24 Traitée par champ StarTeam 23 Type champ StarTeam 35 types chaînes TestDirector 6 dates StarTeam 7 dates TestDirector 6 entiers StarTeam 7 énumérations StarTeam 7 heures StarTeam 7 ID utilisateur StarTeam 7 listes d utilisateurs TestDirector 6 listes de référence TestDirector 6 nombres réels StarTeam 7 nombres StarTeam 7 texte StarTeam 7 V Vérifiée le champ StarTeam 35 Version champ StarTeam 36 ViewID champ StarTeam 36 vts_create_custom_fields directive du fichier de propriétés 14 vts_folder(n) directive du fichier de propriétés 14 vts_password(n) directive du fichier de propriétés 13 vts_port(n) directive du fichier de propriétés 13 vts_project(n) directive du fichier de propriétés 13 vts_recurse_children(n) directive du fichier de propriétés 14 vts_send_to_mtd directive du fichier de propriétés 14 vts_server(n) directive du fichier de propriétés 13 vts_username(n) directive du fichier de propriétés 13 vts_view(n) directive du fichier de propriétés 13 Vue champ StarTeam 36 vues, en lecture seule 9 60 Guide de l utilisateur de TestDirector Synchronizer