Pressman, R., Maxim, B. R. (2021). Pruebas de software: a nivel de integración.

En
Ingeniería de software:un enfoque práctico (pp.395-411)(671p.)(9a ed). Ciudad de México:
McGraw Hill Interamericana. (C100528)
CAPÍTULO

PRUEBAS DE SOFTWARE:
A NIVEL DE INTEGRACIÓN 20
Un solo desarrollador tal vez pueda probar componentes de software sin involucrar a otros
miembros del equipo. Esto no aplica en las pruebas de integración, en donde un componente
debe interactuar de forma adecuada con los componentes desarrollados por otros miembros
del equipo. Las pruebas de integración exponen muchas debilidades de los grupos de desa-
rrollo de software que no están unidos como equipo; estas pruebas presentan un interesante
dilema para los ingenieros de software, quienes por naturaleza son personas constructivas.
De hecho, todas las pruebas requieren que los desarrolladores descarten nociones precon-
cebidas sobre la "precisión" del software que se acaba de desarrollar y, mejor que eso, su
trabajo duro sea diseñar casos de prueba para "romper" el software. Esto significa que los
miembros del equipo necesitan poder aceptar sugerencias de otros miembros acerca de que
su código no se comporta de manera adecuada cuando se prueba como parte del incremento
de software más reciente.

integración continua ....................400 de caja blanca ............. ...... ... 397

integración ascendente . . . . . . . . . . . . . . . . 399
integración descendente ................ 398
inteligencia artificial ....................402
patrones ..............................409
pruebas basadas en hilos ................404
pruebas basadas en escenarios ........... 407
pruebas basadas en fallas ...............405
pruebas
de caja negra ....................... 397
de clúster .......................... 404
de humo ...........................400
de integración .............. ... ..... 398
de partición de clases múltiples ........ 405
de regresión ........................402
de validación ...................... .407

ANÁLISIS BREVE

¿Qué es? Las pruebas de integración ensamblan com-
ponentes de una forma que permiten la prueba de
funciones de software cada vez más grandes, con la
intención de encontrar errores mientras se ensambla el
software.
¿Quién lo hace? Durante las primeras etapas de las
pruebas, un ingeniero de software se hace cargo de
todas las pruebas. Sin embargo y a medida que el
proceso de pruebas progresa, es posible que se invo-
lucren los especialistas de pruebas, además de otras
partes interesadas.
¿Por qué es importante? Los casos de prueba deben
diseñarse mediante el uso de técnicas disciplinadas
para asegurar que los componentes se hayan inte-
grado de manera adecuada en el producto de soft-
ware completo.
¿Cuáles son los pasos? La lógica interna del pro-
grama se ejerce mediante el uso de técnicas de di-
seño de casos de prueba de "caja blanca" y los
requerimientos de software se ejercen mediante el
uso de técnicas de diseño de casos de prueba de
"caja negra".
¿Qué es el producto de trabajo? Se diseña y docu-
menta un conjunto de casos de prueba creados para
ejercer lógica interna, interfaces, colaboraciones entre
componentes y requerimientos externos, se definen
los resultados esperados y se registran los resultados
reales.
¿Cómo me aseguro de que lo hice bien? Cuando
comience las pruebas, cambie su punto de vista. ¡Es-
fuércese por "romper" el software! Diseñe los casos
de prueba en forma disciplinada y revise que los ca-
sos de prueba que cree sean detallados.

395
396 PARTE TRES CALIDAD Y SEGURIDAD

Beizer [Bei90] describe un "mito" al que se enfrentan todos los que prueban software.
Escribe lo siguiente: "Hay un mito que dice que, si fuéramos realmente buenos en la pro-
gramación, no habría errores que atrapar ... Hay errores, dice el mito, porque somos malos
en lo que hacemos; y si somos malos en ello, deberíamos sentirnos culpables".
¿Deberían las pruebas infundir culpa? ¿Son las pruebas realmente destructivas? La
respuesta a estas preguntas es ¡No!
Al principio de este libro, hicimos hincapié en el hecho de que el software es solo
un elemento de un sistema más grande basado en computadora. En última instancia, el
software se incorpora con otros elementos del sistema (como hardware, personas, infor-
mación), y se realizan las pruebas de sistema (una serie de pruebas de integración y vali-
dación del sistema). Estas pruebas quedan fuera del alcance del proceso del software y
no las realizan únicamente los ingenieros de software. Sin embargo, las medidas que
se adopten durante el diseño y la prueba del software pueden mejorar de manera consi-
derable la probabilidad de una integración exitosa del software en un sistema de mayor
tamaño.
En este capítulo analizamos las técnicas para las estrategias de pruebas de integración
del software que se aplican a la mayoría de las aplicaciones de software. En el capítulo 21
analizaremos las estrategias de pruebas de software especializadas.

20.1 Fu DAME TOS DE LAS PRUEBAS

DE SOFTWARE

El objetivo de las pruebas es encontrar errores; una buena prueba tiene una alta probabilidad
de encontrar un error. Kaner, Falk y Nguyen [Kan9 3] sugieren los siguientes atributos de
una "buena" prueba:
Una buena prueba tiene una alta probabilidad de encontrar un error. Para lograr este
objetivo, el que hace las pruebas debe entender el software y tratar de desarrollar una imagen
mental acerca de cómo podría fallar el software.
Una buena prueba no es redundante. El tiempo y los recursos para las pruebas son li-
mitados. No tiene sentido realizar una prueba que tenga el mismo propósito que otra. Cada
prueba debe tener un propósito diferente (incluso aunque tengan diferencias sutiles).
Una buena prueba debe ser "la mejor de su clase" [Kan9 3]. En un grupo de pruebas que
tengan una intención similar, las restricciones de tiempo y recursos pueden dictar la ejecu-
ción de solo aquellas pruebas que tengan la mayor probabilidad de descubrir toda una clase
de errores.
Una buena prueba no debe ser demasiado simple ni demasiado compleja. Aunque algunas
veces es posible combinar una serie de pruebas dentro de un caso de prueba, los posibles
efectos secundarios asociados con este enfoque pueden enmascarar errores. En general,
hay que ejecutar cada prueba por separado.
Cualquier producto de ingeniería (y casi cualquier otra cosa) puede probarse en una
de dos formas: ( 1) Si sabemos la función especificada para la que se diseñó un producto,
pueden realizarse pruebas que demuestren que cada función es totalmente operacional y a
la vez buscar los errores en cada función. (2) Si conocemos el funcionamiento interno de
un producto, pueden realizarse pruebas para asegurar que "todos los engranes se combinen";
esto es, que las operaciones internas se realicen de acuerdo con las especificaciones y que
se hayan ejercido todos los componentes internos. El enfoque de la primera prueba adopta
una perspectiva externa de las pruebas y se conocen como pruebas de caja negra. El segundo
CAPÍTULO 20 PRUEBAS DE SOFTWARE : A NIVEL DE INTEGRACIÓN 397

