View source for Cómo probar GXtest

[[Category: Testing]]
[[Category: Guías de GXtest]]

A continuación se comentan algunos puntos importantes a tener en cuenta a la hora de evaluar GXtest

== Comienzo con GXtest, selección del sistema bajo pruebas ==
Seleccionar el proyecto de desarrollo al que se desea automatizar pruebas. Lo mejor sería ya pensar en qué aplicación de las que estoy desarrollando voy a usarlo primero, en cuál me va a dar más beneficio. En cuál quiero mejorar la calidad, ejecutar siempre pruebas en forma automática cada vez que le hago mantenimiento a la aplicación. En lo posible una aplicación que si bien la estoy desarrollando esté estable, y no sea algo que recién estoy comenzando a desarrollar.

Ver en el manual:
* [[Manual_de_Usuario_de_GXtest_Designer#Proyectos |Crear un proyecto]]. 
* [[Manual_de_Usuario_de_GXtest_Designer#KB_de_Genexus_en_GXtest | Importar la KB de alguna aplicación GeneXus]]

== Selección y diseño de los Casos de prueba ==
Comenzar a grabar casos de prueba. Primero hay que diseñar los casos de prueba que quiero probar. O si ya tengo casos de prueba diseñados, pensar cómo adaptarlos a GXtest. GXtest me permite tener Test cases genéricos, que se alimentan de datos de entrada y salidas esperadas, entonces tengo que diseñar por un lado los flujos a recorrer sobre la aplicación, y por otro lado los datos que voy a usar. Como lo que quiero es probar GXtest, y no mi aplicación (por ahora), tal vez lo mejor sea evaluar si puedo automatizar las cosas que más me complican, si se ajusta a mi aplicación, si hay alguna complicación técnica que no esté seguro de que GXtest la resuelva. Ejemplo: si uso User Controls, si uso Patterns, si uso algún menú javascript desarrollado por mí, si uso seguridad, etc.

Ver en el manual:
* [[Manual_de_Usuario_de_GXtest_Designer#Casos_de_Prueba | Modelo de Casos de Prueba]]
* [[Manual_de_Usuario_de_GXtest_Recorder | Grabar un caso de prueba con el Recorder]]

== Automatización y parametrización ==
Luego que me definí un conjunto pequeño de casos de prueba a probar, grabarlos. Puedo hacerlo directo desde el Designer para mayor facilidad.
Puedo probar las opciones de modificar el modelo, hacer que tome datos variados en cada campo que el usuario ingresa datos, etc.
Puedo probar de hacer invocaciones a procedimientos desarrollados en Genexus con el fin de validar datos a nivel de la base de datos.
Luego tengo que ejecutar desde el designer estos casos de prueba para ver cómo se presentan los resultados, ver que el test case haga lo que yo quería que hiciera.

Ver en el manual:
* [[Manual_de_Usuario_de_GXtest_Designer#Comandos | Comandos]]
* [[Manual_de_Usuario_de_GXtest_Designer#Data_Pools | Datapools]]
 
== Manager: primeras configuraciones ==
Luego ya estamos prontos para agendar las pruebas. Para esto tenemos que preparar todo en el Manager. Luego que definimos las suites (conjuntos de casos de prueba) podemos agendarlas en Tasks (en cierto horario todas las noches por ejemplo). Luego nos llegará el reporte por email.
Luego de varias ejecuciones podremos ver algunas gráficas para visualizar los datos de nuestras ejecuciones.

Ver en el manual:
* [[Manual_de_Usuario_de_GXtest_Manager#Configuraciones | Primeras configuraciones en el Manager]]
* [[Manual_de_Usuario_de_GXtest_Manager#Suites_y_Test_Cases | Suites]]
* [[Manual_de_Usuario_de_GXtest_Manager#Task | Tasks]]
 
== Mantenimiento de los casos de prueba ==
Algo muy importante a evaluar es el tema del mantenimiento de los casos de prueba. La aplicación va a seguir cambiando, entonces los casos de prueba automatizados se van a ver afectados, y hay que impactar los cambios de la KB en los test cases de GXtest. Para esto hagamos cambios intencionalmente en la KB, a modo de ver que GXtest los detecte. Los más importantes son cambios sobre elementos que son referenciados en los test cases que automatizamos. Luego de hacer cambios en GXtest Designer impactemos los cambios, y volvamos a ejecutar las pruebas para ver que todo funcione correctamente.

Ver en el manual:
* [[Manual_de_Usuario_de_GXtest_Designer#Actualizar_la_KB:_Impactar_los_cambios_de_la_KB_en_los_casos_de_prueba | Impactar los cambios de la KB]]
 
== Migración de Genexus 9 a Genexus X o Evolution 1 ==
Si usted está evaluando la migración de una versión anterior (web) de Genexus a la última, GXtest lo puede ayudar en ciertas cosas. Si automatiza pruebas en su aplicación en GeneXus 9, luego cuando se migre, podrá ejecutar esas pruebas en su aplicación en GeneXus X o Evolution 1 sin mayores dificultades. Si está pensando en hacer esto podría intentar hacer alguna prueba para ver si GXtest es capaz de ejecutar sin problemas los casos de prueba que automatizó en la aplicación en GX9, sobre la misma aplicación (la misma versión) en GeneXus Ev1.
 
== Migración de ambiente Java a ambiente C# ==
Lo mismo que lo anterior, pero para migración entre distintos ambientes o configuraciones. GXtest está pensado para que los casos de prueba ejecuten igual (sin necesidad de cambios ni ajustes) cuando usted se migra de una versión de GeneXus a otra, o de un ambiente a otro.

__NOTOC__