![\"C\u00f3mo](\"https:\/\/www.loadview-testing.com\/wp-content\/uploads\/\/how-to-size-load-tests-lv-1024x682.jpeg\")
<\/p>\n<\/p>\n
El mayor error que cometen los equipos en las pruebas de carga ocurre antes de que se escriba un solo script: eligen el tama\u00f1o de prueba equivocado. Una prueba de carga demasiado peque\u00f1a le da una confianza falsa. Todo se ve en verde en sus paneles, pero cuando el tr\u00e1fico se dispara en producci\u00f3n, aparecen las grietas. Una prueba de carga demasiado grande es igual de mala. Desperdicia tiempo, dinero e infraestructura probando un escenario que nunca ocurre, y termina persiguiendo cuellos de botella fantasma.<\/p>\n
Hay muchas historias aleccionadoras. Por ejemplo, una empresa empresarial lanz\u00f3 un nuevo producto en Black Friday despu\u00e9s de probar solo con 500 usuarios concurrentes porque eso \u201cparec\u00eda seguro\u201d. En minutos tras la promoci\u00f3n en vivo, el tr\u00e1fico se dispar\u00f3 a 2.500 usuarios y la canalizaci\u00f3n de pago colaps\u00f3. En el otro extremo del espectro, una universidad insisti\u00f3 en probar su nuevo portal con 1.000 usuarios, aunque el tr\u00e1fico hist\u00f3rico pico nunca hab\u00eda superado los 5.000. El resultado: facturas infladas en la nube y un mes perdido persiguiendo cuellos de botella que nunca se habr\u00edan desencadenado en la realidad.<\/p>\n
Dimensionar es donde el arte y la ciencia de las pruebas de carga se encuentran. Necesita un n\u00famero que sea lo suficientemente grande para ser significativo, pero lo bastante fundamentado para reflejar la realidad. El problema es que la mayor\u00eda de los equipos no tienen una cifra limpia de \u201cusuarios concurrentes\u201d en sus documentos de proyecto. Muchos optan por un n\u00famero redondo como 500, 1.000 o 10.000 simplemente porque parece autoritario en una diapositiva, y eso no es suficiente.<\/p>\n
En este art\u00edculo, repasaremos tres maneras probadas para dimensionar sus pruebas de carga: 1) impulsado por requisitos, 2) basado en transacciones y 3) basado en anal\u00edticas. Cada uno le da un marco para convertir datos desordenados o incompletos en un tama\u00f1o de prueba defendible: uno que coincida con el tr\u00e1fico de producci\u00f3n en vez de con conjeturas.<\/p>\n
Cuando tiene suerte, sus requisitos ya contienen la respuesta: solo tiene que leer entre l\u00edneas.<\/p>\n
Algunos escenarios lo hacen obvio. Si su empresa planea una asamblea transmitida en vivo donde la asistencia es obligatoria, la concurrencia equivale al n\u00famero de asistentes. Si hay 1.000 empleados, deber\u00eda probar para 1.100 usuarios concurrentes (el n\u00famero de asistentes m\u00e1s un 10% de margen de seguridad). Eso es lo m\u00e1s directo que puede ser.<\/p>\n
Otros eventos son m\u00e1s delicados pero a\u00fan previsibles. Tome un sistema de inscripci\u00f3n a cursos universitarios. Durante la mayor parte del a\u00f1o, el tr\u00e1fico es constante y modesto. Pero el d\u00eda de matr\u00edcula, el sistema sufre. Los estudiantes corren para conseguir plazas en los cursos populares, y el tr\u00e1fico se dispara muy por encima de la l\u00ednea base. Si sabe que hay 10.000 estudiantes y la experiencia le dice que el 90% de ellos acceder\u00e1n al sistema durante la matr\u00edcula, eso son 9.000 usuarios concurrentes. Sume comportamientos como estudiantes que piden a amigos o familiares que inicien sesi\u00f3n desde varios dispositivos, y la concurrencia real puede superar el 100% de la poblaci\u00f3n estudiantil. Una prueba segura podr\u00eda dimensionar el tr\u00e1fico al 200% de los usuarios estudiantiles.<\/p>\n
Esto tambi\u00e9n ocurre en otras industrias. Considere un portal de impuestos gubernamental en abril. El sistema puede tener un uso ligero durante todo el a\u00f1o, pero en el d\u00eda de presentaci\u00f3n, la concurrencia se dispara de forma dram\u00e1tica. O mire una plataforma de venta de entradas para conciertos. Para la mayor\u00eda de los eventos, el tr\u00e1fico se reparte. Pero cuando las entradas de un artista importante salen a la venta a las 10:00 en punto, todos los fans actualizan la p\u00e1gina al mismo tiempo (por no mencionar a los bots que intentan comprar entradas, lo cual es otra cuesti\u00f3n a tener en cuenta). Esos son momentos impulsados por requisitos, y su prueba de carga debe dimensionarse en consecuencia.<\/p>\n
Problemas:<\/strong> Los requisitos a menudo subestiman. Las partes interesadas pueden dar cifras bajas para ser conservadoras en el presupuesto, o pueden no contar con los \u201cobservadores\u201d que inician sesi\u00f3n antes para asegurar plaza, o con bots. Cuestione siempre el n\u00famero, modele el comportamiento de oleadas y a\u00f1ada m\u00e1rgenes.<\/p>\n Regla general:<\/strong> El dimensionamiento impulsado por requisitos funciona mejor cuando el evento es limitado en el tiempo y predecible, con recuentos de participantes claros. En esos casos, los requisitos le dan la l\u00ednea base m\u00e1s defendible.<\/p>\n Cuando los requisitos no le dan un n\u00famero, sus transacciones de negocio lo har\u00e1n. En vez de pensar en t\u00e9rminos de usuarios abstractos, piense en t\u00e9rminos de acciones: pedidos, registros, pagos, cargas, pujas.<\/p>\n Las matem\u00e1ticas funcionan as\u00ed:<\/p>\n Ese es el tama\u00f1o de prueba en este ejemplo: 190 usuarios concurrentes que reproducen los patrones de transacci\u00f3n m\u00e1s ocupados y significativos que su sistema ver\u00e1.<\/p>\n Este m\u00e9todo funciona bien porque relaciona la carga directamente con los resultados de negocio. No solo est\u00e1 probando \u201c190 usuarios\u201d, est\u00e1 validando la capacidad de procesar \u201c160 pedidos pico\/hora m\u00e1s navegaci\u00f3n\u201d. Es un n\u00famero que las partes interesadas entienden y valoran.<\/p>\n Segundo ejemplo:<\/strong> Plataformas de subastas. Suponga que ve un promedio de 10.000 pujas por d\u00eda, con un 40% de esas concentradas en las dos \u00faltimas horas de subastas de alto perfil. Eso son 4.000 pujas en dos horas, o ~2.000\/hora. Si la puja media tarda 30 segundos en realizarse, eso son ~16 usuarios concurrentes pujando. Pero si su proporci\u00f3n de navegaci\u00f3n a puja es 30:1 (com\u00fan en sitios de subastas), necesitar\u00e1 simular casi 500 usuarios para reflejar la carga real. Ese tama\u00f1o de prueba le dice si su sistema puede manejar no solo el pico de pujas, sino la avalancha de navegadores que observan y actualizan listados.<\/p>\n La estacionalidad tambi\u00e9n importa.<\/strong> El comercio minorista no es el \u00fanico vertical con picos. Las plataformas de viajes ven aumentos durante las vacaciones de primavera y festivos. Los portales fiscales se colapsan en abril. Las incorporaciones a SaaS se disparan cuando se cierran nuevos contratos. El dimensionamiento basado en transacciones se adapta a todo esto al vincular la concurrencia a eventos espec\u00edficos del negocio.<\/p>\n Regla general:<\/strong> Use el dimensionamiento basado en transacciones cuando los requisitos sean vagos pero las m\u00e9tricas de negocio est\u00e9n claras. Es preciso, comprensible para las partes interesadas y se traduce directamente en resultados.<\/p>\n Cuando los requisitos son vagos y no tiene datos de transacciones, las herramientas de anal\u00edticas pueden llenar el vac\u00edo. Google Analytics, Adobe Analytics u otras plataformas le dan datos de tr\u00e1fico que pueden traducirse en concurrencia con un poco de c\u00e1lculo.<\/p>\n He aqu\u00ed c\u00f3mo:<\/p>\n Ese es su tama\u00f1o de prueba: 130 usuarios que reflejan el tr\u00e1fico m\u00e1s intenso que han visto sus anal\u00edticas.<\/p>\n Ejemplo:<\/strong> Una empresa SaaS con 500.000 usuarios activos mensuales. Si los usuarios activos diarios son ~10% de ese n\u00famero (50.000), y el 20% inicia sesi\u00f3n durante las horas pico laborales, tiene 10.000 usuarios en la ventana m\u00e1s concurrida. Si la duraci\u00f3n media de sesi\u00f3n es de 15 minutos, eso se traduce en ~2.500 usuarios concurrentes para probar.<\/p>\n Advertencias de precisi\u00f3n:<\/strong> Las anal\u00edticas son mejores que nada, pero no son perfectas. Considere:<\/p>\n A pesar de esos problemas, las anal\u00edticas son un recurso pr\u00e1ctico. Reflejan sesiones de usuario reales, normalizadas entre dispositivos y ubicaciones, y pueden segmentarse por geograf\u00eda o tipo de dispositivo si su plataforma tiene tr\u00e1fico regional o centrado en m\u00f3viles.<\/p>\n Regla general:<\/strong> Use el dimensionamiento basado en anal\u00edticas cuando no haya m\u00e9tricas de negocio disponibles, pero s\u00ed datos de tr\u00e1fico consistentes. Es la forma m\u00e1s pr\u00e1ctica de fundamentar las pruebas en la realidad.<\/p>\n \u00bfY si est\u00e1 empezando con una aplicaci\u00f3n completamente nueva? No tiene requisitos que definan concurrencia, historial de transacciones ni datos anal\u00edticos, lo cual es un problema totalmente distinto.<\/p>\n El error com\u00fan es elegir un n\u00famero redondo como \u201c2.000 usuarios concurrentes\u201d porque parece seguro. Pero ese n\u00famero no tiene sentido si no est\u00e1 ligado al comportamiento esperado.<\/p>\n Un enfoque mejor es proyectar el tr\u00e1fico en t\u00e9rminos de transacciones o sesiones. Si espera 200 cargas por hora, dimensione su prueba para validar eso. Si espera 10.000 registros el d\u00eda del lanzamiento, convi\u00e9rtalos en tr\u00e1fico horario y duraci\u00f3n de sesi\u00f3n. Incluso estimaciones toscas enmarcadas as\u00ed le dan resultados que pueden interpretarse en t\u00e9rminos de negocio: son matem\u00e1ticas que puede modelar o calcular.<\/p>\n Ejemplo:<\/strong> Suponga que su equipo de marketing proyecta 5.000 registros durante la semana de lanzamiento, concentrados por un gran comunicado de prensa. Si asume que el 60% cae el primer d\u00eda, eso son 3.000 registros. Distribuido de forma desigual, con el 40% en las primeras tres horas, son ~1.200 registros. Si la creaci\u00f3n de cuenta toma tres minutos, est\u00e1 mirando ~60 registros concurrentes. A\u00f1ada navegaci\u00f3n y tr\u00e1fico de reintentos, y razonablemente podr\u00eda probar entre 200\u2013300 usuarios concurrentes. Ese n\u00famero est\u00e1 enraizado en suposiciones, pero al menos son expl\u00edcitas y puede refinarlas cuando lleguen datos reales.<\/p>\n Tenga cuidado con las conjeturas porque los gerentes quieren presentar algo de cierta manera.<\/strong> Las partes interesadas pueden presionar por n\u00fameros enormes (\u201cProbemos 50.000 usuarios para mostrar a los inversores que estamos listos para escalar\u201d). Resista eso. Las pruebas sobredimensionadas no generan confianza: crean ruido y desperdicio. Fundamente su dimensionamiento en transacciones proyectadas, aunque sean estimaciones.<\/p>\n El prop\u00f3sito de la prueba de carga no es alcanzar un n\u00famero: es responder a una pregunta. \u00bfPuede su sistema manejar los comportamientos y eventos espec\u00edficos que importan a su negocio?<\/p>\n Y sin importar el m\u00e9todo que use, siempre a\u00f1ada un margen. El tr\u00e1fico real es puntilloso, impredecible y rara vez se alinea con promedios perfectos.<\/p>\n LoadView ayuda a hacer pr\u00e1cticos cada uno de estos m\u00e9todos de dimensionamiento. Con LoadView, puede modelar no solo recuentos de usuarios, sino patrones realistas: tr\u00e1fico en r\u00e1fagas durante la matr\u00edcula, mezcla de navegaci\u00f3n y pedidos, o distribuci\u00f3n global que coincida con sus anal\u00edticas. Eso significa que su prueba no es solo un n\u00famero, es un ensayo para la realidad de producci\u00f3n.<\/p>\n Dimensionar es la primera decisi\u00f3n en cualquier prueba de carga. H\u00e1galo bien, y cada resultado que obtenga despu\u00e9s tendr\u00e1 sentido. H\u00e1galo mal, y ning\u00fan guion ni informe lo salvar\u00e1n. Con los tres m\u00e9todos descritos aqu\u00ed, puede dimensionar sus pruebas con confianza y asegurarse de que sus resultados de rendimiento realmente coincidan con el tr\u00e1fico y la actividad en su sitio o aplicaci\u00f3n.<\/p>\n","protected":false},"excerpt":{"rendered":" Aprenda a dimensionar pruebas de carga con tres m\u00e9todos pr\u00e1cticos. Use requisitos, transacciones y anal\u00edticas para ajustar su prueba al tr\u00e1fico real.<\/p>\n","protected":false},"author":22,"featured_media":93400,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_et_pb_use_builder":"","_et_pb_old_content":"","_et_gb_content_width":"","footnotes":""},"categories":[174,149],"tags":[],"class_list":["post-93358","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-api-testing-es","category-performance-testing-es"],"yoast_head":"\nM\u00e9todo 2: Dimensionamiento basado en transacciones<\/h2>\n
\n
M\u00e9todo 3: Dimensionamiento basado en anal\u00edticas<\/h2>\n
\n
\n
Caso especial: aplicaciones completamente nuevas<\/h2>\n
Tabla resumen: elegir el m\u00e9todo correcto<\/h2>\n
\n\n
\n M\u00e9todo<\/strong><\/td>\n Cu\u00e1ndo usarlo<\/strong><\/td>\n Fortalezas<\/strong><\/td>\n Riesgos\/Desventajas<\/strong><\/td>\n<\/tr>\n<\/thead>\n\n \n Impulsado por requisitos<\/td>\n Eventos predecibles y limitados en el tiempo<\/td>\n Claro, defendible, f\u00e1cil de calcular<\/td>\n Subestimaciones por parte de stakeholders, conflictos<\/td>\n<\/tr>\n \n Basado en transacciones<\/td>\n Aplicaciones existentes con datos de negocio claros<\/td>\n Vincula directamente a resultados, proporciones precisas<\/td>\n Requiere buenas m\u00e9tricas, efectos estacionales<\/td>\n<\/tr>\n \n Basado en anal\u00edticas<\/td>\n Sitios con historial de tr\u00e1fico consistente<\/td>\n F\u00e1cil de calcular, basado en sesiones reales<\/td>\n Bloqueadores, bots, precisi\u00f3n desigual<\/td>\n<\/tr>\n \n Nuevas aplicaciones<\/td>\n Sin historial o datos disponibles<\/td>\n Obliga a hacer suposiciones expl\u00edcitas, a prueba de futuro<\/td>\n Riesgo de conjeturas<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Reflexiones finales sobre c\u00f3mo dimensionar correctamente las pruebas de carga<\/h2>\n
\n