GXtest Generator - Complejidad de las pruebas

Esta configuración especifica la complejidad que el caso de prueba y los datos generados tendrán. Por ello, esta configuración afectará la cantidad de líneas de datos que el datapool asociado tendrá.

Opciones disponibles

Estos son los niveles de configuración disponibles:

• Mínimo
• Básico
• Básico con reglas
• Todos los valores discretos
• Válido e inválido

A continuación se explican dichas configuraciones.

Mínimo

Genera solamente un valor por cada campo editable de la entidad analizada (transacción). Los datos son generados en forma aleatoria, o pueden ser tomados desde un un diccionario de datos, o una base de datos de la aplicación.

Básico

Genera un conjunto de valores por cada campo editable, basado en los valores borde de cada uno de los campos. Por ejemplo, para un campo Numeric(4), podría generar los siguientes valores: 183, 0, 1, 9999 La generación de valores se basa en la técnica de boundary value analysis

Básico con reglas

Igual que el básico, pero además incluye valores borde basados en las reglas GeneXus del objeto analizado. Por ejemplo, si existe una regla error sobre un campo "Edad", tal que la aplicación desplegará un error si se ingresa una edad mayor o igual a 120, entonces GXtest Generator elegirá el 119 como un valor interesante para probar.

Las reglas que son analizadas/soportadas son las que tienen comparaciones con valores fijos:

• error() - cuando el error depende de una comparación con un atributo numérico
• error() - cuando el error se dispara si el largo de un atributo de tipo string es más largo o más corto que cierto valor numérico

Todos los valores discretos

Esta configuración se aplica en particular a campos en los que se puede elegir un valor de un conjunto discreto de opciones. El ejemplo más claro de esto son los Combo, los cuales tienen una cantidad acotada de valores que pueden utilizarse. La configuración "All discrete values" agregará a la prueba todos los valores disponibles en ese Combo (en lugar de seleccionar sólo algunos).

Válido e inválido

Además de las pruebas del flujo normal de la aplicación, se generará un caso de prueba adicional con el fin de probar que los ingresos inválidos de datos sean correctamente manejados por la aplicación.

El caso de prueba que validará los mensajes de error, tendrá la siguiente estructura:

• Ingresar valores válidos en todos los campos
• Por cada campo con una regla error asociada (si tiene más de una, se generará una validación por cada regla):
  • Ingresar un valor inválido
  • Validar el mensaje de error
  • Ingresar un valor válido

Por ejemplo, si tenemos una regla error sobre el campo Edad:

error("La edad debe ser menor a 120") if Edad>=120;

El caso de prueba generado ingresará el valor 120 (o uno mayor) en el formulario, y validará que efectivamente aparece el mensaje de error en la pantalla.

GXtest Generator generará entonces un ingreso de datos (FillInput) y una validación (VerifyControlValidation). Para el ejemplo de la edad, el caso de prueba tendrá lo siguiente:

FillInput(Edad, 120)

VerifyControlValidation(Edad, "La edad debe ser menor a 120", Error)

FillInput(Edad, 20)

Los primeros dos comandos, servirán para validar el mensaje de error sobre el campo. El último FillInput, se utiliza para dejar un valor válido en el campo, para el caso que querramos seguir validando otros mensajes de error mas adelante en la pantalla, de modo que este error no nos tranque el resto de las validaciones.

Para las reglas que tengan una lógica más compleja para decidir si un error se debe mostrar (por ejemplo que invoquen a un Procedure), GXtest Generator generará igualmente los tres comandos, pero agregará valores fijos a los FillInputs. Esto se debe a que no podrá conocer cuál valor dispararía el error (porque por ejemplo depende de datos de la ejecución y la lógica del Procedure invocado), pero que seguramente el tester conoce y podrá completar en el datapool asociado luego de la generación.

Los datos que GXtest Generator no pudo calcular, podrán ser identificados fácilmente en el datapool, ya que tendrán los valores "Fill with an invalid value here" y "Fill with a valid value here", para indicar al tester que debe ingresar esos datos y así completar el caso de prueba.

Consideraciones

Para las configuraciones en las que se generan más de una fila de datos (todas menos Mínimo), se utiliza una estrategia similar a pairwise testing para optimizar la cantidad de ejecuciones que se realizará con los datos. Si combináramos cada valor de cada columna con las demás y realizáramos todas las combinaciones posibles, tendríamos un datapool con el producto cartesiano de todos los valores de todas las columnas, y el caso de prueba acabaría demorando mucho en completar su ejecución (ya que tendría demasiados valores para probar).

Pairwise testing es una técnica suficientemente buena para asegurarnos cierta combinación de valores que resulten interesantes en las pruebas, sin que la cantidad de ejecuciones necesarias sea demasiada grande.