Qu'est-ce qu'un process model de test
Un process model définit les opérations qu'un système de test effectue autour de votre code de test : identifier l'unité, initialiser les instruments, exécuter le test, collecter les résultats et nettoyer. Votre séquence de test mesure le produit. Le process model gère tout le reste.
Le terme vient de NI TestStand, où le process model est un fichier de séquence distinct qui appelle votre séquence de test. D'autres test executives utilisent d'autres noms pour la même idée. Ce guide explique ce que fait un process model, pourquoi ce concept existe, et comment les mêmes responsabilités sont prises en charge dans un framework de test Python.
Ce que gère un process model
Chaque test de production fait plus que mesurer. Avant la moindre lecture de tension, quelque chose doit savoir quelle unité se trouve sur le banc. Après la dernière mesure, quelque chose doit décider du verdict et stocker le résultat.
| Responsabilité | Exemple |
|---|---|
| Identification de l'unité | Scanner un code-barres, lire un numéro de série en EEPROM, interroger l'opérateur |
| Initialisation des ressources | Ouvrir une session VISA, connecter une alimentation, charger les données de calibration |
| Exécution du test | Exécuter les étapes de mesure dans l'ordre |
| Résolution du verdict | Décider réussite ou échec à partir de toutes les étapes |
| Stockage des résultats | Écrire un rapport, insérer une ligne en base, envoyer à un serveur |
| Nettoyage | Couper l'alimentation, libérer le banc, fermer les connexions |
Une seule ligne de ce tableau est votre test. Le reste est identique pour chaque procédure du poste, et c'est exactement pourquoi les test executives le factorisent. Écrit une fois, réutilisé partout.
Pourquoi cette abstraction existe
Sans process model, chaque script de test répète le même code de plomberie. Dix procédures, c'est dix copies du scan de code-barres, dix copies du générateur de rapport, dix endroits à modifier quand le schéma de base de données change.
Le process model inverse la relation. Au lieu que votre script appelle une fonction de rapport, le modèle appelle votre script :
Process Model├── Identifier l'unité├── Initialiser les ressources├── ──> Votre séquence de test (la seule partie écrite par produit)├── Résoudre le verdict├── Stocker les résultats└── NettoyerC'est l'inversion de contrôle appliquée au logiciel de test. Votre code de test devient un greffon sur un cycle de vie fixe, plutôt qu'un programme qui doit se souvenir de chaque étape.
Les trois modèles classiques
Les test executives livrent généralement trois modèles intégrés, distingués par leur gestion de plusieurs unités :
| Modèle | Comportement | À utiliser quand |
|---|---|---|
| Séquentiel | Une unité à la fois, du début à la fin | Banc à une position |
| Parallèle | Unités indépendantes, chacune démarrant et finissant selon son propre rythme | Plusieurs bancs indépendants |
| Batch | Plusieurs unités chargées et testées ensemble comme un groupe | Un banc contenant plusieurs unités |
La distinction compte pour le débit. Un modèle séquentiel sur un banc à quatre positions gaspille les trois quarts du matériel. Pour la règle de décision et l'arithmétique du débit, voir Test séquentiel, parallèle ou batch.
Chaque position testée indépendamment dans ces modèles est un test socket, le contexte qui possède une unité pendant la durée de son test.
Callbacks : personnaliser sans dupliquer
Un cycle de vie fixe n'est utile que si l'on peut s'y accrocher. Les test executives exposent des points d'extension nommés, appelés callbacks, qui s'exécutent à des moments définis : avant la boucle d'unités, après chaque unité, avant la génération du rapport.
Les callbacks permettent à un produit de redéfinir le format de rapport pendant que tous les autres gardent le comportement par défaut, sans copier le modèle. Le coût est l'indirection. Lire un test qui repose sur cinq callbacks redéfinis, c'est ouvrir six fichiers pour comprendre une exécution.
Les mêmes responsabilités en Python
Un framework de test Python gère le même cycle de vie, mais le déclare au lieu de le modéliser comme une séquence appelable distincte. Dans le TofuPilot Framework, le cycle de vie est fixé par le moteur et le fichier de procédure décrit ce qui s'exécute à chaque étape :
name: Battery Functional Testunit: serial_number: default_value: "BAT000001" part_number: default_value: "BAT-001"plugs: - name: power_supply python: plugs.psu:PowerSupply scope: stationsetup: - name: Warm Up Instruments python: phases.warm_upmain: - name: Measure Voltage python: phases.measure_voltage measurements: - name: voltage unit: V validators: - operator: ">=" expected_value: 4.8 - operator: "<=" expected_value: 5.2teardown: - name: Power Down python: phases.power_downChaque responsabilité du process model correspond à une déclaration :
| Concept process model | TofuPilot Framework |
|---|---|
| Identification de l'unité | Bloc unit:, avec prompt opérateur ou auto_identify |
| Initialisation des ressources | plugs: avec un scope de durée de vie |
| Callback avant test | Phases setup: |
| Séquence de test | Phases main: |
| Callback après test | Phases teardown:, qui s'exécutent toujours |
| Résolution du verdict | Règle moteur : le pire verdict de phase l'emporte |
| Stockage des résultats | Intégré, envoyé par le moteur |
Les fonctions de phase restent du Python ordinaire :
def measure_voltage(measurements, power_supply): measurements.voltage = power_supply.read_voltage()Ce qui change sans fichier de modèle
Deux choses diffèrent réellement, et les deux découlent du fait que le cycle de vie est fixe plutôt que modifiable.
Le stockage des résultats ne vous appartient plus. Dans une test executive classique, un callback de rapport est un point de personnalisation, et les équipes écrivent leur propre logger de base de données. Ici, l'envoi est le travail du moteur. Vous gagnez un schéma que vous ne maintenez pas ; vous perdez la possibilité d'en changer le format.
L'ordre des opérations n'est pas redéfinissable. Vous ne pouvez pas réordonner l'identification et l'initialisation des plugs comme le ferait une séquence de modèle personnalisée. Ce que vous contrôlez, c'est ce qui s'exécute à l'intérieur de chaque étape, plus le comportement en cas d'échec :
execution: on_first_failure: continue workers: 16Pour la plupart des logiciels de test de production, le cycle de vie fixe est précisément l'intérêt. La personnalisation qui comptait a toujours été le test lui-même, pas la plomberie autour. Si votre personnalisation du modèle existe pour remodeler le reporting ou les écritures en base, ce besoin disparaît plutôt qu'il ne migre.
Pour une correspondance callback par callback, y compris ceux à supprimer plutôt qu'à porter, voir Remplacer les callbacks TestStand en Python.
Quand une orchestration sur mesure reste nécessaire
Certains systèmes ne rentrent réellement pas dans un cycle de vie fixe : un banc qui se reconfigure en cours d'exécution, un flux de réparation qui décide quoi tester après un diagnostic, une boucle de stress qui tourne pendant des jours.
Dans ces cas, pilotez la boucle vous-même et utilisez un SDK pour enregistrer les résultats, plutôt que de forcer une procédure déclarative dans une forme qui ne lui convient pas. L'abstraction du cycle de vie se justifie quand le déroulé est le même à chaque cycle. Quand le déroulé est le produit, écrivez le déroulé.
Points clés
- Un process model est le cycle de vie fixe autour de votre code de test : identifier, initialiser, exécuter, résoudre, stocker, nettoyer.
- Il existe pour éviter que chaque procédure répète la même plomberie.
- Les modèles séquentiel, parallèle et batch ne diffèrent que par leur gestion de plusieurs unités.
- Les callbacks personnalisent le cycle de vie sans le copier, au prix de l'indirection.
- Un framework Python déclaratif conserve les mêmes responsabilités mais fige le cycle de vie, échangeant la flexibilité du fichier de modèle contre beaucoup moins de code à maintenir.