Une stratégie de données de test décide ce que vous capturez, comment vous le nommez et comment vous l'organisez avant d'écrire votre premier test. Bien faire les choses dès le départ fait gagner des mois de nettoyage par la suite. Mal les faire signifie que vos analyses sont bruitées, votre traçabilité a des lacunes et votre équipe perd du temps à décoder des données incohérentes.
Quelles données capturer
Chaque exécution de test devrait inclure quatre catégories de données :
Mesures avec limites
Ce sont les valeurs quantitatives qui déterminent le verdict. Définissez toujours les limites dans le code, pas en post-traitement. Cela garantit que chaque exécution est évaluée selon les mêmes critères, et la limite appliquée accompagne le résultat.
| Type de données | Exemple | Pourquoi c'est important |
|---|---|---|
| Mesures paramétriques | Tension, courant, résistance | Permet l'analyse Cpk et la détection de tendances |
| Vérifications fonctionnelles | Réponse de communication, temps de démarrage | Valide le comportement au niveau système |
| Relevés environnementaux | Température, humidité pendant le test | Explique la variation des mesures |
Enregistrez la valeur mesurée, pas seulement le verdict. Un booléen dit qu'une unité a échoué ; la valeur dit qu'elle mesurait 3,19 V pour une limite à 3,20 V et qu'elle dérivait depuis trois semaines. C'est le seul champ impossible à reconstruire plus tard.
Identité de l'unité
Chaque unité a besoin d'un numéro de série unique. Si votre produit comporte des sous-ensembles, suivez aussi leurs numéros de série. C'est ce qui permet de remonter une défaillance terrain à travers chaque test qu'elle a subi.
Métadonnées
Le contexte qui n'a pas de limites mais compte pour l'analyse : version firmware, révision matérielle, opérateur, station de test. Quand vous investiguez pourquoi le rendement a chuté mardi, les métadonnées sont le moyen de trouver la cause.
Pièces jointes
Fichiers journaux, captures de formes d'onde, images d'inspection optique. Chaque exécution ne nécessite pas de pièces jointes, mais quand une investigation commence, vous les voudrez. Joindre sur les échecs plutôt que sur chaque unité évite que cela dépasse son utilité.
Conventions de nommage
Un nommage cohérent est la différence entre des données interrogeables et des données à parcourir manuellement.
Noms de procédures
Utilisez une hiérarchie claire : {produit}_{étape}_{type_de_test}. Gardez les noms en minuscules avec des underscores.
| Modèle | Exemple |
|---|---|
{produit}_{étape}_{test} | sensor_v2_evt_functional |
{produit}_{étape}_{test} | motor_ctrl_pvt_burn_in |
{produit}_{étape}_{test} | power_supply_dvt_thermal |
N'intégrez pas les dates ou les identifiants de station dans les noms de procédures : ce sont des champs séparés.
Noms de mesures
Utilisez le format {composant}_{paramètre}. Soyez suffisamment spécifique pour qu'une personne non familière du test comprenne ce qui a été mesuré.
test_naming_example.py47 lines
# Mesures bien nommées pour un test d'alimentationimport openhtf as htffrom openhtf.util import unitsfrom tofupilot.openhtf import upload@htf.measures( # Bon : composant spécifique, paramètre clair htf.Measurement("rail_3v3_voltage") .in_range(minimum=3.25, maximum=3.35) .with_units(units.VOLT), htf.Measurement("rail_3v3_ripple") .in_range(maximum=30) .with_units(units.MILLIVOLT), htf.Measurement("rail_5v_voltage") .in_range(minimum=4.9, maximum=5.1) .with_units(units.VOLT), htf.Measurement("rail_5v_load_regulation_pct") .in_range(maximum=2.0), htf.Measurement("input_current_idle") .in_range(maximum=0.050) .with_units(units.AMPERE), htf.Measurement("thermal_shutdown_temp") .in_range(minimum=145, maximum=155) .with_units(units.DEGREE_CELSIUS),)def power_supply_validation(test): test.measurements.rail_3v3_voltage = 3.301 test.measurements.rail_3v3_ripple = 18.4 test.measurements.rail_5v_voltage = 5.03 test.measurements.rail_5v_load_regulation_pct = 1.2 test.measurements.input_current_idle = 0.0321 test.measurements.thermal_shutdown_temp = 150.2def main(): test = htf.Test( power_supply_validation, procedure_id="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", # UUID de procédure du dashboard part_number="PSU-100", ) test.add_output_callbacks(upload()) test.execute(lambda: "PSU-2024-0891")if __name__ == "__main__": main()Installez-le avec pip install "tofupilot[openhtf]". Le callback upload() lit TOFUPILOT_API_KEY dans l'environnement.
Les noms de mesures sont pratiquement définitifs. En renommer un scinde son historique en deux séries, donc la tendance que vous vouliez consulter s'arrête au renommage. Fixez la convention avant la première série de production.
Évitez ces erreurs de nommage :
| Mauvais nom | Problème | Meilleur nom |
|---|---|---|
test1 | Sans signification | rail_3v3_voltage |
voltage | Quelle tension ? | rail_5v_voltage |
V_out_3.3V_meas | Casse et format incohérents | rail_3v3_output_voltage |
temperature | Quelle température, quelle unité ? | thermal_shutdown_temp |
Format de numéro de série
Choisissez un format et appliquez-le. Modèles courants :
| Format | Exemple | Cas d'utilisation |
|---|---|---|
{PRÉFIXE}-{ANNÉE}-{SEQ} | PCB-2024-00042 | Production générale |
{PRODUIT}-{LOT}-{SEQ} | SNS-L0287-015 | Production par lots |
{SITE}-{LIGNE}-{DATE}-{SEQ} | SH-A3-240315-0001 | Suivi multi-sites |
Validez le format à la saisie. Une faute de frappe détectée au montage coûte quelques secondes ; la même retrouvée six mois plus tard dans un enregistrement de traçabilité est généralement irrécupérable.
Organiser les procédures par phase de production
Structurez vos procédures pour correspondre à votre flux réel. Chaque phase de test devrait être une procédure distincte.
EVT (Validation d'ingénierie)
├── sensor_v2_evt_power_on
├── sensor_v2_evt_functional
├── sensor_v2_evt_environmental
└── sensor_v2_evt_reliability
DVT (Validation de conception)
├── sensor_v2_dvt_incoming_inspection
├── sensor_v2_dvt_calibration
├── sensor_v2_dvt_functional
└── sensor_v2_dvt_burn_in
PVT (Validation de production)
├── sensor_v2_pvt_smt_inspection
├── sensor_v2_pvt_ict
├── sensor_v2_pvt_functional
└── sensor_v2_pvt_final_qc
Cette structure donne le rendement au premier passage par phase, permet de comparer EVT et PVT, et rend évident quel test a détecté une défaillance.
Enregistrer les liens de sous-ensembles
sub_units est un champ de htf.Test(...), aux côtés de procedure_id et part_number. Il enregistre quels composants sont entrés dans l'unité testée.
test_with_metadata.py30 lines
# Rattacher les numéros de série des sous-unités pour la traçabilité de la nomenclatureimport openhtf as htffrom tofupilot.openhtf import upload@htf.measures( htf.Measurement("boot_time_ms").in_range(maximum=500), htf.Measurement("self_test_result").equals("PASS"),)def functional_check(test): test.measurements.boot_time_ms = 230 test.measurements.self_test_result = "PASS"def main(): test = htf.Test( functional_check, procedure_id="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", # UUID de sensor_v2_pvt_functional part_number="SENSOR-V2", sub_units=[ {"serial_number": "WIFI-MOD-2024-0331"}, {"serial_number": "BT-MOD-2024-0887"}, ], ) test.add_output_callbacks(upload()) test.execute(lambda: "SENSOR-2024-2210")if __name__ == "__main__": main()Notez que procedure_id est l'UUID du dashboard, pas le nom de la procédure. La convention de nommage ci-dessus sert aux humains qui lisent le dashboard ; le code référence l'UUID. Un identifiant externe legacy fonctionne aussi, mais uniquement s'il a été explicitement défini sur la procédure.
Les numéros de série des sous-unités permettent de tracer quels composants sont entrés dans chaque assemblage. Quand un lot pose problème, vous trouvez chaque unité finie contenant les pièces concernées au lieu de mettre en quarantaine une plage de dates. C'est aussi le champ le plus difficile à ajouter après coup : modélisez-le dès la première série même si vous ne l'interrogez pas encore.
Liste de vérification pour la conservation des données
Avant de commencer à collecter, répondez à ces questions :
- Quelles normes de conformité s'appliquent ? ISO 13485 (médical), AS9100 (aérospatial) et IATF 16949 (automobile) ont des exigences spécifiques de conservation.
- Combien de temps devez-vous conserver les données ? La durée de vie du produit plus la garantie est une base courante. Les dispositifs médicaux exigent souvent plus de 15 ans.
- Quelles données doivent être immuables ? Les résultats utilisés pour la conformité réglementaire ne devraient jamais être modifiables après coup.
- Qui a besoin d'y accéder ? Définissez les rôles tôt. Ingénieurs de test, responsables qualité et clients peuvent avoir besoin de vues différentes.
Ajoutez-en une cinquième : comment sortir les données ? Les obligations de conservation survivent aux choix d'outillage : gardez une voie d'export qui ne dépend pas de la pérennité d'un fournisseur unique.
Les données de test sont stockées avec un historique d'audit complet. Chaque exécution est horodatée et liée à sa procédure, sa station et son opérateur : vous n'avez pas besoin de construire votre propre système de conservation.
