Las categorías generales en mi opinión serían:
Prueba de caja negra . No puede ver el código y solo está probando a ciegas hasta cierto punto, ya que lo que está en la aplicación o el sistema está oculto para usted. Por lo tanto, en este caso, las personas no conocen todos los casos de error y tienen que adivinar con varias condiciones de contorno que pueden o no ser obvias para encontrar todos los casos.
Prueba de caja blanca . Puede ver el código y puede verificar qué rutas de código se están utilizando para que la cobertura del código pueda usarse como una métrica para garantizar que toda la lógica se esté utilizando en el sistema. La idea aquí es saber cómo se ve el código para ayudar a guiar las pruebas para que no sea tan misterioso como las pruebas de caja negra.
La prueba de caja gris es un híbrido de los dos anteriores.
Los casos límite tienden a ser algo que se puede ver en las pruebas de recuadro blanco, ya que hay varias condiciones para ver en el código en el que se escriben las pruebas, por ejemplo, si tuvo un programa que solicita un número y alguien ingresa X cómo se maneja esto debería verse en algún lugar del código.
Las clasificaciones generales de las pruebas serían:
Pruebas unitarias . Estas son generalmente las pruebas más pequeñas que prueban algo bastante específico, por ejemplo, ¿este método maneja este caso límite? Tenga en cuenta que la inyección de dependencia puede usarse aquí para casos que involucran objetos simulados para reducir cualquier dependencia para las pruebas.
Pruebas de integración . Estas son pruebas en las que se conectan un par de componentes y se ejecutan pruebas para garantizar que los componentes funcionen bien juntos. Tenga en cuenta que si bien las pruebas unitarias pueden funcionar de forma independiente, aquí es donde se realiza la prueba de qué tan bien se combinan las cosas, ya que puede haber una falta de comunicación entre las capas que hacen que estas pruebas sean útiles para atrapar varias trampas. El término Pruebas de extremo a extremo se utiliza para pruebas de integración en las que se prueba una cadena completa de componentes desde "un punto final de la aplicación a otro" (lo que sea que eso signifique).
Pruebas de regresión . Estas serían pruebas realizadas en el pasado que se vuelven a hacer para garantizar que lo que se solucionó se mantenga fijo y que los errores no se reintroduzcan en el código.
Pruebas de usabilidad . Estas serían pruebas realizadas para ver qué tan bien pueden los usuarios finales trabajar con el software para completar varias tareas. ¿Dónde se podría automatizar algo para hacer algo más rápido o ajustar la interfaz de usuario para que algo sea más fácil de usar?
Pruebas de aceptación del usuario . Estas serían pruebas realizadas por los usuarios finales para que puedan ver de primera mano cómo funciona algo y estar de acuerdo en que el software satisface las necesidades comerciales que lo solicitaron en primer lugar.
Las pruebas funcionales son todo tipo de pruebas basadas en la especificación funcional del software bajo prueba. Estas son siempre pruebas de caja negra.
Pruebas de rendimiento. Estas serían pruebas realizadas para garantizar que un sistema pueda manejar una cierta cantidad de carga sin ser demasiado lento. Por ejemplo, probar una nueva granja de servidores web podría manejar a 100 usuarios que acceden a un sitio al mismo tiempo sería un ejemplo de una prueba de rendimiento. Estos también pueden denominarse "pruebas de carga" o "pruebas de esfuerzo", ya que generalmente la idea aquí es llevar el sistema a su límite o verificar que el sistema puede manejar alguna proyección de otro departamento. La razón de estas pruebas es que, a menudo, existen numerosos ajustes de configuración para optimizar que pueden tomar más que un poco de trabajo para descubrir cuellos de botella y resolver problemas con esto. El cuello de botella aquí podría ser memoria, E / S, CPU o ancho de banda de red que hace que el sistema no responda tan bien como se esperaba.
Test Driven Development es una metodología y no se refiere a un tipo específico de prueba, sino que las pruebas se escriben antes del código para que las pruebas sean lo que impulsa el desarrollo en lugar del comportamiento , el dominio o la característica que son otros ejemplos en términos de proceso.
La integración continua es una práctica de ejecutar algunas pruebas, como pruebas de unidad, integración y regresión regularmente, de modo que si un cambio rompe una prueba, esto se detecte lo antes posible.