enfoque requiere una perspectiva interna de las pruebas y se denominan pruebas de caja
blanca. 1 Ambas son útiles en las pruebas de integración [Jan 16].

20.1.1 Pruebas de caja negra

Las pruebas de caja negra hacen referencia a las pruebas de integración que se realizan
mediante el ejercicio de las interfaces de los componentes con otros componentes y con
otros sistemas. Examinan cierto aspecto fundamental de un sistema, con muy poca consi-
deración de la estructura lógica interna del software. En cambio, el enfoque está en asegurar
que el componente se ejecute de manera correcta en la versión de software de mayor tamaño,
cuando los datos de entrada y el contexto de software especificado por sus condiciones
previas son correctos y se comportan de las formas especificadas por sus condiciones pos-
teriores. Desde luego que es importante asegurarse de que el componente se comporte en
forma correcta si no se satisfacen sus condiciones previas (por ejemplo, puede manejar las
entradas incorrectas sin fallar).
Las pruebas de caja negra se basan en los requerimientos especificados en las historias
de usuario (capítulo 7). Los autores de los casos de prueba no necesitan esperar a que se
escriba el código de implementación del componente una vez que se define la interfaz de
dicho componente. Tal vez se tengan que escribir varios componentes cooperantes para
implementar la funcionalidad definida por una sola historia de usuario. A menudo, las
pruebas de validación (sección 20.5) definen los casos de prueba de caja negra en términos
de las acciones de entrada visibles para el usuario final y los comportamientos de salida
observables, sin ningún conocimiento de la forma en que se implementaron los componentes
en sí.

20.1.2 Pruebas de caja blanca

Las pruebas de caja blanca, conocidas algunas veces como pruebas de caja de cristal o pruebas
estructurales, son una filosofía de pruebas de integración que usan el conocimiento de la
implementación de las estructuras de control descritas como parte de un diseño a nivel de
componentes para derivar casos de prueba. Las pruebas de caja blanca del software se basan
en un examen minucioso de los detalles de implementación procedimentales y de imple-
mentación de la estructura de datos. Las pruebas de caja blanca pueden diseñarse solo hasta
que exista el diseño a nivel de componentes (o código fuente). Deben estar disponibles los
detalles lógicos del programa. Las rutas lógicas a través del software y las colaboraciones
entre los componentes son el enfoque de las pruebas de integración de caja blanca.
A primera vista parecería que unas pruebas de caja blanca muy minuciosas lograrían
obtener "programas 100% correctos". Todo lo que necesitamos hacer es definir todas las
rutas lógicas, desarrollar casos de prueba para ejercerlas y evaluar los resultados; es decir,
generar casos de prueba para ejercer la lógica del programa de manera exhaustiva. Por
desgracia, las pruebas exhaustivas presentan ciertos problemas de logística. Para programas
incluso pequeños, el número de posibles rutas lógicas puede ser muy grande. Sin embargo,
no hay que rechazar las pruebas de caja blanca como si fueran poco prácticas. Los encargados
de las pruebas deben seleccionar un número razonable de rutas lógicas importantes a
ejercer una vez que ocurra la integración de componentes. También debe probarse la validez
de las estructuras de datos importantes después de la integración de los componentes.

1 Los términos pruebas funcionales y pruebas estructurales se usan algunas veces en lugar de pruebas de
caja negra y de caja blanca, respectivamente.
398 PARTE TRES CALIDAD Y SEGURIDAD

20.2 PRUEBAS DE INTEGRACIÓN

Un principiante en el mundo del software podría hacer una pregunta aparentemente legítima
una vez que se hayan realizado pruebas unitarias de todos los módulos: "Si todos funcionan
de manera individual, ¿por qué dudar de que funcionarán cuando los unamos?". Desde
luego que el problema es "unirlos", o interconectarlos. Pueden perderse datos a través de
una interfaz; un componente puede tener un efecto secundario inadvertido sobre otro;
cuando se combinan subfunciones, tal vez no produzcan la función principal deseada; una
imprecisión aceptable en forma individual puede amplificarse hasta niveles inaceptables;
además, las estructuras de datos globales pueden presentar problemas. Por desgracia, la
lista no termina.
Las pruebas de integración son una técnica sistemática para construir la arquitectura
de software, mientras que al mismo tiempo se realizan pruebas para descubrir errores aso-
ciados con las interfaces. El objetivo es tomar los componentes a los que se les realizó la
prueba unitaria y crear una estructura de programa regida por el diseño.
A menudo existe la tendencia de intentar una integración no incremental; esto es,
construir el programa mediante un enfoque tipo gran explosión o "big bang". En este enfo-
que, todos los componentes se combinan por adelantado y se prueba todo el programa en
general. ¡Usualmente se produce un caos! Se encuentran errores, pero corregirlos es difícil
debido a que el aislamiento de las causas se complica por la amplia extensión de todo el
programa. Adoptar el enfoque del big bang para la integración es una estrategia inútil des-
tinada al fracaso.
La integración incremental es la antítesis del enfoque del big bang. El programa se
construye y se prueba en pequeños incrementos, en donde es más fácil aislar y corregir los
errores; es más probable que las interfaces se prueben por completo y puede aplicarse un
enfoque de prueba sistemático. Integrar en forma incremental y probar a medida que avan-
zamos es una estrategia más efectiva en costos. En el resto del capítulo analizaremos varias
estrategias de pruebas de integración incrementales comunes.

20.2.1 Integración descendente

Las pruebas de integración descendente (top-down) son un enfoque incremental para la cons-
trucción de la arquitectura del software. Los módulos (también conocidos como compo-
nentes en este libro) se integran al moverse hacia abajo por la jerarquía de control, comen-
zando con el módulo de control (programa) principal. Los módulos subordinados (y
finalmente subordinados) al módulo de control principal se incorporan a la estructura, ya
sea de una forma de "primero en profundidad" o de "primero en amplitud".
Con referencia a la figura 20.1, la integración de primero en profundidad integra todos
los componentes en una ruta de control principal de la estructura del programa. La selección
de una ruta principal es algo arbitraria y depende de características específicas de la apli-
cación (por ejemplo, los componentes necesarios para implementar un caso de uso). Por
ejemplo, si seleccionamos la ruta izquierda, los componentes M 1, M 2 y M 5 se integrarían
primero. Después se integrarían M 8 o (si es necesario para el funcionamiento apropiado
de M 2) M6• Después se crean las rutas de control central y derecha. La integración de primero
en amplitud incorpora todos los componentes directamente subordinados en cada nivel,
desplazándose por la estructura en sentido horizontal. Con respecto a la figura, se integrarían
primero los componentes M 2, M 3 y M 4. El siguiente nivel de control, siguen M 5, M 6, etc.
El proceso de integración se realiza en una serie de cinco pasos:
l. El módulo de control principal se usa como controlador de prueba; los stubs se susti-
tuyen para todos los componentes directamente subordinados al módulo de control
principal.
 CAPÍTULO 20 PRUEBAS DE SOFTWARE: A NIVEL DE INTEGRACIÓN 399

