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