Las pruebas de estrés de software protegen las aplicaciones empresariales en producción
Pocas cosas irritan más a un desarrollador que una aplicación supere extensas pruebas y aun así falle poco después de entrar en producción.
Hay pocas cosas más irritantes en la vida de un desarrollador de aplicaciones que una aplicación que supera extensas pruebas y aun así falla poco después de entrar en producción. Durante el pasado JavaOne 2013, Adam Bien –quien ostenta tanto el estatus de Campeón Java como el de Java Rock Star– explicó que la mayoría de las pruebas no se realizan bajo condiciones del mundo real. Según Bien, la verdadera diversión para las pruebas comienza después de que las pruebas de unidad e integración han evaluado que las funciones trabajen por su cuenta –ahí es donde comienzan las pruebas de esfuerzo (o estrés) del software.
Las pruebas de la unidad van directamente al corazón de una función. Las pruebas de integración se aseguran de que el componente A se acople bien con el componente B. Pero esas dos pruebas sólo ven realmente el código tal como se desempeña en el laboratorio, por así decirlo. Para saber cómo va a actuar cuando sea liberada, los equipos de desarrollo de aplicaciones necesitan llevar a cabo extensas pruebas de estrés en su software.
El problema, de acuerdo con el Java Rock Star, Bien, es que las pruebas unitarias y de integración generalmente se ejecutan en hilos individuales, pero ése nunca es el caso en el mundo real. "Las evaluaciones de calidad (QA) a veces se contentan con la cobertura de 80% del código ‘de un solo hilo’", dijo Bien, “pero su aplicación nunca se ejecutará en un solo hilo después de implementarla en un servidor de aplicaciones."
En defensa de la gente de aseguramiento de la calidad (QA), la cobertura de un único subproceso es realmente importante. Si una función no trabaja bien en el laboratorio, tiene pocas posibilidades de sobrevivir al ser liberada. También es mucho más fácil averiguar dónde están los problemas cuando se puede aislar cada parte y cada integración. Sin embargo, incluso después de que una aplicación resulta viable bajo condiciones de prueba aisladas, todavía tiene que demostrar su valía en condiciones de alta tensión antes de que pueda ser desplegada como una aplicación empresarial.
¿Por qué utilizar las pruebas de estrés?
Las pruebas de esfuerzo encuentran fallas en la aplicación que simplemente no se mostrarían en una sola instancia. "Las pruebas de estrés aumentan la probabilidad de encontrar un error crítico de concurrencia o un problema de la memoria", dijo Bien. También mencionó que la mayoría de los problemas que encuentra cuando colabora en un proyecto problemático podrían haberse encontrado con pruebas de tensión simples. Recomendó divertirse con las pruebas de estrés software. "Involucre a un estudiante con la siguiente misión: ‘Tienes toda la noche –sólo rompe nuestro servidor con [una] carga [de trabajo] masiva."
Si usted no tiene un estudiante cerca para que realice las solicitudes al servidor, la mejor opción es la automatización. Bien señaló que la automatización no es nada nuevo y que la integración continua es el resultado razonable de su evolución. "En realidad, todo en TI se trata realmente sobre automatización y racionalización del flujo", dijo. "Es curioso que [nosotros los desarrolladores] no seamos capaces de racionalizar y automatizar nuestro propio proceso de desarrollo."
La integración continua (CI) es la forma lógica de maximizar la automatización y reducir al mínimo la posibilidad de errores humanos, en la opinión de Bien. Estos conceptos también pueden ser más comunes en la empresa de lo que cabría esperar. De acuerdo con Bien, aproximadamente el 90% de sus actuales proyectos Java EE están empleando un servidor de IC, incluso si no han automatizado totalmente el proceso de despliegue. La gran ventaja con la automatización es que las pruebas de estrés –así como otros tipos de pruebas de software que pueden aparecer en el futuro– pueden ser incluidas en la batería de pruebas existente.
Sin embargo, las pruebas automatizadas y el despliegue continuo tal vez no sean estrictamente necesarios, especialmente para las organizaciones que no están realmente en el ámbito empresarial. La integración continua conlleva un grado de inversión en hardware que algunas organizaciones no estarán dispuestas o son capaces de proporcionar. Incluso a nivel de empresa, puede ser difícil obtener el hardware adecuado. "Sin ningún tipo de intervención", dijo Bien, "usted obtendrá la peor máquina disponible para las pruebas de estrés. La gerencia suele creer que un servidor de CI puede ejecutarse en un CPU 486 virtualizado", bromeó.
Pruebas de tensión sin el paquete completo CI
Mientras Bien señaló los desafíos de hardware como la principal preocupación, hay otros asimismo. La integración continua requiere una inversión de tiempo considerable también. Las pruebas de estrés de software no es sólo una cuestión del equipo de control de calidad; los desarrolladores y las operaciones tienen que estar involucrados, también. Todas esas pruebas automatizadas tienen que ser desarrolladas y codificadas, y el hardware debe ser mantenido. Para las organizaciones que no están listas para dar ese salto, Bien recomienda empezar poco a poco. "Comience con las cosas fáciles", aconsejó. "No trate de ser perfecto, simplemente comience con las pruebas de estrés."
Recuerde que lo importante en las pruebas de estrés de una pieza de software es que la aplicación tiene que luchar para mantenerse al día con la carga. Asígnele la tarea más grande que pueda imaginar, y luego hágalo de nuevo una y otra vez. No se detenga para dar a la aplicación una oportunidad de recuperarse; en realidad usted está tratando de romperla. "Realizar pruebas de estrés es divertido", dijo Bien, "y uno aprende sobre el comportamiento de su servidor de aplicaciones bajo carga pesada."
Y si todavía no desea hacer pruebas de estrés de software, hay una alternativa según Bien: "Ponga su aplicación en producción y rece."
