Pruebas funcionales y su relación con los casos de uso

Integrantes: Veronica Dieguez Vargas Angel Paredes Núñez Néstor Núñez Marinovich Giovanni Vara Bernuy Luis Garcia Zapata Jean Mazuelos Saavedra

Contenidos• Introducción• Casos de uso y pruebas funcionales• Identificación de pruebas funcionales

• Identificación de escenarios • Identificación de casos de prueba• Identificar valores de prueba• Materializar prueba

• Caso práctico• Conclusiones

INTRODUCCIÓNConceptos básicos y un vistazo al tema

Las pruebas de software en la industria• Las pruebas suelen ser el 30% al 50% de los costes total del

software.• Es usual que el usuario sienta que el software no ha sido

probado correctamente antes del pase a producción.• Posibles causas

• Las pruebas de software son una tarea difícil• Las pruebas son realizadas sin una metodología que defina los

objetivos de dichas pruebas

Aseguramiento de calidad• Las pruebas deben empezar tan temprano como sea posible

en la fase de desarrollo de software.• La realización de pruebas disminuye los riesgos en el

desarrollo además de ser un factor de éxito del proyecto

Pruebas funcionales• Se basan en la ejecución, revisión y retroalimentación de

funcionalidades previamente diseñada para el software.• Las pruebas se realizan mediante el diseño de casos de

prueba.• Fases para realización de pruebas:

• Análisis de pruebas• Diseño de pruebas• Ejecución de pruebas• Gestión de incidencias

CASOS DE USO Y LAS PRUEBAS FUNCIONALES

La relación entre ambos es muy fuerte, siendo los casos de uso los que guían la elaboración de pruebas

Casos de uso y pruebas funcionales• Casos de uso de uso de

sistema, los casos de uso de sistema son utilizados para mostrar gráficamente lo que se espera que un sistema haga.

• Pruebas funcionales, están basadas en la ejecución revisión y retroalimentación del sistema basado en lo que previamente se ha diseñado para el software.

• ¿No sería lógico entonces definir las pruebas funcionales en base a los casos de uso definidos para el sistema?.

IDENTIFICACIÓN DE PRUEBAS FUNCIONALES

Partimos desde los casos de uso para empezar a definir pruebas funcionales

Paso 2: Identificar casos de prueba: Para cada escenario, identificar al menos un caso de prueba y las condiciones para "ejecutarse".

Paso 3: Identificar valores de datos de prueba. Para cada caso de prueba, identificar los valores de los datos para ponerlos a prueba.

Pasos para la identificación de pruebas

Paso 4: Materializar la prueba. Se deben escoger las pruebas según importancia o necesidad y materializarlas en un documento de pruebas.

Paso 1: Identificar escenarios. Identificamos los posibles caminos que el usuario puede tomar en el uso del sistema.

Identificación de escenarios• Un escenario de caso de uso es una instancia de un caso de

uso, o de un "camino" completo a través de los caso de uso. • Se debe generar una Matriz de Escenarios de CU dónde se

identifiquen todos los posibles flujos del caso de uso.

Flujo básico de eventos y flujos alternativos de eventos para un caso de uso

Identificación de escenarios• Identificar los posibles

flujos de actividades que se realiza en el caso de uso.

• Del caso de uso, se requiere tener especificado:• Flujo básico, es el flujo

normal el cual sigue el usuario.

• Flujos alternativos, son los posibles eventos que alteran el flujo básico.

Estos escenarios se pueden utilizar como base para la creación de casos de prueba

Identificación de escenariosMatriz de Escenarios de Casos de Uso

Escenario 1 Flujo Básico

Escenario 2 Flujo Básico Flujo Alternativo 1

Escenario 3 Flujo Básico Flujo Alternativo 1

Flujo Alternativo 2

Escenario 4 Flujo Básico Flujo Alternativo 3

Escenario 5 Flujo Básico Flujo Alternativo 3

Flujo Alternativo 1

……. …….. ……… ……. ……….

Escenario N Flujo Básico Flujo Alternativo N ……… ………..

Identificar casos de prueba• Se debe guiar de los escenarios anteriormente identificados

para llenar el caso de prueba• Sede debe tener los pasos del flujo básico en el eje vertical.• En el eje horizontal los escenario identificados.• Se deben marcar las acciones realizadas por escenario y paso

del flujo básico• Las acciones son marcadas en cada celda pueden ser:

• C -> correcto• I -> ignorado• N/A -> no hay acción

• Se debe indicar el resultado esperado.

Identificar casos de pruebaEscenarios de prueba por caso de uso

Escenario Paso 1 ……… Paso 1 Resultado esperado

Escenario 1

Escenario 1

Identificar valores de prueba• Una vez identificados los escenarios se identifican posibles

valores como datos.• Cada escenario de prueba puede contener una combinación

diferente de información.• Los resultados esperados deben también incluir los resultados

esperados.

Materializar la prueba• Las pruebas seleccionadas deben ser documentadas para su

posterior ejecución• Se seleccionan las pruebas de mayor importancia o según el

criterio escogido

CASO PRÁCTICODesarrollo de un caso práctico

Conclusiones• La calidad de software es muy importante, pero su realización

es cara en función de las realizaciones.• Los Casos de Uso de Sistema son la guía principal para el

desarrollo de pruebas.• Mientras mejor detalle se tenga de los casos de uso se podrán

identificar mejor los casos de pruebas.