UNIVERSIDAD AUTNOMA DE TLAXCALA

DEPARTAMENTO DE INGENIERA Y TECNOLOGA UNIDAD DE ESTUDIOS DE POSGRADO

PRUEBA DE COMPONENTES DE SOFTWARE BASADAS EN EL MODELO DE JAVABEANS

TESISQUE PARA OBTENER EL GRADO DE

MAESTRO EN CIENCIAS EN INGENIERA EN COMPUTACINPRESENTA:

PERLA INS VELASCO ELIZONDO.DIRIGIDA POR:M.I. JUAN MANUEL FERNNDEZ PEA. M.C. MA. ELENA HERNNDEZ HERNNDEZ.

APIZACO, TLAX.

ABRIL DE 2001.

Dedico cariosamente este trabajo a:

Mis padres, porque con su invaluable apoyo pude iniciar y terminar esta nueva etapa.

Mi hermana Lilia.

Sodel, que comparte conmigo la emocin de este nuevo momento.

Mi maestro y asesor Juan Manuel Fernndez Pea.

ndice

Resumen ........................................................................................................................ Abstract .......................................................................................................................... Introduccin .................................................................................................................

1 2 3

1. Sofware Basado en Componentes ...................................................................1.1 El concepto de componente .......................................................................... 1.2 El concepto de software basado en componentes ........................................

66 8

1.3 Objetos y componentes ................................................................................... 9 1.4 Modelos para el desarrollo ............................................................................ 1.4.1 COM y DCOM ..................................................................................... 1.4.2 Corba ........................................................................................... 1.4.3 JavaBeans ................................................................................ 1.4.3.1 El bean development kit ........................ 10 10 11 12 14

2. Revisin Tcnica sobre Prueba de Software ...................................... .. 172.1 La prueba de software .................................................................................. 2.2 Objetivos de la prueba del software ............................................................ 2.3 Mtodos de prueba del software .................................................................. 2.3.1 2.3.2 Pruebas de caja blanca .................................................................... Pruebas de caja negra ...................................................................... 17 19 20 20 22 23 25 26 27

2.4 Niveles de prueba del software .................................................................... 2.5 Prueba de software para objetos ................................................................. 2.5.1 2.5.2 Generalidades del modelo de desarrollo orientado a objetos ............................................................................ Aspectos a considerar en la prueba del software orientado a objetos .............................................................

2.5.3

Mtodos de prueba de software orientado a objetos ........................................................................................... 30 30 32 34 35 35 36 36 Pruebas de unidad ................................................................... Pruebas de integracin ........................................................... Pruebas de sistema ................................................................

2.5.3.1 2.5.3.2 2.5.3.3 2.6.1

2.6 Prueba de software basado en componentes ............................................ Mtodos de prueba de software basado en componentes ............................................................................... 2.6.1.1 2.6.1.2 Pruebas de unidad .................................................................. Pruebas de integracin ............................................................

3. Descripcin del Diseo .....................................................................................3.1 Antecedentes ............................................................................................... 3.2 La prueba de beans ..................................................................................... 3.3 Aspectos de diseo ..................................................................................... 3.3.1 Seleccin de los componentes .......................................................... 3.3.2 La generacin de casos de prueba .................................................... 3.3.3 La ejecucin de casos de prueba ...................................................... 3.3.4 La presentacin de resultados ...........................................................

3838 39 42 44 46 50 52

4. Descripcin de la Arquitectura e Implementacin ......................................4.1 Arquitectura y colaboracin entre clases ..................................................... 4.1.1 4.1.2 4.1.3 4.1.4 4.1.5 4.1.6 La invocacin de los servicios .......................................................... La extraccin de archivos jar ............................................................ La generacin de casos de prueba .................................................. La ejecucin de casos de prueba generados automticamente .............................................................................. La ejecucin de casos de prueba generados manualmente .................................................................................... La presentacin de resultados .........................................................

5656 59 61 64 67 70 73

5. Pruebas de Funcionamiento ............................................................................5.1 Los componentes utilizados .......................................................................... 5.2 El componente Puzzle ................................................................................ 5.2.1 Los resultados observados ................................................................. 5.3 El componente TextEditor ........................................................................... 5.3.1 Los resultados observados ................................................................. 5.4 El componente ProgressBar ........................................................................ 5.4.1 Los resultados observados .................................................................

7777 78 80 82 84 86 87

Conclusiones ............................................................................................................

89

Anexo A ...................................................................................................................... Anexo B ..................................................................................................................... Anexo C .....................................................................................................................

91 93 106

Referencias bibliogrficas ...................................................................................

109

Resumen.

El desarrollo de software basado en componentes hace necesario contar con herramientas adecuadas; entre ellas se encuentran las herramientas de prueba. Los JavaBeans representan una forma de construir aplicaciones a partir de componentes preexistentes. Por el momento solo hay ayuda para probar aspectos grficos de sus interfaces de usuario, pero no del funcionamiento interno de los beans. Este trabajo presenta una herramienta de prueba de componentes de software construidas bajo el modelo de JavaBeans. El objetivo de la herramienta es proveer al usuario de directrices que le permitan realizar las tareas de seleccin y evaluacin de las componentes mediante la generacin y ejecucin automtica de casos de prueba.

1

Abstract.

Component-based software development makes necessary to have adequate tools; some of them are testing tools. JavaBeans are a way to build applications based in preexistent components. At present testing of interfaces graphical aspects is available, but testing beans internal behavior is not. This work presents a testing tool for software components using the JavaBeans model. Testing tools objective is to offer guides to users on components selection and evaluation through automatic execution and generation of test cases.

2

Introduccin.

Actualmente el reuso de elementos preexistentes es una prctica comn en la actividad de desarrollo de software. Situaciones como la competencia en el mercado para generar nuevos productos o actualizar versiones, han propiciado que m uchos desarrolladores busquen nuevas opciones para generar software en tiempos muy cortos. Incluso, en ambientes de desarrollo no comercial, la actividad del reuso tambin se lleva a cabo; un simple ejemplo es la inclusin de bibliotecas o clases en los programas de un estudiante, con el fin de reutilizar funciones o mtodos ya implementados.

La creacin de nuevas metodologas de desarrollo, cuyas caractersticas han permitido alcanzar en diversos grados la rpida construccin de programas, han considerado al reuso como una actividad bsica, contribuyendo as a que esta se convierta en una alternativa atractiva en la construccin de software. El desarrollo orientado a objetos y el desarrollo basado en componentes, son ejemplos significativos de lo planteado anteriormente. A pesar de la aceptacin alcanzada por estos enfoques, una de las ms importantes limitaciones que surgen, es la falta de garantas que se tienen de que el o los elementos de software que se estn reusando funcionen correctamente en todas las ocasiones, situacin que influye

considerablemente en la calidad de los productos que se desarrollan.

Java Beans, actualmente es uno de los modelos de desarrollo basados en componentes con gran aceptacin, factores como la independencia del sistema operativo, con lo que se pretende eliminar los problemas de plataforma y software, interoperabilidad y capacidad de trabajar en ambientes distribuidos, contribuyen a que el nmero de personas que utilizan este modelo este creciendo notablemente. A pesar de esto, el rea de pruebas es poco robusta.

Definitivamente, la prueba de software es una actividad que de una u otra manera es llevada a cabo en algn momento al menos por su desarrollador original. Para ello este puede planear y realizar un proceso de prueba enfocado a un ambiente en el que espera operar su producto. Aunque esto es aceptable, puede no ser suficiente. Muchas veces el ambiente de operacin pensado por el desarrollador puede diferir del ambiente que se presenta para la

3

persona que utiliza finalmente dicho elemento de software, por lo que en la prueba desarrollada se pueden haber ignorado algunas situaciones. As mismo, cuando una persona distinta al desarrollador desea probar un elemento que est reusando, el hecho de ser un elemento reutilizable, de los que generalmente no se tiene mucha informacin, dificulta esta actividad. En el caso de los componentes, que normalmente se ofrecen como productos terminados, no se dispone del cdigo fuente, por lo que es difcil inspeccionar completamente su estructura interna. Este, adems de otros factores propios del modelo de desarrollo impiden que un proceso de prueba pueda llevarse a cabo fcil y eficientemente.

Actualmente son pocas las herramientas que permiten evaluar elementos preexistentes. Cuando alguien requiere integrar un elemento de software para construir una aplicacin o simplemente para utilizarla de forma aislada, la evaluacin que se realiza radica en la mayora de los casos en una prueba manual, que en el peor de los casos no es nada sistematizada ni fundamentada. Si el usuario requiriera realizar una prueba ms exhaustiva, esta prueba seria ms amplia y formal, pero en raras ocasiones automatizada, por lo que para llevarla acabo se requiere una cantidad de tiempo considerable.

Tomado como temas centrales el desarrollo basado en componentes y la prueba de software, el propsito de este trabajo es presentar una alternativa para la prueba de componentes. Esto se llevar a cabo mediante la implementacin de una herramienta que permita realizar pruebas a componentes desarrollados bajo el modelo propuesto por Sun Microsystems, Java Beans.

Haciendo uso de las funcionalidades que ofrecer esta herramienta, se podrn realizar de forma automtica la generacin y ejecucin de casos de prueba, de modo que con los resultados obtenidos en esta ltima actividad, el usuario de los componentes pueda tener algunas directrices que le permitan realizar con mayor facilidad las tareas de seleccin y evaluacin de las mismas.

4

El tipo de prueba que realizar la herramienta es a nivel de unidad, utilizndose para ello tcnicas de prueba funcional. As mismo, los servicios que ofrecer la herramienta

estarn orientados a los usuarios de los componentes, ms que a los desarrolladores originales.

