Uno de los objetivos de la fase de pruebas del
sistema es verificar que el comportamiento externo del sistema software
satisface los requisitos establecidos por los clientes y futuros usuarios del
mismo. A medida que aumenta la complejidad de los sistemas software y aumenta
la demanda de calidad, se hacen necesarios procesos y métodos que permitan
obtener buenos conjuntos de pruebas del sistema. Este trabajo describe los
modelos necesarios para generar de manera sistemática un conjunto de pruebas
que permitan verificar la implementación de los requisitos funcionales de un
sistema software.
EL PROCESO DE GENERACIÓN DE PRUEBAS DEL SISTEMA
Toda prueba consta tradicionalmente de tres
elementos: interacciones entre el sistema y la prueba, valores de prueba y
resultados esperados. Los dos primeros elementos permiten realizar la prueba y
el tercer elemento permite evaluar si la prueba se superó con éxito o no. Un
proceso de pruebas consta generalmente de cuatro fases: la fase de diseño de
pruebas, la
fase de codificación, la fase de ejecución y la
fase de análisis de los resultados.
El objetivo de un proceso de generación de pruebas
del sistema es desarrollar las dos primeras
fases y obtener esos tres elementos a partir del
modelo de requisitos del propio sistema bajo prueba. Dicho proceso toma como
punto de partida los requisitos y, a partir de ellos genera los resultados y
construye las pruebas.
MODELOS DE PRUEBA
En este punto se describen un conjunto de modelos
de prueba independientes y dependientes de la plataforma (PITs y PDTs). Los
modelos descritos se muestran en la figura 2.
Los óvalos de la figura 2 representan los distintos
modelos implicados. Los óvalos sombreados representan los modelos de
requisitos, los óvalos claros representan los modelos independientes de prueba
y los óvalos a rayas representan los modelos dependientes. Las líneas entre
modelos implican las dependencias y las futuras transformaciones. Todos los
modelos siguen el Testing Profile de UML 2.0 [15] siempre que ha sido posible.
Los modelos de la figura 2 se describen en los siguientes puntos.
A lo largo de este trabajo se muestran ejemplos
basados en uno de los casos prácticos realizado durante el desarrollo de estos
modelos.
Modelos de
requisitos
Los únicos modelos de requisitos necesarios son los
casos de uso y los requisitos de almacenamiento, aunque otros modelos, como por
ejemplo modelos de interfaces o modelos
de navegación pueden enriquecer el
proceso de prueba.
Modelo de
comportamiento
Un gran número de técnicas de requisitos están
basadas en casos de uso definidos en prosa
. Uno de ellos es el modelo WebRE utilizado en el
punto anterior. Pero no es sencillo
manipular programáticamente casos de uso escritos
en prosa. Por este motivo, el primer
paso de nuestro proceso sistemático de generación
de pruebas consiste en expresar dicha
prosa mediante un modelo formal manipulable de
manera automática.
.Modelo de
datos de prueba
Los casos de uso contienen elementos variables
cuyos valores o comportamiento difiere de
una ejecución de un caso de uso a otra . Algunos
ejemplos son la información suministrada por un actor, una opción seleccionada
por un actor, o la información mostrada
por el sistema como resultado del caso de uso.
Los objetivos del modelo de datos de prueba son
dos. En primer lugar, el modelo de datos
de prueba expresa todas las variables del caso de
uso , su estructura si son tipos
complejos (como clientes o compras), las restricciones que puedan
existir entre ellos y las particiones de sus respectivos dominios . Esto se
realiza mediante un diagrama de clases según la notación propuesta en el
Testing Profile de UML.
Modelo de
interfaz abstracta
Los modelos anteriores nos indican lo que una
prueba debe hacer (ejecutar un escenario posible de un caso de uso), qué
información hay que suministrarle y qué información nos va a devolver. Sin
embargo estos modelos aún son demasiado abstractos y no se pueden convertir en
modelos dependientes de la plataforma ni en pruebas ejecutables de manera
directa. Por este motivo, a partir de los modelos anteriores, se obtienen los
modelos de interfaz abstracta y de interacción.
Lo primero que es necesario saber para poder
implementar las pruebas es cómo interactuar con el sistema, es decir, cuál va a
ser la interfaz que el sistema presenta a la prueba para que esta pueda
interactuar con él. El objetivo del modelo de interfaz abstracta es definir las
interfaces que el sistema ofrecerá para poder realizar la funcionalidad
expresada en el modelo de casos de uso y en el modelo de comportamiento. No es
necesario, sin embargo, entrar en detalles de la implementación de dichas
interfaces.
Modelo de
interacción
Una vez que se conocen las interfaces con las que
las pruebas interactuarán, expresadas mediante el modelo de interfaz abstracta,
se refina el modelo de comportamiento para indicar cómo realizar cada uno de
los pasos del caso de uso sobre dicha interfaz.
El objetivo del modelo de interacción es definir
cómo realiza las pruebas sus acciones y definir los árbitros. En el contexto de
las pruebas, un árbitro es elemento encargado de comprobar si la prueba fue
superada o no.
Elaborado por: Efrain Martinez Hernandez Semestre:4to Mudulo: 1
