Prueba de componentes de software basadas en el modelo de ...

UNIVERSIDAD AUTÓNOMA DE TLAXCALA
DEPARTAMENTO DE INGENIERÍA Y TECNOLOGÍA
UNIDAD DE ESTUDIOS DE POSGRADO
PRUEBA DE COMPONENTES DE
SOFTWARE BASADAS EN EL MODELO DE
JAVABEANS
TESIS
QUE PARA OBTENER EL GRADO DE
MAESTRO EN CIENCIAS
EN INGENIERÍA EN COMPUTACIÓN
PRESENTA:
PERLA INÉS VELASCO ELIZONDO.
DIRIGIDA POR:
M.I. JUAN MANUEL FERNÁNDEZ PEÑA.
M.C. MA. ELENA HERNÁNDEZ HERNÁNDEZ.
APIZACO, TLAX. ABRIL DE 2001.

Dedico cariñosamente 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 emoción de este
nuevo momento.
Mi maestro y asesor Juan Manuel Fernández Peña.

Índice
Resumen ........................................................................................................................ 1
Abstract .......................................................................................................................... 2
Introducción ................................................................................................................. 3
1. Sofware Basado en Componentes ................................................................... 6
1.1 El concepto de componente .......................................................................... 6
1.2 El concepto de software basado en componentes ........................................ 8
1.3 Objetos y componentes ................................................................................... 9
1.4 Modelos para el desarrollo ............................................................................ 10
1.4.1 COM y DCOM ..................................................................................... 10
1.4.2 Corba ...........................................................................................…… 11
1.4.3 JavaBeans .................................….............................................…..… 12
1.4.3.1 El bean development kit ………………..……….....................…. 14
2. Revisión Técnica sobre Prueba de Software ...................................... .. 17
2.1 La prueba de software .................................................................................. 17
2.2 Objetivos de la prueba del software ............................................................ 19
2.3 Métodos de prueba del software .................................................................. 20
2.3.1 Pruebas de caja blanca .................................................................... 20
2.3.2 Pruebas de caja negra ...................................................................... 22
2.4 Niveles de prueba del software .................................................................... 23
2.5 Prueba de software para objetos ................................................................. 25
2.5.1 Generalidades del modelo de desarrollo
orientado a objetos ............................................................................ 26
2.5.2 Aspectos a considerar en la prueba del
software orientado a objetos ............................................................. 27

2.5.3 Métodos de prueba de software orientado
a objetos ........................................................................................... 30
2.5.3.1 Pruebas de unidad ................................................................... 30
2.5.3.2 Pruebas de integración ........................................................... 32
2.5.3.3 Pruebas de sistema ................................................................ 34
2.6 Prueba de software basado en componentes ............................................ 35
2.6.1 Métodos de prueba de software basado
en componentes ............................................................................... 35
2.6.1.1 Pruebas de unidad .................................................................. 36
2.6.1.2 Pruebas de integración ............................................................ 36
3. Descripción del Diseño ..................................................................................... 38
3.1 Antecedentes ............................................................................................... 38
3.2 La prueba de beans ..................................................................................... 39
3.3 Aspectos de diseño ..................................................................................... 42
3.3.1 Selección de los componentes .......................................................... 44
3.3.2 La generación de casos de prueba .................................................... 46
3.3.3 La ejecución de casos de prueba ...................................................... 50
3.3.4 La presentación de resultados ........................................................... 52
4. Descripción de la Arquitectura e Implementación ...................................... 56
4.1 Arquitectura y colaboración entre clases ..................................................... 56
4.1.1 La invocación de los servicios .......................................................... 59
4.1.2 La extracción de archivos jar ............................................................ 61
4.1.3 La generación de casos de prueba .................................................. 64
4.1.4 La ejecución de casos de prueba generados
automáticamente .............................................................................. 67
4.1.5 La ejecución de casos de prueba generados
manualmente .................................................................................... 70
4.1.6 La presentación de resultados ......................................................... 73

5. Pruebas de Funcionamiento ............................................................................ 77
5.1 Los componentes utilizados .......................................................................... 77
5.2 El componente Puzzle ................................................................................ 78
5.2.1 Los resultados observados ................................................................. 80
5.3 El componente TextEditor ........................................................................... 82
5.3.1 Los resultados observados ................................................................. 84
5.4 El componente ProgressBar ........................................................................ 86
5.4.1 Los resultados observados ................................................................. 87
Conclusiones ............................................................................................................ 89
Anexo A ...................................................................................................................... 91
Anexo B ..................................................................................................................... 93
Anexo C ..................................................................................................................... 106
Referencias bibliográficas ................................................................................... 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 gráficos 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 selección
y evaluación de las componentes mediante la generación y ejecución automática 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 tool’s objective is to offer guides to users on components selection
and evaluation through automatic execution and generation of test cases.
2

Introducción.
Actualmente el reuso de elementos preexistentes es una práctica común en la actividad
de desarrollo de software. Situaciones como la competencia en el mercado para generar
nuevos productos o actualizar versiones, han propiciado que muchos desarrolladores busquen
nuevas opciones para generar software en tiempos muy cortos. Incluso, en ambientes de
desarrollo no comercial, la actividad del reuso también se lleva a cabo; un simple ejemplo es
la inclusión de bibliotecas o clases en los programas de un estudiante, con el fin de reutilizar
funciones o métodos ya implementados.
La creación de nuevas metodologías de desarrollo, cuyas características han permitido
alcanzar en diversos grados la rápida construcción de programas, han considerado al reuso
como una actividad básica, contribuyendo así a que esta se convierta en una alternativa
atractiva en la construcción de software. El desarrollo orientado a objetos y el desarrollo
basado en componentes, son ejemplos significativos de lo planteado anteriormente. A pesar de
la aceptación alcanzada por estos enfoques, una de las más importantes limitaciones que
surgen, es la falta de garantías que se tienen de que el o los elementos de software que se están
reusando funcionen correctamente en todas las ocasiones, situación 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 aceptación, 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 número 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 algún 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
operación 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 información, dificulta esta
actividad. En el caso de los componentes, que normalmente se ofrecen como productos
terminados, no se dispone del código fuente, por lo que es difícil inspeccionar completamente
su estructura interna. Este, además de otros factores propios del modelo de desarrollo impiden
que un proceso de prueba pueda llevarse a cabo fácil y eficientemente.
Actualmente son pocas las herramientas que permiten evaluar elementos preexistentes.
Cuando alguien requiere integrar un elemento de software para construir una aplicación o
simplemente para utilizarla de forma aislada, la evaluación que se realiza radica en la mayoría
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 más exhaustiva, esta prueba seria
más 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 propósito de este trabajo es presentar una alternativa para la prueba de
componentes. Esto se llevará a cabo mediante la implementación 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 podrán realizar
de forma automática la generación y ejecución 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 selección y
evaluación de las mismas.
4

El tipo de prueba que realizará la herramienta es a nivel de unidad, utilizándose para
ello técnicas de prueba funcional. Así mismo, los servicios que ofrecerá la herramienta
estarán orientados a los usuarios de los componentes, más que a los desarrolladores originales.
Con el propósito de describir el trabajo que se realizará para la creación de la
herramienta, este trabajo se organiza fundamentalmente en dos partes, en la primera que
comprende los capítulos 1 y 2, se presenta de acuerdo a una revisión bibliográfica los temas
Software Basado en Componentes y Métodos de Prueba de software respectivamente, en los
cuales se pretende proporcionar al lector un marco teórico de referencia con respecto al diseño
de aplicación a desarrollar. La segunda parte que comprende de los capítulos 3 al 5, se
concentra en la descripción de la herramienta implementada. Para ello en el capítulo 3
“Descripción del Diseño”, como su nombre lo indica, se presentarán las consideraciones con
respecto al diseño de la herramienta de prueba. En el capitulo 4 “Descripción de la
Arquitectura e Implementación”, se describen detalles referente a la implementación. En el
quinto y último capitulo “Pruebas de Funcionamiento”, se presentan algunas de las pruebas
realizadas con el propósito de verificar el adecuado funcionamiento de la aplicación.
Al final de este documento, se encuentran secciones que contienen las conclusiones,
obtenidas como producto de este trabajo, una sección en donde se citan las referencias
bibliográficas, y anexos.
El Anexo A que contiene información referente a los valores establecidos para la
generación de casos de prueba. El anexo B contiene el manual del usuario de la herramienta.
El anexo C presenta detalles de la notación utilizada para la descripción del diseño.
5

Capítulo 1
Software Basado en Componentes.
Como respuesta a la necesidad de buscar alternativas que permitan hacer más fáciles
las tareas de desarrollo e integración de software, uno de los más recientes modelos de
desarrollo es el de componentes. Aspectos como el reuso y la interoperabilidad, muy
importantes en la actualidad, son característicos de este enfoque. Puede visualizarse como un
modelo de desarrollo bastante prometedor.
Con el propósito de ofrecer información que permita al lector conocer sobre el
desarrollo a partir de componentes, en este capítulo se presenta una descripción del modelo
con base en sus principales características. Así mismo, al término de esta descripción, se
presentarán 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 propósito bien
definido que, trabajando en conjunto con otras, puede ofrecer alguna funcionalidad compleja.
Transportando este concepto al contexto de ingeniería de software, específicamente 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 términos formales, y de acuerdo con [MAR96], un componente es una pieza de
software que cumple con dos características: no depende de la aplicación que la utiliza y, se
puede emplear en diversas aplicaciones.
Según se cita [SZY97], los asistentes a la ECOOP96 definen a un componente como
una unidad de composición con interfaces definidas contractualmente y dependencias
6

contextuales explícitas solamente. Un componente de software puede desplegarse
independientemente y estar sujeta a composición por terceros.
El análisis de las ideas presentadas en estas definiciones y, de acuerdo con lo que
plantea [FER99], se pueden identificar características en común:
- Orientación al reuso, lo que nos hace pensar en algo que se puede tomar y utilizar
más de una vez.
- Interoperabilidad, el componente no puede solo usarse de forma aislada, sino que
puede integrarse a otras y trabajar conjuntamente.
- Función significativa, el componente tiene una función bien definida, identificable
y diferenciable.
- Encapsulamiento, generalmente los componentes ocultan detalles acerca de su
implementación.
Una definición más orientada a un enfoque de desarrollo, es la presentada en [DSO99]
en la que un componente se define como un paquete coherente de una implementación de
software que puede ser independientemente desarrollado y entregado, tiene interfaces
explícitas y bien especificadas para informar los servicios que provee y espera de otros, puede
estar constituido por otros componentes, quizás mediante la especialización de algunas de sus
propiedades, sin que esto signifique modificar los componentes mismos.
Tomando esta última definición se pueden enriquecer algunas de las características
presentadas antes considerando también:
- Una lista de interfaces proveídas y requeridas, las cuales representan mecanismos
indispensables para la interoperabilidad de los componentes.
7

- Una especificación externa, medio que permite principalmente identificar la función
del componente.
- El código de validación, necesario para verificar, cuando se utilizan mas de un
componente, si se conectaron correctamente.
- El código 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 definición presentada para este concepto por [DSO99], se habla de un enfoque
de desarrollo de software en el cual todos los artefactos -desde código ejecutable para la
especificación de la interfaz, arquitecturas, modelos de negocios, escalar aplicaciones
completas y descomposición de sistemas en partes- pueden ser construidos por ensamble,
adaptación y conexión de componentes existentes dentro de una variedad de configuraciones.
Es claro que las características 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 actualización de aplicaciones
o la posibilidad de desarrollo en paralelo de diferentes partes de un sistema. Ante este
panorama, es importante hacer mención de que al ser esta un área de investigación
relativamente joven, existen muchos aspectos que aún no son lo suficientemente robustos.
Carencias como el soporte disponible, la selección de componentes, el manejo de excepciones
o bien la prueba de integración 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.
Según [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 ejecución, el cual es parte de un componente. Esta idea
permite comprender que un componente puede contener uno o más objetos. En términos
reales, un componente se manifiesta frecuentemente como una colección de objetos.
Finalmente, con el propósito de diferenciar a los componentes de los objetos, a
continuación se presentan algunas características que se destacan en [FER99] y [DSO99]:
- Los componentes tienen persistencia, los objetos solo utilizan memoria.
- Los componentes utilizan otras formas de comunicación 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 especificación de las
interfaces proveídas y requeridas, mientras que la en los objetos estas
especificaciones se concentran en las operaciones proveídas.
9

1.4 Modelos para el desarrollo.
La metodología de desarrollo basada en componentes, ha adquirido el respaldo de
compañías importantes como Microsoft y Sun que han propuesto sus propios modelos de
desarrollo. En las siguientes secciones se describen tres de los más 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
construcción de documentos con OLE para Windows 3.1, este modelo ha sido enriquecido con
el propósito de permitir la construcción de aplicaciones a partir de componentes.
COM es esencialmente un esquema de integración, 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 estándar binario.
Este estándar 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,
ocultándose así detalles de implementación, lo cual permite que componentes que estén
escritos en diferentes lenguajes de programación de los que se pueden incluir a C++, Small
Talk, Ada, VisualBasic, Delphi o Power Builder, puedan comunicarse.
Dadas las características de las vtables, las interfaces no pueden definirse utilizando
herencia múltiple, porque se deben considerar la posibilidad de tener varias vtables y más de
un apuntador por interface.
Las interfaces COM se definen utilizando un lenguaje especial denominado IDL. La
compilación de estas interfaces, produce una especie de librerías que contienen información
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 públicas.
Distributed COM, mejor conocido como DCOM, es una extensión 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 comunicación 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ó inicialmente el funcionamiento de COM
y DCOM, se basa estrictamente en el estándar 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 los componentes necesitan ser recompilados para la plataforma
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 están localizados o por quien han sido diseñados. Para esto, se han
considerado algunos elementos importantes como: un lenguaje de definición de interface
(IDL) y una API que provee al programador la interacción cliente-servidor entre componentes
con la implementación 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 definición llamado OMG Interface Definition Language (OMG IDL), mismas que
definen las operaciones de los objetos. Actualmente existen estándares para el mapeo de un
IDL a lenguajes de programación 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 comunicación
transparente entre clientes y objetos, actuando como un intermediario para realizar la
comunicación ya sea local o remota entre componentes. El ORB simplifica la programación
distribuida desligando del cliente detalles sobre la invocación de los métodos. Para ello,
intercepta la solicitud, encuentra el objeto que corresponde a dicha solicitud, invoca al método
correspondiente y regresa el resultado. Al delegarse al ORB todas estas responsabilidades, el
cliente no tiene que preocuparse por detalles sobre la localización del objeto, sobre el lenguaje
de programación 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 aceptación, es el propuesto por Sun Microsystems [SUN97], conocido como Java
Beans.
Java Beans es una API implementada para la construcción y uso de componentes
escritos en Java, los cuales son comúnmente llamados Beans. Esta API es proporcionada por
SUN como una herramienta visual que permite la carga, utilización, modificación, así como
también interconexión de Beans, con el propósito de construir nuevos Beans, applets o bien
aplicaciones completas.
12

Retomando la idea de [VAN98] , una forma útil para describir a un Bean es
comparándolo con una especie de caja negra; una unidad de la cual se conoce su funcionalidad
pero no su implementación o estructura interna. Siendo un Bean un elemento de software
sobre el cual solo se conoce su función, es preciso contar con algún mecanismo que permita la
comunicación con él. En este modelo, ese mecanismo de comunicación consiste en una
interfaz, a partir de la cual, se puede acceder a los elementos principales de un Bean: sus
métodos, propiedades y eventos.
En Java Beans, los métodos implementados en un Bean, especialmente los definidos
con el prefijo set o get, son un medio para interactuar con el. Los métodos pueden entenderse
como servicios con efectos específicos que el usuario puede invocar en algún momento.
Las propiedades son conceptualmente equivalentes a lo que en el software tradicional
se conocen como atributos, estos consisten en conjunto de características que un usuario
puede leer o modificar haciendo uso de los métodos de acceso.
Los eventos son utilizados por el Bean como un medio de comunicación con otros
Beans. Un evento se presenta como un cambio de estado que el componente puede notificar a
su ambiente. El evento lleva información de quién lo genera, así mismo puede llevar datos y
aún 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 propósito de distinguirlo de otros. La
característica más importante, es por supuesto, que el componente este escrito en Java, además
de soportar las siguientes capacidades:
a) Introspección, mecanismo mediante el cual se pueden descubrir las propiedades,
métodos y eventos que un Bean contiene.
13

) Soporte a propiedades, la posibilidad de conocer las características de los
atributos y la capacidad de poder ser modificados a tiempo de diseño.
c) Soporte a eventos, actividades como generación, escucha o respuesta a eventos
con el propósito 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 estándar de CORBA.
Aunque los Beans han sido pensados para ser simples procesos locales, recientemente
se ha propuesto una alternativa para trabajar con componentes remotos diseñadas 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 propósito de realizar estas tareas, el BDK implementa tres elementos
principales: el BeanBox, el ToolBox, y el PropertySheet. La apariencia de estos elementos,
después 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 menúes, que incluyen acciones como salvar el
contenido actual del BeanBox -incluyendo aspectos como tamaño, posición, estado-,
generación de applets a partir del contenido del BeanBox, cargar archivos JAR, realizar un
reporte de introspección al Bean, listar los métodos que lanzan eventos, etc.
Figura 1.1 Apariencia del BDK.
En el BeanBox se presenta al usuario una vista, en tiempo de diseño, de lo que
ocurriría cuando la aplicación 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 descripción 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 manipulación.
Al iniciarse BeanBox, este carga de forma automática 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
manipulación de sus propiedades, métodos 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 modificándose así la apariencia y
comportamiento del Bean, aspectos que en muchos casos pueden ser apreciables desde el
BeanBox.
16