Con el propsito de describir el trabajo que se realizar para la creacin de la herramienta, este trabajo se organiza fundamentalmente en dos partes, en la primera que comprende los captulos 1 y 2, se presenta de acuerdo a una revisin bibliogrfica los temas Software B asado en Componentes y Mtodos de Prueba de software respectivamente, en los cuales se pretende proporcionar al lector un marco terico de referencia con respecto al diseo de aplicacin a desarrollar. La segunda parte que comprende de los captulos 3 al 5, se concentra en la descripcin de la herramienta implementada. Para ello en el captulo 3 Descripcin del Diseo, como su nombre lo indica, se presentarn las consideraciones con respecto al diseo de la herramienta de prueba. En el capitulo 4 Descripcin de la Arquitectura e Implementacin, se describen detalles referente a la implementacin. En el quinto y ltimo capitulo Pruebas de Funcionamiento, se presentan algunas de las pruebas realizadas con el propsito de verificar el adecuado funcionamiento de la aplicacin.

Al final de este documento, se encuentran secciones que contienen las conclusiones, obtenidas como producto de este trabajo, una seccin en donde se citan las referencias bibliogrficas, y anexos.

El Anexo A que contiene informacin referente a los valores establecidos para la generacin de casos de prueba. El anexo B contiene el manual del usuario de la herramienta. El anexo C presenta detalles de la notacin utilizada para la descripcin del diseo.

5

Captulo 1 Software Basado en Componentes.

Como respuesta a la necesidad de buscar alternativas que permitan hacer ms fciles las tareas de desarrollo e integracin de software, uno de los ms recientes modelos de desarrollo es el de componentes. Aspectos como el reuso y la interoperabilidad, muy importantes en la actualidad, son caractersticos de este enfoque. Puede visualizarse como un modelo de desarrollo bastante prometedor.

Con el propsito de ofrecer informacin que permita al lector conocer sobre el desarrollo a partir de componentes, en este captulo se presenta una descripcin del modelo con base en sus principales caractersticas. As mismo, al trmino de esta descripcin, se presentarn tres modelos muy populares que actualmente se ofrecen en el mercado para construir software bajo esta modalidad: COM+/DCOM, CORBA, y Java Beans.

1.1

El concepto de componente. La palabra componente nos hace pensar en una unidad o elemento con propsito bien

definido que, trabajando en conjunto con otras, puede ofrecer alguna funcionalidad compleja. Transportando este concepto al contexto de ingeniera de software, especficamente de desarrollo basado en componentes, un componente es la pieza elemental de este enfoque de desarrollo, de esta forma, a partir de componentes existentes pueden llegarse a construir aplicaciones completas.

En trminos formales, y de acuerdo con [MAR96], un componente es una pieza de software que cumple con dos caractersticas: no depende de la aplicacin que la utiliza y, se puede emplear en diversas aplicaciones.

Segn se cita [SZY97], l s asistentes a la ECOOP96 definen a un componente como o una unidad de composicin con interfaces definidas contractualmente y dependencias

6

contextuales

explcitas

solamente.

Un

componente

de

software

puede

desplegarse

independientemente y estar sujeta a composicin por terceros. El anlisis de las ideas presentadas en estas definiciones y, de acuerdo con lo que plantea [FER99], se pueden identificar caractersticas en comn:

- Orientacin al reuso, lo que nos hace pensar en algo que se puede tomar y utilizar ms de una vez.

- Interoperabilidad, el componente no puede solo usarse de forma aislada, sino que puede integrarse a otras y trabajar conjuntamente.

- Funcin significativa, el componente tiene una funcin bien definida, identificable y diferenciable.

- Encapsulamiento, generalmente los componentes ocultan detalles acerca de su implementacin.

Una definicin ms orientada a un enfoque de desarrollo, es la presentada en [DSO99] en la que un componente se define como un paquete coherente de una implementacin de software que puede ser independientemente desarrollado y entregado, tiene interfaces explcitas y bien especificadas para informar los servicios que provee y espera de otros, puede estar constituido por otros componentes, quizs mediante la especializacin de algunas de sus propiedades, sin que esto signifique modificar los componentes mismos.

Tomando esta ltima definicin se pueden enriquecer algunas de las caractersticas presentadas antes considerando tambin:

- Una lista de interfaces provedas y requeridas, las cuales representan mecanismos indispensables para la interoperabilidad de los componentes.

7

- Una especificacin externa, medio que permite principalmente identificar la funcin del componente.

- El cdigo de validacin, necesario para verificar, cuando se utilizan mas de un componente, si se conectaron correctamente.

- El cdigo ejecutable del componente.

1.2

El concepto de software basado en componentes. El concepto de software basado en componentes considera a todas aquellas

aplicaciones que se construyen haciendo uso de componentes de software.

En la definicin presentada para este concepto por [DSO99], se habla de un enfoque de desarrollo de software en el cual todos los artefactos -desde cdigo ejecutable para la especificacin de la interfaz, arquitecturas, modelos de negocios, escalar aplicaciones completas y descomposicin de sistemas en partes- pueden ser construidos por ensamble, adaptacin y conexin de componentes existentes dentro de una variedad de configuraciones.

Es claro que las caractersticas descritas para este enfoque de desarrollo suenan bastante atractivas; de hecho muchos autores resaltan algunas otras como el reuso de implementaciones e interfaces, la facilidad de mantenimiento y actualizacin de aplicaciones o la posibilidad de desarrollo en paralelo de diferentes partes de un sistema. Ante este panorama, es importante hacer mencin de que al ser esta un rea de investigacin

relativamente joven, existen muchos aspectos que an no son lo suficientemente robustos. Carencias como el soporte disponible, la seleccin de componentes, el manejo de excepciones o bien la prueba de integracin de componentes son situaciones que se destacan en [FER99].

8

1.3

Objetos y componentes. Existen algunos aspectos comunes entre los objetos y los componentes que pueden

hacer que estos se entiendan como conceptos equivalentes. Aunque hay similitudes, existen marcadas diferencias que permiten entenderlos como entidades diferentes, aunque no por ello excluyentes una de otra.

Segn [DSO99] los componentes son artefactos de software que representan el trabajo realizado por los desarrolladores. Por otra parte, un objeto se concibe como una instancia identificable creada en el sistema en ejecucin, el cual es parte de un componente. Esta idea permite comprender que un componente puede contener uno o ms objetos. En trminos reales, un componente se manifiesta frecuentemente como una coleccin de objetos.

Finalmente, con el propsito de diferenciar a los componentes de los objetos, a continuacin se presentan algunas caractersticas que se destacan en [FER99] y [DSO99]:

-

Los componentes tienen persistencia, los objetos solo utilizan memoria.

-

Los componentes utilizan otras formas de comunicacin como eventos, en lugar de limitarse al uso de mensajes como los objetos.

-

La granularidad de los componentes es mayor que la de los objetos, un componente puede presentarse como varios objetos de diferentes clases.

-

El paquete que contiene a el componente, incluye la especificacin de las interfaces provedas y requeridas, mientras que la en los objetos estas especificaciones se concentran en las operaciones provedas.

9

1.4

Modelos para el desarrollo.

La metodologa de desarrollo basada en componentes, ha adquirido el respaldo de compaas importantes como Microsoft y Sun que han propuesto sus propios modelos de desarrollo. En las siguientes secciones se describen tres de los ms populares actualmente, COM+/DCOM, CORBA y Java Beans.

1.4.1 COM y DCOM. El Component Object Model (COM), es la propuesta de Microsoft en materia de componentes, [MIC00]. Aunque inicialmente fue creado para resolver problemas en la construccin de documentos con OLE para Windows 3.1, este modelo ha sido enriquecido con el propsito de permitir la construccin de aplicaciones a partir de componentes.

COM es esencialmente un esquema de integracin, de modo que los componentes que se construyen para trabajar bajo este modelo, deben describir su comportamiento bajo las consideraciones de este esquema, el cual es popularmente conocido como estndar binario. Este estndar permite que las interfaces de los componentes se presenten a los clientes como un conjunto de apuntadores a tablas en memoria, llamadas tablas virtuales de funciones o vtables. El llamado de funciones entre componentes se realiza utilizando estos apuntadores, ocultndose as detalles de implementacin, lo cual permite que componentes que estn escritos en diferentes lenguajes de programacin de los que se pueden ncluir a C++, Small i Talk, Ada, VisualBasic, Delphi o Power Builder, puedan comunicarse.

Dadas las caractersticas de las vtables, las interfaces no pueden definirse utilizando herencia mltiple, porque se deben considerar la posibilidad de tener varias v tables y ms de un apuntador por interface.

Las interfaces COM se definen utilizando un lenguaje especial denominado IDL. La compilacin de estas interfaces, produce una especie de libreras que contienen informacin sobre los metadescriptores del objeto, de sus interfaces, de las estructuras definidas por el

10

usuario y de los elementos referidos por el componente, as como un mapa de memoria para las operaciones pblicas.

Distributed COM, mejor conocido como DCOM, es una extensin de COM que se implementa como una respuesta a la necesidad de aplicaciones distribuidas, proporcionando capacidades para el trabajo con componentes que residen en diferentes computadoras. DCOM utiliza como mecanismo de comunicacin los llamados a procedimientos remotos (RPC), los cuales son transparentes para el cliente.

Tanto COM como DCOM son modelos que inicialmente fueron implementados para trabajar bajo ambientes Windows y Windows NT, sin embargo actualmente existen versiones para operar con MacOS y UNIX. Como se mencion i icialmente el funcionamiento de COM n y DCOM, se basa estrictamente en el estndar binario, por lo que los componentes construidos para estos modelos no son del todo independientes de la plataforma, en caso de migrar a otros entornos, para poder utilizare os componentes necesitan ser recompilados para la plataforma l en que se van a utilizar o bien, disponer el interprete del formato binario correspondiente.

1.4.2 CORBA. CORBA, Common Object Request Broker Architecture, es una infraestructura abierta para el manejo de objetos distribuidos que esta siendo estandarizada por el Object Management Group (OMG), [ORG00]. En CORBA, un objeto se considera como una instancia de una clase que encapsula operaciones, atributos y excepciones.

