Generacin de casos de prueba a partir de especificaciones UML

Luis Fernndez, Pedro J. Lara

Depto. de Programacin e Ingeniera del Software Universidad Europea de Madrid
lufern@dpris.esi.uem.es, pedro@dpris.esi.uem.es

Celia Gutirrez
Universidad Camilo Jos Cela
celiagutierrez@hotmail.com

RESUMEN La generacin sencilla de los casos de pruebas de una aplicacin es una aspiracin antigua de los desarrolladores de software. A lo largo de la historia en investigacin sobre pruebas de software, han existido diversas tentativas de lograr este sueo incluso promoviendo entornos y herramientas que ayudan en la generacin automtica de pruebas a partir de distintos tipos de informacin descriptiva de la aplicacin. Sin embargo, es habitual que tanto las descripciones necesarias para aplicar estas tcnicas como los entornos propicios para ello no sean habituales en los proyectos de desarrollo debido tanto a razones de formato como de frecuencia de uso o dificultad de aplicacin en los desarrollos. En esta comunicacin veremos cmo utilizando informacin de una especificacin de requisitos desarrollada con notacin UML se puede generar un conjunto apropiado de pruebas para la correspondiente aplicacin. Palabras clave Diagramas de actividad, especificaciones, UML, casos de prueba. 1 INTRODUCCIN

software, junto a otras alternativas de evaluacin como revisiones, auditoras, mtricas, etc. Entendemos las pruebas de software como la ejecucin de un programa con el fin de detectar defectos [1]. Para ello, el diseo de las pruebas se basa en la creacin de casos de prueba cuya ejecucin permitir observar posibles sntomas de defectos. Se puede definir un caso de prueba como el 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 [2]. Toda la capacidad de deteccin de defectos de las pruebas se basa en la consideracin de cualquier tipo de discrepancia entre la salida obtenida y la salida esperada (segn lo indicado en las especificaciones) como sntoma de un problema en el software. En consecuencia, todas las tcnicas de diseo de casos de prueba existentes se basan en tomar las especificaciones como referencia de comportamiento de la aplicacin. Lgicamente es importante que la especificacin haya sido validada con el mayor cuidado, seguramente mediante revisiones, para detectar posibles problemas de [3]: Complecin: est completa ya que incluye toda la informacin necesaria (por ejemplo, no deja ninguna situacin de funcionamiento

Las pruebas de software son una tcnica clsica para la verificacin y validacin del

sin definir su comportamiento). Coherencia: internas. no existen contradicciones

Exactitud: se reflejan con precisin las necesidades del cliente. Calidad: legibilidad, facilidad de verificacin, etc.

[1][6]. Los criterios de seleccin (denominados criterios de cobertura) suelen pretender la cobertura de un porcentaje o una representacin del universo posible de elementos estructurales o de situaciones funcionales. De hecho, algunos autores hablan ms de seleccin de casos de pruebas ms que de diseo de los mismos [7]. Por ltimo, nada impide que el diseo y la planificacin de las pruebas se inicie en paralelo al trabajo de especificacin. No slo es algo posible sino que se trata de una prctica recomendada para lograr mayor calidad, productividad y disminucin de riesgos [8][9][10].

En general, es recomendable que estas y otras cualidades [4] estn presentes en la especificacin que se toma como referencia para las pruebas. Las tcnicas de pruebas de software asumen una serie de principios demostrados que condicionan su aplicacin y que podemos expresar de la siguiente manera: Las dos principales filosofas de diseo suelen ser las de caja blanca y caja negra. La primera se centra en la exploracin de las distintas opciones del comportamiento externo a travs de las entradas y salidas del programa (caja negra) y la de caja blanca se apoya en la exploracin de los distintos elementos de la estructura interna. Los mejores resultados suelen aparecer combinando las ventajes de ambas aproximaciones [1]. Resulta inviable plantear pruebas exhaustivas de cualquier aplicacin ya que no se pueden probar todas las posibles entradas y/o situaciones de funcionamiento en plazos y costes razonables (como se puede apreciar, por ejemplo, en [1] y [5]). Por lo tanto, no existe una solucin nica y definitiva, tras la cual no queden dudas de queden posibles defectos en el software. En consecuencia, resulta imprescindible que el diseo de pruebas se apoye en la seleccin de algunas entradas o situaciones que ejercitar (dentro de todo el universo posible), siempre en funcin de que sean representativas en su comportamiento de otros casos similares
2

