La réponse en bref
Le test fonctionnel d’une série pilote doit montrer si chaque carte remplit les fonctions convenues dans des conditions définies. Il faut donc des étapes reproductibles, des limites justifiées et une relation entre chaque résultat et les versions matérielle et logicielle testées.
Transformer les exigences en étapes vérifiables
Commencez par les fonctions dont la défaillance compte pour l’utilisateur : alimentation, entrées, sorties, communication, mesures ou actionneurs. Pour chacune, définissez un stimulus et une réponse attendue. La mention LED allumée ne démontre pas la précision d’une voie de mesure.
Distinguez les contrôles de chaque unité des investigations sur des échantillons choisis. La série pilote aide à améliorer le processus, mais un petit effectif ne prouve pas la fiabilité à long terme et ne remplace pas les essais produit nécessaires.
Documenter les moyens et les limites
Décrivez connexions, alimentation, charges, délais et instruments. Déduisez les limites des exigences du produit en tenant compte de l’incertitude de mesure. Ne transformez pas le résultat d’un seul exemplaire satisfaisant en limite sans en examiner la signification.
Un exemplaire de référence peut révéler un adaptateur défectueux ou un banc déréglé. Il doit lui aussi posséder une identification et un état documenté. Une réparation ou reprogrammation non enregistrée lui fait perdre sa valeur de comparaison.
Relier programmation et résultat du test
La version livrée doit être identifiable. STM32CubeProgrammer propose programmation, vérification et interface en ligne de commande. L’adéquation de ces moyens au banc se vérifie sur le matériel concerné. STMicroelectronics — STM32CubeProgrammer
Conservez ensemble numéro de série, révision de carte, identifiant firmware, version du programme de test et résultat. Si des données d’étalonnage sont individuelles, associez-les à l’exemplaire. Un test réussi avec un autre firmware ne constitue pas la même preuve.
Conserver l’historique après correction
Définissez quels défauts peuvent être repris selon une instruction et lesquels demandent une décision technique. Le résultat initial doit rester visible après un nouvel essai réussi. Cet historique permet de repérer les récurrences et d’étudier leurs causes.
Exemple : plusieurs cartes échouent au contrôle d’un contact de connecteur. Relevez position, fréquence et adaptateur avant d’accuser le composant. Il peut être nécessaire d’examiner à la fois le montage et le contact du banc. Chaque cause proposée doit être étayée par un essai comparatif.
Avant de lancer la série pilote
- Approuver stimulus, réponse et limites de chaque étape.
- Identifier adaptateurs, instruments et exemplaire de référence.
- Figer les versions approuvées du firmware et du logiciel de test.
- Enregistrer les résultats par carte et l’historique des corrections.
- Examiner les points ouverts avant le lot suivant.
Questions fréquentes
Faut-il automatiser tous les essais ?
Non. Des étapes manuelles documentées peuvent convenir à de petites quantités. L’automatisation est surtout utile pour les répétitions, la collecte complexe et les actions sujettes aux erreurs.
Après réparation, suffit-il de répéter l’étape en échec ?
Cela dépend de la modification. Évaluez les autres fonctions potentiellement touchées et définissez le périmètre du nouvel essai avant de libérer la carte.
Sources techniques
Prestation associée