Capítulo 2
Revisión Técnica 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 difícil 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
ingeniería de software, a partir de cual se han generado un gran número de trabajos. En este
capítulo se presenta una revisión técnica sobre la prueba de software, abordándose
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
ejecución.
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 evaluación de
algún aspecto del sistema o componente.
Cuando se habla de condiciones especificas en la definición anterior, se puede suponer
la presencia de una especie de ambiente de operación de la prueba, para el cual deben existir
determinados valores para las entradas y las salidas, así como también ciertas condiciones que
delimitan a dicho ambiente de operación. Formalmente esto es conocido como caso de prueba.
La IEEE [IEEE90] define un caso de prueba como:
Un conjunto de entradas, condiciones de ejecución y resultados esperados diseñados
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 evaluación.
De lo anteriormente presentado surgen cuestionamientos como: ¿cómo seleccionar
casos de prueba representativos?, ¿cuántas pruebas realizar? o bien ¿cómo decidir si es o no
de calidad el producto evaluado?, los cuales permiten entender que cada una de estas acciones
18

equiere especial atención. Por fortuna, actualmente existe una base teórica que permite guiar
la puesta en marcha de estas actividades.
Términos como falla, equivocación y error, pueden considerarse como sinónimos, sin
embargo, dentro del contexto de prueba de software no es prudente realizar esta suposición.
Con el propósito evitar confusiones y presentar al lector conceptos básicos en materia de
pruebas, se presentan estas definiciones tomadas de [IEEE90] :
a) Equivocación (mistake):
Acción del ser humano que produce un resultado incorrecto.
b) Defecto o falta (fault):
Un paso, proceso o definición de dato incorrecto en un programa de computadora. El
resultado de una equivocación.
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 preámbulo, antes de establecer los objetivos de la prueba de software es
recordar la afirmación realizada por Dijkstra en los años 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 sección anterior, la prueba de software se realiza con el
propósito 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 ejecución de un programa con la intención 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 Métodos de prueba de software.
Desde hace ya algunos años, han surgido y evolucionado una variedad de métodos
para realizar pruebas de software. Las alternativas más 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 continuación se hace una
descripción 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 atención a los detalles procedimentales del
software, por ello la implementación de estas pruebas depende fuertemente de la
disponibilidad de código fuente. Este tipo de pruebas, permiten generar casos para ejercitar y
20

validar los caminos de cada módulo, las condiciones lógicas, los bucles y sus límites, así como
también para las estructuras de datos. Las pruebas de caja blanca también son conocidas como
pruebas de caja de cristal o pruebas estructurales.
Algunas de las pruebas más significativas dentro de este enfoque son:
- Prueba de caminos.
En este tipo de prueba se realiza un análisis sobre una representación gráfica de un
programa denominada grafo de control. En este grafo, los nodos representan bloques
de instrucciones de un programa y los flujos de ejecución para dichas instrucciones
se representan por medio de aristas. A partir de este grafo, se puede identificar un
conjunto básico de caminos de ejecución, sobre el cual se pueden realizar pruebas
con el propósito de ejercitar el flujo de ejecución de los caminos en una unidad.
- Prueba de condiciones.
Basándose de igual forma en un grafo de control, pueden generarse casos de prueba
para elementos individuales de expresiones lógicas. De esta forma se pretende probar
cada condición 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 propósito de verificar si se realizan de forma
correcta.
- Prueba de definición de datos.
Estas pruebas son realizadas con el objetivo de encontrar posibles contradicciones o
redundancias en la definición de los datos utilizados en el software. Para ello se
realiza un análisis del comportamiento de cada uno de los datos o cada una de los
flujos de ejecución.
21

2.3.2 Pruebas de caja negra.
Este tipo de pruebas, conocidas también como pruebas funcionales o pruebas de
comportamiento, concentran la atención 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 lógica 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 diseñan 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 aplicación 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 inicialización y terminación.
Estas son algunas de las pruebas más conocidas en este contexto:
- Partición equivalente.
La idea de esta técnica, es en dividir los valores válidos y no válidos para entradas y
salidas en un número reducido de particiones de forma que, el comportamiento del
software sea el mismo para cualquier valor contenido en una partición particular. El
propósito principal de una partición es reducir la cantidad de casos de prueba
generados en el proceso.
- Análisis de los valores límite.
La generación de casos de prueba en esta técnica, se enfoca en los valores limites,
esto bajo la consideración 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 mínimo, valores un poco
arriba del mínimo, valor máximo y valores un poco arriba del máximo.
22

- Pruebas según la experiencia (error guessing).
Este tipo de prueba la generación de casos se realiza a partir de la intuición y la
experiencia. La idea básica es redactar una lista de las posibles fallas o de las
posibles situaciones en las cuales suele ocurrir algún problema y así desarrollar casos
de prueba basados en la información contenida en estas listas.
- Tablas de decisión.
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 lógicos y (and), o (or) y no (not). Al involucrar aspectos
de lógica, se dice que este tipo de prueba se hace más rigurosa, que permite además
transformar una especificación en lenguaje natural en una especificación más 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 están 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
interacción con otras unidades. El propósito fundamental de una prueba de unidad es
23

descubrir diferencias entre la especificación del modulo de la interfaz y el
comportamiento efectivo.
• Pruebas de integración
Las pruebas de integración se realizan con el propósito 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 cómo 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 integración de las unidades para la prueba
puede realizarse siguiendo enfoques como el ascendente, descendente, big bang, o
sandwich.
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 también
aspectos relacionados con la integración del producto a otros sistemas.
• Pruebas de usabilidad.
El diseño de pruebas de usabilidad, requiere considerar a los usuarios que trabajan
con el producto, con el propósito 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 función.
Este tipo de pruebas tiene como objetivo detectar inconsistencias entre la
especificación funcional de un programa y su comportamiento actual.
24

• Pruebas de aceptación.
Realizando estas pruebas se puede comparar el producto final con las necesidades
finales de los los usuarios.
• Pruebas de regresión.
Las pruebas de regresión 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 aceptación es la metodología
orientada a objetos. Si bien es cierto que este nuevo enfoque ha sido adoptado por muchos, es
también cierto que estas personas han tenido que enfrentarse y adaptarse a cambios bastante
significativos. Conceptos como objeto, herencia y encapsulación marcan una nueva
perspectiva que contrasta con los modelos de desarrollo anteriormente utilizados.
Esta nueva percepción ha impedido que áreas de vital importancia, como la prueba de
software, no hayan alcanzado el desarrollo y la robustez que requieren. Es importante destacar
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 guías de acción para realizar esta
actividad.
Esta falta de trabajos quizá sea debida a la suposición y afirmación inicial de algunos
autores de que el software orientado a objetos, al tener como una característica esencial el
reuso, está propenso a presentar menos errores que el software construido usando las
metodologías 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 orientación a objetos han estado
presentes en los lenguajes de programación que se han utilizado; sin embargo la programación
orientada a objetos aparece formalmente durante la década de los 80, como una alternativa de
desarrollo de software que ofrece características muy atractivas: mejor modularidad en los
programas, mayor flexibilidad y una de las más significativas el reuso, característica nada
despreciable en ambientes de trabajo donde se requiere construir software en tiempos muy
cortos.
De acuerdo con [PER90], la programación orientada a objetos puede definirse como la
descripción de tareas en términos de los objetos que la misma tarea envuelve, así como de las
propiedades de dichos objetos.
A pesar de lo simple de la definición, se puede apreciar que un elemento muy
representativo en este modelo es el objeto. Profundizando sobre este tema, es posible decir
que la programación orientada a objetos gira en torno a dos conceptos: el objeto y la clase.
En los lenguajes de programación imperativos, los elementos más 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 definición formal de un objeto esta contenida en una clase a la que pertenece. Esta
definición contiene las características del objeto, las cuales se modelan en términos los
atributos, datos que el objeto utiliza, y los métodos que son las funciones que manipulan a
estos datos.
A continuación se presentan descripciones mas amplias de clase y objeto, que
permitirán tener una mejor comprensión de lo mencionado anteriormente:
26

