En este artículo
LAS IDEAS CLAVE
- 01
La capacidad se acepta para recorridos, carga y condiciones documentadas; no a partir del número de cuentas registradas.
- 02
Los resultados deben mostrar corrección funcional, tiempos, errores y límites del ambiente utilizado.
- 03
Conservar guiones, versiones y criterios permite revisar las correcciones y los cambios posteriores.
1. Define qué trabajo debe sostener el portal
Antes de cotizar la prueba, describe qué harán las personas cuando el portal entre en operación. Un acceso al menú, una búsqueda con filtros y una solicitud con documentos tienen resultados distintos. Identifica los recorridos que, si se vuelven lentos o fallan, detendrían el trabajo del área. Incluye el inicio de sesión cuando forme parte de la experiencia que se quiere evaluar.
Microsoft recomienda vincular las metas de rendimiento con necesidades reales y documentar los criterios de aceptación antes del ensayo. Microsoft: estrategias de pruebas de rendimiento. Proponemos traducirlo en una ficha por recorrido: quién lo usa, qué acción inicia, qué confirma su término y quién del negocio acepta ese resultado. Esta pauta complementa la evaluación general de una empresa de software.
2. Construye la carga con antecedentes de tu operación
Pide distinguir cuentas registradas, personas activas al mismo tiempo y operaciones que llegan durante un período. Una lista de usuarios habilitados no describe, por sí sola, cómo se concentrará el trabajo. Si hay un sistema anterior, revisa sus registros agregados; si el portal es nuevo, identifica los supuestos con las áreas que lo usarán. No presentes una proyección como demanda observada.
Considera un portal ficticio de solicitudes internas: unas personas consultan estados, otras adjuntan antecedentes y otras aprueban. El ensayo debería representar esa mezcla, sus pausas y los momentos en que coinciden tareas. Deja trazable el origen de cada supuesto y acuerda qué escenario probar si la adopción difiere. El tamaño y duración de la prueba se definen para ese caso; aquí no proponemos cantidades universales.
Decisiones que deben quedar en la propuesta
| Decisión | Evidencia a solicitar |
|---|---|
| Qué trabajo importa | Recorridos críticos y resultado que confirma su término. |
| Qué demanda se representa | Origen de supuestos, mezcla de tareas y forma de llegada. |
| Qué se acepta | Criterios por escenario, métrica y ambiente. |
| Qué se entrega | Resultados, incidencias, limitaciones y material para repetir. |
En pantallas pequeñas, desliza la tabla para comparar.
3. Acuerda qué ensayos responden al riesgo
La documentación de Grafana k6 distingue pruebas de carga habitual, estrés, picos repentinos y uso prolongado. Cada una observa un comportamiento diferente; la selección depende del sistema. También recomienda comenzar comprobando que el guion funciona con carga pequeña. Grafana: tipos de pruebas.
Para contratar, pide una justificación breve de los ensayos incluidos y de los que quedan fuera. En el ejemplo ficticio, el equipo podría evaluar la actividad ordinaria y la concentración de solicitudes al cierre de un proceso. La prueba prolongada serviría si interesa observar deterioro durante el uso sostenido. No conviertas la lista de herramientas del proveedor en el alcance: acuerda qué duda resolverá cada ensayo y qué decisión permitirá tomar.
4. Especifica el ambiente, los datos y las dependencias
Solicita una descripción de la versión del portal, su configuración, la base de datos y los servicios conectados durante la prueba. Microsoft recomienda un ambiente parecido a producción para evaluar rendimiento. Microsoft: preparación del ensayo. Si hay diferencias de capacidad, red o configuración, deben aparecer junto a la interpretación del resultado.
Como condición práctica del encargo, pide datos ficticios que representen variedad de tamaños, búsquedas y estados. Documenta si una dependencia externa se prueba realmente o se sustituye por una respuesta simulada: en este último caso, el informe no puede acreditar su capacidad real. Define también cómo impedir envíos comerciales, cobros o modificaciones de operación durante el ensayo. Los responsables acuerdan dónde se ejecuta, quién puede detenerlo y cómo se deja el ambiente al terminar.
5. Mide el recorrido correcto y su distribución de tiempos
Un promedio puede ocultar solicitudes particularmente lentas. Google SRE explica la utilidad de observar distribución de latencia, tráfico, errores y saturación, y distinguir respuestas exitosas de fallidas. Google SRE: señales de monitoreo. Pide resultados por recorrido y etapa para que una consulta liviana no oculte una aprobación que quedó pendiente.
Un percentil indica el tiempo dentro del cual terminó una proporción de las operaciones medidas. Si el proveedor utiliza percentiles, solicita que explique qué conjunto de operaciones representan y cómo calculó cada valor. El informe debe separar tiempo de respuesta técnica, resultado funcional y finalización de trabajos que continúan en segundo plano. En el portal ficticio, aceptar el archivo no demostraría todavía que la solicitud quedó procesada. Acuerda qué evidencia confirma ese cierre y cómo se cuentan los intentos incompletos.
6. Escribe las condiciones para aceptar, corregir o repetir
Deja los límites acordados en la propuesta antes de ejecutar. Deben identificar el recorrido, la métrica, la carga y el ambiente al que se aplican. k6 permite expresar umbrales que determinan si una prueba pasa o falla. Grafana: umbrales de aceptación. Esa capacidad de la herramienta no decide qué necesita tu empresa.
Proponemos que negocio y TI revisen juntos las condiciones: respuesta correcta, espera admisible para la tarea, tratamiento de errores y recuperación después del escenario. Define quién interpreta un incumplimiento y qué corrección exige repetir la prueba. Si se cambia el ambiente o se reduce la carga para obtener un resultado favorable, el nuevo informe debe decirlo; no debe reemplazar silenciosamente las condiciones originalmente pactadas.
7. Recibe un informe que permita comprobar la conclusión
Solicita un paquete de entrega con guiones y versión de la herramienta, escenarios, configuración, datos utilizados, métricas, incidencias y conclusión por criterio. Debe permitir identificar qué se ejecutó, reproducirlo con los accesos autorizados y comparar resultados. Los registros compartidos no necesitan contener contraseñas ni datos personales; acuerda la forma de entregar evidencia depurada.
La gerencia puede recibir una síntesis con tres decisiones: qué alcance quedó comprobado, qué condiciones siguen pendientes y quién las resolverá. TI conserva el detalle para revisar la conclusión. Cuando una prueba se interrumpe, registra la causa y hasta dónde llegaron los resultados. Un gráfico de actividad sirve como antecedente, pero la aceptación necesita vincularlo con operaciones correctas y con las condiciones contratadas.
8. Conserva una base para comprobar los cambios
Después de corregir un problema, repite los escenarios afectados y conserva las versiones anteriores. Si cambian reglas, datos, infraestructura o una integración importante, revisa qué parte de la evidencia sigue siendo comparable. Acuerda esta responsabilidad dentro del mantenimiento para que la capacidad comprobada no quede como un documento aislado del lanzamiento.
Antes de pedir una propuesta, completa el brief de software e IA con los recorridos críticos y los antecedentes disponibles. En una evaluación de desarrollo de software a medida, esos datos permiten conversar sobre alcance, pruebas y aceptación. Esta guía propone cómo ordenar el encargo; no acredita una capacidad concreta ni sustituye las pruebas de tu portal.
Lista de chequeo antes de autorizar el ensayo
Marca lo que ya revisaste. Las marcas quedan solo en esta página.
Errores comunes
Aprobar capacidad por una demostración individual o un total de usuarios registrados.
Evaluar solo promedios sin distinguir recorridos fallidos o incompletos.
Presentar resultados de un servicio simulado como capacidad del proveedor externo.
Cambiar carga o infraestructura sin registrar el efecto sobre la comparación.
Preguntas frecuentes
¿Cuántos usuarios debería soportar la prueba?
La cantidad debe surgir de la demanda esperada y de cómo se usa el portal. Distingue cuentas, concurrencia y operaciones por período. Pide al proveedor documentar los antecedentes y los supuestos; no existe una cifra universal para todas las empresas.
¿Una prueba de carga demuestra que el portal es seguro?
La prueba evalúa comportamiento bajo una carga y condiciones determinadas. No reemplaza la revisión de permisos, la evaluación de seguridad ni otras pruebas de aceptación. Esos alcances deben definirse y comprobarse por separado.
¿Puede aceptarse una prueba hecha en un ambiente distinto de producción?
Puede aportar evidencia, pero hay que documentar las diferencias y limitar la conclusión a lo comprobado. La propuesta debe aclarar qué representa el ambiente, qué queda pendiente y qué validaciones necesita el destino real.
Guías para evaluar tu proyecto
Si necesitas llevar este tema a tu operación, estos recursos te ayudan a comparar alternativas y preparar el alcance antes de contratar.
CON TEXTO Y CONTEXTO
Fuentes y referencias
- Architecture strategies for performance testingMicrosoft Learn
- Load testing typesGrafana Labs
- Monitoring Distributed SystemsGoogle SRE
- ThresholdsGrafana Labs
Contenido elaborado con asistencia de IA a partir de las fuentes enlazadas. Las recomendaciones corresponden al análisis editorial de Digital Dev. Cómo elaboramos y corregimos nuestros artículos.