Como generar scripts de prueba ejecutables a partir de casos de prueba abstractos.

Como generar scripts de prueba ejecutables a partir de casos de prueba abstractos.

Luis Alberto Bonilla Len
Abstract Este articulo tiene como propsito ilustrar el mtodo de generacin automtica de scripts ejecutables a partir de pruebas abstractas y la automatizacin de su ejecucin a travs de herramientas especializadas como MessageMagic, se revisan conceptos tericos de adaptacin de pruebas y se describe detalladamente el procedimiento de automatizacin de la ejecucin de las pruebas. Index Terms Pruebas de software, MBT, Conformiq Qtronic, Elvior Message Magic, Adaptacin de pruebas, Scripts de prueba, Ejecucin automtica.

MessageMagic para la automatizacin de la ejecucin, en la seccin tres se revisan conceptos de adaptacin de pruebas y los distintos enfoques para realizar la transformacin de las pruebas abstractas, en la seccin cuatro se resume la generacin de casos de prueba a partir de modelos y por ultimo en la seccin cinco se describe detalladamente el proceso de adaptacin a travs de MessageMagic y la interaccin de este con el sistema bajo prueba.

II. ANTECEDENTES CONCEPTUALES A. Conformiq Qtronic. Conformiq Qtronic es una herramienta para la automatizacin del diseo de casos de prueba a partir de modelos, esto significa que Conformiq Qtronic disea automticamente pruebas para un sistema dado un modelo como entrada. Estas pruebas son pruebas de caja negra, es decir que se evala el sistema bajo prueba basndose solamente en su comportamiento externo, no monitoreando su actividad a nivel interno directamente (pruebas de caja blanca).[4] Este modelo es una descripcin del comportamiento previsto del sistema en algn nivel de abstraccin, aunque modelos de diseo del sistema pueden ser utilizados, generalmente se utiliza un modelo ms abstracto y simplificado. Estos modelos pueden ser expresados como una coleccin de: 1. Archivos de texto en notacin compatible con Java a nivel extendido que describa los tipos de datos, constantes, clases y sus mtodos. Maquinas de estado o diagramas de estado con mtodos y procedimientos en sintaxis Java representando el comportamiento lgico de las clases y sus transiciones (Action, Guard, Effect) Diagramas de clase como una alternativa grafica para declarar clases y sus relaciones.

CONTENIDO I. Introduccin. II. Antecedentes conceptuales. II-A. Conformiq Qtronic. II-B. Elvior MessageMagic. III. Principios de adaptacin de pruebas. III-A. Aproximacin de adaptacin. III-B. Aproximacin de transformacin. III-C. Cual aproximacin es mejor? IV. Generando scripts de prueba a partir de casos de prueba abstractos realizados en Qtronic. V. Automatizando la ejecucin de las pruebas mediante MessageMagic. VI. Referencias.

I. INTRODUCCIN Parte del potencial presente en la aplicacin de la metodologa basada en modelos en los procesos de pruebas de software es la relativamente sencilla integracin de esta con los mtodos de ejecucin automtica de pruebas presentes en una organizacin, o si es el caso, la implementacin de estos mtodos como complemento de la automatizacin del diseo de pruebas. Este artculo introduce los conceptos generales de la metodologa a seguir para transformar ambientes de prueba abstractos en pruebas ejecutables as como las herramientas que pueden ser utilizadas para este proceso, en la seccin dos se resumen las caractersticas de las herramientas utilizadas, Qtronic para la generacin automtica de casos de prueba y 2.

3.

Los modelos tambin pueden ser vistos como requerimientos operacionales o de comportamiento, ellos describen el propsito de las caractersticas externas del sistema o en otras palabras como el sistema debe funcionar desde la perspectiva del usuario. Los modelos no necesitan expresar la estructura de la implementacin del sistema mientras expresen las caractersticas observables del mismo.