Según [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 métodos del objeto.
Una clase describe el comportamiento común de un grupo único de objetos. Describe
todos los métodos y los atributos de esos objetos. Los objetos son creados mediante
la instanciación 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 públicas de la
clase,
2. un cuerpo de código que implementa las operaciones definidas en la interfaz, y
3. variables de instancia, las cuales implementan el estado del objeto.
Además de clase y objeto, existen otros conceptos relacionados con esta forma de
programación; encapsulación, polimorfismo y herencia, son algunos de los más destacables.
En la siguiente sección 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 propósito de garantizar su calidad. En términos 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 características del software orientado a objetos que generan
problemas adicionales no cubiertos por las técnicas tradicionales de prueba.
Existe una referencia común en [BIN95-A], [PER90] o [FER99], acerca de que la
unidad básica 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 característica importante del enfoque orientado a objetos es la encapsulación. Un
objeto encapsula su estado y sus funciones asociadas. La abstracción, concepto que define la
capacidad de solo destacar las características esenciales de un objeto de tal forma que se puede
separar su comportamiento esencial de su implementación, va estrechamente ligada con la
encapsulación. Indudablemente la posibilidad de poder encerrar dentro de un contenedor
físico o lógico 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 características esenciales, por ejemplo su estructura y la implementación de sus métodos,
hace que parte de un objeto sea inaccesible para el mundo. Naturalmente, esto obstaculiza la
eficiencia de las pruebas, ya que para realizarlas, en algún momento se requiere monitorear el
estado de un objeto. Esto es difícil de realizar con características como la encapsulación y la
abstracción, pues la dificultad de visualizar el estado interno del objeto impide consultar
información que podría requerirse para el desarrollo de la prueba. [BIN95-A].
Por otra parte, la herencia es otra de las características que han venido a facilitar en
gran medida el desarrollo de sistemas, la posibilidad de que una clase pueda ser escrita en
términos de variaciones de otras clases es una ventaja significativa. Puede pensarse que esto
apoya la prevención de fallas al construir software. Desgraciadamente, se ha comprobado que.
mediante esta práctica, se tienen muchas posibilidades de cometer errores, porque
28

generalmente los elementos heredados son sometidos a algún tipo de refinamiento o
redefinición y en algunos casos eliminación de componentes [FER99]. Cuando un objeto es
creado a partir de características 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
métodos heredados debe ser una regla más que una excepción.
La herencia en cierta medida trae como consecuencia reuso, lo que genera una
interrogante común con respecto a la formulación de las pruebas: las subclases de una clase
que ya ha sido probada ¿deben de ser probadas nuevamente?. Si la respuesta es sí, en
referencias como [PER90], se habla de diferentes niveles de herencia lo que incrementa el
número 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 número 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 cada vez que se realiza
una instancia diferente de un objeto como producto del polimorfismo en los métodos, se
requiere una prueba separada. Realizar una prueba separada para cada una de la formas de un
método es una tarea difícil, la complejidad y el tiempo requerido crece considerablemente
cuando se tienen que definir todos los posibles errores y obstáculos 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 operación 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 más significativos y de referencia común en
revisiones bibliográficas, de igual forma pueden mencionarse la dependencia de estado, el
29

desarrollo incremental, el manejo de excepciones, las invocaciones implícitas, el cambio de
tipo, las peculiaridades del lenguaje o la genericidad, las cuales pueden consultarse con mayor
detalle en [FER99].
2.5.3 Métodos de prueba de software orientado a objetos.
Se ha dicho en secciones anteriores que muchas de las generalidades de los métodos de
prueba tradicionales han sido adaptadas considerando las características del modelo orientado
a objetos, con el propósito 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 métodos robustos para
garantizar la realización de las pruebas de forma eficaz.
A continuación se presenta un panorama del estado actual en cuanto a prueba de
software orientado a objetos en términos 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 pequeña unidad trabaje correctamente en forma
aislada, antes de proceder a integrarla en el sistema.
Los métodos contenidos en una clase pueden ser muchos y una operación 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 diseñarla bajo ciertas consideraciones.
En este tiempo, no existe una práctica única de cómo 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. Además existen muchas posibilidades de que estos casos caduquen muy
rápido, 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 métodos son sometidos a la prueba, el orden
en que una jerarquía de clases puede ser probada, ejercitar el flujo de datos o bien el análisis
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, más aún, 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 método de la clase ejecute su responsabilidad especificada. Todo
esto se presenta en [BAS99] con mayor detalle.
Estas son algunas de las técnicas mas populares para realizar pruebas de unidad:
- Pruebas estructurales.
Si se tiene la disponibilidad de código fuente, pueden realizarse pruebas estructurales
a las unidades sometidas a la prueba. Las acciones de esta actividad pueden diseñarse
con el propósito de ejercitar todas las rutas del código, las condiciones establecidas o
bien las ciclos definidos en el programa.
- Prueba de valores limite.
Mediante esta técnica se prueba la unidad bajo situaciones inusuales o extremas, con
el propósito verificar cómo son manejadas por el software. Para ello, los casos de
prueba suministrados son diseñados considerando valores frontera, es decir los
31

valores mínimo y máximo que la unidad puede aceptar, así como también aquellos
valores cercanos a las fronteras identificadas.
- Prueba basada en estados.
Para esta técnica, se generarán casos de prueba para un contexto en donde una clase
se modela como una máquina 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 métodos necesarios para poder observar los cambios de
estado. La aplicación de esta técnica 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 bién, se produce un estado indefinido incorrecto .
- Prueba incremental.
La prueba incremental dirige su atención 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 estarían de más: cuando se han agregado o
modificado propiedades y/o métodos, cuando existen propiedades y métodos que se
han heredado y no se han alterado, pero que realizan algún tipo de interacción con
elementos nuevos o modificados.
2.5.3.2 Pruebas de integración.
Cuando se aplican pruebas de integración 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 interactúan y se integran con otras unidades
32

del sistema. Prácticamente, el trabajo de esta prueba se concentra en la interacción de métodos
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.
de otras clases.
En el enfoque basado en uso, se realizan pruebas para clases las cuales usan servicios
A continuación se presentan algunos métodos para realizar pruebas de integración:
- Método de Caminos de Mensajes.
Este método se concentra principalmente en probar aquellos caminos que se generan
por un evento de entrada y terminan con un evento de salida.
- El método de Overbek.
En este método se prueban las clases por pares, donde una hace el papel de cliente y
otra el de servidor, estableciéndose 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 además de lo anterior, si la clase cliente siempre satisface las precondiciones
de la clase servidora, así como también si satisface las salidas esperadas por la clase
servidora.
- El método de Kung.
Este método emplea una estrategia de ingeniería en reversa sobre el código de las
unidades con el propósito 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 acíclico, que puede contener varios
clusters de objetos y los ordenan topológicamente. Su método involucra las etapas de
pruebas de unidad y de integración y puede usarse también para pruebas de
regresión.
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 integración, se han generado pocos
trabajos, por lo que se emplean muchos de los métodos tradicionales.
- Prueba de función.
La prueba de función comúnmente es llevada a cabo por el grupo de personas que
desarrollaron el producto. Este enfoque se orienta a confirmar que la aplicación
alcanza los requerimientos y la funcionalidad especificadas por el usuario.
- Pruebas de aceptación (beta).
En este tipo de pruebas, versiones que aún no han sido liberadas en el mercado, son
ofrecidas a ciertos grupos de usuarios con el propósito de que las utilicen. El
propósito 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 número de usuarios.
Aplicando este enfoque, se puede verificar si el sistema se comporta como se espera
aún ante este tipo de escenarios.
34

2.6 Prueba de software basado en componentes.
La construcción de software a partir de componentes es una práctica relativamente
nueva, por lo que no es extraño 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 sección 3.2, como la
herencia, encapsulación, polimorfismo, liga dinámica o mecanismos de comunicación, son
comunes entre ambos modelos. Es evidente que para hacer las pruebas de componentes más
robustas, será necesario considerar las características propias del enfoque de componentes.
En la mayoría de los casos, los criterios de prueba de caja negra son los más aplicados
a los componentes, puesto que la disponibilidad del código fuente es nula en la mayoría de las
veces. Debido a que un componente es una unidad concreta, con una función bien definida, no
basta realizar pruebas para su evaluación; de igual forma se requieren procesos de prueba
para su selección y para su integración, [FER99] y [VOA98] .
Durante la etapa de construcción de un componente, el desarrollador puede aplicar las
técnicas de prueba de unidad y de integración tradicionales del modelo OO, sin embargo en lo
que respecta a la selección y evaluación, considerar el punto vista del usuario es un aspecto
vital para la realización de la prueba. Finalmente en el marco de pruebas de integración,
consideraciones como la arquitectura de la aplicación, el software intermediario y los modelos
de los componentes, deben agregarse a los criterios de evaluación.
2.6.1 Métodos de prueba de software basado en componentes.
Con el propósito de organizar algunas de las estrategias de prueba de componentes más
comunes, en las siguientes secciones se presenta una descripción de las mismas en los
términos que se presentaron para el enfoque orientado a objetos, de nivel unidad y nivel de
integración.
35

2.6.1.1 Pruebas de unidad.
Aunque la realización de pruebas de unidad es una actividad que en algún 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 máquinas virtuales de Java cada vez que se carga una clase.
Trusted Components, es un proyecto de investigación paras asistir a la industria de
construcción de software mediante librerías probadas de componentes. Las pruebas que se
aplican a los componentes se construyen bajo los combinación de varios enfoques como
diseño por contrato, como pruebas matemáticas, métricas, validación exhaustiva en proyectos
prácticos y manejo de cambios rigurosos.
2.6.1.2 Pruebas de integración.
Si las pruebas de nivel de unidad para componentes muestran severas carencias, en
nivel de integración, al igual que en otros enfoques de desarrollo, las carencias son aún más
notables. Sin embargo, existen coincidencias en cuanto a las problemáticas 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 código no sea necesario. Este
36

problema se agrava cuando se tienen sistemas grandes, afectándose así su
rendimiento.
- Los mecanismos de comunicación utilizados.
Se han presentado algunas contrariedades e inconsistencias al utilizar dentro de un
mismo sistema varios mecanismos de comunicación como eventos, mensajes o bien
el paso de parámetros.
37

Capítulo 3
Descripción del Diseño.
Una vez que se han abordado los fundamentos teóricos involucrados en el desarrollo
de este proyecto, en este tercer capítulo se presenta información referente al diseño 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
operación, su alcance y limitaciones. Posteriormente, se describirá la herramienta con base en
los módulos 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 construcción de software; actualmente está siendo adoptada por
muchos desarrolladores. Dentro de este entorno, se pueden encontrar una amplia gama de
elementos que asisten la construcción de este tipo de software, lenguajes como Pascal y C++,
que han sido adaptados con el fin de ofrecer capacidades de orientación a objetos, o bien
alternativas como Eiffel y una de las más recientes, Java, lenguaje que cada día es mas
utilizado.
Muy relacionada con la tecnología de objetos se tiene el desarrollo de software basado
en componentes. Actualmente la construcción de software basado en componentes está
convirtiéndose en una práctica que va ganando aceptación 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 términos 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 aceptación 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
característica muy destacable: el reuso, aspecto muy importante a considerar para realizar la
prueba. Cuando se realiza una prueba de software, este proceso la mayoría de las veces, se
lleva a cabo por el mismo desarrollador. Apoyándose en metodologías adecuadas, se pueden
obtener resultados significativos para determinar la calidad del software, sin embargo
convendría reflexionar un poco más sobre esto. El entorno considerado para la realización 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 operación
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
mayoría 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 programación, del cual analizando sus características, no es
difícil entender el porqué.
Java es un lenguaje de programación Orientado a Objetos, de propósito general, creado
por la compañía Sun Microsystems. Está parcialmente basado en C lo que facilita su
aprendizaje; quizás una de sus más atractivas ventajas es la independencia de software y
hardware que tienen las aplicaciones que con él se construyen. Dada esta característica,
cuando se crea una aplicación en Java para una plataforma específica, 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 máquina virtual
adecuada.
Cuando surge el modelo de desarrollo basado en componentes, al igual que ocurrió con
los objetos, algunas compañías ofrecen alternativas para la construcción de software en este
contexto. Tres de las más significativas se presentaron en el capítulo 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 más 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
métodos definidos para probarlo pueden ser aplicables a componentes, ya que estos son un
tipo de software muy parecido al orientado a objetos.
Aún ante la presencia de una afirmación de garantía 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 metodologías formales de prueba de software. Sin embargo, siendo
realistas, la mayoría de los usuarios finales carecen de estos conocimientos. Además, 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 difícil acceso a todos los métodos del
componente, obstaculiza que estos puedan ser sometidos a una prueba. En términos 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 código fuente.
Es cierto que el BeanBox puede considerarse como una herramienta con facilidades de
prueba, pues de manera implícita, 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 ejecución de métodos. 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 podría 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 métodos que no pueden ser directamente afectados
por el usuario, por lo que usando el BDK, no son fáciles de probar.
Todo esto nos permite pensar que se requiere contar con alternativas más 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 diseño.
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 información,
comparándolo con el de nivel de integración.
Para el diseño de la herramienta, se identificaron cuatro etapas determinantes:
a) La selección de unidades a ser probadas,
b) la generación de casos de prueba,
c) la ejecución del plan de prueba, y
d) la presentación de resultados.
Estas etapas se implementan en la herramienta como un conjunto de módulos con
funciones bien definidas y que guardan dependencias mínimas entre sí. La dependencia
principal radica en las salidas que generan, las cuales en algunos casos son utilizadas como
entradas para otros módulos. Esta estructura permite un enfoque similar al de desarrollo a
partir de componentes, de forma que se pueden realizar cambios y sustituciones de módulos
de acuerdo a las preferencias de los usuarios. Todos estos módulos son invocados desde un
modulo lanzador, ver Figura 3.1.
A continuación se presenta la descripción de cada uno de los módulos de la herramienta.
42

Usuario
de la
herramienta
L
a
n
z
a
d
o
r
Selección de los
componentes
Generador de Casos
de Prueba
Editor de Casos de
Prueba
Ejecutor de Casos
de Prueba II
Presentador de
Resultados II
Presentador de
Resultados I
Ejecutor de Casos
de Prueba I
Figura 3.1 Relaciones entre los módulos de la herramienta de prueba.
S3
S4
S5
S1
S2
S6
Salida a un
archivo de texto
43

3.3.1 Selección 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.
Además de las clases, para que funcione una aplicación, se pueden requerir otros elementos
tales como archivos de imágenes, de configuración o de ayuda. Esta situación se presenta
también en los componentes escritos con Java.
La mayoría de los componentes construidos bajo el modelo de Java Beans, contienen
los siguientes elementos:
a) Una o más clases definidas como Beans,
b) un archivo para su representación mediante un icono, y
c) una o más clases que no están 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 razón, 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 ejecución 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 propósito de que los procesos implementados para las pruebas puedan
ser aplicados a los componentes que el archivo contenga. Existen algunas consideraciones con
44

especto a los archivos JAR para que puedan ser correctamente manipulados por la
herramienta. Básicamente 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 válido, es decir pueda ser cargado y utilizado
correctamente en el BeanBox.
Las consideraciones respecto al contenido permiten que la herramienta pueda
disponer de unidades válidas para los procesos que realiza.
2. Con respecto a su función:
a) Que el usuario tenga una comprensión, al menos general, de la función que
realiza el componente.
La consideración respecto al contenido facilitan al usuario el análisis de los
resultados generados por los procesos que realiza la herramienta.
Las salida generada mediante la ejecución de este módulo 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 información se comunica al usuario mediante la interfaz del módulo. La
Figura 3.2, muestra una vista de lo que vería el usuario después de haber utilizado este
módulo.
45

Figura 3.2 El módulo apertura de archivos JAR.
3.3.2 La generación de casos de prueba.
La definición del plan, es un aspecto determinante para la efectividad de la prueba de
software, ya que los resultados obtenidos después de haberse realizado este proceso permitirán
tener ciertas directrices para calificar el comportamiento del elemento evaluado.
Las pruebas de unidad para software orientado a objetos establecen como unidad
elemental de evaluación a la clase, específicamente a una instancia de esta, un objeto,
dirigiendo especial atención a sus atributos y operaciones. De esta forma, una prueba ideal,
podría ser aquella en la que se consideraran a todos los métodos contenidos en la clase.
En el contexto de componentes, y en virtud de que el usuario experimenta con ellos,
generalmente no se dispone del código fuente, el enfoque que parece ser más 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 diseño de un plan de prueba deben
considerarse los siguientes puntos:
a) Establecer una relación entre caso de prueba y clase.
b) Establecer un propósito para la prueba.
c) Definir los pasos de la prueba considerando:
• una lista de estados iniciales de los objetos a probar,
• una lista de métodos 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
• información adicional, en caso que se requiera, con el propósito de ayudar
a realizar la prueba.
Teniendo en cuenta estos aspectos, la herramienta ofrece dos alternativas para la
generación de casos de prueba: casos generados de forma automática y casos administrados
por el usuario. A continuación se describen las generalidades de la generación automática de
casos de prueba.
De acuerdo con el objetivo, automatizar la realización de pruebas tanto como sea
posible, se ejecutarán 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 métodos contenidos en la clase que implementa el componente.
Existen métodos o funcionalidades del componente, de las que un usuario espera
comportamiento determinado en relación a una entrada suministrada. Teniendo en mente esto
y, atendiendo las consideraciones de la técnica de prueba de valores límite, los casos fueron
pensados bajo la premisa de que al suministrar valores a la frontera, es posible que pudieran
presentarse errores al ejecutarse un método.
47

Así mismo, se tomaron en cuenta algunas consideraciones de la prueba basada en
estados, con el propósito de presentar una descripción del estado de los objetos evaluados.
Esto se consideró necesario ya que pueden existir situaciones en la que la ejecución de un
método ocurre sin ningún contratiempo, sin embargo el estado final del componente no es el
esperado. Específicamente se inspecciona el estado inicial y final del componente, con
respecto a la ejecución de un método.
Es importante mencionar que, aunque son técnicas validas y eficientes para evaluar
componentes, mediante su aplicación no es posible garantizar que todas las líneas de código
que contiene un método se ejerciten; esto se debe tener presente al diseñar los casos de prueba
y la cobertura de los mismos.
Cuando un método se invoca suceden varias cosas: el método toma los parámetros de
entrada, los combina con las variables de instancia, ejecuta el código 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 método, las cuales
han sido identificadas mediante la revisión de sus parámetros. Estas pueden presentarse como:
a) Argumentos que consisten en tipos definidos en Java, como un int, char,
Object, Color, etc., o bien,
b) La invocación de un objeto externo, específicamente 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 generación de casos de prueba, también se decidió someter a
la unidad a condiciones muy simples, generado así también casos de prueba con estas
características. Los valores establecidos para la generación 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 métodos contenidos en la clase, sin embargo
este objetivo puede verse impedido ante la presencia de parámetros no considerados en la
herramienta, o bien cuando se presentan problemas al hacer referencia a objetos externos.
Con el propósito de atacar esta debilidad, se ha implementado un mecanismo que
permite a este módulo cargar “Plug-ins” definidos por el usuario. Este mecanismo consiste
básicamente de un archivo que contiene valores de prueba para el nuevo argumento y la
inclusión del constructor correspondiente dentro de una clase especial.
Los casos de prueba generados por este módulo son almacenados en un archivo de
texto. Mediante la interfaz de este módulo, se informa al usuario el número de métodos
contenidos en la clase, el número de métodos para los cuales se generaron casos de prueba, el
número de métodos para los que no se generaron casos de prueba y el número de métodos que
no reciben ningún tipo de argumento, ver Figura 3.3.
Figura 3.3 El módulo generador de casos de prueba.
De igual forma, este módulo genera un segundo archivo de salida con el propósito de
que, posteriormente, el usuario, pueda utilizarlo para almacenar los casos que él plantea
49