Por supuesto, el aumento en la complejidad y sofisticacin tecnolgica del software ha supuesto la evolucin de estas reglas bsicas de diseo y, sobre todo, de las tcnicas de especificacin y de diseo de software. As, la llegada de las interfaces de usuario grficas y las aplicaciones cuyo funcionamiento est basado en eventos complic el manejo en las pruebas de las combinaciones de entradas y de las opciones de funcionamiento. Sin embargo, las pruebas deben seguir basndose en las especificaciones que sirven de referencia de las necesidades del cliente. Desde hace mucho tiempo (por ejemplo, [11]), se ha optado por especificaciones de las interfaces grfica de usuario (GUI1) que describen su comportamiento a travs de diversas variantes de diagramas de estados que reflejan la evolucin dinmica de su funcionamiento y del flujo de eventos implicado. As ocurre, por ejemplo, en [12], mientras que otras propuestas se centran en los diagramas de estados que describen el comportamiento de cada clase [13]. De hecho, cualquiera de estas representaciones permite describir criterios de cobertura para la GUI o la estructura de la aplicacin as como mtodos de diseo

En ingles, Graphical User Interface.

sistemtico de las pruebas o de verificacin a partir de dichos modelos de especificacin.

Figura 1. Diagrama de estados de una GUI usado en [12]

Uno de los problemas de estas aproximaciones es la peculiaridad de los modelos empleados y que los analistas deben generar cuando realizan el trabajo de especificacin de un sistema. Al tratarse de notaciones no convencionales que requieren un considerable esfuerzo, la aplicacin de estas tcnicas resulta poco viable en la mayora de los entornos. Frente a esta situacin, en nuestra propuesta deseamos aproximarnos a enfoques metodolgicos con un mayor grado de implantacin en los proyectos de desarrollo profesional y comercial. As, la implantacin de UML [14] como notacin de desarrollo orientado a objetos ha permitido la difusin e implantacin real de tcnicas de especificacin de software como los casos de uso. En el siguiente apartado, describiremos el formato exacto de especificacin basada en UML que nos servir de base para el mtodo sistemtico de diseo de pruebas de software. Tambin se podr apreciar cmo un apropiado trabajo de especificacin tiene como recompensa adicional la facilidad para el establecimiento de pruebas directamente relacionadas con los requisitos del software. 2 ESPECIFICACIN UML BASADA EN CASOS DE USOS

la especificacin del comportamiento externo de un sistema. Un caso de uso se define como unidad coherente de funcionalidad [...] manifestada por secuencias de mensajes intercambiados por el sistema y uno o ms actores externos junto a las acciones desarrolladas por el sistema [16]. Supone una buena expresin de la interaccin de actores con el sistema para obtener un resultado observable y valioso para los mismos [14]. Como especificacin los casos de uso resultan especialmente aclaratorios cuando se complementan con diagramas de actividad (ver figura 2). Un diagrama de actividades es un caso especial de un diagrama de estados. ste ltimo puede definirse como un modelo que muestra el conjunto de estados por los cuales pasa un objeto durante su vida en una aplicacin, junto con los cambios que permiten pasar de un estado a otro. En los diagramas de actividad, casi todos los estados son estados de accin (identifican qu accin se ejecuta al estar en l) y casi todas las transiciones son activadas al terminar la accin ejecutada en el estado anterior. Permiten detallar el comportamiento de un caso de uso, de un objeto o de un mtodo en un objeto. A continuacin podemos ver cmo una descripcin de un caso de uso (en un formato estndar [17]) se puede expresar con un diagrama de actividad equivalente.
CASO DE USO: BAJA DE USUARIO Objetivo: Borrar completamente los datos de un usuario de la base de datos de la aplicacin. Flujo normal de acontecimientos: Actor 1 Solicita Baja Usuario 3 Introduce ID Usuario 5 Confirma Baja Usuario Sistema 2 Solicita ID Usuario 4 Muestra datos de usuario y pide confirmacin de baja 6 Muestra confirmacin de Baja Usuario

