CAPÍTULO

23 PRUEBAS ORIENTADAS
A OBJETOS

E
L objetivo de las pruebas, expresado de forma sencilla, es encontrar el mayor número
posible de errores con una cantidad razonable de esfuerzo, aplicado sobre un lapso de
tiempo realista. A pesar de que este objetivo fundamental permanece inalterado para el
software orientado a objetos, la naturaleza de los programas O 0 cambian las estrategias y las
tácticas de prueba.
Puede argumentarse que, conforme el A 0 0 y el DO0 maduran, una mayor reutilización de
patrones de diseño mitigarán la necesidad de pruebas intensivas en los sistemas OO. La verdad
es justo lo contrario. Binder [BIN94b] lo analiza, cuando afirma que:
Cada reutilización es un nuevo contexto de uso y es prudente repetir las pruebas. Parece probable que
se necesitarán menos pruebas para obtener una alta fiabilidad en sistemas orientados a objetos.
La prueba de los sistemas O 0 presentan un nuevo conjunto de retos al ingeniero del soft-
ware. La definición de pruebas debe ser ampliada para incluir técnicas que descubran errores
(revisiones técnicas formales), aplicadas para los modelos de A 0 0 y DOO. La integridad, com-
pleción y consistencia de las representaciones O 0 deben ser evaluadas conforme se constru-
yen. Las pruebas de unidad pierden mucho de su significado, y las estrategias de integración
cambian de modo significativo. En resumen, las estrategias y tácticas de prueba deben tomar-
se en cuenta para las características propias del software OO.

¿Qué es? La arquitectura de software la frustración asociada con y pruebas d e agrupa-

orientado a objetos se manifiesta en
una serie de subsistemas organizados
por capas, que encapsuian clases que
colaboran entre sí. Cada uno de estos
elementos del sistema (subsistemas y
clases), realizan funciones que ayudan
a alcanza requerimientos del sistema.
¿Cuáles son los paros? L a
Es necesario probar un sistema OO.en
una variedad de niveles diferentes, en
un esfuerzo para descubrir errores, que
deben ocurrir cuando las clases cola-
boran con otras entre sí, y los subsis-
temas se comunican por medio de las
capas arquitectónicas.
gQlii6n lo hace? L a s pruebas orienta-
das a objetos se realizan por ingenie-
ros d e software y especialistas en
pruebas.
¿Por que es importante? Se debe eje-
cutar el programa antes de que llegue
al cliente, con la intención específica
de descubrir todos los errores, de
manera que el cliente no emerimente
to de baja calidad. Con el prop
encontrar el mayor número
errores, las pruebas deben conducirse
sistemáticamente. y los casos
ba deben ser designados medi
nicas disciplinadas.
O0 son estratégicamente s
las pruebas de sistemas convenci
les. pero tácticamente difer
que los modelos de análisis
O0 son similares en estruct
tenido al programa 00,las
comienzan con la revisión
modelos. Una vez que se ha
el código, las pruebas O0 c
*en lo pequeño. con las pruebas de
clases. Existen pruebas disefíadas
para probar las operaciones de las cla-
ses y examinar s i los error
cuando una clase colabora con otras.
Así como las clases se integran para
formar un subsistema basado en hilos,
amente las clases colabora-
imo, los casos d e uso
como parte del modelo
)se usan para descubrir
ftware a nivel de vali-
d o obtenido? Se
tan un conjunto de
clases, sus colaboraciones y com-
os;se definen los resultados
y se registran los resulta-
o estar seguro de que lo
crorreckmrente?Cuando
las pruebas, se cambia su
ista. ¡intenta crompern el
de una forma disciplinada y revisar los
casos de prueba que se crean con meti-
culosidad.

407
INGENlERfA DEL SOFTWARE. UN ENFOQUE PRACTICO
La construcción del software orientado a objetos
comienza con la creación de los modelos de análisis
y diseño (Capítulos 21 y 22). Debido a la naturaleza
evolutiva del paradigma de ingeniería de software 00,
estos modelos comienzan como representaciones, rela-
tivamente informales, de los requisitos del sistema, y
evolucionan en modelos detallados de clases, cone-
xiones y relaciones de clases, el diseño del sistema y
el diseño de objetos (incorporando un modelo de
conectividad de objetos por medio de mensajes). En
cada etapa, los modelos pueden probarse, en un inten-
to de descubrir errores, antes de su propagación a la
siguiente iteración.
,
Puede argumentarse que la revisión de los mode-
los de análisis y diseño O 0 son especialmente útiles,
ya que las mismas estructuras semánticas (por ejem-
plo, clases, atributos, operaciones, mensajes), apare-
cen en los niveles de análisis, diseño y codificación.
Por consiguiente, un problema en la definición de los
atributos de las clases que se descubren durante el
análisis evitará efectos laterales que pueden ocurrir
si el problema no se descubriera hasta el diseño o
implementación (o incluso la siguiente iteración del
análisis).
Por ejemplo, considérese una clase en la que el núme-
ro de atributos se definen durante la primera iteración
del AOO. Un atributo externo (extraño), se agrega a la
clase (debido al malentendido del dominio de proble-
ma). Se especifican dos operaciones para manipular el
atributo. Se realiza una revisión y un experto en el domi-
nio señala el error. Eliminando el atributo irrelevante
en esta etapa, los problemas y esfuerzos innecesarios se
evitan durante el análisis:
1. Pueden haberse generado subclases especiales para
adoptar (alojar) el atributo innecesario o excepcio-
nes a él. El trabajo involucrado en la creación de sub-
clases no necesarias se ha evitado.
2. Una mala interpretación de la definición de la clase
puede conducir a relaciones de clases incorrectas o
irrelevantes.
408
3. El comportamiento del sistema o sus clases pueden
caracterizarse inadecuadamente, para alojar el atri-
buto irrelevante.
Si el error no se descubre durante el análisis y se pro-
paga más allá, los siguientes problemas pueden ocurrir
(y tendrán que evitarse con una nueva revisión) duran-
te el diseño:
1. La localización impropia de la clase a un subsistema
y/o tareas puede ocurrir durante el diseño del sis-
tema.
2. El trabajo del diseño innecesario tendrá que ser recu-
perado, para crear el diseño procedimental, para las
operaciones que afecten al atributo innecesario.
3. El modelo de mensajes (mensajería) será incorrecto
(debido a que deben diseñarse mensajes para las ope-
raciones innecesarias).
Si el error permanece sin detectarse durante el diseño
y pasa a la actividad de codificación, se gastará un
esfuerzo considerable para generar el código que imple-
menta un atributo innecesario, dos operaciones innece-
sarias, mensajes que controlan comunicaciones entre
objetos, y muchos otros aspectos relacionados. Además,
la prueba de la clase absorberá más tiempo del necesa-
rio. Una vez que se encuentra el problema en su totali-
dad, debe llevarse a cabo la modificación del sistema,
teniendo siempre presentes los posibles efectos colate-
rales producidos por el cambio.
Existe un viejo dicho que dice ((cortar por lo sono)).
Si pierde tiempo revisando los modelos de A00
y 000, después lo gonorá.
Durante las etapas finales de su desarrollo, los mode-
los de A 0 0 y de D O 0 proporcionan información subs-
tancial acerca de la estructura y comportamiento del
sistema. Por esta razón, estos modelos deben estar some-
tidos a una revisión rigurosa, antes de la generación de
código.
Todos los modelos orientados a objetos deben ser
probados (en este contexto, el término «prueba» se uti-
liza para incorporar revisiones técnicas formales), para
asegurar la exactitud, compleción y consistencia
[MGR94], dentro del contexto de la sintaxis, semánti-
ca y pragmática del modelo [LIN94].