•Uh'M·*l·S•
Integración descendente

--- --- - -,.:-----....--

2. Dependiendo del enfoque de integración seleccionado (es decir, primero en profundidad

o primero en amplitud), los stubs subordinados se reemplazan uno a la vez con com-
ponentes reales.
3. Se realizan pruebas a medida que se integra cada componente.
4. Al completar cada conjunto de pruebas, se reemplaza otro stub con el componente real.
5. Pueden realizarse pruebas de regresión (que analizaremos más tarde en esta sección)
para asegurar que no se hayan introducido errores nuevos.

El proceso continúa desde el paso 2 hasta que se crea toda la estructura del programa.
La estrategia de integración descendente verifica los principales puntos de control o
decisión al principio del proceso de prueba. En una estructura de programa "bien factori-
zada", la toma de decisiones ocurre en los niveles superiores de la jerarquía y, por lo tanto,
se encuentra primero. Si existen problemas de control importantes, es imprescindible reco-
nocerlos lo antes posible. Si se selecciona la integración de primero en profundidad, puede
implementarse y demostrarse una función completa del software. La demostración temprana
de la capacidad funcional genera confianza para todas las partes interesadas.

20.2.2 Integración ascendente

Las pruebas de integración ascendente (bottom-up ), como su nombre lo indica, comienzan
la construcción y prueba con módulos atómicos (es decir, componentes a los niveles inferiores
en la estructura del programa). La integración ascendente elimina la necesidad de stubs
complejos. Debido a que los componentes se integran ascendentemente, la funcionalidad
que proporcionan los componentes subordinados a un cierto nivel siempre está disponible
y se elimina la necesidad de stubs. Una estrategia de integración ascendente puede imple-
mentarse con los siguientes pasos:

l. Los componentes de bajo nivel se combinan en clústeres (algunas veces conocidos

como compilaciones) que realizan una subfunción de software específica.
2. Se escribe un controlador (un programa de control para pruebas) para coordinar la
entrada y salida de los casos de prueba.
3. Se prueba el clúster.
4. Se eliminan los controladores y se combinan los clústeres, avanzando hacia arriba en
la estructura del programa.
400 PARTE TRES CA LIDAD Y SEGURIDAD

•4M'hf.*J·t•
Integración ascendente Me
__
--- ---
.._
,. --.._
'
Mb
.._ __ .._ __
,. --- --- --.._
'
--.._
'
r--'
1 o, 02
.... .... .... ....
.... .... "" "" ....
"" ""

Clúster 3

Clúster 1

\....--------~-""v""'""--~--------__,I
Clúster 2

La integración sigue el patrón que se ilustra en la figura 20.1. Los componentes se combinan
para formar los clústeres 1, 2 y 3. Cada uno de los clústeres se prueba mediante el uso de
un controlador (que se muestra como un bloque con líneas punteadas). Los componentes
en los clústeres 1 y 2 son subordinados de Ma. Los controladores D 1 y D 2 se eliminan, y los
clústeres se interconectan directamente a Ma. De manera similar, el controlador D 3 para
el clúster 3 se elimina antes de la integración con el módulo M 6. Tanto Ma como M 6 se
integrarán finalmente con el componente Me y así sucesivamente.
A medida que la integración avanza hacia arriba, la necesidad de controladores de
prueba separados disminuye. De hecho, si los dos niveles de la estructura del programa se
integran descendentemente, el número de controladores puede reducirse de manera subs-
tancial y la integración de los clústeres se simplifica en gran medida.

20.2.3 Integración continua

La integración continua es la práctica de combinar componentes en el incremento de software
evolutivo una o más veces cada día. Esta es una práctica común para equipos que siguen
prácticas de desarrollo ágil tales como XP (sección 3.5.1) o Devüps (sección 3.5.2). Las
pruebas de integración deben llevarse a cabo con rapidez y eficiencia si un equipo intenta
tener siempre un programa funcional preparado como parte de una entrega continua. Al-
gunas veces es difícil mantener sistemas con el uso de herramientas de integración continua
[Stel8]. En la sección 22.4 analizaremos los aspectos de mantenimiento e integración
continua con más detalle.
Las pruebas de humo son un enfoque de pruebas de integración que pueden usarse
cuando un equipo ágil desarrolla el software de un producto mediante el uso de tiempos
de compilación en incrementos cortos. Las pruebas de humo pueden caracterizarse como
una estrategia de integración frecuente o continua. El software se reconstruye (con nuevos
componentes agregados) y se somete a una prueba de humo cada día. Están diseñadas como
CAPÍTULO 20 PRUEBAS DE SOFTWARE: A NIVEL DE INTEGRACIÓN 401

un mecanismo para marcar el ritmo de proyectos de tiempo crítico; permite que el equipo
de software evalúe el proyecto en forma frecuente. En esencia, el enfoque de las pruebas de
humo incorpora las siguientes actividades:
l. Los componentes de software que se hayan traducido en código se integran a una
compilación. Una compilación incluye todos los archivos de datos, bibliotecas, módulos
reutilizables y componentes de ingeniería requeridos para implementar una o más
funciones del producto.
2. Se diseña una serie de pruebas para exponer los errores que eviten que la compilación
desempeñe su función de manera adecuada. La intención debería ser descubrir los
errores graves que tengan la mayor probabilidad de atrasar el proyecto de software.
3. La compilación se integra con otras compilaciones y se realiza a diario la prueba de
humo de todo el producto (en su forma actual). El enfoque de integración puede ser
descendente o ascendente.
La frecuencia diaria de las pruebas ofrece a los gerentes y profesionales especializados una
evaluación realista del proceso de las pruebas de integración, McConnell [McC96] describe
la prueba de humo de la siguiente forma:

La prueba de humo debe ejercitar todo el sistema de un extremo a otro. No tiene que
ser exhaustiva, pero debe ser capaz de exponer los problemas principales. La prueba de
humo debe ser lo bastante minuciosa como para que, si la compilación se aprueba, po-
damos asumir que es lo bastante estable como para probarla en forma más minuciosa.

