Pratiques exemplaires de gestion des types TestStand

TestStand utilise différentes catégories de types pour stocker des informations et définir le comportement des pas.  Les types de données stockent des informations pendant le développement et l’exécution d’un système de test, et les types de pas de test définissent le comportement d’un pas et les résultats que le pas recueille pendant l’exécution.  Les types de données et les types de pas de test peuvent être intégrés et livrés avec TestStand, ou ils peuvent être des types personnalisés que l’utilisateur développe.

Les types TestStand sont classés en types de pas de test, types de données personnalisés et types de données standard.

Types de données

Dans de nombreux cas, vous devrez définir des structures de données complexes pour gérer vos données de test.  Les types de données vous permettent de gérer ces structures de données dans un emplacement centralisé.  Les types de données définissent la structure des propriétés ou des variables TestStand, telles que les variables globales de fichier de séquence, les variables locales de séquence et les propriétés de pas.  Tous les types de données ont les composants suivants :

• Nom du type : utilisé pour indiquer le type de manière unique.  TestStand ne peut jamais charger plus d’un type du même nom en mémoire.
• Version : utilisé pour gérer les révisions des types et résoudre les conflits de types.
• Données : la structure des propriétés définies dans le type
• Valeurs par défaut : les valeurs de propriété que vous définissez dans le volet des types agissent comme des valeurs par défaut pour les instances du type.

En règle générale, vous utilisez des types de données pendant la définition d’un ensemble de données complexes associées, qui contient plusieurs propriétés et conteneurs différents.  Par exemple, un type de données d’erreur peut être composé de trois propriétés : une propriété booléenne dans le type pouvant préciser si une erreur s’est produite, une propriété de valeur de chaîne pouvant contenir le message d’erreur et une propriété entière pouvant définir le code d’erreur.

Vous devez toujours utiliser un type de données pendant la gestion de données complexes, car si vous modifiez la structure d’un type de données, toutes les instances de ce type de données sont mises à jour pour refléter la nouvelle structure de type de données.  Cette façon de faire vous permet de gérer la structure de vos données dans un emplacement centralisé.  

Types de données standard

Les types de données standard sont un ensemble particulier de types de données fournis avec TestStand et qui définissent un format standard pour stocker des types de données courants, tels que l’erreur, le chemin ou le waveform.  Vous ne pouvez pas modifier la plupart des types de données standard. Bien que certains puissent être modifiés, vous ne devez le faire qu’au besoin, car ces types sont largement utilisés par d’autres composants TestStand.  

Types de pas de test

Tout comme vous pouvez créer une variable ou une propriété à partir d’un type de données personnalisé, vous créez une étape à partir d’un type de pas de test.  Chaque type de pas de test comprend un nom unique, des propriétés de type de pas de test intégrées et personnalisées et des valeurs par défaut pour les propriétés et les opérations de type de pas de test.  Tous les types de pas de test partagent un ensemble commun de propriétés qui définissent l’opération de base et les données pour tous les pas.  Utilisez la boîte de dialogue Propriétés du type de pas de test (Step Type Properties) pour modifier ces propriétés communes.

Ce document porte d’abord et avant tout sur les concepts qui s’appliquent à tous les types, y compris les types de pas de test et de données.  Pour plus d’informations particulières sur les pratiques exemplaires de type de pas de test, reportez-vous au document Pratiques exemplaires pour le développement de types de pas de test personnalisés.

Lorsque vous créez de nouveaux types, il est important de prendre en compte l’emplacement sur le disque où le type est stocké. TestStand peut stocker des types dans des fichiers de séquence ou dans des fichiers palette de types.  Dans la plupart des cas, vous devez stocker tous les types que vous créez dans un fichier palette de types. L’utilisation d’une palette de types offre les avantages suivants :

• Les fichiers palette de types fournissent un emplacement centralisé pour stocker les types dans plusieurs fichiers de séquence.
• Les fichiers palette de types peuvent être configurés pour être chargés en mémoire lorsque vous lancez TestStand, garantissant que les types sont disponibles pour tout nouveau fichier de séquence.
• Le fait de disposer d’un emplacement centralisé unique pour les types permet d’éviter les conflits de types, qui peuvent survenir lorsque plusieurs développeurs apportent des modifications aux types stockés dans plusieurs emplacements.
• Par défaut, TestStand ne met pas automatiquement à jour les types dans une palette de types, offrant une protection contre la propagation de type indésirable.

