Liderazgo en Pruebas: Pruebas de Servicio
Nota del editor: Bienvenido a la serie Liderazgo en Pruebas del gurú y consultor del testing de software Paul Gerrard. La serie está diseñada para ayudar a testers con algunos años de experiencia—especialmente aquellos en equipos ágiles—a destacar en sus roles de liderazgo y gestión de pruebas.
En el artículo anterior analizamos el papel cambiante de los testers y cómo fomentar una mejor colaboración con tus colegas. En este artículo, entraremos en detalle sobre cómo probar el rendimiento, la fiabilidad y la gestionabilidad de una aplicación web. También conocido como pruebas de servicio.
Suscríbete al boletín de The QA Lead para recibir notificaciones cuando se publiquen nuevas partes de la serie. Estas publicaciones son extractos del curso Liderazgo en Pruebas de Paul, que recomendamos mucho para una inmersión más profunda en este y otros temas. Si te animas, utiliza nuestro código exclusivo de cupón QALEADOFFER para obtener $60 de descuento en el precio total del curso.
Hola y bienvenido a otro capítulo de la serie Liderazgo en Pruebas. Esta semana nos centraremos en las pruebas de servicio para aplicaciones web. Cubriremos:
- ¿Qué son las pruebas de servicio?
- ¿Qué son las pruebas de rendimiento?
- Pruebas de fiabilidad/tolerancia a fallos
- Pruebas de gestión del servicio
Comencemos.
¿Quieres más de The CTO Club?
Crea una cuenta gratuita para terminar de leer este contenido y unirte a una comunidad de CTOs y líderes de ingeniería que comparten marcos, herramientas y conocimientos reales para diseñar, desplegar y escalar tecnología impulsada por IA.
Have an account? Log In
¿Qué son las pruebas de servicio?
La calidad del servicio que proporciona una aplicación web puede definirse incluyendo todos sus atributos como funcionalidad, rendimiento, fiabilidad, usabilidad, seguridad, entre otros.
Sin embargo, para nuestros propósitos aquí, distinguimos tres objetivos particulares de servicio que están bajo el escrutinio de lo que llamaremos ‘pruebas de servicio’. Estos objetivos son:
- Rendimiento: el servicio debe ser ágil para los usuarios mientras soporta las cargas que se le imponen.
- Fiabilidad: si el diseño considera la resiliencia al fallo, el servicio debe ser fiable y/o continuar prestando servicio incluso cuando ocurre un fallo.
- Gestionabilidad: el servicio debe ser susceptible de ser gestionado, configurado o modificado sin que se perciba una degradación del servicio por parte del usuario final. La gestionabilidad, o pruebas de operaciones, tiene como objetivo demostrar que los procedimientos administrativos, de gestión, copia de seguridad y recuperación del sistema funcionan eficazmente.
En los tres casos, necesitamos simular carga de usuarios para realizar las pruebas de manera efectiva. Los objetivos de rendimiento, fiabilidad y gestionabilidad existen en el contexto de clientes reales que usan el sitio para hacer negocios.
La capacidad de respuesta (en este caso, el tiempo que tarda un nodo del sistema en responder a la petición de otro) de un sitio está relacionada directamente con los recursos disponibles dentro de la arquitectura técnica.
A medida que más clientes usan el servicio, menos recursos técnicos están disponibles para atender las solicitudes de cada usuario y los tiempos de respuesta se degradarán.
Evidentemente, un servicio con poca carga es menos propenso a fallar. Gran parte de la complejidad del software y hardware existe para dar soporte a las demandas de recursos en la arquitectura técnica cuando un sitio está muy cargado.
Cuando un sitio tiene carga (o sobrecarga), las solicitudes conflictivas de recursos deben ser gestionadas por varios componentes de la infraestructura como sistemas operativos de servidor y red, sistemas de gestión de bases de datos, productos de servidores web, brokers de peticiones de objetos, middleware, etc.
Estos componentes de infraestructura suelen ser más fiables que el código de aplicación personalizado que solicita los recursos, pero pueden producirse fallos en ambos casos:
- Los componentes de infraestructura fallan porque el código de la aplicación (por un mal diseño o implementación) impone demandas excesivas sobre los recursos.
- Los componentes de la aplicación pueden fallar porque los recursos que requieren no siempre están disponibles (a tiempo).
Al simular cargas típicas e inusuales de producción durante un período prolongado, los testers pueden descubrir fallos en el diseño o implementación del sistema. Una vez resueltos estos fallos, las mismas pruebas demostrarán que el sistema es resiliente. Los analistas de calidad pueden aprovechar herramientas de pruebas de carga para ejecutar muchos de los procesos definidos a continuación.
En todos los servicios, suele haber una serie de procesos de gestión críticos que deben realizarse para que el servicio funcione sin problemas. Podría ser posible apagar un servicio para hacer mantenimiento de rutina fuera del horario laboral normal, pero la mayoría de los servicios en línea operan las 24 horas del día.
La jornada laboral del servicio nunca termina. Inevitablemente, se deben cumplir procedimientos de gestión mientras el servicio está activo y los usuarios están en el sistema. Estos procedimientos deben probarse cuando existe carga sobre el sistema para comprobar que no afectan negativamente el servicio en vivo, es decir, pruebas de rendimiento.
¿Qué es la Prueba de Rendimiento?
La prueba de rendimiento es un componente clave de las pruebas de servicios. Es una forma de probar cómo se comporta un sistema en términos de capacidad de respuesta y estabilidad bajo una carga específica. Aquí tienes una visión general de cómo funciona:
- La prueba de rendimiento consiste en una variedad de pruebas con diferentes cargas donde el sistema alcanza un estado estable (cargas y tiempos de respuesta en niveles constantes).
- Medimos la carga y los tiempos de respuesta para cada carga, simulados durante un período de 15-30 minutos, para obtener una cantidad estadísticamente significativa de mediciones.
- Monitorizamos y registramos los signos vitales para cada carga simulada. Estos son los diversos recursos de nuestro sistema, por ejemplo, uso de CPU y memoria, ancho de banda de red, tasas de E/S, etc.
Trazamos un gráfico de estas cargas variables frente a los tiempos de respuesta experimentados por nuestros usuarios “virtuales”. Cuando se grafica, nuestro gráfico se parece a la figura de abajo.
En carga cero, donde solo hay un único usuario en el sistema, este disfruta de todos los recursos y los tiempos de respuesta son rápidos. A medida que introducimos cargas crecientes y medimos los tiempos de respuesta, estos empeoran progresivamente hasta que llegamos a un punto donde el sistema está funcionando a máxima capacidad.
En este punto, el tiempo de respuesta para nuestras transacciones de prueba es, en teoría, infinito porque uno de los recursos clave del sistema está completamente agotado y no se pueden procesar más transacciones.
A medida que incrementamos las cargas desde cero hasta el máximo, también supervisamos el uso de varios tipos de recursos como, por ejemplo, el uso del procesador del servidor, uso de memoria, ancho de banda de red, bloqueos de base de datos, etc.
En la carga máxima, uno de estos recursos está saturado al 100%. Este recurso es el recurso limitante porque es el primero en agotarse. Por supuesto, en este punto los tiempos de respuesta se han degradado hasta el punto de ser probablemente mucho más lentos de lo aceptable.
El gráfico de abajo muestra el uso/disponibilidad de varios recursos graficados en función de la carga.
Para aumentar la capacidad de procesamiento y/o reducir los tiempos de respuesta de un sistema, debemos hacer una de las siguientes cosas:
- Reducir la demanda del recurso, normalmente haciendo que el software que utiliza el recurso sea más eficiente (esto suele ser responsabilidad del desarrollo).
- Optimizar el uso del recurso de hardware dentro de la arquitectura técnica, por ejemplo, configurando el DBMS para almacenar más datos en memoria o priorizando algunos procesos sobre otros en el servidor de aplicaciones.
- Hacer que haya más recursos disponibles. Normalmente agregando procesadores, memoria, ancho de banda de red, etc.
Como ya habrás notado, la prueba de rendimiento requiere la colaboración de un equipo para apoyar a los testers. Estos son los arquitectos técnicos, administradores de servidores, administradores de red, desarrolladores y diseñadores/administradores de bases de datos. Estos expertos técnicos están cualificados para analizar las estadísticas generadas por las herramientas de monitorización de recursos y determinar cómo ajustar la aplicación o mejorar el sistema.
Si eres el tester, a menos que seas un experto particular en estos campos, no te sientas tentado a fingir que puedes interpretar estas estadísticas y tomar decisiones de ajuste y optimización. Necesitarás involucrar a estos expertos al principio del proyecto para obtener su asesoramiento y compromiso y más adelante, durante las pruebas, para garantizar que los cuellos de botella sean identificados y resueltos.
Estate atento al próximo artículo donde profundizaremos en cómo gestionar la prueba de rendimiento.
Prueba de Fiabilidad/Failover
Asegurar la disponibilidad continua de un servicio es probablemente un objetivo clave de tu proyecto. La prueba de fiabilidad ayuda a detectar fallos poco comunes que provocan fallos inesperados. Por otro lado, la prueba de failover asegura que las medidas diseñadas para fallos anticipados realmente funcionan.
Prueba de Failover
Cuando se requiere que los sitios sean resilientes y/o fiables, suelen diseñarse con componentes del sistema fiables que cuentan con redundancia y funciones de failover que entran en juego cuando ocurren fallos.
Estas funciones pueden incluir rutas de red diversas, múltiples servidores configurados como clústeres, middleware y tecnologías de servicios distribuidos que gestionan el balanceo de carga y el redireccionamiento del tráfico en escenarios de fallo.
La prueba de failover tiene como objetivo explorar el comportamiento del sistema bajo escenarios de fallo seleccionados antes del despliegue y normalmente involucra lo siguiente:
- Identificación de los componentes que podrían fallar y causar una pérdida de servicio (analizando las fallas desde adentro hacia afuera).
- Identificación de los riesgos que podrían causar una falla y una pérdida de servicio (analizando las amenazas desde afuera hacia adentro).
- Análisis de los modos o escenarios de falla que podrían ocurrir donde se necesita confianza en que la medida de recuperación funcionará.
- Una prueba automatizada que puede usarse para cargar el sistema y explorar el comportamiento del sistema durante un período extendido.
- La misma prueba automatizada también puede usarse para cargar el sistema bajo prueba y monitorear el comportamiento del sistema bajo condiciones de falla.
Una técnica llamada Análisis de Árbol de Fallas (FTA) puede ayudarte a comprender las dependencias del servicio sobre sus componentes subyacentes. El análisis de árbol de fallas y los diagramas de árbol de fallas son una representación lógica de un sistema o servicio y las formas en que puede fallar.
El esquema simple a continuación muestra la relación entre eventos de falla de componentes básicos, eventos de falla de subsistemas intermedios y el evento de falla de servicio más alto. Por supuesto, podría ser posible identificar más de tres niveles de eventos de falla.
Estas pruebas tienen que ejecutarse con una carga automatizada para explorar el comportamiento del sistema en situaciones de producción y ganar confianza en las medidas de recuperación incorporadas. En particular, se quiere saber:
- ¿Cómo se comporta la arquitectura en situaciones de falla?
- ¿Los mecanismos de balanceo de carga funcionan correctamente?
- ¿Las capacidades de recuperación automática absorben la carga cuando falla un componente?
- ¿Funciona la recuperación automática? ¿Los sistemas reiniciados "se ponen al día"?
En última instancia, las pruebas se centran en determinar si el servicio a los usuarios finales se mantiene y si los usuarios realmente notan la ocurrencia de la falla.
Pruebas de fiabilidad (o soak testing)
Las pruebas de fiabilidad tienen como objetivo comprobar que no ocurran fallos bajo carga.
La mayoría de los componentes de hardware son lo suficientemente fiables como para que su tiempo medio entre fallos pueda medirse en años. Las pruebas de fiabilidad requieren el uso (o reutilización) de pruebas automatizadas de dos formas para simular:
- Cargas extremas en componentes o recursos específicos de la arquitectura técnica.
- Períodos prolongados de cargas normales (o extremas) en todo el sistema.
Cuando nos centramos en componentes específicos, buscamos estresar el componente sometiéndolo a una cantidad desmesurada de solicitudes para realizar su función diseñada. A menudo es más sencillo realizar una prueba de estrés sobre los componentes críticos de forma aislada y con grandes cantidades de solicitudes simples antes de aplicar una prueba mucho más compleja a toda la infraestructura. También existen herramientas de pruebas de estrés especialmente diseñadas para facilitar la ejecución del proceso a los QAs.
Las pruebas de resistencia (soak tests) son pruebas que someten a un sistema a una carga durante un período prolongado de, por ejemplo, 24, 48 horas o incluso más para encontrar problemas (que suelen ser) difíciles de detectar. Los fallos poco evidentes a menudo solo se manifiestan después de un uso prolongado.
La prueba automatizada no necesariamente tiene que aumentar hasta cargas extremas (las pruebas de estrés cubren eso). Pero nos interesa especialmente la capacidad del sistema de soportar la ejecución continua de una amplia variedad de transacciones de prueba para detectar posibles fugas de memoria, bloqueos o condiciones de carrera difíciles de detectar.
Pruebas de Gestión de Servicios
Por último, una palabra sobre las pruebas de gestión de servicios.
Cuando el servicio se despliega en producción, tiene que ser gestionado. Mantener un servicio en funcionamiento requiere que sea monitoreado, actualizado, respaldado y reparado rápidamente cuando ocurren problemas.
Los procedimientos que los gestores de servicio usan para realizar actualizaciones, copias de seguridad, publicaciones y recuperaciones de fallos son críticos para ofrecer un servicio fiable, por lo que necesitan ser probados, especialmente si el servicio sufrirá cambios rápidos tras su despliegue.
Los problemas particulares a abordar son:
- Los procedimientos no logran el efecto deseado.
- Los procedimientos no son operables o usables.
- Los procedimientos interrumpen el servicio en vivo.
Las pruebas deben, en la medida de lo posible, ejecutarse de la manera más realista posible.
Algunas Reflexiones
Algunos sistemas son propensos a cargas extremas cuando ocurre cierto evento. Por ejemplo, un negocio en línea esperaría que las cargas máximas ocurran justo después de anunciar ofertas en la televisión, o un sitio web de noticias nacional podría saturarse cuando surge una noticia de gran importancia.
Piensa en un sistema que conozcas bien y que haya sido afectado por incidentes imprevistos en tu empresa o en noticias nacionales.
¿Qué incidentes o eventos podrían desencadenar cargas excesivas en tu sistema?
¿Puedes (o podrías) capturar datos de los registros del sistema que te den el número de transacciones ejecutadas? ¿Puedes escalar este evento para predecir un evento crítico de 1 en 100 años, o de 1 en 1000 años?
¿Qué medidas podrías aplicar (o has aplicado) para reducir la probabilidad de picos, la magnitud de los picos, o eliminarlos por completo?
Suscríbete al boletín de The QA Lead para recibir una notificación cuando se publiquen nuevas partes de la serie. Estas publicaciones son extractos del curso Liderazgo en Pruebas de Paul, que recomendamos mucho si deseas profundizar en este y otros temas. ¡Si te interesa, usa nuestro código de cupón exclusivo QALEADOFFER para obtener $60 de descuento en el precio total del curso!
Lectura sugerida: LAS 10 MEJORES HERRAMIENTAS DE GESTIÓN DE PRUEBAS OPEN SOURCE