mediante el módulo de edición 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
modificación alguna.
3.3.3 La ejecución de casos de prueba.
Una vez que han sido generados los casos de prueba para un Bean, ya sea de forma
automática o de forma manual, la siguiente actividad consiste en alimentar dichos casos de
prueba a los módulos correspondientes para que sean ejecutados, así como también capturar
las salidas generadas como producto de esta serie de ejecuciones. Estas son las tareas que
realizan los dos módulos ejecutores disponibles, uno de ellos que ejecuta los casos generados
de forma automática 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 métodos
contenidos en la clase al menos una vez, pueden existir métodos que se ejecuten más de una
vez, al igual que métodos que pasen desapercibidos durante esta etapa, como consecuencia del
número de casos de prueba generados para cada método en el módulo anterior. De esta forma,
se ejercitan los métodos 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 método y,
b) los mecanismos de excepción.
Por tratarse de software orientado a objetos, es conveniente hacer más profunda la
revisión y manejo de las salidas obtenidas, pues en ocasiones una salida correcta, no implica
que el estado interno de un componente lo sea también. Con este propósito, 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 representación
de los datos miembros y la forma en que los métodos están manipulando la representación del
objeto, con el propósito 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 válidos después 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 básicamente en la generación del pre-estado del objeto sobre el cual el
método actúa y la generación del post-estado resultante. Se está suponiendo el estado del
objeto como la colección de valores de las propiedades del Bean en un momento dado,
accesibles mediante mecanismos del propio Bean.
Los módulos ejecutores de casos de prueba operan de forma individual y, al término de
la ejecución de cualquiera de estos, se dispone de un archivo de texto que almacena los
resultados obtenidos.
De igual forma en ambos módulos, mediante la interfaz del usuario se presenta un
resumen que informa la cantidad de métodos en la clase, la cantidad de métodos para los
cuales se ejecutaron casos de prueba y la cantidad de métodos para los cuales no se generaron
casos de prueba. En la Figura 3.4, se presenta la interfaz de uno de los módulos después de
haberse ejecutado un serie de casos de prueba.
51

Figura 3.4 El módulo ejecutor de casos de prueba.
3.3.4 La Presentación de resultados.
En la herramienta existen tres módulos que permiten al usuario visualizar los
resultados generados después de haberse realizado el proceso de prueba.
Dos de los módulos, describen primordialmente el resultado obtenido a partir de la
prueba realizada al componente. Recordando que pueden existir dos grupos de casos de
prueba, los que genera la herramienta automáticamente y los definidos por el usuario, existe
un módulo para presentar los resultados generados por cada una de estas dos modalidades,
exponiéndose en ambos la siguiente información:
a) Nombre de la clase evaluada.
b) Para cada método contenido en la clase:
• Descripción de los argumentos del método.
• Descripción de valor de retorno del método.
• Total de casos de prueba generados.
c) Para cada caso de prueba generado:
• Detalle de los valores del caso de prueba.
• Estado del componente antes de ejecutarse el caso de prueba.
52

• Estado del componente después de ejecutarse el caso de prueba.
Todo esto se aprecia con mayor detalle en la Figura 3.5.
Figura 3.5 El módulo que presenta los resultados de la prueba.
53

El segundo módulo denominado información interna, presenta información referente a
la implementación de la clase. Para ello se consideran los siguientes datos:
a) Para cada variable:
• El nombre.
• El tipo.
b) Número de métodos en la clase.
c) Para cada método:
• El nombre del método.
• Descripción de sus argumentos de entrada.
• Descripción sobre su valor de retorno.
La Figura 3.6, presenta lo descrito anteriormente.
Como ya se ha mencionado, las salidas generadas por estos módulos, permiten al
usuario obtener algunas de las directrices necesarias para la selección y evaluación de los
componentes. Estas directrices pueden obtenerse cuando se presentan algunas de estas
situaciones:
- Cambios de estado del componente, específicamente en el valor de sus
propiedades.
- Excepciones generadas a partir de la ejecución de un método.
- Análisis de los casos de prueba, lo que permite identificar a qué obedece
determinado comportamiento de la componente.
- Análisis de los métodos y variables, lo que permite obtener directrices orientadas
a métricas de software.
- Total de métodos probados.
- Total de casos de prueba generados para cada método.
- Total de métodos no ejercitados.
54

Figura 3.6 El módulo de información interna.
55

Capítulo 4
Descripción de la Arquitectura e Implementación.
En el capítulo anterior se presentaron aspectos relacionados con los principios de
diseño y la metodología utilizada para la construcción de la herramienta; este capítulo se
concentra en los detalles referentes a su implementación.
En las siguientes secciones se describen cada una de las clases que conforman la
herramienta y la funcionalidad que estas proveen. Con este propósito apoyándose en notación
en UML, inicialmente se presenta un diagrama de colaboración entre clases, a partir del cual
se podrá obtener una vista general de la arquitectura del sistema, para posteriormente, abordar
cada una de estas de forma más precisa.
4.1 Arquitectura y colaboración entre clases.
PACJavaBeans está desarrollada en Java 1.2.2. De esta forma, su implementación
consiste de un conjunto de clases, las cuales proporcionan determinados servicios con el
objetivo de llevar a cabo el proceso de prueba de componentes.
Durante el capítulo anterior se hizo hincapié en que, durante su diseño, se identificaron
ciertas actividades primordiales: la identificación de las unidades a ser probadas, la
generación de casos de prueba, la ejecución del plan de prueba y la presentación de
resultados. De forma general, puede decirse que para llevar a cabo cada una de las actividades
anteriormente citadas, se implementó una clase en Java. En la Figura 4.1 se presentan
gráficamente estas clases, sus métodos más importantes y sus relaciones de colaboración .
Como se mencionó en el capítulo 3 y se aprecia en la Figura 4.1, las relaciones entre
las clases que conforman a la herramienta radican primordialmente en la referencia a archivos
de texto específicos para cada uno de los casos. Estos archivos se generan a partir del trabajo
realizado por alguna otra clase.
56

La clase PACAbre corresponde a la actividad de identificación de la unidades a ser
probadas, específicamente a la extracción de archivos JAR. Esta clase genera como salida el
archivo de texto “beans.txt”, el cual almacena los nombres de los Beans contenidos en el JAR.
Este archivo lo utiliza posteriormente la clase PACGenera.
PACGenera implementa los procesos necesarios para generar los casos de prueba para
cada uno de los métodos contenidos en el Bean. Estos casos se almacenan en el archivo de
texto “casos.txt”. Con la intención de que el usuario pueda proponer sus propios casos de
prueba, la clase PACGenera crea un segundo archivo de salida, denominado “casosp.txt”, el
cual puede utilizarse posteriormente para almacenar este tipo de casos.
La clase PACEjecuta toma los casos de prueba del archivo “casos.txt” y los ejecuta.
Los resultados obtenidos a partir de la ejecución de estos casos se guardan en el archivo
“resultados.txt”, el cual es utilizado posteriormente por la clase PACResumen con el propósito
de presentar al usuario la información generada a partir del proceso de prueba realizado.
De forma similar, la clase PACEjecuta2 ejecuta los casos de prueba proporcionados
por el usuario, mismos que están almacenados en el archivo “casosp.txt”. Los resultados
obtenidos a partir de esta actividad se guardan en el archivo “resultadosp.txt”, el cual utiliza
posteriormente la clase PACResumen2 que informa los resultados obtenidos.
En la figura 4.1 se puede apreciar de igual forma la presencia de otras clases:
PACLanzador PACIInterna y PACAcerca. La clase PACLanzador, es una clase que se
implementó con el propósito de contar con un mecanismo para administración de los procesos
que se generan al ejercitar cada una de las clases de la herramienta. La clase PACLanzador
funciona como un programa lanzador de aplicaciones con el cual el usuario puede invocar los
servicios de las clases restantes.
En los que respecta a la clase PACAcerca, se construye para ofrecer la información
tradicional de los autores de la herramienta.
58

A continuación se presenta una descripción sobre la implementación de cada una de las
clases de la Figura 4.1.
4.1.1 La invocación de los servicios.
Como ya se ha mencionado, PACJavaBeans ofrece al usuario los servicios de: apertura
de archivos JAR, generación automática de casos de prueba, edición de casos de prueba por el
usuario, ejecución de los casos de prueba generados de forma automática, ejecución de los
casos de prueba proporcionados por el usuario y presentación de resultados. Adicionalmente,
proporcionan servicios como Limpieza del Entorno de Trabajo y Acerca de. La clase
PACLanzador es la encargada de proveer los mecanismos necesarios para la invocación de
estos servicios. Los detalles de los atributos y los métodos de esta clase se presentan en la
Figura 4.2.
PACLanzador
JFrame
void invocaModuloPACAbre()
void invocaModuloPACGenera()
void invocaModuloPACGeneraU()
void invocaModuloPACEjecuta()
sdsd
void invocaModuloPACEjecutaU()
void invocaModuloPACResumen()
void invocaModuloPACResumenU()
void invocaModuloPACIInterna()
void invocaAccionesLimpiar()
void invocaAccionesAcerca()
void preparaEntorno()
boolean existeArchivo (String archivo)
boolean borraArchivo (String archivo)
Runtime rt
Process proceso
ImageIcon icono
JButton botonAbre, botonGenera, botonGeneraU, botonEjecuta
JButton botonEjecutaU, botonResultados, botonResultadosU
JButton botonIInterna, botonLimpiar, botonAcerca
Figura 4.2 La clase PACLanzador.
59

La clase PACLanzador implementa un contenedor que reúne un conjunto de botones
que el usuario puede presionar con el propósito de invocar alguno de los servicios
anteriormente mencionados. Para ello es necesario que esta clase haga uso de algunas de las
funcionalidades de la clase JFrame de Java.
Los servicios se representan como un conjunto de procesos que corren de forma
individual y bajo cierto orden. Así mismo, algunos de los procesos requieren de determinadas
condiciones para que puedan ejecutarse, las cuales consisten primordialmente en la existencia
de un archivo de entrada específico.
El constructor esta clase, PACLanzador(), contiene las instrucciones necesarias para
realizar las siguientes tareas: establecimiento del entorno inicial de operación, creación y
presentación en pantalla del contenedor e invocación del método correspondiente al botón
presionado por el usuario.
El establecimiento del entorno inicial de operación consiste en eliminar toda aquella
información que pudiera haberse generado por sesiones de prueba anteriores, utilizándose así
los métodos void preparaEntorno(), boolean existeArchivo(String archivo) y boolean
borraArchivo(String archivo).
Una vez creado el ambiente inicial, el constructor ejecuta las instrucciones necesarias
para la creación y despliegue del contenedor. Inicialmente los únicos botones activos en el
contenedor son el de Apertura de Archivos Jar y el de Acerca de. Si se presiona alguno de
estos botones, el método constructor realiza una llamada a un método especifico de un
conjunto especial, estos tienen la característica de que sus nombres inician con el prefijo
invocaModulo. Por ejemplo, si se presiona el botón Apertura de archivos JAR, el flujo del
sistema pasa al método invocaModuloPACAbre(), el cual contiene la instrucciones necesarias
para la creación y administración del proceso que representará al módulo PACAbre.
Conforme se utilizan los servicios ofrecidos por la herramienta para la prueba del
Bean, se puede observar que diferirá el tipo y número de botones activos en el contenedor. De
60

esta forma, y continuando con el paso anterior, si las acciones del modulo PACAbre se
realizaron de forma exitosa, ya no se tendrá activo en el contenedor el botón Apertura de
Archivos Jar; en lugar de este, se activará el botón Generar Casos de Prueba, que
correspondería a la siguiente etapa del proceso de prueba.
Así, void invocaModuloPACGenera(), void invocaModuloPACGeneraU(), void
invocaModuloPACEjecuta(), void invocaModuloPACEjecutaU(), void
invocaModuloPACResumen(), void invocaModuloPACResumenU() y void
invocaModuloPACIInterna() son los métodos que atienden y administran los procesos
correspondientes a las actividades representadas por los botones Generar Casos de Prueba,
Editar Casos de Prueba, Ejecutar Casos de Prueba, Ejecutar Casos Editados, Ver Resultados,
Ver Resultados CE y Ver Información interna respectivamente
Mediante el botón Limpiar, el usuario puede establecer el entorno inicial en el
momento que lo disponga, incluso aún sin haberse llevado a cabo todas las etapas del proceso
de prueba. Esto se realiza por medio del método void invocaAccionesLimpiar().
El método que atiende al boton Acerca de es void invocaAccionesAcerca(). Este
contienen las instrucciones necesarias para el despliegue de la información tradicional
manejada para este concepto.
4.1.2 La extracción de archivos JAR.
Para que la prueba pueda iniciarse, es necesario conocer y disponer de las unidades que
pueden ser sometidas a este proceso a partir de un archivo JAR. Esto es posible utilizando los
servicios de las clases PACAbre, SimpleFilter y UNzip. Los detalles sobre los atributos y
métodos de estas clases se presentan en la Figura 4.3.
61

La clase PACAbre hereda los servicios de la clase JFrame proporcionada por Java, de
esta forma se pueden utilizar sus métodos para la implementación de la interfaz del módulo, la
cual se genera mediante el constructor PACAbre().
La interfaz implementada por el método PACAbre() consiste fundamentalmente en un
JFileChooser para seleccionar archivos JAR en las unidades de disco del sistema y un botón
que permite, una vez que se ha seleccionado un archivo JAR, iniciar el proceso de extracción.
Con el propósito de ofrecer funcionalidades del filtrado de archivos JAR en el JFileChooser,
se utilizan los servicios de la clase SimpleFilter. Ambas clases son parte de Java.
Cuando el usuario ha seleccionado el archivo JAR, se procede a extraer su contenido.
Para esto se utilizan la clase UNzip, la cual provee este tipo de funcionalidad.
Si las acciones para la extracción del contenido del archivo JAR se llevaron a cabo de
forma adecuada, el método leeManifest() realiza la lectura del archivo MANIFEST.MF con el
propósito de identificar cuales clases disponibles corresponden a JavaBeans. El nombre de los
archivos con la característica “Java-Bean = true”, se almacenan en un Vector para
posteriormente almacenar su contenido en el archivo “beans.txt”. Este procedimiento lo lleva
a cabo el método guardaJavaBeans().
Los resultados obtenidos a partir de la realización de estas actividades, se despliegan
en la interfaz del módulo con el propósito de que el usuario pueda conocerlos.
El diagrama que se presenta en la Figura 4.4, muestra gráficamente las actividades
descritas anteriormente.
62