Las pruebas de humo proveen varios beneficios cuando se aplican en proyectos de software
complejos de tiempo critico:
• Se minimiza el riesgo de la integración. Puesto que las pruebas de humo se realizan a
diario, los errores de incompatibilidades y otros graves se descubren lo antes posible,
con lo cual se reduce la probabilidad de un impacto grave en el calendario cuando se
descubran los errores.
• Se mejora la calidad del producto final. Debido a que el enfoque está orientado a la
construcción (integración), es probable que las pruebas de humo descubran errores
funcionales así como errores de diseño de arquitectura y a nivel de componente. Si
estos errores se corrigen lo antes posible, se logrará una mejor calidad del producto.
• El diagnóstico y la corrección de errores se simplifican. Al igual que todos los enfo-
ques de pruebas, es probable que los errores descubiertos durante las pruebas de
humo se asocien con "nuevos incrementos de software"; es decir, el software que
se acaba de agregar a la o las compilaciones es una causa probable de un error recién
descubierto.
• El progreso es más fácil evaluar. Con cada día que pasa, se integra una mayor parte del
software y se ha demostrado que funcionan más cosas. Esto mejora la moral del equipo
y provee a los gerentes un buen indicio de que se está progresando.
En ciertas formas las pruebas de humo se asemejan a las pruebas de regresión (que se
analizan en la sección 20.3), lo que ayuda a asegurar que los componentes recién agregados
no interfieran con los comportamientos de los componentes existentes que se probaron
previamente. Para ello, es buena idea volver a ejecutar un subconjunto de los casos de prueba
que se ejecutaron con el componente de software existente antes de agregar los nuevos
componentes. El esfuerzo requerido para volver a ejecutar los casos de prueba no es trivial;
pueden usarse las pruebas automatizadas para reducir el tiempo y esfuerzo recreados para
volver a ejecutar estos casos de prueba [Netl8]. Un análisis completo de las pruebas
402 PART E TRES CA LIDAD Y SE GURIDAD

automatizadas está más allá del alcance de este capítulo, pero encontrará vínculos a herra-
mientas representativas en las páginas web que complementan este libro. 2

20.2.4 Productos de trabajo de la prueba de integración

En una especificación de prueba se documenta un plan general para la integración del software
y una descripción de las pruebas específicas. Este producto de trabajo incorpora un plan
de prueba y un procedimiento de prueba; además se vuelve parte de la configuración del
software. Las pruebas se dividen en fases y compilaciones incrementales que abordan ca-
racterísticas funcionales y del comportamiento específicas del software. Por ejemplo, las prue-
bas de integración para el sistema de seguridad CasaSegura podrían dividirse en las siguientes
fases de prueba: interacción con el usuario, procesamiento de sensores, funciones de co-
municaciones y procesamiento de alarmas.
Cada fase de prueba de integración delinea una categoría funcional amplia dentro del
software y, por lo general, puede relacionarse con un dominio específico dentro de la arqui-
tectura del software. Por lo tanto, se crean incrementos de software que correspondan con
cada fase.
También se analizan como parte del plan un calendario para la integración, el desarrollo
de software de andamiaje (sección 19.2.1) y temas relacionados. Se establecen las fechas de
inicio y fin para cada fase y se definen "ventanas de disponibilidad" para los módulos que
se someten a pruebas unitarias. Al desarrollar el calendario de un proyecto, hay que consi-
derar la forma en que ocurre la integración, de modo que los componentes estén disponibles
cuando sean necesarios. Una breve descripción del software de andamiaje (stubs y contro-
ladores) se concentra en las características que pudieran requerir de un esfuerzo especial.
Por último, se describe el ambiente de prueba y los recursos. Las configuraciones de hardware
inusuales, simuladores muy particulares y las herramientas o técnicas de prueba especiales
son algunos de los diversos temas que también pueden analizarse.
El procedimiento de prueba requerido para realizar el plan de prueba se describe
a continuación. Se describe el orden de las pruebas de integración y las correspondientes
en cada paso de integración. También se incluye un listado de todos los casos de prueba
(con comentarios para una referencia posterior) y los resultados esperados. En el mundo ágil,
este nivel de descripción de los casos de prueba ocurre cuando se está desarrollando el
código para implementar la historia de usuario, de modo que el código pueda probarse tan
pronto como esté listo para la integración.
En un informe de la prueba se registra un historial de los resultados reales de la prueba,
problemas o peculiaridades, lo cual puede adjuntarse a la especificación de la prueba. A
menudo es mejor implementar el informe de la prueba como un documento web compartido,
para que todas las partes interesadas tengan acceso a los resultados más recientes de la
prueba y al estado actual del incremento de software. La información contenida en este
documento en línea puede ser vital para los desarrolladores durante el mantenimiento del
software (sección 4.9).

20.3 INTELIGENCIA ARTIFICIAL Y PRUEBAS

DE REGRESIÓN

Cada vez que se agrega un nuevo módulo como parte de las pruebas de integración, el
software cambia. Se establecen nuevas rutas de flujo de datos, puede haber nueva entrada/

