10.

3 Proceso de pruebas
El proceso de pruebas involucra consideraciones similares al del proceso de desarrollo de software, incluyendo estrategias, actividades y metodos, los cuales
deben ser aplicados de manera concurrente con el proceso de desarrollo de
software. En particular, las actividades de pruebas abarcan los siguientes aspectos: planeacion, construccion y ejecucion. For lo general, se mantiene una bitdcora de prueba (test log) durante todo el proceso de pruebas.

10.3.1 Estrategia de prueba

Existen diversas estrategias para el proceso de pruebas, entre las que se destacan el orden en que se van a llevar a cabo, la particion de equivalencias de
pruebas que se van a aplicar y la posibilidad de automatizarlas.
Orden de pruebas. Tiene como proposito definir en que momento y en
que orden se aplicaran las pruebas. Aunque estas deben ser planeadas con
anterioridad, las verificaciones tipicamente se aplican durante el diseno, implementacion y operacion del sistema. Existen dos enfoques generates para
el orden en que se efectuaran las pruebas: de arriba hacia abajo y de abajo
hacia arriba, Este orden depende en gran medida de la estrategia de diseno ya que debe lograr una buena correspondencia con el proceso de desarrollo utilizado. Si se aplican pruebas correspondientes a un diseno de
arriba hacia abajo, entonces se deben desarrollar inicialmente las interfaces
entre subsistemas, para tratar de probar los protocolos a alto nivel antes de
ir a los niveles inferiores. Si se hace un diseno de abajo hacia arriba se puede certlficar primero las unidades de bajo nivel y luego las interfaces entre
ellas. Esta tecnica aprovecha que una vez probadas las unidades, se elimina la necesidad de crear servidores especializados para pruebas. En el de
pruebas de arriba hacia abajo se necesitan servidores de pruebas especiales que simulen el ambiente alrededor de la unidad que se verifica. En el
caso^extremo se debe construir una estructura completa para simular todos
los objetos del sistema que aun no existen. Normalmente, es suficiente tener
una base de pruebas que sea de una magnitud de orden menor que lo que
se esta probando, como una clase de prueba por cada paquete de servicio
(contratos), un contrato para cada subsistema, etcetera.
Alcance de pruebas. Tiene como proposito identificar el tipo, numero y
casos de pruebas que se aplicaran para revisar los diferentes aspectos del
sistema. Si se considera que los tipos de pruebas son bastante amplios y
extensos, el objetivo es seleccionar un numero pequeno pero razonable de
casos de prueba dentro de un gran numero de posibles pruebas donde la
probabilidad de encontrar faltas sea alto. Se define la particion de equivalencias segun conjuntos equivalentes (equivalent set) de pruebas definiendo un grupo de condiciones donde el sistema o algun componente se comportara de manera similar ante diferentes pruebas. La idea es escribir casos
de prueba que cubran todos los conjuntos de equivalencia, pero tener un
caso de prueba para cada conjunto de equivalencia.
Automatizacion de pruebas. Tiene como proposito reducir el esfuerzo y
costo de las pruebas mediante la automatizacion del proceso o aspectos de
el. Este objetivo puede lograrse mediante programas de pruebas especiales
asociados a un conjunto de datos de pruebas. El programa de prueba debe
582

CAP. 10 MODELO DE PRUEBAS

tomar conjuntos de datos de entrada y observar la respuesta del sistema, la

cual puede giiardarse directamente en un archive de salida o ser comparada con alguna respuesta esperada. El objetivo es tener un programa de prueba lo mas general e independiente posible de los datos de prueba, los cuales a su vez pueden ser generados automaticamente. Para probar el sistema
completo son necesarios diferentes programas de prueba. Cuando se desarrollan los programas y datos de prueba, se deben utilizar las mismas tecnicas usadas para el desarrollo del sistema y desarrollarse de forma paralela
con el propio sistema. Estos programas se consideran parte del sistema, e
incluso pueden ser utilizados para el mantenimiento de este, lo cual simplifica la tarea de buscar falias y faltas cuando se haya instalado.

10.3.2 Planeacion de la prueba

La planeacion de la prueba comienza con el establecimiento de las estrategias
de pruebas, lo que incluye la cuestion si estas se haran automatica o manualmente y si existen programas y datos de prueba que puedan ser usados, posiblemente
modificados o desarrollados de nueva cuenta. Se determina el alcance de las
pruebas a traves de conjuntos de equivalencia y se identifican los tipos de pruebas necesarios. For lo general la planeacion se hace durante la etapa de elaboracion del modelo de analisis luego de finalizar el modelo de requisites. La prueba en si se disena durante la fase de la actividad de diseno en el sistema.
Esta etapa de planeacion, que permite estimar los recursos requeridos, sirve
como guia para la especificacion y ejecucion de la prueba. Cuando los recursos de prueba estan restringidos, cada caso de prueba debe maximizar la probabilidad estadistica para detectar falias, pero en primer lugar es necesario detectar las fallas mayores.

