¿Qué son las pruebas unitarias, las pruebas de integración, las pruebas de humo y las pruebas de regresión?

732

¿Qué son las pruebas unitarias, las pruebas de integración, las pruebas de humo y las pruebas de regresión? ¿Cuáles son las diferencias entre ellos y qué herramientas puedo usar para cada uno de ellos?

Por ejemplo, uso JUnit y NUnit para pruebas unitarias y pruebas de integración . ¿Hay alguna herramienta para los dos últimos, pruebas de humo o pruebas de regresión ?

caltuntas
fuente
2
Relacionado: stackoverflow.com/questions/437897/…
Bill the Lizard
2
Otros ya han respondido bien, pero me gustaría agregar que personalmente creo que la Prueba de humo y la Prueba de regresión son redundantes. Hacen lo mismo: realizan pruebas para asegurarse de que los cambios en el sistema no rompan nada.
Randolpho
15
Creo que son bastante diferentes a las pruebas de regresión. Creo que son pruebas rápidas deliberadamente 'ligeras' que se ejecutan al principio para ahorrar tiempo porque si alguna de estas falla, entonces sabes que no vale la pena molestarse con ninguna prueba adicional. p. ej., ¿puede el cliente conectarse a la base de datos, está instalado .net, está instalada la versión correcta? pruebas de implementación de humo.
AndyM
Las pruebas de humo son como las describe AndyM. Pero también son un tipo de prueba de regresión.
kevin mcdonnell
2
Relacionado: stackoverflow.com/questions/4904096/…
rogerdpack

Respuestas:

1044
  • Prueba unitaria : especifique y pruebe un punto del contrato del método único de una clase. Esto debería tener un alcance muy estrecho y bien definido. Las dependencias e interacciones complejas con el mundo exterior se topan o se burlan .

  • Prueba de integración : pruebe la correcta interacción de múltiples subsistemas. Hay un espectro completo allí, desde probar la integración entre dos clases, hasta probar la integración con el entorno de producción.

  • Prueba de humo (también conocido como verificación de cordura ) : una prueba de integración simple en la que simplemente verificamos que cuando se invoca el sistema bajo prueba, vuelve normalmente y no explota.

    • La prueba de humo es a la vez una analogía con la electrónica, donde la primera prueba se produce al encender un circuito (si fuma, ¡es malo!) ...
    • ... y, aparentemente , con plomería , donde un sistema de tuberías se llena literalmente de humo y luego se comprueba visualmente. Si algo fuma, el sistema tiene fugas.
  • Prueba de regresión : una prueba que se escribió cuando se solucionó un error. Asegura que este error específico no vuelva a ocurrir. El nombre completo es "prueba de no regresión". También puede ser una prueba realizada antes de cambiar una aplicación para asegurarse de que la aplicación proporcione el mismo resultado.

A esto, agregaré:

  • Prueba de aceptación : compruebe que una característica o caso de uso se implementa correctamente. Es similar a una prueba de integración, pero con un enfoque en el caso de uso para proporcionar en lugar de los componentes involucrados.

  • Prueba del sistema : prueba un sistema como un cuadro negro. Las dependencias en otros sistemas a menudo se burlan o se tropezan durante la prueba (de lo contrario, sería más una prueba de integración).

  • Comprobación previa al vuelo : pruebas que se repiten en un entorno similar a la producción, para aliviar el síndrome de "construcciones en mi máquina". A menudo, esto se logra haciendo una prueba de aceptación o humo en un entorno similar a la producción.

