Como impactar los casos de prueba cuando cambia la KB GX

From GXtest Wiki
Revision as of 13:13, 22 August 2014 by Mcrespo (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
Spanish.gif
English.gif
Japan.gif

En este ejemplo se verá como se puede Actualizar la KB: Impactar los cambios de la KB en los casos de prueba con un ejemplo concreto.

Contents

Archivos necesarios para seguir el ejemplo

Para realizar completamente el presente ejemplo descargue el siguiente archivo:

UpdateAjaxSample.rar‎: Archivo comprimido .rar que contiene:

  • AjaxSample.gxt: archivo con la versión inicial de la KB de AjaxSample
  • NewAjaxSample.gxt: archivo con la versión modificada (algunos cambios que podrían haber intoducido los desarrolladores) de la KB de AjaxSample
  • AjaxSample.zip: Es un proyecto de GXtest con 3 casos de prueba

Análisis de impacto (actualización de la KB) paso a paso

Paso 1: carga inicial

Primero se debe crear un proyecto nuevo al cual se le debe asociar la KB AjaxSample.gxt. Por más ayuda sobre como realizar esto ver Empezando con GXtest.
Luego importar el proyecto AjaxSample.zip .


Paso 2: modificar el path a la KB

El objetivo de este articulo es justamente ver como impactan los cambios en el desarrollo en los casos de prueba. Para ver esto se debe cambiar la KB con la cual GXtest está trabajando. Con este fin es que suministra el archivo NewAjaxSample.gxt, el cual contiene la misma KB pero con algunos cambios. Para que GXtest consulte la nueva kb se deben realizar los siguientes pasos:

  • Knowleadge Base -> Edit Properties
  • Elegir el nuevo path hacia: NewAjaxSample.gxt

Los cambios realizados en la KB NewAjaxSample.gxt se describen a continuación:

  • Se cambió el nombre de la transacción Client por SuperClient
  • Dentro de la transacción Client, se cambió el botón confirmar por el botón enter
  • Dentro de la transacción Client se cambió el atributo ClientFirstName por ClientName

Nota: Estos cambios producen también cambios en los objetos asociados al pattern Work With.

Paso 3: Update KB Information!

Bien ahora estamos listos para realizar el impacto, para esto debemos ir a Knowleadge Base->Update KB Information

Resultados pre impact

ImpactKB Paso1.png

En esta pantalla se muestra, previo a impactar la nueva KB, por un lado:

  • Los cambios a nivel de la KB
  • Los cambios a nivel de los casos de prueba en GXtest.

Cambios en la KB

Los cambios se muestran como:

  • Objetos nuevos
  • Objetos modificados
  • Objetos eliminados

Cada uno de ellos se puede ver presionando el link "Show details".
Estos cambios se impactarán cuando se presione "Update", pero antes es necesario ver qué issues (si existen) quedarán por resolver en los casos de prueba.

Issues

Generalmente, cuando se renombran objetos o controles, GXtest adapta automáticamente los casos de prueba.
Otras veces, es imposible adaptar los casos de prueba, por ejemplo si se borra un objeto. Al borrar un objeto de la KB, los casos de prueba que utilicen dicho objeto quedarán desabilitados (issue marcado en rojo). Este tipo de issues se pueden ir resolviendo luego.

Es importante recordar que si se está usando GeneXus X o superior entonces GXtest automáticamente detectará los objetos y controles que fueron renombrados, y no es necesario ajustarlo a mano.

GXtest por lo general resuelve automáticamente los conflictos, siempre y cuando esté seguro de que el cambio es el indicado. Por ejemplo, al renombrar un atributo, posee la información (a partir de GeneXus X) para saber si un control cambió de nombre o no.
En dicho caso remplaza sus comandos y actualiza los casos de prueba.
También es probable que aplique heurísticas, para determinar cuando un control debe cambiarse por otro. Ej:

  • El control BUTTON_1 no existe más, pero existe un BUTTON_2 que maneja el mismo evento.

Es ahí cuando aparece el test case en estado "Pending Review" (issue marcado en amarillo). Este es una especie de "advertencia" para que el tester revise si el remplazo es el indicado.

Resolución de Issues

Luego de aplicar los cambios en la KB pueden quedar algunos test cases en tres estados distintos

  • Ready: no tiene ningún issue a verificar
  • Pending Review: se realizaron cambios automáticamente que deberían ser verificados
  • Disabled: el test hace referencia a algún objeto que no existe o algo similar, que hace que no se pueda ejecutar.

Los cambios de la KB pueden hacer que el Test case quede desabilitado hasta que un usuario corrija manualmente las referencias perdidas. Esto puede pasar en caso de que se elimine un objeto usado en una prueba, tal vez por cambios en los requerimientos, etc.

Véase también

Tutorial de GXtest Manager