Difference between revisions of "GXtest2OpenSTA para pruebas de performance"
(New page: Empty) |
|||
| Line 1: | Line 1: | ||
| − | + | == Introducción == | |
| + | Un aspecto fundamental a tener en cuenta en los test de performance es que, por varias razones, es imposible testear todas las funcionalidades de una aplicación. Teniendo presente esto, surge un nuevo problema: ¿Qué casos de prueba automatizar? | ||
| + | |||
| + | Para resolver esto se puede recurrir (en caso de que el sistema tenga una versión anterior en funcionamiento) a datos tomados del sistema anterior referentes a usuarios activos, número de veces que se utiliza la funcionalidad, etc. De no tener esta posibilidad, se puede recurrir al conocimiento de expertos (encargados del proyecto, desarrolladores, usuarios u otras personas que puedan realizar un estimativo de que funcionalidades serán las más adecuadas para incluir en las pruebas). | ||
| + | |||
| + | Luego de determinados los casos de prueba a ejecutar, se deben automatizar. Armar los scripts es generalmente la parte que lleva más tiempo del proyecto, afortunadamente, con Gxtest esta tarea se puede hacer con menor esfuerzo. | ||
| + | |||
| + | Si bien GXtest es una herramienta de testing funcional nos permite una vez que tenemos los casos de prueba automatizados generar scripts en una herramienta gratuita para pruebas de performance como es OpenSTA. | ||
| + | |||
| + | ''¿Cuándo realizar testing de performance?'' | ||
| + | |||
| + | Básicamente, existen dos estrategias para encarar las pruebas de performance. | ||
| + | |||
| + | La más tradicional es comenzar con la automatización de los casos de prueba luego de finalizado el producto, por lo que no van a haber más cambios en el desarrollo. Esta estrategia tiene como ventaja que no se tendrá que invertir tiempo en mantenimiento de los casos de prueba automatizados ya que se trabaja con una única versión del sistema. Sin embargo tiene la principal contra de que se pueden encontrar de manera muy tardía problemas de diseño o de arquitectura que impliquen un retrabajo de construcción del sistema muy grande. | ||
| + | |||
| + | La otra manera de encarar un proyecto de performance, es comenzar las pruebas de performance en paralelo con el desarrollo, a medida que se van liberando las funcionalidades principales. Este método tiene como ventaja que se pueden descubrir fallas más temprano y se pueden ir solucionando a medida que avanza el desarrollo, sin embargo, el costo de las pruebas de performance puede ser mayor ya que hay que ir adaptando los casos de prueba cuando se producen cambios en el desarrollo. En esta tarea de mantenimiento de los casos de prueba es fundamental el uso de GXtest como herramienta de automatización ya que nos va a permitir rápidamente adaptar los casos de prueba automatizados a los cambios del sistema. | ||
| + | |||
| + | == OpenSTA == | ||
| + | [http://www.opensta.org OpenSTA] es una herramienta open source para hacer test de performance, se utiliza para automatizar los casos de pruebas en scripts que contienen los pedidos http (o https) que realiza cada caso y permite modificarlos para realizar distintas acciones (tales como ingresar validaciones, condiciones, parametrizaciones, etc.). En la figura 1, podemos apreciar el formato de un script de OpenSTA. | ||
| + | |||
| + | [[image:OpenSTASctipt.png|center]] | ||
Revision as of 17:08, 29 December 2011
Introducción
Un aspecto fundamental a tener en cuenta en los test de performance es que, por varias razones, es imposible testear todas las funcionalidades de una aplicación. Teniendo presente esto, surge un nuevo problema: ¿Qué casos de prueba automatizar?
Para resolver esto se puede recurrir (en caso de que el sistema tenga una versión anterior en funcionamiento) a datos tomados del sistema anterior referentes a usuarios activos, número de veces que se utiliza la funcionalidad, etc. De no tener esta posibilidad, se puede recurrir al conocimiento de expertos (encargados del proyecto, desarrolladores, usuarios u otras personas que puedan realizar un estimativo de que funcionalidades serán las más adecuadas para incluir en las pruebas).
Luego de determinados los casos de prueba a ejecutar, se deben automatizar. Armar los scripts es generalmente la parte que lleva más tiempo del proyecto, afortunadamente, con Gxtest esta tarea se puede hacer con menor esfuerzo.
Si bien GXtest es una herramienta de testing funcional nos permite una vez que tenemos los casos de prueba automatizados generar scripts en una herramienta gratuita para pruebas de performance como es OpenSTA.
¿Cuándo realizar testing de performance?
Básicamente, existen dos estrategias para encarar las pruebas de performance.
La más tradicional es comenzar con la automatización de los casos de prueba luego de finalizado el producto, por lo que no van a haber más cambios en el desarrollo. Esta estrategia tiene como ventaja que no se tendrá que invertir tiempo en mantenimiento de los casos de prueba automatizados ya que se trabaja con una única versión del sistema. Sin embargo tiene la principal contra de que se pueden encontrar de manera muy tardía problemas de diseño o de arquitectura que impliquen un retrabajo de construcción del sistema muy grande.
La otra manera de encarar un proyecto de performance, es comenzar las pruebas de performance en paralelo con el desarrollo, a medida que se van liberando las funcionalidades principales. Este método tiene como ventaja que se pueden descubrir fallas más temprano y se pueden ir solucionando a medida que avanza el desarrollo, sin embargo, el costo de las pruebas de performance puede ser mayor ya que hay que ir adaptando los casos de prueba cuando se producen cambios en el desarrollo. En esta tarea de mantenimiento de los casos de prueba es fundamental el uso de GXtest como herramienta de automatización ya que nos va a permitir rápidamente adaptar los casos de prueba automatizados a los cambios del sistema.
OpenSTA
OpenSTA es una herramienta open source para hacer test de performance, se utiliza para automatizar los casos de pruebas en scripts que contienen los pedidos http (o https) que realiza cada caso y permite modificarlos para realizar distintas acciones (tales como ingresar validaciones, condiciones, parametrizaciones, etc.). En la figura 1, podemos apreciar el formato de un script de OpenSTA.