Flujos alternativos:

Propuestos por Jacobson [15], los casos de uso son una parte esencial de la notacin UML para
3

En el 4, si el DNI no existe, entonces muestra un mensaje y vuelve al paso 3. En cualquier caso, si el actor selecciona cancelar, entonces no se realiza ninguna opcin y se vuelve al men principal de la aplicacin. Precondiciones Debe existir el usuario que se desea dar de baja. Postcondiciones Eliminacin de los datos del usuario de la base de datos de la aplicacin. 6 Interfaz

tratada ya en diversas contribuciones en congresos y publicaciones. De hecho, incluso en la quinta edicin de las JICS se present una idea al respecto para pruebas de aceptacin [18], donde los casos de uso se complementaban con el tratamiento de combinaciones presente en [1]. Otras opciones de seleccin de casos de pruebas se han basado en [7] y [12].

S o l i c i ta b a j a d e u su a ri o R e q u i e re i d e n t i f i c a d o r d e u su a ri o

C a n c e l a r?

No

El diagrama de actividad correspondiente se puede ver en la figura 2. En cada diagrama de actividad, un escenario de uso (ejecucin especfica de un caso) se representa un camino especfico desde el inicio hasta un final del diagrama de actividad. En adelante asumiremos una especificacin de un sistema que utilice los casos de uso (lo que actualmente es algo habitual dada la extensin de esta tcnica) y que emplee un diagrama de actividad para explicar mejor el comportamiento de cada caso a los usuarios y a quienes validan y comprueban la especificacin. En esta comunicacin pretendemos mostrar cmo este tipo de especificacin UML puede permitir una generacin rpida de escenarios de prueba manteniendo como veremos en los prximos apartados. 3 CRITERIO DE GENERACIN DE PRUEBAS A PARTIR DE CASOS DE USO: TIPOS DE ESCENARIOS

I n t ro d u c e i d e n t i f i c a d o r d e u s u a ri o No

I d c o rre c t o ?

C a n c e l a r?

No M o st r a r d a t o s d e u su a ri o y p e d i r c o n f i rm a c i n

C o n f i rm a r baja C o n f i rm a r S M u e st ra c o n f i rm a c i n No

Figura 2. Diagrama de actividad para el caso de baja de usuario

La utilizacin de los casos de uso como base para el diseo de casos de prueba de software ha sido
4

En nuestro caso, proponemos adoptar un criterio de seleccin de casos de prueba basado en la exploracin de los distintos escenarios de ejecucin de caso de uso. En un diagrama de actividad, podemos asumir que existen diversos tipos de escenarios marcados por cada camino

que se puede trazar en el mismo partiendo de su estado inicial. El nmero de caminos distintos en un diagrama de actividad suele ser muy elevado incluso en los casos ms sencillos. Debemos tener en cuenta que un camino puede diferenciarse de otro simplemente en el hecho de que pase por un ciclo del diagrama de actividad un nmero distinto de veces. Por ejemplo, un camino en el anterior ejemplo es aquel que traza el siguiente recorrido de eventos:
Camino 1: Se solicita la baja de usuario, el sistema requiere el identificador del usuario, se introduce el identificador, el sistema comprueba que no es correcto (no corresponde a ningn usuario dado de alto), se introduce un nuevo identificador, se muestran sus datos, se confirma su baja y el sistema muestra la confirmacin de baja y acaba el caso.