javax.swing.filechooser.FileFilter
SimpleFilter
SimpleFilter (String extension, String description)
String getDescription()
boolean accept (File f)
String m_description
String m_extension
PACAbre
JFrame
PACAbre()
void invocaAcciones()
Vector leeManifest()
boolean guardaJavaBeans()
JTextArea areaTexto
JFileChooser archivoSel
JTextField unNombreJar
Vector vecBeanClases
UNzip
UNzip (String xnombreJar)
boolean unzipArchivo()
File creaJarElemento ( String name )
copiaContenido (InputStream archFuente, File archDestino)
boolean archVacio
String compacArchivo
String archDestinoDir
Figura 4.3 Las clases PACAbre, SimpleFilter y UNzip.
63

Esperar llegada
de evento
Identificar
evento
Extraer Archivo
JAR
[evento del botón Salir]
[evento del botón Abre]
[exito]
Identificar Beans
[si hay Beans]
Generar archivo
beans.txt
[exito]
Informar exito
[fracaso]
[no hay Beans]
[fracaso]
Informar la razón
del fracaso
Figura 4.4 Diagrama de actividades de la clase PACAbre.
4.1.3 La generación de casos de prueba.
La clase PACGenera utiliza el archivo de texto “beans.txt”, que creó la clase
PACAbre, y realiza las actividades necesarias para la generación automática de los casos de
prueba. Los métodos y los atributos de la clase PACGenera se presentan en la figura 4.5.
La clase PACGenera extiende a la clase de Java JFrame, puesto que los servicios de
esta última se utilizan para definir la interfaz del módulo.
Ya se ha mencionado que el punto de partida para que la clase pueda realizar sus
actividades es el archivo “beans.txt”; utilizando su contenido, el método obtenBeans() obtiene
los nombres de los Beans identificados, con el propósito de presentarlos en la interfaz del
64

módulo dentro de un JcomboBox. De este, el usuario puede seleccionar la clase que desea
someter al proceso de prueba.
PACGenera
PACGenera ()
void invocaAcciones ()
Vector obtenBeans ()
boolean verMetodos ()
void iniciaGeneracion ()
public boolean generaCasos(String xmetodoNombre,Class[] xmetodoArgs, boolean xesProp)
void almacenaCasos (String xmetodoNombre ,Vector xvectorCasos)
void almacenaCasosP (String xmetodoNombre ,Vector xvectorCasos)
iniciaVectores (Vector xvectorBoolean, Vector xvectorChar, ...)
String procesaArgs (Class[] xmetodoArgs)
Vector obtenPlugInValores (String xplugIn)
Vector procesaPlugInValores (Vector xvectorInicio, Vector xvectorCasos, String xplugIn )
Vector cargaPlugIns ()
JTextArea areaTexto;
String laClase;
MethodDescriptor[] metodosBean;
MethodDescriptor metodosDescriptor;
Vector vectorPlugIn;
Vector vectorCasos;
JFrame
Figura 4.5. La clase PACGenera.
Una vez que se ha seleccionado un Bean de la lista y se indicó iniciar el proceso de
generación de casos de prueba mediante el botón de la interfaz, la siguiente actividad consiste
en aplicar un proceso de introspección a la clase, con el propósito de conocer cuáles son los
métodos que esta contiene. Esto se hace usando el método verMetodos().
Si existen métodos en el Bean, situación que se espera, se procede a preparar los
elementos indispensables para la generación de casos. Para ello primeramente se cargan en el
sistema los Plug-Ins. Este conjunto de archivos, cuya característica es tener la extensión
“.pin”, están localizados en el directorio /PlugIns, el método cargaPlugIns() lleva a cabo esta
65

actividad. También se procede a crear los archivos “casos.txt” y “casosp.txt” por medio del
método iniciaGeneracion(). El primero almacenará los casos de prueba generados en forma
automática y el segundo que almacenará los casos de prueba propuestos por el usuario.
Para cada método del conjunto obtenido por el método verMétodos() se realiza un
análisis de sus argumentos. De esta forma, si el método recibe argumentos, se realiza la
llamada al método public boolean generaCasos(String xmetodoNombre,Class[] xmetodoArgs,
boolean xesProp), que se encargara de realizar el proceso de generación del o los casos de
prueba para dicho método.
La primera actividad para el proceso de generación de casos consiste en verificar si los
argumentos del método en turno son conocidos por el sistema, pues solo de ser así el proceso
puede continuar. De ser así, si el método corresponde a una propiedad, el método
almacenaCasosP (String xmetodoNombre), se encarga de escribir parcialmente el archivo
“casosp.txt”. Para ello, se escribe el encabezado del método en turno –valor de retorno,
nombre y argumentos- y un terminador especial. Posteriormente, se realizan las acciones
necesarias para generar los casos de prueba. Cuando el proceso de generación ha concluido, el
método almacenaCasos (String xmetodoNombre ,Vector xvectorCasos) guarda los casos
generados en el archivo “casos.txt”.
interfaz.
Los resultados obtenidos por las actividades que realiza el módulo se despliegan en su
El diagrama que describe las actividades que realiza el módulo que implementa la
clase PACGenera se presenta en la Figura 4.6.
66

Leer los nombres de
Beans del archivo
beans.txt
[exito]
Desplegar
nombres en la
interfaz
[fracaso]
[no recibe argumentos]
Almacenar
casos en archivo
casos.txt
Espera llegada
de evento
[evento del botón Salir]
Cargar
Plug-Ins
Crear archivo
casosp.txt
Crear archivo
casos.txt
Tomar método
Verificar
argumentos
[argumentos desconocidos]
[existen métodos]
[no hay metodos por evaluar ]
[hay metodos por evaluar ]
[recibe argumentos]
Generar casos
de prueba
Identificar
evento
Obtener los
Métodos del Bean
[argumentos conocidos]
[evento del botón Genera]
Escribir en
archivo
casosp.txt
[no existen métodos]
Informar
Resultado
[no es Propiedad]
[es Propiedad]
Figura 4.6 Diagrama de actividades de la clase PACGenera.
4.1.4 La ejecución de casos de prueba generados automáticamente.
Informar
Fracaso
La ejecución de estos casos de prueba consiste fundamentalmente en la lectura de los
casos generados automáticamente y su ejecución. Estas actividades son llevadas a cabo por la
clase PACEjecuta con la asistencia de los servicios proporcionados por la clase PlugIn. La
figura 4.7, muestra los detalles de implementación de estas clases.
Cuando el usuario inicia el proceso de ejecución de casos presionando el botón
provisto en la interfaz del módulo, la primera actividad que se realiza es llevada a cabo por el
método cargaPlugIns(), el cual permite al módulo conocer cuáles son los tipos de argumentos
adicionales que deben considerarse para la ejecución de los casos de prueba.
67

PACEjecuta
PACEjecuta()
Vector obtenClase()
void ejecutaMetodos()
void cargaPlugIns ()
void recuperacion()
Vector leeArchivoCasos (String xmetodoInfo)
String verBeanPropiedades (BeanInfo xbeanInformacion, Object xbeanObjeto)
void almacenaResultados (String xmetodoInfo, Vector xvecResulta)
void almacenaRegistro (int xiMetodos)
Object [] generaArgsContenido (Class [] xmetodoArgs, Object objetoCaso, Vector xvectorPlugIn)
Object creaBean()
String procesaArgs (Class[] xmetodoArgs)
JTextArea areaTexto
String laClase = null
Vector vecResulta = new Vector()
Vector vectorPlugIn
MethodDescriptor[] metodosBean
MethodDescriptor metodosDescriptor
PlugIn
JFrame
PlugIn ()
Object creaPlugInValor(String plugIn, String valor)
Object objVal
Figura 4.7 Las clases PACEjecuta y PlugIn.
La siguiente actividad consiste en ejecutar una rutina que permite a la herramienta
recuperarse de fallos ocurridos durante un proceso de ejecución previo. De esta forma, el
método recuperación() revisa si el proceso de ejecución previo es el mismo que el que ahora
se pretende iniciar y si es así, verifica si el proceso anterior se terminó adecuadamente. El
objetivo de esta rutina de recuperación es establecer un método de partida para iniciar la
ejecución de casos, el cual puede ser el primer método de la clase, si no hubo un fallo previo o
68

se trata de una nueva clase, o bien, el método que le sigue al último método que se ejercitó en
el proceso anterior. El método recuperación() utiliza la información contenida en el
archivo“registro.txt”
Una vez establecido el método a partir del cual se iniciará el proceso de ejecución, se
crea el archivo “resultados.txt” que se utiliza para almacenar la información arrojada por este
proceso.
Puesto que para diseñar las pruebas se consideraron algunos aspectos de la técnica
basada en estados, es necesario almacenar el estado inicial del Bean (esta información se
utiliza en el módulo de presentación de resultados). Para llevar a cabo esto, se crea una
instancia del Bean mediante el método creaBean(), se aplica un proceso de introspección
sobre la instancia mediante el método verBeanPropiedades (BeanInfo xbeanInformacion,
Object xbeanObjeto), se crea el archivo “estadoi.txt” y se almacenan en él los nombres y
valores de cada una de las propiedades del Bean.
La ejecución de casos llevada a cabo por el método ejecutaMetodos() se realiza de
forma similar al proceso de generación descrito en la sección anterior. Inicialmente se obtiene
el conjunto de métodos implementados en la clase y para todos aquellos que reciben
argumentos, el método Vector leeArchivoCasos (String xmetodoInfo) realiza la búsqueda de
los casos correspondientes en el archivo “casos.txt”, los cuales regresa en un Vector.
Ya que se dispone de los casos de prueba que le corresponden al método, para cada
uno de estos se realizan las siguientes acciones: se crea nuevamente una instancia del Bean
con el método creaBean(), se ejercita el método con el caso de prueba en turno, se obtiene el
valor de las propiedades del Bean, se almacenan los resultados en el archivo “resultados.txt” y
se almacena el número del método ejercitado en el archivo “registro.txt”. Estas dos últimas
actividades son llevadas a cabo por los métodos almacenaResultados (String xmetodoInfo,
Vector xvecResulta) y almacenaRegistro (int xiMetodos) respectivamente.
69

La figura 4.8, muestra el diagrama de actividades de la clase PACEjecuta.
Esperar llegada
de evento
Almacenar estado
inicial
[evento del botón Ejecutar]
Identificar evento
Cargar Plug-Ins
Ejecutar rutina
de recuperación
Crear Bean
Obtener los
metodos del Bean
Tomar método
Crear Bean
Ejecutar método
con Caso de
Prueba
[evento del botón Salir]
[hay métodos por ejecutar]
[hay errores anteriores]
[no hay errores anteriores]
Crear archivo
resultados.txt
Verifica
argumentos
[no hay métodos por ejecutar]
[no recibe argumentos]
Obtener estado
Final
Almacenar en
resultados.txt
Almacenar en
registro.txt
Establecer método
de partida
[recibe argumentos]
Obtener casos de
prueba del archivo
casos.txt
Figura 4.8 Diagrama de actividades de la clase PACEjecuta.
4.1.5 La ejecución de casos de prueba generados manualmente.
Informar
resultados
La clase PACEjecuta2 se encarga de la ejecución de casos de prueba generados
manualmente por el usuario. El proceso que lleva a cabo esta clase es muy similar al descrito
anteriormente. La figura 4.9, muestra los detalles de implementación de PACEjecuta2.
70

PACEjecuta
PACEjecuta()
Vector obtenClase()
void ejecutaMetodos()
void cargaPlugIns ()
Object creaBean()
Vector leeArchivoCasos (String xmetodoInfo)
Object [] generaArgsContenido (Class [] xmetodoArgs, Object objetoCaso, Vector xvectorPlugIn)
String verBeanPropiedades (BeanInfo xbeanInformacion, Object xbeanObjeto)
void almacenaResultados (String xmetodoInfo, Vector xvecResulta)
String procesaArgs (Class[] xmetodoArgs)
JTextArea areaTexto
String laClase = null
Vector vecResulta = new Vector()
Vector vectorPlugIn
MethodDescriptor[] metodosBean
MethodDescriptor metodosDescriptor
Figura 4.9 Las clases PACEjecuta2 y PlugIn.
Como puede observarse, muchos métodos que se describieron en la sección anterior están
presentes en esta clase. De hecho, las variaciones que presenta esta clase consisten en:
a) El archivo de entrada que utiliza la clase para ejecutar los casos, el cual es ahora el
archivo “casosp.txt”.
b) Se ha omitido el proceso de recuperación, y por consiguiente, la escritura del archivo
de “registro.txt”
PlugIn
PlugIn ()
Object creaPlugInValor(String plugIn, String valor)
Object objVal
JFrame
71

c) No se almacena el estado inicial del Bean, ya al llegar a esta etapa, el archivo
“estadoi.txt” debe haber sido ya creado.
d) El archivo de salida que almacena los resultados obtenidos se llama “resultadosp.txt”.
e) Los métodos ejercitados son únicamente los que corresponden a propiedades.
La figura 4.10, muestra el diagrama de actividades de la clase PACEjecuta2.
Esperar llegada
de evento
[evento del botón Ejecutar]
Identificar evento
Cargar
Pluig-Ins
Crear archivo
resultadosp.txt
Crear Bean
Obtener los
metodos del Bean
Tomar método
[evento del botón Salir]
[hay métodos por ejecutar]
[no es propiedad “set”]
[no hay métodos por ejecutar]
[es propiedad “set”]
Obtener casos de
prueba del archivo
casosp.txt
Ejecutar método
con Caso de
Prueba
Obtener estado
Final
Almacenar en
resultadosp.txt
Informar
resultados
Figura 4.10 Diagrama de actividades de la clase PACEjecuta2.
72

4.1.6 La presentación de resultados.
En el capítulo anterior se indicó que la herramienta cuenta con tres módulos que
permiten presentar resultados al usuario; estos corresponden a las clases: PACResumen,
PACResumen2 y PACIInterna.
Las funcionalidades que ofrecen las clases PACResumen y PACResumen2 consisten
en presentar los resultados generados por las actividades realizadas por los procesos de
prueba. La interfaz de los módulos que implementan estas clases, presentan la información
bajo un formato de árbol.
Para ello fue necesario que, tanto PACResumen como PACResumen2, heredaran las
funcionalidades de la clase JFrame de Java, así como utilizar los servicios de la clase
DefaultTreeCellRenderer, esta última ofrece facilidades para relacionar iconos con nodos y
hojas de un JTree.
En ambas clases se tiene un método denominado void leeArchivoResultados(), el cual
obtiene, ya sea del archivo “resultados.txt” o “resultadosp.txt”, la información generada por el
proceso de ejecución de casos de prueba. Esta información es almacenada en un Vector que
posteriormente es utilizado para la generación del árbol. Con el propósito de mostrar el estado
inicial del Bean, a partir del cual se aplica el proceso de prueba, el método void
leeArchivoEInicial(), presenta esta información utilizando para ello archivo “estadoi.txt”.
Las figuras 4.11. y 4.12, muestran la implementación de estas clases y el diagrama de
actividades para la clase PACResumen. Las figuras 4.13. y 4.14, presentan lo correspondiente
a la clase PACResumen2.
Por otra parte, la clase PACIInterna tiene el propósito de mostrar al usuario detalles
sobre la implementación del Bean. Para ello. el método String obtenClase() busca dentro del
archivo “resultados.txt” el nombre de la clase a inspeccionar. Posteriormente el método
beanIntrospeccion(String laClase), realiza las tareas de introspección con este propósito,
73

