Automatisation des tests : du script au séquenceur

Le banc fonctionne, le script fonctionne, puis l'ingénieur qui l'a écrit s'en va. Six mois plus tard, une limite doit passer de 4,9 V à 4,85 V, et personne ne sait laquelle des 3 000 lignes la contient, ni quels résultats ont été produits avant ou après la dernière modification. La plupart des logiciels de test n'échouent pas parce que la mesure est fausse. Ils échouent parce qu'on ne peut pas les modifier sans risque.

Ce guide montre comment faire évoluer un script de test vers un programme structuré et maintenable : séparation des responsabilités, gestion des données et stratégie d'erreur qui lui permettent de tenir des années en production.

1. Le problème du « gros script unique »

Un premier script mélange souvent tout : commandes d'instruments, ordre des tests, limites, logique de décision et mise en forme du rapport, dans un seul fichier. C'est rapide à écrire et très bien pour un prototype de laboratoire. Cela devient un problème quand :

• le même test doit tourner sur plusieurs variantes de banc avec des instruments différents ;
• les limites changent à chaque révision du produit ;
• un opérateur, et non l'auteur, utilise le banc tous les jours ;
• un client ou le service qualité demande quel logiciel et quelles limites ont produit un résultat donné.

Exemple de ligne fragile : if dmm.read() > 4.9: fail() fige l'instrument, la limite et la décision au même endroit. Changer l'un des trois oblige à modifier et revalider le code.

2. Principe : quatre couches séparées

2.1 Schéma d'architecture décrit

Imaginez quatre couches horizontales, de haut en bas :

1. Séquence : la liste ordonnée des étapes (préparation, mesure, évaluation, remise à zéro). Elle dit quoi tester et dans quel ordre, rien sur comment fonctionne chaque instrument.
2. Limites et configuration : un fichier externe versionné (CSV, JSON, YAML ou table de base de données) avec, pour chaque étape, limite basse, limite haute, unité et paramètres.
3. Pilotes d'instruments : un module par type d'instrument, avec des fonctions simples (measure_voltage(), set_output()), qui cache le protocole (SCPI sur USB/Ethernet, API constructeur, liaison série).
4. Résultats et rapports : un service unique qui reçoit chaque mesure avec son contexte et l'écrit dans le rapport et les fichiers de données.

Les flèches ne descendent que de la séquence vers les pilotes, et vont de chaque couche vers le service de résultats. Aucune couche n'en contourne une autre.

2.2 Pourquoi c'est rentable

Changement demandé	Gros script	Layered program
Nouvelle limite	Modifier le code, retester	Modifier le fichier de limites, le versionner
Remplacer un multimètre par un autre modèle	Chercher toutes les commandes	Remplacer un pilote
Nouvelle variante produit	Copier le script	Nouvelle séquence, mêmes pilotes
Auditer un ancien résultat	Deviner	Le rapport indique les versions logiciel et limites

3. Choisir l'outil : Python, TestStand, LabVIEW

Ce sont les trois outils que nous rencontrons le plus souvent sur les bancs. Nos propres logiciels de test reposent sur un socle Python, avec intégration TestStand ou LabVIEW sur demande.

3.1 Python

• Points forts : gratuit, vaste écosystème, facile à versionner avec Git, adapté au traitement de données, bonnes bibliothèques de communication instrument.
• Vigilance : vous construisez vous-même le cadre de séquencement, l'interface opérateur et le format de rapport, ou vous choisissez un framework. Des frameworks comme pytest structurent les étapes, mais le séquencement de production demande un travail en plus (invites opérateur, numéros de série, données de poste).

3.2 NI TestStand

• Points forts : séquenceur de test dédié, avec types d'étapes, limites, rapports, gestion des utilisateurs et test en parallèle intégrés. Voir la présentation de NI : What is TestStand.
• Vigilance : licences par poste, et modules de code toujours à écrire (Python, LabVIEW, C ou .NET).

3.3 LabVIEW

• Points forts : programmation graphique, intégration étroite avec le matériel NI, rapide pour le pilotage d'instruments et les interfaces.
• Vigilance : le code graphique se compare et se relit moins facilement en gestion de versions ; les gros projets demandent de la discipline.

3.4 Critères de choix

