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

¿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 ?

• 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.

• 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.

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?

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?

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í

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.

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.

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

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".

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.

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.

• 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

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.

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.

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.

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.

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 .

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.