¿Se puede enviar el informe de prueba una vez finalizado el desarrollo? ¡Una guía de pruebas de automatización de interfaces fácil de completar!

Escenario de aplicación

El desarrollo aún no ha finalizado, estas son las verificaciones sobre el servicio, ¿cómo sincronizar las pruebas? Tan pronto como se configura el servidor, se requiere la prueba para enviar un informe, ¿son horas extras?

Las pruebas parecen ser posteriores al trabajo: sólo después de que se desarrolle la versión o se configure el servidor se podrán tomar medidas reales. Y a menudo en esta etapa también llega la fecha para que el sistema (programa) entre en línea. Realmente no es necesario hacerlo en la etapa inicial, pero es agotador en la etapa posterior.

Esta vez utilizamos algunas herramientas (MockServer, Rest Assured) para implementar pruebas de API (interfaz) prospectivas antes de que se inicie el servidor. Y cuando se inicia el servidor real, solo necesita conectar el código de prueba al servidor real para ejecutarlo.

Recordatorio: si desea seguir el ejemplo, asegúrese de configurar las siguientes herramientas.

El caso de uso es principalmente combinar las funciones básicas de Rest-Assured y MockServer para realizar pruebas de API preautomatizadas. Para aquellos que no conocen Rest-Assured, hagan algunos deberes adicionales (pueden consultar Rest-Assured En el artículo que escribí antes hay pasos detallados de configuración y aplicación, y MockServer también tiene artículos básicos ).

  • IDE: IDEA IntelliJ

  • Idioma: Java

  • Desarrollo de pruebas API: tenga la seguridad

  • Servidor API: MockServer

  • Marco de prueba: TestNg

  • Tipo de proyecto: Maven

enfoque en el conocimiento

Aplicación MockServer: verifica la solicitud recibida por el servidor

Tenga la seguridad: simule solicitudes de API

Configuración del proyecto Maven

Configure MockServer, tenga la seguridad de estar en POM.xml.

Como se muestra en la siguiente figura: MockServer y rest-Assured deben introducirse correctamente en el nodo <dependencia> de pom.xml.

Consejo: si la dependencia no se carga automáticamente, puede cargarla manualmente y se descargará el paquete jar correspondiente.

Servidor simulado:

imagen

Está seguro:

imagen

Descomposición de casos de prueba

caso de prueba

La siguiente descripción del caso de uso debería resultarle familiar. Es una descripción típica de BDD. Aquí escribo los parámetros y la solicitud de verificación juntos para facilitar esta explicación. El entorno real puede separar los datos de la escena, lo que será más claro.

Dado: el servidor API se está ejecutando