1. Ce que les équipes du client savent déjà maintenir (le meilleur outil est celui qu'elles peuvent supporter).
2. Nombre de postes et budget de licences.
3. Matériel utilisé (pilotes constructeur disponibles).
4. Besoin de tester plusieurs unités en parallèle.
5. Exigences de traçabilité (qui a lancé quoi, avec quelle version).
6. Traitement des données après le test.

4. Les limites sont des données, pas du code

4.1 Contenu d'une ligne de limite

Pour chaque étape : identifiant, description, limite basse, limite haute, unité, type de comparaison (entre, supérieur, égal) et, si besoin, paramètres de mesure (calibre, temps d'intégration, délai de stabilisation).

Exemple de ligne (valeurs illustratives) :
STEP_120 ; Courant d'alimentation, veille ; 0 ; 15 ; mA ; GELE

(GELE = supérieur ou égal / inférieur ou égal, notation TestStand.)

4.2 Gestion de versions

• Stocker les fichiers de limites dans le même dépôt que le code.
• Chaque livraison reçoit un identifiant de version, écrit dans chaque rapport.
• Les modifications passent en revue : qui a changé quoi, pourquoi, validé par qui.

4.3 Exemple chiffré : bandes de garde

Exemple, valeurs illustratives. La spécification produit autorise 5,00 V ± 0,10 V. L'incertitude de mesure du banc à ce point est estimée à ± 0,02 V. Pour réduire le risque d'accepter une pièce réellement hors tolérance, on peut placer les limites d'acceptation à l'intérieur de la spécification, d'une bande de garde égale ici à l'incertitude de mesure : 4,92 V à 5,08 V. La contrepartie est un risque plus élevé de rejeter des pièces bonnes proches des limites. La bande de garde s'appuie en général sur l'incertitude élargie (k = 2) ; ces règles de décision sont décrites dans l'ISO 14253-1 et le JCGM 106, cités comme références. L'appliquer ou non, et comment, est une décision convenue avec le client et écrite dans la spécification de test.

5. Résultats et rapports

5.1 Ce que chaque résultat doit porter

• Numéro de série de l'unité, date et heure, identifiant du poste, opérateur.
• Version du logiciel et version du fichier de limites.
• Identifiant d'étape, valeur mesurée, unité, limites, statut.
• Identifiants des instruments quand la traçabilité à l'étalonnage est nécessaire.

5.2 Formats

• Rapport lisible (PDF ou HTML) pour l'opérateur et le client.
• Export de données pour l'analyse : CSV pour un usage universel, TDMS dans l'écosystème NI pour de gros volumes de formes d'onde.
• Horodatage dans un fuseau horaire unique et documenté, et noms de fichiers contenant le numéro de série et l'horodatage pour que rien ne soit écrasé.

6. Erreurs d'instrument et reprise

6.1 Erreurs à prévoir

• Instrument qui ne répond pas (câble, alimentation, adresse).
• Délai dépassé sur une mesure longue.
• Valeur hors calibre de l'instrument.
• État inattendu laissé par un essai interrompu.

6.2 Stratégie

1. Distinguer échec du test et erreur de test. Une pièce hors limites est un ÉCHEC. Un instrument qui ne répond pas est une ERREUR : l'état de la pièce est inconnu, pas mauvais.
2. Réessayer, avec une limite. Une ou deux reprises sur erreur de communication, tracées, jamais silencieuses. Ne jamais relancer une mesure qui a échoué sur ses limites.
3. Toujours exécuter la remise à zéro. Quoi qu'il arrive, les sorties sont coupées et les charges déconnectées. Dans le code, cela va dans un bloc finally ou dans le groupe de nettoyage du séquenceur.
4. Partir d'un état connu. Chaque essai commence par réinitialiser les instruments et vérifier leur identité.
5. Tout journaliser , avec assez de contexte pour reproduire le problème.

6.3 Note sur le temps

Le séquenceur PC n'est pas une référence de temps. Quand une étape dépend d'un chronométrage précis, confiez-la à une acquisition cadencée par le matériel et laissez le logiciel lire le résultat. Voir notre guide timing d'acquisition et la gigue.

7. Erreurs fréquentes

• Des limites écrites dans le code.
• Des commandes d'instruments dispersées dans la séquence.
• Pas de version logicielle dans les rapports.
• Relancer jusqu'à ce que ça passe.
• Traiter une erreur d'instrument comme un défaut produit (ou pire, comme un succès).
• Pas de remise à zéro après une interruption, sorties laissées sous tension.
• Des rapports qui s'écrasent parce que les noms de fichiers ne sont pas uniques.

8. Check-list d'un programme de test maintenable

• [ ] Séquence, pilotes, limites et rapports sont dans des modules séparés.
• [ ] Les limites sont dans un fichier externe versionné.
• [ ] Chaque rapport indique les versions du logiciel et des limites.
• [ ] SUCCÈS, ÉCHEC et ERREUR sont des statuts distincts.
• [ ] La remise à zéro s'exécute toujours, y compris après une interruption.
• [ ] L'identité des instruments est vérifiée au démarrage.
• [ ] Les données sont exportées dans un format exploitable, avec des noms de fichiers uniques.
• [ ] Une procédure de modification existe : revue, essai sur unités de référence, livraison.
• [ ] Le logiciel a été validé sur des unités bonnes et mauvaises connues avant la production.

9. Pour aller plus loin

Le logiciel n'est que la moitié d'un banc validé ; l'autre moitié consiste à prouver que le banc mesure juste, sujet du guide Qualifier un banc de test avant la production (FAT/SAT). Les séquenceurs pilotent aussi les bancs HIL et le matrices d'injection de défauts. Pour le lien entre procédures de test et réception, lisez ATP vs QTP et notre Méthodologie ATP.

RAYNOV développe le logiciel de test de ses systèmes de validation sur mesure et peut accompagner votre équipe en Validation en tant que service.

Un regard extérieur sur l'architecture de votre logiciel de test ? Contactez nos ingénieurs.