Anda di halaman 1dari 6

Automatizacin de pruebas

Ing. Dalia Trujillo MSc.

Resumen La automatizacin de pruebas es una disciplina cada vez ms requerida dentro del mbito de desarrollo de software. Es la clave para asegurar que el software que ya ha sido desarrollado, contina con calidad. Sin embargo, se deben tener en cuenta algunos aspectos para que el esfuerzo de automatizacin sea apropiado para el producto de software, y logre los resultados deseados. Para qu automatizar pruebas? La primera vez que me enfrent a la temtica de la automatizacin de pruebas, fue alrededor de 1997 en la certificacin de ao 2000. En este momento nos enfrentbamos a la situacin de tener que probar ciertos cambios que haba tenido un software bancario, en 22 fechas que eran las correspondientes a la certificacin, incluyendo el primer da del ao 2000, el final de febrero del ao 2000 y todos los aos bisiestos, fin de ao, entre otros. Se deba repetir la misma situacin varias veces en un tiempo limitado. En ese momento, surgi una idea: existe una herramienta robot que permite automatizar las pruebas, se graba una sola vez y luego la herramienta ejecuta las pruebas sola, as que slo tendramos que cambiar la fecha y con la herramienta, voal: todo funcionar. Pero la falta de conocimiento y experiencia nos llev a diferentes situaciones. Las pantallas eran negro y verde, propias del AS/400. As que empezamos a grabar los scripts, haciendo las acciones de las pruebas (que por cierto no estaban escritas, eran las que iban surgiendo). Al momento de reproducir, el robot mandaba ejecutar todas las acciones que haba guardado a toda velocidad, y el AS/400 no alcanzaba a responder a la misma velocidad que se enviaban las acciones. Nunca pudimos usar esa herramienta. Lo que nos sirvi fue para tener un script con las pruebas, imprimir ese script y llamar a mucha gente del Banco a probar ejecutando a mano ese script. En este ejemplo de la vida real, se percibe el objetivo de la automatizacin de las pruebas: ejecutar las mismas acciones varias veces sobre el mismo software. Aunque la forma de hacer la automatizacin fall de forma absoluta. El objetivo de la automatizacin no es hacer las pruebas ms rpido, como alguna vez lo crey la gerente de tecnologa de una empresa de salud. Esto tambin fue real: ella tena el proyecto muy atrasado y con calidad deficiente, y pens que la herramienta de automatizacin le iba a ayuda a hacer las pruebas ms rpidamente, y as adelantar el proyecto. Automatizar dispendioso, las pruebas puede largo y complicado, ser sin

embargo, vale la pena y cada vez coge ms fuerza. Es una realidad que cada vez que se hace una modificacin del software, la probabilidad de ingresarle errores es muy alta. Y aunque existen diferentes tcnicas para prevenir errores, como lo son la estimacin de impacto de los cambios, anlisis de cdigo y otros, es mejor tener la forma de volver a probar las partes crticas del software para estar seguros que todo sigue funcionando bien. Por este motivo, una de los usos principales de las pruebas automatizadas es el mantenimiento: tener una suite de pruebas de demuestren que el core del software sigue funcionando adecuadamente. As inicia: por la ejecucin de pruebas de regresin cada vez que sale a produccin una nueva versin. Pero, surge una tendencia que le da otro valor adicional a las pruebas: el desarrollo iterativo. El desarrollo iterativo, que ahora coge ms fuerza con los procesos giles, se basa en el desarrollo por partes del software, y que se va avanzando por varios pequeos cascada, uno tras de otro. Si bien, es muy valioso porque permite tener rpida retroalimentacin del usuario, y si hay fallas de entendimiento o de estructura del software, es posible enderezar el barco en tiempos cortos y no hasta el final del proyecto, tiene tambin un costo: las pruebas. La clave que el manejo iterativo funcione es que se hagan correctamente las pruebas al final de cada iteracin. Esto implica, que cada vez que se termina la iteracin se debe probar lo nuevo, y demostrar que lo que antes estaba funcionando sigue hacindolo,

por lo que las pruebas de regresin con acumulativas. Tipos de pruebas automatizadas: Pruebas de Rendimiento La automatizacin de pruebas no slo se usa para regresin. Tambin se usa para simular condiciones de carga y/o volumen. Estas se llaman herramientas de pruebas de rendimiento (aunque algunas personas errneamente las llaman pruebas de stress o pruebas de carga). Generalmente, se utiliza para esto una herramienta de simulacin de usuarios concurrentes, aunque debe ir acompaado de ms herramientas para generar volumen, para hacer simulaciones de integracin, o para detectar cuellos de botella o abrazos mortales en el sistema. De acuerdo con el plan de pruebas, se utiliza la combinacin de las herramientas para validar el comportamiento en condiciones esperadas, en condiciones extremas, para revisar su escalabilidad o confiabilidad. Al hacer la planeacin de estas pruebas se debe tener en cuenta la arquitectura del sistema, porque no necesariamente el simular concurrencia de usuarios nos lleva a detectar errores cuando haya concurrencia. Me explico. Si se simula concurrencia sobre un solo tipo de transaccin y un mismo usuario, es posible que la respuesta del sistema sea muy rpida, y se lleve la impresin incorrecta que el software soporta las condiciones. Esto gracias a los manejos de cach de los servidores de bases de datos y de aplicaciones. Cuando se hace la planeacin de las pruebas de concurrencia, se deben tener en cuenta

