unit testing - software - ¿Qué son las pruebas unitarias y las pruebas de integración, y qué otros tipos de pruebas debo conocer?

tipos de pruebas de software (10)

¿Debería conocer alguna otra prueba importante de mi código?

Estos son algunos de los diferentes tipos de prueba, según las diferentes fases del ciclo de vida del software:

Prueba de unidad : ¿funciona este pequeño código?
Conjunto de pruebas unitarias : una secuencia de muchas pruebas unitarias (para muchos pequeños fragmentos de código)
Prueba de integración : prueba si dos componentes funcionan juntos cuando se combinan (o ''integrados'')
Prueba del sistema : prueba si todos los componentes funcionan juntos cuando se combinan (o ''integrados'')
Prueba de aceptación : qué hace el cliente para decidir si quiere pagarle (la prueba del sistema descubre si el software funciona según lo diseñado ... la prueba de aceptación descubre si el cliente deseaba "tal como estaba diseñado")

Hay más:

Prueba de usabilidad
Prueba de rendimiento
Prueba de carga
Prueba de estrés

Y, mucho más ... el software de prueba es un tema casi tan amplio como el software de escritura.

He visto a otras personas mencionar varios tipos de pruebas en Stack Overflow.

Los que puedo recordar son pruebas unitarias y pruebas de integración. Especialmente las pruebas unitarias se mencionan mucho. ¿Qué es exactamente la prueba unitaria? ¿Qué es la prueba de integración? ¿De qué otras técnicas de prueba importantes debería estar al tanto?

La programación no es mi profesión, pero me gustaría que fuera algún día; también se agradece la producción, etc.

Esta fue una entrada que escribí: Diferentes tipos de pruebas automatizadas .

Hay diferentes niveles de prueba correspondientes a la etapa en la que se encuentra en el ciclo de vida del desarrollo de software. El nivel más alto es el análisis de requisitos y el nivel más bajo es la implementación de la solución.

¿Qué es la prueba unitaria?

Las pruebas unitarias evalúan el software con respecto a su implementación.
Nos enfocamos en probar unidades de un programa (es decir, métodos individuales) y descartar quién llama / usa estas unidades. Por lo tanto, esencialmente tratamos cada unidad como una unidad independiente.
Hay muchas herramientas de pruebas unitarias, una de las más populares es JUnit.
Al realizar pruebas unitarias, queremos construir un conjunto de prueba (conjunto de casos de prueba) que satisfaga un cierto criterio de cobertura. Estos podrían ser algunos criterios de cobertura estructural (NC, EC, PPC, etc.) o criterios de flujo de datos (ADC, AUC, ADUPC, etc.)
Tenga en cuenta que la prueba unitaria es el nivel más bajo de prueba porque evalúa las unidades de código reales producidas después de la implementación. Este tipo de prueba se realiza antes de las pruebas de integración.
Las pruebas de unidades eficientes ayudan a garantizar que las pruebas de integración no sean dolorosas, ya que es más barato y más fácil detectar y corregir errores cuando se realizan pruebas de unidades

¿Qué es la prueba de integración?

Las pruebas de integración son necesarias para garantizar que nuestro software siga funcionando cuando se combinan dos o más componentes.
Puede realizar pruebas de integración antes de que el sistema se complete.
El problema de orden de prueba de integración de clases (CITO) está asociado con las pruebas de integración. CITO tiene que ver con la estrategia de integración de componentes. Existen muchas soluciones propuestas para CITO, como integración top-down, integración bottom-up, etc. El objetivo principal es integrar componentes de manera que permitan pruebas eficientes y la menor cantidad de stubbing, ya que la escritura de códigos no siempre es fácil y lleva tiempo . Tenga en cuenta que este sigue siendo un área activa de investigación.
Las pruebas de integración se realizan después de la prueba unitaria.
A menudo ocurre que los componentes individuales funcionan bien, pero cuando todo está preparado, de repente vemos errores que aparecen debido a incompatibilidades / problemas con las interfaces.

Otros niveles de prueba incluyen:

Pruebas de regresión
- Este tipo de prueba se le da mucha importancia porque los desarrolladores suelen realizar cambios en el software muy a menudo, por lo que queremos asegurarnos de que estos cambios no introducen errores.
- La clave para una prueba de regresión efectiva es limitar el tamaño de las pruebas de regresión para que no tarde demasiado en finalizar la prueba, de lo contrario, el conjunto de prueba no finalizará antes de la siguiente confirmación. También debemos elegir casos de prueba efectivos que no pierdan errores.
- Este tipo de prueba debe ser automática.
- Es importante tener en cuenta que siempre podemos seguir agregando más máquinas para contrarrestar la creciente cantidad de pruebas de regresión, pero en algún momento la compensación no vale la pena.
Test de aceptación
- Con esta prueba evaluamos el software en relación con los requisitos provistos, básicamente vemos si el software que hemos producido cumple con los requisitos que nos dieron.
- Este suele ser el último tipo de prueba realizada en la secuencia de actividades de desarrollo de software. En consecuencia, este tipo de prueba se realiza después de las pruebas unitarias y las pruebas de integración.

La otra técnica importante es la prueba de regresión . En esta técnica, usted mantiene un conjunto de pruebas (llamadas el conjunto de regresión), que generalmente se ejecutan cada noche, así como antes de cada registro. Cada vez que tiene una solución de error, agrega una o más pruebas al conjunto. El objetivo es evitar que vuelva a introducir errores antiguos que ya se han solucionado. (¡El problema es sorprendentemente común!)

Comience a acumular su conjunto de regresión temprano, antes de que su proyecto sea grande, o lo lamentará. ¡Seguro que sí!

La parte superior de mi cabeza:

Pruebas unitarias en el sentido de "probar la unidad aislable más pequeña de una aplicación"; esto es típicamente un método o una clase, dependiendo de la escala.
Pruebas de integración
Prueba de funciones : esto puede afectar a las unidades y es el foco de TDD.
Prueba de caja negra : prueba solo la interfaz pública sin conocimiento de cómo funciona la cosa.
Prueba de caja de vidrio : prueba todas las partes de una cosa con pleno conocimiento de cómo funciona.
Pruebas de regresión : casos de prueba construidos para reproducir fallas, para asegurar que no vuelvan a aparecer más tarde.
Pruebas sin sentido : probando el mismo estuche básico en más de una manera, o probando cosas tan triviales que realmente no necesitan ser probadas (como getters y setters autogenerados)

La prueba unitaria es simplemente la idea de escribir (con suerte) pequeños bloques de código para probar partes independientes de su aplicación.

Por ejemplo, puede tener una aplicación de calculadora y debe asegurarse de que la función de adición funcione. Para hacerlo, escriba una aplicación por separado que llame directamente a la función de adición. Luego, su función de prueba evaluará el resultado para ver si cumple con lo que esperaba.

Básicamente está llamando a sus funciones con entradas conocidas y verificando que la salida es exactamente lo que esperaba.

Los primeros dos resultados de búsqueda en google para ''tipos de prueba'' parecen completos

Los que creo que son más relevantes. Mira aquí .

MSDN: Prueba unitaria

El objetivo principal de las pruebas unitarias es tomar la pieza más pequeña de software comprobable en la aplicación, aislarla del resto del código y determinar si se comporta exactamente como esperabas. Cada unidad se prueba por separado antes de integrarlas en módulos para probar las interfaces entre los módulos. Las pruebas unitarias han demostrado su valor ya que se identifica un gran porcentaje de defectos durante su uso.

MSDN: prueba de integración

Las pruebas de integración son una extensión lógica de las pruebas unitarias. En su forma más simple, dos unidades que ya han sido probadas se combinan en un componente y se prueba la interfaz entre ellas. Un componente, en este sentido, se refiere a un agregado integrado de más de una unidad. En un escenario realista, muchas unidades se combinan en componentes, que a su vez se agregan en partes aún más grandes del programa. La idea es probar combinaciones de piezas y, finalmente, ampliar el proceso para probar sus módulos con los de otros grupos. Finalmente, todos los módulos que componen un proceso se prueban juntos. Más allá de eso, si el programa se compone de más de un proceso, deben analizarse en pares en lugar de todos a la vez.

Visite los sitios para obtener más información. También hay mucha información de fuentes distintas de Microsoft.

Diferentes tipos de casos de prueba:

Casos de prueba de funcionalidad

