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

Question

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

Las 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; las cosas sobre la producción, etc. también son bienvenidas.

Answer 1

De la parte superior de mi cabeza:

• Prueba de la unidad en el sentido de "comprobación de la unidad más pequeña que se puede aislar de una aplicación"; esto es típicamente un método o una clase, dependiendo de la escala.
• Las pruebas de integración
• prueba Característica: esto puede cortar a través de 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: probando todas las partes de una cosa con pleno conocimiento de cómo funciona.
• Pruebas de regresión: casos de prueba construidos para reproducir errores, para asegurarse de que no vuelvan a aparecer más tarde.
• insustancial de las pruebas: probar el mismo caso básico de más de una forma, o probar cosas tan trivial que en realidad no necesitan ser probados (como captadores y definidores generados automáticamente)

Answer 2

MSDN: Unit Testing

el objetivo principal de la unidad de pruebas es tomar la más pequeña pieza de software comprobable en la aplicación, aislar desde el resto del código, y determinar si se comporta exactamente como esperabas. Cada unidad se prueba por separado antes de integrarlos en módulos para probar las interfaces entre módulos. La prueba unitaria ha demostrado su valor en que un gran porcentaje de defectos se identifican durante su uso.

MSDN: Integration Testing

Las pruebas de integración es un lógico extensión de la unidad de pruebas. En su forma más simple , dos unidades que tienen 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 de , muchas unidades son combinadas en componentes, que están en a su vez agregadas en partes más grandes del programa. La idea es probar combinaciones de piezas y eventualmente 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 que, si el programa está compuesto por más de un proceso, deben ser probados en pares en lugar de todos en una vez.

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

Answer 3

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

Por ejemplo, es posible que tenga 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.

Answer 4

¿Debo conocer otras pruebas importantes de mi código?

Estos son algunos de los diferentes tipos de prueba, de acuerdo a las diferentes fases del ciclo de vida del software:

• prueba Unidad: hace esto poco de trabajo de código?
• conjunto de pruebas Unidad: una secuencia de muchas pruebas unitarias (por muchos pequeños trozos de código)
• Prueba de integración: Prueba si dos componentes trabajan juntos cuando se combinan (o 'integrado')
• prueba del sistema: comprobar si todos los componentes trabajan juntos cuando se combinan (o 'integrado')
• prueba de aceptación: lo que hace el cliente para decidir wheher que quiere que le pague (tE sistema st descubre si el software funciona como complemento ... prueba de aceptación descubre si "diseñada" es lo que quería el cliente)

hay más:

• Test de usabilidad
• Prueba de rendimiento
• prueba de carga
• prueba de esfuerzo

Y, mucho MO re ... el software de prueba es un tema casi tan amplio como el software de escritura.

Answer 5

La otra técnica importante es 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 acumulando su suite de regresión antes de que su proyecto crezca, o lo lamentará. ¡Seguro que sí!

Answer 6

Los dos primeros resultados de búsqueda en Google de 'tipos de pruebas' visión integral

• www.aptest.com/testtypes.html
• www.softwaretestinghelp.com/types-of-software-testing/

Los que yo creo que son los más relevantes. See here.

Answer 7

Esta fue una entrada que escribí: Different Types of Automated Tests.

Answer 8

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

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

Prueba de regresión: Prueba de 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.

Answer 9

Existen 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 de unidades evalúan el software en lo que respecta a su implementación.
• Nos centramos 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 porque evalúa las unidades de código reales producido después de la implementación. Este tipo de prueba se realiza antes de las pruebas de integración.
• pruebas unitarias eficiente ayuda a asegurar que las pruebas de integración no va a ser doloroso, ya que es más barato y más fácil de detectar y corregir errores al hacer las pruebas unitarias

¿Cuál es la prueba de integración?

• Las pruebas de integración son necesarias para garantizar que nuestro software aún funcione cuando se combinan dos o más componentes.
• Puede realizar pruebas de integración antes de que el sistema se complete.
• El problema de la orden de prueba de integración de clase (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.
• Suele suceder que los componentes individuales funcionan bien, pero cuando todo se arma, de repente vemos errores que aparecen debido a incompatibilidades/problemas con las interfaces.

Otros niveles de prueba incluyen:

1. pruebas de regresión

   • Este tipo de pruebas se le da mucha importancia porque los desarrolladores enviar los cambios al software muy a menudo normalmente, por lo queremos asegurarnos de que estos cambios no presenten errores.
   • La clave para realizar pruebas de regresión efectivas es limitar el tamaño de las pruebas de regresión para que no tarde demasiado en finalizar las pruebas, de lo contrario el conjunto de pruebas 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.

2. pruebas de aceptación de

   • Con estas pruebas que evalúan el software en relación con los requisitos previstos, 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.

Answer 10

Diferentes tipos de casos de prueba:

casos de prueba Funcionalidad

casos de prueba de funcionalidad se utilizan para descubrir si la interfaz de una aplicación trabaja con el resto del sistema y su 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.

interfaz de usuario Casos de prueba

casos de prueba interfaz de usuario se utilizan para verificar que las piezas específicas de la Interfaz Gráfica de Usuario (GUI) apariencia y el funcionamiento esperado. 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 estar involucrado 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 la fase de desarrollo esté completa 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 Rendimiento

casos de prueba 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 tiempo le toma al sistema 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?

prueba de integración Casos

casos de prueba de integración tienen el propósito de 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 pruebas identifica qué áreas deben someterse a pruebas de integración, mientras que el equipo de desarrollo tendrá información sobre cómo deben escribirse 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: Verificando 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"?

test de usabilidad Casos

casos de prueba de usabilidad a menudo pueden ser referidos como “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 son preparados por 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 de datos

casos de prueba para las pruebas de base de datos de examinar lo que sucede detrás de las escenas. 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 comprender bien la aplicación completa, 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 la base de datos se utilizan para verificar que el desarrollador haya escrito el código de una manera que almacene y maneje los datos de manera consistente 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.

prueba de seguridad Casos

casos de prueba de seguridad ayudan a asegurar la aplicación restringe las acciones y permisos siempre que 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 controlar las 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, ¿se bloquea la cuenta? ¿Un usuario puede subir datos sin haber iniciado sesión?

usuario de prueba de aceptación Casos

casos de prueba de aceptación del usuario, o casos de prueba “UAT”, ayudan a la prueba del equipo de prueba de aceptación del usuario medio ambiente. 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 reparado 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 grande. 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.