Pruebas de rendimiento · QA Tech Argentina
Pruebas de rendimiento: velocidad y estabilidad bajo uso real
A nadie le importa cuán linda es tu app si tarda 12 segundos en cargar el catálogo. Medimos tiempos, consumo y comportamiento con muchos usuarios a la vez, con picos comerciales y conexiones móviles variables de Argentina.
Lectura: carga · estrés · pico · respuesta por pantalla
Carga esperada
Usuarios reales sobre flujos que venden.
Picos Hot Sale
Subidas bruscas de 50 a 2000 conexiones.
Resistencia
Horas de carga para cazar fugas.
Móvil 4G
Señal variable y gama media.
Base de medición
Qué medimos en realidad cuando hablamos de velocidad
No alcanza con un promedio. Miramos percentiles: cuánto tarda el 95 por ciento de las operaciones. Si el promedio es bueno pero el 5 por ciento peor tarda 8 segundos, esos son los usuarios que se quejan y abandonan en el checkout, en el login o en la inscripción.
Definimos umbrales antes de probar, no después. Sin un límite acordado, cualquier número parece aceptable y ninguna optimización se puede defender con datos.
Cómo documentamos cada mediciónTiempo de respuesta por pantalla y por endpoint
Cuánto tarda el catálogo, el buscador con filtros, el pago y la generación del PDF de factura en condiciones de carga.
Operaciones por segundo y errores bajo carga
Volumen sostenido sin que aparezcan errores 500, timeouts o colas que arrastran todo el sistema.
Consumo de CPU, memoria y base de datos
Dónde se degrada primero: consultas sin índice, sesiones que saturan memoria, integraciones externas sin corte.
Carga en dispositivos reales
Peso de bundle, imágenes sin comprimir y estabilidad visual con Web Vitals en gama media.
Regla: percentil 95 manda. El promedio esconde a los usuarios que más sufren.
Tipos de prueba sin jerga innecesaria
Empezá por carga y pico sobre lo que vende
Para la mayoría de los productos argentinos alcanza con dos pruebas bien diseñadas sobre los flujos que más facturan o inscriben. El resto se agrega cuando aparecen límites concretos. Así se evita una suite enorme que nadie mantiene.
Carga
Verificamos con la cantidad esperada de usuarios. Si esperás 800 concurrentes en una promo nocturna, probamos con 800 más un margen. Incluye navegación, búsqueda y compra completa.
Pico
Simulamos subidas bruscas como las de Hot Sale o la apertura de inscripciones. Rampa rápida de 50 a 2000 usuarios en minutos para ver si el sistema absorbe o colapsa.
Estrés
Subimos hasta que algo se rompe para conocer el límite real. Mejor que se caiga en prueba que en campaña. Registramos el punto exacto de ruptura.
Resistencia
Mantenemos carga moderada por horas para detectar fugas de memoria, conexiones que no se liberan y discos que se llenan de logs.
Escalabilidad
Vemos si agregar recursos mejora de verdad. A veces más servidores no resuelven una consulta bloqueante o un webhook sin timeout.
Escenarios inspirados en uso local
Reproducimos el pico tal como ocurre
Pensá en una tienda que pasa de 50 a 2000 usuarios concurrentes durante una promo nocturna. O en un sistema de turnos que colapsa a las 8 en punto cuando liberan agenda. O en una plataforma educativa con entrega de exámenes a las 23:59. Reproducimos esos patrones con rampas graduales y picos reales.
Operaciones que más pesan
- Búsqueda con filtros sobre miles de productos y pedidos históricos.
- Generación de PDF de factura y consulta de estado de envío y pago.
- Subida de fotos y webhooks que, sin límite de espera, arrastran todo.
Son las operaciones que suelen esconder consultas lentas a base de datos.
Herramientas accesibles
No necesitás una suite cara para la primera evaluación
JMeter y k6 cubren muy bien las pruebas de protocolo y son gratuitas. Para frontend, las auditorías de Lighthouse y las mediciones de Web Vitals ayudan con carga inicial y estabilidad visual. Los proveedores cloud permiten generar carga desde distintas regiones, útil si tus usuarios están repartidos entre AMBA, Córdoba y Mendoza.
Con un plan claro y un ambiente parecido a producción ya obtenés hallazgos accionables. La herramientachain importa menos que el escenario: qué flujos, con cuántos usuarios y durante cuánto tiempo.
Ambiente y datos definen el resultado
Probar en la notebook del desarrollador no dice nada. Necesitás un ambiente similar a producción en recursos y configuración, con datos de volumen realista: miles de productos, historial de pedidos, usuarios con distintos roles.
Aislá el ambiente para que otras pruebas no contaminen la medición. Repetí la prueba al menos dos veces, anotá versión del código, configuración y hora. Sin esos datos, los números no sirven para comparar después de optimizar.
Cómo leer un informe
Dónde se degrada y qué corregir primero
Un buen informe muestra qué escenario se probó, con cuántos usuarios, durante cuánto tiempo, y qué pasó con tiempos y errores. Marca el punto de quiebre: ¿base de datos, API, frontend? Prioriza por impacto: primero lo que bloquea compra o login, después lo secundario.
Incluye gráficos simples de tiempos y errores en el tiempo. Si ves errores 500 a partir de cierto nivel, no es solo poner más servidores. Suele haber una consulta o un bloqueo que hay que corregir en código.
Optimizaciones que aparecen seguido
Listados sin paginación e imágenes pesadas
Paginación faltante, imágenes sin comprimir para mobile y assets sin caché de catálogo. A veces resuelven gran parte del problema sin tocar infraestructura.
Consultas sin índice y sesiones en memoria
Tablas de pedidos sin índice, sesiones que saturan memoria y bloqueos que aparecen solo bajo carga.
Integraciones sin timeout
Envíos, pagos y consultas de estado con webhooks lentos. Medir antes y después evita discusiones.
Rendimiento en móviles
Gran parte del acceso es 4G con señal irregular
Probá con limitación de red, modo ahorro de datos y dispositivos de gama media con poca RAM. Verificá tamaño de bundle, carga diferida de imágenes y comportamiento offline parcial. Una pantalla que pesa 6 MB tarda una eternidad con señal débil en transporte o en el interior.
Reducir peso y mostrar estados de carga claros mejora la percepción aunque el backend tarde lo mismo. Anotá operador, zona y nivel de señal en tus notas para poder comparar entre corridas.
- — Medí tiempo hasta primera interacción, no solo carga total.
- — Revisá saltos visuales y botones que se mueven mientras cargan.
- — Probá login, búsqueda y pago con señal débil sostenida.
Nota de campo
Mismo flujo, tres niveles de señal. El peso manda.
Cuándo hacer las pruebas
Con tres a cuatro semanas de margen para corregir
Hacé una prueba base antes de un lanzamiento o campaña grande, y repetí después de cambios importantes de arquitectura. Para sistemas con picos estacionales como ventas, inscripciones o vencimientos, programá la prueba con tiempo. No la dejes para la noche anterior.
Si no tenés tiempo para una suite completa, al menos medí los tres flujos principales con la carga esperada y documentá los límites encontrados. Un límite conocido se puede planificar; una caída sorpresa, no.
Nuestro alcance
Evaluaciones acotadas, informe priorizado
Hacemos evaluaciones acotadas con escenarios definidos junto a vos, ejecución documentada e informe con hallazgos priorizados. Te decimos hasta dónde llega nuestra medición y qué pedir si necesitás escalar.
No hacemos tuning de infraestructura a gran escala ni pruebas masivas de millones de usuarios. Pedí detalles en Contacto indicando stack, hosting actual y cantidad de usuarios esperada en pico. Con eso proponemos escenarios realistas.
Dudas frecuentes
Preguntas sobre pruebas de carga y estrés
Respuestas directas para planificar ambiente, riesgos y próximos pasos sin sobredimensionar.
Ver todas las preguntas¿Necesito un ambiente igual a producción?
Idealmente similar en recursos y datos. Si no es posible, igual se puede medir de forma comparativa, aclarando las diferencias en el informe. Lo importante es que la comparación antes y después se haga en el mismo ambiente.
¿Qué pasa si la app se cae en la prueba?
Mejor que se caiga en prueba que en Hot Sale. Registramos el punto de ruptura, guardamos evidencia de tiempos y errores, y proponemos por dónde empezar a corregir según impacto en compra, login o inscripción.
¿Cuántos usuarios debo simular?
Partimos de tu pico real esperado: visitas en promo, inscripciones por hora o entregas a las 23:59. Probamos ese nivel y un margen por encima para conocer el límite. Sin ese número, definimos juntos un escenario prudente sobre tus tres flujos principales.
¿Las pruebas afectan a usuarios reales?
No. Trabajamos sobre un ambiente aislado, parecido a producción pero separado. Así evitamos contaminar métricas y evitamos riesgos sobre ventas o turnos en curso.
Cierre y próximo paso
Medí tus tres flujos principales antes del próximo pico
QA Tech Argentina es una guía independiente de calidad para el mercado tecnológico argentino. Contanos stack, hosting actual y usuarios esperados en pico. Proponemos escenarios realistas y un informe que tu equipo puede accionar.
Av. Corrientes 1233, Buenos Aires · Lunes a Viernes 9:00–18:00 · [email protected]
Velocidad de aplicaciones · monitoreo de rendimiento Argentina · test de estrés
Volver al inicio