Los modelos de análisis y diseño no pueden probarse en
el sentido convencional, ya que no pueden ejecutarse. Sin
embargo, se pueden utilizar las revisiones técnicas for-
males (Capítulo 8) para examinar la exactitud y consis-
tencia de ambos modelos de análisis y diseño.
23.2.1. Exactitud de los modelos de A 0 0 y DO0
La notación y sintaxis que se utiliza para representar los
modelos de análisis y diseño se corresponderá con el
método específico de análisis y diseño, elegido para el
proyecto. Por consiguiente, la exactitud sintáctica se
juzga en el uso apropiado de la simbología; cada mode-
lo se revisa para asegurarse de que se han mantenido
las convenciones propias del modelado.
Durante el análisis y diseño, la exactitud semántica
debe juzgarse basada en la conformidad del modelo con
el dominio del problema en el mundo real. Si el mode-
lo refleja con exactitud el mundo real (al nivel de deta-
lle apropiado a la etapa de desarrollo en la que se revisa
el modelo), entonces es semánticamente correcto. Para
determinar si el modelo en realidad refleja el mundo real,
debe presentarse a expertos en el dominio del problema,
quienes examinarán las definiciones de las clases y sus
jerarquías, para detectar omisiones o ambigüedades. Las
relaciones entre clases (conexiones de instancia) se eva-
lúan para determinar si reflejan con exactitud conexio-
nes del mundo real'.
23.2.2. Consistencia de los modelos de A 0 0
y DO0
La consistencia de los modelos de A 0 0 y DO0 debe
juzgarse «considerando las relaciones entre entidades
dentro del modelo. Un modelo inconsistente tiene repre-
sentaciones en una parte, que no se reflejan correcta-
mente en otras partes del modelo» [MGR94].
Para evaluar la consistencia, se debe examinar cada
clase y sus conexiones a otras clases. Un modelo clase-
responsabilidad-colaboración (CRC), y un diagrama
objeto-relación pueden utilizarse para facilitar esta acti-
vidad. Como se comentó en el Capítulo 2 1, el modelo
CRC se compone de una tarjeta índice CRC. Cada tar-
jeta CRC muestra el nombre de la clase, sus responsa-
bilidades (operaciones) y sus colaboradores (otras clases
a las que se envían mensajes y de las cuales depende
para el cumplimiento de sus responsabilidades). Las
colaboraciones implican una serie de relaciones (por
ejemplo, conexiones), entre clases del sistema OO. El
modelo objeto-relación proporciona una representación
I Los casos de uso poseen un valor incalculable, en el seguimiento
de los modelos de análisis y diseño, frente a los escenarios del mundo
real para el sistema OO.
409
CAPfTULO 23 PRUEBAS ORIENTADAS A OBIETOS
gráfica de las conexiones entre clases. Toda esta infor-
mación se puede obtener del modelo de A 0 0 (Capítu-
lo 21).
Modelos de A00
Para evaluar el modelo de clases, se recomiendan los
siguientes pasos [MGR94]:
1. Revisar el modelo CRC y el modelo objeto-relación.
-Realizar un control cruzado, para asegurarse de que
todas las colaboraciones implicadas en el modelo de
A 0 0 hayan sido representadas adecuadamente.
¿Qué pasos deben seguirse
para revisar el modelo
de clases?
2. Inspeccionar la descripción de cada tarjeta CRC,
para determinar si alguna responsabilidad delegada
es parte de la definición del colaborador. Por ejem-
plo, considérese una clase definida para un sistema
de control de punto de venta, llamada venta a cré-
dito. Esta clase tiene una tarjeta CRC, que se ilustra
en la Figura 23.1.
Para esta colección de clases y colaboraciones, se
pregunta si alguna responsabilidad (por ejemplo, leer
la tarjeta de crédito) se cumple si se delega al cola-
borador nombrado (Tarjeta de crédito). Esto signi-
fica que la clase Tarjeta de crédito posee una
operación para ser leída. En este caso, la respuesta
es «Sí». El objeto-relación se recorre,. para asegu-
rarse de que todas las conexiones son válidas.
Sugerencias adicionalespara conducir una revisión
del modelo CRC se presentan en el Capíhrlo 21.
3. Invertir la conexión para asegurarse de que cada cola-
borador que solicita un servicio recibe las peticiones
de una fuente razonable. Por ejemplo, si la clase Tar-
jeta de crédito recibe una petición de cantidad de
compra de la clase Venta a crédito, existirá un pro-
blema. Tarjeta de crédito no reconoce la cantidad de
compra.
INGENlERíA DEL SOFTWARE. U N ENFOQUE PRACTICO
1 Nombre de la clase: venta a crédito
permanente, protegida
1 Leer tarieta de crédito Tarjeta de crédito
I de usuario. El diseño de objetos presenta los detalles de
Obtener autorización
II
Autorización de crédito
I cada clase, y las actividades de mensajería necesarias
I Enviar por correo
cantidad de compra I Etiqueta de producto
I 11 Vendedor
FIGURA 23.1. Un ejemplo de tarjeta índice CRC usada para
revisión.
4. Utilizando las conexiones invertidas, ya examina-
das en el paso 3, determinar si otras clases se requie-
ren y si las responsabilidades se han repartido
adecuadamente entre las clases.
5. Determine si las responsabilidades muy solicita-
das, deben combinarse en una sola responsabili-
dad. Por ejemplo, leer tarjeta de crédito y obtener
autorización ocurren en cada situación. Por consi-
guiente, se pueden combinar en la responsabilidad
validar petición de crédito, que incorpora obtener
el número de tarjeta de crédito, y conseguir la auto-
rización.
6. Se aplican iterativamente los pasos 1 a 5 para cada
clase, y durante cada evolución del modelo de
AOO.
2 1
La estrategia clásica para la prueba de software de orde-
nador, comienza con «probar lo pequeño» y funciona
hacia fuera haciendo «probar lo grande». Siguiendo la
jerga de la prueba de software (Capítulo 1 S), se comien-
za con las pruebas de unidad, después se progresa hacia
las pruebas de integración y se culmina con las pruebas
de validación del sistema. En aplicaciones convencio-
nales, las pruebas de unidad se centran en las unidades
de programa compilables más pequeñas -1 subpro-
grama (por ejemplo, módulo, subrutina, procedimiento,
componente)-. Una vez que cada una de estas unida-
des han sido probadas individualmente, se integran en
una estructura de programa, mientras que se ejecutan
una serie de pruebas de regresión para descubrir errores,
debidos a las interfaces entre los módulos y los efectos
colaterales producidos por añadir nuevas unidades. Por
410
Una vez que se crea el modelo de DO0 (Capítulo 22),
deben llevarse a cabo también las revisiones del diseño
del sistema y del diseño de objetos. El diseño del siste-
ma describe el producto arquitectónico global, los sub-
sistemas que componen el producto, la manera en que
los subsistemas se asignan a los procesadores, la asig-
nación de clases a subsistemas y el diseño de la interfaz
para implementar las colaboraciones entre clases.
Modelos de DO0
El diseño de sistema se revisa examinando el mode-
lo objeto-comportamientodesarrollado durante el AOO,
y la correspondencia necesaria del comportamiento del
sistema, frente a los subsistemas diseñados para lograr
este comportamiento.
La concurrencia y asignación de tareas también se
revisan dentro del contexto del comportamiento del sis-
tema. Los estados de comportamiento del sistema se eva-
lúan para determinar cuáles existen concurrentemente.
Los escenarios o situaciones de los casos de uso se uti-
lizan para validar el diseño de la interfaz de usuario.
El modelado de objetos debe probarse frente a la red
objeto-relación, para asegurarse de que todos los obje-
tos de diseño contienen los atributos y operaciones nece-
sarias y para implementar las colaboraciones que se
definieron para cada tarjeta CRC. Además, la especifi-
cación detallada de las operaciones (por ejemplo, los
algoritmos que implementan a las operaciones), se revi-
san usando técnicas de inspección convencionales.
. .
último, el sistema se comprueba como un todo para ase-
gurarse de que se descubren los errores en requisitos.
23.3.1. Las pruebas de unidad en el contexto
de la O0
Cuando se considera el software orientado a objetos, el
concepto de unidad cambia. La encapsulación conduce
a la definición de clases y objetos. Esto significa que
cada clase y cada instancia de una clase (objeto), envuel-

