Universidad Tecnológica Nacional Facultad Regional Córdoba Cátedra de Diseño de Sistemas

Diseño de Casos de Prueba

Ing. Judith Meles

Condiciones de prueba
Esta es la reacción esperada de un sistema frente a un estímulo particular, este estímulo está constituido por las distintas entradas. Una condición de prueba debe ser probada por al menos un caso de prueba

2

Ing. Judith Meles

1

Ing.. Consta de tres partes: 1) 2) 3) Objetivo: la característica del sistema a comprobar Datos de entrada y de ambiente: datos a introducir al sistema que se encuentra en condiciones preestablecidas." Boris Beizer OBJETIVO CRITERIO descubrir errores en forma completa RESTRICCIÓN con el mínimo de esfuerzo y tiempo 4 Ing. Judith Meles 2 .. Comportamiento esperado: La salida o la acción esperada en el sistema de acuerdo a los requerimientos del mismo.CASOS DE PRUEBA Un caso de prueba es la unidad de la actividad de la prueba. Judith Meles 3 CASOS DE PRUEBA “Los bugs se esconden en las esquinas y se congregan en los límites .

Judith Meles 3 . Si contamos con casos de uso. Además debemos generar: casos de prueba para el control de rango y manejo de errores. Judith Meles Derivación de Casos de Prueba En base a documentos del cliente En base a documentos de relevamiento En base a casos de uso En base a especificaciones de programación En base a código 6 Ing.CASOS DE PRUEBA Los casos de prueba se deben confeccionar en forma paralela al desarrollo. casos de prueba que tengan en cuenta la interacción entre los diversos casos de prueba 5 Ing. los utilizaremos como base para el desarrollo de casos de prueba para probar la funcionalidad requerida del sistema.

Metodología de diseño de software seleccionada. Debe basarse en alguna documentación existente del sistema. Judith Meles En base a documentos del cliente Cobertura muy condicionada: dependerá de cuán completa sea la documentación del cliente. La documentación a recibir en el área de testing. Descripción de casos de pruebas generales que luego se particularizarán on-working.Derivación de Casos de Prueba La actividad de diseño de casos de pruebas siempre debe realizarse. Esos casos de pruebas generales son útiles para medir o estimar el trabajo de testing requerido y poder cotizar. Judith Meles 4 . 8 Ing. dependerá de: Madurez de la organización en cuanto al proceso. 7 Ing.

El diseño de casos de pruebas. etc. Judith Meles 5 . 10 Ing. Se pueden perder detalles que se contemplan en el diseño. incluso en el ciclo 0 del testing. Aconsejable para las pruebas de aceptación de usuario. Judith Meles En base a documentos de relevamiento Se puede caer en supuestos equivocados para aplicar un testing funcional. de carga. performance. Así como en el relevamiento se puede basar un diseño de software. así también puede basarse el diseño de casos de pruebas. 9 Ing. pero deben completarse más adelante.En base a documentos del cliente Útil para el diseño de casos de prueba de funciones de negocio. Puede ser muy pobre para un testing funcional. debería ser más completo que el logrado en base a documentos del cliente.

y no hay que confundir con el diseño del desarrollo.En base a documentos de relevamiento Cobertura condicionada: dependerá de cuán completa sea la documentación de relevamiento. 12 Ing. Judith Meles En base a documentos de relevamiento Si se detectan omisiones o supuestos equivocados en el relevamiento. Judith Meles 6 . 11 Ing. El diseño de casos de pruebas generado de estos documentos tiene que servir al testing. se debe informar para corregir. Aconsejable para las pruebas de sistema. No debería ser pobre para un testing funcional.

planillas de condiciones. tablas. puede ser la misma utilizada para el caso de uso.En base a Casos de Uso Cobertura completa del diseño. 13 Ing. Judith Meles 7 . Aconsejable para las pruebas funcionales. etc. El diseño de casos de pruebas logrado es bien detallado. No se cae en supuestos equivocados. 14 Ing. Pero pueden utilizarse otras plantillas. Será dependiente de lo que se requiera testear. Judith Meles En base a Casos de Uso La plantilla para la descripción de los casos de prueba.

Casos de prueba Los casos de prueba y los casos de uso son dependientes en dos sentidos: Si los casos de uso están completos. precisos y claros el proceso de derivación de casos de prueba es transparente y directo. Casos de prueba Los casos de uso describen lo que el sistema deberá hacer. Judith Meles En base a Casos de Uso Casos de uso vs. 16 Ing. Si los casos de uso no están bien delineados. el intento de derivar de ellos los casos de prueba ayudará a depurar los mismos. Judith Meles 8 .En base a Casos de Uso Casos de uso vs. mientras que los casos de prueba aseguran que el sistema sea todo lo que se definió. 15 Ing.