Cuándo: el servidor recibe una solicitud de la API (dirección de API: http://localhost:10800/testing.retry/{id})

Y: El parámetro es "?testParameter=false"

Y:(header)头字段:headerId="id"; headerVersion="versión"; encabezadoNombre="nombre"

Luego: Verifique que el servidor recibió la solicitud correcta

Ejemplo: veces: 1,

(encabezado)头字段:headerId="id"; headerVersion="versión"; encabezadoNombre="nombre"

Parámetro: "?testParameter=false"

Y: Verificar el código de respuesta del servidor (200)

análisis de casos de uso

Primero, cree un servidor que acepte la API y pueda responder con un 200 a las solicitudes de API elegibles.

Dirección: http://localhost:10800/testing.retry/{id}

Parámetros: ?testParameter=false

(encabezado)头字段:headerId = "id"; headerVersion = "versión"; encabezadoNombre = "nombre";

Cuando el servidor recibe la solicitud, debe verificar que haya recibido la solicitud correcta, que el número de solicitudes sea 1 y devuelva 200.

1. Rest-Assured puede verificar la respuesta del código.

2. MockSever verifica los datos recibidos por el servidor.

Con el entendimiento anterior, ahora vienen los pasos de implementación:

1. Servidor API: MockServer.

2. Crear expectativas de respuesta API (expectativas activas) - MockServer.

3. Simule la solicitud: tenga la seguridad de y verifique el estado de la devolución.

4. Verifique la cantidad de solicitudes, parámetros y campos de encabezado: MockServer.

5. Cierre MockerServer.

Consejo: Este paso es muy importante para organizar las pruebas posteriores y organizar el código de prueba de forma sistemática y lógica.

Script de caso de uso de TestNg

De acuerdo con el análisis anterior, veamos la implementación del código paso a paso.

Consejo: este ejemplo utiliza Java + Maven + testNg (si no está familiarizado con esta combinación, puede leer mis artículos básicos relacionados ).

El script de prueba completo se muestra en la imagen siguiente.

imagen

Código detallado

1. Parámetros globales

Podemos definir la información compartida como variables, y el alcance de la aplicación considerada se puede definir como variables locales o variables globales.

¿Qué debo hacer si no puedo determinar cuál define las variables locales o las variables globales?

Sugerencia: este problema se encuentra al comenzar a escribir código de prueba; incluso una persona experimentada tendrá el mismo problema. No se preocupe por esto, normalmente lo escribiré primero como una variable local o como una variable fija sin definir la variable. Al final, cuando el código de un caso de uso esté escrito por completo, quedará claro de un vistazo al verificar el código que están definidas variables locales o variables globales.

String headerId = "id";
String headerVersion = "version";
String headerName = "name";
String queryParameter = "testParameter";
String queryParameterValue = "false";
String baseURI = "http://localhost:10800";
int requestTime = 1;
private ClientAndServer mockServer;

2. Servidor API: servidor simulado

Como se muestra en la imagen: primero creamos un método startMockServer(), este método es para iniciar un MockServer en el puerto 10800. La dirección predeterminada es esta máquina: http://localhost:10800. La variable MockServer es llamada por otros métodos. Las variables globales se definen aquí.

private void startMockServer() {
    mockServer = startClientAndServer(10800);
}

3. Crear expectativas de respuesta API (expectativas activas) - MockServer

Como se analizó anteriormente, necesitamos que el servidor API responda con 200 a las siguientes solicitudes.

Nota: El {id} de la dirección de solicitud es una variable y la variable pathId está parametrizada en el código.

El método mockServerActiveExpectations () inicia el servidor API y crea expectativas de respuesta API (expectativas activas).

Dirección: http://localhost:10800/testing.retry/{id}

Parámetros: ?testParameter=false

(encabezado)头字段:headerId = "id"; headerVersion = "versión"; encabezadoNombre="nombre"

imagen

La aplicación simuladaServerActiveExpectations():

startMockerServer() inicia el servidor API http://localhost:10800.

El código mockServer.when(request().withPath.... es para crear expectativas activas, estas son la sintaxis estándar de MockServer, no se preocupe por no entenderlo, simplemente pruébelo.

imagen

4. Solicitud simulada: tranquilidad, código de respuesta de verificación 200

imagen

Esta es la sintaxis de rest-Assured: en pocas palabras, simula el comportamiento del usuario y envía una solicitud de API al servidor http://localhost:10800/.

Nota: El encabezado (campo de encabezado) son todos datos de prueba y todos usan "prueba".

log().all: solo para depurar, se puede eliminar o conservar más tarde.

5. Verifique la cantidad de solicitudes, parámetros y campos de encabezado - MockServer

imagen

Para que el código sea conciso y fácil de leer, y al mismo tiempo sea reutilizable, aquí se presenta un método de verificación separado.

verificarReceivedRequestDataAndTimes(), a través del código, podemos ver que aquí se verificará la ruta, los parámetros, los métodos, los datos específicos del campo del encabezado y el número de solicitudes recibidas.

No te preocupes, estas también son sintaxis de MockServer.

imagen

6. Cierra el servidor simulado.

No lo olvides, este paso también es crítico. El entorno de prueba es muy importante, especialmente cuando tienes un conjunto de casos de prueba. Los problemas causados ​​por no limpiar el medio ambiente son innumerables.

imagen

imagen

ejecución de caso de uso

Bien, primero probemos los resultados. Aquí lo ejecuto directamente en el IDE.

Abra el panel de MockerSever al mismo tiempo: http://localhost:10800/mockserver/dashboard

Consejos: El código se ejecuta muy rápido. Para capturar los registros del panel, agregue un tiempo de espera de 20 segundos antes de que el código cierre MockerSever.

imagen

Para aquellos que no entienden cómo ver este panel, pueden consultar mi artículo anterior sobre configuración y construcción de MockServer para obtener una introducción detallada.

imagen

La siguiente figura muestra el resultado de la verificación de la solicitud de MockerSever.

1. Detalles de la solicitud de verificación;

2. Número de solicitudes de autenticación.

imagen

Los datos de la solicitud API simulada por rest-Assured se pueden ver en el registro del código en ejecución, como se muestra en la siguiente figura:

imagen

Comprobación de errores y optimización de código.

Ahora hacemos algunas pruebas negativas para verificar que este caso de uso pueda detectar errores bajo la solicitud y expectativa "incorrectas".

Verificamos que el servidor API recibió 2 solicitudes

imagen

Después de ejecutar el código, obtendremos el siguiente error: Esperábamos que el servidor recibiera 2 solicitudes, pero en realidad recibió 1 solicitud, por lo que el error informó que no se encontraron 2 solicitudes coincidentes.

imagen

Haga clic para ver la diferencia, el lado derecho de la nueva ventana muestra la solicitud real recibida por el servidor (solo una vez). Se pueden ignorar otras diferencias ya que aquí no hay validación.

imagen

Según este cambio, si ve el panel, no podrá ver la información de verificación. El código de validación falla y todo el script se detiene.

Así que mejoramos verificarReceivedRequestDataAndTimes() y agregamos try...catch..

Nota: Este método se cambia para devolver un valor booleano, porque necesitamos este valor booleano para verificar el éxito y el fracaso del caso de prueba. De lo contrario, la validación de la prueba muestra un error, pero el caso de prueba se ejecuta correctamente. Consulte SoftAssert que se describe a continuación.

imagen

Ejecute el código nuevamente: el panel puede mostrar la información del error de verificación.

imagen

El método de verificación agrega SoftAssert, de modo que el código encuentra una falla de verificación y continúa ejecutándose. También agregue afirmarTodo() al final. De esta forma, la validación falla y el caso de uso falla.

imagen

Para poder verificar dónde está el error de un vistazo en el resultado de ejecución, mejore try..catch.. para imprimir el error (aquí uso imprimir, se recomienda usar Iniciar sesión en el entorno real). De esta manera, se comprende que la verificación falla, el caso de uso falla y el motivo del error.

imagen

Comprobamos que el encabezado no coincide

Por ejemplo, esperamos que el valor del headerId de la solicitud sea "ID", pero la solicitud recibida por el servidor es "prueba".

imagen

Los resultados del error de verificación son los siguientes:

imagen

Resumir

Bueno, esto completa cómo poner un elefante en el frigorífico, ¡no es difícil!

Cuando el servidor real está en línea, solo necesita señalar la solicitud de descanso asegurado al servidor de prueba real y comentar el MockServer, incluso si el jefe quiere informar el mismo día, podemos entregarlo.

Lo anterior es una introducción. Lo más importante es utilizar varios tipos de herramientas de prueba para satisfacer sus propias necesidades de prueba. Todos los grandes evaluadores pueden aplicarlo de manera flexible y sacar inferencias de una instancia.

Finalmente: el video tutorial completo de prueba de software a continuación se ha ordenado y subido, y los amigos que lo necesiten pueden obtenerlo ellos mismos [Garantizado 100% gratis]

Documentación de la entrevista de prueba de software

Debemos estudiar para encontrar un trabajo bien remunerado. Las siguientes preguntas de la entrevista son los últimos materiales de entrevista de empresas de Internet de primer nivel como Ali, Tencent y Byte, y algunos jefes de Byte han dado respuestas autorizadas. Termine este conjunto Los materiales de la entrevista Creemos que todos pueden encontrar un trabajo satisfactorio.

Supongo que te gusta

Origin blog.csdn.net/wx17343624830/article/details/132669691
Recomendado
Clasificación