10.3.3 Construction de la prueba

Una vez planificadas las pruebas, estas deben ser disenadas a un nivel funcional
donde se describa cada prueba y su proposito de manera general y detallada. Se
debe describir exactamente como se debera ejecutar el caso de prueba, de manera que personas no familiarizadas con la aplicacion, o incluso el sistema, puedan ejecutar el caso. En una situacion ideal, las especificaciones del diseno de
las pruebas deben servir tambien como especificaciones de la prueba.
Cada caso de prueba, con excepcion de las pruebas de unidad de mas bajo
nivel, debe ser documentado. Las condiciones para realizar la prueba deben ser
especificadas. Asi, por ejemplo, si la prueba debe ser efectuada en un ambiente de desarrollo o real, es necesario determinar el tipo de software, hardware
y equipo de prueba, y bajo que version del sistema. Tambien se debe describir como debe ejecutarse la prueba, en que orden, cual es el resultado esperado y cuales son los criterios para aprobarla. Tambien se debe describir como
preparar los reportes requeridos para documentar los resultados de la prueba.
Si la documentation del diseno del sistema esta descrita como especificaciones,
estas pueden ser usadas tambien como especificaciones de prueba. Una especificacion de prueba es a menudo tambien de diseno. La etapa de diseno de
pruebas tambien ayuda a encontrar problemas en el diseno del sistema e incluso faltas. En tal caso, estas deben ser comunicadas al disenador, el cual debe
PROCESO DE PRUEBAS

583

corregir de manera adecuada para luego aplicar nuevamente las pruebas anteriores. For ejemplo, se puede tener como objetivo general detectar el maximo
posible de faltas presentes en el sistema, por lo cual se puede tener como objetivo particular del diseno de pruebas minimizar el numero de faltas por cada
1 000 lineas de codigo, o algo similar.

10.3.4 Ejecucion de la prueba

Durante esta etapa se utiliza la especificacion del diseno de prueba y los reportes de esta. La estrategia es aplicar de manera paralela el mayor caso de pruebas
posible. Se ejecutan las pruebas automaticas y manuales de manera correspondiente y se indican los resultados esperados. Si alguna prueba particular falla, se
interrumpe su aplicacion y se anota el resultado para luego analizar el defecto y
corregirlo, si ello es posible. Una vez corregido, la prueba se ejecuta nuevamente. Todas las pruebas son ponderadas segun su importancia, y se puede determinar si la prueba completa ha sido aprobada o no segun su resultado. Se analizan los resultados de la prueba completa y se anota en los reportes un resumen
de ella, los recursos utilizados, los resultados individuates y si los resultados fueron aprobatorios o no. El reporte de la prueba debe tambien mostrar el resultado de cada una de ellas, recursos utilizados y acciones tomadas.
Si al ejecutar las pruebas se detectan fallas, se deben analizar sus resultados y
la causa de la falta identificada. Esta no necesariamente tiene que ser responsabilidad del sistema, sino que puede haber sido provocada por otras circunstancias tal como si la prueba se aplico de manera incorrecta, si existen errores
en los datos utilizados o en el programa de prueba, si existe una falla causada
por la base de prueba, o si el software del sistema se comporta de forma incorrecta. Si la falla no fue provocada por el objeto en prueba, se debe corregir y
hacerla nuevamente. Si fue por causa del sistema, sera necesario identificar que
clases o paquetes de servicios deficientes deben ser devueltos al disenador. El
proceso de deteccion de faltas se simplifica si las unidades probadas ofrecen
facilidades apropiadas, por ejemplo, contadores o bitacoras de faltas.

10.4 Pruebas del Sistema de Reservaciones

de Vuelos
En lo que respecta al Sistema de Reservaciones de Vuelos desarrollado a lo largo
del libro, nos limitaremos a verificarlo de acuerdo con la prueba de requisites
o casos de uso. Como objetivo de la prueba revisaremos que la funcionalidad
implementada corresponda a los casos de uso especificados durante el modelo
de requisites. A continuacion revisaremos los casos de uso principales, basicos
y de extension, los cuales fueron descritos durante el diseno Registrar Usuario y Registrar Tarjeta. Notese que los casos de uso Validar Usuario y Ofrecer
Servicios no los describiremos de manera independiente, ya que son inclusiones de los demas.

10.4.1 Registrar Usuario

Se prueba la secuencia mas importante de los casos de uso Registrar Usuario:
Crear Registro Usuario, Actualizar Registro Usuario y Eliminar Registro Usuario.

584

CAP. 10 MODELO DE PRUEBAS