Pratiques exemplaires de développement de types de pas de test personnalisés TestStand

Avant de commencer à concevoir un type de pas de test personnalisé, vous devez envisager d’autres approches qui peuvent être mieux adaptées aux nouvelles fonctionnalités.  

La création ou la modification d’un type de pas de test personnalisé n’est pas recommandée dans les cas suivants :

• La nouvelle fonctionnalité affecte tous ou plusieurs types de pas de test.  Dans ce cas, envisagez d’utiliser un rappel Moteur, qui s’exécute avant ou après chaque pas.
• Vous souhaitez fournir une configuration de base d’un pas existant, mais aucune nouvelle fonctionnalité ou propriété n’est requise.  Dans ce cas, créez un modèle de pas contenant les modifications apportées au pas.
• Vous souhaitez fournir un outil ou un utilitaire à utiliser au moment de l’édition.  Dans ce cas, utilisez un élément de menu d’outils personnalisé pour appeler votre code personnalisé.

Créez ou modifiez un type de pas de test dans les situations suivantes :

• La fonctionnalité ne peut pas être implémentée dans les types de pas intégrés.
• La fonctionnalité nécessite de modifier des propriétés qui ne peuvent pas être modifiées dans les instances de types de pas de test existants,
• La fonctionnalité nécessite que des actions se produisent avant ou après l’appel du code de test, telles que la configuration du pas ou l’analyse des résultats.
• Vous souhaitez simplifier l’expérience utilisateur pour la configuration des pas à l’aide d’une interface utilisateur.
• Vous partagez la fonctionnalité avec d’autres groupes, sociétés ou clients.

Modèles de pas versus types de pas de test personnalisés

Vous pouvez créer des modèles de pas en développant et en configurant des pas dans une séquence, puis en faisant glisser et en déposant ces pas dans la liste des modèles de la palette d’insertion. TestStand stocke une copie de l’instance de pas en tant que modèle. Vous pouvez la réutiliser pour créer rapidement de nouvelles séquences en faisant glisser et en déposant le modèle de pas dans une nouvelle séquence.

La différence entre un modèle de pas et un type de pas de test personnalisé est que vous ne pouvez créer un modèle qu’à partir de types de pas de test existants et que le modèle ne comprend que les mêmes capacités que le type de pas de test d’origine. Vous ne pouvez pas modifier ou reconcevoir le modèle de pas, contrairement au type de pas de test personnalisé. Pour les pas que vous ajoutez à la liste des modèles, vous pouvez configurer uniquement les paramètres activés par le développeur du type de pas d’origine. En revanche, vous pouvez utiliser un nouveau type de pas de test personnalisé pour créer un tout nouveau pas avec un comportement entièrement nouveau. En outre, les modifications apportées à un modèle de pas n’affectent que les futures instances du pas et ne modifient pas les instances existantes de ce pas.

L’un des avantages de l’utilisation d’un modèle de pas est d’éviter de personnaliser plusieurs fois les paramètres de pas si vous réutilisez le même pas de la même manière. Par exemple, si vous définissez une alimentation IVI sur 5 V, puis sur 3,3 V et prévoyez de le faire plusieurs fois tout au long de la séquence, la création de modèles à deux pas après avoir initialement utilisé et configuré les pas peut vous faire gagner du temps. Cependant, si vous avez besoin d’un pas qui configure d’abord l’alimentation avant d’exécuter le code de test, la création d’un type de pas personnalisé est une meilleure approche.

Pendant de la conception de types de pas de test personnalisés, tenez compte des rôles distincts du développeur de framework et du développeur de test.  Le rôle du développeur de framework est de développer des outils et des blocs de construction, tandis que le rôle du développeur de test est d’utiliser ces outils pour implémenter le code de test réel.

Lorsque vous concevez un type de pas de test personnalisé, vous jouez le rôle d’un développeur de framework et il est important de considérer la fonctionnalité du type de pas de test que vous développez en termes d’utilisateurs finaux, les développeurs de test.
Utilisez ces instructions pendant l’établissement des exigences pour le type de pas de test personnalisé