Los casos de prueba de funcionalidad se utilizan para descubrir si la interfaz de una aplicación funciona con el resto del sistema y sus usuarios. Las pruebas identifican el éxito o el fracaso de las funciones que se espera que el software realice. Los casos son un tipo de prueba de caja negra que utiliza para su base las especificaciones o historias de usuario del software bajo prueba. Esto permite que las pruebas se realicen sin necesidad de acceder al funcionamiento o a las estructuras internas del software que se prueba. El equipo de control de calidad son los redactores habituales de los casos de prueba de funcionalidad porque se encuentran dentro de los procesos normales de control de calidad. Se pueden escribir y ejecutar tan pronto como el desarrollo ponga a disposición una primera función para probarla. Para ayudar a dirigir el desarrollo, se pueden escribir antes del código, si todo el probador tiene acceso a los requisitos. Como se especifica anteriormente, se pueden escribir y ejecutar tan pronto como sea viable hacerlo y deben repetirse cada vez que se agreguen actualizaciones, hasta cuando los clientes se conviertan en una posibilidad.

Ejemplo: Confirmar que un usuario puede cargar con éxito una foto de perfil.

Casos de prueba de interfaz de usuario

Los casos de prueba de la interfaz de usuario se utilizan para verificar que las piezas específicas de la interfaz gráfica de usuario (GUI) se vean y funcionen como se esperaba. Estos tipos de casos de prueba se pueden utilizar para identificar inconsistencias cosméticas, errores de ortografía y gramática, enlaces y cualquier otro elemento con el que el usuario interactúe o vea. Estos casos generalmente son escritos por el equipo de prueba, pero el equipo de diseño también puede participar ya que están más familiarizados con la interfaz. Los casos de prueba de la interfaz de usuario son los tipos de casos de prueba en las pruebas de software que generalmente generan pruebas entre navegadores. Los navegadores tienden a presentar las cosas de manera diferente, y los casos de prueba de la interfaz de usuario ayudan a garantizar que su aplicación se comporte de manera consistente en múltiples navegadores. Estos casos de prueba se ejecutarán una vez que se complete la fase de desarrollo y la interfaz de usuario esté conectada a la base de datos.

Ejemplo: ¿Qué sucede cuando el sitio web se ve en una pantalla pequeña, como un teléfono móvil? ¿Se rompe la interfaz de usuario?

Casos de prueba de rendimiento

Los casos de prueba de rendimiento validan los tiempos de respuesta y la eficacia general de una aplicación. Es decir, después de ejecutar una acción, ¿cuánto tiempo tarda el sistema en responder? Los casos de prueba de rendimiento deben tener un conjunto muy claro de criterios de éxito. El equipo de pruebas generalmente escribe estos casos de prueba y a menudo son automáticos. Una aplicación grande puede tener cientos o miles de pruebas de rendimiento. Automatizar estas pruebas y ejecutarlas con frecuencia ayuda a exponer escenarios donde la aplicación no está funcionando al nivel esperado. Los casos de prueba de rendimiento ayudan a comprender cómo funcionará la aplicación en el mundo real. Estos casos se pueden escribir una vez que el equipo de prueba tiene los requisitos de rendimiento del equipo del producto. Sin embargo, muchos problemas de rendimiento pueden identificarse manualmente sin tener requisitos específicos.

Ejemplo: ¿Cuánto tarda el sistema en autenticar a un usuario y cargar la página siguiente? Cuando varias personas inician sesión al mismo tiempo, ¿la aplicación se mantiene estable?

Casos de prueba de integración

Los casos de prueba de integración están destinados a determinar cómo los diferentes módulos interactúan entre sí. El objetivo principal de los casos de prueba de integración es garantizar que las interfaces entre los diferentes módulos funcionen correctamente. El equipo de prueba identifica qué áreas deben someterse a pruebas de integración, mientras que el equipo de desarrollo tendrá información sobre cómo se deben escribir esos casos de prueba. Cualquiera de estos dos equipos puede trabajar para escribir los casos. Verifican que los módulos que ya están trabajando individualmente también puedan funcionar juntos.

Ejemplo: Verificar el enlace entre la página de inicio y la sección de "favoritos". Cuando agrega un artículo como "favorito", desde la página de inicio, ¿aparece en la sección "favoritos"?

Casos de Prueba de Usabilidad

