Mi nombre es Dasha y soy ingeniero de pruebas durante 4 años. Esto significa que las tareas interesantes que realiza con la emoción de "junio" en busca de nuevas soluciones aparecen cada vez menos. ¡Los mismos proyectos, producciones y casos! ¡No, no juego así! Las pruebas siempre son un desafío, y el deseo de cambiar el mundo para mejor no debe morir. Y una vez que me encontré con este problema: debes probar un simple bot de chat en Telegram.
Antecedentes: fue un inconveniente para nuestro cliente llevar a cabo las acciones de rutina según lo acordado, ya que inicialmente se le envió un enlace a los cálculos necesarios, y cada vez que abrió los indicadores necesarios a través del navegador para su revisión, lo que aumentó el tiempo de operación. Propusimos transferir la lógica al bot de chat para reducir el tiempo de toma de decisiones y facilitar la vida de los empleados del cliente.
Para celebrarlo, decidí abordar este asunto con toda responsabilidad, mostrar el máximo ingenio y simplemente disfrutar del trabajo.
La prueba se realizó utilizando el método de caja negra y gris. Por lo tanto, puede usar toda su imaginación para crear scripts personalizados.
Declaración: un servicio de terceros envía una solicitud SOAP, que debemos procesar y guardar en la base de datos, y luego crear una imagen con los parámetros en forma de tabla y enviarla al usuario para su aprobación. En respuesta, el sistema recibe una confirmación o rechazo junto con un comentario sobre la decisión.
Hay una descripción, lápices afilados, listas de verificación preparadas, galletas todas comidas. Estoy listo para comenzar! Cada segundo nacían nuevas preguntas ...
Stop stop stop! Mantén la calma y comienza a hacer pruebas. Entonces, en orden:
1. ¿De qué forma mostrar la fecha? Siempre hay un problema con la fecha: formato, zona horaria, etc.No pudimos obtener los requisitos exactos de un sistema externo, por lo que decidimos mostrar la fecha en la forma en que se recibió originalmente. Es muy difícil predecir en qué formato se recibirá la fecha (incluso una bola mágica no podría haber hecho esto).
2. ¿Cuánto sufrirá la calidad de la imagen si el mensaje contiene una gran cantidad de información?La calidad de la imagen depende de la cantidad de información recibida del exterior. Telegram en sí mismo reduce la calidad de la imagen. En caso de que haya una gran cantidad de información, al transmitir con un documento, obtendremos la tabla en un formato legible, pero luego el usuario debe usar una aplicación de terceros para abrir el archivo PDF generado. Esto complicará la vida, y a nadie le gustan las dificultades (¡pero a todos les encantan las cookies!). Al mismo tiempo, si envía una imagen, será legible solo cuando se hayan recibido pocos datos, pero el usuario podrá usar la funcionalidad de Telegram para ver la imagen. Decidimos que era mejor dejar la pantalla con una imagen, ya que es más conveniente trabajar con ella y es poco probable que obtenga una gran cantidad de información.
3. ¿Cómo debería responder el sistema si no se ha recibido ningún comentario sobre la decisión?Todo resultó ser bastante simple aquí: guardamos el resultado de la decisión que se envió. Y en una segunda solicitud, le dieron al usuario información sobre la necesidad de completar un comentario sobre la decisión.
4. ¿Cómo debe entender el usuario para qué solución es necesario dejar un comentario si se han recibido varias solicitudes de aprobación seguidas?Aquí se implementó la funcionalidad para que un mensaje que solicite un comentario llegue en forma de respuesta a un mensaje con información básica sobre la solución.
5. ¿Qué debe hacer el sistema si el usuario aún no ha tomado una decisión sobre los mensajes antiguos, pero ya se han recibido nuevos?En este caso, nuestro sistema reenvía el mismo mensaje para su aprobación (¡nadie se atreve a ignorarnos!).
6. ¿Cuántos mensajes podemos aceptar?Para responder esta pregunta, decidí crear un Test Suit simple en SOAP UI. La elección recayó en esta aplicación, ya que tiene un amplio alcance (cubre la verificación de servicios web, simulación, pruebas funcionales, pruebas de carga, etc.).
No le diré cómo crear un traje de prueba simple, ya que ya han escrito lo suficiente sobre esto, me gustaría describir el problema y mi solución.
El problema principal era que para cada nueva solicitud se tenía que generar un nuevo identificador, y este valor generado se reutilizaba dentro del mismo XML.
Se encontró la solución:
En un caso de prueba, se crea una Propiedad con el atributo ID_Calc.
Luego, en la pestaña Configuración del script, pegue el script:
testCase.setPropertyValue ("ID_Calc", nuevo java.util.Random (). nextInt (99999) .toString ())
Después de eso, en la solicitud en sí, en las etiquetas donde se usa el identificador, es necesario escribir:
$ {# TestCase # ID}
Por lo tanto, cada solicitud tenía un identificador único, pero dentro del marco de un mensaje separado, los identificadores eran idénticos.
El trabajo de desarrollo y prueba se llevó a cabo de manera muy rápida y armoniosa, por lo que logramos el resultado lo antes posible. La revisión fue entregada inmediatamente al cliente, y él quedó satisfecho.
¡Incluso desde la tarea más simple y mundana, puedes hacer una búsqueda genial, de la que puedes estar orgulloso! Bueno, si estás aburrido, pero quieres sentimientos vívidos, solo encuentra problemas en tu proyecto y resuélvelos de una manera inusual :)
Buena suerte