• Définissez la portée du type de pas de test personnalisé.  Réfléchissez aux tâches utilisées par développeur de test pour implémenter le type de pas de test personnalisé.  La portée doit être suffisamment grande pour gérer ces cas d’utilisation, mais pas trop grande lorsque l’objectif du type de pas de test n’est pas clair.
• En fonction de la portée du type de pas de test, définissez les données dont le type de pas de test aura besoin et comment les données doivent être stockées.
• Définissez toute fonctionnalité devant être implémentée pour toutes les instances du type de pas de test.  Assurez-vous que toutes les données requises pour cette fonctionnalité sont définies dans les propriétés du pas.
• Définissez quelles données doivent être modifiables par les utilisateurs et lesquelles doivent être enregistrées dans le rapport ou la base de données.
• Considérez quelles fonctionnalités ou configurations pourraient être demandées à l’avenir et assurez-vous que ces éléments seront implémentés de manière à ce que les mises à jour du type de pas de test se propagent à toutes les instances.

Les types de pas de test personnalisés stockent les données dans plusieurs propriétés et paramètres que vous pouvez utiliser pour configurer le comportement des instances du type de pas de test et gérer les données requises pour la fonctionnalité du type de pas de test. Ceux-ci incluent :

• Propriétés de type intégrées qui sont présentes pour tous les types de pas de test et ne peuvent pas être modifiées dans les instances du type.
• Propriétés de valeur par défaut qui définissent l’état des nouvelles instances de pas, mais qui peuvent être modifiées dans les instances du type.
• Propriétés personnalisées que vous définissez pour un type de pas de test.

Propriétés de types intégrées

Des propriétés de types de pas de test intégrées existent pour tous les types de pas de test, et l’utilisateur ne peut pas modifier ces paramètres dans les instances du type de pas de test.  En outre, toutes les modifications que vous apportez aux valeurs de ces propriétés se propageront à toutes les instances du type de pas de test.

Exemple : Tous les types de pas de test définissent une expression de description qui s’affiche dans le volet Pas (Steps) à côté des instances de pas.  Cette propriété est présente pour tous les types de pas de test, mais la valeur est définie pour chaque type de pas de test.  La valeur ne peut pas être modifiée dans les instances du type de pas de test.

Pour accéder aux propriétés intégrées d’un type de pas de test :

1. Accédez à la vue des types à l’aide du menu Affichage » Types (View » Types) ou de la touche de raccourci Ctrl + T
2. Cliquez avec le bouton droit sur le type de pas de test, puis sélectionnez Propriétés… (Properties…) pour ouvrir la fenêtre des propriétés

Boîte de dialogue Propriétés du type de pas de test (Step Type Properties)

La plupart des paramètres de cette boîte de dialogue sont des valeurs par défaut, qui sont décrites dans la section suivante.  Les propriétés intégrées incluent :

• Icône : l’icône de pas, située dans le dossier <TestStand Public>/Components/Icons.
• Expression de la description du pas : la description du pas qui apparaît dans le volet des pas, par exemple le type de pas de test
• Paramètres de version : utilisés pour résoudre les conflits de type  
• Expression du nom de l’élément (onglet Menu) : définit le nom du pas dans la palette d’insertion

Création de descriptions d’auto-documentation

Étant donné que la description n’est pas configurable dans les instances de pas, vous pouvez la définir en tant que développeur de type de pas de test pour aider les utilisateurs à créer des étapes d’auto-documentation.  Le champ de description est spécifié par une expression qui vous permet de créer des descriptions dynamiques qui affichent des propriétés de pas importantes.  Lorsque l’utilisateur modifie ces valeurs de propriété dans les instances du type de pas de test, la description est mise à jour et permet à l’utilisateur de voir rapidement l’état du pas sans naviguer dans le volet de configuration du pas.

Exemple : La description du pas dans la deuxième étape de l’image ci-dessous est plus descriptive et fournit une meilleure documentation.  Cette description utilise l’expression suivante pour définir la description :

"Calibrate Channels: " + Str(Step.minChannel) + " - " +Str(Step.maxChannel)

Cette expression configure la description pour une mise à jour dynamique si l’utilisateur configure les propriétés de pas minChannel et maxChannel.

Exemples de description du pas