ddaa
fuente
250
Las pruebas de humo son anteriores a la electrónica en un siglo y provienen de la plomería, cuando un sistema de tuberías se llenó con un humo real y luego se verificó visualmente. Si fumaba, tenía fugas.
SnakE
2
Las pruebas de regresión también se utilizan para cambios de características, no solo para la corrección de errores. La respuesta de Nikita a continuación es una definición más completa.
BobRodes
25
@AndyM El fondo de la 'Prueba de humo' es inexacto. IIRC proviene de la plomería, donde se bombea humo en el sistema de tuberías después de su construcción (y antes de que se conecte al suministro de agua). Si sale humo, las tuberías no están correctamente selladas. Esto es menos dañino que dejar que el agua fluya y ver si hay charcos (posiblemente dañando paredes / mampostería en el proceso). Es una aproximación grosera que el sistema no fallará catastróficamente. Un proceso de desarrollo puede ser: ¿"Build" pasado? => "Prueba de humo" aprobada? => "Prueba de aceptación" pasada => al equipo de control de calidad para realizar pruebas detalladas.
Cristian Diaconescu
44
¿Creo que cometió un error al afirmar que una "Prueba de regresión" realmente es la abreviatura de "Prueba de no regresión"? Soy escéptico, en parte porque eso es poco intuitivo y confuso (aunque hay muchos términos), pero también Wikipedia tiene dos artículos separados sobre pruebas de regresión y no regresión. El artículo sobre las pruebas de regresión incluso dice: Contraste con las pruebas de no regresión ... cuyo objetivo es verificar si, después de introducir o actualizar una aplicación de software determinada, el cambio ha tenido el efecto deseado.
Brian C
2
@ddaa Las pruebas de cordura y las pruebas de humo no son lo mismo. Las pruebas de cordura se realizan después de que la compilación haya eliminado la prueba de humo y haya sido aceptada por el equipo de control de calidad para realizar más pruebas, las pruebas de cordura comprueban la funcionalidad principal con detalles más precisos.
Bharat
105
  • Prueba unitaria : una prueba automática para evaluar el funcionamiento interno de una clase. Debe ser una prueba independiente que no esté relacionada con otros recursos.
  • Prueba de integración : una prueba automática que se realiza en un entorno, muy similar a las pruebas unitarias pero con recursos externos (db, acceso al disco)
  • Prueba de regresión : después de implementar nuevas características o correcciones de errores, vuelve a probar escenarios que funcionaron en el pasado. Aquí cubre la posibilidad de que sus nuevas funciones rompan las funciones existentes.
  • Pruebas de humo : primeras pruebas en las que los evaluadores pueden concluir si continuarán las pruebas.
Gerrie Schenck
fuente
2
La definición de la prueba de regresión no es exactamente como es. @ddaa lo define correctamente.
Robert Koritnik
La definición de prueba de integración es definitivamente difusa. Por ejemplo, en la respuesta aquí stackoverflow.com/a/4904533/32453 se define más como probar múltiples interacciones de su código, no necesariamente necesita un DB (recurso externo) real ... aunque algunas personas lo definen de la manera que usted lo ha descrito ... ahh terminología. (Prefiero la definición anterior, FWIW, que prueba múltiples interacciones.)
rogerdpack
Por favor vea mi pregunta: stackoverflow.com/questions/61711739/…
milad salimi
Eso responde al título, pero no al de herramientas para los dos últimos tipos de pruebas, para pruebas de humo o pruebas de regresión .
Peter Mortensen
90

Todos tendrán definiciones ligeramente diferentes, y a menudo hay áreas grises. Sin embargo:

  • Prueba unitaria: ¿funciona esto un poquito (lo más aislado posible)?
  • Prueba de integración: ¿estos dos (o más) componentes funcionan juntos?
  • Prueba de humo: ¿todo este sistema (tan cerca de ser un sistema de producción como sea posible) se mantiene razonablemente bien? (es decir, ¿estamos razonablemente seguros de que no creará un agujero negro?)
  • Prueba de regresión: ¿hemos reintroducido inadvertidamente algún error que hayamos solucionado anteriormente?
Jon Skeet
fuente
¿Cómo coloca sus pruebas de integración con respecto a las pruebas unitarias? Si myprj es el directorio principal del proyecto y mypkgestá ubicado debajo myprj, tengo las pruebas unitarias ubicadas debajo myprj/tests/test_module1.pyy mi paquete ubicado debajo myprj/mypkg. Esto funciona muy bien para las pruebas unitarias, pero me pregunto si hay alguna convención, ¿debería seguir dónde deberían residir las pruebas de integración?
alpha_989
1
@ alpha_989: No sé cuál sería la convención para Python. En .NET actualmente tengo el código de producción, las pruebas unitarias y las pruebas de integración en tres proyectos separados, iguales entre sí, pero también hay muchas alternativas.
Jon Skeet
OK gracias. Podría encontrar una recomendación estándar que no sea mirar otro proyecto de Python. pero seguiré el tuyo ..
alpha_989
Por favor vea mi pregunta: stackoverflow.com/questions/61711739/…
milad salimi
@miladsalimi: No agregue comentarios no relacionados solo para llamar la atención sobre otra pregunta. Veo que lo has hecho en otras cuatro publicaciones, por favor no lo hagas.
Jon Skeet
51

