En
este punto se describen un conjunto de modelos de prueba independientes y
dependientes de la plataforma (PITs y PDTs).
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. Actualmente existen varias propuestas de modelos de requisitos. En concreto, la
propuesta que utilizamos en este trabajo es
Web Requirement (WebRE) , la cual está basada en Navigational Development Techniques (NDT) .
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.
El
objetivo del modelo de comportamiento es expresar la misma información
contenida en una plantilla de caso de uso de una forma fácilmente manipulable.
Las propuestas estudiadas utilizan como modelos de comportamiento diagramas UML
de estados, diagramas UML de secuencia o diagramas UML de actividades.
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.
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, 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. Dicho
diagrama de clases puede extraerse automáticamente. Las clases se obtienen a
partir de los requisitos funcionales y las distintas particiones se obtienen a
partir de las condiciones evaluadas en las alternativas del diagrama de
comportamiento. Este diagrama de clases puede refinarse posteriormente
añadiendo particiones adicionales si fuera necesario.
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
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.
