Como impactar los casos de prueba cuando cambia la KB GX
 |
 |
 |
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
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.
