FAQs GXtest Designer

Modelado de Casos de Prueba

¿Cómo hacer que una parte del test case se repita?

Para esto hay que modularizar la sección que se quiere repetir en un TC separado. Luego incluirlo en el TC que se está modelando y con doble clic sobre el TC incluido se puede editar sus propiedades. Entre ellas está la cantidad de veces a repetir ese caso de prueba. Para esto se puede elegir un valor fijo, o tomado de un DataPool. Por ejemplo, si estamos creando "Países" y queremos que el "Crear ciudad" se ejecute la cantidad de veces correspondiente para cada país, podríamos tener una columna en el datapool con los datos de los países a dar de alta con el número de ciudades a ingresarle.

¿Cómo ejecutar comandos en grillas dentro de grillas?

Por información acerca de como ejecutar comandos en grillas que se encuentran dentro de otras grillas mirar el artículo Campos en Grillas dentro de Grillas.

Variables

¿Las variables son case-sensitive?

No, es lo mismo utilizar una variable &NumFactura que &numfactura

¿Existen variables "reservadas"?

Si, la variable &URLHome tiene como valor la URL principal de proyecto por defecto, por lo que, si creamos un comando Go(&URLHome) nos llevará a la url principal. Esta variable es también configurable en GXtest Manager, para ejecutar las mismas pruebas en distintos ambientes.

Resultados

¿Puedo visualizar los resultados exportados a XML en el Designer? ¿Puedo almacenar y navegar en alguna forma los resultados de ejecuciones previas?

GXtest Designer tiene el objetivo de preparar las pruebas a ejecutar, y no de ejecutarlas. O sea, da la posibilidad de ejecutarlas y de visualizar resultados sólo con el propósito de asegurarte que las pruebas que se están armando funcionan correctamente. No es la idea el almacenar esos resultados.

Para esto existe el GXtest Manager, que es el que administra el repositorio de pruebas y permite agrupar los Test Cases en Test Suites y agendarlos para ejecutar. Los resultados de estas ejecuciones quedan almacenados en la base de datos y pueden ser navegados desde este componente.

Tiempo de ejecución de GXtest

¿Por qué la ejecución de GXtest demora más que otras herramientas?

Todas las aplicaciones modernas que utilizan Ajax, procesan acciones por detrás de la página mientras el usuario interactúa con ella. Por ejemplo, el ingreso de un valor en un campo puede disparar un pedido de validación contra el servidor web, y eventualmente se podrá mostrar un mensaje al usuario luego que se complete la validación. Esto hace que el usuario tenga una experiencia mucho más rica en las interfaces web, pero dificulta el uso de herramientas automatizadas para las pruebas funcionales.

Por ejemplo, cuando vamos a registrar un nuevo usuario en un formulario, luego de ingresar nuestra dirección de email el sistema realiza un chequeo de que el email ya no esté registrado. Esa llamada puede demorar desde unos milisegundos a varios segundos, y es ejecutada "por detrás" del navegador. Si queremos agregar una verificación en nuestro caso de prueba para comprobar que aparezca correctamente un mensaje que indique que "el email ya está registrado", el test debe esperar que la llamada se complete. Dado que no hay nada que le indique a la herramienta que debe esperar, la mayoría de las herramientas de automatización comunes fallan, o debemos agregar esperas en forma manual (pausas) por un tiempo fijo, lo cual hace que las pruebas sean menos robustas, y fallen solamente porque el sistema funciona un poco mas lento de lo esperado.

GXtest en cambio, al estar diseñado específicamente para GeneXus, sabe cuando las llamadas ajax se completan y cuando hay pedidos pendientes, lo cual ayuda al tester para que éste no deba ingresar esperas manuales, ya que lo resuelve automáticamente. Esto tiene como contrapartida, que GXtest puede demorar más que otras herramientas (sobre todo en aplicaciones remotas o lentas), debido a que espera a que se completen los pedidos para realizar las validaciones en tiempo y forma, sin obtener falsos negativos por demoras del sistema.