Apuntesent

Tema 6. Pruebas del softwareTema 6. Pruebas del software _______________________________________________________ 1 1 2 3 4 5 Definiciones __________________________________________________________________ 2 Filosofa de las pruebas del software ______________________________________________ 2 El proceso de prueba ___________________________________________________________ 3 Tcnicas de diseo de casos de pruebas ____________________________________________ 3 Pruebas estructurales __________________________________________________________ 45.1 5.2 Cmo dibujar un grafo de flujo ______________________________________________________5 Complejidad ciclomtica de McCabe __________________________________________________6

6

Prueba funcional ______________________________________________________________ 76.1 Particiones o clases de equivalencia __________________________________________________7Anlisis de Valores Lmite (AVL)___________________________________________________________ 8 Conjetura de errores. ___________________________________________________________________ 9 6.1.1 6.1.2

7 8 9

Pruebas aleatorias _____________________________________________________________ 9 Enfoque prctico recomendado para el diseo de casos _______________________________ 9 Documentacin del diseo de las pruebas __________________________________________ 99.1 9.2 9.3 9.4 Plan de pruebas __________________________________________________________________9 Especificacin del diseo de pruebas _________________________________________________9 Especificacin de casos de pruebas _________________________________________________ 10 Especificacin del procedimiento de prueba _________________________________________ 10

1010.1 10.2 10.3 10.4 10.5 10.6 10.7

Ejecucin de las pruebas _____________________________________________________ 10El proceso de ejecucin ________________________________________________________ 10 Documentacin de la ejecucin de pruebas ________________________________________ 10 Histrico de pruebas (test log) ___________________________________________________ 10 Informe de incidente (test incident report) _________________________________________ 10 Informe resumen de las pruebas (test summary report) ______________________________ 11 Depuracin __________________________________________________________________ 11 Anlisis de errores o anlisis causal _______________________________________________ 11

1111.1 11.2 11.3 11.4

Estrategia de aplicacin de las pruebas _________________________________________ 11Prueba de unidad _____________________________________________________________ 12 Pruebas de integracin _________________________________________________________ 12 Prueba del sistema ____________________________________________________________ 12 Pruebas de aceptacin _________________________________________________________ 12

12

Ejercicios __________________________________________________________________ 14

Tema 6. Las pruebas del software

Entornos de Desarrollo

1 DefinicionesTodo sistema o aplicacin debe e probado mediante su ejecucin controlada antes de ser entregado al cliente. Las pruebas constituyen un mtodo ms para poder verificar y validar el software. Verificacin: proceso de evaluacin de un sistema o de unos de sus componentes para determinar si los productos de una fase dada satisfacen las condiciones impuestas al comienzo de dicha fase, es decir, indica si se est construyendo correctamente el producto. Validacin: proceso de evaluacin de un sistema o de uno de sus componentes durante o al final del proceso de desarrollo para determinar si satisface los requisitos especificados, esto es, si se est construyendo el producto correcto. Pruebas (test1): una actividad en la cual un sistema o uno de sus componentes se ejecuta en circunstancias previamente especificadas, los resultados se observan y registra y se realiza una evaluacin de algn aspecto. Es el proceso de ejecutar un programa con el fin de encontrar errores. Caso de prueba (test case): un conjunto de entradas, condiciones de ejecucin y resultados esperados desarrollados para un objetivo particular. Tambin es la documentacin en la que se describen las entradas, condiciones y salidas de un caso de prueba. Defecto (defect, default, bug2): software incorrecto en un programa. Fallo (failure): la incapacidad de un sistema o de alguno de sus componentes para realizar las funciones dentro de los requisitos de rendimiento especificados. Error (error): Puede ser: 1) La diferencia entre un valor calculado, observado o medido y el valor verdadero, especificado o tericamente correcto. Por ejemplo, una diferencia de dos centmetros entre el valor real y el calculado. 2) Un defecto. Por ejemplo, una instruccin incorrecta en un programa. 3) Un resultado incorrecto. Por ejemplo, mostrar que la raz cuadrada de 36 es 7 en vez de 6. 4) Una accin humana que conduce a un resultado incorrecto. Por ejemplo, que el operador o el programador pulse una tecla equivocada.

-

-

-

-