Lorsque vous utilisez un type d’un fichier palette de types dans un fichier de séquence, une copie du type est stockée dans le fichier pour garantir qu’il fonctionnera même sans le fichier palette de types. Cependant, vous ne devez apporter des modifications au type qu’à l’aide de la version de la palette de types.  Lorsque vous déployez votre séquence de test, vous n’avez pas besoin d’inclure des fichiers palette de types dans le déploiement.  Cependant, l’inclusion du fichier palette de types vous permettra d’effectuer plus facilement des mises à jour incrémentielles du système de test.  Si des mises à jour sont nécessaires pour des types particuliers, vous pouvez créer et déployer une nouvelle version du fichier palette de types, sans apporter de modifications aux fichiers de séquence.

Durant le partage de types entre plusieurs développeurs, il est important de s’assurer que chaque développeur utilise la même version la plus récente de la définition de type. Vous devez également vous assurer que les développeurs n’apportent pas de modifications distinctes au même type, car il est difficile de fusionner des modifications de types.  Utilisez les techniques suivantes pour gérer efficacement les types partagés :

• Définir un propriétaire pour les fichiers palette de types
• Utiliser le contrôle du code source pour les palettes de types

Définition de la propriété des fichiers palette de types

Pour contrôler les modifications apportées aux types, il est important d’établir un propriétaire clair pour chaque type, qui implémente ou approuve les modifications apportées aux types.  Dans une grande organisation, il est souvent judicieux d’attribuer la propriété du type à différents individus du groupe.  Pour faciliter cette approche, créez des fichiers palette de types distincts pour organiser les types en groupes logiques ; par exemple, vous pouvez stocker des types spécifiques au projet dans une palette de types contenant le nom du projet et vous pouvez enregistrer des types plus généraux que vous utilisez dans plusieurs projets dans un fichier palette de types partagé.  Ensuite, il est possible de déterminer un propriétaire pour chaque fichier palette de types.

L’organisation des fichiers palette de types en groupes logiques vous permet d’attribuer plus facilement des propriétaires de types à chaque fichier de palette de types.

Utilisation du contrôle du code source pour restreindre les modifications des fichiers palette de types

Pour contrôler davantage les modifications apportées aux versions de type, utilisez une solution de contrôle de code source pour vous assurer que les fichiers ne peuvent être modifiés que s’ils sont extraits.  Vous pouvez utiliser les autorisations de contrôle de code source pour vous assurer que seul le propriétaire d’un fichier palette de types particulier a la possibilité d’archiver les modifications.  Au minimum, le propriétaire de la palette de types doit activer les notifications pour les fichiers, afin qu’il soit au courant de toute activité relative au fichier.

Bien que les utilisateurs aient toujours la possibilité de modifier les types sur leur ordinateur local, l’utilisation du contrôle de code source empêche TestStand d’enregistrer ces modifications sur le disque ou dans la version partagée du fichier.  

Prévention des conflits entre les types non liés

Les conflits de types peuvent se produire lorsque plusieurs types non liés portent le même nom par inadvertance. Étant donné que les types utilisent leur nom comme identificateur unique sur le système, lorsque vous développez de nouveaux types, ajoutez un numéro d’identification d’organisation unique au nom du type.  Par exemple, tous les noms des types de pas de test livrés avec TestStand commencent par le préfixe « NI ».  De cette façon, vos types n’entrent pas en conflit avec les types créés en dehors de votre organisation si le code est partagé entre des groupes.

TestStand charge une seule version d’un type avec un nom particulier à la fois pour s’assurer que les mêmes informations de type sont utilisées pour tous les fichiers chargés sur la station.  Si vous essayez d’ouvrir un fichier de séquence ou de charger une palette de types qui contient un type avec le même nom que celui qui est déjà chargé, un conflit de type se produit, où TestStand doit déterminer s’il faut garder le type actuel chargé ou le remplacer par le nouveau type.  

