136 experiencias de-testing_y_resultados_obtenidos
•Descargar como PPTX, PDF•
0 recomendaciones•165 vistas
Recomendados
Recomendados
Más contenido relacionado
Similar a 136 experiencias de-testing_y_resultados_obtenidos
Similar a 136 experiencias de-testing_y_resultados_obtenidos (20)
Más de GeneXus
Más de GeneXus (20)
136 experiencias de-testing_y_resultados_obtenidos
- 1. Experiencias de testing y resultados obtenidos Carolina Torrado ctorrado@genexusconsulting.com Matías Reina mreina@abstracta.com.uy #GX2457
- 8. ¿Cuándo lo hacemos? Durante el desarrollo: Mejorar el desarrollo Al finalizar el desarrollo: Estudiar el desempeño global
- 9. ¿Qué necesitamos para hacerlo?
- 11. ¿Cómo decidir que parte del sistema?
- 13. Ejemplo
- 14. ¿Cómo decidir que parte del sistema? Lo más utilizado Lo más crítico de funcionalidad Lo más pesado en cuanto a performance Inbox (más usado y más critico) Materiales (más pesado) Obra (más pesado)
- 16. Tiempos Automatizar casos de prueba (50%) Ejecutar Resolver lo encontrado (incertidumbre)
- 21. ¿Qué resultados nos da?
- 22. Componentes
- 25. ¡Mucha Gracias! Carolina Torrado ctorrado@genexusconsulting.com Matías Reina mreina@abstracta.com.uy #GX2457
Notas del editor
- Carolina: En la industria automotriz los crashtest son una práctica habitual que permite a los fabricantes obtener información acerca del auto y sus componentes.En esta charla le queremos mostrar las semejanzas que hay entre este tipo de pruebas en la industria automotriz y las pruebas de performance en el software.Las pruebas de performance consisten en estudiar el desempeño de nuestro sistema en condiciones similares a las que va a tener en producción.Así como en el crashtest hacemos que el auto se choque contra un obstáculo a distintas velocidades y luego analizamos la información que este ensayo nos da, en el software vamos a simular las distinta situaciones a las que se va a someter el sistema en producción, por ejemplo todos los usuarios de la empresa concurrentemente, la caída de uno de los servidores, etc para luego analizar la información que nos da el ensayo y así mejorar nuestro sistema.Este testing nos va a permitir tener una mayor calidad y al igual que los autos ganar en tranquilidad Y tenemos la ventaja que en el software no tenemos que construir el sistema de nuevo luego de cada choque____________________________________________________________________________________Crash test en wikipedia:A crash test is a form of destructive testing usually performed in order to ensure safe design standards in crashworthiness and crash compatibility for various modes of transportation or related systems and components.
- Carolina:Ahh entiendo, entonces durante el desarrollo es importante estudiar como responde el sistema y luego de tenerlo todo construido estudio el desempeño global de todo el sistema.
- Carolina:Ahora que ya se cuando lo tengo que hacer, ¿Qué necesitamos para hacerlo?
- MatíasLo primero y fundamental es contar con un buen equipo.Los sistemas como todos sabemos son cada vez más complejos y nuestra solución no es solamente lo que programamos en GeneXus sino también todos los componentes que involucra nuestra arquitectura: el servidor de base de datos, el servidor web, el storage, la red, la virtualización, el sistema operativo, etc. Etc.Pero además de todos estos técnicos también necesitamos el conocimiento de los usuarios y de la gente que conoce del negocio. Al igual que con el auto no es lo mismo que se destruya el habitáculo del conductor que el baúl, en nuestro sistema no es lo mismo que nos deje de andar el deposito por caja que la consulta de movimientos del año pasado en el home banking (para poner un ejemplo).CarolinaBien, entonces para que el proyecto sea exitoso necesito el compromiso de todos, desde el programadorhasta el usuario final. Ahora, la duda que me surge que con toda esta gente involucrada y con lo grande que pueden llegar a ser los sistemas, para probarlo todo voy a tener que parar las rotativas por un año!!----------------------Compromiso de todas las partes del proyecto: (Involucrar un responsable de cada componente involucrado en el sistema, un experto de cada componente)ArquitecturaDBMS ProgramadoresUsuarios funcionalesTantos responsables como componentes tenga la solución.
- MatíasNo se prueban todos los casos por que son muy poco probables de que ocurran y el trabajo extra de incluirlos es muy grande y los beneficios muy pocos. Como sabemos cuales funcionalidades entonces? Bueno nos basamos en la estadística para saber cuales son las más utilizadas, le preguntamos a los desarrolladores y a la gente de infraestructura cuales son aquellas que utilizan más recursos (red, cpu, memoria, disco, etc) o le preguntamos a los usuarios y a la gente que conoce del negocio cuales son críticas para la operativa de la empresa.
- MatíasPor ejemplo, te cuento de un proyecto concreto, de una migración de Genexus 8 web a GeneXus ev1 del sistema SGT de UTE. Es un sistema bien grande y complejo con más de 3000 objetos. Dado los plazos del proyecto escogimos 3 casos de prueba basados en los criterios que te comenté (uso, consumo de recursos y criticidad para el negocio). Solo con estos 3 casos pudimos encontrar gran cantidad de mejoras y correcciones que afectaban el desempeño y la estabilidad.Lo más importante es que los hallazgos que se hagan para los objetos que se involucran en estos casos de prueba se mejoran también en aquellos objetos que no entraron en la prueba.Es como en el auto, si encontramos que el problema está en un tipo de material, entonces tendremos que revisar todas las partes que contengan ese material.
- Carolina:Ok, entonces por lo que me decís aunque mi aplicación sea muy muy grande yo puedo concentrarme solo en un grupo pequeño de casos de prueba para una Kb grande entre 10 y 15 casos de prueba e igual encontrar la gran mayoría de los problemas de performance, o sea que por más que agregue más casos de prueba voy a estar trabajando más pero no necesariamente encontrando más problemas. Y para escoger los casos de prueba me tengo que concentrar en lo más utilizado en el sistema, lo más crítico de funcionalidad y lo que es más pesado en cuanto a performance. En el caso de ute que mencionabas se escogió la bandeja de entrada del workflow, la consulta de materiales y la consulta de obra.Ok entiendo, ahora por más que sean pocos casos de prueba, de cuánto tiempo estamos hablando cuando nos referimos a una prueba de performance sobre “el auto ya armado”______________________________________________Obras: en el Escenario 1 se accede 2314 veces en media hora mientras que en producción se hace 200 veces (como pico máximo histórico). Materiales: en el Escenario 1 se accede 1348 veces mientras que en producción se hace 110 veces (como pico máximo histórico)Inbox: En el escenario 1 se ejecutó 7062 veces mientras que en producción no se tienen esta información. Opción 1Testeo de de los siguientes objetos: - HInbox (cambiando el centro y filtrando, para luego tomar la primera tarea) - HCnsObras (cambiando el Nro. de obra, filtrando y consultado la obra) - HGeneraMovimientosMateriales (genera actualización en la base y tiene interfases con SAP) Opción 2Testeo de de los siguientes objetos: - Todo los testeados en la opción 1 + HConsultaMateriales (cambiando Centro y Servicio Ejecutor)En UTEInbox (más usado y más critico)Materiales (más pesado)Obra (más pesado)
- MatíasMirá, te cuento, la mitad del tiempo de las pruebas de performance se va en programar los scripts para las pruebas. Es por esto que la cantidad de casos de prueba a incluir determina directamente el tiempo de las pruebas de performance.Por otro lado siempre tenemos un tiempo mínimo de ejecución que en general va entre 5 y 15 días. Por último, la cantidad de incidentes que encontremos y el tiempo de análisis y corrección de los mismos, es un factor que no lo conocemos a priori y que dependerá de la madurez del sistema, de la tecnología y del equipo que integra las pruebas
- CarolinaAhh ok, entonces básicamente depende de la cantidad de casos de prueba, los días de ejecución y la cantidad de incidentes que encontremos. En el caso de ute que mencionabamos de 3 casos de prueba nos llevo 23 días de trabajo.
- CarolinaCreo por todo lo que me comentaste realmente me convenciste! Para poder tener una mejor calidad y quedarme más tranquila en la salida en producción tengo que incluir pruebas de performance en mis proyectos! Es más es algo adictivo, no? Luego de realizar una prueba de estrés en la salida a producción jamás saldrán a producción sin realizar una.
- Si quieren conocer un poco más sobre testing los invito especialmente a estas dos charlas que vienen a continuación en este mismo salón, En esta primera podrán conocer sobre la nueva carrera on-line de testing que ha lanzado el CES, se las recomiendo!Y luego Fabían de Abstracta estará contando más detalles sobre Gxtest, en particular estará mostrando la generación de scripts para prueba de performance que hablamos en esta charla.
- CarolinaDespedida, agradecimiento y Contar experiencia conjunta que hemos realizado GXC y Abstracta y (que vamos a seguir realizando)