Valeurs par défaut des propriétés de pas

Pendant le développement d’un type de pas de test, vous pouvez configurer des valeurs par défaut pour tous les paramètres de pas configurables par l’utilisateur.  De plus, vous pouvez configurer ces propriétés pour qu’elles soient désactivées dans les instances de pas afin que les valeurs par défaut que vous définissez ne puissent pas être modifiées.  Comme les propriétés intégrées, les valeurs par défaut sont définies dans la fenêtre des propriétés de pas.  Cependant, tous les paramètres de valeur par défaut contiennent le mot « par défaut », soit dans le nom du paramètre, soit dans l’onglet des paramètres où ils sont configurés.

Exemple : La propriété d’expression d’état est utilisée pour déterminer le résultat du pas.  Cette propriété est présente pour tous les types de pas de test et la valeur par défaut est définie pour chaque type de pas de test.  Dans certains types de pas, tels que le test de limite numérique, l’expression d’état est désactivée dans le type de pas de test afin qu’elle ne puisse pas être modifiée dans les pas de test de limite numérique individuels.

Pendant la conception d’un type de pas de test personnalisé, vous pouvez désactiver toutes les propriétés qui ne varieront pas entre les instances du type de pas de test.  Cette disposition vous donnera plus de contrôle sur la façon dont les utilisateurs du type de pas de test peuvent modifier le comportement. Cependant, empêcher les utilisateurs de modifier les paramètres des pas peut limiter la flexibilité. Vous ne devez donc désactiver que les paramètres dont vous êtes sûr qu’un utilisateur n’aura jamais besoin de modifier.

N’oubliez pas que toutes les modifications futures que vous apporterez aux valeurs par défaut des propriétés de pas, même si vous désactivez leur modification dans les instances de pas, ne se propageront pas aux instances du type de pas de test. Reportez-vous à Mise à jour et maintenance des types de pas de test pour plus d’informations sur l’atténuation de ce problème.

Considérations pendant la mise à jour des valeurs par défaut

Vous ne devez pas utiliser les valeurs de ces propriétés pour définir une fonctionnalité du type de pas de test qui peut avoir besoin d’être mise à jour par le développeur de type de pas de test.  Par exemple, n’utilisez pas l’expression Publier (Post) du pas pour implémenter une fonctionnalité spécifique au type de pas de test.  Si vous devez mettre à jour cette fonctionnalité dans une future version du type de pas de test, il n’y aura aucun moyen de garantir que toutes les instances du pas sont mises à jour.  À la place, implémentez la fonctionnalité dans une sous-étape pré ou post-pas.

Propriétés personnalisées

En plus des propriétés intégrées, vous pouvez définir des propriétés personnalisées spécifiques au type de pas de test.  Utilisez ces propriétés pour stocker des données spécifiquement liées à la fonctionnalité de type de pas de test.  

Exemple : Les pas de test de limite numérique contiennent une propriété Limits.High, qui est unique au type de pas de test Limite numérique.  Le type définit une valeur par défaut de 11 pour cette propriété et l’utilisateur peut modifier la valeur de chaque instance qu’il crée.

Pour créer des propriétés de pas personnalisées :

1. Accédez à la vue des types à l’aide du menu Affichage » Types (View » Types) ou de la touche de raccourci Ctrl + T
2. Développez l’élément de type de pas de test.
3. Cliquez avec le bouton droit sur la propriété Parent ou l’entrée “<Right click to insert field>” pour ajouter une nouvelle propriété.

Si vous définissez une propriété dans le conteneur de résultats du type de pas de test, la propriété sera incluse dans la collection de résultats.  Vous pouvez ensuite utiliser les marqueurs IncludeInReport ou IncludeInDatabase pour consigner les données dans un rapport ou une base de données.

Par défaut, les utilisateurs peuvent modifier les valeurs de propriété de pas pour chaque instance de pas.  Toutefois, si vous définissez le marqueur partagé pour une propriété de pas dans le type de pas de test, la valeur sera verrouillée sur la valeur dans le type de pas de test.  Contrairement aux valeurs par défaut des pas, les mises à jour de la valeur se propageront aux instances du type de pas de test.