CORBA permite que los objetos puedan comunicarse con otros sin necesidad de preocuparse por donde estn localizados o por quien han sido diseados. Para esto, se han considerado algunos elementos importantes como: un lenguaje de definicin de interface (IDL) y una API que provee al programador la interaccin cliente-servidor entre componentes con la implementacin especifica de un Object Request Broker (ORB), el cual es una especie de infraestructura en CORBA que permite que los objetos puedan comunicarse.

11

Un componente expone un conjunto de interfaces, implementadas utilizando un lenguaje de definicin llamado OMG Interface Definition Language (OMG IDL), mismas que definen las operaciones de los objetos. Actualmente existen estndares para el mapeo de un IDL a lenguajes de programacin como C, C++, Java, Smalltalk, o Ada.

Una vez que la interfaz se ha definido, se procede a generar dos archivos especiales, un archivo denominado stub para el cliente y, un archivo skeleton para el servidor, estos archivos son una especie de pegamento entre el cliente y el servidor con el ORB que le permiten acceder a sus interfaces.

El Object Request Broker (ORB),

provee un mecanismo para la comunicacin

transparente entre clientes y objetos, actuando como un intermediario para realizar la comunicacin ya sea local o remota entre componentes. El ORB simplifica la programacin distribuida desligando del cliente detalles sobre la invocacin de los mtodos. Para ello,

intercepta la solicitud, encuentra el objeto que corresponde a dicha solicitud, i voca al mtodo n correspondiente y regresa el resultado. Al delegarse al ORB todas estas responsabilidades, el cliente no tiene que preocuparse por detalles sobre la localizacin del objeto, sobre el lenguaje de programacin en el cual el objeto ha sido implementado, del sistema operativo, u otros aspectos propios del sistema.

1.4.3 JavaBeans. Actualmente uno de los modelos de desarrollo de software basado en componentes con mayor aceptacin, es el propuesto por Sun Microsystems [SUN97], conocido como Java Beans.

Java Beans es una API implementada para la construccin y uso de componentes escritos en Java, los cuales son comnmente llamados Beans. Esta API es proporcionada por SUN como una herramienta visual que permite la carga, utilizacin, modificacin, as como tambin interconexin de Beans, con el propsito de construir nuevos Beans, applets o bien aplicaciones completas.

12

Retomando la idea de [VAN98] , una forma til para describir a un Bean es comparndolo con una especie de caja negra; una unidad de la cual se conoce su funcionalidad pero no su implementacin o estructura interna. Siendo un Bean un elemento de software sobre el cual solo se conoce su funcin, es preciso contar con algn mecanismo que permita la comunicacin con l. En este modelo, ese mecanismo de comunicacin consiste en una interfaz, a partir de la cual, se puede acceder a los elementos principales de un Bean: sus mtodos, propiedades y eventos.

En Java Beans, los mtodos implementados en un Bean, especialmente los definidos con el prefijo set o get, son un medio para interactuar con el. Los mtodos pueden entenderse como servicios con efectos especficos que el usuario puede invocar en algn momento.

Las propiedades son conceptualmente equivalentes a lo que en el software tradicional se conocen como atributos, estos consisten en conjunto de caractersticas que un usuario puede leer o modificar haciendo uso de los mtodos de acceso.

Los eventos son utilizados por el Bean como un medio de comunicacin con otros Beans. Un evento se presenta como un cambio de estado que el componente puede notificar a su ambiente. El evento lleva informacin de quin lo genera, as mismo puede llevar datos y an objetos que migran de una clase a otra.

Puesto que existen otros modelos de desarrollo basados en componentes, en Java Beans se han establecido algunas capacidades con el propsito de distinguirlo de otros. La caracterstica ms importante, es por supuesto, que el componente este escrito en Java, adems de soportar las siguientes capacidades:

a) Introspeccin, mecanismo mediante el cual se pueden descubrir las propiedades, mtodos y eventos que un Bean contiene.

13

b) Soporte a propiedades, la posibilidad de conocer las caractersticas de los atributos y la capacidad de poder ser modificados a tiempo de diseo.

c) Soporte a eventos, actividades como generacin, escucha o respuesta a eventos con el propsito de comunicarse con otros Beans.

d) Persistencia, capacidad para salvar y recuperar las especializaciones realizadas a un Bean.

El modelo propuesto por Sun Microsystems, permite interrelacionar los componentes construidos bajo sus propias consideraciones con componentes de otros lenguajes y modelos, destacando principalmente la compatibilidad con el estndar de CORBA.

Aunque los Beans han sido pensados para ser simples procesos locales, recientemente se ha propuesto una alternativa para trabajar con componentes remotos diseadas para correr en un servidor y ser invocados por clientes, esta propuesta es conocida como Server Beans o Enterprise Java Beans (EJB) [SUN00]. Los EJB cuentan con mecanismos que les permiten ofrecer nuevos y mejores servicios entre los que destacan los de seguridad, manejo de transacciones, concurrencia y persistencia.

1.4.3.1 El Bean Development Kit. El Bean Development Kit (BDK), es un ambiente visual que permite construir y utilizar Beans. Con el propsito de realizar estas tareas, el BDK implementa tres elementos principales: el BeanBox, el ToolBox, y el PropertySheet. La apariencia de estos elementos, despus de haberse seleccionado un Bean, se presenta en la Figura 1.1.

El BeanBox, que es el lugar donde se visualiza y modelan algunos de los aspectos involucrados con el comportamiento de un Bean, en este espacio el usuario puede conectar Beans y definir como quiere que se realicen las interacciones entre ellos. Para esto, el

14

BeanBox ofrece al usuario un conjunto de menes, que incluyen acciones como salvar el contenido actual del BeanBox -incluyendo aspectos como tamao, posicin, estado-, generacin de applets a partir del contenido del BeanBox, cargar archivos JAR, realizar un reporte de introspeccin al Bean, listar los mtodos que lanzan eventos, etc.

Figura 1.1 Apariencia del BDK.

En el BeanBox se presenta al usuario una vista, en tiempo de diseo, de lo que ocurrira cuando la aplicacin se ejecute fuera de este ambiente de trabajo.

Ya se ha mencionado que un componente puede estar conformado por varias clases, las cuales en este modelo deben estar contenidas en un archivo JAR. Un archivo JAR es muy similar a un archivo ZIP, es un archivo que comprime y almacena varios archivos. De hecho, la principal diferencia entre un archivo ZIP y un JAR, es que este ltimo requiere de un archivo especial denominado MANIFEST.MF, que contiene la descripcin de lo que contiene el JAR, dicho de otro modo, el archivo MANIFEST.MF almacena los meta datos del archivo JAR.

15

El ToolBox es un contenedor de Beans, el cual utiliza los archivos JAR localizados en un directorio predefinido dentro del ambiente de referencia, beans/jars. Los mecanismos implementados en el ToolBox examinan el contenido de estos archivos, de forma que puedan mostrarse los Beans contenidos en l y as, permitir al usuario seleccionar y posteriormente colocar los Beans dentro del BeanBox para su manipulacin.

Al iniciarse BeanBox, este carga de forma automtica todos los Beans contenidos en los archivos JAR, sin embargo se pueden cargar JAR de forma manual mediante el men File|LoadJar del BeanBox.

Ya se ha mencionado que la apariencia de un Bean puede cambiarse mediante la manipulacin de sus propiedades, mtodos y eventos; el PropertySheet muestra y permite modificar los valores de las propiedades de un Bean. Si se selecciona un Bean en el BeanBox, en el PropertySheet se despliegan los nombres de cada una de las propiedades y de sus valores actuales. Estos valores pueden ser editados por el usuario modificndose as la apariencia y comportamiento del Bean, aspectos que en muchos casos pueden ser apreciables desde el BeanBox.

16

Captulo 2 Revisin Tcnica sobre Prueba de Software.Cuando se desarrolla software, una de las actividades asociadas a este proceso es la prueba; de hecho, se ha establecido formalmente que la prueba es una actividad fundamental dentro de cada una de las etapas del proceso de desarrollo de software. La prueba es indispensable, puesto que a partir de ella se puede determinar la calidad de los productos implementados; a pesar de esto, no es difcil percibir como su importancia se ha subestimado y en ocasiones hasta ignorado.

Desde hace ya mucho tiempo, la prueba ha sido un tema muy importante en la ingeniera de software, a partir de cual se han generado un gran nmero de trabajos. En este captulo se presenta una revisin tcnica sobre la prueba de software, abordndose fundamentalmente los enfoques de prueba propuestos para probar software construido bajo un enfoque funcional, orientado a objetos y basado en componentes.

2.1

La prueba de software.

Para muchas de las actividades que lleva a cabo el ser humano, la prueba es una actividad necesaria que permite determinar la calidad de estas. Hoy por ejemplo, se realizan pruebas para determinar resistencia de determinados materiales, para determinar la vida til de diversas maquinarias y equipos, o bien para verificar que ciertas tareas se realicen de forma correcta.

Definitivamente la prueba es una actividad fundamental en muchos procesos de desarrollo, incluyendo el del software. De manera general, se puede decir que la prueba de software permite al desarrollador determinar si el producto generado satisface las especificaciones establecidas. As mismo, una prueba de software permite detectar la presencia de errores que pudieran generar salidas o comportamientos inapropiados durante su ejecucin.

17

De acuerdo a la IEEE [IEEE90] el concepto de prueba (testing) se define como:

Una actividad en la cual un sistema o componente es ejecutado bajo condiciones especificas, se observan o almacenan los resultados y se realiza una evaluacin de algn aspecto del sistema o componente.

Cuando se habla de condiciones especificas en la definicin anterior, se puede suponer la presencia de una especie de ambiente de operacin de la prueba, para el cual deben existir determinados valores para las entradas y las salidas, as como tambin ciertas condiciones que delimitan a dicho ambiente de operacin. Formalmente esto es conocido como caso de prueba.