Como generar scripts de prueba ejecutables a partir de casos de prueba abstractos. Conformiq Qtronic selecciona y opcionalmente ejecuta pruebas automticamente basndose en el modelo, adems calcula las respuestas esperadas del sistema bajo prueba de forma automtica, con esta herramienta no es necesario crear scripts de prueba manualmente, el diseo de las pruebas, opcionalmente su ejecucin y anlisis se realizan automticamente, de esta forma logra una reduccin directa de costo y riesgo. Detrs de esto beneficios obvios Conformiq Qtronic brinda un cambio sensible en el proceso de desarrollo de software, comunica el diseo con la validacin de una forma revolucionaria.[5] B. Elvior MessageMagic. MessageMagic es una plataforma de desarrollo y ejecucin de pruebas en TTCN-3 (Testing and Test Control Notation versin 3), puede ser usado para probar componentes de software o hardware en un amplio rango de sectores de la industria. Sistemas que pueden ser candidatos para ser probados con MessageMagic se encuentran en sectores de la industria donde TTCN-3 es ampliamente usado como una notacin de pruebas estndar, como en Comunicaciones, Transporte, Militar y de Defensa. Elvior MessageMagic es ideal para el desarrollo de proyectos de forma incremental, puede ser usado para la prueba de tareas individuales o procesos, continuando con pruebas de integracin de subsistemas hasta llegar al sistema completo e incluso realizar las pruebas mientras software y el hardware estn trabajando en conjunto. MessageMagic simplifica y acelera el desarrollo del producto con todos los beneficios que se derivan de ciclos de desarrollo cortos. A continuacin se resumen algunas de las funcionalidades bsicas que provee la herramienta. Editor, compilador plataforma de ejecucin para pruebas en TTCN-3. TTCN-3 Runtime Interface (TRI) compatible con C/C++, C# y Java. TTCN-3 Control Interface (TCI) compatible con C/C++, C# y Java. Cdec preconstruidos en ASN.1 y BER Texto XML Binario Administracin de pruebas va configuraciones de prueba independientes. Opcin de lnea de comandos. Registro (logging) automtico de trafico de mensajes. Visualizacin detallada del contenido de los mensajes. Soporte para estndares TTCN-3 2003(v 2.2.1), 2005(v 3.1.1), 2007(v 3.2.1), 2008 (v 3.3.2), 2008 Amendment (v 3.4.1), 2009 (v 4.1.1). III. PRINCIPIOS DE ADAPTACIN DE PRUEBAS.

A partir del uso de la metodologa de pruebas basadas en modelos para generar un buen ambiente de pruebas, ser natural que queramos automatizar la ejecucin de estas pruebas para consolidar un proceso de pruebas automatizado en el que podamos ejecutar ms pruebas, pruebas ms frecuentes para pruebas de regresin, reducir nuestros costos de ejecucin de pruebas, reducir el tiempo total de pruebas, etc. El problema que enfrentamos al tratar de ejecutar pruebas generadas a partir de un modelo es que las pruebas generadas son altamente abstractas, al igual que el modelo, en consecuencia estas pruebas no contienen suficientes detalles concretos para ser directamente ejecutadas en el sistema bajo prueba (SUT), en otras palabras el API (Application Program Interface) del modelo no coincide exactamente con el API del SUT. Recordando algunos conceptos de la metodologa de pruebas basadas en modelos algunas abstracciones usadas frecuentemente cuando se disea un modelo para propsitos de prueba son: Modelar solamente un aspecto del sistema no todo su comportamiento. Omitir entradas y salidas que no son relevantes para los objetivos de prueba. Tomar una visin simplificada de datos completos a travs del uso de enumeraciones. Asumir que el SUT ya ha sido inicializado para coincidir con las caractersticas de un escenario particular de pruebas. Definir en el modelo operaciones simples que correspondan a secuencias de operaciones o a solo una parte de una operacin del SUT.

Para ejecutar las pruebas generadas debemos en primer lugar inicializar el sistema para que est listo para nuestro ambiente de pruebas, adicionar los detalles faltantes en las pruebas y arreglar algunas discordancias entre el API del modelo y el SUT para que nuestras pruebas puedan conectarse a la interfaz del SUT. Adems debemos administrar las relaciones entre los valores abstractos en el modelo y los valores reales u objetos en el sistema, esto requiere expandir estos valores abstractos en valores concretos ms complejos que puedan ser usados como entradas del SUT. Para que sea posible comprobar las salidas del SUT contra el modelo tendremos que transformar las salidas esperadas del modelo (orculos) en valores concretos o alternativamente transformar las salidas concretas del SUT en valores abstractos para comprobar su correctitud. Si el modelo es determinstico cualquier enfoque puede ser usado pero si es no determinstico entonces la segunda opcin es mejor. Si el SUT crea nuevos objetos durante el proceso de pruebas, generalmente ser necesario seguir el rastro de la identidad de estos objetos y no solo sus valores. Esto requiere el mantenimiento de una tabla de correspondencia (mapping) entre los objetos abstractos del modelo y los correspondientes