Déterminer la portée d’un type de pas de test personnalisé

Les types de données que vous choisissez pour les propriétés de pas doivent être déterminés par la portée du type de pas de test. Par exemple, pensez aux pas du test de limite numérique et aux pas de test de limite numérique multiples.  Bien que le test de limites numériques multiples puisse prendre en charge des limites supplémentaires et ait plus de capacités, il introduit également de la complexité dans l’interface utilisateur au moment de l’édition et de l’enregistrement des résultats.  Le test de limite numérique plus basique a une portée plus petite et une interface beaucoup plus simple. En plus de nécessiter moins de travail de développement, les pas ayant une portée plus petite sont également plus faciles à utiliser par les développeurs de séquences de tests.

Pendant le développement de vos propres types de pas de test personnalisés, il est important de définir la portée du pas avant de définir les propriétés personnalisées, car les propriétés que vous choisissez ont une incidence importante sur la complexité du type de pas de test.

Les sections suivantes décrivent comment vous pouvez utiliser des sous-pas pour implémenter les comportements de types de pas de test suivants :

• Fonctionnalité du moteur d’exécution qui doit s’exécuter pour toutes les instances du type de pas de test avant ou après le module de code principal
• Interfaces utilisateur pour afficher et modifier les données de pas pendant la modification des séquences de test
• Fonctionnalité à exécuter lorsque le développeur de test crée de nouvelles instances du pas

Implémentation de sous-pas

Les sous-pas appellent les modules de code à l’aide de l’un des adaptateurs TestStand fournis.  Les sous-pas ne peuvent pas être modifiés dans les instances du pas, et toutes les modifications apportées aux paramètres de sous-pas se propageront aux instances du type de pas de test.   

Pour ajouter des sous-pas à un type de pas de test personnalisé :

1. Accédez à la vue des types à l’aide du menu Affichage » Types (View » Types) ou de la touche de raccourci Ctrl + T
2. Cliquez avec le bouton droit sur le type de pas de test, puis sélectionnez Propriétés… (Properties…).
3. Sélectionnez l’onglet Sous-pas (Substeps).  Choisissez l’adaptateur qui correspond au module de code souhaité
4. Cliquez sur Ajouter (Add), puis sélectionnez un type de sous-pas.  Une nouvelle entrée apparaît dans la liste des sous-pas
5. Sélectionnez l’entrée et cliquez sur Spécifier le module (Specify Module) pour configurer le module de code pour le sous-pas de la même manière que vous configureriez le module de code pour un pas

     Publier et modifier des sous-pas du type de pas de test de limite numérique multiple

Définition de la fonctionnalité du moteur d’exécution pour le type de pas de test

Vous pouvez définir la fonctionnalité du moteur d’exécution pour le type de pas de test à l’aide de sous-pas pré-pas et post-pas.  Ces sous-pas s’exécutent avant ou après le module de code principal lorsque le pas est exécuté.   

Exemple : Le type de pas de test contextuel du message utilise un module de code C pour créer et afficher le message au moment de l’exécution.  Ce module est appelé dans un sous-pas post-pas.  

          Ordre d’exécution des pas : Sous-pas

Utilisez ces sous-pas pour définir la fonctionnalité qui s’applique à toutes les instances du pas.  Souvent, les sous-pas nécessitent des données spécifiques liées au comportement du type de pas de test.  Définissez ces données dans les propriétés de pas personnalisées pour vous assurer qu’elles sont disponibles dans toutes les instances du pas.

S’il existe plusieurs sous-pas pré-pas ou post-pas, ils s’exécutent dans l’ordre dans lequel ils apparaissent dans l’onglet Sous-pas (Substep) de la boîte de dialogue Propriété du type de pas de test (Step Type Property).

Par défaut, les développeurs de tests peuvent préciser un module de code pour chaque instance du type de pas de test.  Si le type de pas de test ne nécessite pas de module de code, vous devez désactiver l’option « Spécifier le module » (Specify Module) dans l’onglet Désactiver les propriétés (Disable Properties) pour la configuration du type de pas de test.  De nombreux types de pas de test intégrés sont conçus de cette manière, tels que les pas contextuels des instructions et des messages.

