unit-testing - tipos - pruebas unitarias ejemplos
¿Qué es la prueba unitaria, la prueba de integración, la prueba de humo, la prueba de regresión? (20)
¿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 ellas? ¿Y qué herramientas puedo usar para cada una de ellas?
Por ejemplo, uso JUnit y NUnit para pruebas de unidad y pruebas de integración. ¿Hay alguna herramienta de prueba de humo o prueba de regresión?
PRUEBAS DE REGRESIÓN-
"Una prueba de regresión vuelve a ejecutar pruebas anteriores contra el software modificado para garantizar que los cambios realizados en el software actual no afecten la funcionalidad del software existente".
Algunas buenas respuestas ya, pero me gustaría refinarlas aún más:
La prueba de unidad es 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, puede inspeccionarlo y conoce la salida. Con las pruebas de caja negra, solo se sabe cuál es la entrada y cuál debería ser la salida.
Así que claramente la prueba de unidad es la única prueba de caja blanca aquí.
- Prueba unitaria prueba piezas específicas de código. Normalmente los métodos.
- Prueba de integración prueba si su nueva pieza característica de software puede integrarse con todo lo demás.
- Pruebas de regresión. Esta es una prueba hecha para asegurarse de que no ha roto nada. Todo lo que solía trabajar debería funcionar.
- Las pruebas de humo se realizan como una prueba rápida para asegurarse de que todo se vea bien antes de involucrarse en las pruebas más vigorosas.
Las pruebas de humo y de cordura se realizan después de una compilación de software para identificar si se debe iniciar la prueba. La cordura puede o no puede ejecutarse después de la prueba de humo. Se pueden ejecutar por separado o al mismo tiempo, la cordura se produce 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 automatizarlas.
Las pruebas de humo usualmente no toman más de 5 a 30 minutos para su ejecución. Es más general: verifica una pequeña cantidad de funcionalidades principales 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, lo que bloquea el funcionamiento de los casos de prueba planificados.
Las pruebas de cordura son más detalladas que el humo y pueden durar desde 15 minutos hasta un día entero, dependiendo de la escala de la nueva construcción. Es un tipo de prueba de aceptación más especializado, que se realiza después de la progresión o la reevaluación. Verifica las funciones principales de ciertas nuevas funcionalidades y / o correcciones de errores junto con algunas características estrechamente relacionadas con ellas, para verificar que estén funcionando según la lógica operacional requerida, antes de que las pruebas de regresión puedan ejecutarse en mayor escala.
Prueba de regresión: es un tipo de prueba de SW donde intentamos cubrir o revisar la corrección de errores. la funcionalidad en torno a la corrección de errores no debe modificarse ni modificarse debido a la corrección provista. Los problemas encontrados en dicho proceso se denominan problemas de regresión.
Pruebas de humo: es un tipo de prueba que se realiza para decidir si acepta la compilación / software para realizar más pruebas de control de calidad.
Prueba de unidad: verificar que el componente particular (es decir, la clase) creó o modificó las funciones tal como se diseñó. Esta prueba puede ser manual o automatizada pero no se mueve más allá del límite del componente.
Prueba de integración: verificar que la interacción de componentes particulares funciona como se diseñó. Las pruebas de integración se pueden realizar a nivel de unidad o nivel de sistema. Estas pruebas pueden ser manuales o automatizadas.
Prueba de regresión: verificación de que no se han introducido nuevos defectos en el código existente. Estas pruebas pueden ser manuales o automatizadas.
Dependiendo de su SDLC (cascada, rup, ágil, etc.), las pruebas particulares se pueden realizar en "fases" o se pueden realizar, más o menos, al mismo tiempo. Por ejemplo, las pruebas unitarias pueden limitarse a los desarrolladores que luego pasan el código a los evaluadores para la integración y las pruebas de regresión. Sin embargo, otro enfoque podría hacer que los desarrolladores realicen pruebas unitarias y cierto nivel de integración y pruebas de regresión (utilizando un enfoque TDD junto con una integración continua y pruebas automatizadas de unidades y regresión).
Prueba de unidad: verificar que el componente particular (es decir, la clase) creó o modificó las funciones tal como se diseñó. Esta prueba puede ser manual o automatizada pero no se mueve más allá del límite del componente.
Prueba de integración: verificar que la interacción de componentes particulares funciona como se diseñó. Las pruebas de integración se pueden realizar a nivel de unidad o nivel de sistema. Estas pruebas pueden ser manuales o automatizadas.
Prueba de regresión: verificación de que no se han introducido nuevos defectos en el código existente. Estas pruebas pueden ser manuales o automatizadas.
Dependiendo de su SDLC (cascada, rup, ágil, etc.), las pruebas particulares se pueden realizar en "fases" o se pueden realizar, más o menos, al mismo tiempo. Por ejemplo, las pruebas unitarias pueden limitarse a los desarrolladores que luego pasan el código a los evaluadores para la integración y las pruebas de regresión. Sin embargo, otro enfoque podría hacer que los desarrolladores realicen pruebas unitarias y cierto nivel de integración y pruebas de regresión (utilizando un enfoque TDD junto con una integración continua y pruebas automatizadas de unidades y regresión).
El conjunto de herramientas dependerá en gran medida del código base, pero hay muchas herramientas de código abierto para la prueba de unidades (JUnit). El QTP de HP (mercurio) o el Silktest de Borland son ambas herramientas para la integración automatizada y las pruebas de regresión.
Pruebas unitarias: - las pruebas unitarias generalmente las realizan los desarrolladores, donde los probadores evolucionan en parte en este tipo de pruebas donde se realizan las pruebas unidad por unidad. En Java, los casos de prueba de Junit también pueden ser posibles para comprobar si el código escrito está perfectamente diseñado o no.
Pruebas de integración: - Este tipo de pruebas es posible después de las pruebas unitarias cuando todos / algunos componentes están integrados. Este tipo de pruebas se asegurará de que cuando los componentes estén integrados, afecten a las capacidades de trabajo o funcionalistas de los demás.
Pruebas 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 garantizará 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 pruebas 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 solucionen correctamente y, por lo tanto, no se han producido otros problemas.
Pruebas unitarias: siempre se realiza por el desarrollador después de su desarrollo para descubrir el problema de su lado de prueba antes de preparar cualquier requisito 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 algunos datos / salida de función son conducidos de 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.
Pruebas de humo: el probador se realizó para verificar las pruebas de alto nivel en el sistema y tratar de descubrir el error "show stopper" antes de que los cambios o el código se activen.
Pruebas de regresión: Tester realizó una regresión para verificar la funcionalidad existente debido a los cambios implementados en el sistema para una mejora reciente o cambios en el sistema.
Todos tendrán definiciones ligeramente diferentes, y a menudo hay áreas grises. Sin embargo:
- Prueba de unidad: ¿esto funciona un poco (lo más aislado posible)?
- Prueba de integración: ¿estos dos (o más) componentes trabajan juntos?
- Prueba de humo: ¿todo este sistema (lo más cerca posible de ser un sistema de producción) se mantiene razonablemente bien unido? (es decir, ¿estamos razonablemente seguros de que no creará un agujero negro?)
- Prueba de regresión: ¿hemos vuelto a introducir inadvertidamente algunos errores que habíamos solucionado anteriormente?
Un tipo de prueba que parece que vale la pena mencionar en este hilo son las pruebas de carga / rendimiento / carga, que se pueden poner simplemente como un descubrimiento de los límites más allá de los cuales se rompe una determinada pieza de software. Tenga en cuenta que, en términos de herramientas, es esencial determinar con precisión el alcance de lo que se propone para realizar pruebas de estrés desde la perspectiva del sistema. Por ejemplo, en el caso de una "aplicación web", las pruebas de estrés pueden incluir en su alcance la aplicación del servidor web y, por lo tanto, las herramientas podrían intervenir en ese sentido. Aquí hay un buen post sobre pruebas de carga http
Una nueva categoría de prueba que acabo de conocer es la:
Prueba canaria
Una prueba de Canary es una prueba automatizada y no destructiva que se ejecuta de forma regular en un entorno VIVO , de modo que si alguna vez falla, algo realmente malo ha sucedido.Ejemplos pueden ser:
- Los datos que solo deberían estar disponibles en DEV / TEST aparecieron en LIVE.
- Tiene un proceso en segundo plano no se pudo ejecutar
- ¿Puede un usuario iniciar sesión?
trivia histórica apócrifa: las "pruebas de humo" provienen de la ingeniería submarina (heredada de la plomería) donde se bombearía humo literal en el casco para ver si salía algo de nuevo, ¡lo que sería un fracaso dramático para un submarino!
La prueba de humo ya se ha explicado aquí y es simple. 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)
Llamaría a usar la frase "prueba larga" (LT) para todas las pruebas como prueba de integración, prueba funcional, prueba de regresión, prueba de IU, etc. Y prueba de unidad 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 (por lo tanto, la referencia "mejor reposo"). Largo = distancia entre la página web (inicio) y la base de datos (final).
Y este es un gran artículo que analiza los beneficios de las pruebas de integración (prueba larga) sobre las pruebas unitarias.
Examen de la unidad:
La prueba de unidad es un proceso de desarrollo de software en el que las partes más pequeñas comprobables de una aplicación, llamadas unidades, se examinan individual e independientemente para un funcionamiento adecuado. Las pruebas unitarias a menudo son automatizadas, pero también se pueden hacer manualmente.
Pruebas de integración:
(a veces llamado integración y prueba, I&T abreviada) es la fase de prueba de software en la que los módulos de software individuales se combinan y se prueban en grupo. Ocurre después de la prueba de unidad y antes de la prueba de validación.
Pruebas del sistema:
es a menudo la prueba final para verificar que el sistema que se va a entregar cumple con la especificación y su propósito.
Test de regresión:
después de implementar nuevas funciones o correcciones de errores, vuelve a probar los escenarios que funcionaron en el pasado. Aquí cubre la posibilidad de que sus nuevas funciones rompan las características existentes.
Pruebas de humo:
El objetivo no es realizar pruebas exhaustivas, sino verificar que las funciones críticas del sistema funcionan bien. Por ejemplo, una prueba de humo típica sería: verifique que la aplicación se inicie correctamente, verifique que la GUI responda, etc.
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 .
Las pruebas completas pueden tardar mucho tiempo en ejecutarse, por lo que, después de un cambio, muchos equipos ejecutan algunas pruebas rápidas y completas para detectar roturas significativas. Por ejemplo, ha roto los URI a recursos esenciales. Estas son las pruebas de humo .
Las pruebas de regresión se ejecutan en cada compilación y le permiten refactorizar eficazmente capturando lo que rompe. Cualquier tipo de prueba puede ser una prueba de regresión, pero me parece que las pruebas unitarias son más útiles para encontrar la fuente de la falla.
Responda desde 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, no la voy a pegar aquí, pero puede ser útil para alguien que quiera conocer todas las técnicas de prueba.
Espero que sea de ayuda :)
prueba de unidad : se sabe que la prueba de un módulo individual o componente independiente en una aplicación es una prueba de unidad, la prueba de la unidad la realizará 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 estén funcionando 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 verifican la funcionalidad principal de la aplicación, si hay algún problema de bloqueo en la aplicación, informarán al equipo de desarrolladores, y el equipo de desarrollo lo solucionará y rectifique el defecto y devuélvalo al equipo de pruebas y ahora el equipo de pruebas verificará todos los módulos para verificar que los cambios realizados en un módulo afectarán o no al otro módulo. EN LAS PRUEBAS DE HUMO, los casos de prueba están programados.
pruebas de regresión ejecutando los mismos casos de prueba repetidamente para garantizar que el módulo sin cambios no cause ningún defecto. PRUEBAS DE REGRESIÓN se someten a pruebas funcionales
- Pruebas de integración: Pruebas de integración es la integración del otro elemento
- Pruebas de humo: las pruebas de humo también se conocen como versiones de compilación. Las pruebas de humo son el proceso de prueba inicial que se ejerce para verificar si el software bajo prueba está listo / estable para realizar más pruebas.
- Pruebas de regresión: las pruebas de regresión son pruebas repetidas. Si el nuevo software se efectúa en otro módulo o no.
- Pruebas unitarias: es una prueba de caja blanca. Solo los desarrolladores participan en ella
- 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, similar a las pruebas unitarias pero con recursos externos (db, acceso a disco)
- Prueba de regresión : después de implementar nuevas funciones o correcciones de errores, vuelve a probar los escenarios que funcionaron en el pasado. Aquí cubre la posibilidad de que sus nuevas funciones rompan las características existentes.
- Pruebas de humo : primeras pruebas en las que los evaluadores pueden concluir si continuarán con las pruebas.
Prueba unitaria : especifique y pruebe un punto del contrato de método único de una clase. Esto debería tener un alcance muy estrecho y bien definido. Las dependencias complejas y las interacciones con el mundo exterior son golpeadas o burladas .
Prueba de integración : pruebe la interoperabilidad correcta de varios subsistemas. Hay todo el espectro allí, desde la integración de pruebas entre dos clases, hasta la integración de pruebas con el entorno de producción.
Prueba de humo (también conocida como Sanity check) : una prueba de integración simple en la que simplemente verificamos que cuando se invoca el sistema bajo prueba se devuelve normalmente y no explota.
- La prueba de humo es una analogía con la electrónica, donde la primera prueba se produce cuando se enciende un circuito (si fuma, ¡es malo!) ...
- ... y, apparently , con plumbing , donde un sistema de tuberías se llena literalmente con humo y luego se verifica 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 proporciona el mismo resultado.
A esto añadiré:
Prueba de aceptación : prueba de que una característica o un 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 en los componentes involucrados.
Prueba del sistema : prueba un sistema como una caja negra. Las dependencias de otros sistemas a menudo se burlan o se apagan 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 "se basa en mi máquina". A menudo, esto se realiza realizando una prueba de aceptación o de humo en un entorno de producción.