Para aumentar la capacidad de mantenimiento y de reutilización de los scripts de prueba, deben estar estructurados
antes de que se implementen. Probablemente encontrará que hay acciones que aparecerán en varios scripts de prueba. Un
objetivo debería ser identificar estas acciones para que pueda reutilizar su implementación.
Por ejemplo, puede tener scripts de prueba que son combinaciones de diferentes acciones que se pueden efectuar en un
registro. Estos scripts de prueba pueden ser combinaciones de adición, modificación y eliminación de un registro:
-
Añadir, Modificar, Suprimir (lo obvio)
-
Añadir, Suprimir, Modificar
-
Añadir, Suprimir, Añadir, Suprimir, ...
-
Añadir, Añadir, Añadir ...
Si identifica e implementa estas acciones como scripts de prueba separados y los reutiliza en otros scripts de prueba,
alcanzará un nivel de reutilización más elevado.
Otro objetivo sería estructurar los scripts de prueba de forma que un cambio en el software de destino provoque un
cambio localizado y controlable en los scripts de prueba. Esto hará que sus scripts de prueba sean más flexibles ante
los cambios en el software de destino. Por ejemplo digamos que la porción de conexión del software ha cambiado. Para
todos los casos de prueba que atraviesan la porción de conexión, sólo el script de prueba que pertenece a la conexión
tendrá que cambiar.
Para alcanzar una alta capacidad de mantenimiento de sus scripts de prueba, debe registrarlos de modo que sea menos
vulnerable a los cambios en el destino de la prueba. Por ejemplo, para un script de prueba que rellena los campos de un
recuadro de diálogo, existen opciones sobre cómo proceder de un campo al siguiente:
-
Utilizar la tecla TAB
-
Utilizar el ratón
-
Utilizar las teclas de aceleración del teclado
De estas opciones, algunas son más vulnerables a los cambios de diseño que otras. Si se inserta un nuevo campo en la
pantalla, el enfoque de tecla TAB no será fiable. Si las teclas de aceleración se reasignan, no proporcionarán un buen
registro. Si el método que utiliza el ratón para identificar un campo está sujeto a cambios, este no será un método
fiable. Sin embargo, algunas herramientas de automatización de prueba tienen grabadores de scripts de prueba que se
pueden instruir para identificar el campo con un método más fiable, como el nombre de objeto asignado por la
herramienta de desarrollo (PowerBuilder, SQLWindows o Visual Basic). De este modo, un grabador de script de prueba no
está afectado por los cambios menores de la interfaz de usuario (por ej., cambios en el diseño, cambios en las
etiquetas de campo, cambios de formato, etc.)
Muchos scripts de prueba implican la entrada de varios conjuntos de datos de campo en una pantalla de entrada de datos
para comprobar las funciones de validación de campo, manejo de errores, etc. Los pasos de procedimiento son los mismos;
sólo los datos son diferentes. En lugar de registrar un script de prueba para cada conjunto de datos de entrada, un
único registro debe realizarse y modificarse posteriormente para manejar múltiples conjuntos de datos. Por ejemplo,
todos los conjuntos de datos que producen el mismo error debido a datos no válidos pueden compartir el mismo script de
prueba registrado. El script de prueba se modifica para dirigir los datos como información variable, para leer los
conjuntos de datos desde un archivo u otra fuente externa y para generar un bucle a través de todos los conjuntos de
datos relevantes.
Si los scripts de prueba o el código de prueba se han desarrollado para generar el bucle a través de conjuntos de datos
de entrada y de salida los conjuntos de datos deben estar establecidos. El formato habitual para utilizar estos
conjuntos de datos son los registros de campos separados por comas en un archivo de texto. Este formato es fácil de
leer desde los scripts de prueba y es muy fácil de crear y mantener.
La mayoría de paquetes de base de datos y de hoja de cálculo pueden producir salidas textuales separadas por comas. La
utilización de estos paquetes para organizar o capturar conjuntos de datos tiene dos beneficios importantes. Primero,
proporcionan un entorno más estructurado para entrar y editar los datos que simplemente utilizar un editor de texto o
procesador de texto. Segundo, la mayoría tienen la capacidad de consultar bases de datos existentes y capturar los
datos devueltos, permitiendo una forma sencilla de extraer conjuntos de datos de las fuentes existentes.
El script de prueba registrado es secuencial en esta ejecución. No hay puntos de ramificación. El manejo de errores
robusto en los scripts de prueba requiere una lógica adicional para responder a condiciones de error. La lógica de la
decisión que se puede emplear cuando ocurren los errores incluye:
-
Ramificaciones a diferentes scripts de prueba.
-
Llamada a un script que intenta limpiar la condición de error.
-
Salir del script e iniciar el siguiente.
-
Salir del script y del software, reiniciar y reanudar la prueba en el script de prueba siguiente después del que ha
fallado.
Cada técnica de manejo de errores requiere una lógica de programa añadida al script de prueba. Siempre que sea posible,
esta lógica debe confinarse a los scripts de prueba de alto nivel que controlan las secuencias de los scripts de prueba
de niveles inferiores. Esto permite que los scripts de prueba de nivel inferior se creen completamente desde el
registro.
Cuando se realice una prueba de tensión, suele ser deseable sincronizar los scripts de prueba para que se inicien a
horas predefinidas. Los scripts de prueba se pueden modificar para que se inicien en un momento concreto comparando la
hora de inicio deseada con la hora del sistema. En sistemas en red, cada estación de prueba compartirá, a través de la
red, el mismo reloj. En el ejemplo siguiente (de un script escrito en BASIC), las sentencias se han insertado al inicio
de un script para suspender la ejecución del script hasta que se haya alcanzado la hora necesaria.
InputFile$ = "TIME.DAT"
Open InputFile$ For Input As 1
Input #1, StartTime$
Close #1
Do While TimeValue(StartTime$) > Time
DoEvents
Loop
[Start script]
En este ejemplo, la hora de inicio necesaria se almacena en un archivo. Esto permite que la hora de inicio se cambie
sin cambiar el script de prueba. La hora se lee y se almacena en una variable denominada StartTime$ . El
bucle Do While continua hasta que se alcanza la hora de inicio. La sentencia DoEvents es
importante: permite que las tareas de fondo se ejecuten mientras el script de prueba está suspendido y esperando
empezar. Sin la sentencia DoEvents , el sistema no respondería hasta que se hubiera alcanzado la hora de
inicio.
Cuando los scripts de prueba que se acaban de registrar se ejecutan en el mismo software en que se registraron, no
deben aparecer errores. El entorno y el software son idénticos a cuando se registró. Puede haber instancias en que el
script de prueba no se ejecute satisfactoriamente. La prueba de los scripts de prueba revela estos casos, y permite que
los scripts se corrijan antes de utilizarse en una prueba real. Dos tipos de problemas típicos se discuten a
continuación:
-
La ambigüedad en los métodos que se utilizan para seleccionar elementos en una interfaz de usuario puede hacer que
los scripts de prueba funcionen de forma diferente en la reproducción. Por ejemplo, dos elementos que se reconocen
por su texto (o título) pueden tener un texto idéntico. Habrá ambigüedad cuando se ejecute el script.
-
Se registra la ejecución de la prueba/los datos específicos de la sesión (por ej., un puntero, fecha/hora o algún
otro valor de datos generado por el sistema), pero es diferente en la reproducción.
Las diferencias de tiempo en el registro y la reproducción y puede producir problemas. El registro de los script de
prueba es inherentemente un proceso más lento que ejecutarlo. A veces esta diferencia de tiempo provoca que el script
de prueba se ejecute por delante del software. En estos casos, los estados de espera se pueden insertar para regular el
script de prueba a la velocidad del software.
|