8 test cases a partir de use cases

3,196 views

Published on

Como derivar Casos de Prueba a partir de Casos de Uso

1 Comment
2 Likes
Statistics
Notes
  • muy buena presentacion, felicidades. Te has basado en algun libro o estandard?
    Saludos,
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
3,196
On SlideShare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
70
Comments
1
Likes
2
Embeds 0
No embeds

No notes for slide

8 test cases a partir de use cases

  1. 1. 1 Análisis y Diseño Orientado a Objetos usando UML y Patrones Dr. Ricardo R. Quintero Meza (Test Cases a partir de Use Cases)
  2. 2. Introducción  Un requisito se define como “una condición o capacidad la cual un sistema debe satisfacer”  Algunos ejemplos de requisitos pueden ser:  Un capacidad solicitada por un cliente o usuario para resolver un problema o alcanzar un objetivo.  Una capacidad que debe poseer un sistema para satisfacer un contrato, un estándar, una especificación, regulación o algún otro documento formalmente impuesto.  Una restricción impuesta por un stakeholder. 2
  3. 3. La pirámide de los requisitos 3 Necesidades de los stakeholders Requisitos a diferente nivel de detalle
  4. 4. Trazabilidad entre los requisitos  La Trazabilidad es una técnica que provee una relación entre los diferentes niveles de requisitos del sistema.  La técnica ayuda a determinar el origen de cualquier requisito.  Las típicas relaciones de Trazabilidad son:  Cada necesidad se mapea a características.  Las características se mapean a CU y requisitos suplementarios. 4
  5. 5. Trazabilidad en la pirámide de los requisitos 5
  6. 6. Roles que juega la Trazabilidad  Verificar que una implementación satisface todos los requisitos: todo lo que el cliente solicitó fue implementado.  Verificar que una aplicación hace sólo lo que fue solicitado: no implementar algo que el cliente nunca pidió.  Ayudar con la gestión de cambios: cuando algún requisito cambia, deseamos conocer cuales casos de prueba deberán volver a hacerse para probar el cambio. 6
  7. 7. Trazabilidad en herramientas CASE 7
  8. 8. Casos de Uso, Casos de Prueba y Trazabilidad  El propósito de un CU es facilitar el acuerdo entre desarrolladores, clientes y usuarios sobre lo que el sistema deberá hacer.  Es un contrato entre desarrolladores y clientes.  A partir de los CU se pueden diseñar los Casos de Prueba (CP o Test cases) 8
  9. 9. Diagrama de CU 9
  10. 10. Formato General de un CU  El formato general de un CU es: 1. Breve descripción 2. Flujo de Eventos. 1. Flujo Básico 2. Flujo Alternativo 1 3. Flujo Alternativo 2 … 3. Requisitos especiales 4. Precondiciones 5. Postcondiciones 6. Puntos de Extensión 7. Diagrama de Contexto 8. Diagrama de Actividad 10
  11. 11. Ejemplo de CU (de IBM)-Happy path 1. B1 El Usuario captura la dirección web en el navegador. El Sistema despliega la página de “Login” 2. B2 El Usuario captura una dirección de e-mail y el password. El Sistema autoriza la entrada, muestra la página principal y solicita un “string” de búsqueda. 3. B3 El Usuario captura el “string” de búsqueda-el nombre parcial de un libro. El Sistema regresa todos los libros que empatan con el criterio de búsqueda 4. B4 El Usuario selecciona un libro. El Sistema presenta información detallada del libro 11
  12. 12. Ejemplo de CU (de IBM)-Happy path 5. B5 El Usuario agrega el libro a la cesta de compras. El Sistema muestra el contenido de la cesta de compras 6. B6 El Usuario selecciona la opción “Proceder a pagar”. El Sistema solicita la confirmación de la dirección destino. 7. B7 El Usuario confirma la dirección destino. El Sistema presenta las opciones de embarque 8. B8 El Usuario selecciona la opción de embarque. El Sistema pide cual tarjeta de crédito se utilizará. 9. B9 El Usuario confirma la tarjeta de crédito que está almacenada en el sistema. El Sistema pide la confirmación final para colocar la orden. 10. B10 El Usuario coloca la orden. El Sistema regresa el número de confirmación. 12
  13. 13. Ejemplo de CU (de IBM)-Flujos alternativos 13 A1 Usuario no registrado A2 Password inválido A3 No hay libro que empate el criterio de búsqueda A4 Declinar por un libro A5 Continuar comprando después de guardar el libro en la cesta de compras A6 Capturar una nueva dirección A7 Capturar una nueva tarjeta de crédito A8 Cancelar la orden
  14. 14. Derivando los Flujos Alternativos-Diagrama de Actividad 14
  15. 15. Detectando Happy Path y Flujos Alternativos en el Diagrama de Actividad  El Flujo Básico será la línea recta en el Diagrama de Actividad.  Los Flujos Alternativos serán los ciclos que van hacia adelante y hacia atrás en el Diagrama de Actividad. 15
  16. 16. ¿Cómo crear los Casos de Prueba a partir de los Casos de Uso?  Antes de crear el Caso de Prueba, se necesita identificar todos los escenarios del Caso de Uso.  Un escenario es una instancia del CU. Describe una ruta específica a través del flujo de eventos.  Los escenarios se pueden representar mediante un grafo. 16
  17. 17. Encontrando escenarios en el CU 17
  18. 18. Encontrando escenarios en el CU  Existe un escenario por:  Cada flujo alternativo y  Cada combinación de flujos alternativos  Existen, entonces, más escenarios que flujos alternativos (por ejemplo existe uno por A1, otro por A2 y otro por la combinación de ambos).  Los escenarios se pueden describir como secuencias de flujos alternativos:  SC16: A2,A2, A6 18
  19. 19. ¿Qué hacer con ciclos infinitos? 19 • Hacer el flujo básico una vez. •Hacer el ciclo una vez •Después hacer el ciclo una segunda vez. •Si el programa funciona bien para ambos ejemplos de ciclos puedes suponer que lo hará para todos los ciclos.
  20. 20. Explosión combinatoria de escenarios  Para el CU ejemplo se tiene 1 ciclo básico y 8 ciclos alternativos. 4 de ellos van hacia atrás y 4 hacia adelante.  Si se intenta describir todos las combinaciones de CU se tendrán 4,096 escenarios. Obviamente no se necesita hacerlos todos. 20
  21. 21. Explosión combinatoria de escenarios  Selecciona aquellos que representan un subconjunto razonable de estos 4,096 escenarios.  Los razonables son: 1. El Flujo básico. 2. Los Flujos alternativos 3. Y combinaciones razonables de flujos alternativos (por ejemplo flujos alternativos distantes no valdría la pena combinar –A1 y A7- pero flujos cercanos si –A1 y A2-). 21
  22. 22. Escenarios seleccionados para el ejemplo 22 SC1 – Flujo Básico SC9 – A8 SC2 – A1 SC10 – A1, A2 SC3 – A2 SC11 – A3,A4 SC4 – A3 SC12 – A4, A5 SC5 – A4 SC13 – A3, A5 SC6 – A5 SC14 – A6, A7 SC7 – A6 SC15 – A7, A8 SC8 – A7
  23. 23. De los escenarios a los Casos de Prueba  Ya que se tienen los escenarios, ahora se pueden obtener los CP mediante los siguientes pasos: 1. Identifica las variables para cada paso del CU 2. Identifica opciones diferentes significativas para cada variable 3. Combina las opciones a ser probadas en los CP. 4. Asigna valores a las variables. 23
  24. 24. 1.- Identificar las variables para cada paso del CU  Necesitas identificar todas las variables en todos los pasos de un escenario dado.  Ej.- Si en un paso el usuario captura su ID y Password, existen dos variables.  Ej.- Una variable puede ser la selección de un usuario (“Salvar cambios”, “Cancelar”).  Para el ejemplo:  B2: Dos variables “string”: e-mail y password  B3: El “string” de búsqueda  B4: El libro seleccionado a partir de la lista que regresa el sistema.  B8: La opción de embarque (Amazon ofrece hasta cuatro alternativas) 24
  25. 25. 2.-Identificar opciones significativas diferentes para cada variable  Las “Opciones significativas diferentes” serán aquellas que disparan diferentes comportamientos del sistema.  Por ejemplo si seleccionamos un ID de usuario de 6 a 10 caracteres, las siguientes entradas son significativamente diferentes:  Alex – breve, esperamos un mensaje de error.  Alexandria – una entrada válida.  Alexandrena – grande, esperamos un mensaje de advertencia.  Sin embargo “Alexandria” y “JohnGordon” no son significativamente diferentes, causarían la misma reacción del sistema. 25
  26. 26. 2.-(…)Opciones significativas diferentes – Líneas guía Una opción es “significativamente diferente” si: 1. Dispara un flujo diferente del proceso (usualmente un flujo alternativo). 1. Ej.- Un password inválido dispararía A2 2. Dispara un mensaje de error diferente. 1. Ej.- e-mail largo, el mensaje “email no mayor a 50 caracteres” 2. Ej.- e-mail que no tiene la “@”, el mensaje “email inválido” 3. Causa una apariencia diferente de la IU. 1. Ej.- Si el método de pago es con tarjeta de crédito, campos para capturar el número de la tarjeta de crédito, fecha de expiración y nombre del tarjetahabiente. 4. Causa que una selección diferente esté disponible en los drop-downs. 1. Ej.- En la pantalla de registro se muestran dos listas drop-down: pais y estado. Dependiendo del país se mostraran valores distintos (USA, Canada y otros países) 26
  27. 27. 2.-(…)Opciones significativas diferentes – Líneas guía  Una opción es “significativamente diferente” si: 5. Es una entrada a alguna regla de negocio. 1. Ej.- Suponga la regla “Si la orden se coloca después de las 6 pm y el usuario selecciona ‘embarque nocturno’ el mensaje mostrará que el libro llegará después de mañana”. Se podrían tener 2 opciones: (1) Embarque nocturno, orden colocada después de las 6 pm (2) Embarque nocturno, orden colocada antes de las 6 pm. 5. Una condición de frontera. 1. Ej.- Si el password es de 6 caracteres, probar con 5 y 6 caracteres 27
  28. 28. 2.-(…)Opciones significativas diferentes – Líneas guía  Una opción es “significativamente diferente” si: 7. Algo está cambiado VS valor por default. 1. Ej.- En la pantalla de pago a crédito el nombre del tarjetahabiente se rellena con el nombre de la persona que porta la tarjeta, esto crea dos opciones separadas: (1) Mantener el nombre o (2) Cambiar el nombre por uno diferente. 7. El formato de la entrada no está claramente definido y puede ser interpretado por el usuario. 1. Ej.- Los números telefónicos se pueden escribir distinto por diferentes personas: (973)1234567, 973-123-4567, 973 123 4567 7. Cuando casos regulares difieren en países distintos: 1. Ej.- La fecha de expiración de la tarjeta puede tener un formato distinto en USA y Europa 28
  29. 29. 2.-(…)Opciones significativas diferentes – Líneas guía  Una opción es “significativamente diferente” si: 10. Si se están probando números se podrían considerar las siguientes opciones:  Números regulares, razonables desde el punto de vista de la aplicación actual.  El cero  Números negativos  Un número con 2 decimales  El mayor número que se pueda capturar (9999999999 – tantos 9’s como se puedan capturar)  Aspecto importante: documentar la longitud máxima y mínima de los números antes de hacer las pruebas.  ¿Dónde documentarlos? Candidatos: sección Requisitos Especiales del CU, glosario, diccionario de datos un documento especial para ello. 29
  30. 30. 2.- Opciones identificadas para variables en el Flujo Básico del Ejemplo 30 Paso Variable Opciones a probar B1 Website URL actual B2 Email Regular Blank Min allowed (1 char) Max allowed (50 char) One more allowed (51 char) Very long (257 char) Invalid (no @ sign) B2 Password Regular Blank Too short (5 char) Min allowed (6 char) Max allowed (10 char) One more than allowed (11 char) Very long (257 char) B3 Search string Regular Blank Min allowed (1 char) Max allowed (300 char) One more than allowed (301 char) B4 Selection First selection Last select ion
  31. 31. 2.- Opciones identificadas para variables en el Flujo Básico del Ejemplo 31 Paso Variable Opciones a probar B5 Action selection Add to shopping cart B6 Action selection Proceed to checkout B7 Shipping address Confirm the address on file B8 Shipping method 5 days 3 days 2 days Overnight B9 Payment method Confirm the credit card on file B10 Action selection Place an order
  32. 32. 3.- Combinar las opciones a ser probadas en los Casos de Prueba  Las opciones identificadas en el paso anterior ahora se combinarán en la secuencia de pasos del Caso de Prueba.  Esto se facilita mediante una representación gráfica de las opciones a probar 32
  33. 33. 3.- Combinar las opciones a ser probadas en los Casos de Prueba-Diagrama gráfico 33 Errores que desvían del flujo básico a flujos alternativos Las opciones de error se pueden omitir de los casos de prueba porque no forman parte del flujo básico, se probarán en otro CP
  34. 34. 3.- Crear los Casos de Prueba conectando círculos … 34
  35. 35. 3.- Creando los Casos de Prueba  Para crear el primer CP seleccionas y conectas cualquier opción.  Al crear el segundo CP seleccionas una de las opciones que no se utilizó en el primero.  Continua agregando CP hasta que todos los nodos del grafo se cubren.  Generalmente se necesitarán de 4 a 6 CP para cubrir todas las opciones que deberían probarse. Aunque tome en cuenta que se pudieran tener situaciones específicas. 35
  36. 36. 3.- Casos de Prueba Representación Matricial 36 Paso Variable o selección CP1 CP2 CP3 CP4 B1 Website Actual URL Actual URL Actual URL Actual URL B2 Email Regular Min allowed (1 char) Max allowed (50 char) Regular B2 Password Regular Min allowed (6 char) Max allowed (10 char) Min allowed (6 char) B3 Search string Regular Min allowed (1 char) Max allowed (300 char) Regular B4 Selection First selection Last selection First selection Last selection B5 Action selection Add to shopping cart Add to shopping cart Add to shopping cart Add to shopping cart
  37. 37. 3.- Casos de Prueba Representación Matricial 37 Paso Variable o selección CP1 CP2 CP3 CP4 B6 Action selection Proceed to checkout Proceed to checkout Proceed to checkout Proceed to checkout B7 Shipping address Confirm the address on file Confirm the address on file Confirm the address on file Confirm the address on file B8 Shipping method 5 days 3 days 2 days Overnight B9 Payment method Confirm the credit card on file Confirm the credit card on file Confirm the credit card on file Confirm the credit card on file B10 Action selection Action selection Action selection Action selection Action selection
  38. 38. 4.- Asignar valores a las variables  Se reemplazan los “espacios” como “Apellido muy largo” o “Número telefónico muy largo” con valores como “Georgiamitsopolis” o “011-48(242)425-3456 ext. 1234”  Además se dividen los CP de la matriz anterior, creando una tabla separada para cada CP dando valores a las variables y dejando espacios para que el “tester” aplique la prueba. 38
  39. 39. 4.- Tabla para el “tester”- 1 CP 39 Paso Variable o selección Valor Resultado esperado Resultado actual Pasó/Falló Comentarios B1 Website www.amazon.comLogon screen B2 Email jsmith@hotmail.com B2 Password Johnsm Main Screen B3 Search string “UML” List of books B4 Book selection First selection Book details B5 Action selection Add to shopping cart Cart contents B6 Action selection Proceed to checkout Prompt for Address
  40. 40. 4.- Tabla para el “tester”- 1 CP 40 Paso Variable o selección Valor Resultado esperado Resultado actual Pasó/Falló Comentarios B7 Shipping address Confirm the address on file Prompt for payment B8 Shipping method 5 days Prompt for payment B9 Payment method Confirm the credit card on file Prompt for confirmation B10 Action selection Place en order Order number
  41. 41. Ubicación de los CP respecto al UP 41

×