Pruebas De Software

63,120 views

Published on

Referencias. Ingeniería del Software I, por César Javier Acuña. IEEE.

Published in: Technology, Business
9 Comments
95 Likes
Statistics
Notes
  • Gracias esta buena la presentacion cree usted posible que la pueda acceder indicarme como hacerlo ya que me seria de mucha utilidad el tenerla
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • como puedo desarrollar mi grafo de pruebas fácil y rapido
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Buenos Días, hay manera de que me envira la presentacion , necesito guiarme para hacer mi proyecto de la universidad y la verdad me serviria de mucho. Gracias esta muy bueno el contenido.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • hola buen día me párese perfecta las diapositivas abra alguna forma de q me en vies la presentación ya que es indispensable para mi trabajo ya que soy ¨ TESTER ¨y es de gran ayuda saludos...........
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Hola, podrías apoyarme enviándome tu presentación, me parece muy bien estructurada y me serviría como base para mi tarea... gracias...
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
63,120
On SlideShare
0
From Embeds
0
Number of Embeds
1,168
Actions
Shares
0
Downloads
0
Comments
9
Likes
95
Embeds 0
No embeds

No notes for slide

Pruebas De Software

  1. 1. Pruebas de software
  2. 2. ¿Por qué probar? <ul><li>Las fallas de software ocasionan graves pérdidas económicas; éstos son 100 a 1000 veces más costosos de encontrar y reparar después de la construcción. </li></ul>
  3. 3. ¿Por qué probar? <ul><li>Evitar plazos y presupuestos incumplidos, insatisfacción del usuario, escasa productividad y mala calidad en el software producido y finalmente la p érdida de clientes. </li></ul><ul><li>Automatizar el proceso de pruebas consigue reducciones de hasta un 75% en el costo de la fase de mantenimiento. </li></ul>
  4. 4. ¿Quiénes deben de probar o que se debe probar? <ul><li>Cada caso de prueba debe definir el resultado de salida esperado. </li></ul><ul><li>El programador debe evitar probar sus propios programas, ya que desea (consciente o inconscientemente) demostrar que funcionan sin problemas. </li></ul><ul><li>Se debe inspeccionar a conciencia el resultado de cada prueba, así, poder descubrir posibles síntomas de defectos. </li></ul>
  5. 5. ¿Quiénes deben de probar o que se debe probar? <ul><li>Al generar casos de prueba, se deben incluir tanto datos de entrada válidos y esperados como no válidos e inesperados. </li></ul><ul><li>Las pruebas deben centrarse en dos objetivos: </li></ul><ul><ul><li>Probar si el software no hace lo que debe hacer </li></ul></ul><ul><ul><li>Probar si el software hace lo que no debe hacer, es decir, si provoca efectos secundarios adversos. </li></ul></ul>
  6. 6. ¿Quiénes deben de probar o que se debe probar? <ul><li>Se deben evitar los casos no documentados ni diseñados con cuidado. </li></ul><ul><li>No deben hacerse planes de prueba suponiendo que, prácticamente, no hay defectos en los programas y, por lo tanto, dedicando pocos recursos a las pruebas. </li></ul>
  7. 7. ¿Por qué no probar todo? <ul><li>Prácticamente imposible. </li></ul><ul><li>Es imposible evaluar todas las posibilidades. </li></ul><ul><li>Recursos (costos, tiempo, personal) </li></ul><ul><li>¿Cuántos ciclos de pruebas son suficientes? </li></ul>
  8. 8. Estándares Internacionales <ul><li>ISO 9126 </li></ul><ul><ul><li>Modelo de evaluación de calidad de software; aporta características sencillas de evaluación y medición. </li></ul></ul><ul><ul><ul><li>Modelo de calidad </li></ul></ul></ul><ul><ul><ul><li>Métricas externas (Aseguramiento de calidad) </li></ul></ul></ul><ul><ul><ul><li>Métricas internas (Desarrollo) </li></ul></ul></ul><ul><ul><ul><li>Métricas de calidad en uso (Producto final) </li></ul></ul></ul>
  9. 9. Estándares Internacionales <ul><li>BS 7925 – 2 </li></ul><ul><ul><li>Estándar Británico para pruebas de componentes de software (Standard for Software Component Testing) </li></ul></ul><ul><ul><li>Describe técnicas para el diseño y medición de casos de prueba, trata la ejecución y análisis de los resultados, características a seleccionar para determinar, comparar y mejorar la calidad de la prueba. </li></ul></ul>
  10. 10. Estándares Internacionales <ul><li>IEEE 829 </li></ul><ul><ul><li>Estándar para documentar pruebas de software. Especifica 8 etapas del proceso de documentación. </li></ul></ul><ul><ul><ul><li>Planeación de las pruebas </li></ul></ul></ul><ul><ul><ul><li>Especificación del diseño de prueba </li></ul></ul></ul><ul><ul><ul><li>Especificación de los casos de prueba </li></ul></ul></ul><ul><ul><ul><li>Especificación del procedimiento </li></ul></ul></ul><ul><ul><ul><li>Reporte de avance de los ciclos probados </li></ul></ul></ul><ul><ul><ul><li>Registro de la prueba </li></ul></ul></ul><ul><ul><ul><li>Reporte de incidentes </li></ul></ul></ul><ul><ul><ul><li>Sumario de la prueba </li></ul></ul></ul>
  11. 11. Estándares Internacionales <ul><li>TPI (Test Process Improvement) </li></ul><ul><ul><li>Metodología para evaluar el nivel de madurez de pruebas en una organización, así como para mejorar el proceso. </li></ul></ul>
  12. 12. Definiciones importantes <ul><li>Prueba (test): A ctividad en la cual se somete a un sistema o uno de sus componentes a una evaluación de los resultados que arroja en base a la ejecución de éste en condiciones especificadas. </li></ul><ul><li>Caso de Prueba (test case): C onjunto de entradas y condiciones que arrojan resultados esperados desarrollados con un objetivo en particular. </li></ul>
  13. 13. Definiciones importantes <ul><li>Error </li></ul><ul><ul><li>Acción humana que produce o denera un resultado incorrecto. </li></ul></ul><ul><li>Defecto </li></ul><ul><ul><li>Es la manifestación de un error en el software. </li></ul></ul><ul><li>Un defecto es encontrado porque causa una FALLA , la cuál es una desviación del servicio o resultado esperado. </li></ul>
  14. 14. Definiciones importantes
  15. 15. Definiciones importantes <ul><li>Verificación </li></ul><ul><ul><li>Determinar si los productos de una fase dada satisfacen las condiciones impuestas al inicio de la fase. </li></ul></ul><ul><ul><li>¿Estamos construyendo correctamente el producto? </li></ul></ul>
  16. 16. Definiciones importantes <ul><li>Validación </li></ul><ul><ul><li>Evaluación de un sistema o uno de sus componentes durante o al final de su desarrollo para determinar si satisface los requisitos. </li></ul></ul><ul><ul><li>¿Estamos construyendo el producto correcto? </li></ul></ul>
  17. 17. Modelos de desarrollo de software
  18. 18. Modelo en V
  19. 19. Modelo iterativo
  20. 20. Modelo en cascada
  21. 21. Clasificación de las pruebas <ul><li>Pruebas unitarias (componente, modulares o programa) </li></ul><ul><ul><li>Ejecutadas usualmente por los desarrolladores. </li></ul></ul><ul><ul><li>Técnicas de caja blanca. </li></ul></ul><ul><ul><li>Importante definir nivel de dependencia, a mayor independencia mayor efectividad. </li></ul></ul>
  22. 22. Clasificación de las pruebas <ul><li>Pruebas de sistemas </li></ul><ul><ul><li>Ejecutadas por los desarrolladores o equipo de pruebas en un ambiente controlado. </li></ul></ul><ul><ul><li>Deben demostrar que los sistemas cumplen con los requerimientos detallados en los documentos de especificaciones de funcionalidad y calidad. </li></ul></ul><ul><ul><li>Tipos: </li></ul></ul><ul><ul><ul><li>Funcionales </li></ul></ul></ul><ul><ul><ul><li>No funcionales </li></ul></ul></ul>
  23. 23. Clasificación de las pruebas <ul><li>Pruebas de integración </li></ul><ul><ul><li>Ejecutadas para exponer fallas en interfases y en la interacción entre componentes. </li></ul></ul><ul><ul><li>Ejecutadas por los desarrolladores. </li></ul></ul><ul><ul><li>Técnicas: </li></ul></ul><ul><ul><ul><li>Big bang </li></ul></ul></ul><ul><ul><ul><li>Top down </li></ul></ul></ul><ul><ul><ul><li>Bottom up </li></ul></ul></ul><ul><ul><ul><li>Middle-out </li></ul></ul></ul>
  24. 24. Clasificación de las pruebas <ul><li>Funcionales: </li></ul><ul><ul><li>Requerimientos </li></ul></ul><ul><li>No funcionales: </li></ul><ul><ul><li>Carga </li></ul></ul><ul><ul><li>Estrés </li></ul></ul><ul><ul><li>Usabilidad </li></ul></ul><ul><ul><li>Volumen </li></ul></ul><ul><ul><li>Documentación </li></ul></ul><ul><ul><li>Desempeño </li></ul></ul><ul><ul><li>Seguridad </li></ul></ul><ul><ul><li>Almacenamiento </li></ul></ul><ul><ul><li>Instalación </li></ul></ul><ul><ul><li>Recuperación </li></ul></ul>
  25. 25. Clasificación de las pruebas <ul><li>Pruebas de aceptación </li></ul><ul><ul><li>Ejecutadas por los usuarios y líderes de proyecto ó administradores en un ambiente simulado de operación. </li></ul></ul><ul><ul><li>Deben demostrar que los sistemas cumplen con los requerimientos detallados en los documentos de especificaciones de funcionalidad y calidad. </li></ul></ul>
  26. 26. Clasificación de las pruebas <ul><li>Pruebas de regresión </li></ul><ul><ul><li>Determinar que las modificaciones no han causado fallas o efectos adversos. </li></ul></ul><ul><ul><li>Determina que se cumple con los requerimientos. </li></ul></ul><ul><ul><li>Modificaciones menores selección de pruebas. </li></ul></ul><ul><ul><li>Construir paquetes de pruebas de regresión, actualizarlas. </li></ul></ul>
  27. 27. Pruebas de caja <ul><li>Existen tres enfoques para el diseño de casos de prueba: </li></ul><ul><ul><li>El enfoque estructural o de caja blanca </li></ul></ul><ul><ul><li>El enfoque funcional o de caja negra </li></ul></ul><ul><ul><li>El enfoque aleatorio consiste en utilizar modelos (en muchas ocasiones estadísticos) que representen las posibles entradas al programa para crear a partir de ellos los casos de prueba </li></ul></ul>
  28. 28. Pruebas de caja
  29. 29. Pruebas de caja BLANCA <ul><li>Las pruebas de caja blanca realizan un seguimiento del código fuente de manera que se determinan las instrucciones, bloques, etc. en los que existen errores. </li></ul><ul><li>Las pruebas dinámicas se dividen en dos: </li></ul><ul><ul><li>Explícitas: Ejecución de los casos de prueba, comparar los resultados obtenidos con los esperados. </li></ul></ul><ul><ul><li>Implícitas: Análisis de los datos o información que el sistema entrega, para detectar funcionamientos erróneos. </li></ul></ul>
  30. 30. Técnicas de caja BLANCA <ul><li>Métricas de complejidad </li></ul><ul><li>Statement testing </li></ul><ul><li>Decision coverage </li></ul><ul><li>Condition Coverage </li></ul>
  31. 31. Métricas de complejidad <ul><li>Complejidad ciclomatica </li></ul><ul><ul><li>Mide el número de decisiones lógicas dentro de un segmento de código. </li></ul></ul><ul><ul><li>Número de rutas de prueba recomendado como mínimo a probar. </li></ul></ul><ul><ul><li>Complejidad ciclomatica, v, es la medida de la complejidad lógica de un módulo “G” y el esfuerzo mínimo necesario para calificarlo. V es el número de rutas lineares independientes de un módulo “G”, por lo tanto es el número mínimo de rutas que deben probarse. </li></ul></ul>
  32. 32. edge node arista
  33. 33. Complejidad ciclomatica <ul><li>Calculando v(G) </li></ul><ul><ul><li>Formal (edges and nodes) </li></ul></ul><ul><ul><ul><li>v(G) = e-n+2 </li></ul></ul></ul><ul><ul><li>Predicate (aristas) </li></ul></ul><ul><ul><ul><li>v(G) = p+1 </li></ul></ul></ul><ul><ul><li>Regiones </li></ul></ul><ul><ul><ul><li>v(G)=R </li></ul></ul></ul>
  34. 34. Statement Testing <ul><li>Test_func(int a, int b){ </li></ul><ul><ul><li>If(a==b) </li></ul></ul><ul><ul><ul><li>Op1(); </li></ul></ul></ul><ul><ul><li>Else </li></ul></ul><ul><ul><ul><li>Op2(); </li></ul></ul></ul><ul><ul><li>If(a==c) </li></ul></ul><ul><ul><ul><li>Op3(); </li></ul></ul></ul><ul><ul><li>Else </li></ul></ul><ul><ul><ul><li>Op4(); </li></ul></ul></ul>
  35. 35. Statement Testing <ul><li>Rutas probadas </li></ul><ul><ul><li>Test 1 if(a==b)  true </li></ul></ul><ul><ul><li>If (a==c)  True </li></ul></ul><ul><li> Test 2 if(a==b)  false </li></ul><ul><li>if(a==c)  false </li></ul><ul><li>Resultados de cobertura </li></ul><ul><li>Test 1: 7 líneas probadas  64% </li></ul><ul><li>Test 2: 9 líneas probadas  82% </li></ul><ul><li>Test 1 & 2 : 11 líneas probadas  100% </li></ul><ul><li>2 pruebas requeridas </li></ul>
  36. 36. Decision Coverage <ul><li>Test_func(int a, int b){ </li></ul><ul><ul><li>If(a==b) </li></ul></ul><ul><ul><ul><li>Op1();  Branch 1 </li></ul></ul></ul><ul><ul><li>Else </li></ul></ul><ul><ul><ul><li>Op2();  Branch 2 </li></ul></ul></ul><ul><ul><li>If(a==c) </li></ul></ul><ul><ul><ul><li>Op3();  Branch 3 </li></ul></ul></ul><ul><ul><li>Else </li></ul></ul><ul><ul><ul><li>Op4();  Branch 4 </li></ul></ul></ul>
  37. 37. Decision Coverage <ul><li>Rutas probadas </li></ul><ul><ul><li>Test 1 if(a==b)  true </li></ul></ul><ul><ul><li>If (a==c)  True </li></ul></ul><ul><li> Test 2 if(a==b)  false </li></ul><ul><li>if(a==c)  false </li></ul><ul><li>Resultados de cobertura </li></ul><ul><li>Test 1: 2 ramas probadas  50% </li></ul><ul><li>Test 2: 2 ramas probadas  50% </li></ul><ul><li>Test 1 & 2 : 4 ramas probadas  100% </li></ul><ul><li>2 pruebas requeridas </li></ul>
  38. 38. Condition Coverage <ul><li>Examinar cada punto de decisión. </li></ul><ul><li>Tablas de verdad. </li></ul><ul><li>No es fácil implementar. </li></ul><ul><li>If (a==b or a==c) </li></ul><ul><ul><li>Op1(); </li></ul></ul>F F F 3 T T F 2 T - T 1 Resultado C1 C0 Test #

×