Un conflit de type se produit lorsque vous essayez de charger un fichier contenant une définition de type différente de celle actuellement chargée dans TestStand.  Le conflit doit être résolu avant que le nouveau fichier puisse être chargé.

Si les développeurs veillent à conserver des noms de type uniques ainsi que les types dans un seul fichier palette de types contrôlés, TestStand sera en mesure de gérer correctement les conflits de types.  Cependant, les conflits de type peuvent entraîner des modifications incorrectes de vos fichiers en fonction des règles de résolution automatique des conflits de type ou des décisions incorrectes des développeurs, ce qui peut entraîner une propagation de version de type indésirable.  

Propagation de version de type indésirable

La propagation de type indésirable décrit le cas où la résolution d’un conflit de type entraîne des modifications indésirables des fichiers contenant une version différente d’un type. Lorsque des fichiers de type incorrect sont partagés, d’autres développeurs peuvent charger la mauvaise version du type sans le savoir.  Ainsi le nouveau type se propage à de multiples fichiers au fur et à mesure que ceux-ci sont partagés avec un plus grand nombre de développeurs. Il devient donc difficile de trouver les fichiers comportant le type erroné.
Cette situation peut se produire pendant la résolution de conflits survenant dans les situations suivantes :

• Chargement d’un type dans une version précédente de TestStand dans laquelle le type est incompatible
• Création de plusieurs types non liés portant le même nom
• Plusieurs développeurs apportant des modifications parallèles à un type

Utilisez les techniques de cette section pour minimiser les cas où les conflits de type ne sont pas traités correctement et pour empêcher la propagation de version de type indésirable.

Maintien du champ de version de type

Les types TestStand utilisent le champ version pour déterminer la version d’un type la plus récente.  Si la version la plus récente du type est chargée en mémoire et que vous chargez un fichier de séquence qui utilise une ancienne version du type, TestStand peut automatiquement mettre à jour le fichier pour utiliser la version de type plus récente, en fonction des paramètres de la station.  Par défaut, TestStand résout automatiquement tous les conflits qui ne mettent pas à jour les types dans les fichiers palette de types.

Pour vous assurer que les versions de type sont mises à jour, TestStand suit les types que vous modifiez à l’aide de l’indicateur de type modifié.  Si vous enregistrez un type avec cet indicateur activé, TestStand affiche un avertissement indiquant que des modifications ont été apportées.  

TestStand fournit un avertissement lorsque vous apportez des modifications aux types pour vous assurer que les modifications sont prévues avant de les enregistrer.

Vous devez choisir d’incrémenter les versions de type dans ce cas, ce qui garantira que les modifications que vous apportez sont propagées à d’autres fichiers qui référencent le type pendant leur chargement dans TestStand.  Cependant, vous ne devez pas sélectionner l’option pour enregistrer les paramètres et ne pas demander, car cet avertissement est un outil utile pour empêcher les modifications indésirables des types.  Si vous doutez de la modification, l’annulation de la boîte de dialogue annulera l’opération d’enregistrement, vous permettant d’inspecter le type et de vous assurer que les modifications sont valides.

Configuration de la résolution automatique des conflits de types

Dans certains cas, TestStand peut déterminer automatiquement quel type doit être chargé en cas de conflit de type.  La résolution automatique des conflits de type n’est possible que lorsque ces conditions sont remplies :

• Les versions de type ne sont pas les mêmes pour les deux types
• Le marqueur « modifié » n’est défini pour aucun type.

TestStand fournit le paramètre Autoriser la résolution automatique des conflits de types (Allow Automatic Type Conflict Resolution) pour vous permettre de déterminer quand TestStand résoudra ces conflits automatiquement.  Pour accéder à ce paramètre :

1. Dans l’éditeur de séquence, sélectionnez Configurer » Options de la station (Configure » Station Options).
2. Sélectionnez l’onglet Fichier (File).

TestStand vous permet de configurer le moment où les conflits de type sont traités automatiquement et lorsque le développeur est invité à choisir la version de type à conserver en mémoire.

