Difference between revisions of "Cómo probar GXtest"
(→Comienzo con Gxtest, selección del sistema bajo pruebas) |
|||
| Line 1: | Line 1: | ||
[[Category:GXtest 1.1 Beta]] | [[Category:GXtest 1.1 Beta]] | ||
| − | + | Hay tres caminos a seguir para comenzar con GXtest: | |
| − | * | + | * Comienzo rápido (QuickStart): basados en la aplicación AjaxSample grabe y ejecute su primer caso de prueba automatizado. |
| − | * | + | * Tutorial de GXtest: siga un tutorial paso a paso para conocer las principales funcionalidades de GXtest. |
| + | * Use GXtest con su propio sistema: si ya conoce GXtest y sus funcionalidades, entonces animese y pruebe GXtest con su propio sistema. | ||
Revision as of 17:19, 22 February 2010
Hay tres caminos a seguir para comenzar con GXtest:
- Comienzo rápido (QuickStart): basados en la aplicación AjaxSample grabe y ejecute su primer caso de prueba automatizado.
- Tutorial de GXtest: siga un tutorial paso a paso para conocer las principales funcionalidades de GXtest.
- Use GXtest con su propio sistema: si ya conoce GXtest y sus funcionalidades, entonces animese y pruebe GXtest con su propio sistema.
La prueba en 2 minutos consiste en ejecutar un exe extra que viene con GXtest que lo que hace es cargar una KB de ejemplo (ajaxSample) con algunos Test Cases hechos por nosotros, y de esa forma rápidamente se pueden ejecutar pruebas, o comenzar a grabar otras.
La segunda opción lleva más tiempo pero se le puede sacar mejor provecho, que consiste en probar sobre un sistema propio, siguiendo las guías que aquí les presentamos.
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, que esté estable, y no sea algo que recién estoy comenzando a desarrollar.
Ver en el manual:
Selección y diseño de los Casos de prueba
Comenzar a grabar casos de prueba. A lo loco? No… primero diseñar los casos de prueba que quiero probar. O si ya tengo casos de prueba diseñados, pensar de 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 que GXtest la resuelva. Ejemplo: si uso User Controls, si uso Patterns, si uso algún menú javascript desarrollado por mi, si uso seguridad, etc.
Ver en el manual:
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:
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:
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:
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.
Si ya conoces Gxtest
Entonces tenés que probar directamente esto que es lo nuevo:
