Directriz: Scripts de prueba automatizados de programación
En esta directriz se describen los principios del desarrollo del script de prueba automatizado eficaz.
Relaciones
Elementos relacionados
Descripción principal

Estructura de los scripts de prueba

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.

Técnica de grabación

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.)

Pruebas controladas por datos

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.

Manejo de errores

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.

Sincronización y planificación de script de prueba

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.

Prueba y depuración de los scripts de prueba

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.