ALEJANDRO RAMIREZ PINZON 07090620 UNIDAD 4 PRUEBAS DE SOFTWARE 1.

PRUEBA: Son los ensayos que se hacen para saber cmo resultar algo en su forma definitiva, o los argumentos y medios que pretenden demostrar la verdad o falsedad de algo. Una prueba tambin puede ser una evaluacin o un examen que se hace para que alguien demuestre sus conocimientos y aptitudes sobre una cierta materia. EN DICCIONARIO DE LA LENGUA ESPAOLA La prueba es un proceso que intenta proporcionar confianza en el software. Ian Sommerville Libro Ingieneria de Software 7 ed. Pag. 493 La prueba es un conjunto de actividades que se planean con anticipacin y se realizan de manera sistemtica. Por tanto, se debe definir una plantilla para las pruebas del software. Roger Pressman Libro Ingieneria del Software 6 ed. Pag. 383 CASO DE PRUEBA: Son especificaciones de las entradas para la prueba y la salida esperada del sistema mas una afirmacin de lo que esta probando. Los datos de prueba son las entradas que han sido identificadas para probar el sistema. Los datos de prueba a veces pueden generarse automticamente. Las salidas de las pruebas solo pueden predecirse por personas que comprenden lo que debera hacer el sistema. Ian Sommerville Libro Ingieneria de Software 7 ed. Pag. 493 Con esto entendemos que un caso de prueba es una prueba para determinar el buen funcionamiento del sistema. DEFECTO: Es una imperfeccin en alguien o algo. El diccionario de la Real Academia Espaola (RAE) define al trmino como la carencia de alguna cualidad propia de algo. El concepto se utiliza como sinnimo de error, fallo o desperfecto. Los defectos pueden ser perceptibles por los sentidos (como una camisa a la que le falta un botn), advertirse en el funcionamiento de alguna cosa (un coche con problemas de freno) o estar vinculados a algo ms simblico o subjetivo (los defectos morales de una persona). FALLA: Hace referencia a un defecto, falta o incumplimiento. ERROR: En la informtica, un error de software (o bug, en ingls) es un fallo que se produce durante la creacin de un programa de computadora. Esa equivocacin, con el tiempo, puede aparecer en cualquier momento del uso del software, impidiendo su correcto funcionamiento.

ALEJANDRO RAMIREZ PINZON 07090620 2- PRUEBAS DE VERIFICACION Y VALIDACION 2.1 Las pruebas de validacin intentan demostrar que el software es el que el cliente quiere que satisfaga sus requerimientos. Como parte de la prueba de validacin, se pueden utilizar pruebas estadsticas para probar el rendimiento y la fiabilidad de los programas, y para comprobar cmo trabaja en ciertas condiciones operacionales. En el Captulo 24 se analizan las pruebas estadsticas y la estimacin de la fiabilidad. Las pruebas de defectos intentan revelar defectos en el sistema en lugar de simular su uso operacional. El objetivo de las pruebas de defectos es hallar inconsistencias entre un programa y su especificacin. Por supuesto, no existe un lmite perfectamente definido entre estas aproximaciones de pruebas. Durante las pruebas de validacin, se encontrarn defectos en el sistema. Durante las pruebas de defectos, alguno de los tests mostrar que el programa satisface sus requerimientos. Normalmente, los procesos de V & V y depuracin se intercalan. A medida que se descubren defectos en el programa que se est probando, tiene que cambiarse ste para corregir tales defectos. Sin embargo, las pruebas (o ms generalmente la verificacin y validacin) y la depuracin tienen diferentes objetivos: Los procesos de verificacin y validacin intentan establecer la existencia de defectos en el sistema software. La depuracin es un proceso que localiza y corrige estos defectos. Ian Sommerville Libro Ingieneria de Software 7 ed. Pag. 474 Verificacin es el conjunto de actividades que aseguran que el software implemente correctamente una funcin especfica. Validacin es un conjunto diferente de actividades que aseguran que el software construido corresponde con los requisitos del cliente. Boehm [BOE81] lo establece de otra manera: Verificacin: Estamos construyendo el producto correctamente? Validacin: Estamos construyendo el producto correcto? La definicin de VyV abarca muchas de las actividades incluidas en el aseguramiento de la calidad del software: revisin de tcnicas formales, auditorias de calidad y de configuracin, monitoreo del desempeo, simulacin, factibilidad, revisin de la documentacin y la base de datos, anlisis de algoritmos, pruebas de desarrollo, de facilidad de uso, calificacin e instalacin. Roger Pressman Libro Ingeniera del Software 6 ed. Pag. 384