Como generar scripts de prueba ejecutables a partir de casos de prueba abstractos. objetos concretos creados en el SUT. As, cada vez que en el modelo se cree un nuevo valor abstracto A, el SUT realizar la operacin correspondiente y crear un objeto concreto C; de esta forma se agrega el par (A,C) en la tabla de correspondencia para que futuros usos de A en el modelo puedan ser interpretados como usos de C en el SUT. Estas tcnicas son todas ejemplos de la diferencia en niveles de abstraccin entre el modelo y el SUT, a continuacin se resumen las principales aproximaciones para enlazar esta brecha de abstraccin para despus analizarlas en ms detalle en su correspondiente apartado. En primer lugar la aproximacin de adaptacin que consiste en escribir manualmente un cdigo adaptador (Adaptor) que comunique la parte abstracta y la concreta. Esto es esencialmente una envolvente al SUT que provee una visin ms abstracta del mismo para coincidir con el nivel de abstraccin del modelo. Por otro lado la aproximacin de transformacin que consiste en transformar las pruebas abstractas en scripts de prueba concretas. Por ltimo la aproximacin mixta que es una combinacin de las dos anteriores usada en los casos en que es til adicionar algn cdigo adaptador alrededor del SUT para incrementar el nivel de abstraccin parte del camino hacia el modelo para hacer las pruebas ms fciles y entonces transformar las pruebas abstractas en una forma ms concreta que coincida con la interfaz de adaptacin. Algunos beneficios de este enfoque mixto es que las transformaciones pueden ser ms fciles, ya que los niveles de abstraccin son ms cercanos y el cdigo adaptador puede ser menos especfico al modelo lo cual permite su reutilizacin en diferentes modelos o escenarios de prueba.

Setup: Responsable de la puesta a punto del SUT para que est listo para la prueba, esto puede incluir configurar e inicializar el SUT para que refleje el escenario de prueba asumido por el modelo. Concretizacin: Traduce cada llamada a una operacin abstracta a nivel del modelo y sus valores de entrada abstractos en una o ms llamadas concretas del SUT con los valores apropiados de entrada. Abstraccin: Obtiene los resultados del SUT a partir de las llamadas concretas y los traduce de vuelta en valores abstractos para ser comparados con los resultados esperados consignados en el modelo para producir el veredicto de la prueba. Teardown: Apaga el SUT al final de cada secuencia de prueba o al desplegar resultados de prueba. Existen muchas posibles arquitecturas para conectar la herramienta de pruebas basadas en modelos, el cdigo adaptador y el SUT pero en conclusin cualquier cdigo adaptador transforma cada llamada a una operacin abstracta en operaciones de bajo nivel del SUT simultneamente mientras es interpretada. B. Aproximacin de transformacin. La aproximacin de transformacin consiste en transformar cada prueba abstracta en un script de prueba ejecutable, los scripts de prueba resultantes generalmente estn en alguna de las siguientes notaciones. Un lenguaje de programacin estndar como Java o C. Un lenguaje de scripting como TCL, JavaScript o VBScript. Una notacin de pruebas estndar como TTCN-3. Una notacin de pruebas propietaria como TSL (Test Script Language) de Mercury WinRunner o alguna notacin de alguna compaa especifica. El proceso de transformacin puede ser realizado por un programa traductor de propsito simple que siempre produzca una salida para un lenguaje en particular o por un motor ms genrico capaz de transformar pruebas abstractas en varios lenguajes diferentes a travs de templates y mappings para cada lenguaje de salida. La aproximacin de transformacin puede producir scripts de prueba que se ajusten a las prcticas de administracin de pruebas existentes en la organizacin con un lenguaje similar, estructura y convenciones respecto a nombres como las pruebas escritas de forma manual. C. Cul aproximacin es mejor? Para la mayora de los autores es recomendable usar la aproximacin de adaptacin para pruebas en lnea (online testing) porque este tipo de pruebas requieren una integracin ms estrecha entre la herramienta de pruebas basadas en modelos y el SUT, esto es ms fcil de lograr si la herramienta puede conectarse directamente al API del cdigo adaptador y este a su vez corre conectado directamente al SUT.

Figura 1. Tres aproximaciones para comunicar los casos de pruebas con el SUT. Tomada de [1].

A continuacin exploraremos las alternativas de adaptacin y transformacin en ms detalle y discutiremos cual adaptacin es mejor para cada clase de aplicacin. A. Aproximacin de Adaptacin. La aproximacin de adaptacin como hemos mencionado anteriormente consiste en escribir un cdigo adaptador que acta como intrprete entre los detalles de bajo nivel presentes en el SUT y la visin ms abstracta de este especificada en el modelo. Ms especficamente el cdigo adaptador es responsable por las siguientes tareas.