2 Filosofa de las pruebas del softwareLa prueba exhaustiva del software es impracticable, no se pueden probar todas las posibilidades de su funcionamiento incluso en programas pequeos y sencillos. EL objetivo de las pruebas es la deteccin de defectos en el software. Se trata de una actividad a posteriori, de deteccin, y no de prevencin, de problemas en el software. Las pruebas permiten la rectificacin en el software. El descubrimiento de un defecto significa un xito para la mejora de la calidad. Las recomendaciones para las pruebas son las siguientes: 1) Cada caso de prueba debe definir el resultado de salida esperado. Se compara con el obtenido de la ejecucin de la prueba. Las discrepancias entre ambos son un posible defecto en el software. 2) El programador debe evitar probar sus propios programas. 3) Se debe inspeccionar a conciencia el resultado de cada prueba para poder descubrir posibles sntomas de defectos. 4) Al generar casos de prueba, se deben incluir tanto datos de entrada vlidos y esperados como no vlidos e inesperados. 5) 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.1

El trmino ingls es test que puede referirse tanto al nombre prueba como al verbo probar. Es frecuente que se utilice testing para referirse al proceso o a la actividad de prueba (por ejemplo, software testing = pruebas del software). No es aceptable hablar de testeo o testear 2 La palabra bug significa literalmente en ingls chinche. Existe la leyenda segn la cual, en los primeros tiempos de la informtica un gran ordenador sufra frecuentes e inexplicables fallos. Los tcnicos, tras muchos esfuerzos, lo desmontaron y descubrieron que una colonia de insectos se haba instalado en su interior al calor de los circuitos. Los fallos se provocaban al achicharrarse alguno de los insectos, que ocasionaban cortocircuitos, oscilacin de unos por ceros, etc.

2



6) Se deben evitar los casos desechables, no documentados ni diseados con cuidado. 7) No deben hacerse planes de prueba suponiendo que no hay defectos en los programas y dedicando pocos recursos a las pruebas. 8) Donde hay un defecto hay otros. La probabilidad de descubrir nuevos defectos en una parte del software es proporcional al nmero de defectos ya descubiertos. 9) Las pruebas son una tarea tanto o ms creativas que el desarrollo software.

Ilustracin 1. Relacin entre error, defecto y fallo

La filosofa ms adecuada para las pruebas consiste en planificarlas y disearlas de forma sistemtica para poder detectar el mximo nmero y variedad de defectos con el mnimo consumo de esfuerzo y tiempo.

3 El proceso de pruebaComienza con la generacin de un plan de pruebas en base a la documentacin del proyecto y la documentacin sobre el software aprobar. Se hacen reejecuciones de pruebas y se deja constancia de los defectos ya detectados. A partir de los resultados de salida, se pasa a su evaluacin mediante comparacin con la salida esperada, hacindose dos actividades: La depuracin: localizacin y correccin de defectos. Si no se consigue localizar los defectos, puede ser necesario realizar pruebas adicionales. Si se corrige un defecto, se debe volver a probar el software para comprobar que el problema est resuelto. El anlisis de la estadstica de errores: sirve para realizar predicciones de la fiabilidad del software y para detectar las causas ms habituales de error y mejorar los procesos de desarrollo.

-

4 Tcnicas de diseo de casos de pruebasLas tcnicas de diseo de casos de prueba tienen como objetivo conseguir una confianza aceptable en que se detectarn los defectos existentes, sin necesidad de consumir una cantidad excesiva de recursos. Hay que buscar un equilibrio entre la disponibilidad de recursos y la confianza que aportan los casos de prueba par descubrir los defectos existentes.Ya que no se pueden probar todas las posibilidades de funcionamiento del software, el diseo de pruebas consiste en elegir algunas de ellas que se consideren representativas del resto. La dificultad es saber elegir los casos que se deban ejecutar. Una eleccin puramente aleatoria no proporciona demasiada confianza en que se puedan detectar todos los defectos existentes.

3

Tema 6. Las pruebas del software Existen tres enfoques para el diseo de casos de prueba:


1) Enfoque estructural o de caja blanca3: se centra en la estructura interna del programa par elegir los casos de prueba. La prueba ideal consistira en probar todos los posibles caminos de ejecucin que puedan trazarse. 2) Enfoque funcional o de caja negra: se estudia la especificacin de las funciones, la entrada y la salida para derivar los casos. LA prueba ideal es probar todas las posibles entradas y salidas del programa. 3) Enfoque aleatorio: se utilizan modelos (estadsticos) que representen las posibles entradas al programa para crear a partir de ellos los casos de prueba. Los enfoques de caja negra y caja blanca no son excluyentes entre s, ya que se pueden combinar para obtener una deteccin ms eficaz.

Ilustracin 2. Los enfoques de diseo de pruebas de caja blanca y de caja negra.

5 Pruebas estructuralesPara realizar este tipo de pruebas, y para evitar el elevado nmero de alternativas a revisar en cualquier programa, el diseo de los casos de prueba tiene que basarse en la eleccin de caminos importantes que ofrezcan una seguridad aceptable en descubrir defectos, usando para ello los llamados criterios de cobertura lgica. Para esto no es necesario el uso de ninguna representacin grfica especfica del software, sin embargo es habitual tomar como base los llamados diagramas de flujo de control (flowgraph charts o flowcharts). Como ejemplo tomemos la siguiente figura:

3

En ingls White Box Testing. Sin embargo, la denominacin caja blanca no es acertada, ya que se trata de una caja transparente que permite ver su interior. Recientemente, la mayora de los autores ya utilizan la expresin prueba de caja de cristal (Glass box testing)

4



Ilustracin 3. Grafo de flujo de un programa.

5.1 Cmo dibujar un grafo de flujoPara dibujar un grafo de flujo es recomendable seguir los siguientes pasos: 1) Sealar en el cdigo cada condicin, ya sea IF THEN, CASE OF o cualquier bucle (WHILE o UNTIL). 2) Agrupar el resto de sentencias en secuencias de instrucciones situadas entre cada dos condiciones segn los esquemas representados a continuacin:

Ilustracin 4. Representacin de las estructuras bsicas de programa en un grafo de flujo.

3) Numerar tanto las condiciones como los grupos de sentencias, de forma que se les asigne un identificador nico. Una clasificacin de los criterios de cobertura lgica, en funcin de menor a mayor seguridad, es: 1) 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. 2) Cobertura de decisiones. Cada decisin tiene, por lo menos, un resultado verdadero y, al menos una vez, uno falso. Una ejecucin de pruebas que cumple la cobertura de decisiones cumple la anterior. 3) Cobertura de condiciones. Cada condicin de cada decisin adopta el valor verdadero al menos una vez y falso al menos una vez. No podemos asegurar que si se cumple esta cobertura se cumpla necesariamente la anterior.

5



4) Criterio de decisin/condicin. Consiste en exigir el criterio de cobertura de condiciones obligando a que se cumpla el criterio de decisiones. 5) 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 descompone cada decisin multicondicional en decisiones unicondicionales y se debe conseguir que todas las posibles combinaciones de resultados de cada condicin en cada decisin se ejecute al menos una vez. La cobertura de caminos es el criterio ms elevado, cada uno de los posibles caminos del programa se debe ejecutar al menos una vez. Un camino es la secuencia de sentencias encadenadas desde la sentencia inicial del programa hasta su sentencia final. El camino de pruebas atraviesa como mximo una vez el interior de cada bucle que se encuentra. Los bucles deberan probarse al menos tres veces, una sin entrar en su interior, otra ejecutndolo una vez y otra ms ejecutndolo dos veces. Los bucles constituyen el elemento de los programas que genera un mayor nmero de problemas para la cobertura de caminos.

5.2 Complejidad ciclomtica de McCabeEsta mtrica se trata de un indicador del nmero de caminos independientes que existen en el grfico. La complejidad ciclomtica de McCabe V(G) se puede calcular de tres maneras a partir de un grfico G: 1) V(G) = a n + 2, siendo a el nmero de arcos o aristas del grafo y, n, el nmero de nodos. 2) V(G) = r, donde r es el nmero de regiones cerradas del grafo. 3) V(G) = c + 1, con c el nmero de nodos de condicin, es decir, nodos de los que sale ms de una arista. Si tenemos en cuenta el ejemplo anterior, el clculo sera: V(G) = 14 11 + 2 = 5 V(G) = 5 V(G) = 4 + 1 = 5

Los cinco caminos independientes seran: 1) 2) 3) 4) 5) 1 2 12, 13 1 2 3 4 10, 11 2 12, 13 1 2 3 4 5 10, 11 2 12, 13 1 2 3 4 5 6 7a 8, 9 4 10, 11 2 12, 13 1 2 3 4 5 6 7b 8, 9 4 10, 11 2 12, 13

A partir de aqu habra que definir casos de prueba para cada uno de estos caminos. 6



6 Prueba funcionalLa prueba funcional o de caja negra se centra en el estudio de la especificacin del software, del anlisis de las funciones que debe realizar, de las entradas y de las salidas. La prueba exhaustiva de caja negra es impracticable. Debemos buscar criterios que permitan elegir un subconjunto de casos cuya ejecucin aporte una cierta confianza en detectar los posibles defectos del software. Un caso de prueba est bien elegido si: Reduce el nmero de otros casos necesarios para que la prueba sea razonable. Esto implica que el caso ejecute el mximo nmero de posibilidades de entradas diferentes para as reducir el total de casos. Cubre un conjunto extenso de otros casos posibles, indica algo acerca de la ausencia o la presencia de defectos en el conjunto especfico de entradas que prueba, as como de otros conjuntos similares.

-