ALEJANDRO RAMIREZ PINZON 07090620 3.3.1 PRUEBAS ESTRUCTURALES: Las pruebas estructurales (Figura 23.12) son una aproximacin al diseo de casos de prueba en donde las pruebas se derivan a partir del conocimiento de la estructura e implementacin del software. Esta aproximacin se denomina a veces pruebas de caja blanca, de caja de cristal o de caja transparente para distinguirlas de las pruebas de caja negra.

Fig.23.12 La comprensin del algoritmo utilizado en un componente puede ayudar a identificar particiones adicionales y casos de prueba. Para ilustrar esto, se ha implementado la especificacin de la rutina de bsqueda como una rutina de bsqueda binaria. Por supuesto, sta tiene precondiciones ms estrictas. La secuencia se implementa como un vector, este vector debe estar ordenado y el valor del lmite inferior del vector debe ser menor que el valor del lmite superior. Examinando el cdigo de la rutina de bsqueda, puede verse que la bsqueda binaria implica dividir el espacio de bsqueda en tres partes. Cada una de estas partes constituye una particin de equivalencia. Ian Sommerville Libro Ingieneria de Software 7 ed. Pag. 509-512 Se denomina cajas blancas a un tipo de pruebas de software que se realiza sobre las funciones internas de un mdulo. Las pruebas de caja blanca estn dirigidas a las funciones internas. Entre las tcnicas usadas se encuentran: La cobertura de caminos (pruebas que hagan que se recorran todos los posibles caminos de ejecucin). Pruebas sobre las expresiones lgico-aritmticas. Pruebas de camino de datos (definicin-uso de variables). Comprobacin de bucles (se verifican los bucles para 0,1 y n iteraciones, y luego para las iteraciones mximas, mximas menos uno y ms uno).

ALEJANDRO RAMIREZ PINZON 07090620 PRUEBAS FUNCIONALES: El enfoque funcional o de caja negra. Se centra en las funciones, entradas y salidas. Se centra en las funciones, entradas y salidas. Intenta encontrar errores de las siguientes categoras: Funciones Incorrecta o ausente. Errores de Interfaz. Errores en estructuras de datos o acceso a base de datos externas. Errores de rendimiento. Errores de inicializacin y de terminacin.

Las pruebas de caja negra, tambin denominadas, pruebas de comportamiento, se concentran en los requisitos funcionales del software. Es decir, permiten al ingeniero de software derivar conjuntos de condiciones de entrada que ejercitarn por completo todos los requisitos funcionales de un programa. La prueba de caja negra no es una opcin frente a las tcnicas de caja blanca. Es, en cambio, un enfoque complementario que tiene probabilidades de descubrir una clase diferente errores de los que se descubriran con los mtodos de caja blanca. Las pruebas de caja negra tratan de encontrar errores en las siguientes categoras: 1)funciones incorrectas o faltantes , 2) errores de interfaz, 3) errores en estructuras de datos o en acceso a bases de datos externas, 4) errores de comportamiento o desempeo, y 5) errores de inicializacin y trmino. A diferencia de las pruebas de caja blanca, que se realizan al inicio del proceso de prueba, las de caja negra tienden a aplicarse durante las ltimas etapas de la prueba. Debido a que stas desatienden a propsito la estructura de control, la atencin se concentra en el dominio de la informacin. Las pruebas estn diseadas para responder las siguientes preguntas:
Cmo se prueba la validez funcional? Cmo se prueban el comportamiento y el desempeo del sistema? Cules clases de entrada sern buenos casos de prueba? El sistema es particularmente sensible a ciertos valores de entrada?

ALEJANDRO RAMIREZ PINZON 07090620 Cmo se aslan los lmites de una clase de datos? Cules tasas de datos y cul volumen tolera el sistema? Qu efecto tienen combinaciones especficas de datos sobre la operacin del sistema?

