Page 32 - REVISTA 2016

Diseñar y programar tests unitarios siempre fue una molestia para los desarrolladores de software. El problema
de fondo tal vez sea que las pruebas unitarias no se consideran parte del desarrollo, y se consideran entonces una
tarea opcional y de apoyo. Hay una herramienta que, para los desarrolladores en plataforma Microsoft, puede ser
de gran ayuda para comenzar, principalmente para aquellos que no han hecho muchas pruebas (o ninguna) y
quieren comenzar, lamada IntelliTest. De manera muy sencilla contaremos con un conjunto de pruebas unitarias
que logran cubrir ciertos flujos de ejecución, ahorrándonos bastante tiempo en este tipo de tarea. De todos mo-
dos, esto ayuda a resolver parte del problema desde un aspecto completamente técnico, cuando el problema es
realmente de índole cultural.

Es fundamental definir una buena estrategia de pruebas automatizadas: una base fuerte en pruebas uni-
tarias, varias pruebas a nivel de servicios y solo las más críticas a nivel de interfaz gráfica. Es necesario
considerar la mantenibilidad de las pruebas para poder mantener la relación costo-beneficio. Las pruebas
automáticas son las verificaciones a nivel funcional más importantes que se adjuntan a la herramienta de
Integración Continua, buscando ejecutarlas frecuentemente.

El testing de performance

En las pruebas de performance se simula carga sobre el sistema bajo pruebas para analizar su rendimiento bajo
estas condiciones, pudiendo así encontrar cuellos de botella y oportunidades de mejora. Existen herramientas
especializadas en realizar este tipo de simulaciones, que permiten automatizar las acciones que generarán esa
carga, o sea: las interacciones entre el usuario y el servidor. Para simular muchos usuarios con poca infraestructura
de pruebas, no se puede tener el mismo enfoque que las herramientas de testing funcional (que automatizan a
nivel de interfaz gráfica) sino que se automatizan las interacciones a nivel de protocolo, lo cual hace que la auto-
matización sea más compleja (en cuanto al trabajo necesario para su preparación).

Podríamos distinguir dos tipos de enfoques para las pruebas de performance: las que realizamos antes de salir en
producción a modo de prueba de aceptación, y los chequeos que podemos ir realizando de manera temprana
durante todo el desarrollo. Lo más importante aquí es que ambos enfoques son esenciales. Se necesita simular la
carga esperada, pero no podemos dejar todo para el último momento, ya que si ahí aparecen problemas segura-
mente serán más complejos de resolver. Por otra parte, hacer pruebas a cada componente de forma frecuente nos
permite reducir los costos en las correcciones, pero nada nos garantiza que todo va a funcionar adecuadamente
cuando se integre e instale en un servidor y reciba la carga esperada. En cualquiera de estos enfoques también se
necesita de perfiles de DevOps, que sean capaces de analizar los distintos componentes de la aplicación, sistema
operativo, bases de datos, etc., pudiendo manejar distintas herramientas de monitorización para analizar dónde
puede haber algún cuello de botella, y siendo capaces de ajustar cualquier configuración que haga falta. También
es necesario involucrar a los desarrolladores con estas tareas, ya que la automatización que se necesita es una
tarea de programación, y muchas veces las mejoras que se deben realizar son a nivel de SQLs, esquema de datos,
algoritmos, entre otros.
Un problema importante a la hora de automatizar pruebas de performance para ejecutarlas frecuentemente, es
cómo lograr que los scripts de pruebas sean mantenibles. Esto sucede ya que la automatización se realiza a nivel
de protocolo, y en el caso de sistemas Web por ejemplo esto implica que es a nivel de HTTP, haciendo que los
scripts sean muy susceptibles a cambios de la aplicación. Recientemente surgieron dos herramientas que inten-
tan atacar este problema: Taurus (http://gettaurus.org/) y Gatling (http://gatling.io/). Ambas manejan los scripts
en texto plano y buscan reducir la simplicidad de los mismos, aplicando patrones de diseño de prueba como Page
Object, que logran reducir el impacto de los cambios. Esto muestra que es sumamente importante definir los
objetivos de las pruebas antes de seleccionar la herramienta que se va a utilizar, para poder elegir una que vaya
acorde a las necesidades y dificultades con la que nos podemos encontrar.

Debemos considerar las pruebas de performance para la aceptación de un producto, realizando una simu-
lación de la carga que se espera en producción, así como acompañar todo el desarrollo con chequeos au-
tomáticos, más unitarios y ejecutados de manera frecuente, como para lograr un buen testing continuo.

34 Revista de la Facultad de Ingeniería