Como generar scripts de prueba ejecutables a partir de casos de prueba abstractos. Para pruebas fuera de lnea (offline testing) podemos escoger entre los dos enfoques o usar una mezcla de los dos, si usamos la aproximacin de transformacin obtendremos un conjunto de scripts que pueden ser ejecutados directamente en el SUT o podemos usar la aproximacin de adaptacin haciendo nuestras pruebas abstractas ejecutables a travs del cdigo adaptador conectado al SUT. El enfoque de transformacin tiene la ventaja de producir scripts en el mismo lenguaje y estructura que las convenciones ya existentes en una organizacin reduciendo el impacto de su uso en organizaciones con procesos de pruebas consolidados.

Estos tres scripts en TTCN-3 generados automticamente por Qtronic nos servirn como recurso para automatizar la ejecucin de las pruebas como lo veremos en la siguiente seccin.

V. AUTOMATIZANDO LA EJECUCIN DE LAS PRUEBAS MEDIANTE MESSAGEMAGIC. Para automatizar la ejecucin de las pruebas utilizaremos Elvior MessageMagic cuyas caractersticas hemos mencionado anteriormente, adems de eso no tendra sentido automatizar el proceso de pruebas si no tenemos un sistema que probar, para ejemplificar el proceso hemos desarrollado una implementacin simple pero con toda la funcionalidad que requiere el problema del triangulo, se codifico en lenguaje Java por su amplia utilizacin en la industria y su versatilidad, se cre un archivo .JAR que contiene la aplicacin con todas sus libreras y un archivo .BAT para su ejecucin en plataforma Windows. MessageMagic (MM) est diseado para interactuar con el SUT mediante de una conexin TCP/IP a travs de una interfaz conocida como TRI (TTCN-3 Runtime Interface), al establecer comunicacin con el SUT mediante un protocolo de trasmisin de datos como TCP/IP necesariamente deberemos implementar un cdigo de adaptacin que le permita a nuestro SUT enviar y recibir datos a travs de TCP/IP, para facilitar la construccin de este cdigo MM nos ofrece una serie de plugin en diferentes lenguajes como C/C++, C# y Java, para nuestra aplicacin seleccionaremos el plug-in Java ya que es el lenguaje en el que esta implementada nuestra aplicacin.

IV. GENERANDO SCRIPTS DE PRUEBA A PARTIR DE CASOS DE PRUEBA ABSTRACTOS REALIZADOS EN QTRONIC. Como se menciono anteriormente Qtronic nos permite generar automticamente casos de prueba a partir de un modelo abstracto, por conveniencia para ejemplificar el potencial de la metodologa de pruebas basadas en modelos usaremos un ejemplo preconstruido que podemos encontrar en el directorio de instalacin de Qtronic y que corresponde al problema del triangulo clsico formulado por Myers en [3] como sigue: El programa lee tres valores enteros positivos como entrada, estos valores representan la longitud de los tres lados de un triangulo, el programa imprime un mensaje de estado diciendo si el triangulo es escaleno, issceles o equiltero Generaremos los casos de prueba con la configuracin de prueba Exhaustive predefinida en este ejemplo y obtendremos 19 casos de prueba para nuestro SUT. Con nuestro conjunto de casos de prueba procederemos a generar scripts para estos casos utilizando uno de los scripters que nos provee Qtronic, por conveniencia utilizaremos el TTCNScripter que transformara nuestros casos de prueba en TTCN-3(Testing and Test Control Notation versin 3) que es un lenguaje de scripting formal usado ampliamente en la industria, debemos prestar especial atencin en configurar el scripter para generar no solo el script que contiene el ambiente de pruebas (TestSuite), sino tambin el script de tipos (QtronicTypes) y el de mtodos (QtronicTestHarness) que contendrn las definiciones de las operaciones utilizadas para la ejecucin de los casos de prueba.

Para guiarnos podemos consultar un ejemplo preconstruido en MM, este ejemplo implementa una clase Comm que actua como envolvente del SUT encargndose de la comunicacin, para nuestro ejemplo realizaremos exactamente lo mismo. En nuestro proyecto Triangle, construido en Eclipse un reconocido IDE para Java, el cual contiene las clases propias de nuestra aplicacin adicionaremos el plug-in como librera seleccionando el archivoTriTciJava.jar del directorio lib/Java en la carpeta de instalacin de MM. A continuacin crearemos una clase que servir de condigo de adaptacin entre el SUT y MM que en este caso nombraremos Comm, esta clase deber implementar las interfaces TriCommunicationSA, TriPlatformPA adems de ChannelEventHandler en caso de que queramos reaccionar a eventos propios de la conexin como captura de errores. class Comm implements TriCommunicationSA, TriPlatformPA, ChannelEventHandler Crearemos instancias de las clases que implementamos y las registraremos en la clase TriProvider, adems si