Fournir un feedback visuel pour les opérations longues

TestStand attend que le code des sous-pas pré-pas ou post-pas s’exécute avant de continuer. Si les modules de code pour ces pas fonctionnent lentement ou silencieusement, TestStand peut sembler ne pas répondre. Pour résoudre ce problème, vous pouvez modifier le curseur ou utiliser des messages d’interface utilisateur, tels que UIMsg_ProgressPercent, pour mettre à jour la barre de progression dans la barre d’état. 

Reportez-vous à la section Mise à jour de la barre d’état à l’aide de messages d’interface utilisateur pour plus d’informations sur cette approche

Utiliser le moniteur de terminaison

Les modules de code que vous développez doivent inclure et interroger périodiquement un moniteur de terminaison pour assurer la gestion lorsque les utilisateurs terminent ou abandonnent l’exécution de la séquence à l’aide des options intégrées de TestStand ou de l’API TestStand.  En utilisant le moniteur de terminaison, vous pouvez terminer rapidement le sous-pas si l’utilisateur met fin à l’exécution de la séquence.

Reportez-vous aux exemples de moniteur de terminaison pour plus d’informations sur l’implémentation du moniteur de terminaison dans votre code.

Utiliser des sous-pas pré-pas ou post-pas au lieu du module par défaut

Implémentez le module de code pour les opérations de base inhérentes au type de pas de test en tant que sous-pas pré-pas ou post-pas plutôt qu’en tant que module par défaut. Utilisez le paramètre de module par défaut uniquement lorsque chaque instance d’un pas peut appeler un module de code différent. Le paramètre de module par défaut existe séparément sur chaque instance de pas et TestStand ne met pas à jour les instances de pas existantes par défaut lorsque vous modifiez le paramètre sur le type de pas de test. Cependant, les modifications apportées aux sous-pas affectent automatiquement toutes les instances existantes du type de pas de test.

Création d’interfaces d’édition pour les types de pas

Les sous-pas d’édition fournissent une interface utilisateur graphique (GUI) implémentée dans un module de code, dans laquelle l’utilisateur peut modifier les variables ou les paramètres de cette instance de pas au moment de l’édition. En règle générale, le sous-pas d’édition est utilisé pour configurer les propriétés de pas personnalisées que vous définissez pour le type de pas de test.   

Exemple : Le type de pas de test Open Database ouvre une boîte de dialogue via un sous-pas d’édition pour permettre aux utilisateurs de configurer les propriétés des pas ConnectionString et DatabaseHandle, qui sont des propriétés personnalisées pour le type de pas de test de base de données.

Le sous-pas d’édition fournit une interface utilisateur pour configurer les paramètres de pas

Lorsque l’utilisateur crée une instance d’un type de pas de test personnalisé, il peut accéder à l’interface utilisateur de sous-pas d’édition à l’aide d’un bouton dans le volet des paramètres de pas, qui lance l’interface utilisateur du sous-pas d’édition dans une nouvelle fenêtre.  Cependant, vous pouvez également intégrer l’interface utilisateur du sous-pas d’édition directement dans l’onglet, comme de nombreux types de pas de test intégrés.  Cette approche nécessite un effort de développement supplémentaire et doit être développée dans un langage .NET, mais fournit une interface d’édition plus transparente pour l’utilisateur du type de pas de test.  Reportez-vous à Création d’onglets d’édition de type de pas de test personnalisés dans l’éditeur de séquence pour plus d’informations sur la façon d’implémenter des interfaces du sous-pas d’édition intégrées.

Comparaison entre une interface d’édition intégrée (en haut) et un sous-pas d’édition, qui se lance dans une fenêtre distincte (en bas)

Sous-pas d’édition simples versus multiples

Un type de pas de test personnalisé peut définir de nombreuses propriétés qui peuvent prêter à confusion si elles sont affichées simultanément pour l’utilisateur.  Lorsque vous utilisez l’approche typique des sous-pas d’édition qui se lancent dans une fenêtre distincte, utilisez des méthodes d’organisation au sein d’un seul sous-pas d’édition, telles que l’introduction d’onglets, pour organiser les données en sections gérables.  L’utilisation de plusieurs sous-pas d’édition n’est pas recommandée, car chaque interface doit être lancée indépendamment.  Par exemple, le pas Open SQL Statement implémente un seul sous-pas d’édition avec plusieurs onglets.   