6.1 Particiones o clases de equivalenciaLas cualidades que definen un buen caso de prueba: Cada caso debe cubrir el mximo nmero de entradas. Debe tratarse el dominio de valores de entrada dividido en un nmero finito de clases de equivalencia. La prueba de un valor representativo de una clase de equivalencia permite suponer razonablemente que el resultado obtenido ser el mismo que el conseguido probando cualquier otro valor de la clase.

El mtodo de diseo de casos consiste en: Identificacin de clases de equivalencia: 1) Identificacin de las condiciones de las entradas del programa (restricciones y formato). 2) Identificar las clases de equivalencia (datos vlidos y datos no vlidos), basndose en el principio de igualdad de tratamiento, es decir, cualquier dato de la clase de equivalencia debe ser tratado de la misma manera por el programa. 3) Existen algunas reglas que ayudan a identificar clases: a. Si se especifica un rango de valores para los datos de entrada (por ejemplo, el nmero estar comprendido entre 1 y 49), se crear una clase vlida (1 nmero 49) y dos clases no vlidas (nmero < 1 y nmero < 49). b. Si se especifica un nmero de valores (por ejemplo, se pueden registrar de uno a tres propietarios de un piso), se crear una clase vlida (1 propietarios 3) y dos no vlidas (propietarios < 1 y propietarios > 3). c. Si se trata de una situacin del tipo debe ser o booleana (por ejemplo, el primer carcter debe ser una letra), se identifican una clase vlida (es una letra) y, otra no vlida (no es una letra). d. Si se especifica un conjunto de valores admitidos (por ejemplo, pueden registrarse tres tipos de inmuebles: pisos, chals y locales comerciales) y se sabe que el programa trata de forma diferente cada uno de ellos, se identifica una clase vlida por cada valor y una no vlida (cualquier otro caso, por ejemplo, plaza de garaje). e. En cualquier caso, si se sospecha que ciertos elementos de una clase no se tratan igual que el resto de la misma, deben dividirse en clases menores. Creacin de los casos de prueba correspondientes: 1) Asignacin de un nmero nico a cada clase de equivalencia. 2) Hasta que todas las clases de equivalencia hayan sido cubiertas por casos de prueba, se tratar de escribir un caso que cubra tantas clases vlidas no incorporadas como sea posible. 3) Hasta que todas las clases de equivalencia no vlidas hayan sido cubiertas por casos de prueba, escribir un caso para una nica clase no valida sin cubrir.

-

7



Ejemplo. Se trata de una aplicacin bancaria en la que el operador deber proporcionar un cdigo, un nombre para que el usuario identifique la operacin (por ejemplo, nmina) y una orden que disparar una serie de funciones bancarias.Especificacin: Cdigo de rea: nmero de 3 dgitos que no empieza ni por 0 ni por 1. Nombre de identificacin: 6 caracteres. rdenes posibles: cheque, depsito, pago factura, retirada de fondos. Aplicacin de las reglas que ayudan a identificar las particiones de equivalencia (punto 3): Cdigo: - Nmero, por la regla c de identificacin de clases de equivalencia, booleana: + Clase vlida (nmero). + Clase no vlida (no es nmero). - Por la regla e, la clase nmero puede subdividirse; por la regla a, rango, obtenemos: + Subclase vlida (200 cdigo 999). + Dos subclases no vlidas (cdigo < 200; cdigo > 999). Nombre de identificacin, nmero especfico de valores, por la regla b: - Clase vlida (6 caracteres). - Dos clases no vlidas (menos de 6 caracteres; ms de 6 caracteres). Orden, conjunto de valores, por la regla d: - Una clase vlida por cada orden (cheque, depsito). - Una clase no vlida (cualquier otro valor, por ejemplo, divisas). En la siguiente tabla se enumeran las clases identificadas y la generacin de casos (presuponiendo que el orden de entrada es cdigo nombre orden): Condicin de entrada Clases vlidas Clases invlidas Cdigo de rea (1) 200 cdigo 999 (2) cdigo < 200 (3) cdigo > 999 (4) no es nmero Nombre para identificar la operacin (5) seis caracteres (6) menos de 6 caracteres (7) ms de 6 caracteres Orden (8) Cheque (12) ninguna orden vlida (9) Depsito (10) Pago factura (11) Retirada fondos Casos de prueba vlidos: 300 Nmina Depsito (1) (5) (9) 400 Viajes Cheque (1) (5) (8) 500 Coches Pago factura (1) (5) (10) 600 Comida Retirada fondos (1) (5) (11) Casos de prueba no vlidos 180 Viajes Pago factura 1032 Nmina Depsito XY Compra Retirada fondos 350 A Depsito 450 Regalos Cheque 550 Regalo &%4 (2) (3) (4) (1) (1) (1) (5) (5) (5) (6) (7) (5) (10) (9) (11) (9) (8) (12)

