El documento describe la importancia de las pruebas de software para encontrar defectos y reducir costos. Menciona que las pruebas deben realizarse por equipos independientes utilizando casos de prueba válidos e inválidos. También presenta estándares y técnicas de pruebas como caja blanca y negra, así como clasificaciones como pruebas unitarias, de integración y de aceptación.

1. Pruebas de software

2. ¿Por qué probar? 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.

3. ¿Por qué probar? 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. Automatizar el proceso de pruebas consigue reducciones de hasta un 75% en el costo de la fase de mantenimiento.

4. ¿Quiénes deben de probar o que se debe probar? Cada caso de prueba debe definir el resultado de salida esperado. El programador debe evitar probar sus propios programas, ya que desea (consciente o inconscientemente) demostrar que funcionan sin problemas. Se debe inspeccionar a conciencia el resultado de cada prueba, así, poder descubrir posibles síntomas de defectos.

5. ¿Quiénes deben de probar o que se debe probar? Al generar casos de prueba, se deben incluir tanto datos de entrada válidos y esperados como no válidos e inesperados. Las pruebas deben centrarse en dos objetivos: Probar si el software no hace lo que debe hacer Probar si el software hace lo que no debe hacer, es decir, si provoca efectos secundarios adversos.

6. ¿Quiénes deben de probar o que se debe probar? Se deben evitar los casos no documentados ni diseñados con cuidado. 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.

7. ¿Por qué no probar todo? Prácticamente imposible. Es imposible evaluar todas las posibilidades. Recursos (costos, tiempo, personal) ¿Cuántos ciclos de pruebas son suficientes?

8. Estándares Internacionales ISO 9126 Modelo de evaluación de calidad de software; aporta características sencillas de evaluación y medición. Modelo de calidad Métricas externas (Aseguramiento de calidad) Métricas internas (Desarrollo) Métricas de calidad en uso (Producto final)

9. Estándares Internacionales BS 7925 – 2 Estándar Británico para pruebas de componentes de software (Standard for Software Component Testing) 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.

10. Estándares Internacionales IEEE 829 Estándar para documentar pruebas de software. Especifica 8 etapas del proceso de documentación. Planeación de las pruebas Especificación del diseño de prueba Especificación de los casos de prueba Especificación del procedimiento Reporte de avance de los ciclos probados Registro de la prueba Reporte de incidentes Sumario de la prueba

11. Estándares Internacionales TPI (Test Process Improvement) Metodología para evaluar el nivel de madurez de pruebas en una organización, así como para mejorar el proceso.

12. Definiciones importantes 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. Caso de Prueba (test case): C onjunto de entradas y condiciones que arrojan resultados esperados desarrollados con un objetivo en particular.

13. Definiciones importantes Error Acción humana que produce o denera un resultado incorrecto. Defecto Es la manifestación de un error en el software. Un defecto es encontrado porque causa una FALLA , la cuál es una desviación del servicio o resultado esperado.

14. Definiciones importantes

15. Definiciones importantes Verificación Determinar si los productos de una fase dada satisfacen las condiciones impuestas al inicio de la fase. ¿Estamos construyendo correctamente el producto?

16. Definiciones importantes Validación Evaluación de un sistema o uno de sus componentes durante o al final de su desarrollo para determinar si satisface los requisitos. ¿Estamos construyendo el producto correcto?

17. Modelos de desarrollo de software

18. Modelo en V

19. Modelo iterativo

20. Modelo en cascada

21. Clasificación de las pruebas Pruebas unitarias (componente, modulares o programa) Ejecutadas usualmente por los desarrolladores. Técnicas de caja blanca. Importante definir nivel de dependencia, a mayor independencia mayor efectividad.

22. Clasificación de las pruebas Pruebas de sistemas Ejecutadas por los desarrolladores o equipo de pruebas en un ambiente controlado. Deben demostrar que los sistemas cumplen con los requerimientos detallados en los documentos de especificaciones de funcionalidad y calidad. Tipos: Funcionales No funcionales

23. Clasificación de las pruebas Pruebas de integración Ejecutadas para exponer fallas en interfases y en la interacción entre componentes. Ejecutadas por los desarrolladores. Técnicas: Big bang Top down Bottom up Middle-out

24. Clasificación de las pruebas Funcionales: Requerimientos No funcionales: Carga Estrés Usabilidad Volumen Documentación Desempeño Seguridad Almacenamiento Instalación Recuperación

25. Clasificación de las pruebas Pruebas de aceptación Ejecutadas por los usuarios y líderes de proyecto ó administradores en un ambiente simulado de operación. Deben demostrar que los sistemas cumplen con los requerimientos detallados en los documentos de especificaciones de funcionalidad y calidad.

26. Clasificación de las pruebas Pruebas de regresión Determinar que las modificaciones no han causado fallas o efectos adversos. Determina que se cumple con los requerimientos. Modificaciones menores selección de pruebas. Construir paquetes de pruebas de regresión, actualizarlas.

27. Pruebas de caja Existen tres enfoques para el diseño de casos de prueba: El enfoque estructural o de caja blanca El enfoque funcional o de caja negra 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

28. Pruebas de caja

29. Pruebas de caja BLANCA 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. Las pruebas dinámicas se dividen en dos: Explícitas: Ejecución de los casos de prueba, comparar los resultados obtenidos con los esperados. Implícitas: Análisis de los datos o información que el sistema entrega, para detectar funcionamientos erróneos.

30. Técnicas de caja BLANCA Métricas de complejidad Statement testing Decision coverage Condition Coverage

31. Métricas de complejidad Complejidad ciclomatica Mide el número de decisiones lógicas dentro de un segmento de código. Número de rutas de prueba recomendado como mínimo a probar. 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.

32. edge node arista

33. Complejidad ciclomatica Calculando v(G) Formal (edges and nodes) v(G) = e-n+2 Predicate (aristas) v(G) = p+1 Regiones v(G)=R

34. Statement Testing Test_func(int a, int b){ If(a==b) Op1(); Else Op2(); If(a==c) Op3(); Else Op4();

35. Statement Testing Rutas probadas Test 1 if(a==b)  true If (a==c)  True Test 2 if(a==b)  false if(a==c)  false Resultados de cobertura Test 1: 7 líneas probadas  64% Test 2: 9 líneas probadas  82% Test 1 & 2 : 11 líneas probadas  100% 2 pruebas requeridas

36. Decision Coverage Test_func(int a, int b){ If(a==b) Op1();  Branch 1 Else Op2();  Branch 2 If(a==c) Op3();  Branch 3 Else Op4();  Branch 4

37. Decision Coverage Rutas probadas Test 1 if(a==b)  true If (a==c)  True Test 2 if(a==b)  false if(a==c)  false Resultados de cobertura Test 1: 2 ramas probadas  50% Test 2: 2 ramas probadas  50% Test 1 & 2 : 4 ramas probadas  100% 2 pruebas requeridas

38. Condition Coverage Examinar cada punto de decisión. Tablas de verdad. No es fácil implementar. If (a==b or a==c) Op1(); F F F 3 T T F 2 T - T 1 Resultado C1 C0 Test #