CAPITULO 16 MTODOS DE PRUEBA DEL SOFTWARE La prueba del software es un elemento crtico para la garanta de calidad del soft y representa una revisin final de las especificaciones del diseo y de la codificacin. Costos asociados a un fallo: se emplea entre el 30 y el 40 por ciento del esfuerzo total de un proyecto en la prueba. 16.1 FUNDAMENTOS DE LA PRUEBA DEL SOFTWARE 16.1.1.OBJETIVOS DE LA PRUEBA 1) La prueba es un proceso de ejecucin de un programa con la intencin de descubrir un error. 2) Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrara un error no descubierto hasta entonces. 3) Una prueba tiene xito si descubre un error no detectado hasta entonces. La prueba no puede asegurar la ausencia de defectos, slo puede demostrar que existen defectos en el software. 16.1.2 PRINCIPIOS DE LA PRUEBA - A todas la pruebas se les debera poder hacer un seguimiento hasta los requisitos del cliente: se entiende que los defectos ms graves son aquellos que impiden al programa cumplir sus requisitos. - Las pruebas debera planificarse mucho antes de que empiecen: la planificacin de las pruebas pueden empezar tan pronto como est completo el modelo de requisitos. La definicin detallada de los casos de prueba puede empezar tan pronto como el modelo de diseo se ha consolidado. Por lo tanto, se pueden planificar y disear todas las pruebas antes de generar ningn cdigo. - El principio de Pareto es aplicable a la prueba del software: implica que al 80 por ciento de todos los errores descubiertos durante las pruebas surgen al hacer un seguimiento de slo el 20 por ciento de todos los mdulos del programa. El problema es aislar estos mdulos sospechosos y probarlos concienzudamente. - Las pruebas deberan empezar por lo pequeo y progresar hacia lo grande: las primeras pruebas planeadas y ejecutadas se centran generalmente en mdulos individuales del programa. A medida que avanzan las pruebas, desplazan su punto de mira en un intento de encontrar errores en grupos integrados de mdulos y finalmente en el sistema entero. - No son posibles las pruebas exhautivas: el nmero de permutaciones de caminos para incluso un programa de tamao moderado es excepcionalmente grande. Por este motivo , es imposible ejecutar todas las combinaciones de caminos durante las pruebas. Es posible, cubrir adecuadamente la lgica del programa y asegurarse de que se han aplicado todas las condiciones del diseo procedimental. - Para ser ms efectivas, las pruebas deberan ser conducidas por un equipo independiente: el ingeniero del software que creo el sistema no es el ms adecuado para llevar a cabo las pruebas para el software. 16.1.3 FACILIDAD DE PRUEBA La facilidad de prueba del software es simplemente lo fcil que se puede probar un programa de computadora. Existen mtricas que podran usarse para medir la facilidad de prueba en la mayora de sus aspectos. Caractersticas que llevan a un software fcil de probar: - Operatividad: cuando mejor funcione , ms eficientemente se puede probar - Observabilidad: lo que ves es lo que pruebas - Controlabilidad: cuanto mejor podamos controlar el software, ms se puede automatizar y optimizar. - Capacidad de descomposicin: controlando el mbito de las pruebas podemos aislar ms rpidamente los problemas y llevar a cabo mejores pruebas de regresin. - Simplicidad: cuando menos haya que probar, ms rpidamente podremos probarlo. Simplicidad funcional: Simplicidad estructural: Simplicidad de cdigo: - Estabilidad: cuando menos cambios, menos interrupciones a las pruebas - Facilidad de comprensin: cuanta ms informacin tengamos, ms inteligentes sern las pruebas. 1