La IEEE [IEEE90] define un caso de prueba como:

Un conjunto de entradas, condiciones de ejecucin y resultados esperados diseados para un objetivo particular.

A partir de las definiciones anteriores y retomando las ideas presentadas en [WOH98] y [FER99] , en un proceso de prueba de software, se pueden identificar las siguientes acciones:

a) preparar una serie de casos de prueba, b) llevar a cabo dichos casos de prueba, c) decidir cuando suspender la prueba. d) evaluar los resultados generados por la prueba, e) emitir un criterio de evaluacin.

De lo anteriormente presentado surgen cuestionamientos como: cmo seleccionar casos de prueba representativos?, cuntas pruebas realizar? o bien cmo decidir si es o no de calidad el producto evaluado?, los cuales permiten entender que cada una de estas acciones

18

requiere especial atencin. Por fortuna, actualmente existe una base terica que permite guiar la puesta en marcha de estas actividades.

Trminos como falla, equivocacin y error, pueden considerarse como sinnimos, sin embargo, dentro del contexto de prueba de software no es prudente realizar esta suposicin. Con el propsito evitar confusiones y presentar al lector conceptos bsicos en materia de pruebas, se presentan estas definiciones tomadas de [IEEE90] :

a) Equivocacin (mistake): Accin del ser humano que produce un resultado incorrecto.

b) Defecto o falta (fault): Un paso, proceso o definicin de dato incorrecto en un programa de computadora. El resultado de una equivocacin.

c) Falla (failure): Resultado incorrecto. El resultado de una falla.

d) Error (error): Magnitud por la que el resultado es incorrecto.

2.2

Objetivos de la prueba de software.

Un buen prembulo, antes de establecer los objetivos de la prueba de software es recordar la afirmacin realizada por Dijkstra en los aos 70 y citada en [PRE98], en donde se plantea que el hecho de realizar una prueba no garantiza la ausencia de defectos, sino solamente se demuestra la existencia de stos.

19

Como ya se mencion en la seccin anterior, la prueba de software se realiza con el propsito de encontrar algo que difiera a las especificaciones planteadas para el producto o bien, para detectar la presencia de situaciones que pudieran generar resultados inapropiados.

Aunque a grandes rasgos estas razones pueden orientar el sentido de una prueba, en [MYE79] se presentan algunas normas que pueden servir como objetivos:

a) La prueba es un proceso de ejecucin de un programa con la intencin de descubrir un error.

b) Un buen caso de prueba es aquel que tiene alta probabilidad de mostrar un error no descubierto hasta entonces.

c) Una prueba tiene xito si se descubre un error.

2.3

Mtodos de prueba de software.

Desde hace ya algunos aos, han surgido y evolucionado una variedad de mtodos para realizar pruebas de software. Las alternativas ms significativas en este contexto son las pruebas de caja blanca y las pruebas de caja negra; las primeras, pruebas orientadas a la estructura y las segundas al comportamiento del software. A continuacin se hace una descripcin de algunas de las propuestas que plantean cada una de estas alternativas, tomando material de las referencias [JOR95], [PRE98] y [KIT96].

2.3.1 Pruebas de caja blanca.

La pruebas de caja blanca enfocan su atencin a los detalles procedimentales del software, por ello la implementacin de estas pruebas depende fuertemente de la disponibilidad de cdigo fuente. Este tipo de pruebas, permiten generar casos para ejercitar y

20

validar los caminos de cada mdulo, las condiciones lgicas, los bucles y sus lmites, as como tambin para las estructuras de datos. Las pruebas de caja blanca tambin son conocidas como pruebas de caja de cristal o pruebas estructurales.

Algunas de las pruebas ms significativas dentro de este enfoque son:

- Prueba de caminos. En este tipo de prueba se realiza un anlisis sobre una representacin grfica de un programa denominada grafo de control. En este grafo, los nodos representan bloques de instrucciones de un programa y los flujos de ejecucin para dichas instrucciones se representan por medio de aristas. A partir de este grafo, se puede identificar un conjunto bsico de caminos de ejecucin, sobre el cual se pueden realizar pruebas con el propsito de ejercitar el flujo de ejecucin de los caminos en una unidad.

- Prueba de condiciones. Basndose de igual forma en un grafo de control, pueden generarse casos de prueba para elementos individuales de expresiones lgicas. D esta forma se pretende probar e cada condicin con todas sus posibles alternativas.

- Prueba de ciclos. A partir del grafo de control, pueden generarse casos de prueba para las iteraciones definidas en los programas con el propsito de verificar si se realizan de forma correcta.

- Prueba de definicin de datos. Estas pruebas son realizadas con el objetivo de encontrar posibles contradicciones o redundancias en la definicin de los datos utilizados en el software. Para ello se realiza un anlisis del comportamiento de cada uno de los datos o cada una de los flujos de ejecucin.

21

2.3.2 Pruebas de caja negra.

Este tipo de pruebas, conocidas tambin como pruebas funcionales o pruebas de comportamiento, concentran la atencin en generar casos de prueba que permitan ejercitar los requisitos funcionales de un programa. A diferencia de las pruebas de caja blanca, que se basan en la lgica interna del software, este tipo de pruebas se concentran en su funcionalidad, por lo que mucho del trabajo se realiza interactuando con la interfaz del software. Los casos de prueba generados en este enfoque, se disean a partir de valores entrada y salida. De esta forma, se puede determinar la validez de una salida para un conjunto de entradas proporcionadas.

La aplicacin de pruebas de caja negra permiten detectar errores como funciones incorrectas o ausentes, errores en estructuras de datos, errores de rendimiento, as como errores de inicializacin y terminacin.

Estas son algunas de las pruebas ms conocidas en este contexto:

- Particin equivalente. La idea de esta tcnica, es en dividir los valores vlidos y no vlidos para entradas y salidas en un nmero reducido de particiones de forma que, el comportamiento del software sea el mismo para cualquier valor contenido en una particin particular. El propsito principal de una particin es reducir la cantidad de casos de prueba generados en el proceso.

- Anlisis de los valores lmite. La generacin de casos de prueba en esta tcnica, se enfoca en los valores limites, esto bajo la consideracin de que existe una tendencia a fallar precisamente cuando el software trabaja con valores extremos de la variable de entrada. Generalmente los valores establecidos para generar los casos de prueba son el mnimo, valores un poco arriba del mnimo, valor mximo y valores un poco arriba del mximo.

22

- Pruebas segn la experiencia (error guessing). Este tipo de prueba la generacin de casos se realiza a partir de la intuicin y la experiencia. La idea bsica es redactar una lista de las posibles fallas o de las posibles situaciones en las cuales suele ocurrir algn problema y as desarrollar casos de prueba basados en la informacin contenida en estas listas.

- Tablas de decisin. Este tipo de prueba permite describir el comportamiento de un programa a partir de un conjunto de acciones que este realiza cuando se opera bajo determinadas condiciones. En este enfoque, las condiciones pueden ser interpretadas como entradas de un programa y las acciones como las salidas producidas. Para ello se pueden utilizar conectores lgicos y (and), o (or) y no (not). Al involucrar aspectos de lgica, se dice que este tipo de prueba se hace ms rigurosa, que permite adems transformar una especificacin en lenguaje natural en una especificacin ms formal.

2.4

Niveles de prueba del software.

Un nivel de prueba permite especificar el alcance de la prueba de software que se realiza, se pueden identificar principalmente dos niveles:

a)

Bajo nivel. En este nivel estn consideradas todas aquellas pruebas que se realizan a componentes

individuales de un programa. Las pruebas que se pueden realizar en este nivel son:

Pruebas de unidad. Como su nombre lo indica, este tipo de prueba se aplica a elementos de software individualmente, excluyendo todos aquellos casos en los que se considere la interaccin con otras unidades. El propsito fundamental de una prueba de unidad es

23

descubrir diferencias entre la especificacin del modulo de la interfaz y el comportamiento efectivo.

Pruebas de integracin Las pruebas de integracin se realizan con el propsito de ejercitar la arquitectura de un sistema. Una vez que ya se han probado que las unidades funcionan de forma correcta de forma aislada, se procede a probar cmo funcionan al integrarlas con otras de forma que se llegue a probar el comportamiento de un sistema final. La forma en que se pude organizar la integracin de las unidades para la prueba puede realizarse siguiendo enfoques como el ascendente, sandwich. descendente, big bang, o

b)

Alto nivel. En ste nivel las pruebas se orientan a un producto completo; para ello se proponen las

siguientes alternativas:

Pruebas de sistema Este tipo de pruebas permiten probar el sistema como un todo as como tambin aspectos relacionados con la integracin del producto a otros sistemas.

Pruebas de usabilidad. El diseo de pruebas de usabilidad, requiere considerar a los usuarios que trabajan con el producto, con el propsito de observar sus respuestas hacia ste. De sta forma se pueden observar discrepancias existentes entre las interfaces

implementadas y los requerimientos de los estilos de trabajo de los usuarios finales.

Pruebas de funcin. Este tipo de pruebas tiene como objetivo detectar inconsistencias entre la especificacin funcional de un programa y su comportamiento actual.

24

Pruebas de aceptacin. Realizando estas pruebas se puede comparar el producto final con las necesidades finales de los los usuarios.

Pruebas de regresin. Las pruebas de regresin son recomendables cuando partes del software se modifican, ya que permiten verificar que los cambios realizados no generan comportamientos no deseados.

2.5

Prueba de software para objetos.

Como consecuencia de las facilidades y beneficios que ofrece, actualmente una de las nuevas alternativas para desarrollo de software con mayor aceptacin es la metodologa orientada a objetos. Si bien es cierto que este nuevo enfoque ha sido adoptado por muchos, es tambin cierto que estas personas han tenido que enfrentarse y adaptarse a cambios bastante significativos. Conceptos como objeto, herencia y encapsulacin marcan una nueva perspectiva que contrasta con los modelos de desarrollo anteriormente utilizados.

