Diseo de la interfaz de usuario. Pruebas del software. Sumario: 1. Introduccin. 2. Diseo de la interfaz de usuario. 2.1. Evolucin histrica. 2.2.

Produccin de prototipos preliminares y dilogos. 2.3. Ergonoma del diseo de la interfaz. 3. Pruebas del software. 3.1. Definiciones. 3.2. El proceso de prueba. 3.3. Tcnicas de diseo de casos de prueba. 3.4. Pruebas estructurales. (Prueba de la caja blanca) 3.4.1. Utilizacin de la complejidad ciclomtica de McCabe. 3.5. Prueba funcional. (Prueba de la caja negra) 3.5.1. Particiones o clases de equivalencia. 3.5.2. Anlisis de valores lmite (AVL). 3.5.3. Conjetura de errores. 3.6. Pruebas aleatorias. 3.7. Enfoque prctico recomendado para el diseo de casos.

1. INTRODUCCIN Hasta ahora, se ha realizado el anlisis del sistema (generando los DFD y el modelo E/R) y el diseo del sistema (generando el diagrama de estructura y el diseo lgico de la base de datos que, generalmente, es el modelo relacional). Adems, es necesario definir la interfaz entre el usuario y el ordenador. 2. DISEO DE LA INTERFAZ DE USUARIO 2.1. Evolucin histrica

