¡Hola, Habr! Esta es la secuela de mi , en la que hablaré sobre las opciones para enviar mensajes a las colas con JMeter.
Estamos creando un bus de datos para una gran empresa federal. Diferentes formatos de solicitudes, transformaciones, enrutamiento complejo. Para las pruebas, es necesario enviar muchos mensajes a las colas. A mano es un dolor que no todos los testers pueden soportar.
Introducción
Aunque al principio tuvimos que soportar ese dolor. Todo comenzó con RFHUtil. Poderoso, pero incómodo y aterrador: ya saben de lo que hablo.
Imprescindible en algunos casos, pero que se bloquea constantemente con el uso activo.
No es posible realizar pruebas cómodas con él.
Con JMeter todo se volvió más simple. Después de la primera etapa de aprendizaje y adaptación, brilló una esperanza de pruebas afortunadas.
Uso activamente los muestreadores JMS Publisher y JMS Subscriber. A diferencia de JMS Point-to-Point, esta pareja me parece más conveniente de trabajar. Por ejemplo, en el selector de JMS, el Subscriber puede especificar una variable, pero el Point-to-Point no puede (o este método no es muy obvio).
Preparación de los muestreadores
JMS Publisher
- Configuración — Cada Muestra. Apache usar esta opción si las colas/temas se definen mediante variables.
- Expiration (ms) = 120000. En caso de fallo, las solicitudes de prueba desaparecerán de la cola después de 2 minutos.
- ¿Usar modo de entrega no persistente? — verdadero. IBM , lo que garantiza que el modo persistente proporciona un almacenamiento seguro de los mensajes transmitidos en caso de un fallo repentino. Y un intercambio más rápido en el modo no persistente. Para fines de prueba, la velocidad es más importante.
En cada Publisher establezco una propiedad JMS que el Subscriber utilizará en el Selector JMS. Para cada envío se genera un valor aleatorio en el elemento de plan de prueba User Parameters:
Así podemos estar seguros de que se lee el mensaje correcto.
La "plantilla" final del JMS Publisher preconfigurado:
JMS Subscriber
- Configuración — Cada Muestra. Ya lo entendiste.
- Timeout (ms) = 100000. Si la solicitud no llega a la cola después de 100 segundos de espera, significa que algo salió mal.
- ¿Detener entre muestras? — verdadero.
JMS Selector — una herramienta bastante conveniente ¿Cómo manejar la escritura en cirílico en los mensajes transmitidos? En JMeter, por defecto, se muestra de manera incorrecta después de la lectura. Para evitarlo y disfrutar del gran y poderoso siempre y en todas partes, necesitas:
Agregar al "lanzador" de JMeter el argumento JVM:
- -Dfile.encoding=UTF-8
Agregar un JSR223 PostProcessor en el Subscriber con la línea en groovy: - prev.setDataEncoding("UTF-8")
Transmisión de texto
Transferencia de texto
La opción más perezosa. Ideal para depurar pruebas recién escritas. O para situaciones donde se necesita enviar al menos algo pequeño. Seleccionar opción Fuente del mensaje — Área de texto y colocar el cuerpo del mensaje en el bloque de texto:
Transferencia de archivo
La opción más común. Adecuada para la mayoría de los escenarios. Seleccionar opción Fuente del mensaje — Desde archivo y especificar la ruta al mensaje en el campo Archivo — Nombre del archivo:
Transferencia de archivo en el campo de texto
La opción más versátil. Adecuada para la mayoría de los escenarios + puede usarse en JMS Point-to-Point, donde no hay segunda opción de envío:
Transferencia de arreglo de bytes
La opción más compleja. Adecuada para verificar una transmisión de solicitudes a prueba de errores hasta el byte, sin distorsiones, sms ni perturbaciones. No se puede hacer esto en el JMeter predeterminado, me lo dijeron claramente.
Por eso tuve que descargar y modificar JMS Subscriber.
Reemplacé en el método extractContent(..) la línea:
buffer.append(bytesMessage.getBodyLength() + " bytes recibidos en BytesMessage");a:
byte[] bytes = new byte[(int) bytesMessage.getBodyLength()];
bytesMessage.readBytes(bytes);
try {
buffer.append(new String(bytes, "UTF-8"));
} catch (UnsupportedEncodingException e) {
throw new RuntimeException(e);
}y recompilé JMeter.
Solo queda agregar un par de JSR223 Sampler. El primero — antes de los pares Publisher/Subscriber para crear un archivo DAT que contenga bytes aleatorios:
import org.apache.commons.lang3.RandomUtils;
import java.io.File;
import java.io.FileNotFoundException;
import java.io.FileOutputStream;
import java.io.IOException;
vars.put("PATH_TO_BYTES", "C:temprandomBytes.dat");
File RESULT_FILE = new File(vars.get("PATH_TO_BYTES"));
byte[] arr = RandomUtils.nextBytes((int)(Math.random()*10000));
try {
FileOutputStream fos = new FileOutputStream(RESULT_FILE);
fos.write(arr);
fos.close();
} catch (IOException e) {
System.out.println("archivo no encontrado");
}El segundo — al final del escenario, elimina el archivo:
import java.io.File;
File RESULT_FILE = new File(vars.get("PATH_TO_BYTES"));
RESULT_FILE.delete();Y no olvidar agregar la ruta al archivo en Publisher:
Y también una verificación en JSR223 Assertion para Subscriber — comparar los bytes originales con los que llegan a la cola del receptor:
import java.nio.file.Files;
import java.nio.file.Path;
import java.nio.file.Paths;
import java.util.Arrays;
Path path = Paths.get(vars.get("PATH_TO_BYTES"), new String[0]);
byte[] originalArray = Files.readAllBytes(path);
byte[] changedArray = ctx.getPreviousResult().getResponseData();
System.out.println(changedArray.length);
if (Arrays.equals(originalArray, changedArray))
{
SampleResult.setResponseMessage("OK");
} else {
SampleResult.setSuccessful(false);
SampleResult.setResponseMessage("La comparación falló");
SampleResult.setResponseData("Los bytes han cambiado","UTF-8");
IsSuccess=false;
}Conclusión
He descrito cuatro formas de enviar mensajes en una cola que uso diariamente en la práctica. Espero que esta información le facilite la vida. En el futuro, planeo contar sobre mi experiencia en las pruebas de intercambio, donde en un extremo hay una cola y en el otro, una base de datos o un sistema de archivos.
Cuida tu tiempo. Y gracias por tu atención.
Fuente: habr.com
