Stratégie de données de test

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 passe/échoue. 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.

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

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 qui compte pour l'analyse : version firmware, révision hardware, identifiant de l'opérateur, nom de la 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 de défaillance commence, vous les voudrez.

Conventions de nommage

Un nommage cohérent est la différence entre des données que vous pouvez interroger et des données qu'il faut 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. TofuPilot les suit comme 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 avec le test puisse comprendre ce qui a été mesuré.

test_naming_example.py

# Mesures bien nommées pour un test d'alimentation
import openhtf as htf
from openhtf.util import units
from tofupilot.openhtf import TofuPilot

@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.2

def main():
    test = htf.Test(power_supply_validation)
    with TofuPilot(test):
        test.execute(test_start=lambda: "PSU-2024-0891")

if __name__ == "__main__":
    main()

É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

Organiser les procédures par phase de production

Structurez vos procédures pour correspondre à votre flux de production réel. Chaque phase de test devrait être une procédure distincte dans TofuPilot.

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 vous donne le FPY par phase, permet de comparer le rendement entre EVT et PVT, et rend évident quel test a détecté une défaillance.

Ajouter des métadonnées avec OpenHTF

Utilisez les paramètres TofuPilot pour attacher du contexte qui n'est pas une mesure :

test_with_metadata.py

# Rattacher les numéros de série des sous-unités pour la traçabilité de la nomenclature
import openhtf as htf
from tofupilot.openhtf import TofuPilot

@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)
    with TofuPilot(
        test,
        procedure_id="sensor_v2_pvt_functional",
        sub_units=[
            {"serial_number": "WIFI-MOD-2024-0331"},
            {"serial_number": "BT-MOD-2024-0887"},
        ],
    ):
        test.execute(test_start=lambda: "SENSOR-2024-2210")

if __name__ == "__main__":
    main()

Les numéros de série des sous-unités permettent de tracer quels composants spécifiques sont entrés dans chaque assemblage. Quand un lot de composants pose problème, vous pouvez interroger TofuPilot pour trouver chaque unité finie contenant les pièces concernées.

Liste de vérification pour la conservation des données

Avant de commencer à collecter des données, répondez à ces questions :

Quelles normes de conformité s'appliquent ? ISO 13485 (médical), AS9100 (aérospatial) et IATF 16949 (automobile) ont toutes des exigences spécifiques de conservation des données.
Combien de temps devez-vous conserver les données ? La durée de vie du produit plus la période de garantie est une base courante. Les dispositifs médicaux exigent souvent plus de 15 ans.
Quelles données doivent être immuables ? Les résultats de test 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. Les ingénieurs de test, les responsables qualité et les clients peuvent avoir besoin de vues différentes des mêmes données.

TofuPilot stocke toutes les données de test 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.