2 Vea el sitio web de SEPA 9e (Software Engineering A Practitioner's Approach 9th Edition).
 CAPÍTULO 20 PRUEBAS DE SOFTWARE: A NIVEL DE INTEGRACIÓN 403

salida (E/S) y se invoca una nueva lógica de control. Los efectos secundarios asociados con
estos cambios pueden provocar problemas con las funciones que anteriormente funcionaban
perfectamente. En el contexto de una estrategia de pruebas de integración, las pruebas de
regresión son la re-ejecución de cierto subconjunto de pruebas que ya se realizaron para
asegurar que los cambios no hayan propagado efectos secundarios imprevistos. Las pruebas
de regresión deben ejecutarse cada vez que se realice un cambio importante en el software
(incluida la integración de nuevos componentes). Las pruebas de regresión ayudan a asegurar
que los cambios (debido a las pruebas o por otras razones) no introduzcan un comporta-
miento inesperado o errores adicionales.
Las pruebas de regresión pueden realizarse en forma manual, mediante la re-ejecución
de un subconjunto de todos los casos de prueba o mediante el uso de herramientas de
captura/reproducción automatizadas. Las herramientas de captura/reproducción permiten
al ingeniero de software capturar los casos de prueba y resultados para su posterior repro-
ducción y comparación. La suite de pruebas de regresión (el subconjunto de pruebas a eje-
cutar) contiene tres clases diferentes de casos de prueba:
• Una muestra representativa de pruebas que ejercite todas las funciones del software.
• Pruebas adicionales que se enfoquen en las funciones del software que puedan verse
afectadas por el cambio.
• Pruebas que se enfocan en los componentes de software que cambiaron.
A medida que proceden las pruebas de integración, el número de pruebas de regresión
puede hacerse bastante grande. Por lo tanto, la suite de pruebas de regresión debe diseñarse
para incluir solo las pruebas que aborden una o más clases de errores en cada una de las
funciones principales del programa.
Yoo y Harman [Yoo 13] escriben sobre los posibles usos de la inteligencia artificial (IA)
en la identificación de casos de prueba para usarlos en suites de pruebas de regresión.
Una herramienta de software podría examinar las dependencias entre los componentes en
el incremento de software después de agregar los nuevos componentes, y generar casos de
prueba en forma automática para usarlos en las pruebas de regresión. Otra posibilidad sería
el uso de técnicas de aprendizaje de máquina para seleccionar conjuntos de casos de prueba
que optimicen el descubrimiento de errores de colaboración de componentes. Este trabajo
es prometedor, pero requiere de una interacción considerable del humano para revisar los
casos de prueba y el orden recomendado para ejecutarlos.

CASASEG l lRA

Pruebas de regresión
El escenario: Oficina de Doug Miller,
mientras se realizan las pruebas de
integración.
Los participantes: Doug Miller, gerente de ingeniería
de software: Vinod, Jamie, Ed y Shakira, miembros del
equipo de ingeniería de software de CasaSegura.
La conversación:
Doug: Me parece que no estamos invirtiendo el tiem-
po suficiente en volver a probar los componentes de
software después de integrar nuevos componentes.
Vinod: Creo que sí, pero ¿acaso no basta con que
probemos las interacciones de los nuevos compo-
nentes con los componentes que se supone deben
colaborar?
Doug: No siempre. Algunas veces los componentes
realizan cambios inesperados en los datos que otros
componentes utilizan. Sé que estamos ocupados, pero
es importante descubrir estos problemas lo antes
posible.
Shakira: Tenemos un repositorio de casos de prueba
que hemos estado usando. Tal vez podamos seleccionar
404 PARTE TRES CALIDAD Y SEGURIDAD

al azar varios casos de prueba y ejecutarlos mediante
nuestro marco de trabajo de pruebas automatizado.
Doug: Es un comienzo. Pero tal vez deberíamos ser
más estratégicos en cuanto a la forma de seleccionar
nuestros casos de prueba.
Ed: Supongo que podríamos usar nuestra tabla de ras-
treabilidad de casos de prueba/requerimientos y revisar
nuestro modelo de tarjetas CRC.
Vinod: He estado usando la integración continua, lo
que significa que integro cada componente tan pronto
como uno de los desarrolladores me lo pasa. Trato de
ejecutar una serie de pruebas de regresión en el pro-
grama parcialmente integrado.
Jamie: He estado tratando de diseñar un conjunto de
pruebas asociadas para cada función en el sistema. Tal
vez deba etiquetar algunas de las más importantes pa-
ra que Vinod las use para las pruebas de regresión.
Doug (a Vinod): ¿Con qué frecuencia ejecutarás los
casos de prueba de regresión?
Vinod: Cada día que integre un nuevo componente
usaré los casos de prueba de regresión ... hasta que
decidamos que el incremento de software está listo.
Doug: Probemos los casos de prueba de regresión de
Jamie a medida que se crean y veamos cómo salen las
cosas.

20.4 PRUEBAS DE INTEGRACIÓN EN EL CONTEXTO 00

El software orientado a objetos no tiene una estructura de control jerárquica obvia, por
lo que las estrategias tradicionales de integración descendente y ascendente (sección
20.2) no tienen mucho significado. Además, a menudo es imposible integrar las opera-
ciones una a la vez en una clase (el enfoque convencional de integración incremental),
debido a las "interacciones directas e indirectas de los componentes que conforman la
clase" [Ber93].
Hay dos estrategias diferentes para las pruebas de integración de sistemas 00: pruebas
basadas en hilos y pruebas basadas en uso [Bin99]. La primera, las pruebas basadas en hilos,
integra el conjunto de clases requeridas para responder a una entrada o evento para el sis-
tema. Cada hilo se integra y prueba de manera individual. Se aplican pruebas de regresión
para asegurar que no ocurran efectos secundarios. Una estrategia importante para las pruebas
de integración del software 00 es la de las pruebas basadas en hilos. Los hilos son con-
juntos de clases que responden a una entrada o evento.
El segundo enfoque de integración, las pruebas basadas en uso, comienza la construcción
del sistema mediante la prueba de las clases (conocidas como clases independientes) que
usan muy pocas (si acaso) clases servidor. Una vez que se prueban las clases independientes,
se prueba el siguiente nivel de clases, conocidas como clases dependientes, que usan las
clases independientes. Esta secuencia de niveles de prueba de clases dependientes continúa
hasta que se construye todo el sistema. Las pruebas basadas en uso se enfocan en clases
que no colaboran mucho con otras clases.
El uso de software de andamiaje (controladores) también cambia cuando se realizan
las pruebas de integración de sistemas OO. Pueden usarse controladores para probar ope-
raciones al nivel más bajo y para la prueba de grupos enteros de clases. También puede
usarse un controlador para reemplazar la interfaz de usuario, de modo que puedan realizarse
pruebas de funcionalidad del sistema antes de la implementación de la interfaz. Pueden
usarse stubs en situaciones en las que se requiere la colaboración entre clases, pero una o
más de las clases colaboradoras no se ha implementado todavia por completo.
Las pruebas de clúster son un paso en las pruebas de integración de software OO. Aquí,
se emplea un clúster de clases colaboradoras (que se determinan mediante un examen del
modelo CRC y de objeto-relación) mediante el diseño de casos de prueba que intentan
descubrir errores en las colaboraciones.
CAPÍTULO 20 PRUEBAS DE SOFTWARE : A NIVEL DE INTEGRACIÓN 405

20.4.1 Diseño de casos de pruebas basadas en fallas 3

El objeto de las pruebas basadas en fallas dentro de un sistema 00 es diseñar pruebas que
tengan una alta probabilidad de descubrir las fallas plausibles. Debido a que el producto o
sistema debe conformarse a los requerimientos del cliente, la planeación preliminar requerida
para realizar las pruebas basadas en fallas comienza con el modelo de análisis. La estra-
tegia para las pruebas basadas en fallas es formular una hipótesis de un conjunto de fallas
plausibles y luego derivar pruebas para demostrar cada hipótesis. El encargado de las pruebas
busca fallas plausibles (es decir, aspectos de la implementación del sistema que puedan
provocar defectos). Para determinar si existen estas fallas, se diseñan casos de prueba para
ejecutar el diseño o código.
Desde luego que la efectividad de estas técnicas depende de cómo perciban los encar-
gados de las pruebas una falla plausible. Si las fallas reales en un sistema 00 se perciben
como poco plausibles, entonces este enfoque no es realmente mejor que cualquier técnica
de prueba aleatoria. Pero si los modelos de análisis y diseño pueden dar información acerca de
lo que probablemente saldrá mal, entonces las pruebas basadas en fallas pueden encontrar
números considerables de errores con relativamente poco esfuerzo.
Las pruebas de integración buscan fallas plausibles en las llamadas de operaciones o
conexiones de mensajes. Se encuentran tres tipos de fallas en este contexto: resultado ines-
perado, uso de operación/mensaje incorrecto e invocación incorrecta. Para determinar las
fallas plausibles a medida que se invocan funciones (operaciones), hay que examinar el
comportamiento de la operación.
Las pruebas de integración se aplican a los atributos así como a las operaciones. Los
"comportamientos" de un objeto se definen mediante los valores que se asignan a sus atri-
butos. Las pruebas deben emplear dichos atributos para determinar si ocurren valores
apropiados para los distintos tipos de comportamiento del objeto.
Es importante señalar que las pruebas de integración intentan encontrar errores en el
objeto cliente, no en el servidor. Dicho en términos convencionales, el enfoque de las pruebas
de integración es determinar si existen errores en el código que hacen la llamada, no el
código al que se llama. La llamada de la operación se usa como pista, como una forma de
encontrar los requerimientos de prueba que emplean el código que hace la llamada.
El enfoque para las pruebas de partición de clases múltiples es similar al enfoque utilizado
para las pruebas de partición de clases individuales. Una sola clase se particiona como vimos
en la sección 19.6.1. Sin embargo, la secuencia de pruebas se expande para incluir las ope-
raciones que se invocan mediante mensajes a las clases colaboradoras. Un enfoque alternativo
particiona las pruebas con base en las interfaces para una clase específica. Si nos referimos
a la figura 20.3, la clase Bank recibe mensajes de las clases ATM y Cajero. Los métodos
dentro de Banco pueden por lo tanto probarse si se particionan en los que sirven a ATM y
los que sirven a Cajeo.
Kirani y Tsai [Kir94] sugieren la siguiente secuencia de pasos para generar casos de
prueba aleatorios de clases múltiples:
l. Para cada clase cliente, usa la lista de operaciones de la clase para generar una serie
de secuencias de prueba aleatorias. Las operaciones enviarán mensajes a otras clases
servidor.
2. Para cada mensaje que se genere, determinar la clase colaboradora y la operación
correspondiente en el objeto servidor.

3 Las secciones 20.4.1y20.4.2 se adaptaron de un artículo de Brian Marick que se publicó originalmente
en el grupo de noticias de internet comp.testing. Esta adaptación se incluye con el permiso del autor.
Si desea más información sobre estos temas, vea [Mar94]. Hay que tener en cuenta que las técnicas
analizadas en las secciones 20.4.1 y 20.4.2 también se aplican para el software convencional.
406 PARTE TRES CALIDAD Y SEGURIDAD

•Uh'M·*l·f •
Diagrama de colaboración tarjeta Insertada verificarCta
contraseña verificarNIP
de clases para la aplicación depósito verificarPolítica
bancaria retiro reqRetiro
estadoCuenta reqDepósito

-------, terminar
....-------,_ infoCta
;;;:
Interfaz de
ATM Banco
usuario del ATM

verificarEstado
límiteCrédito

! !
estadoDepósito nipVálido
abrirCta tipoCta
dispensarEfectivo ctaVálida
depósitolnicial balance
imprEstadoCta
autorizarTarj retiro
leerlnfoTarj
desautorizar depósito
obtenerMontoEfvo
cerrarCta cerrar

lnfo
Cajero Cuenta
Validación

Fuente: Kirani, Shekhar y Tsai, W. T., "Specification and Verification of Object-Oriented Programs", Informe técnico TR 94-64, University
of Minnesota, 4 de diciembre de 1994, 72.

3. Para cada operación en el objeto servidor (que se haya invocado mediante mensajes
enviados desde el objeto cliente), determinar los mensajes que transmite.
4. Para cada uno de los mensajes, determinar el siguiente nivel de operaciones que se
invocan e incorporarlos en la secuencia de pruebas.
Para ilustrar [Kir94], considere una secuencia de operaciones para la clase Banco relativa
a una clase ATM (figura 20.3):

verificarCta•verificarNIP•[[verificarPolftica•reqRetiro]lreqDepósitolreqlnfoCta]n

Un caso de prueba aleatorio para la clase Banco podría ser

Caso de prueba r3 = verificarCta•verificarNIP•reqDepósito

Para considerar los colaboradores involucrados en esta prueba, se toman en cuenta los
mensajes asociados con cada una de las operaciones señaladas en el caso de prueba r3.
Banco debe colaborar con InfoValidación para ejecutar verificarCta() y verificarNIP(). Banco
debe colaborar con Cuenta para ejecutar reqDepósito(). Por lo tanto, un nuevo caso que
emplea estas colaboraciones es

Caso de prueba r4 = verificarCta[Banco:validarCtalnfoValidación]•

verificarNIP [Banco: validarNIPinfoValidación]•
reqDepó~to[Banco:depó~tocuenta]

20.4.2 Diseño de casos de prueba basados en escenarios

Las pruebas basadas en fallas omiten dos tipos principales de errores: ( 1) especificaciones
incorrectas y (2) interacciones entre subsistemas. Cuando ocurren errores asociados con
una especificación incorrecta, el producto no hace lo que el cliente desea. Podría hacer lo
 CAPÍTULO 20 PRUEBAS DE SOFTWARE: A NIVEL DE INTEGRACIÓN 407

incorrecto u omitir funcionalidad importante. Pero en cualquier caso, la calidad (de con-
formidad con los requerimientos) sufre. Ocurren errores asociados con la interacción del
subsistema cuando el comportamiento de un subsistema crea circunstancias (eventos, flujo
de datos, etc.) que provocan la falla de otro subsistema.
Las pruebas basadas en escenarios descubrirán errores que ocurren cuando cualquier
actor interactúa con el software. Las pruebas basadas en escenarios se concentran en lo
que hace el usuario, no en lo que hace el producto. Esto significa capturar las tareas (me-
diante casos de uso) que el usuario tiene que realizar, para luego aplicarlas junto con sus
variantes como pruebas. Esto es muy similar a las pruebas de hilos.
Las pruebas de escenarios descubren los errores de interacción. Pero para lograr esto,
los casos de prueba deben ser más complejos y realistas que las pruebas basadas en fallas.
Las pruebas basadas en escenarios tienden a emplear múltiples subsistemas en una sola
prueba (los usuarios no se limitan al uso de un subsistema a la vez).
El diseño de casos de prueba se vuelve más complicado cuando comienza la integración
del sistema orientado a objetos. Es en esta etapa que deben empezar las pruebas de las
colaboraciones entre clases. Para ilustrar la "generación de casos de prueba entre clases"
[Kir94], vamos a expandir el ejemplo bancario que presentamos en la sección 19.6 para
incluir las clases y colaboraciones señaladas en la figura 20.3. La dirección de las flechas
en la figura indica la dirección de los mensajes; el etiquetado indica las operaciones que se
invocan como consecuencia de las colaboraciones que implican los mensajes.
Al igual que las pruebas de clases individuales, las pruebas de colaboraciones entre
clases pueden realizarse mediante la aplicación de métodos aleatorios y de particionamiento,
así como pruebas basadas en escenario y del comportamiento.

20.5 PRUEBAS DE VALIDACIÓN

Al igual que todos los pasos de las pruebas, la validación trata de descubrir errores, pero el
enfoque está en el nivel de requerimientos: en las cosas que serán evidentes de inmediato
para el usuario final. Las pruebas de validación comienzan en la culminación de las pruebas
de integración, cuando se han empleado los componentes individuales, el software se en-
sambla completamente como un paquete y se han descubierto y corregido los errores de
interfaces. Al nivel de validación o del sistema, la distinción entre las diferentes categorías
de software desaparece. Las pruebas se enfocan en las acciones visibles para el usuario y la
salida del sistema reconocida por el usuario.
Podemos definir la validación de muchas formas, pero una definición simple (aunque
cruda) es que la validación tiene éxito cuando el software funciona de una forma que el
cliente pueda esperar razonablemente. En este punto, un desarrollador de software curtido
por la batalla podría protestar: "¿Quién o qué es el árbitro de expectativas razonables?". Si
se desarrolló una especificación de requerimientos de software, describe cada historia de
usuario, todos los atributos visibles para el usuario y los criterios de aceptación del cliente
para cada uno de ellos. Los criterios de aceptación del cliente forman la base de un enfoque
de pruebas de validación.
La validación del software se logra a través de una serie de pruebas que demuestran la
conformidad con los requerimientos. Un plan de pruebas describe las clases de pruebas a
realizar y un procedimiento de pruebas define los casos de prueba específicos diseñados
para asegurar que se cumpla con todos los requerimientos funcionales, se logren todas las
características del comportamiento, todo el contenido sea preciso y se presente de manera
adecuada, se obtengan todos los requerimientos de rendimiento, la documentación sea
correcta y se cumpla con los requerimientos de facilidad de uso y otros más (como facilidad
de transporte, compatibilidad, recuperación de errores, facilidad de mantenimiento).
408 PARTE TRES CA LIDA D Y SE GURIDAD

Si se descubre una desviación de la especificación, se crea una lista de deficiencias. Hay

que establecer un método para resolver deficiencias (aceptable para las partes interesadas).
Los métodos de prueba especializados para estos requerimientos no funcionales se analizan
en el capítulo 21.
Un elemento importante del proceso de validación es una revisión de configuración. El
propósito de la revisión es asegurar que todos los elementos de la configuración del software
se hayan desarrollado de manera adecuada, se clasifiquen y tengan el detalle necesario para
reforzar las actividades de apoyo. La revisión de configuración, conocida algunas veces
como auditoría, se analiza con más detalle en el capítulo 22.

CASASEGl ' RA

~ Prepamción pam la validación

Ui.Jlii[J El escenario: Oficina de Doug Miller,
mientras continúan el diseño a nivel de
componentes y la construcción de ciertos componentes.
Los participantes: Doug Miller, gerente de ingeniería
de software; Vinod, Jamie, Ed y Shakira, miembros del
equipo de ingeniería de software de CasaSegura.
La conversación:
Doug: El primer incremento estará listo para validación
en ... ¿alrededor de tres semanas?
Vinod: Es correcto. La integración va bien. Realizamos
pruebas de humo a diario, encontramos algunos erro-
res, pero nada que no podamos manejar. Hasta ahora,
todo bien.
Doug: Háblenme sobre la validación.
Shakira: Bueno, usaremos todos los casos de uso co-
mo la base de nuestro diseño de pruebas. No he comen-
zado aún, pero voy a desarrollar pruebas para todos
los casos de uso de los que sea responsable.
Ed: Yo también.
Jamie: Y yo igual, pero tenemos que unir fuerzas para
las pruebas de aceptación y también para las pruebas
alfa y beta, ¿no?
Doug: Sí. De hecho, he estado pensando; podríamos
conseguir un contratista externo para que nos ayude
con la validación. Tengo el dinero en el presupuesto...
y esto nos daría un nuevo punto de vista.
Vinod: Creo que lo tenemos bajo control.
Doug: Estoy seguro de ello, pero un grupo de pruebas
independiente (ITG) nos dará una perspectiva indepen-
diente del software.
Jamie: Tenemos el tiempo muy limitado, Doug. Por mi
cuenta, creo que no tengo el tiempo para atender a
alguien que traigas de fuera para hacer el trabajo.
Doug: Lo sé. Pero si un ITG trabaja con base en los
requerimientos y casos de uso, no tendrán que cuidar-
lo mucho.
Vinod: Yo sigo pensando que tenemos todo bajo control.
Doug: Te escucho, Vinod, pero ya lo tengo decidido.
Vamos a planear una reunión con el representante del
ITG más adelante en la semana. Que empiecen para
ver qué resultados obtienen.
Vinod: Muy bien, tal vez aligeren un poco la carga.

A nivel de validación o del sistema, desaparecen los detalles de las conexiones de las clases.
La validación del software 00 se enfoca en las acciones visibles para el usuario y las salidas
del sistema que el usuario reconoce. Para ayudar en la derivación de las pruebas de valida-
ción, el encargado de las pruebas debe basarse en los casos de uso (capítulos 7 y 8) que sean
parte del modelo de requerimientos. El caso de uso proporciona un escenario que tiene una
alta probabilidad de descubrir errores en los requerimientos de interacción con el usuario.
Los métodos convencionales de las pruebas de caja negra (capítulo 19) pueden usarse
para controlar las pruebas de validación. Además, puede optar por derivar los casos de prueba
del modelo de objeto-comportamiento creado como parte del análisis orientado a objetos
(AOO).
 CAPÍTULO 20 PRUEBAS DE SOFTWARE: A NIVEL DE INTEGRACIÓN 409

20.6 PATRONES DE PRUEBA

En el capítulo 15 analizamos el uso de los patrones como un mecanismo para describir
soluciones a problemas de diseño específicos. Pero los patrones también pueden usarse para
proponer soluciones a otras situaciones de ingeniería de software: en este caso, pruebas del
software. Los patrones de prueba describen los problemas de pruebas comunes y las solu-
ciones que pueden ayudar a lidiar con ellos.
Gran parte de las pruebas de software, incluso durante la década anterior, han sido
una actividad ad hoc. Si los patrones de prueba pueden ayudar a un equipo de software a
comunicarse acerca de las pruebas con más efectividad, entender las fuerzas motivacionales
que conducen a un enfoque específico para las pruebas y abordar el diseño de las pruebas
como una actividad evolutiva en la que cada iteración resulta en una suite más completa de
casos de prueba, estos patrones han logrado mucho.
Los patrones de prueba se describen en forma muy parecida a los patrones de diseño
(capítulo 15). Se han propuesto docenas de patrones de prueba en la literatura (como
[Mar02] ). Los siguientes tres patrones de prueba (presentados en forma abstracta solamente)
proveen ejemplos representativos:

Nombre del patrón: PruebasPorPares

Abstracto: este patrón orientado a objetos llamado pruebas por pares describe una técnica
analógica a la programación por pares [capítulo 3] , en la que dos personas encargadas
de las pruebas trabajan en conjunto para diseñar y ejecutar una serie de pruebas que puedan
aplicarse a las actividades de las pruebas unitarias, de integración o de validación.

Nombre del patrón: InterfazPruebaSeparada

Abstracto: es necesario probar todas las clases en un sistema orientado a objetos, inclui-
das las "clases internas" (es decir, clases que no exponen interfaces fuera del componente
que las utilizó). El patrón InterfazPruebaSeparada describe cómo crear una "interfaz de
prueba que pueda usarse para describir pruebas específicas en clases que sean visibles
solo de manera interna para un componente" [LanOl].

Nombre del patrón: PruebasEscenarios

Abstracto: una vez que se realizan las pruebas unitarias y de integración, es necesario
determinar si el software se desempeñará de una forma que satisfaga a los usuarios. El
patrón PruebasEscenarios describe una técnica para ejecutar el software desde el punto
de vista del usuario. Una falla en este nivel indica que el software no logró cumplir un
requerimiento visible para el usuario [KanOl].

Un análisis más detallado de los patrones de prueba queda fuera del alcance de este libro.
Si le interesa, consulte [Bin99], [Mar02], [Tho04], [MaclO] y [Gonl7] para obtener más
información sobre este importante tema.

20. 7 RESUMEN
Las pruebas de integración construyen la arquitectura del software, y a la vez realizan pruebas
para descubrir errores asociados con las interfaces entre los componentes de software. El
objetivo es tomar componentes que se hayan sometido a pruebas unitarias y crear una es-
tructura del programa dictada por el diseño.
A menudo los desarrolladores de software dicen: "las pruebas nunca terminan; solo se
transfieren de uno [el ingeniero de software] al cliente. Cada vez que su cliente usa el pro-
grama, se está llevando a cabo una prueba". Al aplicar el diseño de casos de prueba, es
410 PARTE TR ES C ALIDAD Y SE GURIDAD

posible obtener pruebas más completas y, por lo tanto, descubrir y corregir el mayor número
de errores antes de que comiencen las "pruebas del cliente".
Hetzel [Het84] describe las pruebas de caja blanca como "pruebas en pequeño". Su
lógica es que las pruebas de caja blanca que consideramos en este capítulo se aplican por
lo general a componentes pequeños del programa (como módulos o pequeños grupos de
módulos). Por otro lado, las pruebas de caja negra amplían nuestro enfoque y podrían lla-
marse "pruebas en grande".
Las pruebas de integración de caja negra se basan en los requerimientos especificados
en las historias de usuario o en alguna otra representación de modelado de análisis. Los autores
de casos de prueba no necesitan esperar a que se escriba el código de implementación del
componente, siempre y cuando entiendan la funcionalidad requerida de los componentes
que se someten a las pruebas. Por lo general, las pruebas de validación se realizan con casos
de prueba de caja negra que producen acciones de entrada visibles para el usuario final y
comportamientos de salida observables.
Las pruebas de caja blanca requieren de un examen minucioso de los detalles de im-
plementación procedimentales y los detalles de implementación de estructuras de datos
para los componentes que se someten a las pruebas. Las pruebas de caja blanca pueden
diseñarse solo hasta que exista el diseño a nivel de componentes (o código fuente). Las
rutas lógicas a través del software y las colaboraciones entre componentes son el enfoque
de las pruebas de integración de caja blanca.
Las pruebas de integración del software 00 pueden lograrse mediante una estrategia
basada en hilos o en uso. Las pruebas basadas en hilos integran el conjunto de clases que
colaboran para responder a una entrada o evento. Las pruebas basadas en uso construyen el
sistema en niveles, comenzando con las clases que no usan clases servidor. Los métodos de diseño
de casos de uso de integración también pueden hacer uso de pruebas aleatorias y de partición.
Además, las pruebas basadas en escenarios y las pruebas derivadas de modelos del compor-
tamiento pueden usarse para probar una clase y sus colaboradoras. Una secuencia de pruebas
rastrea el flujo de operaciones a través de las colaboraciones de clases.
Las pruebas de validación de un sistema 00 están orientadas a la caja negra y pueden
realizarse mediante la aplicación de los mismos métodos de caja negra que vimos para el
software convencional. Sin embargo, las pruebas basadas en escenarios dominan la valida-
ción de los sistemas de 00; hacen del caso de uso un controlador principal para las pruebas
de validación.
Las pruebas de regresión son el proceso de re-ejecutar un caso de prueba seleccionado
después de realizar un cambio en un sistema de software. Las pruebas de regresión deben
ejecutarse cada vez que se agregan nuevos componentes o cambios a un incremento de
software. Las pruebas de regresión ayudan a asegurar que los cambios no introduzcan un
comportamiento inesperado o errores adicionales.
Los patrones de prueba describen problemas de pruebas comunes y soluciones que
pueden ayudarnos a lidiar con ellos. Si los patrones de prueba pueden ayudar a un equipo
de software a comunicarse sobre las pruebas con más eficiencia, entender las fuerzas mo-
tivacionales que conducen a un enfoque específico para las pruebas y abordar el diseño de
los casos de prueba como una actividad evolutiva en la que cada iteración resulta en una
suite más completa de casos de prueba, entonces los patrones han logrado mucho.

PROBLEMAS Y PUNTOS A PONDERAR

20.1. ¿Cómo puede el calendario de un proyecto afectar en las pruebas de integración?

20.2. ¿Quién debe realizar las pruebas de validación: el desarrollador o el usuario del software?
Justifique su respuesta.
CAPÍTULO 20 PRUEBAS DE SOFTWARE: A NIVEL DE INTEGRACIÓN 411

20.3. ¿Las pruebas exhaustivas (incluso si es posible para programas muy pequeños) garantizan que
un programa sea 100% correcto?

20.4. ¿Por qué las "pruebas" deben comenzar con el análisis y diseño de los requerimientos?
20.5. ¿Deben probarse los requerimientos no funcionales (como seguridad o rendimiento) como
parte de las pruebas de integración?

20.6. ¿Por qué tenemos que volver a probar las subclases que se instancian de una clase existente, si
la clase existente ya se probó de manera exhaustiva?
20. 7. ¿Cuál es la diferencia entre las estrategias basadas en hilos y basadas en uso para las pruebas
de integración?

20.8. Desarrolle una estrategia de pruebas completa para el sistema CasaSegura que analizamos
antes en este libro. Documéntela en una especificación de pruebas.

20.9. Seleccione una de las historias de usuario del sistema CasaSegura para usarlo como la base de
las pruebas basadas en escenarios; elabore un conjunto de casos de prueba de integración necesarios
para realizar las pruebas de integración para esa historia de usuario.
20.10. Para los casos de prueba que escribió en el problema 20.9, identifique un subconjunto de casos
de prueba que usará para realizar pruebas de regresión en Jos componentes de software que se agregan
al programa.

Elemento de diseño: lupa del icono Vista rápida: © Roger Pressman