Una nueva categoría de prueba de la que acabo de darme cuenta es la prueba canaria . Una prueba canaria es una prueba automatizada y no destructiva que se ejecuta de forma regular en un entorno en vivo , de modo que si alguna vez falla, algo realmente malo ha sucedido.

Los ejemplos pueden ser:

  • ¿Los datos que solo deberían estar disponibles en desarrollo / testy aparecieron en vivo ?
  • ¿Ha fallado la ejecución de un proceso en segundo plano?
  • ¿Puede un usuario iniciar sesión?
AndyM
fuente
2
¿Se puede hacer ping al sitio? De manera adecuada, existe un servicio llamado Binary Canary.
Dan Dascalescu
15
El nombre proviene de la minería del carbón: lleve al canario con usted "abajo". Cuando se apaga, sal rápido. Los canarios son muy sensibles a pequeñas concentraciones de gases nocivos y morirían antes de que los niveles de concentración se volvieran tóxicos para los humanos. Si falla una prueba de Canary, corríjala rápidamente porque solo será cuestión de tiempo antes de que LIVE falle.
Robino
1
La forma en que usamos las pruebas de Canary en mi trabajo es cambiar primero a algunos clientes a una nueva versión, en lugar de a todos a la vez. Si los primeros clientes sobreviven, podemos agregar el resto. Esos primeros son los canarios.
00prometheus
2
@ 00prometheus, eso es una prueba beta.
GregNash
1
@HarveyLin, aunque una prueba de Canary es necesariamente una prueba que previene el desastre, por supuesto, no solo se usa de esta manera. Pero la regla general es "probar que esto está funcionando porque ES crítico". Por supuesto, cada prueba tiene casi este mismo objetivo, pero el concepto es muy específico. En su caso, no consideraría todas las pruebas como canarias.
Charles Roberto Canato
12

Respuesta de uno de los mejores sitios web para técnicas de prueba de software:

Tipos de pruebas de software: lista completa, haga clic aquí

Ingrese la descripción de la imagen aquí

Es una descripción bastante larga, y no voy a pegarla aquí: pero puede ser útil para alguien que quiera conocer todas las técnicas de prueba.

Kaleem Ullah
fuente
10

Prueba unitaria: Verificación de ese componente particular (es decir, clase) creado o modificado funciones según lo diseñado. Esta prueba puede ser manual o automatizada, pero no se mueve más allá del límite del componente.

Prueba de integración: Verificación de que la interacción de componentes particulares funciona según lo diseñado. Las pruebas de integración se pueden realizar a nivel de unidad o a nivel de sistema. Estas pruebas pueden ser manuales o automatizadas.

Prueba de regresión: Verificación de que no se introducen nuevos defectos en el código existente. Estas pruebas pueden ser manuales o automatizadas.

Dependiendo de su SDLC ( cascada , RUP , ágil , etc.), se pueden realizar pruebas particulares en 'fases' o se pueden realizar todas, más o menos, al mismo tiempo. Por ejemplo, las pruebas unitarias pueden limitarse a los desarrolladores que luego entregan el código a los probadores para pruebas de integración y regresión. Sin embargo, otro enfoque podría hacer que los desarrolladores realicen pruebas unitarias y algún nivel de pruebas de integración y regresión (usando un enfoque TDD junto con integración continua y pruebas unitarias y de regresión automatizadas).

El conjunto de herramientas dependerá en gran medida de la base de código, pero hay muchas herramientas de código abierto para pruebas unitarias (JUnit). HP (Mercury) QTP o Borland's Silk Test son herramientas para la integración automatizada y las pruebas de regresión.

rdrex
fuente
Esta es una de las pocas respuestas que incluye algo sobre herramientas.
Peter Mortensen
8

Prueba unitaria : la prueba de un módulo individual o componente independiente en una aplicación se conoce como prueba unitaria. La prueba unitaria será realizada por el desarrollador.

