Respuesta breve
La prueba funcional de un lote piloto debe mostrar si cada placa cumple las funciones acordadas bajo condiciones definidas. Para ello hacen falta pasos reproducibles, límites justificados y una relación entre cada resultado y la versión de hardware y firmware ensayada.
Transforme los requisitos en pasos verificables
Empiece por funciones cuyo fallo importaría al usuario: alimentación, entradas, salidas, comunicación, medidas o actuadores. Para cada una defina un estímulo y una respuesta esperada. La anotación el LED se enciende no demuestra la exactitud de un canal de medida.
Distinga verificaciones realizadas en todas las unidades de estudios sobre muestras seleccionadas. El lote piloto permite mejorar el proceso, pero una cantidad pequeña no demuestra fiabilidad a largo plazo ni sustituye las pruebas de producto que sean necesarias.
Documente medios de prueba y límites
Registre conexiones, alimentación, cargas, tiempos de espera e instrumentos. Obtenga los límites de los requisitos del producto y considere la incertidumbre de medida. No convierta el resultado de una única unidad buena en un límite sin evaluar qué significa.
Una unidad de referencia puede ayudar a detectar un adaptador averiado o un banco desajustado. También necesita identificación y estado documentado. Si se repara o reprograma sin dejar constancia, deja de ser una comparación fiable.
Vincule la programación con el resultado
La versión entregada debe poder identificarse. STM32CubeProgrammer dispone de programación, verificación e interfaz de línea de comandos. Su idoneidad para el banco debe comprobarse con el hardware concreto. STMicroelectronics — STM32CubeProgrammer
Guarde juntos número de serie, revisión de placa, identificador de firmware, versión del programa de prueba y resultado. Si existen datos de calibración individuales, vincúlelos a su unidad. Una prueba superada con otro firmware no representa la misma evidencia.
Conserve el historial después de corregir un fallo
Defina qué defectos permiten retrabajo mediante una instrucción y cuáles requieren una decisión técnica. Mantenga el resultado original aunque la repetición sea satisfactoria. El historial ayuda a reconocer problemas recurrentes y a evaluar sus posibles causas.
Ejemplo: varias placas fallan en la comprobación de un contacto. Registre posición, frecuencia y adaptador antes de atribuirlo al componente. Puede ser necesario investigar tanto el montaje como el contacto del banco. Cada causa propuesta necesita una comparación verificable.
Antes de iniciar el lote piloto
- Aprobar estímulo, respuesta y límites de cada paso.
- Identificar adaptadores, instrumentos y unidad de referencia.
- Fijar versiones aprobadas de firmware y software de prueba.
- Guardar resultados por placa e historial de correcciones.
- Revisar las cuestiones pendientes antes del siguiente lote.
Preguntas frecuentes
¿Hay que automatizar todas las pruebas?
No. En lotes pequeños pueden servir pasos manuales documentados. La automatización es especialmente útil para repeticiones, recogida compleja de datos y operaciones propensas a errores.
¿Tras reparar basta repetir el paso que falló?
Depende del cambio. Evalúe qué otras funciones pueden verse afectadas y defina el alcance de la repetición antes de liberar la unidad.
Fuentes técnicas
Servicio relacionado