Descargar para leer sin conexión
Subido porGeneXus
¡Esta prueba tiene que automatizarse!
Este documento discute la necesidad de automatizar las pruebas funcionales de un sistema de personal que tiene 2500 usuarios. Explica que el proyecto ha evolucionado tecnológicamente con un nuevo portal de autogestión, reingeniería de funcionalidades complejas e implementación de procesos con GXflow. También detalla el proceso de construcción con roles especializados en testing y herramientas, así como las pruebas de rendimiento automatizadas y su análisis. Finalmente, explica los beneficios de automatizar las pruebas funcionales como cobert
¡Esta prueba tiene que automatizarse!
- 1. ¡ESTA PRUEBA TIENEQUE AUTOMATIZARSE! Lorena Campistrous Andréi Guchin lcampistro@ancap.com.uy andrei.guchin@abstracta.com.uy Mauro Alvez malvez@genexusconsulting.com
- 2. Agenda o Contexto del Proyecto o Pruebas de performance o Automatización de pruebas funcionales
- 3. Proyecto: Sistema dePersonal 2500 usuarios Visibilidad a toda la organización Abarca: Control de Asistencia, ingreso de justificaciones de horas trabajadas o no y proceso para su autorización, interfaz con el sistema de sueldos, consultas
- 4. Evolución Tecnológica Cambio en la arquitectura: Portal de Autogestión Reingeniería funcionalidades mas complejas Implementación de procesos con GXflow Aplicación de K2BTools Nuevo esquema de seguridad
- 5. Proceso de construcción o Incorporación de roles especializados o Coordinación o Equipo de Testing o Expertos en test de Performance o Incorporación de herramientas
- 6. Pruebas de Performance o Diseño o Automatización o Ejecución y análisis
- 7. 200 1200 800 1000 1400 400 600 0 12:00:00 AM 12:30:00 AM 1:00:00 AM 1:30:00 AM 2:00:00 AM 2:30:00 AM 3:00:00 AM 3:30:00 AM 4:00:00 AM 4:30:00 AM 5:00:00 AM 5:30:00 AM 6:00:00 AM 6:30:00 AM 7:00:00 AM 7:30:00 AM 8:00:00 AM 8:30:00 AM 9:00:00 AM 9:30:00 AM 10:00:00 AM 10:30:00 AM 11:00:00 AM 11:30:00 AM 12:00:00 PM 12:30:00 PM 1:00:00 PM 1:30:00 PM 2:00:00 PM 2:30:00 PM 3:00:00 PM 3:30:00 PM 4:00:00 PM 4:30:00 PM 5:00:00 PM 5:30:00 PM 6:00:00 PM 6:30:00 PM Diseño de modelo de carga 7:00:00 PM 7:30:00 PM 8:00:00 PM 8:30:00 PM 9:00:00 PM 9:30:00 PM 10:00:00 PM 10:30:00 PM 11:00:00 PM 11:30:00 PM y mayor...
- 8. Diseño de modelode carga 1500 1000 500 0 Estadísticas de acceso a objetos
- 9. Diseño de modelode carga 1500 #UV #Iter CP01-Remuneración 122 4 1000 CP02-Ficha Detallada 66 4 500 CP03-Anuncio de Licencia 8 7 0 CP04-Anuncio de compensar hrs extras 8 7 CP05-Anuncio de salida en comisión 8 7 CP06-Anuncio de Hrs particulares 8 7 CP07-Ver Saldo de Licencia 6 2 CP08-Interfase de sueldos 3 1 CP09-Trabajar con subordinados 10 1 CP10-Consultar Anuncios 28 4 CP12-Consultar Marcas Normales 20 2 CP13-Trabajar con Anuncios 20 3 CP14-Marcas Subordinados 10 1 Escenario de carga
- 10.
- 11. Ejecuciones Herramientas de monitorización: o Performance Monitor o Iseries Navigator o Tivoli Performance Viewer o Jconsole o IBM Heap Analyzer o JProfiler
- 12.
- 13.
- 14.
- 15. ¿Por qué? o Funcionalidad crítica o Cobertura de las pruebas o Tiempo insumido en testing o Tarea repetitiva o Costo de la automatización
- 16. Proceso Antes Automatización Después
- 17. Proceso Antes Automatización Después
- 18. Proceso Antes Automatización Ahora
- 19. Adaptación de loscasos de prueba
- 20. Proceso Antes Automatización Después
- 21. Proceso Antes Automatización Después
- 22. ¡ESTA PRUEBA TIENEQUE AUTOMATIZARSE! Lorena Campistrous Andréi Guchin lcampistro@ancap.com.uy andrei.guchin@abstracta.com.uy Mauro Alvez malvez@genexusconsulting.com
- 23. Conferencias relacionadas o Hoy o Sacándole el jugo al testing- Sala 2C, 16:15 hs. o Mitos sobre el testing y el testing automatizado- Sala 2C, 17:15 hs. o Testing en Smart Devices: Getting Started- Sala 2C, 17:45 hs. o Martes o Laboratorio Gxtest (parte 1)- Sala 4P, 10:30 hs. o Laboratorio Gxtest (parte 2)- Sala 4P, 11:00 hs. o Miércoles o Testing: 20 años, 5 niveles, 1 desafío- Sala 4R, 11:45hs.
- 24.
Notas del editor
- #3 En esta charla le vamos a estar contando de nuestra experiencia en el testing del Sistema de Personal de ANCAP, tanto de pruebas de performance como la automatización de pruebas funcionales y como esto redundó y redunda en una mejor calidad del producto. La idea es mostrarle lo que a nosotros nos funcionó y quizá puedan llevarse algo que puedan aplicar en sus proyectos.
- #4 Es un sistema que cuenta con más de 2500 usuarios, todos los funcionarios de ANCAP como también los tercerizados pueden consultar sus horas trabajadas por ejemplo.Entonces estamos hablando de un sistema con una visibilidad a toda la organización. Además de los funcionarios del área de RRHH que administran SisPer, usuarios comunes, jefes y gerentes acceden al sistema diariamente con roles específicos para ellos.¿Qué abarca Sisper? El control de Asistencia, ingreso de justificaciones de horas trabajadas o no, inasistencias, licencias y el proceso de autorización para estas justificaciones en el que participan más de 400 autorizantes. Interfaz con el sistema de Sueldos donde se genera la información necesaria que el sistema de sueldos utiliza como insumo para la liquidación de los sueldos. También consultas varias sobre toda la información del funcionario. En SisPer el funcionario puede visualizar e imprimir su recibo de sueldo. Y más…
- #5 Este proyecto implicó una evolución tecnológica del sistema .Hubo un cambio en la arquitectura pasando de una aplicación Cliente Servidor a un portal de autogestión Web. Para soportar esto y aprovechar el potencial que nos brinda GeneXus es sus últimas versiones se migraron las KB’s de versiones anteriores a la Evolution 1. También se hizo una reingeniería de las funcionalidades más complejas que son las que implican el procesamiento de las horas trabajadas para generar los datos para la interfaz de sueldos que les comentaba como también para visualizarlas en detalle .Se implementaron procesos con GXflow, específicamente en lo que tiene que ver con el proceso de autorización de las justificaciones que hablé hace un rato.Se aplicaron Patterns utilizando las K2BTools.Y se definió un nuevo esquema de seguridad con usuarios, roles y permisos para ejecutar las distintas acciones.
- #6 Este proyecto también introdujo cambios en el proceso de construcción del sistema.Se incorporaron roles especializados en lo relacionado con la coordinación para la gestión del proyecto.Se definió un equipo de testing separado del equipo desarrollo. Antes eran los mismos desarrolladores que testeaban sus desarrollos. Ahora es este equipo es el que lleva acabo las pruebas funcionales. Luego se sumaron expertos en test de performance pertenecientes a la empresa Abstracta para la realización de este tipo de pruebas.Además se incorporaron distintas herramientas para mejorar el seguimiento de las versiones, el desarrollo y el testing. Entre ellas el Mantis que es una de las aplicaciones OpenSource más difundidas para la gestión de incidentes.GXtest. Herramienta para la automatización de pruebas de aplicaciones web desarrolladas con GeneXus. Y también para generar los scripts base a utilizar en las pruebas de performance.SoapUI para el testing de web services.Gxserver. Herramienta que permite coordinar el trabajo de equipos para el desarrollo distribuido de aplicaciones GeneXus.
- #7 Mi nombre es AndréiGuchin, trabajo en Abstracta como tester y me especializo en pruebas de performance. Como comentaba Mauro, les voy a hablar de las pruebas de performance realizadas en el Sisper.Cuando hablamos de pruebas de performance, nos estamos refiriendo al tipo de pruebas que tienen por objetivo determinar el rendimiento o la capacidad de respuesta de un sistema sometido a una determinada carga. En otras palabras, lo que se busca es ver si el sistema soporta la carga actual o la proyectada. En particular, los objetivos de las pruebas realizadas en el Sisper fueronmitigar riesgos asociados a la salida en producción así como aplicar optimizaciones que permitan obtener el mejor desempeño posible del sistema. Para lograr esto, se genera carga en el sistema con herramientas especializadas a la vez que se monitorizan los recursos. Si les interesa saber algo más sobre pruebas de performance los invito a quedarse a la charla siguiente en este salón que estará Federico hablando un poco más acerca de ellas.Un proyecto de performance, se divide básicamente en tres grandes etapas: diseño, automatización y ejecución y análisis de resultados. Asi que a continuación les contaré como nos fue en este proyecto en cada una de estas etapas.
- #12 Luego de automatizados los casos, se comenzó con la ejecución de las pruebas. Se considera una buena práctica comenzar con menor carga que la determinada en el escenario (por ejemplo, un 25%) e ir aumentándola gradualmente a medida que las ejecuciones van dando resultados positivos. Esto permite encontrar primero los problemas más grandes, que generalmente son los más importantes a corregir y los que afectan más la performance.Para la monitorización de recursos se utilizaron varias herramientas, como por ejemplo:-iSeriesNavigator de IBM para la monitorización del sistema operativo y desempeño de la base de datos.-JConsole: para la monitorización de indicadores de la Java Virtual Machine y otros indicadores expuestos especificamente por Genexus.(estás no las voy a nombrar pero taría bueno saber que hacen por si alguno pregunta)Performance monitor de Microsoft: para monitorizar las generadoras de carga.Tivoli Performance Viewer de IBM para analizar los tiempos de los servlets y el comportamiento del heap de la JVMIBM HeapAnalyzer para el análisis de la memoria de la JVM.JProfiler de e-techologies: para el estudio detallado del consumo de tiempo de distintas funcionalidades.
- #16 ¿Por qué automatizar las pruebas del ingreso de anuncio?Funcionalidad crítica. Esta funcionalidad tiene que andar si o si en cada entrega porque:Está disponible para todos los usuarios.Junto con las marcas de reloj son el insumo principal para la liquidación de haberes.Cobertura de las pruebas.No teníamos casos de prueba especificados formalmente, contábamos con una lista de cosas a probar y de escasa cobertura. Debíamos mejoramos la cobertura de las pruebas.Tiempo insumido en testing.El sistema estaba en producción y surgían varios cambios urgentes que debían ser testeados a la vez. Debíamos reducir el tiempo de testing.Tarea repetitiva.Era una tarea rutinaria y que no presentaba desafíos. Costo de la automatización.A priori no parecía ser una funcionalidad difícil de automatizar. Además ya contábamos con un caso de prueba automatizado resultado de las pruebas de Performance y podíamos re-utilizarlo.
- #18 Para comenzar…Una vez que definimos la funcionalidad a automatizar comenzamos a preparar los casos de prueba que iban a ser nuestro insumo principal para comenzar a automatizar. Como se comentó no teníamos casos de prueba formalmente documentados. Solo una lista de cosas que se debían probar y que era de escasa cobertura. Utilizando distintas técnicas se generaron 24 pruebas conceptuales y luego 80 casos de prueba con datos. Mientras tanto…Paralelamente a la elaboración de los casos de prueba se solicitó al equipo de desarrollo la creación de un ambiente específico para automatización. Contábamos con dos ambientes de prueba y se creó un tercero. Para esto se necesitó la copia de la aplicación web y de la base de datos. También solicitamos el gxt de la KB que va a ser el insumo de GXtest. Ambiente específico para automatizaciónCopia de la aplicación webCopia de base de datos
- #19 Cuando tuvimos el ambiente preparado y los casos de prueba terminados comenzó la automatización. En esta etapa contamos con el apoyo de la gente de Abstracta. En el momento de la creación de los casos de prueba tuvimos dos etapas:1.- Revisar los casos de prueba creados en la etapa de Performance, ver cuales se podían adaptar….
- #20 ….Por ejemplo el ingreso de anuncios estaba automatizado. Se le hicieron modificaciones para que se adaptara a la realidad y se le agregaron validaciones. Para las validaciones se pidió a desarrollo la creación de algunos ws para consultar los datos que se grabaron en la BD. El 90% de los casos de pruebas con datos entraban en este flujo.2.-Para el otro 10% de casos de prueba se grabaron otros flujos para no complejizar este, ya que la idea es dejar los flujos, siempre que se pueda, que sean simples.
- #21 Una vez que tuvimos los casos de prueba grabados empezamos a probar los datos que se habían seleccionado y a depurarlos. Llenamos el datapool y ejecutamos las pruebas.Algunas cosas que tuvimos en cuenta para la automatización y que necesitamos tener resueltas al momento de ejecutar las pruebas:Preparar la base de datos:parametrizaciones necesarias para el éxito de la prueba, información que el sistema esperaba encontrar. Estas parametrizaciones se realizaron en ese momento y ya quedaron para el resto de las veces en que se ejecutó la prueba. Restaurar la base de datos Para inicializar la base de datos lo que se eligió hacer es en esta primera instancia, para no pedir que se nos restaure la base cada vez que se realicen las pruebas de regresión es correr un script que borra todos los registros generados en la ejecución anterior ya que el sistema no permite que se den de alta dos anuncios con los mismos datos. Para el caso particular de la funcionalidad que automatizamos necesitábamos que la funcionalidad tomara siempre una fecha fija y no la fecha del servidor, esta tarea se le solicitó al equipo de desarrollo.
- #22 Una vez que tuvimos todos los datos seleccionados depurados comenzamos a revisar los incidentes reportados con referencia al ingreso de anuncio y fuimos agregando esos casos, que en su mayoría eran combinación de datos que entraban en nuestro caso de prueba automatizado principal. Y ahora…En que estamosAhora estamos manteniendo los casos de prueba creados. Para esto cada vez que surge un incidente que involucre el ingreso de anuncios o hay un cambio en la funcionalidad se agrega el caso a las pruebas que tenemos. Otra de las cosas que se está haciendo es instalar GXtest en un servidor, el manager y la base de datos. Hoy están en la pc que se utilizó en el momento de probar la herramienta. PendienteAutomatización de ingreso de anuncios médicos y en grupo. Validaciones: agregar validaciones a los casos de prueba existentes. Hoy se controla únicamente el estado del anuncio y si generó instancia de wf. Ahora, cada vez que se prueba un cambio en la funcionalidad de ingreso de anuncios, o la corrección de un incidente se ejecutan las pruebas automatizadas para asegurarnos de que todo funciona correctamente.