Si un programador puede codificar en base a estas especificaciones. con lo que hay que definir casos de prueba específicos. Y los casos de uso no contemplan la interacción entre ellos. Se puede lograr un diseño de casos de prueba de amplia cobertura 18 Ing. Más completo que el diseño que se logra en base a documentos del cliente y de relevamiento. Además recordar que los casos de uso no especifican requerimientos no funcionales. 17 Ing. Judith Meles 9 . Testing debe poder diseñar casos de prueba y testear.En base a Casos de Uso Casos de uso vs. Más detalle. Judith Meles En base a especificaciones de programación En Testing se reciben las mismas especificaciones que se le envían al programador. Normalmente hay más de un caso de prueba para cada alternativa de un caso de uso. Casos de prueba Cada alternativa de un caso de uso define automáticamente un caso de prueba.

20 Ing. ya hemos empezado tarde las tareas de testing. Si las especificaciones incluyen un prototipo de pantalla. Judith Meles 10 .En base a especificaciones de programación Sirve para el testing funcional. se pueden diseñar casos para testing de usabilidad. 19 Ing. Lo que implica que los errores que encontremos serán más caros de corregir para la organización. Judith Meles En base a especificaciones de programación DESVENTAJA: Si empezamos acá a diseñar casos de prueba.

Permite completar los casos de prueba para asegurar una mayor cobertura 21 Ing.En base a código En Testing se recibe el CODIGO. Es complementario al diseño de casos de prueba en base a documentación. Es aplicable en el diseño con técnicas de CAJA BLANCA. Se usa para el diseño de casos de prueba de Test de Componentes. Judith Meles Diseño de Casos de Prueba desde los casos de uso Prueba de Software 11 . Amplia cobertura del código y por supuesto del diseño. Adquiere las mismas ventajas y desventajas que esta técnica tiene.

El control de rangos y el manejo de errores en el ingreso de valores representan otra clase de problemas a considerar. tal vez lo más fácil de probar sea la funcionalidad del sistema definida por un Modelo de Casos de Uso. CASOS DE USO Los caso de uso describen lo que el sistema deberá hacer. Muchas cosas pueden salir mal en un sistema. Los rangos pueden reflejar la habilidad del sistema para crecer a lo largo del tiempo. Los casos de uso son generales. Un problema a tener en cuenta es la interacción entre casos de uso. Muchos tipos de problemas están relacionados con requerimientos no funcionales. mientras que los Casos de Prueba aseguran que el sistema sea todo lo que se prometió. mientras que los casos de prueba son particulares. Judith Meles Estrategia de Prueba La actividad de construcción de casos de prueba puede distribuirse a lo largo del desarrollo de software en lugar de dejarlo para el final. dado que el modelo no muestra secuencialidad  orden natural. 23 Ing.CASOS DE PRUEBA vs. 24 Ing. que están más allá del modelado de casos de uso. Se construyen casos de prueba para cada escenario de un caso de uso. Judith Meles 12 .

Judith Meles 13 . que están fuera del alcance de la técnica. Judith Meles Creación de Casos de Prueba Se puede construir un juego de casos de prueba para cada caso de uso. Pruebas de Interacción Pruebas de Rango Pruebas de Manejo de Errores Pruebas relacionadas con requerimientos no funcionales. Nos concentramos en los tipos de prueba que pueden derivarse implícita o explícitamente del Modelo de Casos de Uso. Se indica con “S” cuando el sistema realiza una acción. Cada caso de prueba representa un escenario del caso de uso.Estrategia de Prueba Una estrategia de prueba completa incluye: Pruebas Funcionales. Se indica con “A” los pasos ejecutados por el ACTOR. Algunos pasos representan puntos de decisión donde el sistema necesita más información del actor. 26 Ing. 25 Ing. Se indica con “E” cuando un paso es una condición excepción o no es parte del curso normal.

El sistema muestra la lista de pedidos que estén listos y no hayan sido facturados aún. El vendedor no confirma la impresión 9.A.A. 2. El sistema informa la situación mostrando un 2. 7. El sistema muestra los datos completos del pedido y calcula el monto total a cobrar 5. El vendedor selecciona el pedido que desea facturar.A.A. Curso Normal Alternativas A S A S S A S S A S S 28 1.A. Judith Meles 14 . Fin del use case Ing. E 6.1. No existen pedidos en ese estado. Se cancela el use case. el use case se cancela si no se confirma la generación de la misma o si no se selecciona ningún pedido. Fin del use case E mensaje 2. Se genera la factura actualizando el estado del pedido según corresponda. E 9. Se imprime la factura 11. 8.Condiciones: factura generada. 9. Precondiciones: no aplica Post. 2. El use case comienza cuando el vendedor ingresa la opción de generar factura. Se cancela el use case. Judith Meles Ejemplo: Caso de Uso “Generar Factura” Nombre del Use Case: GENERAR FACTURA Actor Principal: Vendedor Tipo de Use Case: Concreto Abstracto Nro. El Vendedor confirma la impresión 10. 6. 1.A.A. El vendedor confirma la generación de la factura.1. El sistema solicita la confirmación de la generación de la factura. 6. 3. El vendedor no confirma la generación de la factura. 4. de Orden: 1 Actor Secundario: no aplica Objetivo: generar la factura correspondiente a un pedido determinado.Ejemplo: Caso de Uso “Generar Factura” Vendedor (f rom Modelo del SI) Generar Factura 27 Ing. El sistema solicita confirmación de la impresión de la factura.2.

