prueba de aplicaciones convencionales

1,558 views

Published on

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,558
On SlideShare
0
From Embeds
0
Number of Embeds
27
Actions
Shares
0
Downloads
65
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

prueba de aplicaciones convencionales

  1. 1. PRUEBA DE APLICACIONES CONVENCIONALES. INGENIERÍA DE SOFTWARE UN ENFOQUE PRÁCTICO ROGER S. PRESSMAN. CAPÍTULO 18
  2. 2. PRUEBAS EN EL SOFTWARE • Se requiere que el desarrollador deseche nociones preconcebidas sobre lo “correcto” para diseñar casos de prueba a fin de “romper” el software. • La meta de probar es encontrar errores
  3. 3. COMPROBABILIDAD DEL SOFTWARE. Operatividad • Mientras mejor funcione, más eficientemente puede probarse. Observabilidad • Lo que ve es lo que prueba. Controlabilidad • Mientras mejor pueda controlar el software, más podrá automatizar y optimizar las pruebas.
  4. 4. COMPROBABILIDAD DEL SOFTWARE. Descomponibilidad • Al controlar el ámbito de las pruebas, es posible aislar más rápidamente los problemas y realizar pruebas nuevas y más inteligentes. Simplicidad. • Mientras haya menos que probar, más rápidamente se le puede probar. Estabilidad. • Mientras menos cambios, menos perturbaciones para probar.
  5. 5. COMPROBABILIDAD DEL SOFTWARE. Comprensibilidad • Mientras más información se tenga, se probará con más inteligencia.
  6. 6. ATRIBUTOS DE UNA BUENA PRUEBA Alta probabilidad de encontrar un error No ser redundante No debe ser demasiado simple o demasiado compleja
  7. 7. 18.3 - PRUEBAS DE CAJA BLANCA
  8. 8. PRUEBAS DE CAJA BLANCA • La prueba de caja blanca del software se basa en el examen cercano de los detalles de procedimiento. Las rutas lógicas a través del software y las colaboraciones entre componentes.
  9. 9. CARACTERÍSTICAS Garantizar que todas las rutas independientes dentro de un módulo se revisaron al menos una vez. Ejecutar todos los bucles en sus fronteras y dentro de sus fronteras operativas. Revisar todas las decisiones lógicas en sus lado verdadero y falso. Revisar estructuras de datos internas para garantizar su validez.
  10. 10. 18.4 - PRUEBA DE RUTA BÁSICA
  11. 11. PRUEBA DE RUTA BÁSICA • Permite al diseñador de casos de prueba definir un conjunto básico de rutas de ejecución. • Los casos de prueba obtenidos tienen la garantía de ejecutar todo enunciado en el programa, al menos una vez durante la prueba.
  12. 12. NOTACIÓN DE GRÁFICO O GRAFO DE FLUJO • Es una forma de representar los procesos y el flujo de control lógico, dentro de la ejecución de un programa.
  13. 13. NOTACIÓN DE GRÁFICO O GRAFO DE FLUJO
  14. 14. RUTAS DE PROGRAMA INDEPENDIENTES • Una ruta independiente es cualquiera que introduce al menos un nuevo conjunto de enunciados de procesamiento o una nueva condición en el programa • ruta 1: 1-11 • ruta 2: 1-2-3-4-5-10-1-11 • ruta 3: 1-2-3-6-8-9-10-1-11 • ruta 4: 1-2-3-6-7-9-10-1-11 • Ruta no independiente: 1-2-3-4-5-10-1-2-3-6-8-9-10-1-11
  15. 15. COMPLEJIDAD CICLOMÁTICA • Es una medición de software que proporciona una evaluación cuantitativa de la complejidad lógica de un programa. • Define el número de rutas independientes
  16. 16. MEDIR COMPLEJIDAD CICLOMÁTICA 1. Por el número de regiones •4 2. Aristas – Nodos + 2 • 11 – 9 + 2 = 4 3. NodosPredicado + 1 • 3+1=4 • // NodoPredicado.- De los cuales emanan dos o más aristas.
  17. 17. EJEMPLO (ALGORITMO)
  18. 18. EJEMPLO (GRAFO)
  19. 19. EJEMPLO (COMPLEJIDAD CICLOMÁTICA) • 6 regiones • 17 aristas -13 nodos + 2 = 6 • 5 nodos predicado + 1 = 6
  20. 20. EJEMPLO (RUTA BÁSICA) • • • • • • ruta 1: 1-2-10-11-13 ruta 2: 1-2-10-12-13 ruta 3: 1-2-3-10-11-13 ruta 4: 1-2-3-4-5-8-9-2-... ruta 5: 1-2-3-4-5-6-8-9-2-... ruta 6: 1-2-3-4-5-6-7-8-9-2-... • Preparar casos de prueba que fuercen la ejecución de cada ruta
  21. 21. 18.5 - PRUEBA DE LA ESTRUCTURA DE CONTROL ESTA PRUEBA ES MÁS AMPLIA, CUBRE Y MEJORA LA CALIDAD DE LA PRUEBA DE CAJA BLANCA.
  22. 22. PRUEBA DE CONDICIÓN • Es un método de diseño de casos de prueba que revisa las condiciones lógicas contenidas en un módulo de programa • Se enfoca en la prueba de cada condición del programa para asegurar que no contiene errores
  23. 23. PRUEBA DE FLUJO DE DATOS • Selecciona rutas de prueba de un programa de acuerdo con las ubicaciones de las definiciones y con el uso de variables en el programa.
  24. 24. PRUEBA DE BUCLE • Es una técnica de prueba de caja blanca que se enfoca exclusivamente en la validez de los constructos bucle. • Bucles: • • • • Simples Concatenados Anidados No estructurados
  25. 25. BUCLES
  26. 26. 18.6 - PRUEBAS DE CAJA NEGRA
  27. 27. PRUEBAS DE CAJA NEGRA • También llamadas pruebas de comportamiento, se enfocan en los requerimientos funcionales del software; es decir, revisarán por completo todos los requerimientos funcionales para un programa • No son una alternativa para las técnicas de caja blanca sino un complemento, es probable que se descubra una clase de errores diferente. • Tienden a aplicarse durante las últimas etapas de las pruebas.
  28. 28. TIPOS DE ERRORES PARA CAJA NEGRA • Las pruebas de caja negra están orientadas a descubrir el siguiente tipo de errores • Funciones incorrectas o faltantes • Errores de interfaz • Errores en las estructuras de datos o en el acceso a datos. • Errores de comportamiento o rendimiento • Errores de inicialización y terminación
  29. 29. ANÁLISIS DE VALOR DE FRONTERA • Un mayor número de errores ocurre en las fronteras del dominio de entrada y no en el “centro”. Por esta razón es que el análisis de valor de frontera se desarrolló como una técnica de prueba. • Si una condición de entrada/salida especifica un rango de valores entre a y b, los casos de prueba deben designarse con valores a y b, justo arriba y justo abajo de a y b.
  30. 30. PRUEBA BASADA EN MODELO EN MUCHOS CASOS, USA DIAGRAMAS DE ESTADO UML
  31. 31. PRUEBA BASADA EN MODELO • Es una técnica de prueba de caja negra que usa la información contenida en el modelo de requerimientos como la base para la generación de casos de prueba.
  32. 32. PASOS 1 • Analizar un modelo de comportamiento existente para el software. 2 • Recorrer el modelo de comportamiento y especificar las entradas que forzarán al software a realizar la transición de estado a estado 3 • Revisar el modelo de comportamiento y observar las salidas esperadas, conforme el software realiza la transición de estado a estado.
  33. 33. PASOS 4 5 • Ejecutar los casos de prueba • Comparar los resultados reales y esperados y adoptar una acción correctiva según se requiera
  34. 34. PRUEBA PARA ENTORNOS, ARQUITECTURAS Y APLICACIONES ESPECIALIZADAS
  35. 35. PRUEBAS DE INTERFACES GRÁFICAS DE USUARIO • La complejidad de las GUI ha crecido, lo que conduce a más dificultad en el diseño y ejecución de los casos de prueba. • Debido a que muchas GUI modernas tienen la misma apariencia y ambiente, puede derivarse una serie de pruebas estándar
  36. 36. PRUEBA DE ARQUITECTURAS CLIENTE-SERVIDOR • Pruebas de función de aplicación. • Pruebas de servidor. • Pruebas de base de datos. • Pruebas de transacción. • Pruebas de comunicación de red.
  37. 37. PRUEBA DE ARQUITECTURAS CLIENTE-SERVIDOR • Se recomienda el desarrollo de perfiles operativos derivados de escenarios de uso cliente-servidor. • Un perfil operativo indica cómo interactúan con el sistema cliente-servidor diferentes tipos de usuarios. • Es decir, los perfiles proporcionan un “patrón de uso” que puede aplicarse cuando las pruebas se diseñan y ejecutan.
  38. 38. PRUEBAS A LA DOCUMENTACIÓN • Los errores en la documentación pueden ser tan devastadores para la aceptación del programa como los errores en los datos o en el código fuente. • Por esta razón, las pruebas de documentación deben ser parte significativa de todo plan de prueba de software
  39. 39. GRACIAS. By: Carlos Yoong.

×