generándose así el conjunto de datos que se presentarán en el módulo. De igual forma que en
PACResumen y PACResumen2, se hace uso de una estructura de árbol para presentar la
información.
PACResumen
PACResumen()
leeArchivoResultados()
void leeArchivoEInicial()
JFrame DefaultTreeCellRenderer
Vector vectorResultados
Vector vectorEInicial
JTree tree
DefaultTreeModel treeModelo
DefaultMutableTreeNode nodoClase;
DefaultMutableTreeNode nodoC;
DefaultMutableTreeNode nodoMetodo;
DefaultMutableTreeNode nodoCaso;
Figura 4.11 La clases PACResumen y resRenderer.
Lee archivo
estadoi.txt
Lee archivo
resultados.txt
Organiza
información
Presenta
información
resRenderer
Component getTreeCellRendererComponent()
boolean esClase(Object value)
boolean esMetodo(Object value)
boolean esCaso(Object value)
esExcepcion(Object value)
esError(Object value)
ImageIcon clase
ImageIcon metodo
ImageIcon caso
ImageIcon propiedad
ImageIcon error
ImageIcon exepcion
Figura 4.12 Diagrama de actividades de la clase PACResumen.
74

PACResumen2
PACResumen()
void leeArchivoResultados()
void leeArchivoEInicial()
JFrame DefaultTreeCellRenderer
Vector vectorResultados
Vector vectorEInicial
Vector vectorNodos
JTree tree
DefaultTreeModel treeModelo
DefaultMutableTreeNode nodoClase;
DefaultMutableTreeNode nodoC;
DefaultMutableTreeNode nodoMetodo;
DefaultMutableTreeNode nodoCaso;
Figura 4.13 La clases PACResumen y respRenderer.
Lee archivo
estadoi.txt
Lee archivo
resultadosp.txt
Organiza
información
Presenta
información
respRenderer
Component getTreeCellRendererComponent()
boolean esClase(Object value)
boolean esMetodo(Object value)
boolean esCaso(Object value)
boolean esExcepcion(Object value)
boolean esError(Object value)
ImageIcon clase
ImageIcon metodo
ImageIcon caso
ImageIcon propiedad
ImageIcon error
ImageIcon exepcion
Figura 4.14 Diagrama de actividades de la clase PACResumen2.
75

Las figuras 4.15. y 4.16, muestran la implementación de la clase PACIInterna y el
diagrama de actividades respectivamente.
PACResumen
JFrame
PACIInterna()
beanIntrospeccion(String laClase)
String procesaArgs (Class[] xmetodoArgs)
String obtenClase()
JTree tree
DefaultTreeModel treeModelo
DefaultMutableTreeNode nodoClase;
DefaultMutableTreeNode nodoC;
DefaultMutableTreeNode nodoConcepto;
DefaultMutableTreeNode nodoVariable;
String laClase;
Vector vecPrivate
Vector vecProtected
Vector vecMetodos
Figura 4.15. La clases PACInformación interna y metRenderer.
Obtener
Clase
Realizar
introspección
Organizar
información
Presentar
información
metRenderer
DefaultTreeCellRenderer
Component getTreeCellRendererComponent()
boolean esClase(Object value)
boolean esProtected(Object value)
boolean esPrivate(Object value)
boolean esMetodos(Object value)
boolean esMetodo(Object value)
boolean esVariable(Object value)
boolean esVariables(Object value)
ImageIcon clase
ImageIcon metodo
ImageIcon vprotected
ImageIcon metodos
ImageIcon variable
ImageIcon vprivate
Figura 4.16. Diagrama de actividades de la clase PACIInterna.
76

Capitulo 5
Pruebas de Funcionamiento.
En este capítulo se presenta información referente un conjunto de pruebas que se
realizaron con el propósito de verificar el funcionamiento de los módulos que conforman la
herramienta. La información que se citará corresponde a procedimientos aplicados a los
componentes Puzzle, TextEditor y ProgressBar, los cuales se abordan en las secciones 5.2, 5.3
y 5.4 respectivamente.
Con el propósito de clasificar las actividades observadas durante la prueba, estas se
presentan en dos tablas. La primera considera los resultados generados a partir del
funcionamiento de cada uno de los módulos al ser utilizados de forma individual y la segunda,
que presenta un análisis de los resultados obtenidos al final de proceso de prueba, los cuales se
pueden apreciar utilizando los módulos de presentación de resultados.
5.1 Los componentes utilizados.
Los componentes utilizados en ésta sección fueron seleccionados aleatoriamente de un
banco disponible. Este banco consiste de varios componentes que han sido recolectados de la
WWW y referencias bibliográficas, así como la creación de nuevas versiones a partir de
componentes existentes. Es importante mencionar que, debido a que el mercado de
componentes es relativamente nuevo, no hay mucha disponibilidad de componentes.
A pesar de que en la mayoría de los casos, los componentes se ofrecen como productos
a la venta, los cuales se entregan sin código fuente y con una pobre documentación, para las
componentes contenidas en el banco se tiene información clara sobre sus especificaciones.
77

5.2 El componente Puzzle.
Puzzle es un componente que representa un rompecabezas de números. Utilizándolo,
en combinación con otros componentes, se puede construir una aplicación que permita
manipular las piezas que lo conforman de un modo organizado. La figura 5.1 es un applet
construído desde el BeanBox utilizando el componente Puzzle.
El archivo JAR que contiene al componente es Puzzle.jar y la clase definida como
Bean corresponde al archivo Puzzle.class, localizado en el directorio /jozart/puzzle. Esta clase
contiene 45 métodos.
La tabla 5.1 presenta las principales actividades llevadas a cabo y los resultados
obtenidos para estas al realizar la prueba para el componente Puzzle. Las actividades se
agrupan de acuerdo al módulo que las lleva a cabo. Mediante el análisis de la información
presentada en la tabla se puede observar que todas estas se llevaron de la forma en que se
esperaba.
Figura 5.1 Una applet que usa el componente Puzzle.
78

Módulo Actividad Resultado Observaciones
Apertura de Archivos
JAR.
Primer
Generador de Casos de
Prueba
Segundo
Generador de Casos de
Prueba
Extracción y creación de archivos
propios del componente
Correcto
Identificación de Beans. Correcto
Creación del archivo “beans.txt” Correcto
La generación archivo “casos.txt” Correcto
Uso de Plug-Ins en la generación
de casos.
Correcto
Creación archivo “casosp.txt” Correcto
Uso de Plug-Ins en la generación
de casos.
Creación del archivo
Primer
“resultados.txt”
Ejecutor de Casos de
Prueba Uso de Plug-Ins en la ejecución de
casos.
Creación del archivo
Segundo
“resultadosp.txt”
Ejecutor de Casos de
Prueba Uso de Plug-Ins en la ejecución de
casos.
Correcto
Correcto
Correcto
Correcto
Correcto
Se crearon correctamente las estructuras de
directorios, así como los contenidos para los
archivos .class y manifest.mf
La clase Puzzle, corresponde con lo
establecido en el archivo manifest.mf.
Se crea correctamente el archivo y su
contenido en el directorio /reportes
- Se crea correctamente el archivo en el
directorio /reportes
- Solo se almacenan los casos para 12 * de los
19 métodos que reciben argumentos.
* Solo los argumentos de 12 métodos son
conocidos por la herramienta.
Se utilizaron correctamente los Plug-Ins para
los argumentos:
- Color para métodos 28 y 42.
- Font para el método 36.
- Se crea correctamente el archivo en el
directorio /reportes
- Solo se almacenan los casos para 12 * de los
15 métodos que corresponden a propiedades.
* Solo los argumentos de 12 métodos son
conocidos por la herramienta.
Se utilizaron correctamente los Plug-Ins para
los argumentos:
- Color para métodos 28 y 42.
- Font para el método 36.
- Se crea correctamente el archivo en el
directorio /reportes
- Se almacenan los resultados para los 45
métodos contenidos en la clase.
Se utilizaron correctamente los Plug-Ins para
los argumentos:
- Color para métodos 28 y 42.
- Font para el método 36.
- Se crea correctamente el archivo en el
directorio /reportes
- Se almacenan los resultados para los 12
métodos que corresponden a propiedades.
Se utilizaron correctamente los Plug-Ins para
los argumentos:
- Color para métodos 28 y 42.
- Font para el método 36.
Tabla 5.1 Comportamiento de los módulos durante la prueba al componente Puzzle.
79

5.2.1 Los resultados observados.
Mediante el Primer Módulo de Presentación de Resultados se puede observar que las
pruebas de los métodos etiquetados como 4, 11, 20, 23 y 24, que corresponden a void
scramble(), void startSolving(), void moveBackward(), void moveForward() y addNotify()
respectivamente, generaron excepciones, debido a que estos requieren contextos especiales
para su ejecución, como lo son la llegada de un evento proveniente de otro componente.
Los métodos 13, 16, 25 y 33 que corresponden a void setGap(int), void
setPuzzleCols(int), void setPuzzleRows(int), void setBelvelHeigth(int), tienen que ver con la
apariencia del Bean. No se espera que estos métodos admitan valores negativos para
especificar el número de filas y columnas del rompecabezas (métodos 16 y 25), o bien para
establecer el espacio entre fichas y el sombreado de cada una de estas (métodos 13 y 33). A
diferencia de estas expectativas, al suministrarse los valores de prueba -2147483648, -
2147483647, -2147483646, -1073741824, -2, y –1, el componente no generó ninguna
excepción o acción correctiva y sí un cambio de estado admitiendo este tipo de valores. Este
comportamiento advierte al usuario sobre el funcionamiento de estos métodos.
La tabla 5.2 presenta un resumen de los resultados obtenidos en la prueba del
componente Puzzle.
80

Método Caso Resultado Generado Resultado Esperado Diagnóstico
4 void scramble () Único Excepción Excepción.
El método
11 void startSolving () Único Excepción Excepción.
funcionó
20 void moveBackward () Único Excepción Excepción. correctamente.
23 void moveForward () Único Excepción Excepción.
34 void addNotify () Único Excepción Excepción.
13 void setGap(int),
16 void setPuzzleCols(int),
25 void setPuzzleRows(int),
33 void
setBelvelHeigth(int),
-2147483648
-2147483647
-2147483646
-1073741824
–2
–1
-2147483648
-2147483647
-2147483646
-1073741824
–2
–1
-2147483648
-2147483647
-2147483646
-1073741824
–2
–1
-2147483648
-2147483647
-2147483646
-1073741824
–2
–1
null y la propiedad gap
igual al valor suministrado.
null y la propiedad
puzzleCols igual al valor
suministrado.
null y la propiedad
puzzleRows igual al valor
suministrado.
null y la propiedad
belvelHeigth igual al valor
suministrado.
Excepción o acción
correctiva sobre el valor de
la propiedad gap
(gap > 0)
Excepción o acción
correctiva sobre el valor de
la propiedad puzzleCols
(puzzleCols > 0)
Excepción o acción
correctiva sobre el valor de
la propiedad puzzleRows
(puzzleRows > 0)
Excepción o acción
correctiva sobre el valor de
la propiedad belvelHeigth
(belvelHeigth > 0)
Tabla 5.2 Resultados de la prueba al componente Puzzle.
Ningún error
detectado
El método no
siempre funcionó
correctamente.
Error detectado
El método no
siempre funcionó
correctamente.
Error detectado
El método no
siempre funcionó
correctamente.
Error detectado
El método no
siempre funcionó
correctamente.
Error detectado
81

5.3 El componente TextEditor.
TextEditor es un componente que ofrece las funcionalidades de un sencillo procesador
de texto. La figura 5.2 muestra un applet que utiliza este y otros componentes con el propósito
de crear una aplicación.
Figura 5.2 Una applet que usa el componente TextEditor.
El archivo TextEditor.jar comprime los elementos necesarios por el componente y el
componente según lo especificado en el archivo “manifest.mf”, corresponde a la clase
TextEditor.class localizada en el directorio sunw/demo/TextEditor. Esta clase contiene 15
métodos.
La tabla 5.3 contiene una descripción de las actividades realizadas y los resultados por
cada uno de los módulos que conforma la herramienta, durante la prueba del componente
TextEditor. Las acciones realizadas se llevaron a cabo sin presentarse ningún contratiempo.
82

Módulo Actividad Resultado Observaciones
Apertura de Archivos
JAR.
Primer
Generador de Casos de
Prueba
Segundo
Generador de Casos de
Prueba
Primer
Ejecutor de Casos de
Extracción y creación de archivos
propios del componente
Correcto
Identificación de Beans. Correcto
Creación del archivo “beans.txt” Correcto
La generación archivo “casos.txt” Correcto
Uso de Plug-Ins en la generación
de casos.
Creación archivo “casosp.txt” Correcto
Uso de Plug-Ins en la generación
de casos.
Creación del archivo
“resultados.txt”
Prueba Uso de Plug-Ins en la ejecución de
casos.
Segundo
Ejecutor de Casos de
Prueba
Creación del archivo
“resultadosp.txt”
Uso de Plug-Ins en la ejecución de
casos.
Se crearon correctamente las estructuras de
directorios, así como los contenidos para los
archivos .class y manifest.mf
La clase TextEditor, corresponde con lo
establecido en el archivo manifest.mf.
Se crea correctamente el archivo y su
contenido en el directorio /reportes
- Se crea correctamente el archivo en el
directorio /reportes.
- Solo se almacenan los casos para 4 de los
15 métodos que reciben argumentos.
* Solo los argumentos de 4 métodos son
conocidos por la herramienta.
Correcto No se requirieron Plug Ins.
- Se crea correctamente el archivo en el
directorio /reportes
- Se almacenan los casos para los 4 métodos
que corresponden a propiedades.
Correcto No se requirieron Plug Ins.
Correcto
- Se crea correctamente el archivo en el
directorio /reportes
- Se almacenan los resultados para los 15
métodos contenidos en la clase.
Correcto No se requirieron Plug Ins.
Correcto
- Se crea correctamente el archivo en el
directorio /reportes
- Se almacenan los resultados para los 4
métodos contenidos en la clase que
corresponden a propiedades.
Correcto No se requirieron Plug Ins.
Tabla 5.3 Comportamiento de los módulos durante la prueba al componente TextEditor.
83