Prueba de integración : combina todos los módulos y prueba la aplicación para verificar que la comunicación y el flujo de datos entre los módulos funcionan correctamente o no. Esta prueba también la realizan los desarrolladores.

Prueba de humo En una prueba de humo verifican la aplicación de manera superficial y amplia. En las pruebas de humo verifican la funcionalidad principal de la aplicación. Si hay algún problema de bloqueo en la aplicación, informarán al equipo desarrollador, y el equipo desarrollador lo solucionará y rectificará el defecto, y lo devolverá al equipo de prueba. Ahora el equipo de prueba verificará todos los módulos para verificar que los cambios realizados en un módulo impactarán o no en el otro módulo. En las pruebas de humo, los casos de prueba están programados.

Las pruebas de regresión ejecutan los mismos casos de prueba repetidamente para asegurar que el módulo sin cambios no cause ningún defecto. Las pruebas de regresión están bajo pruebas funcionales

malini
fuente
Eso responde al título, pero no al de herramientas para los dos últimos tipos de pruebas, para pruebas de humo o pruebas de regresión. También repite respuestas anteriores: podría hacerse único respondiendo la pregunta sobre herramientas.
Peter Mortensen
7

PRUEBAS DE REGRESIÓN-

"Una prueba de regresión vuelve a ejecutar las pruebas anteriores contra el software modificado para garantizar que los cambios realizados en el software actual no afecten la funcionalidad del software existente".

Nikita G
fuente
18
¿De dónde estás citando?
Daryl
44
Según esta página , esa cita proviene del artículo de Wikipedia "Pruebas de software", aunque parece que el pasaje ha cambiado en algún momento desde 2010.
Zach Lysobey
De todos modos, WP no es una fuente válida. Las fuentes a las que se hace referencia pueden ser válidas. No hay fuentes válidas a las que se haga referencia en WP, ni en los artículos ni en las páginas de discusión, que respalden la afirmación de que el "no" hace alguna diferencia. Comparé los fragmentos de texto en las listas de resultados de las búsquedas en Google Books para ambos "regression test"y "non-regression test". Es lo mismo.
Rainald62
Eso responde (parte del) título, pero no el de herramientas para los dos últimos tipos de pruebas, para pruebas de humo o pruebas de regresión. También repite respuestas anteriores: podría hacerse único respondiendo la pregunta sobre herramientas.
Peter Mortensen
7

Solo quería agregar y dar más contexto sobre por qué tenemos estos niveles de prueba, qué significan realmente con ejemplos

A Mike Cohn en su libro "Triunfar con Agile" se le ocurrió la "Pirámide de prueba" como una forma de abordar las pruebas automatizadas en los proyectos. Hay varias interpretaciones de este modelo. El modelo explica qué tipo de pruebas automatizadas deben crearse, qué tan rápido pueden dar retroalimentación sobre la aplicación bajo prueba y quién escribe estas pruebas. Básicamente, se necesitan 3 niveles de pruebas automáticas para cualquier proyecto y son los siguientes.

Pruebas unitarias: prueban el componente más pequeño de su aplicación de software. Esto podría ser literalmente una función en un código que calcula un valor basado en algunas entradas. Esta función es parte de varias otras funciones de la base de código de hardware / software que conforma la aplicación.

Por ejemplo: tomemos una aplicación de calculadora basada en la web. Los componentes más pequeños de esta aplicación que necesitan ser probados en unidades podrían ser una función que realiza la suma, otra que realiza la resta y así sucesivamente. Todas estas pequeñas funciones juntas forman la aplicación de la calculadora.