componentes compartidos, manejo de cach, diferentes usuarios, y en general, la arquitectura del sistema, para que las pruebas haga la exigencia requerida del software. Cuando se hace una prueba de carga, debe estar unida con el objetivo de la prueba, los criterios de aceptacin, y preferiblemente con herramientas de monitoreo en el servidor de aplicaciones y servidor de base de datos para detectar cuellos de botella. Se debe tener en cuenta adems, que es diferente cargar una aplicacin de forma puntual, a hacerlo por un tiempo determinado. La carga en un tiempo largo, demuestra la confiabilidad del sistema a lo largo del tiempo. Es posible encontrar software que se comporte adecuadamente en una carga puntual (de un minuto, por ejemplo), pero que falle si la carga es contnua (por ejemplo de 15 o 20 minutos). Esto debido al manejo de memoria o cach. Tambin, es posible contar con escenarios de picos de carga, lo que demuestra el manejo del software en condiciones extremas. El realizar las pruebas o no y las condiciones de las mismas se deben realizar en la planeacin de acuerdo con el tipo de software a probar, y las condiciones esperadas en produccin. Es de tener en cuenta adems, que se recomienda que el ambiente de pruebas a utilizar para las pruebas de rendimiento sea diferente al de las pruebas de aceptacin, y en lo posible, tenga condiciones similares a las de produccin. No existe una frmula matemtica que haga extrapolacin del

ambiente de pruebas, al ambiente de produccin, aunque s se pueden hacer anlisis basados en los resultados de la carga y conocimiento y experiencia de la infraestructura. Dentro de las herramientas libres de carga que se pueden encontrar en el mercado son (tomado de www.webresourcedepot.com): Pylot web performance tool Apache Jmeter Siege The Grinder

Pruebas Funcionales Automatizadas Las pruebas de las que se habl en la introduccin se refieren a las pruebas funcionales automatizadas. En ellas se pretende reemplazar la funcin que hara un probador que interacta con el sistema y que hace de forma repetitiva, con un script ejecutado por un robot. Cuando se hace automatizacin de pruebas funcionales se debe incluir dos aspectos: las acciones que se ejecutan en la prueba, y los puntos de verificacin de la misma. Estos puntos son los aspectos que se validan en el software que demuestran que su comportamiento es aceptable, como pueden ser: mensajes de confirmacin, despliegues de informacin, activacin de botones o de opciones en general, entre otros. Las herramientas de automatizacin detectan estos objetos, los comparan con el resultado esperado y por medio de esta comparacin reportan si el comportamiento es correcto o fallido. As que uno de los aspectos ms importantes es que el robot pueda detectar los objetos de la pantalla. Es por esto que

existen diferentes versiones o herramientas de automatizacin dependiendo de la interaccin con el sistema. Es diferente un objeto en Visual Basic, a uno en forms, o en .NET. Para hacer la automatizacin de pruebas, se recomienda identificar cuales son los escenarios que vale la pena mecanizar, dados los riesgos para el negocio y la probabilidad de ocurrencia. Tambin se deben tener en cuenta la estabilidad de los requerimientos y estabilidad de las pantallas. Es decir, cuando se modifican las pantallas en los desarrollos, tambin hay que modificar los scripts de automatizacin. Dependiendo de la herramienta, se puede cambiar como si fuera un lenguaje de programacin, o se debe volver a grabar completamente. De otro lado, hay que parametrizar las variables que se ingresan en la aplicacin. Es decir, si se automatiza la creacin de un cliente con nombre Juan Perez con resultado de confirmacin en la aplicacin, cuando se ejecute sobre la aplicacin las pruebas automatizadas, sobre la misma base de datos, el resultado ser diferente dado que el cliente ya existe. Es por esto, que las variables de ingreso se deben parametrizar para que las tome sobre una base Excel, o alguna entrada que se pueda cambiar sin necesidad de modificar los scripts de automatizacin. Dentro de las herramientas libres funcionales que se pueden encontrar en el mercado son (tomado de www.webresourcedepot.com): SeleniumHQ Watir AtiWate Webdriver

