¿Qué es la prueba unitaria, la prueba de integración, la prueba de humo, la prueba de regresión?

¿Qué es la prueba unitaria, la prueba de integración, la prueba de humo, la prueba de regresión y cuáles son las diferencias entre ellos? ¿Y qué herramientas puedo usar para cada una de ellas?

Por ejemplo, uso JUnit y NUnit para pruebas unitarias y pruebas de integración. ¿Hay alguna prueba de humo o herramientas de prueba de regresión?

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

    • Prueba de integración : prueba la interoperación correcta de subsistemas múltiples. Aquí hay un espectro completo, desde probar la integración entre dos clases hasta probar la integración con el entorno de producción.

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

      • La prueba de humo es tanto una analogía con la electrónica, donde la primera prueba se produce al encender un circuito (¡si fuma, es malo!) …
      • … y, al parecer , con la fontanería , donde un sistema de tuberías se llena literalmente de humo y luego se controla visualmente. Si algo fuma, el sistema está goteando.
    • 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 : pruebe que una característica o caso de uso se ha implementado correctamente. Es similar a una prueba de integración, pero con un enfoque en el caso de uso para proporcionar en lugar de en los componentes involucrados.

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

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

    • Prueba unitaria : una prueba automática para probar 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, de manera 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 corregir errores, vuelve a probar los escenarios que funcionaron en el pasado. Aquí cubre la posibilidad de que sus nuevas funciones rompan características existentes.
    • Prueba 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 poco (lo más aislado posible)?
    • Prueba de integración: ¿estos dos (o más) componentes funcionan juntos?
    • Prueba de humo: ¿todo este sistema (lo más parecido posible a ser un sistema de producción) 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 enterarme es la siguiente:

    Prueba canaria

    Una prueba de Canarias 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:

    • Tiene datos que solo deberían estar disponibles en DEV / TEST aparecieron en LIVE.
    • Ha fallado la ejecución de un proceso en segundo plano
    • ¿Puede un usuario iniciar sesión

    trivia histórica apócrifa: “prueba de humo” proviene de la ingeniería submarina (heredada de la fontanería) donde literalmente se bombearía humo al casco para ver si volvía a salir, lo que sería una falla dramática para un submarino.

    Prueba unitaria: Verificando que un componente particular (es decir, una clase) haya creado o modificado funciones tal como se diseñaron. Esta prueba puede ser manual o automática, pero no se mueve más allá de los límites del componente.

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

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

    Dependiendo de su SDLC (cascada, rup, ágil, etc.), las pruebas particulares pueden realizarse en ‘fases’ o pueden realizarse todas, más o menos, al mismo tiempo. Por ejemplo, las pruebas unitarias pueden estar limitadas a los desarrolladores que luego entregan el código a los evaluadores para realizar 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 integración y pruebas de regresión (utilizando un enfoque TDD junto con una integración continua y pruebas unitarias automatizadas y de regresión).

    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’s (mercurio) QTP o Borland’s Silktest son ambas herramientas para integración automatizada y pruebas de regresió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í

    enter image description here

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

    Espero que sea útil 🙂

    Prueba unitaria : se sabe que las pruebas de un módulo individual o componente independiente en una aplicación son pruebas unitarias, la prueba de la unidad será realizada por el desarrollador.

    Prueba de integración : combinando todos los módulos y probando la aplicación para verificar que la comunicación y el flujo de datos entre los módulos funcionen correctamente o no, esta prueba también la realizan los desarrolladores.

    prueba de humo EN prueba de humo comprueban la aplicación de manera superficial y amplia, en las pruebas de humo comprueban la funcionalidad principal de la aplicación, si hay algún problema de bloqueador en la aplicación informarán al equipo de desarrollo, y el equipo en desarrollo lo arreglará y rectifique el defecto y devuélvalo al equipo de prueba y ahora el equipo de prueba verificará todos los módulos para verificar que los cambios realizados en un módulo afectarán al otro módulo o no. EN PRUEBAS DE HUMO, los casos de prueba tienen guiones

    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. PRUEBA DE REGRESIÓN viene bajo prueba funcional

    PRUEBAS DE REGRESIÓN-

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

    Prueba unitaria: Verificando que un componente particular (es decir, una clase) haya creado o modificado funciones tal como se diseñaron. Esta prueba puede ser manual o automática, pero no se mueve más allá de los límites del componente.

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

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

    Dependiendo de su SDLC (cascada, rup, ágil, etc.), las pruebas particulares pueden realizarse en ‘fases’ o pueden realizarse todas, más o menos, al mismo tiempo. Por ejemplo, las pruebas unitarias pueden estar limitadas a los desarrolladores que luego entregan el código a los evaluadores para realizar 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 integración y pruebas de regresión (utilizando un enfoque TDD junto con una integración continua y pruebas unitarias automatizadas y de regresión).

    Un tipo de prueba que parece que vale la pena mencionar en este hilo son las pruebas de estrés / rendimiento / carga, que podrían simplemente establecer los límites más allá de los cuales se rompe un determinado software. Tenga en cuenta que, en términos de herramientas, es esencial determinar con precisión el scope de lo que se propone para poner a prueba las pruebas desde una perspectiva del sistema. Por ejemplo, en el caso de una “aplicación web”, las pruebas de tensión pueden incluir en su scope la propia aplicación de servidor web, por lo que las herramientas podrían intervenir en ese extremo. Aquí hay una buena publicación sobre pruebas de carga http

    Las pruebas unitarias se dirigen a la parte más pequeña posible de la implementación. En Java esto significa que estás 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 prueba completos pueden tardar mucho tiempo en ejecutarse, por lo que después de un cambio, muchos equipos realizan algunas pruebas de detección rápidas 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 comstackción y le permiten refactorizar de forma efectiva atrapando lo que rompe. Cualquier tipo de prueba puede ser una prueba de regresión, pero encuentro que las pruebas unitarias son más útiles para encontrar el origen de la falla.

    Pruebas unitarias: las pruebas unitarias las realiza generalmente el lado de los desarrolladores, donde los evaluadores se desarrollan parcialmente en este tipo de pruebas donde las pruebas se realizan unidad por unidad. En java, los casos de prueba de 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 se asegurará de que cuando se integran los componentes, afecten las funcionalidades o funcionalidades de los demás.

    Prueba de humo: – Este tipo de prueba se realiza por última vez cuando el sistema se integra exitosamente y está listo para funcionar en el servidor de producción. Este tipo de prueba asegurará que todas las funciones 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 probar que los defectos no deseados / no deseados no están presentes en el sistema cuando el desarrollador solucionó algunos problemas. Estas pruebas también aseguran que todos los errores se resuelven con éxito y debido a eso no se producen otros problemas.

    • Prueba de integración: la prueba de integración es la integración del otro elemento
    • Pruebas de humo: Las pruebas de humo también se conocen como pruebas de versión de construcción. La prueba de humo es el proceso de prueba inicial que se realiza para verificar si el software bajo prueba está listo / estable para realizar más pruebas.
    • Prueba de regresión: la prueba de regresión es prueba reactiva. Si el nuevo software se efectúa en otro módulo o no.
    • Prueba unitaria: es una prueba de caja blanca. Solo los desarrolladores participan en ella

    Algunas buenas respuestas ya, pero me gustaría refinarlas:

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

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

    • Pruebas unitarias prueban piezas específicas de código. Usualmente métodos.
    • Prueba de prueba de integración para saber si su nueva característica de software puede integrarse con todo lo demás.
    • Pruebas de regresión. Esta es una prueba hecha para asegurarte de que no has roto nada. Todo lo que solía funcionar debería funcionar.
    • La prueba de humo se realiza como una prueba rápida para asegurarse de que todo se vea bien antes de involucrarse en las pruebas más vigorosas.

    Prueba de regresión: es un tipo de prueba de SW en la que tratamos de cubrir o revisar el error Fix. la funcionalidad en torno a la corrección de errores no debería modificarse ni modificarse debido a la reparación provista. Los problemas encontrados en dicho proceso se llaman Problemas de regresión.

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

    Examen de la unidad:

    La prueba unitaria es un proceso de desarrollo de software en el que las partes más pequeñas comprobables de una aplicación, llamadas unidades, se analizan de forma individual e independiente para un funcionamiento adecuado. Las pruebas unitarias a menudo están automatizadas, pero también pueden realizarse manualmente.

    Pruebas de integración:

    (a veces llamado integración y prueba, abreviado I & T) es la fase de prueba de software en la que los módulos de software individuales se combinan y se prueban como un grupo. Ocurre después de la prueba unitaria y antes de la prueba de validación.

    Prueba del sistema:

    suele ser la prueba final para verificar que el sistema que se entregará cumple con la especificación y su propósito.

    Test de regresión:

    después de implementar nuevas características o corregir errores, vuelves a probar los escenarios que funcionaron en el pasado. Aquí cubre la posibilidad de que sus nuevas funciones rompan características existentes.

    Prueba de humo:

    El objective no es realizar pruebas exhaustivas, sino verificar que las funcionalidades críticas del sistema funcionen correctamente. Por ejemplo, una prueba de humo típica sería: compruebe que la aplicación se inicia correctamente, verifique que la GUI responda, etc.

    Pruebas unitarias: siempre se realiza por el desarrollador después de su desarrollo para averiguar el problema desde el lado de las pruebas antes de que preparen un requisito para la garantía de calidad.

    Pruebas de integración: Significa que el probador debe verificar la verificación de módulo a submódulo cuando parte de la salida de datos / función se dirige a un módulo a otro módulo. O en su sistema si utiliza una herramienta de terceros que utiliza los datos de su sistema para integrarse.

    Prueba de humo: el comprobador se realizó para verificar el sistema de pruebas de alto nivel y para tratar de descubrir errores de show showper antes de que los cambios o el código se activen.

    Pruebas de regresión: Tester realizó la regresión para la verificación de la funcionalidad existente debido a los cambios implementados en el sistema para una nueva mejora o cambios en el sistema.

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

    Debido a que las pruebas de cordura son más exhaustivas y tardan más tiempo, en la mayoría de los casos, está bien automatizado.

    Las pruebas de humo generalmente no requieren más de 5-30 minutos para la ejecución. Es más general: comprueba un pequeño número de funcionalidades básicas de todo el sistema, para verificar que la estabilidad del software sea lo suficientemente buena para realizar más pruebas y que no haya problemas, bloqueando el funcionamiento 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 completo, dependiendo de la escala de la nueva construcción. Es un tipo más especializado de prueba de aceptación, realizada después de la progresión o la repetición de la prueba. 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 mayor escala.

    Ha habido un gran detalle de la diferencia entre varias técnicas de prueba. Dicho esto, muy poco ha tocado las herramientas Prueba de Humo o Prueba de Regresión.

    Por lo general, hay algunos marcos combinados con el lenguaje / marco que se ha utilizado para desarrollar la aplicación. Habiendo desarrollado Angular, el transportador podría ser una buena opción, ya que el pepino o el arquillian de Java podría ser otra opción. Con todo, cuantos más idiomas / marcos tenga, más opciones tendrá. O es eso ?.

    Personalmente, he creído en un lenguaje declarativo que se adapta a todos los idiomas y a todos los platofrm para realizar pruebas de principio a fin.

    Finalmente, se trata de un marco de automatización y pruebas de primer extremo a extremo totalmente declarativo, que puede utilizarse para cualquier cosa en cualquier idioma.

    La prueba de humo ya se ha explicado aquí y es simple. La prueba de regresión viene bajo prueba de integración.

    Las pruebas automatizadas se pueden dividir en solo 2.

    Prueba unitaria y Prueba de integración. (Esto es todo lo que importa)

    Yo llamaría usar la frase “prueba larga” (LT) para todas las pruebas como la prueba de integración, la prueba funcional, la prueba de regresión, la prueba UI, etc. Y la prueba unitaria 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’). Largo = distancia entre la página web (inicio) y la base de datos (final).

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