Dans la plupart des cas, vous devez utiliser la valeur par défaut de ce paramètre, qui consiste uniquement à demander si un fichier palette de types sera modifié.  Ce paramètre permettra à TestStand de choisir automatiquement le type avec la version supérieure, tant que le type de version inférieure n’est pas stocké dans un fichier palette de types.  Ce paramètre permet de garantir que le message de conflit de type apparaît uniquement en cas de risque de propagation de type indésirable.  Cette disposition garantie que les conflits inoffensifs, tels que le chargement d’un ancien fichier de séquence avec des types NI plus anciens dans une nouvelle version de TestStand, sont résolus automatiquement et qu’ils ne nécessitent pas que l’utilisateur prenne une décision.

Par exemple, le développeur A met à jour le type de pas de test « RunCalibration », un type stocké dans le fichier palette de types de société, Company_types.ini.  Après en avoir discuté avec le propriétaire du fichier palette de types, ils enregistrent la modification du type et choisissent d’incrémenter la version du type à 1.0.1.0.  Ils enregistrent ensuite la palette de types mise à jour dans le référentiel de contrôle du code source.  Un autre développeur B se synchronise plus tard avec le référentiel, obtenant la version de Company_types.ini avec le type mis à jour.  Il ouvre ensuite TestStand et charge un fichier de séquence qui fait référence au type.  Puisque le fichier de séquence fait toujours référence à la version de type précédente, la référence dans le fichier de séquence est mise à jour automatiquement, ce qui est le comportement souhaité.

Cependant, un troisième développeur C a également un fichier de séquence qui utilise le pas « RunCalibration », et il apporte par inadvertance une modification distincte au type de pas de test « RunCalibration » sans consulter le propriétaire du type, mettant à jour son instance locale vers la version 1.1.0.0.  Si ce développeur synchronise le fichier palette de type de société, puis charge son fichier de séquence dans TestStand, TestStand lui demandera de résoudre le conflit de type, car le type sera modifié si la version la plus récente est utilisée.  Le développeur C saura que le fichier palette de types a été mis à jour et consultera le propriétaire de la palette de types ou annulera les modifications locales qu’il a apportées au type.

Si TestStand ne peut pas résoudre automatiquement le conflit de type, vous serez invité à décider la manière de résoudre le conflit :

Utilisez la boîte de dialogue Conflit de types dans le fichier (Type Conflict In File) pour résoudre les conflits de type qui ne peuvent pas être résolus automatiquement.

Pour résoudre le conflit de types, vous pouvez choisir de charger l’un des deux types, renommer l’un des types ou annuler l’ouverture du fichier.  Lorsque vous sélectionnez la version à utiliser, TestStand convertit toutes les instances en mémoire pour qu’elles correspondent au type que vous avez sélectionné. Si vous renommez l’un des types, TestStand modifie les instances en mémoire pour faire référence au type chargé et les instances du nouveau fichier pour faire référence au type dans le fichier.

Paramètres de résolution de conflit spécifiques au type

Dans un environnement étroitement contrôlé, vous pouvez être tenté de sélectionner l’option Toujours demander à l’utilisateur de résoudre le conflit (Always prompt the user to resolve the conflict) pour désactiver la résolution automatique des conflits de type dans tous les cas. Ce processus invitera l’utilisateur à résoudre le conflit dans tous les cas où un conflit de type est détecté, vous permettant d’avoir un contrôle total sur les types chargés.  Cependant, il faudra faire des choix supplémentaires pendant le processus de développement, car les développeurs pourraient prendre des décisions incorrectes et à rejeter rapidement les nombreuses boîtes de dialogue qu’ils rencontreront.  

L’approche idéale consiste à utiliser le paramètre spécifique au type pour les types qui nécessitent un contrôle strict.  Situé dans l’onglet Version des paramètres Type, vous pouvez spécifier si le type peut être résolu automatiquement.  L’utilisation de ce paramètre empêche toute interaction utilisateur inutile pour les conflits de types à faible risque, comme le chargement d’un ancien fichier de séquence avec des types NI plus anciens dans une nouvelle version de TestStand, tout en offrant un contrôle total sur les types personnalisés étroitement contrôlés.

Désactiver la résolution automatique des conflits de types pour des types spécifiques qui nécessitent un contrôle plus strict.