Le sous-pas d’édition pour le pas Open SQL Statement contient deux onglets pour classer les paramètres

Si vous utilisez l’approche du volet de pas intégré pour les types de pas de test complexes, il est avantageux d’utiliser plusieurs volets d’édition, car les données seront facilement visibles sur les onglets de pas. Par exemple, le pas Multiple Numeric Limit Test comprend deux onglets pour modifier la source des données numériques et les conditions limites pour chaque source de données.  

Les onglets Limite (Limit) et Source de données (Data source) sont chacun implémentés dans un volet d’édition séparé

Rendre les sous-pas modaux dans TestStand

Faites toujours en sorte que les sous-pas d’édition et les autres modules de code d’interface utilisateur soient modaux dans TestStand, car lorsque ce dernier appelle les sous-pas d’édition, il désactive l’éditeur de séquence. Si les modules de code ne sont pas modaux, la fenêtre TestStand peut masquer les modules de code. Les utilisateurs peuvent penser que l’éditeur de séquence est bloqué et peuvent essayer de fermer TestStand.

Reportez-vous à l’exemple Rendre des boîtes de dialogue modales dans TestStand pour plus de détails sur la façon d’implémenter la modalité dans un module de sous-pas.

Utiliser des expressions pour maximiser la flexibilité

L’utilisation de champs d’expression dans une interface utilisateur de sous-pas d’édition est un moyen flexible pour les utilisateurs d’interagir avec les données et permet aux utilisateurs d’utiliser des variables et une logique dans les valeurs de propriété.  Cependant, l’utilisation du contrôle Expression peut nécessiter un investissement plus important que l’utilisation de contrôles de chaîne ou numériques et nécessite une vérification supplémentaire pour garantir que l’expression est évaluée à une valeur valide pour la propriété.  

Les expressions sont plus flexibles que les valeurs fixes pour spécifier les paramètres

Définir un comportement lorsque les développeurs créent des instances de pas

Dans de nombreux cas, vous souhaiterez peut-être définir des fonctionnalités qui se produisent lorsqu’un développeur de test crée une nouvelle instance de pas.  Par exemple, le type de pas de test If intégré utilise un sous-pas OnNewStep pour insérer un pas End correspondant.

Pour implémenter ce type de fonctionnalité, créez un sous-pas d’édition et renommez le sous-pas par « OnNewStep ».  Ces sous-pas utilisent généralement l’API TestStand pour manipuler l’instance de pas ou créer des instances de pas supplémentaires.

Recommandations générales pour les sous-pas

Utilisation de paramètres par rapport à l’API TestStand pour accéder aux données dans les sous-pas

Comme avec un module de code standard, il existe deux méthodes pour fournir des données TestStand à un sous-pas.  Vous pouvez transmettre des données via les paramètres du module de code.  Alternativement, vous pouvez appeler l’API TestStand à partir du module de code pour accéder directement et modifier les propriétés. Les sous-pas pré-pas et post-pas n’ont généralement besoin que de lire les propriétés du pas pour déterminer leur comportement. Par exemple, la valeur de température pour l’installation d’une chambre chauffée.  Les sous-pas d’édition, cependant, nécessitent que l’état actuel des propriétés s’affiche dans l’interface utilisateur initiale, mais également un moyen de mettre à jour les valeurs que l’utilisateur modifie.   

Dans la plupart des cas, il est préférable d’utiliser des paramètres pour transmettre des données plutôt que l’API TestStand pour y accéder directement.  L’utilisation de paramètres est moins sujette aux erreurs : toutes les erreurs dans les noms de propriété ou les types de données seront faciles à trouver, car les propriétés sont définies dans les paramètres de type du pas de test dans TestStand, pas directement dans le module de code. De plus, le fait d’avoir toutes les propriétés définies dans la configuration du pas rend le type de pas de test plus facile à gérer.  Toutes les modifications apportées aux propriétés du pas peuvent être prises en compte sans aucune modification du module de code.