Judith Meles Construcción de Casos de Prueba Para crear casos de prueba desde los casos de uso.AE9.S4.A3.AE6. se invierte el proceso por el cual los escenarios se transformaron en casos de uso.A3.S5. A1 – SE2. S5 A6 S7 S8 AE9 A9 S10 29 FIN USE CASE AE6 Casos de Prueba Negativos: 3.S4. Cada paso en el caso de prueba debe tener un estado de: PASÓ. 30 Ing. esto ocurre en las pre y pos condiciones y flujos de eventos. Las post condiciones se mapean a la sección de RESULTADOS del caso de prueba. A1 – S2. FALLÓ o ADVERTENCIA después que el caso de prueba se ha completado.S4. Judith Meles 15 . Ing. 2.A3. 4.S10. A1 – S2. Las precondiciones se mapean a la sección de SETUP del caso de prueba.S5-A6-S7S8. A1 – S2.A9.S5-A6-S7S8. Se reemplazan las entidades abstractas del caso de uso por instancias específicas.Grafo de Caminos para el Caso de Uso “Generar Factura” A1 S2 A3 S4 CANCELA USE CASE SE2 Caminos Resultantes: Casos de Prueba Positivos: 1.

Se pueden utilizar técnicas para buscar áreas donde la interacción entre casos de uso pueda traer problemas. Judith Meles Prueba de Interacción Las interacciones entre caso de uso son las áreas más difíciles de probar.Plantilla para la Construcción de Casos de Prueba Id del Caso de Prueba Juego de Prueba Camino de Prueba Resultado Condiciones de Inicio Nombre del Caso de Prueba Tipo de Prueba Prioridad Ciclo 0 Paso Descripción Resultado Esperado Resultado Obtenido Estado Id de Problema Estado del Caso de Prueba en el Ciclo Nombre del Analista de Prueba que ejecutó el caso de prueba en el Ciclo Fecha de Ejecución del Caso de Prueba 31 Ing. Judith Meles 16 . Caso de Prueba 1 -3 Use case 1 Juego de Pruebas 1 + Caso de Prueba 14-1 Juego de Prueba de Interacción Caso de Prueba 2-1 Use case 2 Juego de Pruebas 1 32 Ing. Esto se debe a la gran cantidad de combinaciones. aún en un sistema de tamaño moderado.

Judith Meles 17 . ¿Qué pasa cuando borramos objetos que otros leen o actualizan?  “Leer después de borrar”. y en particular los casos de prueba de aceptación de usuarios:  Se debe crear al menos un caso de prueba por cada caso de uso.Prueba de Interacción Una forma de buscar interacciones es buscar objetos compartidos entre use cases. Las matrices relacionados. ¿Qué pasa cuando los objetos no existen?  “Leer antes de crear”. 34 Ing. si es posible antes que se dé por concluido el análisis. ACTUALIZADOS o BORRADOS en un use case y creados en otro.  Se debe crear al menos un caso de prueba por cada alternativa de un caso de uso.  En todos los casos de prueba se debe especificar el comportamiento esperado del sistema.  Si hay alternativas se debe preparar al menos un caso en que la expresión contenga el curso normal y uno con cada alternativa. se tendrán 4 o 5 casos de prueba por cada caso de uso. Judith Meles ¿Cuántos casos de Prueba? Los Use Cases son un punto de partida excelente para definir caso de prueba. debo incluir al menos un caso de prueba con una acción inválida por parte del usuario. En general.  Si hay una relación de extensión.  Es muy importante crear los casos de prueba en el momento en que finalizó la documentación de los caso de uso. CRUD pueden utilizarse entre para ver use cases En especial se buscan situaciones donde los objetos son: LEIDOS. se debe plantear un Caso de Prueba que la contenga y uno que no. Veamos la matriz de interacción: Use Case 1 Use Case 1 Use Case 2 Use Case 3 LAC LDB Use Case 2 Use Case 3 LAC 33 Ing.  Por cada caso de uso.

Sign up to vote on this title
UsefulNot useful