Plan de prueba de producto electrónico / scripts ... ¿cómo hacer para escribirlos?

Antes de comenzar a diseñar y durante el diseño, debería haber creado una serie de documentos, como la Especificación de requisitos del usuario (URS) y la Especificación de requisitos funcionales (FRS).

¡Todo lo que especifique tarde o temprano debe ser probado!

¿Por qué si no te tomas la molestia de escribirlo?
El URS debe estar de donde deriva el Manual del usuario, pero también la Especificación de prueba del usuario. Describa lo que espera que suceda cuando el usuario realice una acción, como presionar un botón, bajo qué circunstancias . Presionar el botón 1 puede causar una acción diferente dependiendo del estado del interruptor A.
Por lo tanto, describe las condiciones de inicio, las acciones, las condiciones finales esperadas . Para todas las acciones normales del usuario.

Entonces hay un uso involuntario. Organice una sesión de creatividad para descubrir tantas formas como sea posible de abusar del producto. Si sabes cómo llevar a cabo una lluvia de ideas, puedes usar eso. Los problemas pueden ir desde presionar varios botones simultáneamente hasta insertar las baterías de manera incorrecta. ¿Se puede insertar el tipo incorrecto de pilas? Nuevamente, describe condiciones de inicio, acciones, condiciones finales esperadas. Si no sabe cuál debería ser el resultado de una acción (incluso involuntaria), entonces se perdió algo durante el diseño.

Esto implica que la escritura de una Especificación de prueba (especialmente la parte sobre el uso no deseado) no debe hacerse justo antes de la prueba. El diseñador del software debe saber qué debe suceder si presiona dos botones al mismo tiempo antes de que comience a escribir el software. Recuerde que el costo de los cambios en un diseño aumenta exponencialmente con el tiempo.

Por supuesto, se permite el fallo del dispositivo en ciertas condiciones. Es posible que no tenga protección contra la inserción incorrecta de las baterías y sabe que el dispositivo se dañará si el usuario lo hace. (No es una buena idea IMO, solo un ejemplo). Además, esto debe describirse en una especificación funcional, para demostrar que no lo ha pasado por alto. Incluso lo mencionaría en la especificación de prueba con el comentario "prueba no requerida".

Debería ser obvio que presionar dos botones simultáneamente no debería bloquear el software. Pero no digas que es imposible. El diseñador de software debe poder mostrar en su código cómo se ocupa de esto. Lo cual es incluso mejor que solo intentarlo. Durante la prueba, se puede presionar un botón un poco más tarde que el otro.

La mejor manera de probar el firmware y el diseño del hardware es conectar todo el circuito a algo como un Arduino. El Arduino aplicaría varias entradas al juguete y mediría las salidas. Esto incluso se puede usar para pruebas por pieza.

Si tengo suficiente FLASH, a menudo escribo pruebas de firmware en el firmware. En algunos casos, es posible hacer que el firmware haga algunas pruebas en el hardware también. Por ejemplo, podría probar que los pines del microcontrolador están funcionando al intentar pulsarlos muy alto y bajo muy brevemente, y probar si lo hicieron.

Hacer esto crea una prueba mucho más exhaustiva del hardware, y lo bueno es que no cuesta nada por cada parte. (excepto posiblemente por el FLASH adicional requerido)

El firmware también contendría algunas pruebas de funciones básicas que son fáciles de equivocar: la escritura a mano firmada de 32 bits se multiplica en un MCU de 8 bits, por ejemplo.

También contendría aserciones de tiempo de compilación para verificar que los enteros tengan el tamaño correcto.

Al hacer todo esto, con frecuencia se detectaron errores de inmediato y me ahorraron muchos días de depuración. También puede detectar hardware defectuoso o dañado por ESD.