6.1.1 Anlisis de Valores Lmite (AVL)Son casos de prueba que exploran las condiciones lmete de un programa. Las situaciones lmite son las que se hallan arriba, abajo y en los mrgenes de las clases de equivalencia. El anlisis de los valores lmite es una tcnica de diseo que complementa a la de particiones de equivalencia. Las diferencias entre ambas son las siguientes: Se requiere la seleccin de uno o ms elementos de manera que los mrgenes se sometan a prueba. Consideran tambin el espacio de salida.

El proceso de seleccin de casos es tambin heurstico4, aunque existen ciertas reglas orientativas: 1. Si una condicin de entrada especifica un rango de valores (por ejemplo, 1,5 valor 15,5), se deben generar casos para los extremos del rango (1,5 y 15,5) y casos no vlidos para situaciones ms all de los extremos (si slo podemos tener un valor decimal, 1,4 y 15,6). 2. Si la condicin de entrada especifica un nmero de valores (por ejemplo, el fichero de entrada tendr de 1 a 255 registros), hay que escribir casos para los nmeros mximo, mnimo, una ms del mximo y uno menos del mnimo (0, 1, 255 y 256 registros).4

Segn la RAE Tcnica que se basa en mtodos no rigurosos, como tanteo, reglas empricas, etc.

8



3. Usar la regla 1 para la condicin de salida (el descuento mximo aplicable en compra al contado ser 50%, el mnimo ser el 6%). Se escribirn casos para intentar obtener descuentos de 5,99%, 6%, 50% y 50,01%. 4. Usar la regla 2 para la condicin de salida (el programa puede mostrar de 1 a 4 listados). Se escriben casos para intentar generar 0, 1, 4 y 5 listados.

6.1.2 Conjetura de errores.Se intenta enumerar una lisa de equivocaciones que pueden cometer los desarrolladores y de las situaciones propensas a ciertos errores. Despus se generan casos de prueba en base a dicha lista. Casos que se pueden presentar: El valor cero es una situacin propensa a errores. Si se han de introducir un nmero variable de valores, probar el caso de no introducir ninguno. Suponer que el programador pudiera haber interpretado algo mal en la especificacin.

7 Pruebas aleatoriasSimulamos la entrada habitual del programa creando datos de entrada en la secuencia y con la frecuencia con la que podran aparecer en la prctica, de forma continua sin parar. Esto implica usar una herramienta denominada generador de pruebas, a los que se alimenta con una descripcin de las entradas y las secuencias de entrada posibles y su probabilidad de ocurrir en la prctica. Este enfoque es muy usado en la prueba de compiladores. Indicando la distribucin estadstica que siguen las entradas, hacemos que la frecuencia de las entradas sea la apropiada para orientar las pruebas hacia lo que es probable que suceda en la prctica.

8 Enfoque prctico recomendado para el diseo de casosAunque, en la prctica, la aplicacin de las distintas tcnicas est bastante discriminada segn la etapa de la estrategia de prueba, se propone un enfoque razonable: 1) Si la especificacin contiene combinaciones de condiciones de entrada, comenzar formando un grafo de causa efecto. 2) En todos los casos, usar el anlisis de valores lmite para aadir casos de prueba. 3) Identificar las clases de equivalencia vlidas y no vlidas. 4) Utilizar la tcnica de conjetura de errores para aadir casos nuevos referidos a valores especiales. 5) Ejecutar los casos generados hasta el momento, es decir, de caja negra, y analizar la cobertura obtenida. 6) Examinar la lgica del programa para aadir los casos precisos o de caja blanca.

9 Documentacin del diseo de las pruebasLa documentacin es necesaria para una buena organizacin de las pruebas, as como para asegurar su reutilizacin, que es fundamental para optimizar tanto la eficacia como la eficiencia de las pruebas.

9.1 Plan de pruebasSu objetivo es sealar el enfoque, los recursos y el esquema de las actividades de prueba, as como los elementos a probar, caractersticas, personal responsable y los riesgos asociados.

9.2 Especificacin del diseo de pruebasSu objetivo es especificar los refinamientos necesarios sobre el enfoque general reflejado en el plan e identificar las caractersticas que se deben probar con este diseo de pruebas.

9



9.3 Especificacin de casos de pruebasEl objetivo es definir uno de los casos de prueba identificado por una especificacin del diseo de las pruebas.

9.4 Especificacin del procedimiento de pruebaEl objetivo es especificar los pasos para la ejecucin de un conjunto de casos de prueba o los pasos utilizados para analizar un elemento software con el propsito de evaluar un conjunto de caractersticas del mismo.

