Un equipo una vez envi\u00f3 placas con un sello de 'prueba funcional pasada' porque un cargador de arranque imprimi\u00f3 una bandera UART amigable. La cadena coincid\u00eda, el fixture se ilumin\u00f3 en verde, y el cronograma parec\u00eda menos aterrador. Luego, las unidades tempranas comenzaron a regresar con reinicios aleatorios\u2014unas 6% fallos en la vida temprana en las primeras miles\u2014justo cuando el producto necesitaba credibilidad. En el banco, las placas parec\u00edan estar bien hasta que la actividad real ocurri\u00f3: un r\u00e1faga de transmisi\u00f3n BLE tir\u00f3 del sistema de energ\u00eda y una ca\u00edda en la l\u00ednea de 1.8 V se mostr\u00f3 claramente en una traza de osciloscopio. La causa ra\u00edz no fue un comportamiento misterioso del firmware. Era una realidad de ensamblaje: un inductor sustituido con una marca superior similar pero con un comportamiento de saturaci\u00f3n diferente, adem\u00e1s de una prueba que nunca estres\u00f3 la l\u00ednea.<\/p>\n\n\n\n
Esa escapatoria no es solo un error t\u00e9cnico; es un fracaso social disfrazado de t\u00e9cnico. Una vez que un informe dice 'funcional PASA', otras personas escuchan 'caracter\u00edsticas validadas', y la organizaci\u00f3n comienza a tomar decisiones de env\u00edo con un mapa falso.<\/p>\n\n\n\n
Funcional no es un sin\u00f3nimo de 'imprime algo'.<\/p>\n\n\n
Cuando el firmware llega tarde o es inestable, las primeras pruebas deben comportarse como lo que son: detectores de defectos de ensamblaje y l\u00edneas base de hardware. Llamarlas 'funcionales' es c\u00f3mo los equipos certifican accidentalmente comportamientos que nunca ejercitaron.<\/p>\n\n\n\n
Aqu\u00ed yace la trampa de la etiqueta de 'prueba funcional'. Alguien dice, 'necesitamos una prueba funcional sin firmware', y lo que generalmente quieren decir es 'necesitamos una forma de mantener la l\u00ednea en movimiento sin convertir la fabricaci\u00f3n en un laboratorio de firmware'. Esos son objetivos diferentes. La primera frase invita a una marca de PASA\/NO PASA descuidada. La segunda invita a una prueba con alcance definido y afirmaciones expl\u00edcitas y no afirmaciones expl\u00edcitas, lo que evita que los argumentos se repitan en las revisiones de construcci\u00f3n. Tambi\u00e9n mantiene los paneles de control honestos cuando el liderazgo pide tasas de aprobaci\u00f3n y alguien intenta equiparar automatizaci\u00f3n con calidad.<\/p>\n\n\n\n
Para prevenir la desviaci\u00f3n del alcance, obliga a cada plan de prueba temprana a responder por escrito dos preguntas: qu\u00e9 defectos detecta esto, y qu\u00e9 comportamientos del producto esto no<\/em> certifica. Algunos equipos lo formalizan como un artefacto de aprobaci\u00f3n de dos columnas durante la transferencia de DVT a PVT, porque la memoria no sobrevive a la presi\u00f3n del cronograma.<\/p>\n\n\n\n Un p\u00fablico profesional no necesita una definici\u00f3n de JTAG, SWD, UART, I2C o SPI aqu\u00ed. El trabajo \u00fatil es decidir qu\u00e9 se puede medir de manera determinista hoy, y c\u00f3mo se nombran y llevan adelante esas mediciones para que nadie arme un arma con una luz verde.<\/p>\n\n\n Una l\u00ednea base no significa agregar \u201cm\u00e1s pruebas\u201d. Significa establecer un peque\u00f1o conjunto de invariantes \u2014 5 a 8 generalmente son suficientes \u2014 que una placa debe cumplir antes de que cualquier s\u00edntoma de firmware valga la pena debatir. Los rieles y relojes son los invariantes cl\u00e1sicos porque son precondiciones para todo lo dem\u00e1s, y son dif\u00edciles de discutir cuando se capturan en instrumentos en lugar de en registros.<\/p>\n\n\n\n Esto aparece en el patr\u00f3n de \u201cexcusa de firmware tard\u00edo que ocult\u00f3 un problema de reloj\u201d. En un caso, las placas arrancaban a veces y colgaban otras veces, y \u201cel firmware es inestable\u201d se convirti\u00f3 en la explicaci\u00f3n predeterminada. La soluci\u00f3n comenz\u00f3 eliminando la variabilidad: repetir el mismo experimento en 50 ciclos de encendido, medir el inicio del oscilador y el tiempo de reinicio, y dejar de tratar los registros inconsistentes como evidencia. La fuente del reloj ten\u00eda un arranque marginal en condiciones fr\u00edas debido a una elecci\u00f3n de capacitor de carga que era \u201csuficientemente cercana\u201d en papel. Una vez medido y corregido eso, el firmware dej\u00f3 de parecer inestable. La victoria no fue un mejor formato de registro; fue una forma de onda y una disciplina de repetibilidad.<\/p>\n\n\n\n La primera prioridad de la l\u00ednea base son los rieles de alimentaci\u00f3n, porque si los rieles est\u00e1n mal, todos los dem\u00e1s s\u00edntomas son mentira. Eso significa medir m\u00e1s que \u201carranca, as\u00ed que la alimentaci\u00f3n est\u00e1 bien\u201d. Significa voltajes nominales de riel, secuenciaci\u00f3n en relaci\u00f3n con habilitadores y reinicio, ripple\/ruido con un ancho de banda conocido y t\u00e9cnica de sonda adecuada, y una tensi\u00f3n deliberada que se asemeje a una transitoria de peor caso. Un osciloscopio de la serie Tektronix MDO3000 y una fuente de banco como una Keysight E36313A pueden hacer mucho de esto sin ceremonias, y un mult\u00edmetro calibrado como un Fluke 87V detecta las mentiras aburridas r\u00e1pidamente.<\/p>\n\n\n\n La historia del \u201csello de APROBADO que cost\u00f3 un cuarto\u201d es una buena raz\u00f3n para tratar la respuesta transitoria de carga como no opcional. Una comparaci\u00f3n de banner UART puede aprobar en un riel marginal porque el arranque es un evento de bajo estr\u00e9s en comparaci\u00f3n con radios, motores o sensores que tiran corriente en r\u00e1fagas. Un paso de carga programado de 10 segundos, o cualquier paso repetible que se asemeje a una transitoria de corriente real, es una forma econ\u00f3mica de detectar inductores sustituidos, capacitores de valor incorrecto o un regulador que apenas es estable. Sin ese estr\u00e9s, la prueba solo verifica que la placa est\u00e9 tranquila, no que est\u00e9 saludable.<\/p>\n\n\n\n En este punto, suele aparecer la trampa de escaneo I2C: \u201cnuestro escaneo I2C muestra dispositivos, por lo que el hardware est\u00e1 bien\u201d. Una enumeraci\u00f3n a\u00fan puede pasar con el valor de pull-up incorrecto, un riel marginal alimentando un nivelador de nivel, una uni\u00f3n fr\u00eda que se abre bajo vibraci\u00f3n, o un reloj que arranca lentamente lo suficiente como para alterar el tiempo una vez en diez arranques. Tambi\u00e9n puede pasar mientras una referencia anal\u00f3gica est\u00e1 en mal estado, porque las comunicaciones digitales permanecen perfectas hasta que las mediciones se desv\u00edan en el campo. Un escaneo I2C es una verificaci\u00f3n r\u00e1pida, pero no evidencia de una base de alimentaci\u00f3n y temporizaci\u00f3n estable.<\/p>\n\n\n\n Una l\u00ednea base que debe sobrevivir a cambios en firmware necesita al menos un ejemplo de umbral concreto, porque la vaguedad es c\u00f3mo la \u201cmedici\u00f3n\u201d se convierte en sensaciones. Un ejemplo, no una regla universal: un riel de 1.8 V podr\u00eda requerir mantenerse dentro de \u00b15% en estado estable, y bajo un paso de carga definido (por ejemplo, aproximando la r\u00e1faga de radio esperada), la ca\u00edda podr\u00eda limitarse a <100 mV con recuperaci\u00f3n en una ventana corta. Esa ventana podr\u00eda ser de menos de milisegundo o varios milisegundos dependiendo del regulador, el perfil de carga y lo que los ICs downstream puedan tolerar. Aqu\u00ed es donde importa el l\u00edmite de incertidumbre: los umbrales de ripple y ca\u00edda dependen de la compensaci\u00f3n espec\u00edfica del regulador, del ancho de banda de la sonda, del \u00e1rea f\u00edsica del lazo de la sonda y de la forma transitoria real. La forma de hacer que el umbral sea honesto es validarlo en una unidad de referencia y luego en una unidad conocida como defectuosa (o una falla inducida) para confirmar que la medici\u00f3n discrimina entre \u201csaludable\u201d y \u201ca punto de crear una cola RMA\u201d.<\/p>\n\n\n\n El punto de referencia tambi\u00e9n deber\u00eda incluir un peque\u00f1o conjunto de sanidad anal\u00f3gica en placas de se\u00f1al mixta, porque saltarse la anal\u00f3gica es c\u00f3mo los equipos env\u00edan desastres de \u201cfunciona en mi banco\u201d. La falla cl\u00e1sica es sutil y costosa: la interfaz digital es perfecta, los valores parecen razonables a temperatura ambiente, y luego las lecturas en campo se desv\u00edan con la temperatura o la variaci\u00f3n de la fuente. En un programa de sensores, la causa fue una sustituci\u00f3n impulsada por escasez: una referencia de 2.048 V con la tolerancia incorrecta, un car\u00e1cter diferente en el n\u00famero de pieza. El firmware intent\u00f3 cubrir la deriva con tablas de compensaci\u00f3n hasta que alguien midi\u00f3 el pin de referencia y observ\u00f3 la distribuci\u00f3n del c\u00f3digo ADC con una entrada fija. La soluci\u00f3n fue control de BOM y una medici\u00f3n de referencia en las primeras pruebas con un umbral lo suficientemente ajustado para detectar sustituciones. La calibraci\u00f3n no puede arreglar una familia de componentes intercambiados; solo puede adornar la falla hasta que escapa.<\/p>\n\n\n\n Los relojes y los resets merecen un lugar de referencia por la misma raz\u00f3n que los rieles: crean mentiras si son marginales. Un h\u00e1bito simple\u2014capturar el tiempo de desasserti\u00f3n del reset y el arranque del oscilador en docenas de ciclos de energ\u00eda\u2014convierte un \u201cbloqueo aleatorio\u201d en un sistema reproducible. Tambi\u00e9n evita que equipos en diferentes zonas horarias conviertan cada intermitente en una discusi\u00f3n de Slack sobre qui\u00e9n rompi\u00f3 qu\u00e9 durante la noche.<\/p>\n\n\n Las fallas intermitentes a menudo tienen un origen mec\u00e1nico, y un fixture de producci\u00f3n es un sistema mec\u00e1nico con efectos secundarios el\u00e9ctricos. Tratar los resultados del fixture como la verdad absoluta sin demostrar que el fixture es as\u00ed, es c\u00f3mo los equipos pierden d\u00edas en retrabajo que nunca tuvo la oportunidad de ayudar.<\/p>\n\n\n\n Un fixture de cama de clavos que empez\u00f3 a fallar placas que previamente pasaron la puesta en marcha en banco. Los s\u00edntomas eran inconsistentes, lo que hizo que la \u201cinestabilidad del firmware\u201d fuera un chivo expiatorio f\u00e1cil. La medida m\u00e1s r\u00e1pida fue hacer pasar una placa dorada conocida por buena a trav\u00e9s del fixture y comparar la resistencia de contacto en los pogo pins. La placa dorada tambi\u00e9n fall\u00f3. Eso cambi\u00f3 inmediatamente la culpa del dise\u00f1o hacia la infraestructura de prueba. El culpable no fue sutil: una carcasa de conector en el fixture estaba fuera de tolerancia, desplazando la alineaci\u00f3n de modo que dos pogo pins apenas tocaban. Reemplazar el conector, y el patr\u00f3n de falla desapareci\u00f3. Despu\u00e9s de eso, un paso de autoprueba del fixture se volvi\u00f3 innegociable.<\/p>\n\n\n\n Utiliza este \u00e1rbol de decisiones para prevenir la mayor parte del caos temprano:<\/p>\n\n\n\n La frase \u201cfallas aleatorias en el fixture\u201d debe tratarse como una solicitud para demostrar el fixture, no como una petici\u00f3n de m\u00e1s registros de firmware. Ese h\u00e1bito \u00fanico cambia el tono de la depuraci\u00f3n nocturna entre sitios porque acorta inmediatamente el espacio de b\u00fasqueda.<\/p>\n\n\n Una estrategia productiva de pruebas tempranas no es la que tiene la lista de verificaci\u00f3n m\u00e1s larga. Es la que detecta las clases de defectos m\u00e1s probables con las mediciones confiables m\u00e1s baratas, haciendo expl\u00edcitas las demoras para que no puedan ser introducidas con un sello verde.<\/p>\n\n\n\n Una escalera de modelos de fallos comienza enumerando las clases de defectos que realmente aparecen en construcciones bajo contrato: circuitos abiertos, cortocircuitos, pieza incorrecta, orientaci\u00f3n incorrecta, pieza faltante, puentes de soldadura y desalineaci\u00f3n mec\u00e1nica. Luego asigna cada clase a un m\u00e9todo de detecci\u00f3n que no requiere firmware estable: AOI para errores gruesos de colocaci\u00f3n y polaridad, verificaciones de continuidad donde exista acceso, firmas de riel y respuesta a carga para sustituciones y componentes pasivos faltantes, y boundary-scan donde las cadenas y el acceso sean reales. El valor de la escalera no es la cobertura te\u00f3rica, sino la capacidad de decir, en voz alta y por escrito, \u201cesta prueba detecta circuitos abiertos\/cortocircuitos en estas redes, pero no valida la funci\u00f3n X.\u201d<\/p>\n\n\n\n Esto tambi\u00e9n aborda la presi\u00f3n de \u201cautomatizar completamente las pruebas de producci\u00f3n ahora\u201d. La automatizaci\u00f3n no es progreso si automatiza el ruido. Demostrar la repetibilidad del fixture, definir invariantes y elegir pruebas de clases de defectos que seguir\u00e1n significando lo mismo la pr\u00f3xima semana es progreso. Todo lo dem\u00e1s es teatro en el tablero de control.<\/p>\n\n\n\n La postergaci\u00f3n necesita una l\u00ednea de defensa porque las personas equiparan \u201cno probado\u201d con negligencia. La mejor forma de enmarcarlo es que las postergaciones son decisiones de riesgo intencionales: pospuestas por falta de acceso, por firmware demasiado vol\u00e1til o porque la clase de defecto es rara en relaci\u00f3n con el cronograma y el contexto de construcci\u00f3n actual. El objetivo es evitar que esas postergaciones se conviertan en reclamaciones impl\u00edcitas.<\/p>\n\n\n Boundary-scan es la herramienta menos glamorosa y de mayor apalancamiento en esta situaci\u00f3n, porque puede proporcionar cobertura determinista para circuitos abiertos y cortocircuitos en componentes de pitch fino sin necesidad de firmware de aplicaci\u00f3n. Tambi\u00e9n elimina debates. Si la cadena puede realizar pruebas de interconexi\u00f3n y una red muestra un circuito abierto, no hay discusi\u00f3n sobre si un ajuste de temporizaci\u00f3n del firmware lo solucionar\u00e1.<\/p>\n\n\n\n En un caso con fallos intermitentes del bus, un analizador l\u00f3gico barato hizo que el bus pareciera \u201cen su mayor\u00eda bien\u201d, lo que mantuvo la culpa dirigida al firmware en el tiempo. Las pruebas de interconexi\u00f3n boundary-scan aislaron un circuito abierto en una pata de direcci\u00f3n BGA\u2014probablemente una soldadura fr\u00eda\u2014sin esperar m\u00e1s registros o m\u00e1s c\u00f3digo. Eso evit\u00f3 un costoso ciclo de retrabajo con rayos X y convirti\u00f3 el retrabajo en una acci\u00f3n dirigida con verificaci\u00f3n cuantitativa. La coordinaci\u00f3n entre Everett y un equipo de CM en Penang se simplific\u00f3 porque la evidencia era determinista.<\/p>\n\n\n\n La verificaci\u00f3n de la realidad importa: boundary-scan solo funciona si el acceso es real. La continuidad de la cadena necesita ser dise\u00f1ada, los BSDL deben ser usables, las resistencias de pull-up y las estrangulaciones deben ser sensatas, y la configuraci\u00f3n de seguridad no son \u201cproblemas posteriores\u201d\u2014el acceso a depuraci\u00f3n fusionado es una restricci\u00f3n estricta. La petici\u00f3n com\u00fan y optimista es \u201c\u00bfpuede el boundary scan probar todo?\u201d, a menudo acompa\u00f1ado de \u201csin pads de prueba pero a\u00fan as\u00ed deber\u00eda ser posible.\u201d La respuesta honesta es que la viabilidad depende del acceso a la cadena, la calidad de los BSDL y el estado de bloqueo; prometer un porcentaje de cobertura sin esos hechos es c\u00f3mo los planes de prueba se convierten en ficci\u00f3n.<\/p>\n\n\n\n Un compromiso pr\u00e1ctico que evita que los equipos se queden atascados es pilotar boundary-scan en una placa con el acceso previsto y la cadena de herramientas (las suites de Corelis\/Asset\/Keysight son comunes en f\u00e1bricas). Si funciona, puede reemplazar d\u00edas de debate en cada an\u00e1lisis de fallos futuro. Si no, el plan debe pivotar inmediatamente de regreso a rieles, relojes, reinicios y un peque\u00f1o conjunto de firmas anal\u00f3gicas\u2014cosas que a\u00fan se pueden medir a trav\u00e9s de conectores y pads disponibles.<\/p>\n\n\n Las pruebas tempranas tienden a fallar porque son fr\u00e1giles, no documentadas o vinculadas a las preferencias de herramientas de una sola persona. Un arn\u00e9s m\u00ednimo que sobreviva es aburrido por dise\u00f1o: un corredor, un mapa de pines espec\u00edfico de la placa, un conjunto de umbrales y registros que hacen que las rerun sean comparables.<\/p>\n\n\n\n Un patr\u00f3n que ha perdurado a trav\u00e9s de m\u00faltiples reescrituras de firmware es un arn\u00e9s de tres capas: abstracci\u00f3n de est\u00edmulo\/medici\u00f3n (controladores de instrumentos mediante algo como pyvisa o una capa DAQ), un mapa de placa (a menudo un mapa de pines YAML es suficiente), y casos de prueba que permanecen deterministas. Registrar en CSV con clave en el n\u00famero de serie puede ser suficiente temprano, siempre que los metadatos sean disciplinados: revisi\u00f3n de placa, ID del fixture, condiciones ambientales y versi\u00f3n de la imagen de prueba cuando el firmware est\u00e1 involucrado. La elecci\u00f3n del lenguaje (Python vs LabVIEW vs entornos de proveedores) importa menos que el l\u00edmite modular. Un VI monol\u00edtico de LabVIEW que solo una persona puede editar se convierte en un riesgo de personal en lugar de una estrategia de prueba.<\/p>\n\n\n\n Tambi\u00e9n hay una sutil incertidumbre que pertenece a la conversaci\u00f3n del arn\u00e9s: firmas de perfil de corriente. Son poderosas cuando los estados del firmware son estables. Cuando el firmware cambia a diario, los umbrales de corriente deben tratarse como detecci\u00f3n de tendencias\/anomal\u00edas, no como pase\/fallo duro, a menos que el equipo pueda bloquear una imagen de prueba con versiones controladas y banderas de caracter\u00edsticas reproducibles.<\/p>\n\n\n\n El punto de transferencia es sencillo: las pruebas tempranas pueden ampliar sus afirmaciones a medida que el firmware madura, pero solo si el arn\u00e9s mantiene confiable la capa de medici\u00f3n y el nombramiento se mantiene honesto. La detecci\u00f3n temprana de fallos reduce las escapatorias de ensamblaje. No certifica el comportamiento del producto.<\/p>","protected":false},"excerpt":{"rendered":" Cuando el firmware es inestable, un sello verde de \u201cfuncional\u201d puede ocultar defectos reales. Este art\u00edculo replantea las pruebas tempranas en torno a mediciones deterministas\u2014barras, relojes, reinicios, prueba de accesorios y cobertura del modelo de fallos\u2014para que las tasas de aprobaci\u00f3n reflejen la realidad, no el optimismo.<\/p>","protected":false},"author":1,"featured_media":10696,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"article_term":"","article_term_alternate":"","article_term_def":"","article_hook":"","auto_links":"","article_topic":"","article_fact_check":"","mt_social_share":"","mt_content_meta":"","mt_glossary_display":"","glossary_heading":"","glossary":"","glossary_alter":"","glossary_def":"","article_task":"Functional test development when firmware is late or unstable","footnotes":""},"categories":[12],"tags":[],"class_list":["post-10694","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog"],"_links":{"self":[{"href":"https:\/\/www.besterpcba.com\/es\/wp-json\/wp\/v2\/posts\/10694","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.besterpcba.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.besterpcba.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.besterpcba.com\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.besterpcba.com\/es\/wp-json\/wp\/v2\/comments?post=10694"}],"version-history":[{"count":1,"href":"https:\/\/www.besterpcba.com\/es\/wp-json\/wp\/v2\/posts\/10694\/revisions"}],"predecessor-version":[{"id":10698,"href":"https:\/\/www.besterpcba.com\/es\/wp-json\/wp\/v2\/posts\/10694\/revisions\/10698"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.besterpcba.com\/es\/wp-json\/wp\/v2\/media\/10696"}],"wp:attachment":[{"href":"https:\/\/www.besterpcba.com\/es\/wp-json\/wp\/v2\/media?parent=10694"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.besterpcba.com\/es\/wp-json\/wp\/v2\/categories?post=10694"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.besterpcba.com\/es\/wp-json\/wp\/v2\/tags?post=10694"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Categor\u00eda<\/th> El test puede afirmar esto<\/th> El test no debe afirmar esto<\/th><\/tr><\/thead> Cribado temprano en ensamblaje<\/td> Detecta defectos de ensamblaje consistentes con mediciones definidas (rieles\/reloj\/restablecimiento\/continuidad\/una o dos verdades anal\u00f3gicas)<\/td> Certifica caracter\u00edsticas visibles para el cliente, rendimiento en diferentes condiciones, seguridad\/conformidad, o \u201cfunciona\u201d en un sentido amplio<\/td><\/tr> Asistido por firmware posteriormente<\/td> Valida comportamientos espec\u00edficos vinculados a una imagen de prueba versionada y reproducible y a la trazabilidad de requisitos<\/td> Implica cobertura fuera de las banderas de funciones habilitadas o fuera de las condiciones de prueba<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n L\u00ednea base de medici\u00f3n primero: rieles, luego relojes\/restablecimientos, luego una verdad anal\u00f3gica<\/h2>\n\n\n
Probar el fixture antes de culpar a las placas (Disciplina Golden-First)<\/h2>\n\n\n
\n
Cobertura de clases de defectos: una peque\u00f1a escalera de modelos de fallos supera al teatro de la 'suite de pruebas completa'<\/h2>\n\n\n
Escaneo de frontera: evidencia determinista, cuando el hardware lo permite<\/h2>\n\n\n
El arn\u00e9s que sobrevive: m\u00ednimo ahora, m\u00e1s profundo despu\u00e9s<\/h2>\n\n\n