Como generar scripts de prueba ejecutables a partir de casos de prueba abstractos. ChannelEventHandler fue implementado tendremos que registrar su instancia en TriTciChannel. TriProvider.getInstance().setTriCommunica tionSA(this); TriProvider.getInstance().setTriPlatformP A(this); TriTciChannel.getInstance().setEventHandl er(this); Para establecer la conexin TCP/IP entre el SUT y MM se ejecuta una llamada al mtodo Open de la instancia TriTciChannel. TriTciChannel.getInstance().open() Esta llamada la hemos ejecutado al interior de un mtodo llamado Run que sincroniza la conexin y termina la ejecucin de la aplicacin en caso de que no haya una conexin exitosa. Para la conexin basada en mensajes ms simple sobre TRI necesitaremos adicionar algn cdigo a dos mtodos de la interfaz TriCommunicationSA, al mtodo TriMap que guarda informacin necesaria para enviar informacin a MM como componentes y puertos del sistema, y el mtodo TriSend que es necesario para recibir informacin de MM, en el caso de nuestra aplicacin simple de clasificacin de triangulos utilizaremos TriSend para recibir entradas en formato de tramas (TCP/IP) y transformarlas en la cadena de caracteres propia de la lgica de nuestra aplicacin, adems para enviar mensajes desde el SUT a MM usaremos el mtodo TriEnqueueMsg de la instancia de TriProvider. TriProvider.getInstance().TriEnqueueMsg Con esto lograremos una interaccin entre nuestro SUT y MM a travs del cdigo de adaptacin, el siguiente paso es ya directamente en MM crear una nueva solucin (proyecto de MM) para la ejecucin de nuestras pruebas, creada nuestra solucin y desde la vista de navegacin del proyecto importaremos al nodo Scripts los scripts en TTCN-3 que hemos creado previamente con la ayuda de Qtronic, es decir los archivos TestSuite.ttcn3, QtronicTypes.ttcn3 y QtronicTestHarness.ttcn3, es importante que estos tres archivos sean importados a la solucin de MM y que compilen correctamente, ntese que al importarlos estamos trabajando directamente sobre estos archivos y no sobre copias de los mismos, dependiendo de las caractersticas de nuestro SUT tendremos que adicionar cdigo a los mtodos que nos ha generado Qtronic automticamente como la comparacin entre salidas del SUT con las salidas esperadas en el modelo y de acuerdo a estas, criterios de decisin de cuando una prueba es exitosa (PASS) o fallida (FAIL).

Por ltimo para acoplar nuestro SUT a nuestra solucin de MM, seleccionaremos el nodo SUT en la vista de navegacin del proyecto e introduciremos la ubicacin de nuestra aplicacin que en el caso de nuestro ejemplo corresponde a Triangle.bat que ejecuta nuestro archivo .JAR, es importante notar que esta ruta es siempre relativa al directorio donde se encuentra nuestra solucin, as que por conveniencia y simplicidad es recomendable conservar todo lo necesario en un solo directorio. Con estos pasos tendremos nuestro proyecto listo, podremos ejecutar nuestro script de prueba y disponernos a corregir los errores correspondientes, con la interaccin de estas dos potentes herramientas hemos automatizado el diseo y la ejecucin de las pruebas para aumentar nuestra eficiencia en el proceso de verificacin y validacin, detectaremos los defectos de la aplicacin, modificaremos el modelo manualmente, generaremos las pruebas y las ejecutaremos automticamente cuantas veces sea necesario para garantizar la calidad de nuestro software de manera sistemtica y confiable.

Como generar scripts de prueba ejecutables a partir de casos de prueba abstractos. VI. REFERENCIAS
[1] M. Utting and B.Legeard, Practical Model-Based Testing, Morgan Kaufmann Publishers. 2007. [2] J, Warmer and A, Kleppe, The Object Constraint Language: Getting your models ready to MDA, 2nd Edition, Addison Wesley, 2003. [3] .J, Myers, The Art of Software Testing, John Wiley & Sons. 1979. [4] http://www.conformiq.com/ [5] Conformiq Qtronic2 Manual 1998-2008. [6] http://www.elvior.ee/messagemagic/general [7] MessageMagic User Guide [8] TRI in Java tutorial for MessageMagic