Los casos de prueba de usabilidad a menudo se pueden denominar "tareas" o "escenarios". En lugar de proporcionar instrucciones detalladas paso a paso para ejecutar la prueba, el probador se presenta con un escenario de alto nivel o una tarea para completar. Los casos de prueba de usabilidad ayudan a identificar cómo un usuario se acerca y usa la aplicación de manera natural. Ayudan a guiar al probador a través de diversas situaciones y flujos. No se requiere conocimiento previo de la aplicación. Estos casos de prueba generalmente los prepara el equipo de diseño junto con el equipo de prueba. Las pruebas de usabilidad deben realizarse antes de la prueba de aceptación del usuario.

Ejemplo: ¿Puede el usuario agregar con éxito más de un artículo a su carrito de compras? ¿Cómo es esa experiencia?

Casos de prueba de base

Los casos de prueba para las pruebas de la base de datos examinan lo que sucede detrás de escena. La interfaz de usuario está limpia, y todo parece estar funcionando ... pero, ¿a dónde van todos esos datos? Para escribir estos casos de prueba, debe tener una sólida comprensión de toda la aplicación, las tablas de la base de datos y los procedimientos almacenados. El equipo de prueba a menudo usará consultas SQL para desarrollar casos de prueba de base de datos. Las pruebas de base de datos se utilizan para verificar que el desarrollador haya escrito el código de una manera que almacena y maneja los datos de una manera constante y segura.

Ejemplo: consideremos la creación de un perfil de usuario. Cuando el usuario envía su perfil, se debe probar lo siguiente con respecto a la base de datos. ¿La aplicación almacenó los datos ingresados en la base de datos? ¿Se perdió algún dato en el proceso? Los datos parcialmente realizados no deberían haberse guardado. Los usuarios no autorizados no deberían poder ver ni acceder a la información del usuario.

Casos de prueba de seguridad

Los casos de prueba de seguridad ayudan a garantizar que la aplicación restrinja las acciones y los permisos cuando sea necesario. Estos casos de prueba están escritos para proteger los datos cuando y donde necesitan salvaguardarse. Los casos de prueba de seguridad se usan para conducir pruebas de penetración y otros tipos de pruebas basadas en seguridad. La autenticación y el cifrado son a menudo el enfoque principal en los casos de prueba de seguridad. El equipo de seguridad (si existe) generalmente es responsable de escribir y realizar estas pruebas.

Ejemplo: si un usuario alcanza el número X de intentos fallidos de inicio de sesión, ¿la cuenta se bloquea? ¿Un usuario puede subir datos sin haber iniciado sesión?

Casos de prueba de aceptación del usuario

Los casos de prueba de aceptación del usuario, o casos de prueba "UAT", ayudan al equipo a probar el entorno de prueba de aceptación del usuario. Estos casos de prueba deben ser amplios y abarcar todas las áreas de la aplicación. El objetivo de estos casos de prueba no es encontrar errores (con suerte ya se han encontrado y corregido en pruebas anteriores), sino verificar que la aplicación sea aceptable para el usuario. Entonces, cuando ejecutan una prueba, ¿son aceptables los resultados de esa prueba y la experiencia de esa prueba? Dado que ya se han realizado muchos otros tipos de pruebas para cuando se inicia el UAT, el enfoque no es tanto en un nivel granular, sino más en una imagen más amplia. Los casos de prueba de aceptación del usuario son utilizados por el usuario final o el cliente y preparados por el equipo de prueba o el gerente de producto. Esta es quizás la fase más importante de las pruebas, ya que es el último paso antes de entrar en producción.

Ejemplo: si se prueba, por ejemplo, una aplicación de gestión de fotografías para un estudio de fotografía, el cliente (el usuario) debería probar que puede cargar y gestionar sus fotos de una manera que se adapte a sus necesidades comerciales.

Pruebas unitarias : las pruebas realizadas a una unidad o a una pieza de software más pequeña. Hecho para verificar si satisface su especificación funcional o su estructura de diseño prevista.

Pruebas de integración: prueba de los módulos relacionados en conjunto por su funcionalidad combinada.

Pruebas de regresión: prueba la aplicación para verificar que las modificaciones no hayan causado efectos involuntarios.

Prueba de humo : la prueba de humo se verifica si la construcción es comprobable o no.