10 Ejecucin de las pruebas10.1 El proceso de ejecucinEl proceso de pruebas consta de las siguientes fases:

1) Ejecutar las pruebas: 1. Ejecutar las pruebas. 2. Comprobar si ha habido algn fallo en la ejecucin. 3. En caso de fallo, pasar a depuracin o correccin del cdigo. Ejecutar las nuevas pruebas corregidas. 4. Si no hay fallos, pasar a la comprobacin de la terminacin de las pruebas.2) Comprobar si se ha concluido el proceso de prueba:

1. Tras la ejecucin, comprobar si se cumplen los criterios de complecin de pruebas descritos en el plan de pruebas. 2. En caso de terminar las pruebas, pasar a la evaluacin de los productos probados sobre la base de los resultados obtenidos. 3. En caso de no terminar las pruebas, comprobar la presencia de condiciones anormales en la prueba. 4. Si se dan condiciones anormales, se pasa de nuevo a la evaluacin, en caso contrario, se pasa a generar y ejecutar pruebas adicionales. 3) En caso de que hayan terminado, evaluar los resultados. En caso contrario, generar pruebas adicionales.

10.2 Documentacin de la ejecucin de pruebasSe pueden distinguir dos grupos principales de documentos: 1) Documentacin de entrada, constituida por las especificaciones de los casos de prueba que se van a usar y las especificaciones de los procedimientos de pruebas. 2) Documentacin de salida o informes sobre la ejecucin. Cada ejecucin de pruebas generar dos tipos de documentos: - Histrico de pruebas o registro cronolgico de la ejecucin. - Informe de los incidentes ocurridos durante la ejecucin.

10.3 Histrico de pruebas (test log)El objetivo es la documentacin de todos los hechos relevantes ocurridos durante la ejecucin de las pruebas.

10.4 Informe de incidente (test incident report)Su objetivo es documentar cada incidente ocurrido en la prueba y que requiera una posterior investigacin.

10



10.5 Informe resumen de las pruebas (test summary report)El objetivo es resumir los resultados de las actividades de prueba y aporta una evaluacin del software basada en dichos resultados.

10.6 DepuracinEs el proceso de localizar, analizar y corregir los defectos que se sospecha que contiene el software. Suele ser consecuencia de una prueba con xito. Las consecuencias de la depuracin pueden ser: Encontrar la causa del error, analizarla y corregirla. No encontrar la causa y, por tanto, tener que generar nuevos casos de prueba.

Las dos principales etapas en la depuracin son: Localizacin del defecto, que conlleva la mayor parte del esfuerzo. Correccin del defecto, efectuando las modificaciones necesarias en el software.

Consejos para la localizacin del error: 1) 2) 3) 4) 5) 6) Analizar la informacin y pensar, para no utilizar un enfoque aleatorio en la bsqueda del defecto. Al llegar a un punto muerto, pasar a otra cosa o describir el problema a otra persona. Usar herramientas de depuracin slo como recurso secundario. No experimentar cambiando el programa. Se deben atacar los errores individualmente. Se debe fijar la atencin tambin en los datos.

Consejos para la correccin del error: 1) 2) 3) 4) 5) 6) Por experiencia, donde hay un defecto, suele haber ms. Debe fijarse y corregirse el defecto de los problemas, no sus sntomas. La probabilidad de corregir perfectamente un defecto no es del 100%. Cuidado con crear nuevos defectos. La correccin debe situarnos temporalmente en la fase de diseo. Cambiar el cdigo fuente, no el cdigo objeto.

10.7 Anlisis de errores o anlisis causalEl objetivo es proporcionar informacin sobre la naturaleza de los defectos, con el fin de formar al personal sobre los errores que comete para que se puedan prevenir en el futuro, recogiendo informacin como cundo se cometi el error? Quin lo hizo? Qu se hizo mal? Cmo se podra haber prevenido? Por qu no se detect antes? Cmo se podra haber detectado antes? Cmo se encontr el error?

11 Estrategia de aplicacin de las pruebasPretender integrar el diseo de los casos de prueba en una serie de pasos bien coordinados a travs de la creacin de distintos niveles de prueba con diferentes objetivos. Sigue las siguientes etapas: 1) Se comienza en la prueba de cada mdulo, que normalmente la realiza el propio personal de desarrollo en su entorno (pruebas de unidad). 2) Con el esquema del diseo del software, los mdulos probados se integran para comprobar sus interfaces en el trabajo conjunto (pruebas de integracin). 3) El software totalmente ensamblado se prueba como un conjunto para comprobar si cumple o no tanto los requisitos funcionales como los requisitos de rendimientos, seguridad, etc. (pruebas de sistema) 4) El software ya validado se integra con el resto del sistema para probar su funcionamiento conjunto. 5) El producto final se pasa a la prueba de aceptacin para que el usuario compruebe en su propio entorno de explotacin si lo acepta como est o no (pruebas de aceptacin).