La tecnologa de interfaz de usuario, al igual que el hardware, ha pasado por una serie de generaciones [TESLER, 1991]. Estas generaciones contienen o parecen contener a las anteriores, y se pueden clasificar cronolgicamente como sigue [NIELSEN, 1993]: Hasta 1945: no exista ningn paradigma de interfaz de usuario, y se haca acceso directo de forma manual al hardware. 19451955: programacin en modo batch o por lotes. La primera generacin de interfaces no era interactiva, ya que la interaccin entre el sistema y el usuario se restringa a un nico punto en el tiempo. Todos los mandatos del usuario tenan que ser especificados antes de que el usuario conociera el resultado de cualquiera de ellos. Se recomienda que tales modos batch proporcionen alguna opcin al usuario para controlar continuamente el progreso del trabajo batch, de forma que pueda interrumpir o modificar el trabajo. Es muy frustante tener un trabajo grande ejecutndose y que, cuando vaya a finalizar, tenga que descartarse porque se debera haber modificado el ltimo mandato. Actualmente estas interfaces han tenido un renacimiento en los sistemas de acceso por medio del intercambio de mensajes de correo electrnico. 19551965: lenguajes de mandatos. Tambin denominadas interfaces en lnea. Los sistemas de tiempo compartido se inventaron alrededor de 1960 como un medio para permitir a varios usuarios tener acceso simultneo interactivo a un nico servidor [LEE et al., 19921. Uno de los problemas principales de estos sistemas es la pequea cantidad de recursos de ordenador disponibles para soportar la interfaz de cualquier usuario, por lo que, a menudo, se utilizan interfaces en lnea. stas eran bsicamente interfaces de una dimensin, en las que el usuario slo poda interactuar con el ordenador en una lnea que serva como lnea de mandato. Cuando el usuario pulsaba la tecla de intro (Return o Enter), no se poda modificar la entrada. De forma similar, cuando el ordenador presentaba una salida al usuario, no se poda modificar para reflejar cambios en los datos. Estas interfaces se implementaron originalmente en las mquinas teletipos, aunque las ltimas versiones utilizan pantallas tipo ternnal. Debido a que las interfaces en lnea no permitan a los usuarios navegar por la pantalla, la inte-raccin se limitaba a dilogos preguntarespuesta y a la introduccin de mandatos con parmetros. La mayora de las interfaces de usuario en lnea se implementaban en lenguajes de mandatos y, aunque algunos de ellos son muy poderosos y permiten la construccin de secuencias de mandatos muy com-plicadas, desafortunadamente es normal que se olviden de los errores del usuario, ya que requieren que ste especifique el mandato deseado exacta-mente en el formato requerido. 19651980: pantallas completas con mens estrictamente jerrquicos. El espacio de diseo de la interfaz es de dos dimensiones. Un uso clsico de la pantalla completa es el de los dilogos para rellenar informes, en los que el usuario tiene un nmero de campos etiquetados que puede editar en la secuencia que desee. Estos dilogos todava existen en las interfaces modernas en forma de cajas de dilogo, las cuales son ms dinmicas que los informes tradicionales, ya que contienen mens desplegables y ayuda para que el usuario rellene el informe. Adems de los mens, muchas de las interfaces de pantalla completa utilizan tambin las teclas de funcin como una forma de interaccin. Estas teclas aceleran la interaccin y existen tan pocas que los usuarios, generalmente, se las aprenden de memoria. 19801995: ventanas, iconos, mens y ratn. Tambin denominadas interfaces grficas de usuario. La mayora de las interfaces actuales de usuario pertenecen a esta categora, a veces denominada sistemas WIMP (Windows, Icons, Menus and Pointing device). Las interfaces windows aaden casi una tercera dimensin a las dos dimensiones inherentes a cada ventana debido a la posibilidad de superponer ventanas (est claro que superponer ventanas no es verdaderamente una tercera dimensin, ya que no es posible ver el contenido de la ventana que est debajo, por tanto, podramos decir que tienen dos dimensiones y media). El estilo de interaccin utilizado en muchas interfaces grficas de usuario es la manipulacin directa [SHNEIDERMAN, 1983], la cual se basa en la 2

representacin visual de los objetos del dilogo que tengan inters para el usuario. Esto permite al usuario controlar el dilogo con slo mover los objetos por la pantalla y manipularlos con el ratn. Sin embargo, las interfaces de manipulacin directa pueden resultar ms difciles de utilizar que las tradicionales, debido a que son ms dependientes de un control fino sobre el ratn. 1995Futuro: interfaces no basadas en mandatos. La prxima generacin de interfaces ya se est desarrollando [NIELSEN, 1993b]. Es probable que la tendencia de las generaciones previas contine, y que la dimensin de las interfaces de usuario aumente de 2.5 a 3 o ms dimensiones. Las formas comunes de aadir una dimensin a las interfaces de usuario consisten en aadir tiempo (en forma de animacin), sonido o voz, as como una verdadera tercera dimensin espacial en forma de sistemas de realidad virtual. Las dos predicciones ms fciles con respecto a la siguiente generacin de interfaces de usuario son que incluirn una dimensionalidad ms alta con ms tipos de medios y que sern altamente portables y personales, a la vez que se utiliza tecnologa de comunicaciones para conseguir una gran conectividad. Otro estilo de dilogo para las interfaces de usuario de la prxima generacin puede ser el de las interfaces de usuario no basadas en mandatos. Todos los estilos de interfaz hasta ahora han tenido en comn, al menos, el concepto de mandato, y se basaban en el principio de un dilogo explcito entre el usuario y el ordenador en el que el usuario ordenaba al ordenador que hiciese ciertas acciones especficas. Por el contrario, muchos esfuerzos actuales de investigacin apuntan a sistemas que permitan al usuario centrarse en el dominio en lugar de tener que controlar al ordenador explcitamente. En estos sistemas futuros, el ordenador se encargar de tomar la responsabilidad de la interaccin, basando sus acciones en sus observaciones del usuario, utilizando tecnologas como el seguimiento del ojo, reconocimiento de gestos y anlisis semiinteligente de las acciones del usuario. 2.2. Produccin de prototipos preliminares y dilogos El propsito de la interfaz es muy simple: recoger de los usuarios la informacin del sistema y ponerla a disposicin de otros usuarios. La informacin recogida se llama entrada del sistema y se almacena en la base de datos para ponerla a disposicin de los dems usuarios. La informacin suministrada se llama salida del sistema. Es decir, el diseo de interfaces cubre tanto las entradas como las salidas. Las entradas y salidas pueden ser interactivas o por lotes. En una interfaz interactiva, el usuario se comunica directamente con el ordenador y la salida se obtiene muy poco tiempo despus de la entrada. En el caso de entradas o salidas no interactivas, es decir, por lotes, las transacciones se renen en formularios en el punto de recepcin y despus se introducen en el ordenador al mismo tiempo. Estas transacciones se procesan y un tiempo despus se producen las salidas, las cuales se pasan al usuario. As, el tiempo transcurrido desde la introduccin de los datos hasta que se obtiene una respuesta puede ser considerable. El diseo de interfaz interactivo provoca un dilogo hombremquina que permite un intercambio rpido de informacin entre los ordenadores y sus usuarios humanos, mientras que la interfaz no interactiva utiliza un soporte de papel para contener la informacin en el que las entradas normalmente se realizan en formularios especialmente diseados y las salidas se producen en un listado impreso. Ser necesario definir los formatos individuales de las pantallas utilizadas. En el caso de utilizar un paquete estndar, habr que evaluar la posibilidad de adoptar el tipo de formato del producto. Entre los aspectos a considerar en los formatos de pantalla se destacan: encabezamiento, cuerpo principal, pie, teclas de funcin, teclas de ayuda y lneas de visualizacin de los mensajes de ayuda. Tambin hay que describir, de forma detallada, los dilogos entre pantallas y su encadenamiento. Para ello, es til representarlas jerrquicamente, de forma que en los niveles superiores se representen los mens, y en los niveles inferiores las pantallas de dilogos, representativas de funciones o procesos concretos del sistema. En esta representacin jerrquica nos interesa identificar los mens o dilogos concretos en funcin de los grupos 3

de usuarios que los utilicen. Ser tambin necesario determinar los dilogos que se consideran crticos para un funcionamiento correcto del nuevo sistema. Los dilogos crticos se determinan en funcin de factores como: tipo de proyecto, grado de cambio con respecto al sistema actual, complejidad de los trabajos del sistema. Para ello, es til tener en cuenta los siguientes criterios: frecuencia de uso de estos dilogos, acceso a gran nmero de entidades de datos del sistema, gran nmero de elementos de datos asociados con el dilogo, cambio en el modo habitual de trabajo en el sistema actual, dilogos comunes a diferentes grupos de usuarios, dilogos que contienen opciones complejas de navegacin, etc. Por ltimo, habr que realizar un prototipo dinmico que permita la simulacin (introduccin y validacin de datos por pantalla) para los dilogos considerados como crticos. Como recomendaciones para realizar este prototipo se tendr en cuenta: la determinacin del punto de entrada a cada pantalla y sus posibilidades de navegacin a otras, la especificacin de los datos asociados a cada pantalla (longitud, reglas de validacin, mensajes de ayuda, etc.), la evaluacin de la consistencia del diseo, asegurando que toda la informacin necesaria para el usuario est contemplada en las pantallas, y la confirmacin con el usuario de la validez de los diseos de pantalla realizados. 2.3. Ergonoma del diseo de la intefaz El viaje al mundo del diseo de pantallas comienza con una discusin con el usuario, la parte ms importante de cualquier sistema informatizado. Como hemos comentado, es de aceptacin general que el sistema sera ms fcil de utilizar si lo hubiera diseado el usuario, por tanto, el diseo de la interfaz debe estimular al usuario hacindolo cmplice del sistema. El ser humano es un organismo complejo con una variedad de atributos que tienen una influencia importante en el diseo de pantallas [GALITZ, 1989]. Entre estos atributos, destacamos la percepcin, la memoria, el aprendizaje, la capacidad y diferencias individuales. Por tanto, debe cultivarse la satisfaccin personal y, consecuentemente, mejorar la aceptacin del sistema, permitiendo que las personas mejoren sus conocimientos mientras utilizan el sistema. Para realizar un buen trabajo, la interfaz con el ordenador debe ser, entre otras cosas, lo ms fcil, amigable y agradable posible, y se debe usar un dilogo que se acerque al lenguaje natural en vez de la jerga informtica. Entre las consideraciones a tener cuenta a la hora de disear pantallas se encuentran las siguientes: Caractersticas deseadas: simplicidad, claridad y fcil de comprender. Ser necesario tener claridad visual, de forma que los elementos estn agrupados de forma comprensible y con significado en vez de al azar y de forma confusa. Saber dnde situar la informacin en la pantalla. Ser necesario indicar un punto de partida obvio en la esquina superior izquierda de la pantalla, reservar reas especficas de pantalla para diferentes tipos de informacin (como, por ejemplo, mandatos, mensajes de error, ttulos y campos de datos, de forma que esta consistencia se mantenga en todas las pantallas) y proporcionar una composicin que guste visualmente (es decir, que est balanceada, sea simtrica, sea predecible, secuencial, simple, con agrupamientos, etc.). Saber qu informacin situar en la pantalla. Para ello, hay que poner slo la informacin que es esencial para la toma de una decisin o para la ejecucin de una accin (No inundar al usuario con informacin!) y poner todos los datos relacionados con una tarea en una nica pantalla (as el usuario no tiene que recordar datos de una pantalla a otra). Saber cmo situar la informacin en la pantalla. As, en cuanto a las fuentes de letras, se recomienda 4

utilizar minsculas para el texto con la letra inicial de la frase en maysculas; para las etiquetas, encabezamientos o subttulos utilizar maysculas. En cuanto a las palabras, se recomienda no usar jerga, sino utilizar palabras cortas, familiares, etc. Tambin es necesario saber como alinear y/o resaltar el texto y las palabras, dnde situar las ilustraciones, los campos de datos, etc. La interfaz de entrada debe recoger todos los datos necesarios, sin introducir errores, para el sistema. De esta forma, la interfaz contiene una proteccin contra errores de entrada. As mismo, tambin debe recoger los datos minimizando el nmero de teclas pulsadas por el usuario. Las entradas deben estar bien estructuradas y ser fciles de comprender y utilizar. Se deben usar nombres precisos y permitir abreviaturas cuando se necesiten introducciones rpidas de datos. Se deben evitar las entradas repetitivas. Igualmente, el diseo de la salida asegura que se extraen todos los datos suministrados por el sistema y que esas salidas estn estructuradas de forma que sean fciles de leer. El color aade una nueva dimensin a la facilidad de uso de la pantalla, ya que atrae la atencin del usuario. Si se utiliza de forma adecuada, puede resaltar la organizacin lgica de una pantalla, facilitar la separacin de componentes y acentuar las diferencias. Por el contrario, si se usa inadecuadamente, puede distraer y fatigar la visin debilitando la facilidad de uso del sistema. Por ejemplo, en las pantallas grficas se recomienda no utilizar ms de seis colores a la vez, evitar colores extremos (rojo y azul, amarillo y prpura), evitar colores que no tengan contraste (blanco y amarillo, rojos, azules). Para finalizar, diremos que el diseo de pantallas es un proceso ordenado que empieza en los requisitos y finaliza con la implementacin. 3. PRUEBAS DEL SOFTWARE Una de las caractersticas tpicas del desarrollo de software basado en el ciclo de vida es la realizacin de controles peridicos, normalmente coincidiendo con los hitos del proyectos o la terminacin de documentos. Estos controles pretenden una evaluacin de la calidad de los productos generados (especificacin de requisitos, documentos de diseo, etc.) para poder detectar posibles defectos cuanto antes. Sin embargo, todo sistema o aplicacin, independientemente de estas revisiones, debe ser probado mediante su ejecucin controlada antes de ser entregado al cliente. Estas ejecuciones o ensayos de funcionamiento, posteriores a la terminacin del cdigo del software, se denominan habitualmente pruebas. Las pruebas constituyen un mtodo ms para poder verificar y validar el software. Se puede definir la verificacin como [IEEE, 1990] el proceso de evaluacin de un sistema o de uno de sus componentes para determinar si los productos de una fase dada satisfacen las condiciones impuestas al comienzo de dicha fase. Por ejemplo, verificar el cdigo de un mdulo significa comprobar si cumple lo marcado en la especificacin de diseo donde se describe. Por otra parte, la validacin es el 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. As, validar una aplicacin implica comprobar si satisface los requisitos marcados por el usuario. Podemos recurrir a la clsica explicacin informal de Boehm de estos conceptos: Verificacin: estamos construyendo correctamente el producto? Validacin: estamos construyendo el producto correcto? Como hemos dicho, las pruebas permiten verificar y validar el software cuando ya est en forma de cdigo ejecutable. A continuacin, expondremos algunas definiciones de conceptos relacionados con las pruebas. 3.1. Definiciones Las siguientes definiciones son algunas de las recogidas en el diccionario IEEE en relacin a las pruebas [IEEE, 1990], que complementamos con otras ms informales: 5

 Pruebas (test): una actividad en la cual un sistema o uno de sus componentes se ejecuta 2 en circunstancias previamente especificadas, los resultados se observan y registran y se realiza una evaluacin de algn aspecto. Para Myers [MYERS, 1979], probar (o la prueba) es el proceso de ejecutar un programa con el fin de encontrar errores. El nombre prueba, adems de la actividad de probar, se puede utilizar para designar un conjunto de casos y procedimientos de prueba [IEEE, 1990]. Caso de prueba (test case): un conjunto de entradas, condiciones de ejecucin y resultados esperados desarrollados para un objetivo particular como, por ejemplo, ejercitar un camino concreto de un programa o verificar el cumplimiento de un determinado requisito. Tambin se puede referir a la documentacin en la que se describen las entradas, condiciones y salidas de un caso de prueba. Defecto (defect, fault, bug): un defecto en el software como, por ejemplo, un proceso, una definicin de datos o un paso de procesamiento incorrectos en un programa. Fallo (failure): La incapacidad de un sistema o de alguno de sus componentes para realizar las funciones requeridas dentro de los requisitos de rendimiento especificados. Error (error): tiene varias acepciones: 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 calculado y el real. Un defecto. Por ejemplo, una instruccin incorrecta en un programa. Un resultado incorrecto. Por ejemplo, un programa ofrece como resultado de la raz cuadrada de 36 el valor 7 en vez de 6. Una accin humana que conduce a un resultado incorrecto (una metedura de pata). Por ejemplo, que el operador o el programador pulse una tecla equivocada. Nosotros desecharemos las acepciones 2 y 3, ya que coinciden con las definiciones de defecto y fallo, para evitar equvocos. La relacin entre error, fallo y defecto queda ms clara en la Figura 121.

Figura 1. Relacin entre error, defecto y fallo. 3.2. El proceso de prueba El proceso de prueba comienza con la generacin de un plan de pruebas en base a la documentacin sobre el proyecto y la documentacin sobre el software a probar. A partir de dicho plan, se entra en detalle diseando 6

pruebas especficas basndose en la documentacin del software a probar. Una vez detalladas las pruebas (especificaciones de casos y de procedimientos), se toma la configuracin del software (revisada, para confirmar que se trata de la versin apropiada del programa) que se va a probar para ejecutar sobre ella los casos. En algunas situaciones, se puede tratar de reejecuciones de pruebas, por lo que es conveniente tener constancia de los defectos ya detectados aunque an no corregidos. A partir de los resultados de salida, se pasa a su evaluacin mediante comparacin con la salida esperada. A partir de sta, se pueden realizar dos actividades: La depuracin (localizacin y correccin de defectos). El anlisis de la estadstica de errores. La depuracin puede corregir o no los defectos. Si no consigue localizarlos, puede ser necesario realizar pruebas adicionales para obtener ms informacin. Si se corrige un defecto, se debe volver a probar el software para comprobar que el problema est resuelto. Por su parte, el anlisis de errores puede servir para realizar predicciones de la fiabilidad del software y para detectar las causas ms habituales de error y mejorar los procesos de desarrollo. 3.3. Tcnicas de diseo de casos de prueba El diseo de casos de prueba est totalmente mediatizado por la imposibilidad de probar exhaustivamente el software. Pensemos en un programa muy sencillo que slo suma dos nmeros enteros de dos cifras (del 0 al 99). Si quisiramos probar, simplemente, todos los valores vlidos que se pueden sumar, deberamos probar 10.000 combinaciones distintas de cien posibles nmeros del primer sumando y cien del segundo. Pensemos que an quedaran por probar todas las posibilidades de error al introducir los datos (por ejemplo, teclear una letra en vez de un nmero). La conclusin es que, si para un programa tan elemental debemos realizar tantas pruebas, pensemos en lo que supondra un programa medio. En consecuencia, las tcnicas de diseo de casos de prueba tienen como objetivo conseguir una confianza aceptable en que se detectarn los defectos existentes (ya que la seguridad total slo puede obtenerse de la prueba exhaustiva, que no es practicable) sin necesidad de consumir una cantidad excesiva de recursos (por ejemplo, tiempo para probar o tiempo de ejecucin). Toda la disciplina de pruebas debe moverse, por lo tanto, en un equilibrio entre la disponibilidad de recursos y la confianza que aportan los casos para descubrir los defectos existentes. Este equilibrio no es sencillo, lo que convierte a las pruebas en una disciplina difcil que est lejos de parecerse a la imagen de actividad rutinaria que suele sugerir. Ya que no se pueden probar todas las posibilidades de funcionamiento del software, la idea fundamental para el diseo de casos de prueba consiste en elegir algunas de ellas que, por sus caractersticas, se consideren representativas del resto. As, se asume que, si no se detectan defectos en el software al ejecutar dichos casos, podemos tener un cierto nivel de confianza (que depende de la eleccin de los casos) en que el programa no tiene defectos. La dificultad de esta idea es saber elegir los casos que se deben ejecutar. De hecho, una eleccin puramente aleatoria no proporciona demasiada confianza en que se puedan detectar todos los defectos existentes. Por ejemplo, en el caso del programa de suma de dos nmeros, elegir cuatro pares de sumandos al azar no aporta mucha seguridad a la prueba (una probabilidad de 4/10.000 de cobertura de posibilidades). Por eso es necesario recurrir a ciertos criterios de eleccin que veremos a continuacin. Existen tres enfoques principales para el diseo de casos: El enfoque estructural o de caja blanca (vase la figura 2). Consiste en centrarse en la estructura interna (implementacin) del programa para elegir los casos de prueba. En este caso, la prueba ideal (exhaustiva) del software consistira en probar todos los posibles caminos de ejecucin, a travs de las instrucciones del cdigo, que puedan trazarse. 7

 El enfoque funcional o de caja negra (vase la figura 2). Consiste en estudiar la especificacin de las funciones, la entrada y la salida para derivar los casos. Aqu, la prueba ideal del software consistira en probar todas las posibles entradas y salidas del programa. 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. La prueba exhaustiva consistira en probar todas las posibles entradas al programa. Estos enfoques no son excluyentes entre s, ya que se pueden combinar para conseguir una deteccin de defectos ms eficaz. Veremos a continuacin una presentacin de cada uno de ellos. Figura 2. Los enfoques de diseo de pruebas de caja blanca y de caja negra. 3.4. Pruebas estructurales. (Prueba de la caja blanca) Como hemos dicho, las pruebas exhaustivas son impracticables. Podemos recurrir al clsico ejemplo de Myers [MYERS, 1979] de un programa de 50 lneas con 25 sentencias IF en serie, en el que el nmero total de caminos contiene 33,5 millones de secuencias potenciales (contando dos posibles salidas para cada IF tenemos 225 posibles caminos). El diseo de casos tiene que basarse en la eleccin de caminos importantes que ofrezcan una seguridad aceptable en descubrir defecto, y para ello se utilizan los llamados criterios de cobertura lgica. Antes de pasar a examinarlos, conviene sealar que estas tcnicas no requieren el uso de ninguna representacin grfica especfica del software, aunque es habitual tomar como base los lla-mados diagramas de flujo de control (flowgraph charts o flowcharts). Como ejemplo de diagrama de flujo junto al cdigo correspondiente, vase la Figura 3. En el recuadro adjunto pueden consultarse algunas recomendaciones para dibujar los grafos de flujo de los programas para poder generar los casos de prueba correspondientes. Tambin existen herramientas que dibujan el grafo de flujo de un programa slo con facilitar el cdigo fuente del mismo como entrada. Figura 3. Grafo de flujo de un programa (pseudocdigo). Una posible clasificacin de criterios de cobertura lgica es la que se ofrece abajo. Hay que destacar que los criterios de cobertura que se ofrecen estn en orden de exigencia y, por lo tanto, de coste econmico. Es decir, el criterio de cobertura de sentencias es el que ofrece una menor seguridad de deteccin de defectos, pero es el que cuesta menos en nmero de ejecuciones del programa. 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. En general, una ejecucin de pruebas que cumple la cobertura de decisiones cumple tambin 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 podemos asegurar que si se cumple la cobertura de condiciones se cumple necesariamente la de decisiones. 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 simltanea (por ejemplo, segn se ejecuta en el procesador), se podra considerar que cada decisin multicondicional se descompone en varias decisiones unicondicionales. Es decir, una decisin como IF((a=1)AND(c=4)) THEN se convierte en una concatenacin de dos decisiones: IF(a=1) y IF(c=4). En este caso, debemos conseguir que todas las combinaciones posibles de resultados (verdadero/falso) de cada condicin en cada decisin se ejecuten al menos una vez.

La cobertura de caminos (secuencias de sentencias) es el criterio ms elevado: cada uno de los posibles caminos del programa se debe ejecutar al menos una vez. Se define camino como la secuencia de sentencias encadenadas desde la sentencia inicial del programa hasta su sentencia final. Como hemos visto, el nmero de caminos en un programa pequeo puede ser impracticable para las pruebas. Para reducir el nmero de caminos a probar, se habla del concepto de camino de prueba (test path): un camino del programa que atraviesa, como mximo, una vez el interior de cada bucle que encuentra. La idea en la que se basa consiste en que ejecutar un bucle ms de una vez no supone una mayor seguridad de detectar defectos en l. Sin embargo, otros especialistas recomiendan que se pruebe cada bucle tres veces: una sin entrar en su interior, otra ejecutndolo una vez y otra ms ejecutndolo dos veces. Esto ltimo es interesante para comprobar cmo se comporta9 a partir de los valores de datos procedentes, no del exterior del bucle (como en la primera iteracin), sino de las operaciones de su interior. Si trabajamos con los caminos de prueba, existe la posibilidad de cuantificar el nmero total de caminos utilizando algoritmos basados en matrices que representan el grafo de flujo del programa. As, en [SHOOMAN, 1983] y en [BEIZER, 1990] se ofrecen diversos mtodos basados en ecuaciones, expresiones regulares y matrices que permiten tanto calcular el nmero de caminos como enumerar dichos caminos expresados como series de arcos del grafo de flujo. Saber cul es el nmero de caminos del grafo de un programa ayuda a planificar las pruebas y a asignar recursos a las mismas, ya que indica el nmero de ejecuciones necesarias. Tambin sirve de comprobacin a la hora de enumerar los caminos. Los bucles constituyen el elemento de los programas que genera un mayor nmero de problemas para la cobertura de caminos. Su tratamiento no es sencillo ni siquiera adoptando el concepto de camino de prueba. Pensemos, por ejemplo, en el caso de varios bucles anidados o bucles que fijan valores mnimo y mximo de repeticiones. Se puede consultar una presentacin detallada de su tratamiento en [BEIZER, 1990]. 3.4.1. Utilizacin de la complejidad ciclomtica de McCabe. La utilizacin de la mtrica de McCabe [MCCABE, 1976] ha sido muy popular en el diseo de pruebas desde su creacin. Esta mtrica es un indicador del nmero de caminos independientes que existen en un grafo. El propio McCabe defini como un buen criterio de prueba la consecucin de la ejecucin de un conjunto de caminos independientes, lo que implica probar un nmero de caminos igual al de la mtrica. Se propone este criterio como equivalente a una cobertura de decisiones, aunque se han propuesto contraejemplos que invalidan esta suposicin. La complejidad de McCabe V (G) se puede calcular de las tres maneras siguientes a partir de un grafo de flujo G: V (G) = a n + 2, siendo a el nmero de arcos o aristas del grafo y n el nmero de nodos. V (G) = r, siendo r el nmero de regiones cerradas del grafo. V (G) = c + 1, siendo c el nmero de nodos de condicin Veamos cmo se aplican estas frmulas sobre el grafo de flujo de la figura 5: V (G) = 14 11 + 2 = 5. Los arcos han sido identificados con las marcas desde a1 hasta a14. Los nodos estn numerados del 1 al 11. V (G) = 5. Las regiones o reas cerradas (limitadas por aristas) del grafo son cinco, que hemos numerado en el grafo. Como puede verse, se ha marcado un rea (regin 5) aadiendo un arco ficticio desde el nodo 11 al nodo 1. Esto se debe a que las frmulas de McCabe slo son aplicables a grafos fuertemente conexos, es decir, aquellos para los cuales existe un camino entre cualesquiera dos nodos que se elijan. Los programas, con un nodo de inicio y otro de final, no cumplen esta condicin. Por eso, debemos marcar dicho arco o, como alternativa, contabilizar la regin externa al grafo como una ms. V (G) = 4 + 1. Los nodos de condicin son el 2, el 4, el 5 y el 6. Todos ellos son nodos de decisin binaria, 9

es decir, surgen dos aristas de ellos. En el caso de que de un nodo de condicin (por ejemplo, una sentencia Caseof) partiera n arcos (n>2), debera contabilizarse como n1 para la frmula (que equivale al nmero de bifurcaciones binarias necesarias para simular dicha bifurcacin naria). Una vez calculado el valor V (G) podemos afirmar que el nmero mximo de caminos independientes de dicho grafo es cinco. El criterio de prueba de McCabe consiste en elegir cinco caminos que sean independientes entre s y crear casos de prueba cuya ejecucin siga dichos caminos. Para ayudar a la eleccin de dichos ca-minos, McCabe [MCCABE, 1982] cre un procedimiento llamado mtodo del camino bsico, consistente en realizar variaciones sobre la eleccin de un primer camino de prueba tpico denominado camino bsico. Figura 5. Clculo de la complejidad ciclomtica sobre un grafo. En nuestro caso, un posible conjunto de caminos (descritos como secuencias de nodos visitados) podra ser el siguiente: 1211 1234102 12345102 12345679410211 12345689410211 Hemos subrayado los elementos de cada camino que lo hacen independiente de los dems. Conviene aclarar que algunos de los caminos quizs no se puedan ejecutar solos y requieran una concatenacin con algn otro. A partir de estos caminos, el diseador de las pruebas debe analizar el cdigo para saber los datos de entrada necesarios para forzar la ejecucin de cada uno de ellos. Una vez determinados los datos de entrada hay que consultar la especificacin para averiguar cul es la salida tericamente correcta para cada caso. Puede ocurrir tambin que las condiciones necesarias para que la ejecucin pase por un determinado camino no se puedan satisfacer de ninguna manera. Nos encontraramos entonces ante un camino imposible. En ese caso, debemos sustituir dicho camino por otro posible que permita satisfacer igualmente el criterio de prueba de McCabe, es decir, que ejecute la misma arista o flecha que diferencia al impo-sible de los dems caminos independientes. La experimentacin con la mtrica de McCabe ha dado como resultado las siguientes conclusiones [BEMER, 1990]: V (G) marca un lmite mnimo de nmero de casos de prueba para un programa, contando siempre cada condicin de decisin como un nodo individual. Parece que cuando V(G) es mayor que diez la probabilidad de defectos en el mdulo o en el programa crece bastante si dicho valor alto no se debe a sentencias Caseof o similares. En estos casos, es recomendable replantearse el diseo modular obtenido, dividiendo los mdulos para no superar el lmite de diez de la mtrica de McCabe en cada uno de ellos. 3.5. Prueba funcional. (Prueba de la caja negra) La 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. Lamentablemente, la prueba exhaustiva de caja negra tambin es generalmente impracticable: pensemos en el ejemplo de la suma visto en el apartado 3.3. De nuevo, ya que no podemos ejecutar todas las posibilidades de funcionamiento y todas las combinaciones de entradas y de salidas, debemos buscar criterios que permitan elegir un subconjunto de casos cuya ejecucin 10

aporte una cierta confianza en detectar los posibles defectos del software. Para fijar estas pautas de diseo de pruebas, nos apoyaremos en las siguientes dos definiciones de Myers que definen qu es un caso de prueba bien elegido: El que 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 entrada diferentes para as reducir el total de casos. Cubre un conjunto extenso de otros casos posibles, es decir, nos 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. Veremos a continuacin distintas tcnicas de diseo de casos de caja negra. 3.5.1. Particiones o clases de equivalencia Esta tcnica utiliza las cualidades que definen un buen caso de prueba de la siguiente manera: 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 que cumplan la siguiente propiedad: la prueba de un valor representativo de una clase permite suponer razonablemente que el resultado obtenido (existan defectos o no) ser el mismo que el obtenido probando cualquier otro valor de la clase. El mtodo de diseo de casos consiste entonces en: Identificacin de clases de equivalencia. Creacin de los casos de prueba correspondientes. Para identificar las posibles clases de equivalencia de un programa a partir de su especificacin se deben seguir los siguientes pasos: Identificacin de las condiciones de las entradas del programa, es decir, restricciones de formato o contenido de los datos de entrada. A partir de ellas, se identifican clases de equivalencia que pueden ser: De datos vlidos. De datos no vlidos o errneos. La identificacin de las clases se realiza basndose en el principio de igualdad de tratamiento: todos los valores de la clase deben ser tratados de la misma manera por el programa. Existen algunas reglas que ayudan a identificar clases: 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). 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). 11

 Si se especifica 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 una no vlida (no es una letra). 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 (en este caso son tres: piso, chal y local) y una no vlida (cualquier otro caso: por ejemplo, plaza de garaje). 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. La aplicacin de estas reglas para la derivacin de clases de equivalencia permi-te desarrollar los casos de prueba para cada elemento de datos del dominio de entrada. La divisin en clases deberan realizarla personas independientes al proceso de desarrollo del programa, ya que, si lo hace la persona que prepar la especificacin o dise el software, la existencia de algunas clases (en concreto, las no consideradas en el tratamiento) no ser, probablemente, reconocida. El ltimo paso del mtodo es el uso de las clases de equivalencia para identificar los casos de prueba correspondientes. Este proceso consta de las siguientes fases: Asignacin de un nmero nico a cada clase de equivalencia. Hasta que todas las clases de equivalencia hayan sido cubiertas por (incorporadas a) casos de prueba, se tratar de escribir un caso que cubra tantas clases vlidas no incorporadas como sea posible. Hasta que todas las clases de equivalencia no vlidas hayan sido cubiertas por casos de prueba, escribir un caso para una nica clase no vlida sin cubrir. La razn de cubrir con casos individuales las clases no vlidas es que ciertos controles de entrada pueden enmascarar o invalidar otros controles similares. Por ejemplo, en un programa donde hay que introducir cantidad (199) y letra inicial (AZ) ante el caso 105 & (dos errores), se puede indicar slo el mensaje 105 fuera de rango de cantidad y dejar sin examinar el resto de la entrada (el error de introducir & en vez de una letra). Veamos un ejemplo de aplicacin de la tcnica. 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 rea: nmero de 3 dgitos que no empieza por 0 ni por 1. Nombre de identificacin: 6 caracteres. rdenes posibles: cheque, depsito, pago factura, retirada de fondos. Aplicacin de las reglas Cdigo nmero, regla 3, booleana: clase vlida (nmero) clase no vlida (no es nmero) regla 5, la clase nmero debe subdividirse; por la regla 1, rango, obtenemos: 12

 subclase vlida (200 cdigo 999) dos subclases no vlidas (cdigo < 200; cdigo > 999) Nombre de id., nmero especfico de valores, regla 2: clase vlida (6 caracteres) dos clases no vlidas (ms de 6; menos de 6 caracteres) Orden, conjunto de valores, regla 4: una clase vlida para cada orden (cheque, depsito ... ); 4 en total. una clase no vlida (divisas, por ejemplo). En la tabla 1 se han enumerado las clases identificadas y la generacin de casos (presuponiendo que el orden de entrada es cdigonombreorden) se ofrece a continuacin. Condicin de entrada Clases vlidas Clases invlidas (2) cdigo <200 (3) cdigo >999 (4) no es nmero (6) menos de 6 caracteres (5) seis caracteres (7) ms de 6 caracteres (8) cheque (9) depsito Orden (10) pago factura (11) retirada fondos Tabla 1. Tabla de clases de equivalencia del ejemplo. Casos vlidos: 300 Nmina Depsito (1) (5) (9) 400 Viajes Cheque (1) (5) (8) 500 Coches Pagofactura (1) (5) (10) 600 Comida Retiradafondos (1) (5) (11) Casos no vlidos: 180 Viajes Pagofactura (2) (5) (10) 1032 Nmina Depsito (3) (5) (9) XY Compra Retiradafondos (4) (5) (11) 350 A Depsito (1) (6) (9) 450 Regalos Cheque (1) (7) (8) 550 Casa &%4 (1) (5) (12) 3.5.2. Anlisis de valores lmite (AVL). 13 (12) ninguna orden vlida