Non propagation de version de type indésirable vers les versions précédentes de TestStand

Comme vous pouvez enregistrer des fichiers de séquence dans des versions précédentes de TestStand, mais que certains types peuvent ne pas s’exécuter correctement sur les versions précédentes de TestStand, vous pouvez spécifier la version la plus ancienne de TestStand qui peut exécuter un type. Activez l’option Définir la version la plus ancienne de TestStand pouvant utiliser ce type (Set Earliest TestStand Version that can Use this Type) dans l’onglet Version de la boîte de dialogue Propriétés du type (Type Properties) et définissez la version la plus ancienne sur la version actuelle de TestStand. Cette procédure empêchera la version actuelle d’un type d’être utilisée ou propagée accidentellement vers une version TestStand antérieure.

Si un type doit être disponible dans les versions précédentes de TestStand, créez différentes versions du type à exécuter dans différentes versions de TestStand. Lorsque vous enregistrez une séquence pour une version précédente de TestStand, TestStand recherche un ensemble de répertoires de compatibilité pour trouver la version de type compatible avec la version précédente pour laquelle vous souhaitez enregistrer le fichier de séquence. TestStand enregistre les types des fichiers palette de types dans les répertoires <TestStand Public>\Components\Compatibility\<version number> et <TestStand Public>\Components\Compatibility\<version number> avec le fichier de séquence. Vous pouvez placer les fichiers palette de types des versions antérieures de TestStand dans le répertoire <TestStand Public>\Components\Compatibility\<version number> pour vous assurer que TestStand enregistre la bonne version des types avec le fichier de séquence.

Les développeurs doivent être prudents pendant la personnalisation des types de données intégrés, y compris les types de données standard et les types de données de modèle de processus.  De nombreux types intégrés, tels que CommonResults, sont largement utilisés par d’autres types de pas de test ou types de données TestStand, ce qui augmente le potentiel de propagation de type indésirable.

Considérations relatives à la personnalisation des types de données standard

Ne personnalisez pas les types intégrés si vous créez des fichiers de séquence ou des fichiers palette de types qui seront distribués en tant que produits tiers ou seront utilisés dans plusieurs organisations. Les fichiers avec des types intégrés modifiés doivent rester dans une seule organisation qui est informée des changements de type.  Si vos fichiers de séquence ou vos palettes de types sont distribués, d’autres organisations hériteront de vos personnalisations de types ou rencontreront des conflits si la version de ces types de l’autre organisation est chargée dans vos fichiers.  

Étant donné qu’une modification apportée aux types intégrés a une telle incidence sur toute station de test où ils sont utilisés, affectez un développeur ou un architecte central qui comprend l’architecture de test des organisations pour approuver les modifications afin de réduire les problèmes de gestion des types.

Considérations relatives à la personnalisation des types de données de modèle de processus

Les modèles de processus et les séquences de plug-in TestStand utilisent une variété de types de données pour définir des structures de données de modèles de processus.  Par exemple, le type de données UUT contient des données telles que le numéro de série, le numéro de pièce et l’indice de l’interface de connexion de test.  Bien que vous puissiez personnaliser ces types, vous ne devez le faire qu’au besoin.  Les types de modèles de processus sont définis uniquement dans des fichiers de séquence et n’ont pas de palette de types centrale.  Pour cette raison, une propagation de type indésirable peut se produire plus facilement pour ces types, car les paramètres de résolution automatique des conflits par défaut permettront à TestStand de mettre à jour ces types automatiquement.
Si vous devez ajouter des données supplémentaires aux types de données UUT ou NI_StationInfo, vous pouvez utiliser la propriété AdditionalData, qui est un conteneur non structuré défini dans le type, pour ajouter des données supplémentaires aux instances du type au moment de l’exécution.  Pour plus d’informations sur cette approche, reportez-vous à la rubrique d’aide Stockage d’informations supplémentaires pour les UUT et les stations de test dans les modèles de processus.

Cliquez ici pour accéder à d’autres ressources de la série d’architecture avancée TestStand, qui traite de sujets d’intérêt pour les développeurs avancés en NI TestStand.