Pregunta

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

  

La estrategia deseada sería reunir cada unidad de una en una, 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 agrega una pequeña cantidad de unidades, se genera una versión de prueba y " prueba de humo, " en donde se ejecutan una pequeña cantidad de pruebas para ganar confianza de que el producto integrado funcionará como se espera La intención no es probar a fondo la (s) nueva (s) unidad (es) ni realizar una prueba de regresión completa del sistema en general.

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

  

También es importante que la prueba de humo realice una comprobación rápida de todo el sistema, no solo de los nuevos componentes.

Nunca he visto " extenso " y " prueba de regresión " no se utilizaron juntos ni una prueba de regresión descrita como "prueba de regresión completa del sistema general". Se supone que las pruebas de regresión son lo más ligeras y rápidas posible. Y la definición de prueba de humo es lo que aprendí fue una prueba de regresión.

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

¿Fue útil?

Solución

Hay múltiples interpretaciones. Si solo está solucionando un error que afecta a una pequeña parte de su sistema, las pruebas de regresión podrían incluir solo un pequeño conjunto de pruebas que ejercen la clase o el paquete en cuestión. Si corrige un error o agrega 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.

El " si es posible que se rompa, pruébalo " La regla de oro se aplica aquí. Si un cambio en Foo podría afectar a Bar , ejecute las regresiones para ambos.

Las pruebas de regresión solo verifican si un cambio causó que una prueba pasada anteriormente fallara. Se pueden ejecutar en cualquier nivel (unidad, integración, sistema). Referencia .

Otros consejos

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

La regresión se usa generalmente para referirse a todo el conjunto de pruebas. Es lo último que hace un control de calidad antes de un lanzamiento. Se utiliza para mostrar que todo lo que solía trabajar todavía funciona, en la medida en que eso sea posible mostrar. En mi experiencia, generalmente es un conjunto de pruebas de todo el sistema, independientemente de lo pequeño que fue el cambio (aunque los cambios pequeños pueden no desencadenar una prueba de regresión).

Donde trabajo, las pruebas de regresión están estandarizadas para cada aplicación al final de cada lanzamiento. Están diseñados para 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 confirmar que cada tipo de validación se realiza (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é pasa si dejo el campo A en blanco?

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 la cantidad de defectos que surgen durante las pruebas. Esos dos no están necesariamente relacionados, pero lo notamos de manera bastante consistente.

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

  • las pruebas de unidad se escriben para probar las características cuando se crea el sistema
  • cuando se descubren errores, se escriben más pruebas unitarias para reproducir el error y verificar que se haya corregido
  • una prueba de regresión ejecuta todo el conjunto de pruebas y demuestra que todo sigue funcionando, incluido el hecho de que no han reaparecido errores antiguos [es decir, para probar que el código no ha "regresionado "]

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

Comienza con lo que estás tratando de lograr. Luego haz lo que debes hacer para lograr ese objetivo. Y luego usa buzzword bingo para asignar una palabra a lo que realmente haces. Al igual que todos los demás :-) La precisión no es tan importante.

  

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

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

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 las versiones X + 1, X + 2, etc. Con el tiempo, puede reducir el tiempo que llevan las pruebas de característica / regresión de características estables que no han sufrido regresiones. Si una característica sufre de muchas regresiones, puede ser beneficioso aumentar el énfasis en la característica.

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

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top