Cdigo rea

(1) 200 " cdigo " 999

Nombre para identificar la operacin

Mediante la experiencia (e incluso a travs de demostraciones) se ha podido constatar que los casos de prueba que exploran las condiciones lmite de un programa producen un mejor resultado para la deteccin de defectos, es decir, es ms probable que los defectos del software se acumulen en estas condiciones. Podemos definir las condiciones lmite como las situaciones que se hallan directamente arriba, abajo y en los mrgenes de las clases de equivalencia. El anlisis de valores lmite es un tcnica de diseo de casos que complementa a la de particiones de equivalencia. Las diferencias entre ambas son las siguientes: Ms que elegir cualquier elemento como representativo de una clase de equivalencia, se requiere la seleccin de uno o ms elementos tal que los mrgenes se sometan a prueba. Ms que concentrarse nicamente en el dominio de entrada (condiciones de entrada), los casos de prueba se generan considerando tambin el espacio de salida. El proceso de seleccin de casos es tambin heurstico, aunque existen ciertas reglas orientativas. Aunque parezca que el AVL es simple de usar (a la vista de las reglas), su aplicacin tiene mltiples matices que requieren un gran cuidado a la hora de disear las pruebas. Las reglas para identificar clases son las siguientes: Si una condicin de entrada especifica un rango de valores (l.0 valor +1.0) se deben generar casos para los extremos del rango (1.0 y +1.0) y casos no vlidos para situaciones justo ms all de los extremos ( 1.001 y + 1.001, en el caso en que se admitan 3 decimales). Si la condicin de entrada especifica un nmero de valores (el fichero de entrada tendr de 1 a 255 registros), hay que escribir casos para los nmeros mximo, mnimo, uno ms del mximo y uno menos del mnimo de valores (0, 1, 255 y 256 registros). Usar la regla 1 para la condicin de salida (el descuento mximo aplicable en compra al contado ser el 50%, el mnimo ser el 6%). Se escribirn casos para intentar obtener descuentos de 5,99%, 6%, 50% y 50,01 %. Usar la regla 2 para cada condicin de salida (el programa puede mostrar de 1 a 4 listados). Se escriben casos para intentar generar 0, 1, 4 y 5 listados. En esta regla, como en la 3, debe recordarse que: Los valores lmite de entrada no generan necesariamente los valores lmite de salida (recurdese la funcin seno, por ejemplo). No siempre se pueden generar resultados fuera del rango de salida (pero es interesante considerarlo). Si la entrada o la salida de un programa es un conjunto ordenado (por ejemplo, una tabla, un archivo secuencial, etc.), los casos se deben concentrar en el primero y en el ltimo elemento. Es recomendable utilizar el ingenio para considerar todos los aspectos y matices, a veces sutiles, en la aplicacin del AVL. 3.5.3. Conjetura de errores. La idea bsica de esta tcnica consiste en enumerar una lista 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 (se suelen corresponder con defectos que aparecen comnmente y no con aspectos funcionales). Esta tcnica tambin se ha denominado generacin de casos (o valores) especiales, ya que no se obtienen en base a otros mtodos sino mediante la intuicin o la experiencia. No existen directrices eficaces que puedan ayudar a generar este tipo de casos, ya que lo nico que se puede 14