Cependant, l’utilisation de l’API pour accéder directement aux propriétés peut être utile dans les cas où le module de code accède dynamiquement à une variété de données, en fonction de l’état du pas.  L’utilisation de paramètres du pas dans ce cas peut conduire à une longue liste de paramètres où seuls certains sont utilisés dans diverses conditions.

L’adaptateur de module lit ou écrit les variables du pas dans les entrées et sorties des modules de code et vérifie les erreurs

L’accès aux propriétés du pas à partir de LabVIEW à l’aide de l’API TestStand ne fournit pas de vérification d’erreur de paramètre au moment de l’édition

Déchargement des modules pendant l’édition

Lorsque vous développez et testez des modules de code pour des sous-pas d’un type de pas de test personnalisé, sachez que TestStand charge et réserve le module de code en mémoire lorsque le sous-pas est exécuté. Cette fonctionnalité améliore les performances, car le module reste chargé pour les exécutions suivantes, mais vous ne pouvez pas modifier le module de code tant que TestStand ne le décharge pas. Vous pouvez décharger le module de code de deux manières :

1. Sélectionnez Fichier » Décharger tous les modules (File » Unload All Modules) pour décharger tous les modules actuellement réservés en mémoire.
2. Dans le volet de configuration du sous-pas, sélectionnez le bouton d’édition pour décharger le module et l’ouvrir dans l’environnement de développement correspondant

Pratiques exemplaires pour la gestion des types de pas de test personnalisés

Stockage et distribution des types de pas de test personnalisés

Il est important de réfléchir à la façon de stocker et de distribuer les pas personnalisés que vous créez. NI recommande de créer tous les types de pas de test dans un fichier de palette de types, et non dans un fichier de séquence, car TestStand recherche dans les fichiers de palette de types les mises à jour de type de pas de test lorsque vous chargez un fichier de séquence. TestStand vous aide également à gérer la réutilisation des pas en conservant une copie de chaque type de pas de test utilisé dans un fichier de séquence. Si vous déployez le fichier de séquence sans le fichier de palette de types, le fichier de séquence contient toujours une copie du type de pas de test.   

En tant que développeur de framework, il est courant que vos types de pas de test soient utilisés par plusieurs développeurs de tests.  Une telle situation peut constituer un défi, car les types de pas de test ont de nombreux fichiers associés.  Pour aider à gérer les fichiers de type de pas de test, utilisez les répertoires suivants pour stocker les fichiers pour votre type de pas de test

• Fichier de palette de types contenant la définition de type <TestStand Public>/Components/TypePalettes/
• Fichiers de module de code de sous-pas <TestStand Public>/Components/StepTypes/[typeName]
• Icône personnalisée <TestStand Public>/Components/Icons/[typeName]

En utilisant ces répertoires, vous pouvez distribuer les fichiers nécessaires dans le répertoire public TestStand sur n’importe quel système de développeur de test.  Si vous avez défini votre type dans un nouveau fichier de palette de types, vous pouvez configurer TestStand pour importer automatiquement la palette de types en ajoutant un préfixe «Install_» au nom du fichier de palette de types.  Reportez-vous à la rubrique d’aide Fichiers de palette de types pour plus de détails sur cette méthode

Éviter de renommer ou de modifier le type de données des propriétés de pas

Si vous devez modifier le type d’une propriété personnalisée, vous pouvez le faire en créant une autre propriété avec le nouveau type et en conservant la propriété avec le type précédent. Si vous modifiez le nom ou le type de données d’une propriété, TestStand remplace la valeur de la propriété dans les instances de pas par la valeur par défaut de la propriété. En plus de créer une nouvelle propriété avec le nouveau type, vous pouvez ajouter une logique au type de pas de test pour gérer les cas où un pas utilise l’ancienne propriété et la nouvelle. Par exemple, lorsque TestStand a implémenté des valeurs limites en tant qu’expressions, deux nouvelles propriétés booléennes ont été ajoutées pour spécifier d’utiliser l’ancienne propriété de limite numérique. Les propriétés UseLowExpr et UseHighExpr déterminent si le pas évalue les anciennes limites numériques ou les nouvelles limites d’expression.

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