Esta nueva percepcin ha impedido que reas de vital importancia, como la prueba de software, no hayan alcanzado e desarrollo y la robustez que requieren. Es importante destacar l que mucho del software que se est fabricando hoy es orientado a objetos, por lo resulta evidente la necesidad de contar con herramientas o al menos guas de accin para realizar esta actividad.

Esta falta de trabajos quiz sea debida a la suposicin y afirmacin inicial de algunos autores de que el software orientado a objetos, al tener como una caracterstica esencial el reuso, est propenso a presentar menos errores que el software construido usando las metodologas tradicionales. Lamentablemente las experiencias obtenidas han demostrado que no es as.

25

2.5.1 Generalidades del modelo de desarrollo orientado a objetos.

En cierto grado algunos de los conceptos de la orientacin a objetos han estado presentes en los lenguajes de programacin que se han utilizado; sin embargo la programacin orientada a objetos aparece formalmente durante la dcada de los 80, como una alternativa de desarrollo de software que ofrece caractersticas muy atractivas: mejor modularidad en los programas, mayor flexibilidad y una de las ms significativas el reuso, caracterstica nada despreciable en ambientes de trabajo donde se requiere construir software en tiempos muy cortos. De acuerdo con [PER90], la programacin orientada a objetos puede definirse como la descripcin de tareas en trminos de los objetos que la misma tarea envuelve, as como de las propiedades de dichos objetos.

A pesar de lo simple de la definicin, se puede apreciar que un elemento muy representativo en este modelo es el objeto. Profundizando sobre este tema, es posible decir que la programacin orientada a objetos gira en torno a dos conceptos: el objeto y la clase.

En los lenguajes de programacin imperativos, los elementos ms significativos son las estructuras de datos y los procedimientos, los cuales aparecen en forma desligada. En el modelo orientado a objetos, existe una unidad que conjunta estos elementos, esta unidad es el objeto. La definicin formal de un objeto esta contenida en una clase a la que pertenece. Esta definicin contiene las caractersticas del objeto, las cuales se modelan en trminos los atributos, datos que el objeto utiliza, y los mtodos que son las funciones que manipulan a estos datos.

A continuacin se presentan descripciones mas amplias de clase y objeto, que permitirn tener una mejor comprensin de lo mencionado anteriormente:

26

Segn [KIR94], un objeto tiene un estado y un comportamiento. El estado del objeto lo determina un conjunto de atributos. El comportamiento de un objeto est definido por el conjunto de mtodos del objeto. Una clase describe el comportamiento comn de un grupo nico de objetos. Describe todos los mtodos y los atributos de esos objetos. Los objetos son creados mediante la instanciacin de clases.

Para [PER90], un objeto es un entidad instanciada la cual tiene: 1. un conjunto de operaciones a las cuales responde, 2. un estado el cual es afectado por un subconjunto de operaciones, 3. la habilidad de enviar mensajes a otros objetos para invocar operaciones. Una clase especifica las propiedades de un objetos y contiene: 1. una interfaz la cual detalla como se accede a las propiedades pblicas de la clase, 2. un cuerpo de cdigo que implementa las operaciones definidas en la interfaz, y 3. variables de instancia, las cuales implementan el estado del objeto.

Adems de clase y objeto, existen otros conceptos relacionados con esta forma de programacin; encapsulacin, polimorfismo y herencia, son algunos de los ms destacables. En la siguiente seccin se abordan cada uno de ellos, dentro del contexto de prueba de software.

2.5.2 Aspectos a considerar en la prueba de software orientado a objetos.

Al igual que el software construido utilizando otros enfoques de desarrollo, todo producto construido a partir del modelo orientado a objetos requiere ser sometido a pruebas con el propsito de garantizar su calidad. En trminos generales, se puede decir que los dos enfoques mas representativos en materia de pruebas, de caja blanca y de caja negra, son aplicables al software orientado a objetos en cierta medida. Sin embargo como se menciona en

27

[FER99],

existen algunas caractersticas del software orientado a objetos que generan

problemas adicionales no cubiertos por las tcnicas tradicionales de prueba.

Existe una referencia comn en [BIN95-A], [PER90] o [FER99], acerca de que la unidad bsica para la prueba de software orientado a objetos es la clase. A pesar de ello, cuando se prueba al software orientado a objetos, no es posible realizar una prueba para una clase por s misma, sino que hay que realizarla para una instancia de sta, es decir para un objeto.

Una caracterstica importante del enfoque orientado a objetos es la encapsulacin. Un objeto encapsula su estado y sus funciones asociadas. La abstraccin, concepto que define la capacidad de solo destacar las caractersticas esenciales de un objeto de tal forma que se puede separar su comportamiento esencial de su implementacin, va estrechamente ligada con la encapsulacin. Indudablemente la posibilidad de poder encerrar dentro de un contenedor fsico o lgico elementos como arreglos, registros o incluso objetos parece ser muy atractiva para ciertas actividades, sin embargo en el contexto de prueba esto no es realmente una ventaja.

Como se cita en [BAS99], el ocultar todos los detalles del objeto que no contribuyen a sus caractersticas esenciales, por ejemplo su estructura y la implementacin de sus mtodos, hace que parte de un objeto sea inaccesible para el mundo. Naturalmente, esto obstaculiza la eficiencia de las pruebas, ya que para realizarlas, en algn momento se requiere monitorear el estado de un objeto. Esto es difcil de realizar con caractersticas como la encapsulacin y la abstraccin, pues la dificultad de visualizar el estado interno del objeto impide consultar informacin que podra requerirse para el desarrollo de la prueba. [BIN95-A].

Por otra parte, la herencia es otra de las caractersticas que han venido a facilitar en gran medida el desarrollo de sistemas, la posibilidad de que una clase pueda ser escrita en trminos de variaciones de otras clases es una ventaja significativa. Puede pensarse que esto apoya la prevencin de fallas al construir software. Desgraciadamente, se ha comprobado que. mediante esta prctica, se tienen muchas posibilidades de cometer errores, porque

28

generalmente los elementos heredados son sometidos a algn tipo de

refinamiento o

redefinicin y en algunos casos eliminacin de componentes [FER99]. Cuando un objeto es creado a partir de caractersticas heredadas, se genera un nuevo contexto que puede ser diferente al que pudiera crearse por la clase antecesesora si esta trabajara de manera aislada y, por tanto, presentarse problemas ante situaciones no previstas en el nuevo contexto. Todas estas situaciones hacen que autores como [BIN95-A], afirmen que realizar una prueba a los mtodos heredados debe ser una regla ms que una excepcin.

La herencia en cierta medida trae como consecuencia reuso, lo que genera una interrogante comn con respecto a la formulacin de las pruebas: las subclases de una clase que ya ha sido probada deben de ser probadas nuevamente?. referencias como [PER90], se habla Si la respuesta es s, en

de diferentes niveles de herencia lo que incrementa el

nmero de pruebas a realizar. As mismo, en [BIN95-B] se afirma que el reuso no garantiza que el software est exento de errores, ya que no es posible determinar si un nmero suficiente de rutas y estados hayan sido ejercitados.

Otro aspecto que determina la dificultad de las pruebas que se realizan al software orientado a objetos es el polimorfismo. En [BIN95-A] se explica que c vez que se realiza ada una instancia diferente de un objeto como producto del polimorfismo en los mtodos, se requiere una prueba separada. Realizar una prueba separada para cada una de la formas de un mtodo es una tarea difcil, la complejidad y el tiempo requerido crece considerablemente cuando se tienen que definir todos los posibles errores y obstculos que pueden presentarse.

En los sistemas orientados a objetos, el flujo de control se lleva a cabo mediante el paso de mensajes entre objetos. Cuando un mensaje es enviado de un objeto u otro, la consecuencia es, generalmente, que el objeto receptor ejecute alguna operacin para examinar o alterar su estado. En [PER90] hace hincapi que el paso de mensajes es un punto fundamental al realizar la prueba .

Si bien estos son algunos de los aspectos ms significativos y de referencia comn en revisiones bibliogrficas, de igual forma pueden mencionarse la dependencia de estado, el

29

desarrollo incremental, el manejo de excepciones, las invocaciones implcitas, el cambio de tipo, las peculiaridades del lenguaje o la genericidad, las cuales pueden consultarse con mayor detalle en [FER99].

2.5.3 Mtodos de prueba de software orientado a objetos.

Se ha dicho en secciones anteriores que muchas de las generalidades de los mtodos de prueba tradicionales han sido adaptadas considerando las caractersticas del modelo orientado a objetos, con el propsito de que puedan ser aplicables en este nuevo contexto.

Actualmente, existen muy pocos trabajos producto del estudio de prueba de software orientado a objetos; de hecho, por s mismo, el rea de prueba de software es bastante compleja y dentro de este marco de objetos existe una carencia de mtodos robustos para garantizar la realizacin de las pruebas de forma eficaz. A continuacin se presenta un panorama del estado actual en cuanto a prueba de software orientado a objetos en trminos del nivel de prueba, basado principalmente en [AMB99], [JAC92] y [FER99].

2.5.3.1 Pruebas de unidad.

En el software orientado a objetos

la menor unidad a considerar para realizar una

prueba es la clase. Para [PRE98], la prueba de clases en el mbito de software OO es equivalente a la prueba de unidad realizada al software tradicional. Esta prueba est fundamentalmente dirigida a las operaciones encapsuladas por la clase, as como al estado y comportamiento del objeto que se implementa en ella. Como se explica en [BAS99], el nfasis de la prueba de unidad es verificar que esta pequea unidad trabaje correctamente en forma aislada, antes de proceder a integrarla en el sistema.

Los mtodos contenidos en una clase pueden ser muchos y una operacin en particular de ese conjunto, a consecuencia de la herencia, puede existir como parte de varias clases

30

diferentes. Por lo tanto el significado de prueba de unidad cambia en muchos sentidos y es importante disearla bajo ciertas consideraciones.

