Difference between revisions of "Como impactar los casos de prueba cuando cambia la KB GX"

From GXtest Wiki
Jump to: navigation, search
(→‎Archivos necesarios para seguir el ejemplo)
(→‎Análisis de impacto (actualización de la KB) paso a paso)
Line 17: Line 17:
 
=== Paso 1: carga inicial===
 
=== Paso 1: carga inicial===
  
−
Primero se debe crear un proyecto nuevo al cual se le debe asociar la KB AjaxSampleCompleta.xpz. Por más ayuda sobre como realizar esto ver [[Empezando con GXtest]]. <br>
+
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]]. <br>
−
Luego importar los casos de prueba de facturas y clientes. Por más detalle ver [[Exportar e Importar un TestCase]].<br>
+
Luego importar el proyecto AjaxSample.zip .<br>
  
  
 
=== Paso 2: modificar la KB ===
 
=== Paso 2: modificar 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 AjaxSampleCompleta_modificada.xpz, el cual contiene la misma KB pero con algunos cambios. Para que GXtest consulte la nueva kb se deben realizar los siguientes pasos:<br>
+
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:<br>
 
* Knowleadge Base -> KB Properties
 
* Knowleadge Base -> KB Properties
−
* Elegir el nuevo path hacia: AjaxSampleCompleta_modificada.xpz
+
* Elegir el nuevo path hacia: NewAjaxSample.gxt
  
−
Los cambios realizados en la KB AjaxSampleCompleta_modificada.xpz se describen a continuación:
+
Los cambios realizados en la KB NewAjaxSample.gxt se describen a continuación:
−
* Un Objeto nuevo: ObjNuevo
+
* Se cambió el nombre de la transacción Client por SuperClient
−
* Un objeto renombrado que se usaba en un caso de prueba (Home->SuperHome). Al usarse en un caso de prueba se genera un conflicto a resolver.
+
* Dentro de la transacción Client, se cambió el botón confirmar por el botón enter
−
* Un objeto renombrado que no se usaba en ningún caso de prueba (Product->SuperProduct). Al no utilizarse no se genera ningún conflicto.
+
* Dentro de la transacción Client se cambió el atributo ClientFirstName por ClientName
−
* Un control nuevo en un objeto que no se usaba en un caso de prueba (City, TextBox:Hola)
+
 
−
* Dentro del objeto Invoice usado en un caso de prueba se realizan los siguientes cambios:
+
Nota: Estos cambios producen también cambios en los objetos asociados al pattern Work With.
−
** Un control nuevo: TextBox:Holassss
+
−
** Un control en uso que se "renombro" pero que sigue con el mismo caption asociado (btn_enter->Superbtn_enter)
+
−
** Un control en uso que se "renombro" pero que sigue siendo del mismo tipo (Grid1->SuperGrid1)
+
−
** Un boton en uso que se "renombro" y se cambio el caption pero que sigue apuntando al mismo evento (Se borró el botón Cancel, se agregó el botón Button1 que apunto a el evento Cancel)   
+
−
** Un control en uso que simplemente se quito (InvoiceLineQty)
+
  
 
=== Paso 3: Update KB Information! ===
 
=== Paso 3: Update KB Information! ===
 
Bien ahora estamos listos para realizar el impacto, para esto debemos ir a Knowleadge Base->Update KB Information
 
Bien ahora estamos listos para realizar el impacto, para esto debemos ir a Knowleadge Base->Update KB Information
  
−
==== Lista de objetos a eliminar ====
+
==== Resultados pre impact ====
−
[[Image:ImpactKB_Paso2.jpg]]
+
[[Image:ImpactKB Paso1.png]]
−
 
+
−
En esta pantalla se muestra el objeto Product que se va a eliminar porque no se encuentra en la KB actual (el mismo fue renombrado por SuperProduct). Este objeto se puede eliminar sin problemas porque no está siendo utilizado en ningún caso de prueba. Si la KB sobre la cual estamos trabajando es de GeneXus X, entonces automáticamente GXtest se da cuenta cuales objetos fueron renombrados.
+
−
Para continuar presionar Next.
+
−
 
+
−
==== Impacto a nivel de los objetos ====
+
−
[[Image:ImpactKB_Paso3.jpg]]
+
−
 
+
−
En esta pantalla se muestran los conflictos a nivel macro, ya que solo se pueden ver aquellos conflictos en los objetos y no en el contenido de los mismos. Las secciones que se pueden ver son las siguientes:
+
−
* ''Objetos con conflictos'': contiene la lista de objetos que son utilizados en algún caso de prueba pero no se encuentran en la nueva KB. En este caso se muestra el objeto Home, ya que el mismo fue renombrado y se estaba utilizando en los casos de prueba.
+
−
* ''Objetos sugeridos'': cuando se selecciona una objeto en conflicto se sugiere en caso de ser posible otros objetos para sustituir el mismo.
+
−
* ''Conflictos resueltos'': cuando se indica que un objeto en conflicto se corresponde con un nuevo objeto, el objeto en conflicto se va de la lista de Objetos con conflictos y pasa a la lista Conflictos resueltos, a su vez el objeto disponible sale de la lista de objetos disponibles.
+
−
* ''Objetos disponibles'': muestra la lista actual de objetos disponibles (objetos nuevos que no se ha indicado que se correspondan con algún objeto en conflicto). En este caso inicialmente muestra tres objetos: ObjNuevo, SuperHome y SuperProduct
+
−
 