HtmlUnit Sahi Ottomate Ieunit Fwptt

Pruebas Unitarias Automatizadas Dentro del manejo iterativo, cada vez toman ms fuerza las pruebas unitarias automatizadas. Consisten en las pruebas de unidad que validan el correcto funcionamiento de un mdulo o componente de la aplicacin. La automatizacin de estas pruebas se hacen con herramientas de ambiente de desarrollo, que tienen la caracterstica de facilitar al programador la creacin de ambientes para la ejecucin de ciertos mtodos de componentes, bajo parmetros determinados. Tambin permiten llevar estas pruebas a scripts de integracin contnua, de forma que se puedan ejecutar sobre estas herramientas de integracin y probar continuamente el software. La clave de estas pruebas es que son de caja blanca, y se deben planear basadas en el diseo. Una de las dificultades de la automatizacin de pruebas unitarias, y en general, la ejecucin de pruebas unitarias es la generacin de condiciones ambientales para un set interesante de pruebas. Si bien estas herramientas permiten inicializar variables, objetos o componentes, dejan de lado una tarea que se debe suplir manualmente o por medio de algn otro mecanismo, que es el ingreso de la informacin en la base de datos de forma que los scripts funcionan adecuadamente.

De otro lado, tambin se requiere la creacin de componentes conocidos como Stubs y Mocks, que son parches que se le colocan a los componentes que se quieren probar y que necesitan interactuar con componentes que no estn disponibles en el ambiente, posiblemente porque no estn desarrollados. Los procesos giles estn fuertemente soportados en la necesidad de automatizacin de las pruebas unitarias, hacer un manejo iterativo de dos semanas a un mes, lo que requiere ejecucin de pruebas en estos intervalos, y mucho ms si est implementada la integracin contnua, que incluso prefiere ejecutar las pruebas unitarias diariamente. Dentro de las herramientas libres funcionales que se pueden encontrar en el mercado son (tomado de www.wikipedia.com):

NUnit: Versin del framework para la plataforma.NET. FoxUnit: Entorno OpenSource de pruebas unitarias para Microsoft Visual FoxPro MOQ: Entorno para la creacin dinmica de objetos simuladores (mocks). MOQ. QUnit: Librera para pruebas unitarias en Javascript. Creada por la fundacin jQuery, ha sido reescrita para ser independiente de la librera jQuery

Recomendaciones Finales El mundo de la automatizacin de pruebas es amplio y puede llevar a grandes esfuerzos. Es por eso que se recomienda llevar esta automatizacin de la mano con la correcta aplicacin metodolgica, que est orientado a riesgos y a un esquema particular de uso. La automatizacin de pruebas no se puede llevar, como alguna vez lo pretendi el Gerente de Aplicaciones de una empresa de Telecomunicaciones, prendiendo el robot en la medida en que iban realizando las pruebas. La automatizacin requiere planeacin, diseo, desarrollo y pruebas de las pruebas del software, lo que indica que es un subproyecto dentro de los esfuerzos del proyecto o mantenimiento del software. Deben ser claros los objetivos, los recursos, los lmites y un esfuerzo fuerte en esquema metodolgico para evitar que sea una moda de algunos precursores dentro de la empresa.

JUnit: Entorno de pruebas para Java creado por Erich Gamma y Kent Beck. Se encuentra basado en SUnit creado originalmente para realizar pruebas unitarias para el lenguaje Smalltalk. TestNG: Creado para algunas deficiencias en JUnit. suplir

JTiger: Basado en anotaciones, como TestNG. SimpleTest: Entorno de pruebas para aplicaciones realizadas en PHP. PHPUnit: Sistema para la realizacin pruebas unitarias en PHP. CPPUnit: Versin del framework para lenguajes C/C++.

Esto, porque adems se debe dejar implementado el esfuerzo del mantenimiento de los scripts de automatizacin. Porque es comn que se haga un esfuerzo fuerte en automatizacin de pruebas que permiten ejecutar ciertos momentos iniciales en el software, pero que en la medida en que el software vaya cambiando los scripts se vayan relegando, hasta que ya no sea posible utilizarlos por cambios en la aplicacin. En la medida en que el software va cambiando, tambin se deben modificar a la par los scripts de automatizacin. Lo que implica que automatizar pruebas, no necesariamente es tener menos esfuerzo para mayor calidad. Es ms la aplicacin de la frase de Napolen: Vstame despacio que voy de prisa. Referencias Grahan, Dorothy. Van Veenendaal, Erick. Evans, Isabel. Black, Rex. Foundations of Software Testing. Course Technology. 2008. Kruchten, Philippe. The Rational Unified Process. An Introduction. Addison Wesley. 2001. Pginas web: www.wikipedia.com www.webresourcedepot.com http://www.scrumalliance.org/

Anda mungkin juga menyukai