11



Cada nivel de pruebas se centra en probar el software realizado en una diferente etapa de desarrollo: 1) La prueba del mdulo (pruebas de unidad) centra sus actividades en ejercitar la lgica del mdulo (caja blanca) y los distintos aspectos de la especificacin de las funciones que debe realizar el mdulo (caja negra). 2) La prueba de integracin debe tener en cuenta los mecanismos de agrupacin de mdulos fijados en la estructura del programa, as como, las interfaces entre componentes de la arquitectura del software. 3) La prueba de validacin debe comprobar si existen desajustes entre el software y los requisitos fijados para su funcionamiento en la ERS. 4) La prueba del sistema debe centrar sus comprobaciones en el cumplimiento de los objetivos iniciados para el sistema. 5) La prueba de aceptacin sirve para que el usuario pueda verificar si el producto final se ajusta a los requisitos por fijados.

11.1 Prueba de unidadEst orientado al diseo de casos de caja blanca debido a: El tamao del mdulo es apropiado. El tipo de defectos que se busca coincide con los propios de la lgica detallada de los mdulos. Permiten declarar que un mdulo est listo y terminado.

11.2 Pruebas de integracinTenemos los siguientes tipos: 1) Integracin incremental. Se combina el siguiente mdulo que se debe probar con el conjunto de mdulos ya probados. Puede ser: - Ascendente: se comienza por los mdulos hoja (los menos importantes). Se escribe para cada conjunto un driver que permite simular la llamada de los mdulos. - Descendente: se comienza por los mdulos raz o principales. Hay que construir mdulos ficticios para simular la presencia de los subordinados, que luego sern sustituidos por los propios subordinados. Existen dos rdenes: - Primero en profundidad, completando las ramas del rbol. - Primero en anchura, completando los niveles del rbol (hermanos y primos).2) Integracin no incremental. Se prueba cada mdulo por separado y, luego, se integran todos de una vez y se prueba el programa completo. Requiere de un mdulo impulsor y uno o ms mdulos ficticios que simulan la funcin de cada mdulo.

11.3 Prueba del sistemaCumplimiento de todos los requisitos funcionales.

-

Funcionamiento y rendimiento de las interfaces hardware, software, de usuario y de operador. Adecuacin de la documentacin del usuario. Ejecucin y mantenimiento en condiciones lmite y de sobrecarga.

11.4 Pruebas de aceptacinComprueba si el producto est listo para ser implantado para el uso operativo en el entorno de usuario. Las caractersticas son: Participacin del usuario. Enfocada hacia la prueba de los requisitos de usuario especificados. Fase final del proceso. No hay que olvidar que el objetivo es probar que el producto est listo para su uso operativo. 12

Hay que tener en cuenta que:

Tema 6. Las pruebas del software Hay que evitar probar sin planificar.


Las pruebas pueden ser: Pruebas alfa: la prueba se realiza bajo el control de la organizacin de desarrollo en el entorno real de trabajo, ayudando al usuario. Pruebas beta: se entregan versiones a usuarios de confianza, sin control directo, que informarn de la opinin que les merece la aplicacin.

13



12 EjerciciosEjercicio 1. Un programa toma como entrada un fichero cuyo formato de registro es el siguiente: Nmero_Empleado Donde: Nmero_Empleado es un campo de nmeros enteros positivos de tres dgitos (excluido el 000). Nombre_Empleado es un campo alfanumrico de 10 caracteres. Meses_Trabajo es un campo que indica el nmero de meses que lleva trabajando el empleado; es un entero positivo (incluido el 000) de 3 dgitos. Directivo es un campo de un solo carcter que puede ser + para indicar que el empleado es un directivo y - para indicar que no lo es. El programa asigna una prima, que se imprime en un listado, a cada empleado segn las normas siguientes: P1 a los directivos con, al menos, 12 meses de antigedad. P2 a los no directivos con, al menos, 12 meses de antigedad. P3 a los directivos sin el mnimo de 12 meses de antigedad. P4 a los no directivos sin el mnimo de 12 meses de antigedad. Nombre_Empleado Meses_Trabajo Directivo

