Sistemas de Información Administrativo - Universidad Diego Portales. Cátedra : Sistemas de Información Administrativa S.I.A.

Transcripción

1 Cátedra : Sistemas de Información Administrativa S.I.A. Escuela de Contadores Auditores Tema: Ingeniería del Software Estrategias de Pruebas Relator: Sr. Eduardo Leyton G

2 Pruebas del Software (Basado en IEEE) Una de las características típicas del desarrollo del software es la realización de controles periódicos coincidiendo con los hitos del proyecto, terminación de éste o en procesos de mantención. Los controles pretenden evaluar la calidad de los productos generados (aplicaciones, sistemas) para detectar defectos, errores o fallos en el producto de software. (calidad del Sw, cumplimiento de las ERS, cumple con los estándares de la empresa, los procesos y funcionamiento del sistema son de acuerdo a lo esperado, y verificar que la documentación del sistema es completa y suficiente) Fuera de estos controles, los productos deben ser probados mediante estrategias de pruebas efectuadas tanto por el área tecnológica (pruebas a) como por el área funcional (`pruebas b). Es decir verificar ( estamos construyendo correctamente el producto?) y validar ( estamos construyendo el producto correcto?) el software. Términos Técnicos: Pruebas (test) : Actividad en la cual un sistema o uno de sus componentes se ejecuta en circunstancias especificadas; los resultados se observan y se registran para su evaluación en algún aspecto previamente definido.

3 Caso Prueba (test case): Conjunto de E/S, condiciones de ejecución y resultados esperados desarrollados para un objetivo particular. (Modelo de Prueba estándar) Defecto (defect, fault, bug/calidad): defecto en el software, como un proceso, una definición de datos o un paso de procesamiento incorrecto en un programa o aplicación. Fallo (failure/ tecnológico o de instrumentación): Incapacidad de un sistema o de alguno de sus componentes para realizar las funciones requeridas dentro de los requisitos de rendimiento esperados o especificados. Error (error humano/instrumentación): a) diferencias entre valores calculados, observados o medidos; b) resultado incorrecto por función básica; c) defecto por instrucción de código incorrecta y d) acción humana (mistake) por mala operación.

4 Recomendaciones de G.J. Myers para pruebas: 1. Cada caso de prueba debe definir el resultado de salida esperado para su comparación con el resultado de la ejecución de la prueba. 2. El programador debe evitar probar sus propias aplicaciones. 3. Revisión acuciosa, (sep), para descubrir defectos. 4. Al efectuar casos de pruebas deben considerarse datos correctos, erróneos y extremos. (Análisis de Valores Límites) 5. Las pruebas deben centrarse en probar si el Sw NO hace lo que debe hacer y Si el Sw hace lo que NO debe hacer, es decir si genera efectos secundarios adversos. 6. Evitar probar aquellos casos no documentados o diseñados o probar códigos efectuados sobre la marcha. 7. Excesivo optimismo puede obviar o esconder inconscientemente defectos. 8. La P(x) de descubrir defectos o fallos en una parte del Sw es proporcional al numero de defectos ya descubiertos. Efecto en cadena, donde hay un fallo existe otro) 9. El diseño de pruebas requiere tanto o más creatividad que el mismo desarrollo. 10. Participación del usuario. Las pruebas están orientadas a satisfacer los requisitos de los usuarios (ERS). 11. Las pruebas son la fase final del proceso, por lo tanto los esfuerzos son para crear confianza que el producto de Sw es adecuado. 12. Se debe evitar probar que el sistema es perfecto, sólo probar que el Sw esta para su uso operativo. 13. No probar sin planificar en conjunto con AF-ATI. 14. Aplicar estrategias de paralelos en un entorno similar al potencialmente real. 15. Deben definirse Criterios de Aceptación de Pruebas. 16. Validar documentación y los procedimiento de uso, la auditabilidad y seguridad del sistema (confiabilidad, confidencialidad, consistencia, intrusión, sustracción => SL).

5 Tipos de Pruebas: 1. Estructural o de Caja Blanca: Ruteo /Trace código ENTRADA SALIDA Revisar íntegramente el código es impracticable: Programa 50 líneas con 25 sentencias IF en serie implica 33,5 millones de caminos. => Criterios de Cobertura Lógica (ruteo por materialidad) 2. Funcional o de Caja Negra: Pruebas integras I/O FUNCIONES Este tipo de pruebas se centra en el estudio de la especificación del software, del análisis de las funciones que debe realizar, de las entradas y salidas del mismo. También es impracticable ver todo Aleatorio: Modelos estadísticos de pruebas de I/O. Apoyo de herramientas de modelos matemáticos o software de pruebas como los SQA (Aseguramiento de Calidad de Software). 4. Pruebas de Unidad. Pruebas por separado, modulo por modulo. 5. Pruebas de Integración Incremental (Asc/Des) Pruebas de un modulo con otros (combinación) y después en forma integral. 6. Pruebas de Integración No Incremental (big bang) Pruebas por separado, modulo por modulo y después en forma integral.

6 El Proceso de Pruebas Configuración de las pruebas. Casos y procedimientos. Planificación de Pruebas Plan de Pruebas Diseño de Pruebas Ejecución de Pruebas Información sobre el proyecto. Desarrollo Información sobre el software. Correcciones Configuración del Software. Notificación de defectos del Software. Resultados Actividades Preventivas. Depuración Errores Evaluación Estadísticas de errores. Predicción de Fiabilidad. Análisis de Errores Resultados esperados.

7 Pruebas Técnicas de la Gerencia de Tecnología (aporte del Prof. R.Pizarro) Snapshot (vaciado de la memoria o dump) Se registra la imagen de parte de la memoria del computador que contiene los elementos de datos involucrados Esto se registra en un archivo desde el cual se obtendrán los informes para el análisis y evaluación del sistema. Permite experimentar con situaciones de excepción a objeto de verificar la eficacia de los controles y medidas de seguridad del sistema. Snapshot / Pasos 1. Selección de los puntos Snapshot 2. Desarrollar un método de identificación de los registros a examinar 3. Diseñar archivos Snapshot 4. Marcar los puntos para identificar los datos obtenidos en cada snapshot 5. Diseñar los informes Snapshot 6. Incorporar las rutinas snapshot, Construir los programas, Documentar su uso. Tracing Esta técnica utiliza la instrucción Trace que tienen definida la mayoría de los lenguajes de programación. El objetivo de esta técnica es observar las operaciones ejecutadas para una transacción y la secuencia seguida. Puede utilizarse con datos reales o con datos de prueba. Mapping Mediante un Software especial se establece que sentencias de programa han sido ejecutadas y cuales no, tiempo de CPU que gasta cada una de ellas.