1999 n. 1-99 - Archivo Digital del COIT

Revista de Telecomunicaciones de Alcatel – 1 Trimestre 1999
resultados de la prueba permitirán una
estimación de la fiabilidad.
■ Gestión de la
Complejidad de los
Modelos del Uso
Normalmente, es difícil modelar un sistema
con Cadenas de Markov porque
tienden rápidamente a ser muy complejas.
La única forma de hacer frente a la
creciente complejidad es a través de una
estrategia de "divide y vencerás". Son posibles
varias aprox i m a c i o n e s :
• Abstracción, que significa concentrarse
en las cosas esenciales y omitir los detalles
que pueden añadirse durante la
ejecución de las pruebas;
• Estratificación, que significa crear modelos
diferentes para aspectos diferentes
del sistema;
• Modelos jerárquicos.
La aproximación jerárquica es muy
potente. El uso del sistema se describe
primero de una forma sumamente resumida.
En el segundo paso, las transiciones
entre estados se amplían, donde sea
apropiado, a modelos del uso. Este es un
proceso recursivo. En cada nivel se añaden
más detalles, lo que conduce a un
árbol de modelos del uso.
Por desgracia, no existe un soporte de
herramientas para manejar modelos jerárquicos.
Para trabajar con ellos, pueden
ampliarse los modelos o pueden generarse
casos de prueba para submodelos
y después ampliarse a casos de prueba
completos.
Una forma especial de ampliar los casos
de prueba es la combinación de Cadenas
de Markov y expresiones gramaticales.
Esta solución funciona bien para
manejar órdenes del operador. Se comienza
con un modelo del uso de alto nivel
en el que cada estado describe un estado
del objeto manejado. [ Ejemplo: un
n ú m e ro de abonado telefónico puede
ser inexistente, estar asignado a un
abonado analógico, estar asignado a
un abonado a la red RDSI (Red Digital
de Servicios Integrados) o a una PA B X ,
e t c . ] . Los casos de prueba generados por
un modelo de este tipo son completamente
de alto nivel. Se amplían a casos
de prueba ejecutables por medio de una
expresión gramatical que describe las
posibles órdenes del operador.
Las cartas de estados son una notación
adecuada para máquinas de estados
jerárquicos, estados con registros con la
historia y estados concurrentes. Simplificarían
enormemente los modelos.
■ Pruebas Funcionales
El objetivo de las pruebas funcionales
es verificar la corrección de todas las
facilidades implementadas. Se detectarán
muchos defectos y serán necesarias
muchas actualizaciones del programa
para corregirlos. Esto hace inútil la aplicación
de la teoría de Markov para predicción
de la fiabilidad. Sin embargo,
las pruebas orientadas al uso son útiles
cuando la cobertura es un tema importante
durante las pruebas funcionales.
La cobertura del código no tiene sentido
en esta etapa del proceso de pruebas.
Se define cobertura de la prueba como
cobertura del modelo. La cobertura del
modelo (estados y arcos) puede seguirse
fácilmente y el progreso es más significativo
que en una lista de pruebas.
Para alcanzar la cobertura completa del
modelo, normalmente es necesario un
elevado número de casos de prueba
generados aleatoriamente, la mayoría
de los cuales están duplicados. La ejecución
de todos estos casos de prueba
no es posible. Alternativamente, podría
generarse un conjunto mínimo de casos
de prueba que cubriera el modelo. Esto
último tiene la desventaja de no ser realista.
Como compromiso, se generaron
suficientes casos de prueba para alcanzar
una cobertura completa del modelo
y se descartaron todas las duplicaciones.
Esto disminuye espectacularmente
el número de casos de prueba sin deteriorar
la calidad.
■ Pruebas de Certificación
El objetivo de las pruebas de certificación
es valorar la calidad del programa,
no depurarlo. No deberían comenzarse a
no ser que el programa sea estable y casi
libre de errores. Las pruebas de certificación
son pruebas de calificación interna
que afectan a la decisión sobre la
entrega del programa.
La teoría de Markov permite una predicción
precisa de la fiabilidad. La fiabilidad
calculada se representa en función
del número de casos de prueba ejecutados.
Esta representación se utiliza para
o b s e rvar el progreso de la prueba. Si no
se observan fallos (o sólo fallos menores),
la fiabilidad aumentará continuamente;
pero si los fallos son más frecuentes (o
más serios), la reducción de la fiabilidad
con cada fallo observado hará que disminuya
el valor total. Si la fiabilidad converge,
puede pararse la prueba. Si la fiabilidad
estimada es suficientemente
buena, el programa puede entregarse
después de corregir y eliminar los defectos
detectados. Si no, debe pasarse un
nuevo conjunto completo de pruebas después
de rehacer el programa.
■ Resultados
El experimento mostró que las facilidades
típicas de un conmutador RDSI pueden
modelarse con máquinas de estados
finitos “planas”. La realización del modelo
del uso de una facilidad condujo a
la detección de algunos problemas de diseño
con anterioridad a las pruebas. Las
pruebas funcionales basadas en modelos
fueron un 30% más eficaces que la integración
convencional y las pruebas de facilidades
(en términos de defectos por
caso de prueba). Adicionalmente, los defectos
fueron detectados antes. En aquellas
facilidades que se probaron con
U SS T, se encontraron solamente muy pocos
defectos durante las pruebas de certificación.
Los pocos problemas detectados
después de la entrega fueron resultado
de la integración con otras facilidades
que habían sido probadas de forma
c o n v e n c i o n a l .
En conclusión, podemos afirmar que
U SST proporciona buenos resultados.
No obstante, la solución elegida también
mostró limitaciones prácticas. Modelos
multiusuario, interacciones entre
facilidades y entradas complejas condujeron
muy pronto a modelos “que ex p l o-
taban”. Se encontró una solución para
entradas complejas (combinaciones con
expresiones gramaticales), pero los modelos
multiusuario y las interacciones
14