hacer es presentar algunos ejemplos tpicos que reflejan esta tcnica. Algunos valores a tener en cuenta para los casos especiales son los siguientes: El valor cero es una situacin propensa a error tanto en la salida como en la entrada. En situaciones en las que se introduce un nmero variable de valores (por ejemplo, una lista), conviene centrarse en el caso de no introducir ningn valor y en el de un solo valor. Tambin puede ser interesante una lista que tiene todos los valores iguales. Es recomendable imaginar que el programador pudiera haber interpretado algo mal en la especificacin. Tambin interesa imaginar lo que el usuario puede introducir como entrada a un programa. Se dice que se debe preveer toda clase de acciones de un usuario como si fuera completamente tonto o, incluso, como si quisiera sabotear el programa. 3.6. 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 forma continua sin parar., Esto implica usar una herramienta denominada un generador de pruebas, a las 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 de prueba es muy comn en la prueba de compiladores en la que se generan aleatoriamente cdigos de programas que sirven de casos de prueba para la compilacin. Si el proceso de generacin se ha realizado correctamente, se crearn eventualmente todas las posibles entradas del programa en todas las posibles combinaciones y permutaciones. Tambin se puede conseguir, indicando la distribucin estadstica que siguen, que la frecuencia de las entradas sea la apropiada para orientar correctamente nuestras pruebas hacia lo que es probable que suceda en la prctica. No obstante, esta forma de disear casos de prueba es menos utilizada que las tcnicas de caja blanca y de caja negra. 3.7. Enfoque prctico recomendado para el diseo de casos. Los dos enfoques estudiados, caja blanca y caja negra, representan aproximaciones diferentes para las pruebas. El enfoque prctico recomendado para el uso de las tcnicas de diseo de casos pretende mostrar el uso ms apropiado de cada tcnica para la obtencin de un conjunto de casos tiles sin perjuicio de las estrategias de niveles de prueba: Si la especificacin contiene combinaciones de condiciones de entrada, comenzar formando sus grafos de causaefecto (ayudan a la comprensin de dichas combinaciones). En todos los casos, usar el anlisis de valoreslmites para aadir casos de prueba: elegir lmites para dar valores a las causas en los casos generados asumiendo que cada causa es una clase de equivalencia. Identificar las clases vlidas y no vlidas de equivalencia para la entrada y la salida, y aadir los casos no incluidos anteriormente (cada causa es una nica clase de equivalencia? Deben dividirse en clases?). Utilizar la tcnica de conjetura de errores para aadir nuevos casos, referidos a valores especiales. Ejecutar los casos generados hasta el momento (de caja negra) y analizar la cobertura obtenida. Examinar la lgica del programa para aadir los casos precisos (de caja blanca) para cumplir el criterio de cobertura elegido si los resultados de la ejecucin del punto 5 indican que no se ha satisfecho el criterio de cobertura elegido (que figura en el plan de pruebas). Aunque ste es el enfoque integrado para una prueba razonable, en la prctica la aplicacin de las distintas tcnicas est bastante discriminada segn la etapa de la estrategia de prueba. 15