Atributos de una buena prueba: 1) Una buena prueba tiene una alta probabilidad de encontrar un error. 2) Una buena prueba no debe ser redundante: todas las pruebas deben tener un propsito diferente. 3) Una buena prueba debera ser la mejor de la cosecha: se debe emplear la prueba que tenga la ms alta probabilidad de descubrir una clase entera de errores. 4) Una buena prueba no debera ser ni demasiado sencilla ni demasiado compleja. 16.2 DISEO DE CASOS DE PRUEBA Debemos disear pruebas que tengan la mayor probabilidad de encontrar el mayor nmero de errores con la mnima cantidad de esfuerzo y tiempo posible. Cualquier producto de ingeniera puede comprobarse de una de estas dos formas: 1) Conociendo la funcin especfica para la que fue diseado el producto, se pueden llevar a cabo pruebas que demuestren que cada funcin es completamente operativa y al mismo tiempo buscando errores en cada funcin 2) Conociendo el funcionamiento del producto, se pueden desarrollar pruebas que aseguren que todas las piezas encajan o sea, que la operacin interna se ajusta a las especificaciones y que todos los componentes internos se han comprobado de forma adecuada. El primer enfoque de prueba se denomina prueba de caja negra y el segundo prueba de caja blanca 16.3 PRUEBA DE CAJA BLANCA (prueba de caja de cristal) Es un mtodo de diseo de casos de prueba que usa estructura de control del diseo procedimental para obtener los casos de prueba. Mediante los mtodos de prueba de caja blanca, el ingeniero puede obtener casos de prueba que: 1) garanticen que se ejercita por lo menos una vez todos los caminos independientes de cada mdulo 2) ejerciten todas las decisiones lgicas en sus vertientes verdadera y falsa 3) ejecuten todos los bucles en sus lmites y con sus lmites operacionales. 4) ejerciten las estructuras internas de datos para asegurar su validez. Defectos del software: - Los errores y las suposiciones incorrectas son inversamente proporcionales a la probabilidad de que se ejecute un camino del programa. - A menudo creemos que un camino lgico tiene pocas posibilidades de ejecutarse cuando, de hecho, se puede ejecutar de forma normal. - Los errores tipogrficos son aleatorios. Estas razones nos dan un argumento para llevar a cabo las pruebas de caja blanca. La prueba de caja negra, sin tener en cuenta cmo sea de completa, puede pasar por alto los tipos de errores que acabamos de sealar. 16.4 PRUEBA DEL CAMINO BASICO Permite al diseador de casos de prueba obtener una medida de la complejidad lgica de un diseo procedimental y usar esa medida como gua para la definicin de un conjunto bsico de caminos de ejecucin. Los casos de pruebas obtenidos del conjunto bsico garantizan que durante la prueba se ejecuta por lo menos una vez cada sentencia del programa. 16.4.1 NOTACIN DE GRAFO DE FLUJO 16.4.2 COMPLEJIDAD CICLOMTICA Es una mtrica del software que proporciona una medicin cuantitativa de la complejidad lgica de un programa. Cuando se usa en el contexto del mtodo de prueba del camino bsico, el valor calculado como complejidad ciclomtica define el nmero de caminos independientes del conjunto bsico de un programa y nos d un lmite superior para el nmero de pruebas que deben realizar para asegurar que se ejecuta cada sentencia al menos una vez. Un camino independiente es cualquier camino del programa que introduce por lo menos un nuevo conjunto de sentencias de proceso o una nueva condicin. 2