5.3.1 Los resultados observados.
TextEditor.
La tabla 5.4 presenta los resultados obtenidos al realizar la prueba al componente
El método 2, void load(), que permite la carga de un archivo, generó una excepción al
ejercitarse, aspecto que se esperaba. Sin embargo el método 3 que corresponde a la
declaración void save(), del cual se esperaba un comportamiento similar, no presentó el
mismo comportamiento y se ejecuto sin problemas.
El método void setFontName(java.lang.String) (método 7) permite establecer el tipo de
fuente a utilizar en el procesador de texto, sin embargo al probarlo se comprobó que no existe
ningún tipo de validación con respecto a entradas que no corresponden con un tipo de letra.
Algo similar ocurre con métodos que manipulan el tamaño y estilo de la fuente como lo son
void setFontSize(int) y void setFontStyle(int) (metodos 11 y 15).
Al no presentarse algún tipo de validación del argumento de entrada, estos métodos
deben ser utilizados con sumo cuidado para evitar inconsistencias y mal funcionamiento del
componente.
84

Método Caso Resultado Generado Resultado Esperado Diagnóstico
2 void load () Único Excepción Excepción.
3 void save () Único null Excepción.
7 void setFontName
(java.lang.String)
11 void setFontSize (int)
15 void setFontStyle (int)
aeiou
!”#$%&/()=?¡
1234567890
2147483645
2147483646
2147483647
1073741824
2
1
0
-1
-2
-1073741824
-2147483646
-2147483647
-2147483648
2147483645
2147483646
2147483647
1073741824
2
1
0
-1
-2
-1073741824
-2147483646
-2147483647
-2147483648
null y la propiedad
fontName igual al valor
suministrado
null y la propiedad fontSize
igual al valor suministrado
null y la propiedad
fontStyle igual al valor
suministrado
Excepción o acción
correctiva sobre el valor de
la propiedad fontName
Excepción o acción
correctiva sobre el valor de
la propiedad fontSize
(fontSize > 0)
Excepción o acción
correctiva sobre el valor de
la propiedad fontStyle
(fontStyle > 0)
5.4 Resultados de la prueba al componente TextEditor.
El método
funcionó
correctamente.
Ningún error
detectado
El método
funcionó
correctamente.
Error detectado
El método no
siempre funcionó
correctamente.
Error detectado
El método no
siempre funcionó
correctamente.
Error detectado
El método no
siempre funcionó
correctamente.
Error detectado
85

5.4 El componente ProgressBar.
El componente ProgressBar es un termómetro que permite la representación gráfica de
un porcentaje especificado. La clase ProgressBar.class que mediante la cual se implementa el
JavaBean contiene 11 métodos. La figura 5.3, muestra este componente en el BeanBox.
Figura 5.3 El componente ProgressBar.
Los resultados obtenidos durante el proceso de prueba para este componente fueron
satisfactorios, sin presentarse alguna contrariedad. La tabla 5.5 presenta un resumen de los
mismos.
86

Módulo Actividad Resultado Observaciones
Apertura de Archivos
JAR.
Primer
Generador de Casos de
Prueba
Segundo
Generador de Casos de
Prueba
Primer
Ejecutor de Casos de
Extracción y creación de archivos
propios del componente
Tabla 5.5 Comportamiento de los módulos durante la prueba al componente
ProgressBar.
5.4.1 Los resultados observados.
Correcto
Identificación de Beans. Correcto
Creación del archivo “beans.txt” Correcto
La generación archivo “casos.txt” Correcto
Uso de Plug-Ins en la generación
de casos.
Correcto
Creación archivo “casosp.txt” Correcto
Uso de Plug-Ins en la generación
de casos.
Creación del archivo
“resultados.txt”
Prueba Uso de Plug-Ins en la ejecución de
casos.
Segundo
Ejecutor de Casos de
Creación del archivo
“resultadosp.txt”
Prueba Uso de Plug-Ins en la ejecución de
casos.
Correcto
Correcto
Se crearon correctamente las estructuras de
directorios, así como los contenidos para los
archivos .class y manifest.mf
La clase ProgressBar, corresponde con lo
establecido en el archivo manifest.mf.
Se crea correctamente el archivo y su
contenido en el directorio /reportes
- Se crea correctamente el archivo en el
directorio /reportes.
- Solo se almacenan los casos para 3 * de los
4 métodos que reciben argumentos.
* Solo los argumentos de 3 métodos son
conocidos por la herramienta.
Se utilizó correctamente los Plug-Ins para el
argumento:
- Color para el método 3
- Se crea correctamente el archivo en el
directorio /reportes
- Se almacenan los casos para los 3 métodos
que corresponden a propiedades.
Se utilizó correctamente los Plug-Ins para el
argumento:
- Color para el método 3
- Se crea correctamente el archivo en el
directorio /reportes
- Se almacenan los resultados para los 11
métodos contenidos en la clase.
Correcto No se requirieron Plug Ins.
Correcto
Correcto
- Se crea correctamente el archivo en el
directorio /reportes
- Se almacenan los resultados para los 3
métodos que corresponden a propieades.
Se utilizó correctamente los Plug-Ins para el
argumento:
- Color para el método 3
Un aspecto interesante de este componente descubierto a partir de las pruebas, es el
que tiene que ver con el método que modifica la propiedad percent del componente, void
setPercent(int), (método 1). En el análisis de los resultados se observa que al proporcionar
valores que no cumplen con la característica de ser mayor que 0 y menor que 100, el
87

componente restaura el valor de la propiedad percent a un valor válido que puede ser 0 o bién
1. Esto se presenta con detalle en la tabla 5.6.
A diferencia del componente analizado en la sección anterior, ProgressBar realiza una
validación de los valores sumistrados por el usuario para la propiedad percent.
Dentro del conjunto de resultados obtenidos no se encontró ningún tipo de excepción.
Método Caso Resultado Generado Resultado Esperado Diagnóstico
1 void
setPercent(int)
2147483645
2147483646
2147483647
1073741824
null y la propiedad percent
igual con 0
Excepción o acción
correctiva sobre el valor de
la propiedad percent.
(percent
0)
2 2 2
1 1 1
0 0 2
-1
-2
-1073741824
-2147483646
-2147483647
-2147483648
null y la propiedad percent
igual con 0
Excepción o acción
correctiva sobre el valor de
la propiedad percent.
(percent
0)
Tabla 5.6 Resultados de la prueba al componente ProgressBar.
El método no siempre
funcionó correctamente.
Error detectado
El método funcionó
correctamente.
Ningún error detectado
El método funcionó
correctamente.
Ningún error detectado
El método no siempre
funcionó correctamente.
Error detectado
El método no siempre
funcionó correctamente.
Error detectado
88

Conclusiones.
Es claro que una actividad indispensable en todo proceso de desarrollo de software, es
la prueba, si esta actividad no se llevara a cabo, se tendría un desconocimiento total sobre la
calidad de los productos.
No se puede negar que, con la aparición de nuevos modelos de desarrollo, muchos de
los procesos involucrados en la construcción de software se han simplificado; sin embargo
existen otras actividades que no han corrido con la misma suerte, ejemplo de ello es la prueba
de software.
Las actividades realizadas para la realización de éste trabajo han permitido obtener las
siguientes conclusiones:
a) Con respecto a la herramienta de prueba:
• Se logró el objetivo de desarrollar una herramienta para probar componentes
construidas bajo el modelo de JavaBeans. Esta herramienta terminada y probada,
provee una alternativa de prueba automática de este tipo de componentes.
• Como se mencionó en un principio, la generación automática de casos de prueba así
como la puesta en marcha de los mismos, representa una ventaja significativa si se
piensa que el usuario que utiliza los componentes, carece, regularmente, de
conocimientos formales para ello.
• Así mismo, es importante destacar que para la implementación de la herramienta, se
consideran aspectos relevantes en el área de prueba de software, técnicas como la
prueba de valores limite y la prueba basada en estado, así como algunas métricas para
software orientado a objetos, todo esto con el propósito de enriquecer los criterios de
evaluación.
89

• Aunque pudiera pensarse como una limitación el hecho de utilizar técnicas de prueba
funcional, es importante hacer mención que dada la naturaleza de los componentes, los
cuales se ofrecen como productos en los que no se incluye el código fuente, las
estrategias de prueba utilizadas corresponden con el contexto actual del software
basado en componentes, ya que de otro modo pudieron haberse incluido en la
herramienta otras técnicas de prueba.
b) Con respecto a aplicaciones futuras y mejoras de la herramienta:
• Puesto que el mercado de componentes está en desarrollo y aún no existen acuerdos
totalmente establecidos en este contexto, inicialmente se optó por contemplar las
pruebas a nivel de unidad, sin embargo a futuro podrían contemplarse niveles
superiores de prueba.
• Otro desarrollo potencial es la aplicación de técnicas similares en la prueba de servlets
y aún de Enterprise JavaBeans. Todos ellos comparten elementos comunes con los
JavaBeans.
• En un trabajo posterior, podría mejorarse la edición de casos por el usuario, de forma
que los errores en su captura puedan disminuirse.
• Así mismo, podría incluirse un mecanismo para proporcionar el estado inicial del
componente a partir del cual iniciar el proceso de prueba. Esto mejoraría lo que
actualmente provee la herramienta, que es únicamente el estado posterior a la
instanciación del Bean.
La realización de este trabajo, los resultados obtenidos a partir de él y, muchas otras
experiencias, permiten darnos cuenta que la prueba es una actividad que indiscutiblemente
debe llevarse a cabo, aun ante la presencia de modelos de desarrollo que insisten en
subestimarla.
90

a) Tipos de datos primitivos.
ANEXO A
Valores Establecidos para la
Generación de Casos de Prueba.
Nombre Tamaño
Máximo
Valores Establecidos
Medio Mínimo
boolean 1 bit true False
byte 8 bits
short 16 bits
int 32 bits
long 64 bits
125
126
127
32765
32766
32767
2147483645
2147483646
2147483647
9223372036854775805
9223372036854775806
9223372036854775807
-64
-2
-1
0
1
2
64
-16384
-2
-1
0
1
2
16384
-1073741824
-2
-1
0
1
2
-1073741824
-4611686018427387904
-2
-1
0
1
2
-4611686018427387904
-128
-127
-126
-32768
-32767
-32765
-2147483648
-2147483647
-2147483646
-9223372036854775808
-9223372036854775807
-9223372036854775805
91

Nombre Tamaño
float 32 bits
double 64 bits
b) Otros tipos.
Máximo
Valores Establecidos
Medio Mínimo
-3.40292347 E36
-3.40292347 E37
-3.40292347 E38
-1.79769313486231570E306
-1.79769313486231560E307
-1.79769313486231560E308
Nombre Valores Establecidos
String
char
aeiou
!#$%&/()=?¡
1234567890
a
Z
%
1
-9223372036854775807.99
-2.9
-1.1
0.1
1.1
2.9
9223372036854775807.99
-3.40292347E36
-2.9
-1.1
0.1
1.1
2.9
3.40292347E36
-3.40292347 E38
-3.40292347 E37
-3.40292347 E36
-1.79769313486231570E308
-1.79769313486231560E307
-1.79769313486231560E306
92

ANEXO B
Manual de Operación.
En la actualidad existen pocas herramientas para probar software orientado a objetos y
aún menos para probar software basado en componentes, por lo que surgió la idea de
desarrollar una herramienta para ello.
La herramienta de Prueba Automática de Componentes JavaBeans, “PACJavaBeans”,
ofrece varios servicios orientados a la prueba de componentes construidos bajo el modelo
JavaBeans, de forma que al utilizarlos el usuario lleve a cabo de forma más sencilla las tareas
de selección y evaluación de Beans. La siguiente figura, muestra el panel con el cual el
usuario interactúa con el propósito de utilizar los servicios que ofrece la herramienta.
Los servicios que ofrece PACJavaBeans, se presentan en el panel lanzador como un
conjunto de botones que el usuario utiliza para invocar a los módulos que los llevan a cabo.
Estos servicios deben ser invocados bajo un orden, ya que representan etapas diferentes de un
93

proceso de prueba. El orden está ya predeterminado en la herramienta de modo que, a medida
que se van utilizando los servicios, los botones que los representan cambian de estado (activo
o inactivo), de acuerdo a la etapa del proceso que se este llevando a cabo. De esta forma, el
proceso de prueba para un Bean consiste de los siguientes pasos:
1. Abrir el archivo JAR para identificar los componentes contenidos en él. Este servicio
está representado por el botón Abrir archivo JAR..
2. Generar automáticamente los casos de prueba. Servicio representado por el botón
Generar Casos de Prueba.
3. Ejecutar los casos de prueba previamente generados, esto mediante el botón Ejecutar
Casos de Prueba.
4. De manera opcional, el usuario podría proponer casos de prueba manualmente. Si se
desea realizar esta actividad, se debe presionar Editar Casos de Prueba.
a. Si el usuario ha propuesto algunos casos de prueba, el siguiente paso consiste
en la ejecución de los mismos. Para ello se debe presionar el botón Ejecutar
Casos Editados.
5. Finalmente, una vez ejecutados todos los casos de prueba se procede a la lectura de los
resultados. Para los casos generados de forma automática debe utilizarse el botón Ver
Resultados.
De igual forma se recomienda invocar el servicio ofrecido por el botón Información
interna, que permitirá realizar el análisis de algunos aspectos relacionados con la
implementación del Bean.
a. Si fuera el caso, para ver los resultados de los casos editados se utiliza el botón
Ver Resultados de CE.
6. Una vez concluido el proceso de prueba, si se desea llevar a cabo una nueva sesión, se
recomienda limpiar el entorno de operación mediante el botón Limpiar.
A continuación se explican de forma más amplia los servicios que ofrece PACJavaBeans.
94

Abrir archivo JAR.
Normalmente, los Beans se ofrecen dentro de un archivo JAR. Este archivo, entre otras
cosas, empaqueta uno o más Beans dentro de una sola unidad. Atendiendo esta característica,
es necesario contar con un medio que permita extraer el contenido del archivo JAR, además
de identificar y disponer de las componentes que este contiene.
Si se presiona el botón Abrir archivo JAR desde el panel lanzador, se ejecutará el
Módulo de Apertura de archivos JAR. Al inicio, el módulo tiene la apariencia que se muestra
en la figura.
Para indicar el nombre del archivo JAR que se desea analizar debe presionarse el botón
Abrir JAR...., localizado en la parte superior derecha del módulo. Esta acción desplegará un
seleccionador de archivos.
El seleccionador mostrará los archivos JAR contenidos en el directorio /jars, lugar
donde deben ser colocados los JAR que se desean evaluar, por ello es indispensable que estos
archivos se copien dentro de este directorio con anterioridad. La apariencia del seleccionador
de archivos se presenta a continuación.
95

