serie de herramientas software de carácter propietario dentro de la compañía Alcatel, en cooperación con la consultora internacional especializada en procesos de prueba SQS. En este apartado se explican, dentro de las limitaciones que impone la confidencialidad, las características de dichas herramientas [EMM02][MeET02].
Las herramientas que se explican son: el generador de casos de prueba “Test Composer”, el ejecutor de Pruebas “Test Tracker”, el emisor de veredictos de prueba “Test Comparer” y el medidor de cobertura de Pruebas “Test Cover”. En la Figura 5.4 se muestra en qué fase concreta del proceso de automatización se ha usado cada herramienta:
Entradas: Casos de Prueba Datos de Prueba Hoja de cálculo Salidas: Resultado Pruebas Registro de Mensajes Cobertura de Código Ficheros de registro
ficheros fuente EJECUTABLE
DE PRUEBA TEST COMPOSER: generación script compilación y enlazado TEST TRACKER: ejecución TEST COMPARER: veredicto de pruebas TEST COVER: medida cobertura
Figura 5.4 Herramientas aplicadas en el ejemplo industrial
5.3.1 Generador de Casos de prueba “Test Composer”
Esta herramienta genera los casos de prueba para el diagrama de estados a partir de la información contenida en una hoja de cálculo comercial (Excel) sobre los cambios de estado. Cada hoja de cálculo especifica una clase de prueba, es decir, una máquina de estados en forma de una tabla de estados y eventos, que se crea manualmente. Como se ha dicho ya, este concepto se ha aplicado con algunas diferencias sobre dos subsistemas diferentes, el FEC y el IM, que tienen diferente grado de complejidad en cuanto al número de estados y de transiciones posibles. La respuesta de la máquina de estados al evento exterior puede ser un cambio de estado, o un cambio de estado y el envío de un mensaje al exterior. Las máquinas de estados especificadas son máquinas de estados tradicionales, es decir no tienen jerarquías de estados. Por motivos de la certificación de seguridad de los subsistemas bajo prueba, asociada a las tablas de estados se incluye información de requisitos con el objetivo de documentar la trazabilidad, pero esa información se introduce en la hoja de cálculo de forma manual, lo que requiere un esfuerzo para mantener la información en un estado consistente a lo largo de todo el proceso. En el caso del entorno para el IM la información de trazabilidad de requisitos se introduce en una hoja de cálculo separada, y en el caso del FEC, con la experiencia adquirida en el entorno anterior, se usa una única hoja de cálculo para toda la información de la máquina de estados.
El caso de prueba se define de la forma:
CP= {Identificador, Einicial, Evento, Efinal}
Cada caso de prueba tiene un identificador que es usado por las diferentes herramientas del entorno para gestionarlo, y que se usa también para monitorizar el avance de las pruebas. Los estados inicial y final corresponden a estados de la clase de prueba correspondiente. El evento es en ambos entornos un mensaje, en el caso del entorno del IM puede ser un mensaje del FEC o del OM, y en el caso del entorno del FEC es siempre un mensaje del IM.
En la hoja de cálculo aparte de la información de la máquina de estados hay que incluir la información para los datos de prueba. Es decir, que hay que indicar valores concretos, también de forma manual, para los parámetros de configuración tanto del FEC como del IM. Recuérdese que se ha dicho que la variabilidad de estos subsistemas se implementa mediante ficheros de configuración específicos para cada instalación real y específicos para cada cliente (administración ferroviaria, en este caso). Una
mejora del entorno sería que los datos de prueba se reconfiguraran de forma automática leyendo los ficheros de configuración originales de cada instalación, pero no se ha abordado dentro de la Tesis Doctoral por estar muy ligada al caso concreto de aplicación.
En ambos entornos la estrategia de generación de pruebas es la de recorrer transiciones simples; es decir, no se contemplan transiciones que pasen por varios estados. Los casos en los que esta estrategia es insuficiente, se cubrieron con escenarios ejecutados de forma manual. De ahí surgió la idea de desarrollar una nueva herramienta en el marco de la Tesis Doctoral para mejorar esta fase del proceso, que se explica en el apartado 5.4.4.
En ambos entornos de validación, una vez que la hoja de cálculo con la tabla de estados se ha completado, se arranca la herramienta “Test Composer”, se selecciona la clase de prueba a la que corresponde la hoja de cálculo y el “Test Composer” transforma los casos de prueba en código, que se integra en el entorno de prueba automatizada. Aquí es claro que se está asumiendo la existencia de puntos de acceso a la implementación (IAP) en los subsistemas bajo prueba que permiten la interacción del código ejecutable generado.
5.3.2 Ejecutor de Pruebas “Test Tracker”
Esta herramienta sólo se utiliza en el entorno de validación del FEC y sirve para realizar las pruebas de forma interactiva. El “Test Tracker” se ejecuta en una plataforma hardware diferente (un PC con Windows concretamente) que la de la implementación bajo prueba, el FEC, que corre en una plataforma hardware empotrada específica, porque esto descarga al sistema bajo prueba, el FEC, del tiempo de proceso necesario para dialogar con el operador, que para un sistema de tiempo real como el FEC es difícilmente asumible y proporciona además una interfaz de usuario gráfica de la que el FEC no dispone.
En el caso del entorno de validación del IM, la ejecución de las pruebas se realiza en modo “batch” o secuencial en la misma plataforma hardware que el sistema real, y no existe un “Test Tracker”, teniendo esto la ventaja de que se realizan de una vez un número muy elevado de casos de prueba, pero también con la desventaja de que durante la fase de depuración del entorno automático, ha sido preciso analizar manualmente ficheros de registro de gran tamaño, para asegurar que el entorno no estaba falseando los resultados.
La forma de operar el “Test Tracker” se describe a continuación.
El operador selecciona en un menú primero la clase de prueba y luego los casos de prueba que va a ejecutar, conforme al plan de pruebas de validación, por ejemplo todos los casos de prueba de las agujas para RENFE.
• El “Test Tracker” ejecuta entonces en secuencia todos los casos seleccionados:
• Primero se asegura que el estado del elemento hardware es el que se ha definido para el caso de prueba. En el caso del ejemplo de la aguja de tipo RENFE, el operador comprobaría el estado del relé de posición de aguja en el grupo de relés que se conecta al motor de la aguja. Supongamos que se ha seleccionado el caso de prueba de mover aguja partiendo de posición a derechas, que es la posición en la que mirando desde la punta de la aguja, se lleva al tren a cambiar de dirección a la derecha.
a mano y dé su visto bueno para comenzar a ejecutar el caso de prueba. En el caso del ejemplo, si la aguja en vez de estar a derechas estaba a izquierdas, el operador le dice al “Test Tracker” que el estado inicial no es correcto y el “Test Tracker” envía al FEC un mando para cambiar la aguja a posición derecha.
• En este momento tiene lugar la ejecución del caso de prueba, que puede también requerir la confirmación y la intervención manual del operador. En el caso del ejemplo, es totalmente automático, el “Test Tracker” envía al FEC el mando de mover aguja, y si el FEC mueve la aguja a derechas, se lo notifica al “Test Tracker”, que da el caso de prueba por pasado. Si hay algún problema de hardware o de software por el que la aguja no se haya movido, el “Test Tracker” lo notifica al operador y le pide que confirme el fallo.
• El “Test Tracker” registra el resultado de la prueba y pasa a un nuevo caso de prueba. Los resultados de todos los casos de prueba quedan almacenados en un fichero de registro, disponibles para la medida de la cobertura y el seguimiento del proceso de pruebas.
• Cuando la ejecución de los casos de Prueba ha terminado, el operador puede seleccionar más casos de prueba o interrumpir la ejecución, si lo desea.
5.3.3 Emisor de Veredictos de Prueba “Test Comparer”
Esta herramienta analiza los ficheros de registro creados durante la generación de las pruebas y los analiza. El entorno del IM tiene un “Test Comparer” diferente al del FEC, pues los contenidos de los ficheros de registro son diferentes (ver ejemplos en Figura 4.28 y Figura 4.30). En el entorno del FEC, el “Test Tracker” ya ha emitido el veredicto de prueba y la tarea del “Test Comparer” es elaborar a partir del fichero de registro creado por el “Test Tracker” una lista con todos los casos de prueba ejecutados, diciendo cuáles han pasado y cuáles han fallado. En el caso del IM no existe “Test Tracker” sino que la ejecución es secuencial en modo no interactivo, y se guarda en el fichero de registro el resultado real del caso de prueba y el resultado esperado del caso de prueba para que el “Test Comparer” los analice. El “Test Comparer” analiza en el fichero de registro si el resultado real se corresponde con el esperado, y si es así emite un veredicto de caso de prueba pasado, y si no, de caso de prueba fallido (Ver Figura 4.29).
En ambos entornos, el operador selecciona en un menú el fichero de registro de pruebas y el “Test Comparer” crea un nuevo fichero de resultados con la lista de todos los casos de prueba ejecutados, y una estadística final de casos de prueba pasados y casos de prueba fallidos.
5.3.4 Evaluador de Cobertura de Pruebas “Test Cover”
Para saber qué porcentaje de los requisitos se ha cubierto con las pruebas realizadas, se usa la herramienta “Test Cover”. Esta herramienta se sirve de la información de trazabilidad de requisitos existentes en las hojas de cálculo donde se especifican las máquinas de estados en forma de tabla. Como ya se ha dicho, se asocia a cada caso de prueba uno o más requisitos, tras analizar el contenido de la especificación, lo que requiere esfuerzo, y no es automatizable. Este esfuerzo crece mucho si los requisitos son muy numerosos y tienen un nivel de detalle muy alto, por ello en ese caso una opción a considerar es la de clasificar los requisitos en “niveles de especificación”, por ejemplo unos que sean esenciales y otros de detalle, y asignar a las transiciones y estados del modelo de la clase de prueba sólo los requisitos esenciales. En el caso de validación industrial el esfuerzo de trazabilidad está justificado por las exigencias de certificación de seguridad del dominio de aplicación.
El “Test Cover” necesita como entrada las hojas de cálculo que contienen los casos de prueba. El operador selecciona la hoja de cálculo correspondiente a la clase de prueba que desea verificar y el “Test Cover” genera un fichero donde aparecen todos los requisitos asociados a los casos de prueba seleccionados. Adicionalmente, el operador dispone de una serie de comandos de consulta para obtener los valores del número de casos de prueba y el número de requisitos cubiertos.
La herramienta “Test Cover” no se utilizó de forma tan intensiva como las demás, pues no se consiguió por motivos de tiempo una versión que pudiera integrar de forma automática los resultados de todas las clases de prueba de una vez, y esa labor debió de ser realizada manualmente integrando la información de todos los ficheros de registro de la ejecución de los casos de prueba para ambos entornos automáticos.