16.4.3. OBTENCIN DE CASOS DE PRUEBA El mtodo de prueba de camino bsico se puede aplicar aun diseo procedimental detallado o a un cdigo fuente. 16.4.4. MATRICES DE GRAFOS 16.5 PRUEBA DE LA ESTRUCTURA DE CONTROL Aunque la prueba del camino bsico es sencilla y altamente efectiva, no es suficiente por s sola. Hay que tratar otras variantes de la prueba de estructura de control. Estas variantes amplian la cobertura de la prueba y mejoran la calidad de la prueba de caja blanca. 16.5.1 PRUEBA DE CONDICIN Es un mtodo de diseo de casos de prueba que ejercita las condiciones lgicas contenidas en el mdulo de un programa. 16.5.2 PRUEBA DE FLUJO DE DATOS Este mtodo selecciona caminos de prueba de un programa de acuerdo con la ubicacin de las definiciones y los usos de las variables del programa. 16.5.3 PRUEBA DE BUCLES La prueba de bucles es una tcnica de prueba de caja blanca que se centra exclusivamente en la validez de las construciones de bucles. Se pueden definir cuatro clases diferentes de bucles: SIMPLES CONCATENADOS-ANIDADOS-NO ESTRUCTURADOS 16.6 PRUEBA DE CAJA NEGRA. Se refiere a las pruebas que se llevan a cabo sobre la interfaz del software. Los casos de prueba pretenden demostrar que las funciones del software son operativas, que la entrada se acepta en forma adecuada y que se produce un resultado correcto, as como que la integridad de la informacin externa se mantiene. Este tipo de prueba examina algunos aspectos del modelo fundamental del sistema sin tener mucho en cuenta la estructura lgica interna del software. Las pruebas de la caja negra se centran en los requisitos funcionales del software. Permite al ingeniero del software obtener conjuntos de condiciones de entrada que ejerciten completamente todos los requisitos funcionales de un programa. Esta tcnica no es una alternativa a las tcnicas de prueba de caja blanca, se trata de un enfoque complementario que intenta descubrir diferentes tipos de errores que los mtodos de caja blanca. Las pruebas de caja negra intenta encontrar errores de las siguientes categoras: 1) funciones incorrectas o ausentes 2) errores de interfaz 3) errores en estructuras de datos o en accesos a bases de datos externas 4) errores de rendimiento 5) errores de inicializacin y terminacin A diferencia de la prueba de caja blanca, que se lleva a cabo previamente en el proceso de prueba, la prueba de caja negra tiende a aplicarse durante fases posteriores de la prueba. Ya que la prueba de caja negra ignora intencionalmente la estructura de control, centra su atencin en el campo de la informacin. Mediante las tcnicas de prueba de caja negra se obtiene un conjunto de casos de prueba que satisfacen los siguientes criterios: 1) Casos de prueba que reducen, en un coeficiente que es mayor que uno, el nmero de casos de prueba adicionales que se deben disear para alcanzar una prueba razonable. 2) Casos de prueba que nos dicen algo sobre la presencia o ausencia de clases de errores en lugar de errores asociados solamente con la prueba que estamos realizando. 16.6.1 MTODOS DE PRUEBA BASADOS EN GRAFOS 3

