¿Las pruebas de regresión son el conjunto de pruebas completo o una muestra de pruebas?

Question

Me enseñaron que una prueba de regresión era una muestra pequeña (lo suficiente para demostrar que no se rompió nada con la introducción de un cambio o nuevos módulos) de las pruebas generales. Sin embargo, this article por Ron Morrison y Grady Booch me hace pensar de manera diferente:

La estrategia deseada sería traer cada unidad en uno a la vez, realizar una prueba de regresión extensa, corregir cualquier defecto y luego pasar a la siguiente unidad.

El mismo documento también dice:

Tan pronto como se añade un pequeño número de unidades, se genera una versión de prueba y "a prueba de humo", en el que un pequeño número de pruebas se ejecutan para ganar confianza de que el producto integrado funcionará como se espera. La intención no es probar minuciosamente la (s) nueva (s) unidad (es) ni realizar una prueba de regresión completa del sistema en general.

Al describir pruebas de humo, los autores dicen que esto:

También es importante que la prueba de humo realizar una comprobación rápida de todo el sistema, no sólo el nuevo componente (s).

Nunca he visto "extensa" y "prueba de regresión" juntas ni una prueba de regresión descrita como "prueba de regresión completa del sistema en general". Se supone que las pruebas de regresión son lo más ligeras y rápidas posibles. Y la definición de prueba de humo es lo que aprendí que era una prueba de regresión.

¿He entendido mal lo que me enseñaron? ¿Me enseñaron incorrectamente? ¿O hay múltiples interpretaciones de "prueba de regresión"?

Answer 1

Hay varias interpretaciones. Si solo está solucionando un error que afecta una pequeña parte de su sistema, entonces las pruebas de regresión pueden incluir solo un pequeño conjunto de pruebas que ejercitan la clase o paquete en cuestión. Si está solucionando un error o agregando una función que tiene un alcance más amplio, entonces sus pruebas de regresión también deberían tener un alcance más amplio.

Aquí se aplica la regla empírica "si podría romperse, pruébelo". Si un cambio en Foo puede afectar Bar, ejecute las regresiones para ambos.

Las pruebas de regresión solo comprueban si un cambio hizo que fallara una prueba previamente aprobada. Se pueden ejecutar en cualquier nivel (unidad, integración, sistema). Reference.

Answer 2

La regresión se utiliza generalmente para hacer referencia a todo el conjunto de pruebas. Es lo último que hace QA antes de un lanzamiento. Se usa para mostrar que todo lo que solía funcionar sigue funcionando, en la medida en que sea posible mostrarlo. En mi experiencia, generalmente es un conjunto de pruebas de todo el sistema, independientemente de cuán pequeño sea el cambio (aunque pequeños cambios pueden no desencadenar una prueba de regresión).

Answer 3

Donde trabajo, las pruebas de regresión se estandarizan para cada aplicación al final de cada lanzamiento. Están destinados a probar toda la funcionalidad, pero no están diseñados para detectar errores sutiles. Entonces, si tiene un formulario que tiene varios tipos de validación, por ejemplo, un conjunto de regresión para ese formulario sería para confirmar que se realiza cada tipo de validación (nivel de campo y nivel de formulario) y que se puede enviar la información correcta . No está diseñado para cubrir todos los casos (es decir, ¿qué sucede si dejo el campo A en blanco? ¿Qué hay del campo B?solo probará uno de ellos y asumirá que los demás funcionan).

Sin embargo, en el proyecto actual en el que estoy trabajando, las pruebas de regresión son mucho más exhaustivas, y hemos notado una reducción en el número de defectos que surgen durante la prueba. Esos dos no están necesariamente relacionados, pero lo notamos de manera bastante consistente.

Answer 4

mi comprensión del término 'pruebas de regresión' es:

• pruebas unitarias se escriben para probar características cuando se crea el sistema de
• cuando se descubren errores, más pruebas de unidad se escriben en reproducir el error y verifique que se haya corregido
• una prueba de regresión ejecuta todo el conjunto de pruebas que prueban que todo funciona, incluso que no han reaparecido errores antiguos [es decir, para demostrar que el código no ha "retrocedido")

En la práctica, es mejor ejecutar siempre todas las pruebas de unidad existentes cuando se realizan cambios. la única vez que me molestaría con un subconjunto de pruebas es cuando el conjunto de pruebas de la unidad completa tarda "demasiado" en ejecutarse [donde "demasiado tiempo" es bastante subjetivo]

Answer 5

Comience con lo que está tratando de lograr. Luego haz lo que necesites para lograr ese objetivo. Y luego usa el bingo de palabra de moda para asignar una palabra a lo que realmente haces. Como todos los demás :-) La precisión no es tan importante.

Answer 6

... prueba de regresión fue una pequeña (sólo lo suficiente para demostrar que no se rompe nada con la introducción de un cambio o nuevos módulos) de la muestra de las pruebas globales

Si una pequeña muestra de pruebas es suficiente para demostrar que el sistema funciona, ¿por qué el resto de las pruebas incluso existen? Y si cree que sabe que su cambio solo afectó un subconjunto de la funcionalidad, ¿por qué necesita probar algo después de realizar el cambio? Los humanos son falibles, nadie sabe realmente si cambiar algo rompe algo más. OMI, si sus pruebas son automáticas, vuelva a ejecutarlas todas. Y si no están automatizados, automatízalos. Mientras tanto, vuelva a ejecutar lo que sea que esté automatizado.

Answer 7

En general, un subconjunto de las pruebas de características para la nueva característica introducida en la versión X de un producto se convierte en la base de las pruebas de regresión para la versión X + 1, X + 2, y así sucesivamente. Con el tiempo, puede reducir el tiempo empleado por las pruebas de función/regresión de funciones estables que no han sufrido regresiones. Si una característica sufre de muchas regresiones, entonces puede ser beneficioso aumentar el énfasis en la característica.

Creo que el artículo que se refiere a la "prueba de regresión extensa" significa ejecutar un extenso conjunto de pruebas de regresión (individualmente simples).

Answer 8

Siempre tomé las pruebas de regresión para referirme a cualquier prueba cuyo propósito fuera asegurar que la funcionalidad existente no se rompa por nuevos cambios. Eso no implicaría ninguna restricción en el tamaño del conjunto de pruebas.