| 1 | //////////////////////////////////////////////////////////////////////////////
|
|---|
| 2 | // //
|
|---|
| 3 | // TOL-Tester //
|
|---|
| 4 | // //
|
|---|
| 5 | //////////////////////////////////////////////////////////////////////////////
|
|---|
| 6 |
|
|---|
| 7 | ==============================================================================
|
|---|
| 8 | A) Definición de TOL-Tester
|
|---|
| 9 | ==============================================================================
|
|---|
| 10 |
|
|---|
| 11 | Se trata de un sistema estándar de chequeo del comportamiento del lenguaje TOL
|
|---|
| 12 | y de las herramientas relacionadas como TOLBase. Antes de publicar cada nueva
|
|---|
| 13 | versión se debe comprobar que TOL actúa como se espera lo cual no suele ser
|
|---|
| 14 | nada trivial dado el extenso número de aplicaciones del lenguaje.
|
|---|
| 15 |
|
|---|
| 16 |
|
|---|
| 17 | ==============================================================================
|
|---|
| 18 | B) Estructura de TOL-Tester
|
|---|
| 19 | ==============================================================================
|
|---|
| 20 |
|
|---|
| 21 | En el directorio raíz se encuentran los ficheros TOL comunes a todas las
|
|---|
| 22 | baterías de tests además de éste fichero de ayuda.
|
|---|
| 23 |
|
|---|
| 24 | - _testCommon.tol : Estructuras y funciones auxiliares comunes
|
|---|
| 25 | - _testConfig.tol : Parámetros de configuración comunes
|
|---|
| 26 |
|
|---|
| 27 | Los tests se encuentran clasificados en directorios dependiendo del PRODUCTO
|
|---|
| 28 | concreto que se intenta probar. Dentro de cada producto existirán directorios
|
|---|
| 29 | dedicados a las distintas baterías de tests que lo comprueban, en virtud del
|
|---|
| 30 | TEMA a chequear. El par PRODUCTO/TEMA define una BATERÏA de tests
|
|---|
| 31 | relacionados entre sí.
|
|---|
| 32 |
|
|---|
| 33 | Dentro de cada batería puede haber una estructura totalmente libre de
|
|---|
| 34 | subdirectorios que se recorrerán recursivamente en busca de archivos
|
|---|
| 35 | test.tol los cuales se interpretarán como cada uno de los tests particulares
|
|---|
| 36 | de la batería asociada. De esta manera cada batería se puede adaptar a sus
|
|---|
| 37 | necesidades de forma muy flexible sin perder generalidad ni facilidad de uso.
|
|---|
| 38 |
|
|---|
| 39 | A cada uno de los paths relativos a la batería que contengan un test le
|
|---|
| 40 | llamaremos BASE del test. Es decir los tests se definen en los ficheros de
|
|---|
| 41 | la forma PRODUCTO/TEMA/BASE/test.tol
|
|---|
| 42 |
|
|---|
| 43 | Por el momento existen los siguientes productos y temas
|
|---|
| 44 |
|
|---|
| 45 | -tol: los tests acerca del lenguaje propiamente dicho sin que intervenga
|
|---|
| 46 | ningún módulo auxiliar
|
|---|
| 47 |
|
|---|
| 48 | -tol/Bugzilla: comprueba que los bugs resueltos siguen funcionando
|
|---|
| 49 | -tol/ARIMA: Tests de simulación acerca de modelos ARIMA
|
|---|
| 50 | -tol/TimeSetCoherence: Tests de simulación acerca del álgebra del tiempo
|
|---|
| 51 |
|
|---|
| 52 | -tolcon: los tests acerca del ejecutable de TOL en modo de consola
|
|---|
| 53 |
|
|---|
| 54 | -tolcon/Bugzilla: comprueba que los bugs resueltos siguen funcionando
|
|---|
| 55 |
|
|---|
| 56 | -toltcl: los tests acerca de la API de comunicación de TCL con TOL para la
|
|---|
| 57 | construcción de interfaces
|
|---|
| 58 |
|
|---|
| 59 | -toltcl/Bugzilla: comprueba que los bugs resueltos siguen funcionando
|
|---|
| 60 |
|
|---|
| 61 | -toldb: los tests acerca de la conexión de TOL con bases de datos
|
|---|
| 62 |
|
|---|
| 63 | -toldb/Bugzilla: comprueba que los bugs resueltos siguen funcionando
|
|---|
| 64 |
|
|---|
| 65 |
|
|---|
| 66 | ==============================================================================
|
|---|
| 67 | B) Modo de empleo de TOL-Tester
|
|---|
| 68 | ==============================================================================
|
|---|
| 69 |
|
|---|
| 70 | En cada directorio existe un archivo _tolTester.tol que se encarga de realizar
|
|---|
| 71 | todo lo necesario, y que debe ser compilado con la versión de TOL que se desea
|
|---|
| 72 | comprobar.
|
|---|
| 73 |
|
|---|
| 74 | Antes de hacerlo es conveniente repasar la configuración de la lista de
|
|---|
| 75 | baterías de tests que se desean comprobar en el conjunto TestConfigTable de
|
|---|
| 76 | registros con estructura strBatteryConfig definida en _testCommon.tol
|
|---|
| 77 |
|
|---|
| 78 | Los test se pueden ejecutar una o varias veces o incluso ninguna si así se
|
|---|
| 79 | especifica en TestConfigTable, para facilitar de este modo la adaptación a
|
|---|
| 80 | diferentes situaciones de chequeo de cada una de las baterías. Por ejemplo,
|
|---|
| 81 | tras un cambio profundo de TOL o al publicarse una nueva versión sería
|
|---|
| 82 | conveniente realizar un chequeo exhaustivo que puede durar varias horas,
|
|---|
| 83 | pero tras una leve modificación quizás sólo queremos probar alguna batería
|
|---|
| 84 | en concreto o un poco de todo, de forma que dure apenas unos minutos. Nos
|
|---|
| 85 | referiremos a cada una de estas ejecuciones con el término ITER.
|
|---|
| 86 |
|
|---|
| 87 | Opcionalmente, un test puede tener un fichero de parametrización PARAM que
|
|---|
| 88 | se puede usar, por ejemplo, para modular el volumen de las simulaciones
|
|---|
| 89 | efectuadas.
|
|---|
| 90 |
|
|---|
| 91 | ==============================================================================
|
|---|
| 92 | C) Visualización de resultados
|
|---|
| 93 | ==============================================================================
|
|---|
| 94 |
|
|---|
| 95 | La mayoría de los tests serán deterministas en el sentido de que sólo pueden
|
|---|
| 96 | salir bien o mal, pero otras veces no es posible determinar tal cosa y tan
|
|---|
| 97 | sólo se puede dar una medida probabilística e incluso subjetiva de la calidad
|
|---|
| 98 | obtenida.
|
|---|
| 99 |
|
|---|
| 100 | El programa irá sacando una traza del cada test con el resultado de su
|
|---|
| 101 | calidad en una norma probabilística de 0 a 100% así como el tiempo empleado.
|
|---|
| 102 |
|
|---|
| 103 | Al final de cada batería se dará un pequeño resumen de sus resultados y una
|
|---|
| 104 | vez terminada la compilación es posible ver sendos resumenes a nivel de
|
|---|
| 105 | batería (AllReport) y a nivel de test (AllDetail) donde se puede encontrar
|
|---|
| 106 | información adicional acerca de los tests que no hayan dado el resultado
|
|---|
| 107 | esperado.
|
|---|
| 108 |
|
|---|
| 109 | Cada test genera de forma automática un directorio de resultados localizado
|
|---|
| 110 | en PRODUCTO/.result/test_YYYY_MM_DD_HH_MM/[PARAM_]TEMA/BASE[/ITER] en el que
|
|---|
| 111 | se almacenan estos ficheros
|
|---|
| 112 |
|
|---|
| 113 | - test.bat: fichero de llamada del test por si se quiere
|
|---|
| 114 | reproducir posteriormente
|
|---|
| 115 | - test.log: fichero de salida estándar de la ejecución para
|
|---|
| 116 | buscar posibles errores o anomalías
|
|---|
| 117 | - test.bst: fichero de resultados utilizado después para generar
|
|---|
| 118 | las tablas de resúmenes.
|
|---|
| 119 |
|
|---|
| 120 | Nota: YYYY_MM_DD_HH_MM significa año,mes,día,hora,minuto
|
|---|
| 121 |
|
|---|
| 122 | ==============================================================================
|
|---|
| 123 | D) Funcionamiento interno de TOL-Tester
|
|---|
| 124 | ==============================================================================
|
|---|
| 125 |
|
|---|
| 126 | Cada test retornara un Set de estructura strTestStatus definida en
|
|---|
| 127 | _testCommon.tol con la informacion de los resultados propiamente dichos y
|
|---|
| 128 | elementos desriptivos y auxiliares. La llamada a cada uno se hará usando el
|
|---|
| 129 | sistema operativo para arrancar una nueva sesión TOL para evitar por un lado
|
|---|
| 130 | efectos colaterales entre los distintos tests así como salvaguardar el proceso
|
|---|
| 131 | de lanzamiento de posibles caídas provocadas en uno de ellos.
|
|---|
| 132 |
|
|---|
| 133 | El que invoca cada test (tol_tester) se encarga de recolectar las metricas que
|
|---|
| 134 | son generales para todos los tests además de la devuelta en el strTestStatus,
|
|---|
| 135 | confeccionando un conjunto de estructura strTestMetric definida en
|
|---|
| 136 | _testCommon.tol, en la que se incluye la información heredada de la batería a
|
|---|
| 137 | la que pertenece así como de los cambios de estado de ciertas variables:
|
|---|
| 138 | tiempo y memoria empleados, número de errores y warnings, etc.
|
|---|
| 139 |
|
|---|
| 140 | Cuando se finaliza un batería concreta se genera un conjunto con estructura
|
|---|
| 141 | strTestBattery definida en _testCommon.tolen el que se incluye información
|
|---|
| 142 | sobre la propia definición de la batería, sobre las condiciones de ejecución
|
|---|
| 143 | del test (sistema operativo, versión del compilador y de TOL, momento de
|
|---|
| 144 | inicio), así como algunos estadísticos de resumen de los resultados obtenidos.
|
|---|
| 145 |
|
|---|
| 146 |
|
|---|
| 147 | ==============================================================================
|
|---|
| 148 | E) Tareas por hacer en TOL-Tester
|
|---|
| 149 | ==============================================================================
|
|---|
| 150 |
|
|---|
| 151 | 1- En una etapa posterior podria ser interesante almacenar toda la informacion
|
|---|
| 152 | en una base de datos a modo de realizar queries avanzadas que permitan hacer
|
|---|
| 153 | un diagnostico automatico del resultado de los tests.
|
|---|
| 154 |
|
|---|
| 155 | 2- En ocasiones la ejecución de un test puede ocasionar un ciclo infinito o
|
|---|
| 156 | que se quede a la espera por cualquier motivo (especialmente en windows que
|
|---|
| 157 | tiene por costumbre sacar ventanas para cualquier tontería). En tales casos
|
|---|
| 158 | sería necesario poder lanzar los tests como hilos y quedar a la espera hasta
|
|---|
| 159 | que el test acabe o transcurra un tiempo máximo. Mientars no sea así los tests
|
|---|
| 160 | se tendrán que seguir lanzando bajo la tutela de un operario.
|
|---|
| 161 |
|
|---|
| 162 | 3- Otra posibilidad relacionada con la anterior sería lanzar los tests contra
|
|---|
| 163 | otras máquinas de forma remota utilizando TRC o cualquier otro método, para
|
|---|
| 164 | liberar recursos en la máquina cliente y dedicar máquinas específicas a las
|
|---|
| 165 | tareas de chequeo de versiones de TOL.
|
|---|
| 166 |
|
|---|
