Lo que debe ser más correcto.

En serio, las pruebas de caja blanca (es decir, las pruebas de las partes internas del código) deberían realizarse con pruebas unitarias por el desarrollador que escribió el código. Las pruebas unitarias se acumularían con el tiempo y parte del proceso de compilación para que no desperdiciéramos el tiempo del probador deficiente con el código que sabemos que no funciona como debería. Las pruebas de unidad se vuelven más importantes cuanto más pequeño sea tu equipo, especialmente porque no tienes un ejército de evaluadores para eliminar los problemas.

Las pruebas de caja negra (es decir, las pruebas a través de la interfaz de usuario / sistema) suelen ser lo que hacen la mayoría de los evaluadores.

Todas las pruebas deben tener prioridad sobre la importancia de una función para el producto terminado. Si la misión es proporcionar una herramienta para hacer X y el producto no hace X, ese es un gran problema.

Negro

Pruebas de caja negra para verificar las características. Prueba de caja blanca según sea necesario si las cosas están rotas. Si todas las pruebas de caja negra pasan y la cobertura es buena, la prueba de caja blanca no es necesaria.

Caja negra.

Los componentes de la caja blanca son generalmente dependientes de los componentes de la caja negra, por lo que me gustaría probar la caja negra primero y luego pasar a la caja blanca.

Primero debes hacer pruebas de blanco pensando como programador / desarrollador para asegurarte de que las cosas funcionarán bien. Luego, realiza pruebas de caja negra, por lo general, tratando de pensar como si fuera el usuario final, sin pensar en la estructura interna del programa. A veces, debe pensar como un programador / desarrollador, incluso si está realizando una prueba de negro, ya que podría estar probando un módulo interno que fue escrito por otra persona y no tiene acceso al código.

Si desea tener un buen ciclo de prueba, debe tener diferentes personas haciendo Ambos :

• Un desarrollador que se enfoca principalmente en pruebas de caja blanca sabe qué ha cambiado recientemente en el código, qué áreas son más complejas (y por lo tanto es probable que se rompan), etc. Nuevos defectos.

• Por otro lado, un probador de control de calidad centrado en pruebas de caja negra puede abordar las pruebas más fácilmente como un usuario final. Sin ningún conocimiento interno del código, pueden adoptar un enfoque nuevo y no están sesgados por el conocimiento de cómo se implementan las diferentes partes de la solución. Cogerán errores que el desarrollador puede haber pasado por alto, o regresiones de cambios de código que rompieron accidentalmente otras áreas de la aplicación.

Para responder a su pregunta, la prueba de caja blanca debe hacerse primero. Pero realmente necesitas tener a otra persona haciendo la prueba de caja negra si quieres que sea efectiva.

Me gusta comenzar con las pruebas de caja negra, luego usar la información de cobertura de código o el depurador para averiguar qué estoy haciendo y analizar lo que está sucediendo.

Pero la respuesta real es depende . Es probable que me sumerja en el código antes (o incluso primero) si estoy haciendo pruebas de API, pero mucho más tarde si mi objetivo es ver algunos escenarios grandes de extremo a extremo.

Diría que Black Box prueba primero, simplemente porque como proponente de TDD, las pruebas se escriben antes de que el código (o cuadro) exista de todos modos :)

White Box (por lo que tengo entendido) es más útil en una mentalidad de depuración.

Pruebas de caja negra, porque está escribiendo pruebas antes de que exista el código. El evaluador debe estar desarrollando pruebas automáticas que consumen mucho tiempo en paralelo con el código de escritura del desarrollador para que sea eficiente en un equipo pequeño.

Si el código ya está escrito, sugeriría que dedique un poco de tiempo a esbozar la cobertura de la prueba desde un punto de vista de caja negra para asegurarse de tener tiempo de lluvia de ideas antes de saturar su cerebro con el código real. Sin embargo, luego puede cambiar a la casilla blanca y mirar el código antes de ir demasiado lejos junto con las pruebas reales para tener una idea de las áreas de riesgo y para priorizar aquellas pruebas que realizó con anterioridad (y aumentarlas con nuevas pruebas ideadas por mirando partes del código que parecen complicadas o cuestionables).

Ninguno. Intento escribir buenas pruebas utilizando mi BICEP correcto , teniendo en cuenta las condiciones de contorno CORRECTAS sin importar el orden en el que vienen a la mente. Esos son ambos acrónimos propuestos en Pragmatic Unit Testing .

Mi objetivo es centrarme en escribir buenas pruebas y no en qué color escribir primero.

Primero haz las pruebas de caja blanca .

En segundo lugar, vaya a las pruebas de caja negra

> Pruebas de caja negra

yo El probador debe verificar el funcionamiento de la aplicación, como el cuadro de texto, el botón de radio, el cuadro de lista, el botón de comando, ... etc. ,

II. El probador debe verificar que la aplicación no sea funcional, como el logotipo, la imagen, la ortografía, etc. etc.

III. El probador debe verificar todo el flujo de la aplicación.

Nota: Para comprobar condiciones positivas y negativas.