En este tiempo, no existe una prctica nica de cmo realizar pruebas de unidad al software orientado a objetos, pues el construir casos de prueba para este tipo de sistemas no es una tarea sencilla. Adems existen muchas posibilidades de que estos casos caduquen muy rpido, por lo que resulta imposible reutilizarlos muchas veces. Autores como [MCG94], [MUR94] y [BIN96], han propuesto estrategias para llevar a cabo la pruebas de unidad considerando aspectos como el orden en que los mtodos son sometidos a la prueba, el orden en que una jerarqua de clases p uede ser probada, ejercitar el flujo de datos o bien el anlisis del estado del objeto.

Pero, qu aspectos deben considerarse para construir casos de prueba para una clase?. Se puede verificar que esta proporcione los servicios que promete, que responda correctamente a las condiciones esperadas y, ms an, ante las inesperadas. Aspectos adicionales pueden el verificar si la clase contiene y permite disponer de todas las funciones asociadas a ella o que cada mtodo de la clase ejecute su responsabilidad especificada. Todo esto se presenta en [BAS99] con mayor detalle.

Estas son algunas de las tcnicas mas populares para realizar pruebas de unidad:

- Pruebas estructurales. Si se tiene la disponibilidad de cdigo fuente, pueden realizarse pruebas estructurales a las unidades sometidas a la prueba. Las acciones de esta actividad pueden disearse con el propsito de ejercitar todas las rutas del cdigo, las condiciones establecidas o bien las ciclos definidos en el programa.

- Prueba de valores limite. Mediante esta tcnica se prueba la unidad bajo situaciones inusuales o extremas, con el propsito verificar cmo son manejadas por el software. Para ello, los casos de prueba suministrados son diseados considerando valores frontera, es decir los

31

valores mnimo y mximo que la unidad puede aceptar, as como tambin aquellos valores cercanos a las fronteras identificadas.

- Prueba basada en estados. Para esta tcnica, se generarn casos de prueba para un contexto en donde una clase se modela como una mquina de estados con secuencias de transiciones, con esto se pretende analizar el estado de los objetos de acuerdo a su comportamiento. Una vez que se ha establecido un modelo de estados con base en los atributos del objeto, se consideran en la prueba los mtodos necesarios para poder observar los cambios de estado. La aplicacin de esta tcnica permite observar alguna de las siguientes situaciones: se produce un cambio a un estado correcto, se produce cambio a un estado incorrecto, no hay cambio de estado, se produce un estado indefinido correcto o bin, se produce un estado indefinido incorrecto .

- Prueba incremental. La prueba incremental dirige su atencin a las subclases generadas como consecuencia de la herencia, siendo la clase padre una clase previamente probada. Aunque existen situaciones en las que ste tipo de pruebas se descarta, se pueden identificar algunas en las que no estaran de ms: cuando se han agregado o modificado propiedades y/o mtodos, cuando existen propiedades y mtodos que se han heredado y no se han alterado, pero que realizan algn tipo de interaccin con elementos nuevos o modificados.

2.5.3.2 Pruebas de integracin.

Cuando se aplican pruebas de integracin al software orientado a objetos, se pretende demostrar que las unidades que ya han sido sometidas a un proceso de prueba y funcionan correctamente, lo hacen de igual forma cuando interactan y se integran con otras unidades

32

del sistema. Prcticamente, el trabajo de esta prueba se concentra en la interaccin de mtodos en diferentes unidades.

Existe una coincidencia en los dos enfoques para realizar este tipo de pruebas: el basado en hilos y el basado en uso. En el primero, pretende que todas las clases respondan a sencillas entradas externas, provenientes de otra unidad. De esta forma, se realizan casos de prueba para cada clase en la unidad, con lo cual un hilo de este conjunto se ejercita.

En el enfoque basado en uso, se realizan pruebas para clases las cuales usan servicios de otras clases.

A continuacin se presentan algunos mtodos para realizar pruebas de integracin:

- Mtodo de Caminos de Mensajes. Este mtodo se concentra principalmente en probar aquellos caminos que se generan por un evento de entrada y terminan con un evento de salida.

- El mtodo de Overbek. En este mtodo se prueban las clases por pares, donde una hace el papel de cliente y otra el de servidor, establecindose para estas dos conjuntos de pruebas. El primer conjunto, son pruebas orientadas a verificar si los mensajes de entrada y de salida generados son correctos; es decir si se usa correctamente cualquier clase servidora y si todas las secuencias de operaciones son correctas. En el segundo conjunto se verifica adems de lo anterior, si la clase cliente siempre satisface las precondiciones de la clase servidora, as como tambin si satisface las salidas esperadas por la clase servidora.

- El mtodo de Kung. Este mtodo emplea una estrategia de ingeniera en reversa sobre el cdigo de las unidades con el propsito de generar un diagrama de relaciones entre objetos. A partir de este diagrama se propone un orden para las pruebas que minimiza el uso de

33

cabos. El diagrama se convierte en un grafo acclico, que puede contener varios clusters de objetos y los ordenan topolgicamente. Su mtodo i volucra las etapas de n pruebas de unidad y de integracin y puede usarse tambin para pruebas de regresin.

2.5.3.3 Pruebas de sistema.

Las pruebas de unidad se concentran en verificar si las funcionalidades descritas en las especificaciones o en los requisitos iniciales corresponden a las que se presentan en el producto final. En esta rea, al igual que la de pruebas de integracin, se han generado pocos trabajos, por lo que se emplean muchos de los mtodos tradicionales.

- Prueba de funcin. La prueba de funcin comnmente es llevada a cabo por el grupo de personas que desarrollaron el producto. Este enfoque se orienta a confirmar que la aplicacin alcanza los requerimientos y la funcionalidad especificadas por el usuario.

- Pruebas de aceptacin (beta). En este tipo de pruebas, versiones que an no han sido liberadas en el mercado, son ofrecidas a ciertos grupos de usuarios con el propsito de que las utilicen. El propsito de sto es que los usuarios reporten defectos que pudieran presentarse.

- Prueba bajo stress. Para realizar esta prueba, el sistema somete a condiciones extremas de trabajo, como pueden ser un alto volumen de transacciones o una gran nmero de usuarios. Aplicando este enfoque, se puede verificar si el sistema se comporta como se espera an ante este tipo de escenarios.

34

2.6

Prueba de software basado en componentes.

La construccin de software a partir de componentes es una prctica relativamente nueva, por lo que no es extrao que sea escasa la existencia de trabajos generados al respecto. Puesto que el desarrollo basado en componentes presenta algunas similitudes con el enfoque orientado a objetos, para un componente pueden ser aplicables algunas de sus consideraciones, incluso en materia de prueba. Aspectos descritos en la seccin 3.2, como la herencia, encapsulacin, polimorfismo, liga dinmica o mecanismos de comunicacin, son comunes entre ambos modelos. Es evidente que para hacer las pruebas de componentes ms robustas, ser necesario considerar las caractersticas propias del enfoque de componentes.

En la mayora de los casos, los criterios de prueba de caja negra son los ms aplicados a los componentes, puesto que la disponibilidad del cdigo fuente es nula en la mayora de las veces. Debido a que un componente es una unidad concreta, con una funcin bien definida, no basta realizar pruebas para su evaluacin; de igual forma se requieren procesos de prueba para su seleccin y para su integracin, [FER99] y [VOA98] .

Durante la etapa de construccin de un componente, el desarrollador puede aplicar las tcnicas de prueba de unidad y de integracin tradicionales del modelo OO, sin embargo en lo que respecta a la seleccin y evaluacin, considerar el punto vista del usuario es un aspecto vital para la realizacin de la prueba. Finalmente en el marco de pruebas de integracin, consideraciones como la arquitectura de la aplicacin, el software intermediario y los modelos de los componentes, deben agregarse a los criterios de evaluacin.

2.6.1 Mtodos de prueba de software basado en componentes.

Con el propsito de organizar algunas de las estrategias de prueba de componentes ms comunes, en las siguientes secciones se presenta una descripcin de las mismas en los trminos que se presentaron para el enfoque orientado a objetos, de nivel unidad y nivel de integracin.

35

2.6.1.1 Pruebas de unidad.

Aunque la realizacin de pruebas de unidad es una actividad que en algn momento es llevada a cabo por el desarrollador, existe un marco de trabajo adicional a considerar: el de la persona que se interesa en el componente con el fin de integrarlo en sus sistemas.

Actualmente son pocos los trabajos en materia de pruebas de unidad para componentes, dos sobresalientes en este ramo son el proyecto Trusted Components [TRU99] y el Proyecto Kimera [SIR97], aunque este ltimo no esta dirigido totalmente a componentes, sino a la seguridad de las mquinas virtuales de Java cada vez que se carga una clase.

Trusted Components, es un proyecto de investigacin paras asistir a la industria de construccin de software mediante libreras probadas de componentes. Las pruebas que se aplican a los componentes se construyen bajo los combinacin de varios enfoques como diseo por contrato, como pruebas matemticas, mtricas, validacin exhaustiva en proyectos prcticos y manejo de cambios rigurosos.

2.6.1.2 Pruebas de integracin.

Si las pruebas de nivel de unidad para componentes muestran severas carencias, en nivel de integracin, al igual que en otros enfoques de desarrollo, las carencias son an ms notables. Sin embargo, existen coincidencias en cuanto a las problemticas comunes al integrar componentes:

-

El volumen y la lentitud. Cuando se utilizan componentes dentro de un sistema, no siempre se utilizan todas sus capacidades, lo que hace que cierta parte del cdigo no sea necesario. Este

36

problema se agrava cuando se tienen sistemas grandes, afectndose as su rendimiento.

-

Los mecanismos de comunicacin utilizados. Se han presentado algunas contrariedades e inconsistencias al utilizar dentro de un mismo sistema varios mecanismos de comunicacin como eventos, mensajes o bien el paso de parmetros.

