Casos de prueba

Tema Casos de prueba

[pic 1][pic 2]

[pic 3]

[pic 4]

[pic 5]

[pic 6]

[pic 7]

INTRODUCCION

Los casos de prueba son una técnica utilizada para evaluar el comportamiento de un sistema o aplicación bajo diferentes condiciones. Estos casos de prueba son esenciales para garantizar que el sistema o aplicación funcione correctamente y cumpla con los requisitos del usuario. Los casos de prueba se utilizan para detectar errores y problemas en el sistema o aplicación antes de que estos problemas afecten a los usuarios finales.

CASO DE PRUEBA

Un caso de prueba es un escenario utilizado para evaluar la funcionalidad de una aplicación utilizando un conjunto específico de acciones o condiciones para probar los resultados esperados. En otras palabras, un caso de prueba es un conjunto de pasos que se realizan para probar la funcionalidad de una aplicación.

Un caso de prueba son varias partes, como pasos de prueba, datos de prueba y condiciones previas y posteriores diseñadas para un escenario de prueba específico. Los casos de prueba se pueden utilizar para cualquier aplicación de software. Esto se puede hacer con pruebas manuales y automatizadas o cualquier herramienta de gestión de pruebas.

Hay varios tipos diferentes de casos de prueba.

• Casos de prueba funcionales:

Primero, si conoce un poco sobre estas pruebas, debe saber que las pruebas funcionales son una práctica de desarrollo beneficiosa. De esta manera, puede administrar el progreso del proyecto con aprobaciones y errores en las pruebas de funciones. Aquí se facilita la comunicación entre desarrolladores, analistas y probadores. Hardik Shah explica en detalle cómo funcionan.

Los casos de prueba funcionales se utilizan, como sugiere el nombre, para analizar si el sistema funciona según lo previsto. El equipo de control de calidad es responsable de escribir casos de prueba funcionales. Este tipo de prueba se puede realizar cuando el equipo de desarrollo tiene la primera funcionalidad de la aplicación disponible para probar. Por ejemplo, comprueba si el usuario puede subir una foto de perfil.

[pic 8]

Existen pruebas funcionales y no funcionales.

• Pruebas unitarias: Las pruebas unitarias son pruebas que aseguran que cada unidad de código desarrollada en un componente produzca el resultado apropiado. En estas pruebas, el desarrollador observa las interfaces y especificaciones de los componentes, proporciona documentación para el desarrollo del código y, por supuesto, realiza pruebas independientes antes de cambiar a otro dispositivo. Las pruebas unitarias admiten pruebas funcionales mediante la ejecución de código que es más probable que se rompa. Entonces, si usa pruebas funcionales sin pruebas unitarias, puede tener problemas con diagnósticos de prueba defectuosos. Así que mantenlos cerca.
• Pruebas de componentes: Las pruebas de componentes se realizan de forma independiente para verificar que los resultados cumplan con los requisitos. Su propósito es probar la funcionalidad y/o usabilidad de los componentes, pero no solo. Para ilustrar mejor esto, un ejemplo de esta prueba sería cualquier elemento que tenga una entrada y debería generar alguna salida. Estos son algunos usos de los componentes que puede probar:

•  Pruebas de interfaz de usuario para usabilidad y accesibilidad
•  Pruebas de carga para garantizar el rendimiento
•  Inyección SQL usando componentes de UI para seguridad
•  Verificación de inicio de sesión con credenciales válidas y no válidas

• Pruebas de humo: Se realizan pruebas de humo para verificar que las funciones principales de la aplicación funcionan correctamente. Así el software más básico funciona correctamente con una sencilla y rápida prueba. Esta es una de las pruebas de características más importantes y debe realizarse primero en una nueva compilación. La prueba de humo es común, aunque el concepto a veces es ambiguo. No está destinado a realizar pruebas exhaustivas, sino a verificar que las funciones principales del sistema funcionen correctamente. Si las pruebas tienen éxito, esta será una versión estable. Posteriormente, el equipo de control de calidad realizará pruebas funcionales o de regresión en las características o funciones recién agregadas, según sea necesario. Por otro lado, si una compilación falla debido a la inestabilidad, generalmente se devuelve al equipo de desarrollo para solucionar el problema de compilación y reconstruirla.
• Pruebas de integración: Las pruebas de integración son uno de los tipos más comunes de pruebas funcionales y se realizan de forma automatizada. Se utilizan para probar componentes individuales para probar cómo funcionan los módulos que funcionan por separado cuando están integrados. El propósito de estas pruebas es que los desarrolladores generalmente se enfocan en construir diferentes módulos del sistema al mismo tiempo sin prestar atención a otros módulos. Las pruebas de integración permiten el flujo de datos y comandos operativos entre módulos. Para que todo funcione como parte de un solo sistema, no como una aplicación separada. Esto a menudo nos ayuda a identificar problemas relacionados con las operaciones de la interfaz de usuario, los formatos de datos, las llamadas API, el acceso a la base de datos y más.

Algunas de las validaciones realizadas en las pruebas de integración son:

• Prueba de interfaz: prueba de transmisión de datos entre dos componentes. Pruebe interfaces como servicios web, API, etc. Esto se hace para verificar que los componentes estén sincronizados entre sí. Ayudan a garantizar que varias funciones, como la transferencia de datos entre diferentes elementos del sistema, se realicen según lo diseñado
• Pruebas de regresión: Es normal que los desarrolladores cambien y mejoren las características que desarrollan. Por lo tanto, es más probable que produzcan "efectos" no deseados en su comportamiento. Estas pruebas de regresión se realizan para garantizar que los cambios o adiciones no cambien ni eliminen la funcionalidad existente. El propósito de las pruebas de regresión es encontrar errores que pueden haberse introducido inadvertidamente en las versiones existentes, asegurando así que los errores eliminados permanezcan.
• Pruebas de cordura: Si su compilación se modifica ligeramente, hacemos verificaciones de cordura en lugar de pruebas de regresión. De esta manera podemos estar seguros de que el cambio solucionó el problema. Y estas correcciones no causaron ningún problema. A menudo, estas pruebas son subpruebas de las pruebas de "regresión" porque se relacionan con los cambios realizados en el producto. No confunda estas pruebas de humo con las comprobaciones de cordura por una sencilla razón: las pruebas de humo inician la compilación desde cero y prueban la funcionalidad más importante. Las personas inteligentes analizan las versiones de software en profundidad. Es decir, el primero confirma la estabilidad del producto y el segundo garantiza la racionalidad del producto.
• Pruebas de aceptación: Realizamos pruebas de aceptación cuando hemos observado e implementado las pruebas necesarias para el producto. Son parte de la etapa final de este proceso de prueba. Aquí es donde los usuarios reales del software lo usan para probar que hace lo que se supone que debe hacer en un entorno "real". A veces esto sucede "como punto de control final entre todo tipo de pruebas funcionales" cuando se entrega el producto. Desde el inicio hasta la implementación, el software requiere varios tipos de pruebas. El objetivo es siempre asegurar la calidad para evitar reelaboraciones y garantizar la funcionalidad de la aplicación para usuarios finales y clientes.

[pic 9]

• Casos de prueba de integración:

Los casos de prueba de integración sirven para analizar si los diferentes módulos de la aplicación interactúan correctamente ellos. El equipo de prueba es responsable de aislar el área de prueba para la integración. Por otro lado, el equipo de desarrollo ayuda a escribir los casos de prueba de integración. Por ejemplo, verifique si la página de inicio de sesión se muestra cuando hacemos clic en el botón "Iniciar sesión" en la página de inicio.

...