Creo que esto depende del contexto. ¿Terminó de implementar las especificaciones en su mayoría y desea comenzar su prueba final o está hablando generalmente en cualquier momento durante el ciclo de desarrollo? Como algunos mencionan en las respuestas, sus implementadores generalmente escribirán pruebas unitarias que pueden considerarse parte de su prueba de caja blanca, ya que estos codificadores entienden el funcionamiento interno y desean afirmar la funcionalidad de su implementación antes de comprometerse.
Chris
Respuestas:
11
Lo que sea más correcto.
En serio, las pruebas de caja blanca (es decir, probar las partes internas del código) deberían hacerse idealmente con pruebas unitarias por el desarrollador que escribió el código. Las pruebas unitarias se construirían con el tiempo, y parte del proceso de construcción para que no perdamos el tiempo del pobre probador con un código que sabemos que no funciona como debería. Las pruebas unitarias se vuelven más importantes cuanto más pequeño sea su equipo, especialmente porque no tiene un ejército de evaluadores para deshacerse de 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.
Es necesario priorizar todas las pruebas 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.
Bien dicho, la mejor respuesta que he leído hasta ahora.
Chris
5
Negro
Prueba 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 es innecesaria.
A menos que, por supuesto, las pruebas de la caja negra no se hayan probado una pieza clave de funcionalidad o configuración:}
Alan
3
@Alan: el mismo argumento se aplica a las pruebas de caja blanca, de ahí la advertencia de 'la cobertura es buena'
Steven A. Lowe
1
De acuerdo: supongo que mi declaración depende de su definición de buena cobertura.
Alan
1
@DocBrown No veo absolutamente cómo lo que explicaste es algo remotamente como las pruebas de whitebox. La prueba de Whitebox consiste en seguir las rutas de ramificación de una implementación determinada y escribir casos de prueba que ejerciten todas las rutas. Si aún no tiene una implementación, no puede, por definición, realizar pruebas de whitebox. Con TDD y BDD escribes pruebas de la forma general dada cuando-entonces. Configura los datos de entrada o el estado precondicional, dispara la unidad y realiza comprobaciones en los datos de salida o finaliza el estado o las llamadas de terceros. Esta es la definición de prueba de blackbox.
Sammi
1
@SamJudge: según tengo entendido, cuando miras dentro del código de implementación y usas esa información para diseñar datos de prueba muy específicos (que luego se pasan a través de la interfaz pública), entonces se justifica llamar a esta prueba de caja blanca. Tal prueba también falla si el resultado no es lo que uno espera. Si luego mira solo la prueba, es posible que no pueda decir claramente "esta prueba fue producida por un enfoque de caja blanca (o caja negra)", por supuesto.
Doc Brown
3
Caja negra.
Los componentes del cuadro blanco generalmente dependen de los componentes del cuadro negro, por lo que me gustaría probar primero el cuadro negro y luego pasar al cuadro blanco.
No estoy seguro de lo que entendemos por "componentes de la caja negra" y "componentes de caja blanca" - me they'r sólo "componentes" (que se puede probar con o sin el conocimiento del código subyacente o arquitectura.
Alan
No entiendo la relación "dependiente" que sugieres aquí. El blanco negro y el cuadro negro no son componentes, más bien un estilo de probar cualquier componente como Alan menciona. La diferencia está en el enfoque adoptado para probar el componente en cuestión.
Chris
2
Primero realiza pruebas en blanco pensando como codificador / desarrollador para asegurarse de que las cosas funcionen bien. Luego haces pruebas de recuadro negro, generalmente tratando de pensar como si fueras el usuario final, sin pensar en la estructura interna del programa. A veces, debe pensar como un programador / desarrollador, incluso si está haciendo una prueba negra porque 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 centrado principalmente en las 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. y puede enfocar los esfuerzos de manera apropiada en estas áreas con mayor probabilidad de introducir nuevos defectos.
Por otro lado, un probador de control de calidad centrado en las pruebas de caja negra puede acercarse más fácilmente a las pruebas como un usuario final. Sin ningún conocimiento interno del código, pueden adoptar un nuevo enfoque y no están sesgados por el conocimiento de cómo se implementan las diferentes partes de la solución. Detectarán errores que el desarrollador pudo haber pasado por alto o regresiones de cambios en el código que accidentalmente rompieron otras áreas de la aplicación.
Para responder a su pregunta, la prueba de caja blanca debe hacerse primero. Pero realmente necesita que una persona diferente haga la prueba de caja negra si desea que sea efectiva.
Me gusta comenzar con las pruebas de recuadro negro, luego usar la información de cobertura del código o el depurador para descubrir lo que estoy haciendo y analizar lo que está sucediendo.
Pero la verdadera respuesta es que 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 mirar algunos escenarios grandes de extremo a extremo.
Diría que Black Box prueba primero, simplemente porque como defensor de TDD, las pruebas se escriben antes de que el código (o caja) exista de todos modos :)
La prueba de White Box (hasta donde yo entiendo) es más útil en una mentalidad de depuración.
-1, TDD es una prueba de caja blanca. En TDD es esencial saber qué hace el código involucrado en la prueba (y qué no hace) para escribir la próxima prueba. La prueba de caja negra significa que alguien que no tiene idea del código (un probador, alguien que ni siquiera necesita saber cómo codificar), diseña las pruebas.
Doc Brown
1
Entonces no practicamos TDD de la misma manera. TDD para mí se trata de hacer cumplir las especificaciones de una clase / función: las pruebas se escriben para verificar que la clase / función se comporta como se especifica, pero no importa cómo se comporta el código detrás de escena, siempre y cuando se cumplan esas especificaciones ... lo cual es necesario dado que las pruebas se escriben antes de la funcionalidad.
Matthieu M.
1
Prueba de caja negra, porque está escribiendo pruebas antes de que exista el código. El probador necesita desarrollar pruebas automáticas que consuman mucho tiempo en paralelo con el código de escritura del desarrollador para ser eficiente en un equipo pequeño.
Si el código ya está escrito, te sugiero que pases un tiempo dibujando la cobertura de la prueba desde un punto de vista de recuadro negro para asegurarte de tener algo de lluvia de ideas antes de saturar tu cerebro con el código real. Sin embargo, puede cambiar a la casilla blanca y mirar el código antes de llegar demasiado lejos con las pruebas reales para tener una idea de las áreas de riesgo y priorizar esas pruebas que hizo una lluvia de ideas antes (y aumentarlas con nuevas pruebas pensadas por mirando partes del código que parecen complicadas o cuestionables).
Ninguno. Trato de escribir buenas pruebas usando mi BICEP derecho , teniendo en cuenta las condiciones de contorno CORRECTAS sin importar el orden en que se me ocurran. Esos son los dos acrónimos propuestos en Pragmatic Unit Testing .
Mi objetivo es concentrarme en escribir buenas pruebas y no en qué color escribir primero.
'Blanco' y 'negro' no son términos de prueba de unidad, por lo que, por supuesto, no te preocupas por eso. Las pruebas unitarias son caja blanca de facto.
Ethel Evans
@Ethel Evans: No son pruebas de caja blanca por definición. La gran mayoría de las pruebas unitarias son pruebas de caja blanca, pero no es un requisito. Cualquier prueba que asigne el dominio de entradas al rango de salidas de una función son pruebas unitarias, pero no necesita conocer los detalles de la implementación.
Steven Evers
0
Primero haz la prueba de caja blanca .
Segundo ir para la prueba de caja negra.
> Prueba de caja negra
I. El probador debe verificar el funcionamiento de la aplicación, como cuadro de texto, botón de radio, cuadro de lista, botón de comando, ... etc.
II El probador debe verificar el funcionamiento no funcional de la aplicación, como el logotipo, la imagen, la ortografía, etc., etc.
III. El probador debe verificar todo el flujo de la aplicación.
Nota: Para verificar las condiciones positivas y negativas.
Respuestas:
Lo que sea más correcto.
En serio, las pruebas de caja blanca (es decir, probar las partes internas del código) deberían hacerse idealmente con pruebas unitarias por el desarrollador que escribió el código. Las pruebas unitarias se construirían con el tiempo, y parte del proceso de construcción para que no perdamos el tiempo del pobre probador con un código que sabemos que no funciona como debería. Las pruebas unitarias se vuelven más importantes cuanto más pequeño sea su equipo, especialmente porque no tiene un ejército de evaluadores para deshacerse de 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.
Es necesario priorizar todas las pruebas 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.
fuente
Negro
Prueba 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 es innecesaria.
fuente
Caja negra.
Los componentes del cuadro blanco generalmente dependen de los componentes del cuadro negro, por lo que me gustaría probar primero el cuadro negro y luego pasar al cuadro blanco.
fuente
Primero realiza pruebas en blanco pensando como codificador / desarrollador para asegurarse de que las cosas funcionen bien. Luego haces pruebas de recuadro negro, generalmente tratando de pensar como si fueras el usuario final, sin pensar en la estructura interna del programa. A veces, debe pensar como un programador / desarrollador, incluso si está haciendo una prueba negra porque podría estar probando un módulo interno que fue escrito por otra persona y no tiene acceso al código.
fuente
Si desea tener un buen ciclo de prueba, debe tener diferentes personas haciendo ambos :
Un desarrollador centrado principalmente en las 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. y puede enfocar los esfuerzos de manera apropiada en estas áreas con mayor probabilidad de introducir nuevos defectos.
Por otro lado, un probador de control de calidad centrado en las pruebas de caja negra puede acercarse más fácilmente a las pruebas como un usuario final. Sin ningún conocimiento interno del código, pueden adoptar un nuevo enfoque y no están sesgados por el conocimiento de cómo se implementan las diferentes partes de la solución. Detectarán errores que el desarrollador pudo haber pasado por alto o regresiones de cambios en el código que accidentalmente rompieron otras áreas de la aplicación.
Para responder a su pregunta, la prueba de caja blanca debe hacerse primero. Pero realmente necesita que una persona diferente haga la prueba de caja negra si desea que sea efectiva.
fuente
Me gusta comenzar con las pruebas de recuadro negro, luego usar la información de cobertura del código o el depurador para descubrir lo que estoy haciendo y analizar lo que está sucediendo.
Pero la verdadera respuesta es que 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 mirar algunos escenarios grandes de extremo a extremo.
fuente
Diría que Black Box prueba primero, simplemente porque como defensor de TDD, las pruebas se escriben antes de que el código (o caja) exista de todos modos :)
La prueba de White Box (hasta donde yo entiendo) es más útil en una mentalidad de depuración.
fuente
Prueba de caja negra, porque está escribiendo pruebas antes de que exista el código. El probador necesita desarrollar pruebas automáticas que consuman mucho tiempo en paralelo con el código de escritura del desarrollador para ser eficiente en un equipo pequeño.
Si el código ya está escrito, te sugiero que pases un tiempo dibujando la cobertura de la prueba desde un punto de vista de recuadro negro para asegurarte de tener algo de lluvia de ideas antes de saturar tu cerebro con el código real. Sin embargo, puede cambiar a la casilla blanca y mirar el código antes de llegar demasiado lejos con las pruebas reales para tener una idea de las áreas de riesgo y priorizar esas pruebas que hizo una lluvia de ideas antes (y aumentarlas con nuevas pruebas pensadas por mirando partes del código que parecen complicadas o cuestionables).
fuente
Ninguno. Trato de escribir buenas pruebas usando mi BICEP derecho , teniendo en cuenta las condiciones de contorno CORRECTAS sin importar el orden en que se me ocurran. Esos son los dos acrónimos propuestos en Pragmatic Unit Testing .
Mi objetivo es concentrarme en escribir buenas pruebas y no en qué color escribir primero.
fuente
Primero haz la prueba de caja blanca .
Segundo ir para la prueba de caja negra.
> Prueba de caja negra
I. El probador debe verificar el funcionamiento de la aplicación, como cuadro de texto, botón de radio, cuadro de lista, botón de comando, ... etc.
II El probador debe verificar el funcionamiento no funcional de la aplicación, como el logotipo, la imagen, la ortografía, etc., etc.
III. El probador debe verificar todo el flujo de la aplicación.
Nota: Para verificar las condiciones positivas y negativas.
fuente