37

Captulo 3 Descripcin del Diseo.Una vez que se han abordado los fundamentos tericos involucrados en el desarrollo de este proyecto, en este tercer captulo se presenta informacin referente al diseo y funciones de la herramienta de prueba.

Inicialmente se presentan al lector algunas secciones que sirven como un marco de referencia en que se abordan aspectos sobre la necesidad de la herramienta, su ambiente de operacin, su alcance y limitaciones. Posteriormente, se describir la herramienta con base en los mdulos que la conforman y la funcionalidad que estos proveen.

3.1

Antecedentes.

El modelo de desarrollo orientado a objetos se ha convertido en una alternativa bastante popular para la construccin de software; actualmente est siendo adoptada por muchos desarrolladores. Dentro de este entorno, se pueden encontrar una amplia gama de elementos que asisten la construccin de este tipo de software, lenguajes como Pascal y C++, que han sido adaptados con el fin de ofrecer capacidades de orientacin a objetos, o bien alternativas como Eiffel y una de las ms recientes, Java, lenguaje que cada da es mas utilizado.

Muy relacionada con la tecnologa de objetos se tiene el desarrollo de software basado en componentes. Actualmente la construccin de software basado en componentes est convirtindose en una prctica que va ganando aceptacin y aunque ofrece ciertas ventajas, el principal inconveniente que se presenta es el que se refiere a su calidad. Los componentes se ofrecen generalmente como unidades terminadas por lo que, para usarlas el usuario requiere conocer en primera instancia qu hace, y en segunda, y no menos importante, que lo que el componente hace se hace siempre bien, o al menos, en trminos mas realistas, que la funcionalidad del componente ser la esperada dentro del marco de trabajo en el que se

38

pretende usarlo. Esto permite entender que un aspecto fundamental para determinar la calidad, y por consiguiente conseguir la aceptacin de un componente y de su enfoque de desarrollo, sigue siendo la prueba, igual que ocurre en otros modelos.

En el software orientado a objetos y especialmente en el de componentes, existe una caracterstica muy destacable: el reuso, aspecto muy importante a considerar para realizar la prueba. Cuando se realiza una prueba de software, este proceso la mayora de las veces, se lleva a cabo por el mismo desarrollador. Apoyndose en metodologas adecuadas, se pueden obtener resultados significativos para determinar la calidad del software, sin embargo convendra reflexionar un poco ms sobre esto. El entorno considerado para la realizacin de la prueba es el imaginado por el desarrollador del componente, mismo que en algunos casos puede verse influenciado de manera inconsciente por sus propios intereses, esto ltimo puede evitar que muchos de los errores puedan ser descubiertos. Si el software es utilizado por personas diferentes al desarrollador, es muy posible considerar que el ambiente de operacin difiera, ante esta posibilidad, puede plantearse la siguiente interrogante, es suficiente la prueba realizada por el desarrollador para garantizar que el componente es de calidad?, en la mayora de los casos la respuesta es no.

3.2

La Prueba de beans.

De las nuevas alternativas para construir software orientado a objetos, Java es una de las que ha ganado muchos adeptos. De hecho, mucho del software que se construye hoy, esta siendo escrito con este lenguaje de programacin, del cual analizando sus caractersticas, no es difcil entender el porqu.

Java es un lenguaje de programacin Orientado a Objetos, de propsito general, creado por la compaa Sun Microsystems. Est parcialmente basado en C lo que facilita su aprendizaje; quizs una de sus ms atractivas ventajas es la independencia de software y hardware que tienen las aplicaciones que con l se construyen. Dada esta caracterstica, cuando se crea una aplicacin en Java para una plataforma especfica, el desarrollador de

39

aplicaciones ya no tiene que invertir tiempo y esfuerzo para modificarla en caso de que tenga que migrarla hacia otros ambientes, sino solo preocuparse por disponer de la mquina virtual adecuada.

Cuando surge el m odelo de desarrollo basado en componentes, al igual que ocurri con los objetos, algunas compaas ofrecen alternativas para la construccin de software en este contexto. Tres de las ms significativas se presentaron en el captulo 1. Con Java Beans, actualmente es posible contar con las capacidades que ofrece Java en el mbito de los componentes.

Como el software de componentes es relativamente nuevo, en materia de pruebas no tiene nada formal, sobre todo si la prueba sta pensada ms para un usuario final, factor determinante para el uso de componentes. Actualmente existen herramientas automatizadas para probar software orientado a objetos y bajo ciertas consideraciones algunos de los mtodos definidos para probarlo pueden ser aplicables a componentes, ya que estos son un tipo de software muy parecido al orientado a objetos.

An ante la presencia de una afirmacin de garanta total sobre el componente que se dispone a utilizar, el usuario normalmente, antes de adoptarlo, lo somete a una proceso de prueba. Este proceso, de acuerdo a su experiencia y suspicacia, puede ser detallado e implementado bajo metodologas formales de prueba de software. Sin embargo, siendo realistas, la mayora de los usuarios finales carecen de estos conocimientos. Adems, cuando un componente se ofrece en el mercado, es una unidad encapsulada y, en el caso de JavaBeans, comprimida dentro de un archivo JAR, que impide al menos de forma inmediata, que pueda ser inspeccionada por el usuario. El difcil acceso a todos los mtodos del componente, obstaculiza que estos puedan ser sometidos a una prueba. En trminos generales, no se cuentan con muchas alternativas para probar componentes.

40

Actualmente existen en el mercado herramientas para probar clases de Java como por ejemplo junit(1)

y jtest

(2)

, pero no son tiles para realizar pruebas a Beans y, en general estas

descansan sobre el cdigo fuente.

Es cierto que el BeanBox puede considerarse como una herramienta con facilidades de prueba, pues de manera implcita, implementa algunas funciones para la prueba de componentes. El usuario puede cargar, interconectar y ejecutar componentes dentro del BeanBox. Mediante la PropertySheet, se permite al usuario modificar directamente los valores para las algunas propiedades, o bien, visualizar efecto generado sobre estas, como producto de la ejecucin de mtodos. Este procedimiento puede repetirse tantas veces se requiera, y aunque el monitoreo de casos es responsabilidad del usuario, este puede comparar los

resultados obtenidos y determinar si el comportamiento del componente es el adecuado, o mejor dicho, si la funcionalidad del componente es la que necesita. A pesar de esto, las

capacidades ofrecidas distan mucho de las que ofrece una herramienta creada especialmente para probar software, puesto que la prueba es solo visual.

En el caso que una componente presenta una falla, mediante el BeanBox, no siempre es posible saber qu parte es la que fall; con un poco de suerte, el usuario podra identificar bajo qu condiciones no trabaja correctamente el componente; sin embargo esto no deja de ser una prueba muy oscura. Ya se mencion que existen elementos de la clase que son manipulables, pero no son todos, existen mtodos que no pueden ser directamente afectados por el usuario, por lo que usando el BDK, no son fciles de probar.

Todo esto nos permite pensar que se requiere contar con alternativas ms robustas que permitan probar este tipo de componentes.

1 http://www.mcwestcorp.com/Junit.html 2 http://www.parasoft.com/products/jtest/quick.html

41

3.3

Aspectos de diseo.

El objetivo de este trabajo es presentar una herramienta para realizar pruebas a componentes construidos bajo el modelo de Java Beans. Las pruebas que realiza la

herramienta se aplican en el nivel de unidad, puesto que como un primer esfuerzo, este trabajo se apoya en trabajos generados para este nivel en el mbito orientado a objetos. As mismo en materia de componentes, es el nivel del cual se dispone mayor cantidad de informacin, comparndolo con el de nivel de integracin.

Para el diseo de la herramienta, se identificaron cuatro etapas determinantes:

a) b) c) d)

La seleccin de unidades a ser probadas, la generacin de casos de prueba, la ejecucin del plan de prueba, y la presentacin de resultados.

Estas etapas se implementan en la herramienta como un conjunto de mdulos con funciones bien definidas y que guardan dependencias mnimas entre s. La dependencia principal radica en las salidas que generan, las cuales en algunos casos son utilizadas como entradas para otros mdulos. Esta estructura permite un enfoque similar al de desarrollo a partir de componentes, de forma que se pueden realizar cambios y sustituciones de mdulos de acuerdo a las preferencias de los usuarios. Todos estos mdulos son invocados desde un modulo lanzador, ver Figura 3.1.

A continuacin se presenta la descripcin de cada uno de los mdulos de la herramienta.

42

S1

Seleccin de los componentes

S2

Generador de Casos de Prueba

S3

L a n z aUsuario de la herramienta

Editor de Casos de Prueba

S4

S5

Ejecutor de Casos de Prueba II

d o rEjecutor de Casos de Prueba IS6

Presentador de Resultados II

Presentador de Resultados I

Salida a un archivo de texto

Figura 3.1 Relaciones entre los mdulos de la herramienta de prueba.

43

3.3.1 Seleccin de los componentes.

El software orientado a objetos generalmente est construido a partir de un conjunto de clases, las cuales ofrecen y utilizan servicios entre s con el fin de realizar ciertas funciones. Adems de las clases, para que funcione una aplicacin, se pueden requerir otros elementos tales como archivos de imgenes, de configuracin o de ayuda. Esta situacin se presenta tambin en los componentes escritos con Java.

La mayora de los componentes construidos bajo el modelo de Java Beans, contienen los siguientes elementos:

a) b) c)

Una o ms clases definidas como Beans, un archivo para su representacin mediante un icono, y una o ms clases que no estn definidas como Beans, pero que son necesarias para el funcionamiento del componente.

Para muchos de los usuarios del software orientado a objetos, y en especial de componentes, el tener que manejar estos elementos en forma individual puede representar cierta dificultad o incomodidad, por esta razn, si se ha tenido la oportunidad de utilizar componentes de Java, se puede apreciar que estos se presentan en muchas ocasiones como un archivo JAR, mismo que empaqueta todos los elementos necesarios para la ejecucin del componente dentro una sola unidad.