Una vez que se ha seleccionado un archivo de la lista presentada, es necesario
presionar el botón Open para iniciar el proceso de extracción. De lo contrario presionar el
botón Cancel.
Si el archivo seleccionado es una archivo válido, es decir, es un archivo JAR que
contiene JavaBeans, se realiza el proceso de extracción del mismo y se informan los
resultados. La siguiente figura presenta la información final después de haberse llevado a cabo
el procedimiento anteriormente descrito para el archivo puzzle.jar
96

Generar Casos de Prueba.
El botón Generar Casos de Prueba, permite ejecutar el módulo que lleva a cabo la
generación automática de casos de prueba. Para llevar a cabo esta actividad, es necesario que
la apertura del archivo JAR se haya realizado.
El Módulo de Generación de Casos de Prueba buscará las clases que hayan sido
extraídas del archivo JAR y que correspondan Beans. El nombre de cada una de estas clases se
despliega en una lista que se presenta en la interfaz del módulo. Para que el proceso de
generación pueda iniciarse, es necesario que se seleccione un nombre de la lista y
posteriormente presionar el botón Generar Casos como se aprecia a continuación.
97

Al término del proceso de generación de casos, en la interfaz del módulo se presenta
un resumen que informa las acciones efectuadas.
Editar Casos de Prueba.
Con la intención de proveer otra alternativa para la generación de casos de prueba, se
implementa el servicio de edición de casos, el cual permite que la herramienta pueda admitir
casos propuestos por el usuario; esto de forma manual mediante la modificación del archivo
“casosp.txt”.
Presionando el botón Editar Casos de Prueba, desde el panel lanzador se activa un
sencillo editor de textos que carga el archivo anteriormente mencionado y permite que este sea
modificado por el usuario. Con el propósito de que el proceso de ejecución de estos casos se
lleve a cabo de forma correcta, es necesario que la escritura de este archivo se realice de
acuerdo a ciertas consideraciones.
Como puede observarse en la siguiente figura, el contenido inicial del archivo consiste
en un texto que describe algunos de los métodos contenidos en la clase que implementa al
Bean (valor de retorno, nombre y argumentos) y, una especie se separador entre ellos (el
asterisco). Los métodos que aparecerán escritos en el archivo, son únicamente aquellos que
98

corresponden a las propiedades del Bean y para los que el sistema conoce el tipo de
argumentos que utilizan.
Al escribir los valores para generar los casos de prueba, es importante identificar el
tipo de argumento, y de esta forma, escribir los valores afines entre el nombre del método y el
terminador asterisco. Por ejemplo, en la siguiente figura, se observa que el método
setImageFile requiere un argumento de tipo String, de esta forma se ha propuesto dos casos de
prueba con los valores “flor.bmp” y “animal”; estos se han escrito entre el nombre del método
y el asterisco. Así mismo, siguiendo esta sencilla regla, se ha propuesto el valor “false” para el
método setShadowLabels y el valor “-123” para el método setGap.
99

No es necesario escribir casos de prueba para todos los métodos, ni el mismo número
de casos para todos los métodos. Una vez terminado el proceso de edición, se procede a salvar
el contenido del archivo.
Ejecutar Casos de Prueba.
Si se presiona el botón Ejecutar Casos de Prueba desde el panel lanzador, se ejercita el
Módulo de Ejecución de Casos de Prueba. Este módulo lleva a cabo la ejecución de los casos
de prueba que han sido generados de forma automática por la herramienta.
Una vez que el módulo ha sido activado, es necesario seleccionar el nombre del Bean
al que corresponden los casos de prueba desde la lista disponible en la interfaz del usuario y,
posteriormente, presionar el botón Ejecutar Casos. Esto se ilustra a continuación:
100

Una vez que el proceso ha finalizado, el módulo presenta un resumen que informa las
actividades realizadas.
101

Ejecutar Casos Editados.
El botón ejecutar casos, invoca al Módulo de Ejecución de Casos Editado. Este realiza
una función equivalente a la que se describió antes, solo que en esta ocasión, los casos de
prueba que se ejecutan corresponden a los que se escribieron en el archivo “casosp.txt“.
Casos.
La operación y comportamiento de este módulo es igual al de Modulo de Ejecución de
Ver resultados.
El botón Ver Resultados permite que los resultados del proceso de prueba puedan
observarse. Al presionar este botón, se activará el módulo que presenta los resultados que
corresponden a los casos generados de forma automática. La siguiente figura presenta los
resultados obtenidos después de aplicar haber probado la componente Puzzle.
102

En la parte superior, los resultados se presentan al usuario en un formato de árbol, mismo
que permite que el usuario pueda visualizar los resultados de un modo más organizado. Este
árbol contiene la siguiente información:
a) Nombre de la clase a la que corresponde el Bean.
b) El nombre del método bajo el siguiente formato:
número_de_identificación (número_de_casos_generados) encabezado
c) Datos del caso de prueba bajo el siguiente formato:
Caso: valores_del_caso ... valor_que_regresó_el_método
d) Datos que describe el estado final del Bean, específicamente sus propiedades, bajo el
siguiente formato:
nombre_de_la_propiedad = valor_final
En la parte inferior del módulo se presenta información que describe el estado inicial
del Bean, es decir, el valor de las propiedades antes de ejecutarse el método con su caso
correspondiente. Se pretende que esta información pueda ser utilizada para realizar algunas
comparaciones. Su formato es el siguiente:
Ver resultados de CE.
nombre_de_la_propiedad = valor_inicial
El botón Ver Resultados CE, invoca al módulo que presenta la información referente a
la ejecución de los casos propuestos por el usuario. Prácticamente este modulo tiene un
comportamiento similar al que se describió anteriormente.
Ver Información interna.
Con la finalidad de ofrecer más información que permita al usuario enriquecer su
evaluación, el Modulo Información interna, que se ejecuta al presionar el botón información
interna. Despliega información relacionada con la implementación de la clase como:
103

a) Descripción de la variables privadas.
b) Descripción de la variables protegidas.
c) Descripción de otro tipo de variables.
d) Descripción de los métodos que corresponden a propiedades.
e) Descripción de otros métodos.
A continuación se presenta una vista de este módulo.
Limpiar.
El botón limpiar permite establecer el entorno inicial que se requiere para llevar a cabo
un proceso de prueba. Este procedimiento consiste fundamentalmente en la eliminación de
archivos temporales que almacenan resultados de pruebas realizadas con anterioridad.
104

Este procedimiento es recomendable efectuarlo al final de un proceso de prueba y
antes de iniciar uno nuevo. De igual forma este procedimiento puede utilizarse aún sin haberse
completado todas las etapas del proceso de prueba.
105

ANEXO C
Elementos Notacionales en UML.
El Unified Modeling Modeling Language (UML), en un lenguaje visual de propósito
general que se utiliza para especificar, visualizar, construir y documentar cualquier sistema.
UML pretende unificar la técnicas de modelado, con el propósito de capturar la información
de la estructura estática de sistema, así como de su comportamiento. Para ello, el lenguaje
incluye una serie de elementos que incluyen conceptos semánticos, notación y directrices, los
cuales se clasifican en las siguientes áreas:
a) Estructura Estática.
Se consideran los conceptos claves de la aplicación, sus propiedades y las relaciones
entre objetos.
b) Comportamiento Dinámico.
Trata con la representación del o de los objetos y su interacción con el mundo, así
como con los patrones de comunicación entre objetos necesarios para implementar un
comportamiento específico.
c) Implementación.
Se concentra en el manejo de constructores que representan las implementaciones de
ciertos elementos.
d) Organización de Modelos.
Cuando se manejan sistemas muy grandes, conviene dividir la información en un
conjunto de piezas coherentes que realicen el trabajo en diferentes partes de manera
concurrente.
e) Mecanismos de Extensión.
Convenciones que tienen el propósito de permitir la inclusión de nuevos elementos en
forma ordenada sin necesidad de realizar cambios significativos en el lenguaje.
106

Los elementos de UML utilizados durante la descripción del diseño de la herramienta
que se describe en este trabajo, incluyen los Diagramas de Clases y los Diagramas de
Actividades, los cuales corresponden a las áreas de Estructura Estática y Comportamiento
Dinámico respectivamente. Estos se abordan con mayor detalle a continuación.
Diagramas de Clases.
Un diagrama de estructura estática muestra el conjunto de clases importantes que
conforman parte de un sistema, junto con las relaciones existentes entre ellas. Muestra de una
manera estática la estructura de información del sistema y la visibilidad que tiene cada una de
las clases, dada por sus relaciones con las demás en el modelo.
A continuación se presenta una tabla que concentra a los elementos gráficos que se
utilizaron en los diagramas de clases que contiene este documento.
Elemento Descripción
Clase
Asociación
Agregación
Generalización
Representada por un rectángulo con tres
divisiones internas, que alojan el nombre de la
clase, sus atributos y sus métodos,
respectivamente. Son los elementos
fundamentales del diagrama.
Permiten tener una mejor información sobre las
relaciones entre los objetos de un sistema. Se
representa como una línea etiquetada con la
palabra que describe la relación existente.
Es una relación que permite describir a un “todo”
y sus partes. Se representa con línea con un
rombo en uno de sus extremos, el rombo debe ir
situado del lado del objeto que representa el
“todo”.
Es una relación entre una descripción más
general y una más especifica variedad de cosas.
Aspectos como qué o quién construye a un
objeto o quién lo extiende. Este elemento se
utiliza para representar la herencia. Se representa
con línea con un triángulo en uno de sus
extremos, el triángulo debe ir situado del lado del
objeto que representa la vista general.
Representación
Gráfica
107

Diagrama de Actividades.
Un diagrama de actividades es un caso especial de un diagrama de estados en el cual
casi todos los estados, son estados de acción (identifican qué acción se ejecuta al estar en él).
Puede dar detalle a un caso de uso, un objeto o un mensaje en un objeto. Sirven para
representar transiciones internas, sin hacer mucho énfasis en transiciones o eventos externos.
Generalmente modelan los pasos de un algoritmo.
A continuación se presenta una tabla que concentra a los elementos gráficos que se
utilizan en los diagramas de clases, así como una descripción de su significado.
Elemento Descripción
Estado de acción
Transiciones
Decisiones
Fin del proceso
Representa un estado con acción interna, con por
lo menos una transición que identifica la
culminación de la acción (por medio de un
evento implícito).
Las flechas entre estados representan
transiciones con evento implícito. Pueden tener
una condición en el caso de decisiones.
Se representa mediante una transición múltiple
que sale de un estado, donde cada camino tiene
una etiqueta distinta.
Establecen el punto en el que concluyen cada una
de las actividades presentadas en el diagrama.
Representación
Gráfica
108

Referencias Bibliográficas.
[AMB99] Ambler, S. “Object testing patterns”.
http:///www.sdmagazine.com/uml/articles/s997dcl.shtml. Julio 1999.
[BAS99] Bashir, I. y Goel A. “Testing object-oriented software. Life cycle solutions”.
Springer-Verlag New York , Inc.1999.
[BER93] Berard, E.V. “Essays on object oriented software engineering”. Volumen 1,
Addison-Wesley, 19993.
[BIN95-A] Binder, R. “Testing object-oriented systems: A status report”.
http:///www.rbsc.com/pages/ootstat.html. Documento en Línea. Abril 1995.
[BIN95-B] Binder, R. “Object-oriented testing”.
http:///www.rbsc.com/pages/myths.html. Documento en Línea. Mayo 1995.
[BIN96] Binder, R. “Testing object-oriented software: a survey”. Software testing,
Verification and Reliability, v 6, pp 125-252
[DSO99] D´Souza, D. F. y Cameron W. A, “Objects, components and frameworks with
UML. The catalysis approach”. Addison-Wesley, Reading Mass, 1999.
[FER99] Fernández, J. M. “Prueba de software basado en componentes. Estado actual”.
Informe Técnico N° 28 Serie Verde, CIC, IPN. 1999.
[IEE90] “IEEE Standard Glossary of Software Engineering Terminology”. 1990
[JAC92] Jacobson, I. “Object-oriented software testing. A use case driven approach”. ACM
Press.1992.
109

[JOR95] Jorgensen, D.C. “Software testing. A craftsman´s approach”, CRC Press, Boca
Raton, Florida.1995.
[KIR94] Kirani, S. and Tsai, W. “Method sequence specification and verification of classes”.
Testing Object-Oriented Software. IEEE Computer Society, 1998. pp 43-57
[KIT96] Kit, E. “Software testing in the real world. Improving the process”, ACM
Press.1996.
[KUN96] Kung, D., Lu Y, Venugopalan, N., Sia, P., toyoshima, Y., Chen C. y Gao, J.
“Object State testing and fault analisys for reliable software systems”. Testing Object-
Oriented Software. IEEE Computer Society, 1998. pp 133-142.
[MAR96] Martin, R.H. y Odell. “Object oriented methodology: pragmatic considerations”.
Prentice Hall, Upper Saddle River.1996.
[MCG94] McGregror, J.D. y Korson, T. “Integrated object-oriented testing and
development processes”. CACM 37:9, pp 59-77. 1994.
[MIC00] ”Component Object Model”.
http://www.microsoft.com/com Documento en línea. 2000.
[MUR94] Murphy, G.C., Townsend P., y Wong P.S. “Experiences with cluster and class
testing”. CACM 37:9, pp 39-47. 1994.
[MYE79] Myers G. “The art of software testing”. Wiley. 1979.
[ORG00] “CORBA”. http://www.corba.org . Documento en línea. 2000.
[PER90] Perry, D. y Kaiser, G. “Adecuate testing y object-oriented programming”. Testing
Object-Oriented Software. IEEE Computer Society, 1998. pp 11-17.
110

[PRE98] Pressman, R. “Ingeniería del software. Un enfoque práctico”. Cuarta Edición.
McGraw-Hill/Interamaericana de España. 1998.
[SIR97] Sirer, E.G. “Kimera. A system architecture for networked computers”
http://kimera.cs.washington.edu/ Documento en linea, 1997
[SUN00] “Enterprise JavaBeans ”.
http://java.sun.com/ejb . Documentación en línea. 2000.
[SUN97] SUN “Java Beans”. http:///java.sun.com . 1997.
[SZY97] Szyperski, C. “Component software. Beyond object-oriented programming”.
Addison-Wesley y ACM Press, 1997.
[TRU99] “Trusted components for the software industry”.
http://www.eiffel.com/doc/manuals/technology/bmarticles/computer/trusted/pa
ge.html Documento en linea. 1999.
[TUR93] Turner, C. y Robson D. “The sate-based testing of object-oriented programs”.
Testing Object-Oriented Software. IEEE Computer Society, 1998. pp 133-142.
[VAN98] Vanhelsuwe , L. “Mastering Java Beans” Sybex, Inc. 1998.
[VOA98] Voas, J.M. “Certifying off-the-shelf software components”. IEEE Computer, junio
1998. pp 53-59.
[WOH98] Wohlin C. y Regnell B., “Reliability certification of software components”.
Proceedings Fifth international Conference on Software Reuse, Canada, 1998. pp 56-65.
111