Al aplicar tcnicas de caja negra se deriva un conjunto de casos de prueba que satisfacen los siguientes criterios [MYE79]: 1) casos de prueba que reducen, mediante una cuenta mayor que uno, el nmero de casos de prueba adicionales que deben disearse para alcanzar una prueba razonable, y 2) casos de prueba que indicar acerca de la presencia o ausencia de clases de errores, en lugar de un error asociado slo con la prueba especfica a la mano.
Roger Pressman Libro Ingeniera del Software 6 ed. Pag. 433

PRUEBAS ALEATORIAS En las pruebas aleatorias simulamos la entrada habitual del programa creando datos de entrada en la secuencia y con la frecuencia con las que podran aparecer en la Prctica (de manera repetitiva). Para ello habitualmente se utilizan generadores automticos de casos de prueba. Consiste en utilizar modelos (en muchas ocasiones estadsticos) que representen las posibles entradas al programa para crear a partir de ellos los casos de prueba. El enfoque aleatorio consiste en utilizar modelos (en muchas ocasiones estadsticos) que representen las posibles entradas al programa para crear a partir de ellos los casos de prueba. Cobertura de sentencias. Se trata de generar los casos de prueba necesarios para que cada sentencia o instruccin del programa se ejecute al menos una vez. Cobertura de decisiones. Consiste en escribir casos suficientes para que cada decisin tenga, por lo menos una vez, un resultado verdadero y, al menos una vez, uno falso. (Incluye a la cobertura de sentencias) Cobertura de condiciones. Se trata de disear tantos casos como sea necesario para que cada condicin de cada decisin adopte el valor verdadero al menos una vez y el falso al menos una vez. (No incluye cobertura de condiciones) Criterio de decisin/condicin. Consiste en exigir el criterio de cobertura de condiciones obligando a que se cumpla tambin el criterio de decisiones. Criterio de condicin mltiple. En el caso de que se considere que la evaluacin de las condiciones de cada decisin no se realiza de forma simultnea, se puede considerar que cada decisin multicondicional se descompone en varias condiciones unicondicionales. Ejemplo en la siguiente diapositiva. Criterio de cobertura de caminos. Se recorren todos los caminos (impracticable)

ALEJANDRO RAMIREZ PINZON 07090620

3.2 PLAN DE PRUEBA: Describe todos los mtodos que se utilizarn para verificar que el software satisface la especificacin del producto y las necesidades del cliente. Incluye los objetivos de calidad, necesidades de recursos, cronograma, asignaciones, mtodos, etc. CASOS DE PRUEBA: lista los tems especficos que sern probados y describe los pasos detallados que sern seguidos para verificar el software. Casos de prueba: lista los tems especficos que sern probados y describe los pasos detallados que sern seguidos para verificar el software. REPORTE DE RESUMEN DE PRUEBAS: Un informe resumen de la prueba es un producto de trabajo de pruebas que formalmente se resumen los resultados de todas las pruebas de esfuerzo. Contenido: Objetivos Beneficios Contenido Las partes interesadas Fases Las condiciones previas Directrices 4.4.1 5.5.1 FACILIDAD DE PRUEBA: (Testability,ISO 9126) Subcaracterstica de mantenimiento, que indica la capacidad del software para permitir que sea validado tras ser modificado. OPERATIVIDAD: (operability, ISO 9126) Subcaracterstica de facilidad de uso, que indica las caractersticas del software que influyen en el esfuerzo del usuario para operar y control operacional. OBSERVABILIDAD: es una propiedad importante de un sistema de control, y gobierna la existencia de una solucin de control ptimo. Es una medicin que determina cmo los estados internos pueden se inferidos a travs de las salidas externas.

ALEJANDRO RAMIREZ PINZON 07090620

CONTROBABILIDAD: CAPACIDAD PARA DESCOMPONER: SIMPLICIDAD ESTABILIDAD: (stability,ISO 9126) Subcaracterstica de mantenimiento, que indica volumen de riesgos de efectos inesperados tras una modificacin. FACILIDAD DE COMPRENSION 5.2 CAJA BLANCA EJEMPLO CAJA NEGRA EJEMPLO 6.6.1 PRUBAS BASADAS EN REQUERIMIENTOS PRUEBAS DE PARTICIPACION PRUEBAS ESTRUCTURALES 7.7.1 Esquema 7.2 UNIDAD INTEGRACION SISTEMA ACEPTACION