ven atributos (datos) y operaciones (también conoci-
dos como métodos o servicios), que manipulan estos
datos. En vez de probar un módulo individual, la uni-
dad más pequeña comprobable es la clase u objeto
encapsulado. Ya que una clase puede contener un núme-
ro de operaciones diferentes, y una operación particu-
lar debe existir como parte de un número de clases
diferentes, el significado de la unidad de prueba cam-
bia drásticamente.
No se puede probar más de una operación a la vez
(la visión convencional de la unidad de prueba), pero sí
como parte de una clase. Para ilustrar esto, considére-
se una jerarquía.de clases, en la cual la operación X se
define para la superclase y se hereda por algunas sub-
clases. Cada subclase utiliza la operación X, pero se
aplica en el contexto de los atributos y operaciones pri-
vadas que han sido definidas para la subclase. Ya que el
contexto en el que la operación X se utiliza varía de
manera sutil, es necesario para probar la operación X
en el contexto de estas subclases. Esto significa que pro-
bar la operación X en vacío (la aproximación de la prue-
ba de unidades tradicionales) es inefectiva en el contexto
orientado a objetos.
8%
CLAVE
l a prueba de software O0 es equivalente a1 módulo
de pruebas unitarias para el software convencional.
No es recomendable comprobar operaciones por separado.
La prueba de clases para el software O 0 es el equiva-
lente de las pruebas de unidad para el software conven-
cional*.A diferencia de las pruebas de unidad del software
convencional que tienden a centrarse en el detalle algo-
ntmico de un módulo y de los datos que fluyen a través
de la interfaz del módulo, la prueba de clases para el soft-
ware O 0 se conduce mediante las operaciones encapsu-
ladas por la clase y el comportamiento de la clase.
23.3.2. Las pruebas de integración
en el contexto O0
Ya que el software orientado a objetos no tiene una
estructura de control jerárquico, las estrategias con-
vencionales de integración descendente (top-down) y
ascendente (bottom-up) tienen muy poco significado.
En suma, la integración de operaciones una por una en
una clase (la aproximación de la integración incremen-
tal convencional), a menudo es imposible por la «inte-
racción directa e indirecta de los componentes que
conforman la clase» [BER93].
Existen dos estrategias diferentes para las pruebas
de integración de los sistemas O 0 [BIN94a]. El prime-
Los métodos de diseño para pruebas de caso, para las clases 00,
se discuten de las Secciones 23.4 a 23.6.
411
CAP1TULO 23 PRUEBAS ORIENTADAS A OBJETOS
ro, las pruebas basadas en hilos, integran el conjunto
de clases requeridas, para responder una entrada o suce-
so al sistema. Cada hilo se integra y prueba individual-
mente. Las pruebas de regresión se aplican para asegurar
que no ocurran efectos laterales. La segunda aproxi-
mación de integración, la prueba basada en el uso,
comienza la construcción del sistema probando aque-
llas clases (llamadas clases independientes), que utili-
zan muy pocas (o ninguna) clases servidoras. Después
de que las clases independientes se prueban, esta secuen-
cia de pruebas por capas de clases dependientes conti-
núa hasta que se construye el sistema completo. A
diferencia de la integración convencional, el uso de dri-
vers y stubs como operaciones de reemplazo, debe evi-
tarse siempre que sea posible.
c VE
l a estrategia de integración de pruebas O0 se centra
en grupos de clases que colaboran o se comunican
de la misma manera.
La prueba de agrupamiento [MGR94] es una fase
en las pruebas de integración de software OO. Aquí, un
agrupamiento de clases colaboradoras (determinadas
por la revisión de los modelos CRC y objeto-relación),
se prueba diseñando los casos de prueba, que intentan
revelar errores en las colaboraciones.
23.3.3. Pruebas de validación en un contexto O 0
Al nivel de sistema o de validación, los detalles de
conexiones de clases desaparecen. Así como la vali-
dación convencional, la validación del software O 0
se centra en las acciones visibles al usuario y salidas
reconocibles desde el sistema. Para ayudar en la cons-
trucción de las pruebas de validación, el probador debe
utilizar los casos de uso (Capítulo 20), que son parte
del modelo de análisis. Los casos de uso proporcionan
un escenario, que tiene una gran similitud de errores
con los revelados en los requisitos de interacción del
usuario.
Aparentemente, todos los métodas de pruebas
de coja negm r i i ~ ~ en
o sel Capftula 17
son aplicablesa la OO.
Los métodos de prueba convencionales de caja negra
pueden usarse para realizar pruebas de validación. Ade-
más, los casos de prueba deben derivarse del modelo de
comportamiento del objeto y del diagrama de flujo de
sucesos, creado como parte del AOO.
INGENIERfA DEL SOFTWARE. UN ENFOQUE PRACTICO
Los métodos de diseño de casos de prueba para soft-
ware orientado a objetos continúan evolucionando. Sin
embargo, una aproximación global al diseño de casos
de prueba O 0 ha sido definida por Bernard [BER93]:
1. Cada caso de prueba debe ser identificado separa-
damente, y explícitamente asociado con la clase a
probar.
2. Debe declararse el propósito de la prueba.
3 . Debe desarrollarse una lista de pasos a seguir, como
consecuencia de la prueba, pero además debe con-
tener [BER93]:
a. definición de una lista de estados, específicos
para el objeto a probar.
b. una lista de mensajes y operaciones, que se ejer-
citarán como consecuencia de las pruebas.
C. una lista de excepciones, que pueden ocurrir con-
forme el objeto se comprueba.
d. una lista de condiciones externas (por ejemplo,
los cambios en el ambiente externo al software,
que debe existir para conducir apropiadamente
las pruebas).
e. información adicional, que ayudará a la com-
prensión e implementación de la prueba.
A diferencia del diseño de pruebas convencional, que
se conduce mediante una visión entrada-proceso-salida
de software, o el detalle algorítmico de los módulos indi-
viduales, la prueba orientada a objetos se enfoca en las
secuencias de operaciones de diseño apropiadas para
probar los estados de una clase.
23.4.1. Implicaciones de los conceptos de O0
al diseño de casos de prueba
Como ya se ha visto, la clase es el objetivo del diseño
de casos prueba. Debido a que los atributos y opera-
ciones se encapsulan, las operaciones de prueba fuera
de la clase son generalmente improductivas. A pesar de
que la encapsulación es un concepto de diseño esen-
cial para la 00, puede crear un obstáculo cuando se
hacen las pruebas. Como menciona Binder [BIN94a],
«la prueba requiere informes del estado abstracto y con-
creto del objeto». La encapsulación puede dificultar un
poco la obtención de esta información. A menos que se
proporcionen operaciones incorporadas para conocer
los valores para los atributos de la clase, una imagen
instantánea del estado del objeto puede ser difícil de
adquirir.
Concepto de DO0 que debe usarse con extrema precaución.
412
3
Referencia Web
Una colección excelente de publicaciones, fuentes
y bibliografías de pruebas O0 puede encontrarse
en www.rbsc.com
La herencia también conduce a retos adicionales para
el diseñador de casos de prueba. Ya se ha dicho que cada
nuevo contexto de uso requiere repetir la prueba, aún y
cuando se haya logrado la reutilización. Además, la
herencia múltiple' complica mucho más las pruebas,
incrementando el número de contextos para los que se
requiere la prueba [BIN94a]. Si las subclases instan-
ciadas de una superclase se utilizan dentro del mismo
dominio de problema, es probable que el conjunto de
casos de prueba derivados de la superclase puedan usar-
se para la prueba de las subclases. De cualquier mane-
ra, si la subclase se utiliza en un contexto enteramente
diferente, los casos prueba de la superclase serán esca-
samente aplicables, y tendrá que diseñar un nuevo con-
junto de pruebas.
23.4.2. Aplicabilidad de los métodos convencio-
nales de diseño de casos de prueba
Los métodos de «caja blanca» descritos en el Capítulo 17
pueden aplicarse a las operaciones definidas para una cla-
se. Técnicas como el camino básico, pruebas de bucle o
técnicas de flujo de datos pueden ayudar a asegurar que
se ha probado cada sentencia de la operación. De cual-
quier modo, la estructura concisa de muchas operaciones
de clase provoca que algunos defiendan que el esfuerzo
aplicado a la prueba de «caja blanca» debe ser redirigido
adecuadamente a las pruebas, a un nivel de clase.
Los métodos de prueba de «caja negra» son tan apro-
piados para los sistemas 00,como lo son para los siste-
mas desarrollados utilizando los métodos convencionales
de ingeniería de software. Como se dijo al principio del
capítulo, los casos de uso pueden proporcionar datos Úti-
les en el diseño de pruebas de «caja negra», y pruebas
basadas en estados [AMB95].
23.4.3. Pruebas basadas en errores4
El objetivo de las pruebas basadas en errores dentro de
un sistema 00,es diseñar pruebas que tengan una alta
probabilidad de revelar fallos. Ya que el producto o sis-
tema debe adaptarse a los requerimientos del cliente, la
Las Secciones 23.4.3 a 23.4.6 han sido adaptadas de un artículo'
de Brian Marick, divulgado en el grupo de noticias de internet
comp.testing. Esta adaptación se ha incluido con el permiso del autor.
Para adentrarse más en la discusión de este tema, véase [MAR94].