Históricamente, el desarrollador escribe estas pruebas ya que generalmente están escritas en el mismo lenguaje de programación que la aplicación de software. Para este propósito se utilizan marcos de prueba de unidad como JUnit y NUnit (para java), MSTest (para C # y .NET) y Jasmine / Mocha (para JavaScript).

La mayor ventaja de las pruebas unitarias es que se ejecutan muy rápido debajo de la interfaz de usuario y podemos obtener comentarios rápidos sobre la aplicación. Esto debería abarcar más del 50% de sus pruebas automatizadas.

API / Pruebas de integración: prueban juntos varios componentes del sistema de software. Los componentes pueden incluir bases de datos de prueba, API (interfaz de programación de aplicaciones), herramientas y servicios de terceros junto con la aplicación.

Por ejemplo: en nuestro ejemplo de calculadora anterior, la aplicación web puede usar una base de datos para almacenar valores, usar API para hacer algunas validaciones del lado del servidor y puede usar una herramienta / servicio de terceros para publicar resultados en la nube para que esté disponible en diferentes plataformas.

Históricamente, un desarrollador o un QA técnico escribirían estas pruebas usando varias herramientas como Postman, SoapUI, JMeter y otras herramientas como Testim.

Estos se ejecutan mucho más rápido que las pruebas de IU, ya que todavía se ejecutan debajo del capó, pero pueden consumir un poco más de tiempo que las pruebas unitarias, ya que tiene que verificar la comunicación entre varios componentes independientes del sistema y garantizar que tengan una integración perfecta. Esto debería comprender más del 30% de las pruebas automatizadas.

Pruebas de IU: finalmente, tenemos pruebas que validan la IU de la aplicación. Estas pruebas generalmente se escriben para probar flujos de extremo a extremo a través de la aplicación.

Por ejemplo: en la aplicación de la calculadora, un flujo de extremo a extremo podría ser, abrir el navegador-> Ingresar la URL de la aplicación de la calculadora -> Iniciar sesión con nombre de usuario / contraseña -> Abrir la aplicación de la calculadora -> Realizar algunas operaciones en la calculadora -> verificar esos resultados desde la interfaz de usuario -> Cerrar sesión en la aplicación. Este podría ser un flujo de extremo a extremo que sería un buen candidato para la automatización de la interfaz de usuario.

Históricamente, los QA técnicos o los probadores manuales escriben pruebas de IU. Utilizan marcos de código abierto como Selenium o plataformas de prueba de IU como Testim para crear, ejecutar y mantener las pruebas. Estas pruebas brindan más comentarios visuales, ya que puede ver cómo se ejecutan las pruebas, la diferencia entre los resultados esperados y reales a través de capturas de pantalla, registros e informes de pruebas.

La mayor limitación de las pruebas de IU es que son relativamente lentas en comparación con las pruebas de nivel de Unidad y API. Por lo tanto, debe comprender solo el 10-20% de las pruebas automatizadas generales.

Los siguientes dos tipos de pruebas pueden variar según su proyecto, pero la idea es:

Pruebas de humo

Esto puede ser una combinación de los 3 niveles de prueba anteriores. La idea es ejecutarlo durante cada registro de código y garantizar que las funcionalidades críticas del sistema sigan funcionando como se esperaba; después de que se fusionen los nuevos cambios de código. Por lo general, deben ejecutarse con 5 a 10 minutos para obtener comentarios más rápidos sobre fallas

Pruebas de regresión

Por lo general, se ejecutan al menos una vez al día y cubren diversas funcionalidades del sistema. Se aseguran de que la aplicación siga funcionando como se esperaba. Son más detalles que las pruebas de humo y cubren más escenarios de la aplicación, incluidos los no críticos.

Raj Subrameyer
fuente
Esta respuesta podría mejorarse respondiendo la pregunta sobre las herramientas para la prueba de humo o la prueba de regresión .
Peter Mortensen
5

Las pruebas unitarias se dirigen a la parte más pequeña posible de la implementación. En Java, esto significa que está probando una sola clase. Si la clase depende de otras clases, estas son falsas.

Cuando su prueba llama a más de una clase, es una prueba de integración .

Los conjuntos de pruebas completos pueden tardar mucho tiempo en ejecutarse, por lo que después de un cambio, muchos equipos ejecutan algunas pruebas rápidas para completar para detectar roturas significativas. Por ejemplo, ha dividido los URI en recursos esenciales. Estas son las pruebas de humo .

Las pruebas de regresión se ejecutan en cada construcción y le permiten refactorizar de manera efectiva al atrapar lo que rompe. Cualquier tipo de prueba puede ser una prueba de regresión, pero creo que las pruebas unitarias son más útiles para encontrar la fuente de la falla.

Dave
fuente
Eso responde al título, pero no al de herramientas para los dos últimos tipos de pruebas, para pruebas de humo o pruebas de regresión. También repite respuestas anteriores: podría hacerse único respondiendo la pregunta sobre herramientas.
Peter Mortensen
4
  • Prueba de integración: la prueba de integración es la integración de otro elemento
  • Prueba de humo: la prueba de humo también se conoce como prueba de versión de compilación. La prueba de humo es el proceso de prueba inicial ejercido para verificar si el software bajo prueba está listo / estable para pruebas adicionales.
  • Pruebas de regresión: Las pruebas de regresión son pruebas repetidas . Si el nuevo software se realiza en otro módulo o no.
  • Prueba de unidad: es una prueba de caja blanca. Solo los desarrolladores participan
Madhivanan
fuente
Eso responde al título, pero no al de herramientas para los dos últimos tipos de pruebas, para pruebas de humo o pruebas de regresión. También repite respuestas anteriores: podría hacerse único respondiendo la pregunta sobre herramientas.
Peter Mortensen
2

Pruebas unitarias: siempre se realiza por el desarrollador después de su desarrollo para averiguar el problema desde su lado de prueba antes de que cualquier requisito esté listo para el control de calidad.

Pruebas de integración: significa que el probador debe verificar la verificación de módulo a submódulo cuando algunas salidas de datos / funciones se conducen de un módulo a otro. O en su sistema si utiliza una herramienta de terceros que utiliza los datos de su sistema para integrar.

Prueba de humo: el probador se realizó para verificar el sistema para pruebas de alto nivel y para tratar de encontrar un error de detención antes de que los cambios o el código se activen.

Pruebas de regresión: el probador realizó una regresión para verificar la funcionalidad existente debido a los cambios implementados en el sistema para nuevas mejoras o cambios en el sistema.

Krunal
fuente
¿No tenemos que crear la prueba antes de hacer el desarrollo real?
Vin Shahrdar
@VinShahrdar, ¿Estás hablando de pruebas unitarias?
Krunal
si. Por lo general, creo mis pruebas unitarias antes de escribir el código de producción. Así es como se supone que debes hacerlo, ¿correcto?
Vin Shahrdar
1
Sí ... Pero las pruebas unitarias también se realizan antes del control de calidad que enfrenta el desarrollador. Antes de implementar código en el servidor de control de calidad siempre dev realizar pruebas unitarias
Krunal
2

Examen de la unidad

Las pruebas unitarias generalmente las realiza el lado de los desarrolladores, mientras que los probadores evolucionan en parte en este tipo de pruebas donde las pruebas se realizan unidad por unidad. En Java, los casos de prueba JUnit también pueden ser posibles para probar si el código escrito está perfectamente diseñado o no.

Pruebas de integración:

Este tipo de prueba es posible después de la prueba de la unidad cuando todos / algunos componentes están integrados. Este tipo de prueba asegurará que cuando los componentes están integrados, ¿afectan las capacidades o funcionalidades de trabajo de los demás?

Prueba de humo

Este tipo de prueba se realiza al final cuando el sistema se integra con éxito y está listo para funcionar en el servidor de producción.

Este tipo de prueba asegurará que todas las funcionalidades importantes de principio a fin funcionen bien y que el sistema esté listo para implementarse en el servidor de producción.

Pruebas de regresión

Este tipo de prueba es importante para comprobar que los defectos no deseados / no deseados no están presentes en el sistema cuando el desarrollador solucionó algunos problemas. Esta prueba también se asegura de que todos los errores se resuelvan con éxito y por eso no se produjeron otros problemas.

mohit sarsar
fuente
Eso responde al título, pero no al de herramientas para los dos últimos tipos de pruebas, para pruebas de humo o pruebas de regresión. También repite respuestas anteriores: podría hacerse único respondiendo la pregunta sobre herramientas.
Peter Mortensen
2

Las pruebas de humo y cordura se realizan después de una compilación de software para identificar si se debe comenzar la prueba. La cordura puede o no ser ejecutada después de la prueba de humo. Se pueden ejecutar por separado o al mismo tiempo, la cordura es inmediatamente después del humo.

Debido a que las pruebas de cordura son más profundas y requieren más tiempo, en la mayoría de los casos vale la pena automatizarse.

La prueba de humo generalmente no demora más de 5-30 minutos en ejecutarse. Es más general: comprueba una pequeña cantidad de funcionalidades centrales de todo el sistema, para verificar que la estabilidad del software sea lo suficientemente buena como para realizar más pruebas y que no haya problemas, bloqueando la ejecución de los casos de prueba planificados.

Las pruebas de cordura son más detalladas que el humo y pueden tomar desde 15 minutos hasta un día entero, dependiendo de la escala de la nueva construcción. Es un tipo más especializado de pruebas de aceptación, que se realiza después de la progresión o de las nuevas pruebas. Comprueba las características principales de ciertas nuevas funcionalidades y / o correcciones de errores junto con algunas características estrechamente relacionadas con ellas, con el fin de verificar que estén funcionando en cuanto a la lógica operativa requerida, antes de que las pruebas de regresión puedan ejecutarse a una escala mayor.

Radostta
fuente
Esto elabora algo, pero no sobre herramientas para los dos últimos tipos de pruebas, para pruebas de humo o pruebas de regresión . Podría hacerse único respondiendo la pregunta sobre herramientas.
Peter Mortensen
1

Ya hay algunas buenas respuestas, pero me gustaría refinarlas aún más:

Las pruebas unitarias son la única forma de prueba de caja blanca aquí. Los otros son pruebas de caja negra. La prueba de caja blanca significa que conoce la entrada; conoce el funcionamiento interno del mecanismo y puede inspeccionarlo y conoce el resultado. Con las pruebas de recuadro negro solo se sabe cuál es la entrada y cuál debería ser la salida.

Claramente, la prueba unitaria es la única prueba de caja blanca aquí.

  • Prueba de unidad prueba piezas específicas de código. Usualmente métodos.
  • Las pruebas de integración prueban si su nueva pieza de software puede integrarse con todo lo demás.
  • Pruebas de regresión. Esta prueba se realiza para asegurarse de que no haya roto nada. Todo lo que solía funcionar aún debería funcionar.
  • La prueba de humo se realiza como una prueba rápida para asegurarse de que todo se vea bien antes de participar en las pruebas más enérgicas.
uridio
fuente
55
Las pruebas unitarias no son necesariamente de caja blanca. Algunas de las mejores pruebas unitarias que he visto son esencialmente ejemplos extraídos de los requisitos, que especifican los resultados esperados independientemente de los conceptos de implementación.
joel.neely
1
Además de eso, sus pruebas unitarias están incluidas en sus pruebas de regresión, por lo tanto, las pruebas de regresión no son pruebas de caja blanca o negra. Llegaría al extremo de decir que incluso las pruebas de integración y humo pueden ser pruebas de blanco o de caja negra.
Lieven Keersmaekers
1
Tendría que estar en desacuerdo con esto. Probar una implementación de patrón de diseño es una forma de prueba de integración y es una prueba de caja blanca.
Hazok
Eso responde al título, pero no al de herramientas para los dos últimos tipos de pruebas, para pruebas de humo o pruebas de regresión . También repite respuestas anteriores: podría hacerse único respondiendo la pregunta sobre herramientas.
Peter Mortensen
1

Las pruebas de humo ya se han explicado aquí y es simple. Las pruebas de regresión vienen bajo pruebas de integración.

Las pruebas automatizadas se pueden dividir en solo dos.

Pruebas unitarias y pruebas de integración (esto es todo lo que importa)

Llamaría usar la frase "prueba larga" (LT) para todas las pruebas como pruebas de integración, pruebas funcionales, pruebas de regresión, pruebas de IU, etc. Y pruebas unitarias como "prueba corta".

Un ejemplo de LT podría ser, cargar automáticamente una página web, iniciar sesión en la cuenta y comprar un libro. Si la prueba pasa, es más probable que se ejecute en el sitio en vivo de la misma manera (de ahí la referencia de "mejor sueño"). Larga = distancia entre la página web (inicio) y la base de datos (final).

Y este es un gran artículo que discute los beneficios de las pruebas de integración (prueba larga) sobre las pruebas unitarias .

Nubes azules
fuente
1

Prueba de regresión - Es un tipo de pruebas de software en la que tratamos de cubrir o Hora en todo el bug fix . La funcionalidad en torno a la corrección de errores no debe modificarse ni alterarse debido a la corrección provista. Los problemas encontrados en dicho proceso se denominan problemas de regresión .

Prueba de humo: es un tipo de prueba que se realiza para decidir si acepta la compilación / software para más pruebas de control de calidad.

Sanyal
fuente