16.6.2 PARTICIN EQUIVALENTE La particin equivalente es un mtodo de prueba de caja negra que divide el dominio de entrada de un programa en clases de datos de los que se pueden derivar casos de prueba. Un caso de prueba ideal descubre de forma inmediata una clase de error que de otro modo, requiririn la ejecucon de muchos casos antes de detectar el error genrico. La particin equivalente se dirige a la definicin de casos de prueba que descubran clases de errores, reduciendo as el nmero total de casos de prueba que hay que desarrollar. 16.6.3. ANLISIS DE VALORES LMITE Los errores tienden a darse ms en los lmites del campo de entrada que en el centro. Por ello, se ha desarrollado el anlisis de valores lmites (AVL) como tcnica de prueba. El anlisis de valores lmites nos lleva a una eleccin de casos de prueba que ejerciten los valores lmites. El anlisis de valores lmite es una tcnica de diseo de casos de prueba que complementa a la particin equivalente. En lugar de seleccionar cualquier elemento de una clase de equivalencia, el AVL lleva a la eleccin de casos de prueba en los extremos de la clase. En lugar de centrarse solamente en las condiciones de entrada, el AVL obtiene casos de prueba tambin para el campo de salida. 16.6.4 PRUEBA DE COMPARACIN Hay situaciones en las que la fiabilidad del soft es algo absolutamente crtico. En ese tipo de aplicaciones, a menudo se utiliza hard y soft redundante para minimizar la posibilidad de error. Cuando se desarrolla soft redundante, varios equipos de ingenieria del soft separados desarrollan versiones independientes de una aplicacin, usando las mismas especificaciones. En esas situaciones, se deben probar todas las versiones con los mismos datos de prueba, para asegurar que todas proporcionan una salida idntica. Luego, se ejecutan todas las versiones en paralelo y se hace una comparacin en tiempo real de los resultados, para garantizar la consistencia. Para las aplicaciones crticas, se deben desarrollar versiones de soft independientes, incluso aunque solo se vaya a distribuir una de las versiones en el sistema basado en computadora. Esas versiones independientes son la base de una tcnica de prueba de caja negra llamada prueba de comparacin o mano a mano. La prueba de comparacin no es infalible. Si el error se encuentra en la especificacin a partir de la cual se han desarrollado todas las versiones, lo ms probable es que todas las versiones reflejen el error, entonces este no ser detectado. 16.7 PRUEBA DE ENTORNOS Y APLICACIONES ESPECIALIZADAS. Los mtodos de la caja blanca y negra son aplicables a todos los entornos, arquitecturas y aplicaciones, pero aveces se necesitan unas directrices y enfoques nicos para las pruebas. 16.7.1 PRUEBA DE INTERFACES GRFICAS DE USUARIO La creacin de la interfaz de usuario se ha convertido menos costosas en tiempo y ms exacta. Al mismo tiempo la complejidad de las interfaces grficas de usuario (IGU) ha aumentado, originando ms dificultades en el diseo y ejecucin de los casos de prueba. Para dichas pruebas hay que considerar: - ventanas - menu emergentes y operantes con el ratn - entrada de datos 16.7.2 PRUEBA DE ARQUITECTURAS CLIENTE*SERVIDOR 16.7.3 PRUEBA DE DOCUMENTACIN Y DE AYUDA Los errores en la documentacin pueden ser tan destructivos para la aceptacin del programa como los errores en los datos o en el cdigo fuente. Nada es ms frustrante que seguir fielmente el manual del usuario y obtener resultados o comportamientos que no coinciden con los anticipados por el documento. Este tipo de prueba debera ser una parte importante de cualquier plan de pruebas de soft. Esta prueba se puede enfocar en dos fases: 1) revisin tcnica formal 2) la prueba en vivo 16.7.4 PRUEBA DE SISTEMAS DE TIEMPO REAL 4

Se puede proponer una estrategia en cuatro pasos: Pruebas de tareas: Probar cada tarea independientemente. Se disean pruebas de caja blanca y de caja negra y se ejecutan para cada tarea. La prueba de la tarea ha de descubrir errores en la lgica y en el funcionamiento, pero no los errores de temporizacin o de comportamientos. Prueba de comportamiento:Utilizando modelos del sistema creados con herramientas CASE es posible simular el comportamiento del sistema en tiempo real y examinar su comportamiento como consecuencia de sucesos externos. Estas actividades de anlisis pueden servir como base del diseo da casos de prueba que se llevan a cabo cuando se ha construdo el soft de tiempo real. Pruebas intertareas: Una vez que se han asilado los errores en las tareas individuales y en el comportamiento del sistema, la prueba se dirige hacia los errores relativos al tiempo. Se prueban las tareas asncronas que se sabe que comunican con otras, con diferentes tasas de datos y cargas de procesos para determinar si se producen errores de sincronismo entre las tareas. Pruebas del sistema: el soft y el hard estn integrados, por lo que se lleva a cabo una serie de pruebas completas del sistema para intentar descubrir errores en la interfaz soft-hard. * Es esencial la prueba del manejo de interrupciones y el proceso que ocurre como consecuencia de la misma *

5