planificación preliminar requerida para llevar a cabo la
prueba basada en fallos comienza con el modelo de aná-
lisis. El probador busca fallos posibles (por ejemplo, los
aspectos de implementación del sistema que pueden
manifestarse en defectos). Para determinar si existen
estos fallos, los casos de prueba se diseñan para probar
el diseño o código.
CLAVE
l a estrategia consiste en hacer hipótesis de una serie
de posibles fallos, y luego conducir las pruebas
para comprobar las hipótesis.
Considérese un ejemplo simple5. Los ingenieros de
software generalmente cometen errores en los límites
del problema. Por ejemplo, cuando se prueba una ope-
ración SQRT que genera errores para números negati-
vos, se sabe probar los límites: un número negativo
cercano al cero y el cero mismo. El «cero mismo» com-
prueba si el programador ha cometido un error como:
If( x > O ) calcular-la-raíz-cuadrada(
En lugar de lo correcto
If ( x >= O I calcular-la-raíz-cuadrada(
Como otro ejemplo, considérese la expresión booleana
siguiente:
if (a && !b / / c )
Ya que la prueba basada en fallos se da en un nivel
detallada, se reservo mejor para las operaciones
y clases que son críticas a sospechosas.
Las pruebas de multicondición y técnicas relaciona-
das examinan las faltas posibles con toda seguridad en
esta expresión, como, por ejemplo,
&& debería de ser II
! se ignoró donde se necesitaba
Y debería haber un paréntesis alrededor de !b IIc
Para cada error probable, se diseñan casos de prue-
ba, que forzarán a la condición incorrecta a fallar. En la
expresión anterior, (a=O, b=O, c=O) forzarán a que la
expresión se evalúefalsa. Si el && hubiera sido II, el
código hubiera dado el resultado incorrecto y el control
habría seguido la rama errónea.
Desde luego que la efectividad de estas técnicas
depende de cómo los probadores perciben el «fallo pro-
bable». Si los fallos verdaderos en un sistema O 0 se
El código presentado en ésta y en las siguientes secciones utiliza la
sintaxis de C++. Para mayor información, véase cualquier buen libro
de C++.
CAPfTULO 23 PRUEBAS ORIENTADAS A O B J E T O S
perciben como «improbables», entonces esta aproxi-
mación no es en realidad mejor que la técnica de pme-
bas aleatorias. De cualquier manera, si los modelos de
análisis y diseño pueden proporcionar la visión de lo
que parece andar mal, entonces las pruebas basadas en
errores pueden encontrar un número significativo de
errores con esfuerzos relativamente pequeños.
Las pruebas de integración buscan fallos probables
en operaciones o mensajes de conexión. Tres tipos de
fallos se encuentran en este contexto: resultados ines-
perados, uso incorrecto de operaciones/mensajes, invo-
caciones incorrectas. Para determinar fallos probables
cuando las funciones (operaciones) se invocan, se debe
examinar el comportamiento de la operación.
¿Qué tipo de fallos
se encuentran en llamadas
o operaciones y conexiones
de mensajes?
Las pruebas de integración se aplican tanto a atribu-
tos como a operaciones. Los «comportamientos» de un
); objeto se definen por los valores que se asignan a sus
atributos. Las pruebas deben verificar los atributos para
determinar si se obtienen valores apropiados para los
);
distintos tipos de comportamientos de los objetos.
Es importante hacer notar que las pruebas de inte-
gración intentan encontrar los errores en el objeto clien-
te, no en el servidor. Dicho en términos comunes, el
enfoque de las pruebas de integración es determinar si
el error existe en el código de invocación, no en el códi-
go invocado. La invocación a operaciones se utiliza como
una pista, una forma de encontrar los requerimientos de
la prueba que validen el código de invocación.
23.4.4. El impacto de la programación O 0 en las
pruebas
Hay distintas maneras en que la programación orienta-
da a objetos puede tener un impacto en las pruebas.
Dependiendo del enfoque de la POO.
Algunos tipos de fallos se vuelven menos probables
(no vale la pena probar).
Algunos tipos de fallos se vuelven más probables
(vale la pena probar).
Aparecen algunos tipos nuevos de fallos.
413
INGENIERfA DEL SOFTWARE. UN ENFOQUE PRÁCTICO
Cuando se invoca una operación es difícil decir exac-
tamente qué código se ejecuta. Esto es, la operación
debe pertenecer a una de muchas clases. Incluso, pue-
de ser difícil determinar el tipo exacto o clase de un
parámetro. Cuando el código lo acceda puede obtener-
se un valor inesperado. La diferencia puede entenderse
considerando la llamada a una función convencional:
x = funcly);
Para el software convencional, el probador debe con-
siderar todos los comportamientos atribuidos a func y
nada más. En un contexto 00,el probador debe consi-
derar los comportamientos de base:func( ), de deriva-
da:func( ), y así sucesivamente. Cada vez que func se
invoca, el probador debe considerar la unión de todos
los comportamientos distintos. Esto es más fácil si se
siguen prácticas de diseño O 0 adecuadas, y se limitan
las diferencias entre superclases y subclases (en el len-
guaje de C++, estas se llaman clases base y clases deri-
vadas).
La aproximación a las pruebas para clases derivadas
y base es esencialmente la misma. La diferencia es de
contabilidad.
Probar las operaciones de clases es análogo a probar
código que toma un parámetro de la función y luego la
invoca. La herencia es una manera conveniente de pro-
ducir operaciones polimórficas. En la llamada, lo que
importa no es la herencia, sino el polimorfismo. La
herencia hace que la búsqueda de los requisitos de prue-
ba sea más directa.
En virtud de la construcción y arquitectura de soft-
ware, ¿existen algunos tipos de fallos más probables
para un sistema 00, y otros menos probables? la res-
puesta es «sí>>.Por ejemplo, a causa de que las ope-
raciones O 0 son generalmente más pequeñas, se
tiende a gastar más tiempo en la integración ya que
existen más oportunidades de errores de integración.
Así que los errores de integración se vuelven más pro-
bables.
23.4.5. Casos de prueba y jerarquía de clases
Como se explicó previamente en este capítulo, la heren-
cia no obvia la necesidad de probar todas las clases
derivadas. De hecho, puede complicar el proceso de
prueba.
".%
c VE
Aunque se haya comprobado bastante una clase base,
tendrá que comprobar las clases derivadas de ella.
Considérese la situación siguiente. Una clase base
contiene operaciones heredadas y redefinidas. Una
clase derivada redefine operaciones redefinidas para
funcionar en un contexto local. Existe la pequeña duda
de que la d e r i v a d a : : r e d e f i n i d a ( ) debe ser compro-
414
bada, porque representa un nuevo diseño y nuevo
código. Pero, ¿la d e r i v a d a : : h e r e d a d a ( ) debe ser
recomprobada?
Si la d e r i v a d a : h e r e d a d a ( ) invoca a redefini-
da y el comportamiento de redefinida cambia, d e r i -
v a d a : : h e r e d a d a ( ) podría manejar erróneamente
el nuevo comportamiento. De este modo, se necesi-
tan nuevas pruebas aunque el diseño y el código no
hayan cambiado. Es importante hacer notar, sin
embargo, que solo un subconjunto de todas las prue-
bas para d e r i v á d a : : h e r e d a d a ( ) deben rehacerse.
Si parte del diseño y codificación para heredada no
depende de redefinida (por ejemplo, no la llama ni
llama ningún código que indirectamente la llame),
ese código no necesita ser recomprobado en la clase
derivada.
Baserredefinida ( ) y derivada: :redefinida ( )
son dos operaciones diferentes con especificaciones e
implementaciones diferentes. Cada una debería tener
un conjunto de requisitos de prueba, derivadas de la
especificación e implementación. Aquellos requisitos
prueban errores probables: fallos de integración, fallos
de condición, fallos de límites y así sucesivamente. Pero
las operaciones es probable que sean similares por lo
que el conjunto de requisitos de pruebas se solapan.
Cuanto mejor sea el diseño 00, el solapamiento será
mayor. Es necesario desarrollar las nuevas pruebas, solo
para aquellos requisitos de d e r i v a d a : :r e d e f i n i d a ( )
que no fueron satisfechas por pruebas de b a s e : :r e d e -
finida ( ) .
Para concluir, las pruebas de b a s e : :r e d e f i n i d a ( i
se aplican a los objetos de la clase derivada. Las entra-
das de las pruebas deben ser apropiadas para las clases
base y derivada, pero los resultados esperados pueden
diferir en la clase derivada.
23.4.6. Diseño de pruebas basadas
en el escenario
Las pruebas basadas en los errores no localizan dos
tipos de errores: (1) especificaciones incorrectas y ( 2 )
interacción entre subsistemas. Cuando ocurren errores
asociados con especificaciones erróneas, el producto
no realiza lo que el cliente desea. Puede que haga cosas
incorrectas, o puede omitir funcionalidad importante.
Pero en cualquier circunstancia, la calidad (cumpli-
miento de requisitos) se sacrifica. Los errores asocia-
dos con la interacción de subsistemas ocurren cuando
el comportamiento de un subsistema crea circunstan-
cias, (por ejemplo, sucesos, flujo de datos) que causan
que el otro subsistema falle.
Las pruebas basadas en el escenario se concentran
en lo que el usuario hace, no en lo que el producto
hace. Esto significa capturar las tareas (por medio de
los casos de uso) que el usuario tiene que hacer,
después aplicarlas a ellas y a sus variantes como
pruebas.

“ic;% VE
La prueba basada en el escenario descubrirá errores
que ocurren cuando cualquier actor interoctúa
con el software OO.
Los escenarios revelan errores de interacción. Pero
para llevar a cabo esto, los casos de prueba deben ser
más complejos y realistas que las pruebas basadas en
los errores. Las pruebas basadas en el escenario tienden
a validar subsistemas en una prueba sencilla (los usua-
rios no se limitan al uso de un subsistema a la vez).
A manera de ejemplo, considérese el diseño de prue-
bas basadas en el escenario, para un editor de texto. Uti-
lícense los siguientes casos:
Caso de uso: Prepara la versión final.
Aspectos de fondo: No es inusual imprimir el borrador «final»,
leerlo y descubrir algunos errores incómodos que no eran tan
obvios en la imagen de la pantalla. Este caso de uso describe
la secuencia de pasos que ocurren cuando esto pasa.
1. Imprimir el documento entero.
2. Rondar dentro del documento, cambiar algunas páginas.
3. Al momento en que cada página se cambia, se imprime.
4. Algunas veces se imprime una serie de páginas.
Este escenario describe dos elementos: una prueba
y unas necesidades específicas del usuario. Las necesi-
dades del usuario son obvias: (1) un método para impri-
mir una sola página y (2) un método para imprimir un
rango de páginas. Hasta donde va la prueba, existe la
necesidad de editar después de imprimir (así como lo
contrario). El probador espera descubrir que la función
de impresión causa errores en la función de edición; esto
es, que las dos funciones de software sean totalmente
independientes.
Caso de uso: Impresión de una nueva copia.
Aspectos de fondo: Se pide una copia reciente. Debe ser
impresa:
1. Abrir el documento
2. Imprimirlo.
3. Cerrar el documento.
Aunque lo pruebo basada en el escenario tiene su mérito,
encontrar6 uno recompenso mayor revisondo los cosos de
uso cuando se desarrollan durante el AOO.
Una vez más, la aproximación de las pruebas es rela-
tivamente obvia. Excepto que el documento no apare-
ció fuera de ningún lugar. Fue creado en una tarea
anterior. ¿La tarea anterior afecta a esta?
En los editores modernos, los documentos registran
como fueron impresos por última vez. Por omisión, se
imprimen de la misma forma la siguiente vez. Después
del escenario preparar la versiónfinal, con solo selec-
415
CAPÍTULO 23 PRUEBAS ORIENTADAS A O B l E T O S
cionar «imprimir» en el menú y presionando el botón
«imprimir» en la caja de diálogo, se conseguirá que la
última página corregida se imprima de nuevo. Así que,
de acuerdo con el editor, el escenario correcto debería
ser como el siguiente:
Caso de uso: Imprimir una nueva copia.
1. Abrir el documento.
2. Seleccionar «imprimir» en el menú.
3. Comprobar si se imprime un rango de páginas; si es así, pre-
sionar para «imprimir» el documento entero.
4. Presionar en el botón de impresión.
5. Cerrar el documento.
Pero este escenario indica una especificación poten-
cial de error. El editor no hace lo que el usuario razo-
nablemente espera. Los clientes generalmente pasarán
por alto la opción de rango de páginas del paso 3 en el
ejemplo anterior. Se incomodarán cuando enciendan la
impresora y encuentren una página cuando ellos que-
rían 100. Los clientes fastidiados significan errores de
especificación.
Un diseñador de casos de prueba debe olvidar la depen-
dencia en un diseño de pruebas, pero es probable que el
problema aparezca durante las pruebas. El probador ten-
dría entonces que lidiar con la respuesta probable, «¿Esa
es la forma como se supone que debe funcionar?».
23.4.7. Las estructuras de pruebas superficiales
y profundas
La estructura superficial se refiere a la estructura visi-
ble al exterior de un programa OO. Esto es, la estruc-
tura que es inmediatamente obvia al usuario final. En
vez de llevar a cabo funciones, los usuarios de muchos
sistemas O 0 deben de proveerse de objetos para mani-
pular de alguna forma. Pero sin importar la interfaz, las
pruebas aún se basan en las tareas de los usuarios. Cap-
turar estas tareas involucra comprensión, observación,
y conversar con usuarios representativos (y tantos usua-
rios no representativos como valga la pena considerar).
Debe haber alguna diferencia en detalle con seguri-
dad. Por ejemplo, en un sistema convencional con una
interfaz orientada a comandos, el usuario debe usar la
lista de comandos como una lista de control de pruebas.
Si no existen escenarios de prueba para ejercitar un
comando, las pruebas probablemente pasaron por alto
algunas tareas del usuario (o la interfaz contiene coman-
dos inútiles). En una interfaz basada en objetos, el veri-
ficador debe usar la lista de todos los objetos, como una
lista de control de pruebas.
“56L
C VE
l o estructura de pruebas se da en dos niveles:
(1) pruebas que validan la estructura visible
por el usuario final, (2) pruebas diseñadas
para validar la estructura interna del programa.
I N G E N I E R ~ ADEL SOFTWARE. U N ENFO Q UE PR A CTICO
Las mejores pruebas se dan cuando el diseñador
observa al sistema de una manera nueva o poco con-
vencional. Por ejemplo, si el sistema o producto tiene
una interfaz basada en comandos, pruebas más com-
pletas se darán si el diseñador de casos supone que las
operaciones son independientes de los objetos. Hacer
preguntas como <<¿Querrá el usuario usar esta operación
- q u e se aplica sólo al objeto scanner- mientras tra-
baja con la impresora?». Cualquiera que sea el estilo de
la interfaz, el diseño de casos de prueba que ejercita la
estructura superficial debe usar ambos objetos y opera-
ciones, como pistas que conduzcan a las tareas desa-
percibidas.
La estructura profunda se refiere a los detalles téc-
nicos de un programa OO. Esto es, la estructura que se
comprende examinando el diseño y/o el código. La veri-
ficación de la estructura profunda está diseñada para
ejercitar dependencias, comportamientos y mecanismos
de comunicación, que han sido establecidos como par-
te del diseño del objeto y del sistema (Capítulo 22) de
software OO.
En el Capítulo 17 se mencionó que la prueba de soft-
ware comienza «en lo pequeño» y lentamente progresa
hacia la prueba «a grande». La prueba «en pequeño»,
se enfoca en una sola clase y los métodos encapsulados
por ella. La verificación y partición al azar son méto-
dos que pueden usarse para ejercitar a una clase duran-
te la prueba O 0 [KIR94].
23.5.1. La verificación a l azar para c l a s e s O0
A manera de ilustraciones sencillas de estos métodos,
considérese una aplicación bancaria en la cual una cla-
se cuenta contiene las siguientes operaciones: abrir,
configurar,depositar, retirar, consultur saldo, resumen,
Limitecrédito y cerrar [KIR94]. Cada una de estas ope-
raciones debe aplicarse a cuenta, pero algunas limita-
ciones (por ejemplo, la cuenta debe ser abierta antes de
que otras operaciones puedan aplicársele, y cerrada des-
pués de que todas las operaciones hayan sido comple-
tadas) están implícitas en la naturaleza del probletna.
Aún con estas limitaciones, existen muchas combina-
ciones de operaciones. El registro de operaciones míni-
ma de una instancia de cuenta incluye las siguientes
operaciones :
Abrir - coniigurar - depositar - retirar
El número de combinociones posibies poro uno prueba
oleotorio puede crecer mucha. Una estiategio similar
poro lo pruebas de orroys ariagonoles (Cupítulo 17),
puede usarse poro mejorar lo eficiencia de los pruebos.
Los modelos de análisis y diseño se utilizan como
una base para la verificación de la estructura profunda.
Por ejemplo, el diagrama objeto-relación o el diagrama
de colaboración de subsistemas describe colaboracio-
nes entre objetos y subsistemas, que no pueden ser visi-
bles externamente.
El diseño de casos de prueba entonces se pregunta:
«¿Se ha capturado (como una prueba) alguna tarea que
pruebg la colaboración anotada en el diagrama objeto
relación, o en el diagrama d&colaboración de subsiste-
mas? Si no es así, ¿por qué no?»
El diseño de representaciones de jerarquías de clases
proporciona una visión de la estructura de herencia. La
estructura jerárquica se utiliza en la verificación basada
en errores. Considérese la situación en la cual una ope-
ración llamada llamar a( ) tiene un solo argumento, y
ese argumento es unareferencia a la clase base. ¿Qué
ocurrirá cuando llamar a( ) pase a la clase derivada?
¿Cuáles serán las diferencias en comportamientoque pue-
dan afectar a tal función? Las respuestas a estas pregun-
tas pueden conducir al diseño de pruebas especializadas.
Esto representa la secuencia de verificación mínima
para una cuenta. De cualquier modo, pueden existir una
amplia variedad de combinaciones de operaciones posi-
bles, dentro de esta secuencia:
Abrir - configurar - depositar - [depositar / reti-
rar / consultar saldo / resmen / Limitecrédito 1” -
retirar - cerrar
Pueden generarse una variedad de secuencias de ope-
raciones diferentes al azar. Por ejemplo,
Prueba rl: & r L i ~ configurar-
depositar - consultar
~
c<iIdo - resumen retirar - cerrar.
-
Pruehd abrir - coniigurar - depositar - retirar -
depositar ~consuitar saldo - LímiteCré-
d i t o - retirar - cerrar.
Estas y otras pruebas de orden aleatorio se realizan
para probar diferentes registros de operaciones de ins-
tancias de clases.
23.5.2. Prueba de partición al nivel de clases
La prueba de partición reduce el número de casos de prue-
ba requeridos para validar la clase, de la misma forma que
la partición equivalente (Capítulo 17) para software con-
vencional. Las entradas y salidas se clasifican, y los casos
de prueba se diseñan, para validar cada categoría. Pero
- cerrar. ¿cómo se derivan las categorías de partición?
¿Qué opciones de pruebas
están disponibles a nivel
de clases?
La partición basada en estados clasifica las opera-
ciones de clase basada en su habilidad de cambiar el
416

estado de la clase. Una vez más, considerando la clase
cuenta, operaciones de estado incluyen a depositar y
retirar, y considerando que las operaciones de no-esta-
do incluyen a consultar saldo, resumen y LímiteCrédi-
to, las pruebas se diseñan de manera que las operaciones
que cambian el estado, y aquellas que no lo cambian,
se ejerciten separadamente. Entonces:
Prueba pI: abrir - configurar - depositar - depositar
- retirar retirar - cerrar.
-
Prueba p2: abrir - configurar - depositar ~ resumen
Límitecrédito - retirar cerrar.
~
La prueba pi cambia el estado, mientras que la prue-
ba p2 ejercita las operaciones que no cambian el estado
(excepto por las necesarias de la secuencia mínima de
prueba).
El diseño de casos de prueba se vuelve más complica-
do cuando la integración del sistema O 0 comienza. Es
en esta etapa en que la verificación de colaboraciones
entre clases comienza. Para ilustrar «la generación de
casos de prueba interclasew [KIR94], se expande el
ejemplo de la aplicación bancaria introducida en la Sec-
ción 23.5, para incluir las clases y colaboraciones de la
Figura 23.2. La dirección de las flechas en la Figura
indica que se invocan como consecuencia de colabora-
ciones implícitas a los mensajes.
Así como la verificación de clases individuales, la
verificación de colaboraciones de clases puede com-
pletarse aplicando métodos de partición y al azar, así
como pruebas basadas en el escenario y pruebas de com-
portamiento.
\
23.6.1. Prueba de múltiples clases
Kirani y Tsai [KIR94] sugieren la secuencia siguiente
de pasos, para generar casos de prueba aleatorios para
múltiples clases:
1. Para cada clase cliente, utilice la lista de operacio-
nes de clase, para generar una serie de secuencias de
pruebas al azar. Las operaciones enviarán mensajes
a las otras clases servidoras.
2. Para cada mensaje que se genere, determine la clase
colaboradora y la operación correspondiente en el
objeto servidor.
3. Para cada operación en el objeto servidor (invocada
por mensajes enviados por el objeto cliente), deter-
mine los mensajes que transmite.
4. Para cada uno de los mensajes, determine el siguiente
nivel de operaciones que son invocadas, e incorpore
éstas a la secuencia de pruebas.
Para ilustrar [KIR94], considérese una secuencia de
operaciones para la clase banco relativa a una clase
ATM (Figura 23.2):
CAPfTULO 23 PRUEBAS ORIENTADAS A O B J E T O S
La partición basada en atributos clasifica las opera-
ciones de clase basada en los atributos que ellas usan.
Para la clase cuenta, los atributos saldo y LímiteCré-
dito pueden usarse para definir particiones. Las opera-
ciones se dividen en tres particiones: (1) Operaciones
que utilizan Limitecrédito, (2) operaciones que modi-
fican Límitecrédito, y (3) operaciones que no utilizan
o modifican Límitecrédito. Las secuencias de prueba
se diseñan por cada partición.
-
La partición basada en categorías clasifica las opera-
ciones de la clase basadas en la función genérica que cada
una lleva a cabo. Por ejemplo, las operaciones en la cla-
se cuenta pueden clasificarse en operaciones de iniciali-
zación (abrir, configurar),operaciones computacionales
(depositar, retirar), consultas (saldo, resumen, Límite-
Crédito) y operaciones de terminación (cerrar).
verifcuenta - verifNiP - [[verifpoliza -
regRetirar1i reqDepositar / reqInfoCuenta 1"
ObtenerCantidadEfectivo
Depósito
I
FIGURA 23.2. Grafo de colaboraciones de clase
para una aplicación bancaria (KIR941.
Un caso de prueba aleatorio para la clase banco
podría ser:
Prueba r3 = verifcuenta ~ verifNIP - reqDepositar
Con la finalidad de considerar a los colaboradores
involucrados en esta prueba, los mensajes asociados con
cada una de las operaciones mencionadas en el caso de
prueba r, deben ser tomados en cuenta. Banco debe cola-
borar con infovalidación para ejecutar verifcuenta y
veriflZP. Banco debe colaborar con cuenta para ejecu-
tar reqDepositar. De aquí que un nuevo caso de prueba,
que ejercite estas colaboraciones, es:
[validCuenta~,,,,,,,~,~~]
Prueba rq = verifCuentaH~31)Lo
- VerifNIpHanLo ,riscló,,l
- [Val idNIp,nfc,,dal
- reqDeposit a r - [DepositarcucnLal
La aproximación para la prueba de partición de múl-
tiples clases es similar a la aproximación usada para la
417
INGENlERfA DEL SOFTWARE. UN ENFOQUE PRdCTICO
prueba de partición de clases individuales. La manera
como una sola clase se particiona se discutió en la Sec-
ción 23.4.5. De cualquier modo, la secuencia de prue-
bas se extiende para incluir aquellas operaciones que se
invocan por los mensajes a clases colaboradoras. Una
aproximación alternativa basa las pruebas por partición
en las interfaces de una clase en particular. Haciendo
referencia a la Figura 23.2, la clase banco recibe men-
sajes de las clases ATM y Cajero. Los métodos inclui-
dos en banco pueden probarse particionándolos en
aquellos que sirven a ATM y aquellos que sirven a Caje-
ro. La partición basada en estados (Sección 23.4.9), pue-
de usarse para refinar aún más las particiones.
23.6.2. Prueba derivada de los modelos
de comportamiento
En el Capítulo 2 1 se discutió el uso del diagrama de tran-
sición de estados, como el modelo que representa el com-
portamiento dinámico de una clase. El DTE (Diagrama
de transición de estados) para una clase puede usarse
para ayudar a derivar una secuencia de pruebas, que ejer-
citarán el comportamiento dinámico de la clase (y aque-
llas clases que colaboran con ella). La Figura 23.3
[KIR94] ilustra una DTE para la clase cuenta explica-
da con anterioridad6. Con referencia a la Figura, las tran-
siciones iniciales se mueven por los estados cuenta vacía
y configura cuenta. Un retiro final y cierre causan que
la clase cuenta haga transiciones a los estados nohace-
trabajo de cuenta y cuenta muerta, respectivamente.
Preparar
cuenta
Depósito (inicial)
Depósito
con la
Balance cuenta
Crédito
Retirar
1 Retirar todo (final)
A ancho».
FIGURA 23.3.Diagrama de transición de estados
para la clase cuenta [KIR94].
Las pruebas a diseñarse deben alcanzar una cober-
tura de todos los estados [KIR94]. Eso significa que las
secuencias de operaciones deben causar que la clase
cuenta haga transiciones por todos los estados:
La simbologia UML se utiliza para el DTE que se ilustra en la Figura
23.3. Difiere ligeramente de la simbología usada para los DTEs en la
parte tres de este libro.
418
Prueba s l : abrir - preparar cuenta - depositar ( i n i -
c i a l ) - r e t i r o ( f i n a l ) - cerrar
Nótese que esta secuencia es idéntica a la secuencia
mínima de pruebas, discutida en la Sección 23.5.1. Si
se agregan secuencias de prueba adicionales a la secuen-
cia mínima:
Prueba s2: abrir - preparar cuenta - depositariini-
c i d - saldo - crédito - r e t i r o (final) -
cerrar.
Prueba s3: preparar cuenta - depositar ( i n i c i a l ) -
r e t i r o - infocuenta r e t i r o (final) cerrar.
~
Se pueden derivar aún más casos de prueba, para ase-
gurarse de que todos los comportamientos para la cla-
se han sido adecuadamente ejercitados. En situaciones
en las que el comportamiento de la clases, resulte en
una colaboración con una o más clase se utilizan múl-
tiples DTEs para registrar el flujo de comportamientos
del sistema.
El modelo de estado puede ser recorrido <<primeroa
lo ancho» [MGR94]. En este contexto, primero a lo
ancho implica que un caso de prueba valida una sola
transición y después, cuando se va a verificar una nue-
va transición, se utilizan sólo las transiciones previa-
mente verificadas.
Considérese el objeto tarjeta-de-crédito de la Sec-
ción 23.2.2. El estado inicial de tarjeta-de-crédito
es indefinido (es decir, no se ha proporcionado un
número de tarjeta de crédito). Una vez leída la tarjeta
de crédito durante una venta, el objeto asume un esta-
do definido; esto significa que los atributos número
tarjeta y fecha expiración, se definen junto con iden-
tificadores específicos del banco. La tarjeta de crédi-
to se envía, cuando se envía la autorización, y es
aprobada cuando la autorización se recibe. La transi-
ción de tarjeta-de-créditode un estado a otro puede
probarse generando casos de prueba, que hagan que la
transición ocurra. Un enfoque «primero a lo ancho»
en este tipo de pruebas, puede no validar el envío antes
de que se ejercite indefinida y definida. Si lo hiciera,
haría uso de transiciones que no han sido verificadas
con anterioridad, y violaría el criterio «primero a lo
Referencia Web/ ’
Uno extensa colección de ((consejos sobre
pruebas 00)) (incluyendo muchos referencias
útiles) puede encontrarse en:
www.kinetita.tom/ootips/

., . .
El objetivo global de la verificación orientada a objetos
-encontrar el máximo número de errores con un míni-
mo de esfuerz-, es idéntico al objetivo de prueba del
software convencional. Pero la estrategia y tácticas para
la prueba O 0 difieren de modo significativo. La visión
de verificación se amplía, para incluir la revisión de
ambos modelos de diseño y de análisis.
En resumen, el enfoque de prueba se aleja del com-
ponente procedimental (el módulo) hacia la clase. Ya que
los modelos d e análisis y diseño O 0 y el código fuente
resultante se acoplan semánticamente, la prueba (a mane-
ra de revisiones técnicas formales) comienza en estas acti-
vidades de ingeniería. Por esta razón, la revisión de los
métodos CRC, objeto-relación y objeto-comportamiento,
pueden verse como una primera etapa de prueba.
Una vez que la PO0 ha sido concluida, las prue-
bas de unidad se aplican a cada clase. El diseño de
pruebas para una clase utiliza una variedad de méto-
dos: pruebas basadas en errores, las pruebas al azar
y las pruebas por partición. Cada uno de estos méto-
dos ejercita las operaciones encapsuladas por la cla-
se. Las secuencias de pruebas se diseñan para
asegurarse de que las operaciones relevantes se ejer-
[AMB95] Ambler, S., «Using Use Cases», Software Deve-
lopment, Julio de 1995, pp. 53-61.
[BER93] Berard, E.V., Essays on Ohject-Oriented Software
Engineering, vol. 1, Addison-Wesley, 1993.
[BIN94a] Binder, R.V., «Testing Object-Oriented Systems:
A Status Report», American Programmer, vol. 7 , n.' 4,
Abril de 1994, pp. 23-28.
[BIN94b] Binder, R.V., «Object-Oriented Software Testing»,
CACM, vol. 37, n.' 9, Septiembre de 1994, p. 29.
[CHA93] DeChampeaux, D., D. Lea y P. Faure, Ohject-Orien-
ted System Development, Addison-Wesley, 1993.
[FIC92] Fichman, R., y C. Kemerer, «Object-Oriented and
conceptual Design Methodologies», Computer, vol. 25,
n.' 10, Octubre de 1992, pp. 22-39.
23.1. Describa con sus propias palabras por qué la clase es
la más pequeña unidad razonable para las pruebas dentro de
un sistema OO.
23.2. ¿Por qué debemos probar de nuevo las subclases ins-
tanciadas de una clase existente si ésta ya ha sido probada por
completo? ¿Podernos usar los casos de prueba diseñados para
dicha clase?
23.3. ¿Por qué debe comenzar la «prueba» con las activida-
des de A 0 0 y DOO?
419
CAPfTULO 23 PRUEBAS ORIENTADAS A OBJETOS
. .
. .,
, .,
',
.. . .... ..
.
5 ..
.:
\
j .
, J n' 1
citen. El estado de la clase representada por los valo-
res de sus atributos se examina, para determinar si
persisten errores.
La prueba de integración puede llevarse a cabo utili-
zando una estrategia basada en hilos o basada en el uso.
La estrategia basada en hilos integra el conjunto de cla-
ses, que colaboran para responder a una entrada o suce-
so. Las pruebas basadas en el uso construyen el sistema
en capas, comenzando con aquellas clases que no usan
clases servidoras. Los métodos de diseño de integración
de casos de prueba pueden usar pruebas al azar y por par-
tición. En suma, las pruebas basadas en el escenario y las
pruebas derivadas de los modelos de comportamiento pue-
den usarse para verificar una clase y sus colaboraciones.
Una secuencia de pruebas registra el flujo de operacio-
nes, a través de las colaboraciones de clases.
La prueba de validación de sistemas O 0 está orien-
tada a caja negra y puede completarse aplicando los
mismos métodos de prueba de caja de negra discutidos
para el software convencional. Sin embargo, las prue-
bas basadas en el escenario dominan la validación de
sistemas 00, haciendo que el caso de uso sea el con-
ductor primario para las pruebas de validación.
[KIR94] Kirani, S., y W.T. Tsai, «Specification and Verifica-
tion of Object-Oriented Programw, Technical Report TR
94-96, Computer Science Department, University of Min-
nesota. Diciembre de 1994.
[LIN94] Lindland, O.I., et al., «Understanding Quality in Con-
ceptual Modelinp, IEEE Software, vol. 11, n.' 4, Julio de
1994, pp. 42-49.
[MAR941 Marick, B., The Crafi of Software Testing, Prenti-
ce Hall. 1994.
[MGR94] McGregor, J.D., y T.D. Korson, dntegrated Object-
Oriented Testing and Development Processes», CACM,
vol. 37, n." 9, Septiembre de 1994, pp. 59-77.
23.4. Derive un conjunto de tarjetas índice CRC para Hogar-
Seguro y ejecute los pasos señalados en la Sección 23.2.2 para
determinar si existen inconsistencias.
23.5. ¿Cuál es la diferencia entre las estrategias basadas en hilos
y aquellas estrategias basadas en uso para las pruebas de inte-
gración? ¿Cómo cabe la prueba de agrupación en ellas?
23.6. Aplique la prueba aleatoria y la de partición a tres cla-
ses definidas en el diseño del sistema Hogarseguro produci-
do por usted en el Problema 22.12.
INGENIERiA DEL SOFTWARE. UN ENFOQUE PRACTICO
Produzca casos de prueba que indiquen las secuencias de ope-
raciones que se invocarán.
23.7. Aplique la prueba de múltiples clases y las pruebas deri-
vadas del modelo de comportamiento al diseño de HogarSe-
guro.
23.8. Obtenga pruebas usando los métodos señalados en los
Problemas 23.6 y 23.7 para el sistema SSRB descrito en el
Problema 22.13.
23.9. Obtenga pruebas usando los métodos señalados en los
Problemas 23.6 y 23.7 para el juego de vídeo considerado en
el Problema 22.14.
La literatura para la prueba O 0 es relativamente escasa, aun-
que se ha expandido algo en años recientes. Binder (Testing
Ohject-Oriented Systems: Models, Patterns, und Tools, Addi-
son-Wesley, 2000) ha escrito el tratamiento más extenso del
tema publicado hasta la fecha. Siegel y Muller (Object Orien-
red Software Testing: A Hierurchical Approach, Wiley, 1996)
propusieron una estrategia práctica de prueba para sistemas
OO. Marick (The Craft of Software Testing: Subsystem Tes-
ting Including Ohject-Based and Ohject-Oriented Testing,
Prentice Hall, 1995) cubre la prueba tanto para software con-
vencional como para OO.
Antologías de publicaciones sobre prueba O 0 han sido edi-
tadas por Kung et al. (Testing Object-Oriented Software, IEEE
Computer Society, 1998) y Braude (Ohject Oriented Analysis,
Design and Testing: Selected Readings, IEEE Computer
Society, 1998). Estos tutoriales de IEEE proporcionan una inte-
resante perspectiva histórica en el desarrollo de prueba OO.
420
23.10. Obtenga pruebas usando los métodos señalados en los
Problemas 23.6 y 23.7 para el sistema de e-mail considerado
en el Problema 22.15.
23.11. Obtenga pruebas usando los métodos señalados en los
Problemas 23.6 y 23.7 para el sistema ATC considerado en el
Problema 22.16.
23.12. Obtenga cuatro pruebas adicionales usando cada
uno de los métodos señalados en los Problemas 23.6 y 23.7
para la aplicación bancaria presentada en las Secciones 23.5
y 23.6.
Jorgenesen (Software Testing: A Cruftsman 's Approuch,
CRC Press, 1995) y McGregor y Sykes (Ohject-Oriented
Softwure Development, Van Nostrand Reinhold, 1992) pre-
senta capítulos dedicados al tema. Beizer (Black-Box Tes-
ting, Wiley, 1995) analiza una variedad de métodos de
diseño de casos prueba los cuales son apropiados en un con-
texto OO.
Binder (Testing Object-Oriented Systems, Addison-Wes-
ley, 1996) y Marick [MAR941 presenta tratamientos detalla-
dos de prueba OO. En resumen, muchas de las fuentes
anotadas para el Capítulo 17 son en general aplicables a la
prueba OO.
Una amplia variedad de fuentes de información de prue-
ba orientada a objetos y temas relacionados se encuentran dis-
ponibles en intemet. Una lista reciente a sitios (páginas) web
que son relevantes a la prueba O 0 puede encontrarse en
h ttp://www.pressmanS.com