Cuando un componente se carga en el BeanBox, si el archivo JAR fue correctamente creado, se extraen el o los Beans contenidos en l, as como otros elementos de forma que puedan utilizarse dentro del ambiente de trabajo.

De forma similar al BeanBox, la herramienta cuenta con la capacidad para leer archivos JAR, con el propsito de que los procesos implementados para las pruebas puedan ser aplicados a los componentes que el archivo contenga. Existen algunas consideraciones con

44

respecto a los archivos JAR para que puedan ser correctamente manipulados por la herramienta. Bsicamente las consideraciones son de dos tipos:

1. Con respecto a su contenido: a) Que las clases sean componentes implementados bajo las consideraciones del modelo propuesto por JavaBeans. b) Que el componente sea vlido, es decir pueda ser cargado y utilizado correctamente en el BeanBox.

Las consideraciones respecto al contenido permiten que la herramienta pueda disponer de unidades vlidas para los procesos que realiza.

2. Con respecto a su funcin: a) Que el usuario tenga una comprensin, al menos general, de la funcin que realiza el componente.

La consideracin respecto al contenido facilitan al usuario el anlisis de los resultados generados por los procesos que realiza la herramienta.

Las salida generada mediante la ejecucin de este mdulo consiste en un archivo de texto dentro del cual se almacenan los nombres de cada uno de los componentes contenidos en el archivo JAR, esta informacin se comunica al usuario mediante la interfaz del mdulo. La Figura 3.2, muestra una vista de lo que vera el usuario despus de haber utilizado este mdulo.

45

Figura 3.2 El mdulo apertura de archivos JAR.

3.3.2 La generacin de casos de prueba.

La definicin del plan, es un aspecto determinante para la efectividad de la prueba de software, ya que los resultados obtenidos despus de haberse realizado este proceso permitirn tener ciertas directrices para calificar el comportamiento del elemento evaluado.

Las pruebas de unidad para software orientado a objetos establecen como unidad elemental de evaluacin a la clase, especficamente a una instancia de esta, un objeto, dirigiendo especial atencin a sus atributos y operaciones. De esta forma, una prueba ideal, podra ser aquella en la que se consideraran a todos los mtodos contenidos en la clase.

En el contexto de componentes, y en virtud de que el usuario experimenta con ellos, generalmente no se dispone del cdigo fuente, el enfoque que parece ser ms aplicable para realizar pruebas a este tipo de software es el funcional, ya que permite al probador experimentar con respecto a entradas suministradas y salidas obtenidas.

46

De acuerdo a lo que establece [BER93], para el diseo de un plan de prueba deben considerarse los siguientes puntos:

a) Establecer una relacin entre caso de prueba y clase. b) Establecer un propsito para la prueba. c) Definir los pasos de la prueba considerando: una lista de estados iniciales de los objetos a probar, una lista de mtodos a ejercitar, una lista de excepciones que pueden ocurrir cuando se prueba el objeto, una lista de condiciones externas para que se lleve a cabo de forma correcta la prueba, e informacin adicional, en caso que se requiera, con el propsito de ayudar a realizar la prueba.

Teniendo en cuenta estos aspectos, la herramienta ofrece dos alternativas para la generacin de casos de prueba: casos generados de forma automtica y casos administrados por el usuario. A continuacin se describen las generalidades de la generacin automtica de casos de prueba.

De acuerdo con el objetivo, automatizar la realizacin de pruebas tanto como sea posible, se ejecutarn programas con casos de prueba asociados. Con esto se pretende ofrecer al usuario una directriz sobre la calidad de la componente.

La prueba preparada por la herramienta, consiste de un conjunto de casos de prueba, los cuales se aplican a los mtodos contenidos en la clase que implementa el componente.

Existen mtodos o funcionalidades del componente, de las que un usuario espera comportamiento determinado en relacin a una entrada suministrada. Teniendo en mente esto y, atendiendo las consideraciones de la tcnica de prueba de valores lmite, los casos fueron pensados bajo la premisa de que al suministrar valores a la frontera, es posible que pudieran presentarse errores al ejecutarse un mtodo.

47

As mismo, se tomaron en cuenta algunas consideraciones de la prueba basada en estados, con el propsito de presentar una descripcin del estado de los objetos evaluados. Esto se consider necesario ya que pueden existir situaciones en la que la ejecucin de un mtodo ocurre sin ningn contratiempo, sin embargo el estado final del componente no es el esperado. Especficamente se inspecciona el estado inicial y final del componente, con respecto a la ejecucin de un mtodo.

Es importante mencionar que, aunque son tcnicas validas y eficientes para evaluar componentes, mediante su aplicacin no es posible garantizar que todas las lneas de cdigo que contiene un mtodo se ejerciten; esto se debe tener presente al disear los casos de prueba y la cobertura de los mismos.

Cuando un mtodo se invoca suceden varias cosas: el mtodo toma los parmetros de entrada, los combina con las variables de instancia, ejecuta el cdigo correspondiente y produce un resultado, [KUN96]. Considerando esta secuencia de acciones, en la herramienta cada caso de prueba se genera en torno a las entradas que puede recibir un mtodo, las cuales han sido identificadas mediante la revisin de sus parmetros. Estas pueden presentarse como:

a) Argumentos que consisten en tipos definidos en Java, como un int, char, Object, Color, etc., o bien, b) La invocacin de un objeto externo, especficamente objetos definidos por el usuario.

Aunque se ha mencionado que se han tomado en cuenta las consideraciones de la prueba de valores limite para la generacin de casos de prueba, tambin se decidi someter a la unidad a condiciones muy simples, generado as tambin casos de prueba con estas caractersticas. Los valores establecidos para la generacin de casos de prueba se presentan con detalle en el Anexo A.

48

Con respecto a la cobertura de las pruebas, se pretende inicialmente generar y suministrar casos de prueba a cada uno de los mtodos contenidos en la clase, sin embargo este objetivo puede verse impedido ante la presencia de parmetros no considerados en la herramienta, o bien cuando se presentan problemas al hacer referencia a objetos externos.

Con el propsito de atacar esta debilidad, se ha implementado un mecanismo que permite a este mdulo cargar Plug-ins definidos por el usuario. Este mecanismo consiste bsicamente de un archivo que contiene valores de prueba para el nuevo argumento y la inclusin del constructor correspondiente dentro de una clase especial.

Los casos de prueba generados por este mdulo son almacenados en un archivo de texto. Mediante la interfaz de este mdulo, se informa al usuario el nmero de mtodos contenidos en la clase, el nmero de mtodos para los cuales se generaron casos de prueba, el nmero de mtodos para los que no se generaron casos de prueba y el nmero de mtodos que no reciben ningn tipo de argumento, ver Figura 3.3.

Figura 3.3 El mdulo generador de casos de prueba.

De igual forma, este mdulo genera un segundo archivo de salida con el propsito de que, posteriormente, el usuario, pueda utilizarlo para almacenar los casos que l plantea

49

mediante el mdulo de edicin de casos de prueba. En caso de que el usuario no desee proporcionar casos en la prueba de forma manual, el contenido del archivo puede dejarse sin modificacin alguna.

3.3.3 La ejecucin de casos de prueba.

Una vez que han sido generados los casos de prueba para un Bean, ya sea de forma automtica o de forma manual, la siguiente actividad consiste en alimentar dichos casos de prueba a los mdulos correspondientes para que sean ejecutados, as como tambin capturar las salidas generadas como producto de esta serie de ejecuciones. Estas son las tareas que realizan los dos mdulos ejecutores disponibles, uno de ellos que ejecuta los casos generados de forma automtica por la herramienta y otro que ejecuta los casos de prueba proporcionados por el usuario.

Aunque en condiciones ideales se pretende ejercitar cada uno de los mtodos contenidos en la clase al menos una vez, pueden existir mtodos que se ejecuten ms de una vez, al igual que mtodos que pasen desapercibidos durante esta etapa, como consecuencia del nmero de casos de prueba generados para cada mtodo en el mdulo anterior. De esta forma, se ejercitan los mtodos que as lo permiten

Como consecuencia de estas ejecuciones se producen una serie de salidas las cuales, se identifican mediante alguna de las siguientes alternativas:

a) el valor de retorno del mtodo y, b) los mecanismos de excepcin.

Por tratarse de software orientado a objetos, es conveniente hacer ms profunda la revisin y manejo de las salidas obtenidas, pues en ocasiones una salida correcta, no implica que el estado interno de un componente lo sea tambin. Con este propsito, se tomaron en

50

cuenta algunas consideraciones de la prueba basada en estados, por lo se agrega un tercer tipo de alternativa:

c) el estado del objeto

Retomando ideas planteadas en [TUR93] y [BAS99], se inspecciona la representacin de los datos miembros y la forma en que los mtodos estn manipulando la representacin del objeto, con el propsito de establecer un conjunto de estados que un objeto puede tener, concretamente, un conjunto de estados validos a partir de los cuales puede aceptar una entrada y un conjunto de estados vlidos despus de haberse generado una salida esperada. Esto permite que se puedan ejecutar casos de prueba partiendo del estado inicial de la componente, o bien cuando este estado haya cambiado como resultado de operaciones previas. Este manejo de estados consiste bsicamente en la generacin del pre-estado del objeto sobre el cual el mtodo acta y la generacin del post-estado resultante. Se est suponiendo el estado del objeto como la coleccin de valores de las propiedades del Bean en un momento dado, accesibles mediante mecanismos del propio Bean.

Los mdulos ejecutores de casos de prueba operan de forma individual y, al trmino de la ejecucin de cualquiera de estos, se dispone de un archivo de texto que almacena los resultados obtenidos.

De igual forma en ambos mdulos, mediante la interfaz del usuario se presenta un resumen que informa la cantidad de mtodos en la clase, la cantidad de mtodos para los cuales se ejecutaron casos de prueba y la ca