Otra cuestin importante en relacin a los dos tipos de diseo de pruebas es: por qu incluir tcnicas de caja blanca para explorar detalles lgicos y no centrarnos mejor en probar los requisitos funcionales con tcnicas de caja negra? (si el programa realiza correctamente las funciones por qu hay que intentar probar un determinado nmero de caminos?). Los errores lgicos y las suposiciones incorrectas son inversamente proporcionales a la probabilidad de que se ejecute un camino del programa (a menor probabilidad de ejecutarse un camino, mayor nmero de errores). Se suele creer que un determinado camino lgico tiene pocas posibilidades de ejecutarse cuando, de hecho, se puede ejecutar regularmente. Los errores tipogrficos son aleatorios; pueden aparecer en cualquier parte del programa (sea muy usada o no). La probabilidad y la importancia de un trozo de cdigo suele ser calculada de forma muy subjetiva. Debemos recordar que tanto la prueba exhaustiva de caja blanca como de caja negra son impracticables. Bastara, no obstante, una prueba exhaustiva de caja blanca solamente? Vase el siguiente programa: if ((x+y+z)/13 = x) printf(X, Y y Z son iguales); else printf(X, Y y Z no son iguales); En este programa, una prueba exhaustiva de caja blanca (que pase por todos los caminos) no asegura necesariamente la deteccin de los defectos de su diseo. Vase, por ejemplo, cmo los dos casos siguientes no detectan ningn problema en el programa: x=5, y=5, z=5 x=2, y=3, z=7 Estos contraejemplos no pretenden influir en el tipo de tcnica de diseo de casos que debemos elegir. Ms bien nos indican que conviene emplear lo mejor de todas las tcnicas para obtener pruebas ms eficaz. El caso x=2, y=3, z=1 s permitira detectar el defecto de diseo de la decisin. I.E.S. Almunia. ADAIG. 3 Cmo dibujar un grafo de flujo. Para dibujar el grafo de flujo de un programa es recomendable seguir los siguientes pasos: Sealar sobre el cdigo cada condicin de cada decisin (por ejemplo, mismo producto en la figura 3 es una condicin de la decisin haya registros y mismo producto) tanto en sentencias Ifthen y Caseof como en los bucles While o Until. Agrupar el resto de las sentencias en secuencias situadas entre cada dos condiciones segn los esquemas de 16

representacin de las estructuras bsicas que mostramos a continuacin.

Figura 4. Grafo de flujo de las estructuras bsicas de programa Numerar tanto las condiciones como los grupos de sentencias, de manera que se les asigne un identificador nico. Es recomendable alterar el orden en el que aparecen las condiciones en una decisin multicondicional, situndolas en orden decreciente de restriccin (primero, las ms restrictivas). El objetivo de esta alteracin es facilitar la derivacin de casos de prueba una vez obtenido el grafo. Es conveniente identificar los nodos que representan condiciones asignndoles una letra y sealar cul es el resultado que provoca la ejecucin de cada una de las aristas que surgen de ellos (por ejemplo, si la condicin x es verdadera o falsa).

17