infinitas: introduciendo caracteres que no son cifras, etc.). Como se indic en la introduccin, ya que no resulta viable comprobar el comportamiento del software en todas las situaciones de funcionamiento, debemos seleccionar los casos de prueba eligiendo aquellos que resulten representativos de otros muchos equivalentes. As, el comportamiento del software (por ejemplo, falla en hacer lo previsto) con un caso de prueba (por ejemplo, uno basado en el camino 1 se podra suponer, razonablemente, que sera idntico en uno del mismo tipo (por ejemplo, uno basado en el camino 2 con equivalentes entradas de datos). En nuestro caso, el primer criterio de eleccin de casos se basar en la traza de caminos a travs del diagrama de actividad. Ser un criterio de cobertura similar al que se plantea con otros tipos de diagramas en [12]. Para ello nos inspiraremos en la teora de grafos y utilizaremos un criterio anlogo al que McCabe [19] utilizaba con los grafos de flujo de control del cdigo procedimental. Recordemos que el criterio de pruebas estructurado exige que se pruebe un conjunto mnimo de caminos representativos (linealmente independientes, segn el razonamiento de McCabe) del conjunto total posible. Este conjunto debe asegurar que la traza de ejecucin pasa por todas las flechas o aristas del grafo y resulta equivalente al tradicional criterio de cobertura de decisiones contemplado en [1]. Por lo tanto, nuestro primer criterio de cobertura de pruebas basadas en casos de uso se expresar como sigue: Un caso de uso, a travs de su diagrama de actividad, estar suficientemente probado si los caminos utilizados (tipos de escenarios) permiten pasar por todas las flechas o transiciones del diagrama de actividad al menos una vez.

Otro camino considerado diferente sera el siguiente:

Camino 2: Se solicita la baja de usuario, el sistema requiere el identificador del usuario, se introduce el identificador, el sistema comprueba que no es correcto (no corresponde a ningn usuario dado de alto), se introduce un nuevo identificador, el sistema comprueba de nuevo que no es correcto (no corresponde a ningn usuario dado de alta), se introduce un nuevo identificador, se muestran sus datos, se confirma su baja y el sistema muestra la confirmacin de baja y acaba el caso.

En definitiva, el actor ha fallado dos veces en aportar el identificador de usuario. Pero no slo el nmero de caminos diferentes de un diagrama de actividad puede ser muy elevado sino que dentro de cada camino (tipo de escenario) podemos distinguir mltiples escenarios de pruebas posible simplemente considerando todas las posibilidades de valores de datos de entrada posibles. Por ejemplo, en el caso anterior, si el identificador de usuario corresponde con un nmero entero de 6 cifras, tendramos al menos un milln de opciones, nicamente de valores vlidos (las posibilidades de valores no vlidas admisibles son virtualmente
5

El razonamiento de este criterio obedece a la intencin de que todas las opciones de comportamiento contempladas en el caso de uso, a travs de su diagrama de acatividad, estn probadas al menos una vez: es decir, no nos limitamos a probar el flujo de eventos happy day sino todos los flujos alternativos del caso. Al igual que en [19], sera posible aplicar las frmulas clsicas de clculo del nmero mximo de caminos (tipos de escenarios), aplicables a cualquier tipo de grafo conexo, necesario para cumplir este criterio de cobertura.
1

limitadas por aristas. En los clculos, se cuenta la regin que rodea al grafo como un rea cerrada ms. En el caso anterior, observamos que V(G)=4, algo que se podra prever intuitivamente al mirar el grafo. Los cuatro caminos independientes son los siguientes: 1-2,3-4,5-10-1... 1-2,3-6-8-9-10-1... 1-2,3-6-7-9-10-1... 1-11

2,3

En el caso del diagrama de actividad de la figura 2, el clculo nos lleva a limitar el nmero de caminos (tipos de escenarios) a 5, que en la prctica podramos condensar en las siguientes 4 clases de interacciones entre usuario y sistema: Solicita baja, requiere ID y cancela. Solicita baja, requiere ID, introduce ID no correcto, introduce ID correcto, confirma baja. Solicita baja, requiere ID, introduce ID correcto, cancela. Solicita baja, requiere ID, introduce ID correcto, no confirma baja.

4,5

7 9

10

11

Figura 3. Ejemplo de diagrama de flujo genrico

CRITERIO DE GENERACIN DE PRUEBAS A PARTIR DE CASOS DE USO: CRITERIOS DE CAJA NEGRA

Las frmulas para obtener el nmero mximos de caminos independientes del grafo G, V(G), son las siguientes (el resultado obtenido con cada una de ellas debe ser igual para un mismo grafo): V(G)=n regiones V(G)=P+1 V(G)=A-N+2 P es el nmero de nodos predicado (nodos con ms de una flecha de salida), A es el nmero de aristas o flechas y N es el nmero de nodos o crculos. Las regiones son reas cerradas
6

En cada camino de un diagrama de actividad (tipo de escenario) pueden existir demasiados escenarios distintos como para asegurar la representatividad de todos ellos en un solo caso de prueba.

Siguiendo las recomendaciones tradicionales de diseo de pruebas de caja negra [1], deberamos realizar un anlisis del dominio de valores de entrada para detectar grupos/clases de datos que cuenten con un comportamiento homogneo en el sistema; es decir, la aplicacin trata todos los

valores del grupo de la misma manera. As, si el sistema falla al ser probado con un dato, podemos suponer que fallara igualmente cuando introduzcamos otro de la misma clase. A esta tcnica se le denomina clases de equivalencia. Algunas de ellas las componen datos vlidos de entrada y otros datos no vlidos. Como ejemplo, se puede decir que si una entrada especifica un rango (por ejemplo, valores entre 0 y 99), se tendrn dos clases de equivalencia no vlidas (valores fuera de los lmites del rango por arriba, mayor que 99, y por abajo, menor que cero) y otra vlida (valores dentro del rango) Una vez extradas las clases de equivalencia, en vez de probarlas con cualquier tipo de valor, es recomendable elegir aquellos que constituyen los lmites de la clase ya que tienen mayor probabilidad de detectar defectos. Por lo tanto, nuestro segundo criterio de cobertura de pruebas basadas en casos de uso se expresar como sigue [1]: Para las entradas de datos en un caso de uso, debemos lograr que todas las clases de equivalencia vlidas sean ejercitadas por un caso de pruebas y que cada clase no vlida sea comprobada en solitario en un caso especfico, logrando que se ejerciten todos los valores lmite. La combinacin de ambos criterios en un diagrama de actividad resulta fcil utilizando los elementos de representacin contemplados en la notacin UML. As, en los pasos de un caso de uso que supongan entrada de datos, no utilizaremos el concepto de accin sino el de actividad. Mientras que una accin es un estado con una accin de entrada y al menos una de salida [...] no debe tener transiciones internas basadas en eventos explcitos [16]. En general, se indica que una accin es elemental y no puede ser interrumpida cuando se inicia [15]. Por el contrario, una actividad invoca un subdiagrama de actividad. Cuando se entra en un
7

estado de actividad, el diagrama anidado se ejecuta [...] No se sale del subdiagrama hasta que se alcanza su estado final [16].
Accin Activ idad

Figura 4. Smbolos de accin y actividad

En nuestro caso, cada paso de introduccin de datos se convertir en un estado de actividad cuyo subdiagrama deber expresar las distintas opciones de prueba basadas en clases de equivalencia y valores lmite. En el ejemplo de baja de usuario, el diseo de clases de equivalencia para la introduccin de identificador de usuario supone la creacin de una tabla como la siguiente:
Restricciones de la entrada Identificador de usuario Grupos de datos vlidos Es nmero (1) Grupos de datos no vlidos

No es nmero (3) Mayor de 999999 (4) Tiene 6 cifras (2) Menor de 000000 (5)

Tabla 1. Tabla de clases para identificador de usuario

Los casos que deberan generarse para la tabla 1 deben asegurar que todas las clases cuentan con casos con todos sus valores lmite contemplados. Un ejemplo de estos casos y las clases que contemplan seran los siguientes: 999999 (1)(2) 000000 (1)(2) A546B6 (3) 1000000 (4) -000001 (5) Para ello, es importante transformar el diagrama de actividad original como el de la figura 2, en el que simplemente se representa la estructura de los flujos del caso de uso. El nuevo diagrama debera contemplar una actividad en todos los pasos en los que se produzca entrada de datos y un subdiagrama con la estructura de opciones de casos correspondiente.

Id Usuario 000000

Id Usuario 999999

Id Usuario 1000000

Id Us uari o -000001

Id Usuario no nmero

Solicita baja de usuario

Req uiere identificador de usuario

Figura 6. Subdiagrama de actividad para Introducir ID Usuario.

C ancelar ?

MTODO DE GENERACIN CASOS DE PRUEBA

DE

Introducir id usuario

Contemplando los dos criterios de cobertura expresados en nuestra propuesta, el mtodo de generacin de casos de pruebas se realizara en la prctica de la siguiente manera:
C ancelar ?

No Mostrar datos de usuario y pedir confirmacin

Confirmar baja Confirmar

S Muestra confirmacin No

Figura 5. Diagrama definitivo con estado de actividad para la introduccin del identificador de usuario

Como se contempla en la jerarqua de diagramas prevista por UML y que queda patente en el funcionamiento de las herramientas convencionales de diagramacin como Rose, el estado de actividad Introducir ID Usuario lleva asociado el diagrama de la figura 6.

1. Generar para cada caso de uso, a partir de la descripcin de su interaccin (ver apartado 2), un diagrama de actividad primario donde se marcan los caminos de flujos de eventos (figura 2). 2. Identificar en cada flujo la introduccin de datos y analizar para cada caso las clases de equivalencia, valores lmites e , incluso, tratamiento de combinaciones (como el previsto en [18] tomado de [1]). 3. Transformar cada accin de entrada de datos en un estado de actividad que contenga como subdiagrama las opciones de entradas y de tratamiento de las mismas (figura 6), generando el diagrama definitivo (figura 5). 4. Contemplando el diagrama definitivo, cumplir con los dos criterios de cobertura de manera que todas las flechas o aristas del mismo sean ejercitadas, al menos, una vez. El hecho de que, a partir de un grafo, es fcil contar con un programa que nos proporcione automticamente tanto el nmero de caminos existente como la descripcin de los mismos. Los algoritmos que existen son muy variados si bien, como en las pruebas de caja blanca, se pueden apoyar en las expresiones regulares que
8

caracterizan las distintas estructuras topolgicas de los grafos de flujo [20][21]. Dado que estos algoritmos son claros y bien definidos, la construccin de programas que automaticen esta tarea es inmediata. En nuestro caso, dicho programa ya est diseado si bien debe partir de una introduccin especfica de la topologa. Actualmente estamos evaluando la posibilidad de que a travs de XMI pueda importarse la estructura de los diagramas directamente desde herramientas CASE de amplia difusin (Rose, Tau, etc.). Evidentemente, como en las propuestas de pruebas estructurales tradicionales de McCabe [22], es importante considerar los siguientes puntos para una correcta aplicacin prctica: Dado que la cobertura de realizarse formando caminos de ejecucin a travs del diagrama definitivo, es importante controlar que los caminos formados no sean imposibles de ejecutar por combinar resultados de decisin incompatibles. A este respecto, la posibilidad de aplicar estereotipos a las distintas acciones del diagrama (como se hace en [23]), facilitara la deteccin automtica de dichos caminos imposibles (por ejemplo, para detectar que no existan dos tratamientos de error en el mismo caso de prueba, siguiendo la recomendacin de [1]). Todo caso de prueba debe incorporar tanto la entrada de datos y eventos como la salida esperada segn la especificacin. Para ayudar a documentar correctamente cada caso de pruebas es recomendable tomar en consideracin tanto las pre y poscondiciones del caso de uso (como se aprecia en la descripcin estndar presentada en el apartado 2) como la posibilidad de incorporar informacin al diagrama en forma de caminos o como restricciones UML.
9

Con el objeto de que el control de los requisitos que debe cumplir la aplicacin sea ms eficaz, actualmente estamos analizando la posibilidad de que el mtodo de generacin de casos/escenarios se integre en herramientas de requisitos como IrqA con la que trabajamos desde hace tiempo a travs del convenio con TCPSI. En esta herramienta, como se recomienda en la bibliografa de pruebas y en las metodologas y procesos de desarrollo en general (vase el apartado 1), es conveniente plantear las pruebas ya desde el establecimiento de los requisitos del software. Este tipo de herramientas permite describir escenarios para pruebas del software que estamos especificando.

ALGUNAS CONCLUSIONES

Se puede aprender bastante de la experiencia de haber tenido que asumir la realizacin de pruebas independientes en aplicaciones de gestin que, para el entorno dado, se supona bien documentadas en su especificacin. Las especificaciones de tipo estructurado resultan muy poco adecuadas para el control de pruebas de aceptacin como demuestra el hecho de que en el proyecto mencionado no se obtuvo una significativa deteccin de defectos aplicando la sistemtica de diseo de casos. Los defectos surgieron de la realizacin de un nuevo y costoso trabajo de repeticin de anlisis de la aplicacin. La confianza que supone la utilizacin de tcnicas ms adecuadas a los entornos de desarrollo actuales como los casos de uso y las especificaciones UML descritas en este trabajo redunda en una mayor facilidad para obtener, simultneamente y como beneficio aadido, una descripcin bastante fiable de un conjunto de pruebas apropiado para el sistema. Esta generacin de casos de prueba puede resultar incluso ms productiva tras el desarrollo de los mecanismos de automatizacin en la aplicacin del mtodo propuesto a partir de la

documentacin de diagramas en CASE ya habituales para los desarrolladores. No se debe descartar que las descripcin de casos obtenida se pueda, con un pequeo desarrollo, transformar en scripts (como ya hacen otras herramientas) que alimente una herramienta de GUI replay para pruebas2.

J.R. Cameron, IEEE Computer Society Press, 1983 [12] A.T.Memon, M.L. Soffa, M.E. Pollack, Coverage criteria for GUI testing, 8th European Software Engineering Conference (ESEC) and 9th ACM SIGSOFT International Symposium on the Foundations of Software Engineering (FSE-9), Vienna University of Technology, Austria, Sept. 10-14, 2001. [13] M.E. Vieira, M.S. Dias y D.J.Richardson, Object-oriented specification-based testing using UML statecharts diagrams, Proceedings of the 22nd International Conference on Software Engineering (ICSE 2000), junio, 2000. [14] G. Booch, J. Rumbaugh e I. Jacobson, El lenguaje unificado de modelado, AddisonWesley, 1999. [15] I. Jacobson, Object-oriented engineering, Addison-Wesley, 1992. software

BIBLIOGRAFA Y REFERENCIAS [1] G.J.Myers, The art of software testing, John Wiley & sons, 1979. [2] IEEE, IEEE Std. 610 Computer dictionary, IEEE, 1990. [3] E. Yourdon, Structured Prentice-Hall, 1985. walkthroughs,

[4] IEEE, IEEE Std. 830 guide to software requirements specifications, IEEE, 1998. [5] B. Beizer, Software testing techniques, Van Nostrand Reinhold, 1990. [6] IEEE, IEEE Std. 829 for Software Test Documentation, IEEE, 1998. [7] E.M. Choi y A. von Mayrhauser, Testing object-oriented systems using extended usecases, PDPTA Conference, vol. 2 , 2000. [8] IEEE, IEEE Std. 1012 for Software Verification and Validation, IEEE, 1998. [9] M. C. Paulk, C.V.Weber, S. M. Garcia, M. B. Chrissis y M. Bush, Capability Maturity Model For Softwarem v. 1.1., CMU/SEI-93-Tr-25, SEI, 1993. [10] Consejo Superior de Informtica, Mtrica versin 3. Gua de referencia, MAP, 2001. [11] Autores varios, JSP [and] JSD : the Jackson approach to software development, editado por
2

[16] Object Management Group, OMG unified modeling language specification. Version 1.3, OMG, junio, 1999. [17] G. Schneider y J. P. Winters, Applying Use Cases. A Practical Guide, Addison-Wesley, 2001. [18] J.L. Fernndez, Utilizacin de casos de uso en las pruebas de aceptacin, V Jornadas sobre Calidad del Software, 2000, pp. 65-76. [19] T.J. McCabe, A complexity measure, IEEE Transactions on software engineering, vol. 2, pp. 228-363, 1976. [20] M.L. Shooman, Software engineering: design, reliability and management, McGrawHill, 1983. [21] T.J. McCabe (ed.), IEEE Tutorial: structured testing, IEEE Computer Society, 1982. [22] B. Lieberman, UML Activity Diagrams: Versatile Roadmaps for Understanding System Behaviour, The Rational Edge, abril, 2001 (ver http://www.therationaledge.com/content/apr_01)

Herramientas que automatizan la reproduccin de eventos de interfaz grfica de usuario para la entrada de datos de pruebas. Tambin pueden capturar la salida y compararla con una salida esperada pre-especificada. 10

11