+
−
Lo que se debe hacer en esta pantalla es indicar que el objeto Home ahora se llama SuperHome. Para esto se debe seleccionar (con un clic) el objeto Home y luego seleccionar el objeto SuperHome y presionar el botón Resolved.
+
−
 
+
−
 
+
−
Para indicar que un objeto en conflicto se corresponde con un objeto disponible, marcar el objeto en conflicto y luego marcar el objeto disponible o sugerido. Luego presionar el botón Resolved.
+
−
 
+
−
{| border="1" cellpadding="5" cellspacing="0" align="center"
+
−
|-
+
−
! style="background:#efefef;" | Es importante tener en cuenta si se está utilizando GeneXus X o superior automáticamente se detectan cuales objetos fueron renombrados y no es necesario que el usuario lo indique.
+
−
|}
+
−
 
+
−
 
+
−
Luego presionar  Next.
+
−
 
+
−
==== Impacto a nivel de los Controles ====
+
−
[[Image:ImpactKB_Paso4.jpg]]
+
  
−
En esta pantalla se van a poder recorrer los distintos objetos que han sido afectados con los cambios. Si se observa en la parte superior se puede navegar por los mismos.
+
En esta pantalla se muestra, previo a impactar la nueva KB, por un lado:<BR>
 +
* Los cambios a nivel de la KB
 +
* Los cambios a nivel de los casos de prueba en GXtest.
  
−
Para cada objeto se tiene un esquema similar al de la pantalla anterior en donde se puede indicar que controles han sido renombrados, o sustituidos por otros.
+
==== Cambios en la KB ====
 +
Los cambios se muestran como: <BR>
 +
* Objetos nuevos
 +
* Objetos modificados
 +
* Objetos eliminados
  
−
En este caso en particular el único objeto con conflictos es el objeto Invoice. En el mismo podemos ver que tenemos los siguientes controles en conflicto:
+
Cada uno de ellos se puede ver presionando el link "Show details". <br>
−
* InvoiceLineQty
+
Estos cambios se impactarán, pero antes es necesario ver qué conflictos (si existen) quedarán por resolver en los casos de prueba.
−
* btn_cancel
+
−
* Grid1
+
−
* btn_enter
+
  
−
Al hacer clic arriba de btn_cancel, Grid1 y btn_enter se sugiere adecuadamente cuales son los controles por los cuales se debería sustituir. Esas sugerencias son en base a heurísticas.
+
==== Conflictos ====
−
Presionar Resolve para cada los controles btn_cancel, Grid1, btn_enter y dejar el control InvoiceLineQty sin resolver, ya que simplemente se quito de la aplicación. Luego presionar Next, se preguntará si se desea dejar conflictos sin resolver, presionar Yes.
+
Generalmente, cuando se renombran objetos o controles, GXtest adapta automáticamente los casos de prueba.<BR>
 +
Otras veces, es imposible adaptar los casos de prueba, por ejemplo si se borra un objeto. <BR>
 +
Al borrar un objeto de la KB, los casos de prueba que utilicen dicho objeto quedarán desabilitados (conflicto rojo).
 +
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.<BR>
 +
En dicho caso remplaza sus comandos y actualiza los casos de prueba.<BR>
 +
También es probable que aplique heurísticas, para determinar cuando un control debe cambiarse por otro. Ej:<BR>
 +
* El control BUTTON_1 no existe más, pero existe un BUTTON_2 que maneja el mismo evento.
  
−
==== Reporte ====
+
Es ahí cuando aparece un conflicto pasivo (conflicto amarillo). Este es una especie de "advertencia" para que el tester revise si el remplazo es el indicado. <BR>
−
[[Image:ImpactKB_Paso5.jpg]]
+
  
−
Por último se muestra un reporte donde se visualiza el resultado de la actualización realizada. Para observar dichos cambios abrir los casos de prueba y fijarse como los comandos ahora hacen referencias a los nuevos controles impactados, por ejemplo abrir el caso de prueba de Clientes y hacer doble clic en la pagina de Home para visualizar como ahora el objeto Genexus referenciado es SuperHome y no Home como lo era previamente.
+
Para saber más sobre la resolución de conflictos puede ver [Resolución de conflictos | Resolución de conflictos]
  
 
== Véase también ==
 
== Véase también ==
 
[[Tutorial de GXtest Manager]]
 
[[Tutorial de GXtest Manager]]

Revision as of 15:55, 27 January 2011

Categoría: Guías de GXtest

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 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 -> KB 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, pero antes es necesario ver qué conflictos (si existen) quedarán por resolver en los casos de prueba.

Conflictos

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 (conflicto rojo). 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 un conflicto pasivo (conflicto amarillo). Este es una especie de "advertencia" para que el tester revise si el remplazo es el indicado.

Para saber más sobre la resolución de conflictos puede ver [Resolución de conflictos | Resolución de conflictos]

Véase también

Tutorial de GXtest Manager

Retrieved from "http://gxtest.abstracta.com.uy/wiki/index.php?title=Como_impactar_los_casos_de_prueba_cuando_cambia_la_KB_GX&oldid=2127"