Ir al contenido

Parámetros de consulta

Puedes escribir los parámetros de consulta directamente en la URL de una solicitud o añadirlos uno a uno en Query Params (haz clic en Cabeceras, cuerpo, cookies… debajo de la URL de la solicitud para ver el botón):

https://www.example.com?query1=value1&query2=value2
https://api.example.com/v2/resources/1?query1=value1&query2=value2

La URL y la lista Query Params siempre muestran los mismos parámetros. Cuando escribes una URL que contiene una cadena de consulta, LoadFocus copia los parámetros a la lista Query Params y sustituye las filas que había. Cuando editas una fila, reescribe la URL para que coincida. Un fragmento como #hash1 no se conserva: nunca se envía a un servidor.

Parámetros de consulta

Nota: no puedes hacer global un Query Param (por ejemplo una clave de API) y usarlo en todas las solicitudes. Añade el parámetro a cada solicitud que lo necesite.

Para codificar un valor con porcentajes antes de pegarlo, usa la herramienta gratuita para codificar y decodificar URL.

Por qué los parámetros de consulta importan en una prueba de carga

Sección titulada «Por qué los parámetros de consulta importan en una prueba de carga»

Los parámetros de consulta forman parte de la URL de la solicitud, así que el servidor, y lo que haya delante de él, como una CDN, un proxy inverso o un WAF, los trata como parte de lo que se le pide. Esto importa de dos maneras:

  • Enrutamiento y filtrado: muchas APIs usan parámetros de consulta para elegir un recurso, una página o un filtro (?page=2, ?status=active, ?locale=en). Si tu prueba solo envía una combinación, solo pruebas una ruta de código. Un endpoint de búsqueda rápido para ?q=shoes puede comportarse de forma muy distinta con ?q= (vacío) o con una consulta con muchos filtros a la vez.
  • Caché: una CDN o un proxy inverso suele usar la URL completa, cadena de consulta incluida, como clave de caché. Un parámetro que cambia en cada solicitud (una marca de tiempo para saltarse la caché, un id aleatorio) puede convertir un endpoint cacheable en uno que falla la caché para cada usuario virtual. El backend parece entonces mucho más lento y cargado de lo que lo haría el tráfico real, y la causa es la propia cadena de consulta.
  • Los caracteres especiales necesitan codificación. Los espacios, los ampersands y otros caracteres reservados dentro de un valor deben codificarse con porcentaje (un espacio como %20, un & como %26). Introduce el valor ya codificado en una fila de Query Params: LoadFocus lo añade a la URL tal como lo escribiste y no lo codifica por ti.
  • Las claves repetidas se envían todas. Si añades la misma clave dos veces (por ejemplo dos filas query1), se envían ambas. Algunos servidores conservan solo un valor por clave, así que prueba la estructura exacta de solicitud que esperas en producción.
  • Un mismo valor para todos los usuarios. Cada usuario virtual envía tal cual, en cada iteración, el valor que escribes en una fila. Si el endpoint espera un valor distinto en cada llamada (un cursor de paginación, un id de pedido único, un token de un solo uso), un valor fijo solo prueba ese caso, no la variedad de valores que envía el tráfico real.

Para la configuración completa de una solicitud, consulta Cómo ejecutar una nueva prueba de carga. Para comprobar que la propia URL es válida, consulta Qué es una URL válida para una prueba de carga.