Pruebas de caja negra o caja blanca: ¿qué hace usted primero?

14

En un equipo muy pequeño, donde la prueba de la caja negra y la caja blanca es realizada por la misma persona, ¿qué debería hacer el examinador primero?

    
pregunta Pillar of Salt 17.12.2010 - 18:04

10 respuestas

11

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.

    
respondido por el Berin Loritsch 17.12.2010 - 18:20
5

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.

    
respondido por el Steven A. Lowe 17.12.2010 - 20:03
3

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.

    
respondido por el Walter 17.12.2010 - 18:20
2

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.

    
respondido por el Enrique 17.12.2010 - 18:21
2

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.

    
respondido por el Justin Ethier 17.12.2010 - 22:08
1

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.

    
respondido por el Alan 17.12.2010 - 18:34
1

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 :)

La prueba de

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

    
respondido por el Matthieu M. 20.12.2010 - 13:46
1

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).

    
respondido por el Ethel Evans 21.12.2010 - 20:09
0

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.

    
respondido por el Steven Evers 17.12.2010 - 19:13
0

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.

    
respondido por el Narayanan 20.12.2010 - 12:10

Lea otras preguntas en las etiquetas