Se pide: 1. Crear una tabla de equivalencia (las clases debern ser numeradas) en la que se indiquen las siguientes columnas en cada fila: a. Condiciones de entrada que se analizan. b. Clases vlidas. c. Clases no vlidas que se generan para la condicin. 2. Generar los casos de prueba (especificando la entrada en todos los casos y la salida esperada slo para los casos vlidos) para las clases creadas utilizando la tcnica de particiones de equivalencia, indicando en cada caso las clases que cubre. Enunciar la regla que se aplica para derivar los casos a partir de las clases de equivalencia. Ejercicio 2. Se ha ideado el siguiente pseudocdigo para cumplir las especificaciones del programa del Ejercicio 1: 1 2 3 4 5 6 7 8 9 10 11 12 13Else If (directivo_FICH == +) Begin // del programa Print (Ilmo. Sr. Director General:); Read (registro_FICH); Prima = 0; While (not EOF of FICH) do Begin // del whilw If (meses_FICH >= 12) Then If (directivo_FICH == +) Then Prima = 1000; Else Prima = 75;

14

Tema 6. Las pruebas del software 14 15 16 17 18 19 20Then Prima = 500; Else; Print (num_FICH, nombre_FICH, Prima); Read (registro_FICH); End; // del while Print (S.e.u.o); End; // del programa


Se han aadido algunas lneas de cabecera y de final al listado de las primas, y se han asignado valores concretos a las primas P1, P2, P3 y P4. El fichero de entrada se denomina FICH y los nombres de los campos son ms o menos iguales. Suponiendo que en la anterior prueba de clases de equivalencia el programa se ejecuta slo con los dos registros siguientes (de casos vlidos), consecutivamente, en el orden dado (el smbolo # indica un carcter en blanco): 123 456 Se pide: 1. Realizar el grafo de flujo, calculando la complejidad ciclomtica e indicando cada uno de los caminos a probar. 2. Busca casos de prueba para cada uno de los caminos encontrados. Ejercicio 3. Ecuaciones de segundo grado. Dada la siguiente funcin, realiza la prueba de caja blanca del cdigo que la contiene:1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 INICIO d = b^2 4*a*c; SI (d>0) ENTONCES INICIO DE BLOQUE x1 = (-b + SQRT(d))/(2*a); X2 = (-b - SQRT(d))/(2*a); n = 2; FIN DE BLOQUE SINO SI (d == 0) INICIO DE BLOQUE x1 = -b/(2*a); X2 = x1; n = 1; FIN DE BLOQUE FUNCION segundogrado (a, b, c: NUMERICO; ref x1, x2: NUMERICO) DEVUELVE NUMERICO /* resuelve ecuaciones de segundo grado */ VARIABLES d, n: NUMERICO;

Fernndez# Fernando##

009 013

+ -

15

Tema 6. Las pruebas del software19 20 21 FIN SINO n = 0; DEVUELVE n;


Ejercicio 4. Insertar en lista enlazada. Dada la siguiente especificacin de listas enlazadas: 1 Encontrar la posicin en la que insertarPosicin en la que se inserta el nuevo elemento

3 Actualizar el siguiente del anterior al nuevo nodo

2 Actualizar el valor del nuevo nodo

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

bool function inputlist (LIST* L, NODE* n, int position) { NODE* cursor; bool ex; int i; if ((pos < 1) OR (pos > L.nnodes)) ex = false; else { cursor = L.first; for (i = 1; i < position; i++) cursor = cursor.next; // only one instruction n.next = cursor.next; cursor.next = n*; L.nnodes++; ex = true; } // end else return (ex) } // end function

Ejercicio 5. Se ha diseo un programa para la realizacin de operaciones bsicas con nmeros complejos. El programa tiene las siguientes entradas de datos: Nmero complejo 1, formado por dos nmeros enteros (parte real y parte imaginaria). Nmero complejo 2, formado por dos nmeros enteros (parte real y parte imaginaria). Operacin a realizar: carcter a elegir entre los siguientes: o + para la suma de nmeros complejos. o para la resta de nmeros complejos. o * para la multiplicacin de nmeros complejos. o / para la divisin de nmeros complejos. 16



Ejercicio 6. Se ha diseado un programa generador de medias a partir de un fichero XLS. El fichero debe tener cuatro columnas, una con el nombre y una con la nota de cada evaluacin (1, 2 y 3). Por tanto las entradas del programa son las siguientes: La ruta del fichero XLS con el formato indicado. El tipo de media que se va a realizar a cada una de las filas de alumnos: o A, para realizar la media aritmtica (suma de las notas dividida entre el nmero de notas). o G, para realizar la media geomtrica (raz n-sima de la suma de los n valores correspondientes a las notas). o M, para realizar la media armnica (nmero de datos dividido por la suma de la inversa de los datos). Posteriormente, segn la calificacin obtenida, el profesor pondr una de las siguientes calificaciones: o IN para valores menores de 5. o SU para valores entre 5 y 7. o NO para valores entre 7 y 8. o SB para valores mayores de 8.

-

17

Apuntesent

Documents

Transcript of Apuntesent