En el proceso de prueba de automatización de interfaz, ¿cómo llevar a cabo las pruebas de automatización de interfaz? ¿Cómo probar la asociación entre un solo módulo y varios módulos?

(1) ¿Cómo llevar a cabo la automatización de la interfaz?

0. Investigación, preparación de premisas y pensamiento
a) Premisa:
1. Al diseñar casos de uso formalmente, combine herramientas como cartero/jmeter
2. Diseñe diferentes datos de prueba, inicie solicitudes y verifique si los resultados de la respuesta son consistentes con el diseño
3. (Requerido Ir a través de pruebas manuales) -- errores encontrados
b) método de almacenamiento de casos de uso:
1. formulario de Excel - configurar la ruta json
2. archivo json - hay muchos parámetros de solicitud, escritos en el archivo json
3. archivo yaml - httprunner3.0
4 , Base de datos - crear tablas
c)  ¿Qué tal la cobertura de automatización
: cobertura de casos de uso funcional/manual - 30% - 90%
1. ¿Cuánto tiempo lleva automatizando la interfaz de este proyecto?
2. ¿Qué tan grande es el sistema? ¿Es complicado?
3. ¿Cuántos casos de uso de cobertura? ¿Qué dificultades (y soluciones) encontraste?

1. Análisis de requisitos
Comprender las funciones comerciales del proyecto, los módulos con más errores, cuáles son las interfaces relativamente estables y cuáles son las funciones principales

2. Comprender la interfaz
2.1 Mirar la interfaz capturando paquetes
2.2 Comprender a través del documento de la interfaz

3. Selección de marco y herramientas de automatización
3.1 Escalabilidad del trabajo y lenguaje de extensión + selección de varias interfaces complejas para uso de prueba
3.2 Comparación de estructuras de marco
3.3 Especificación de nombres

4. Escribir casos de uso de interfaz
4.1 Escribir guiones de casos de uso de interfaz

• 1. El negocio principal va primero: la tasa de utilización de usuario más alta
• 2. Prioridad del caso de uso: escenarios funcionales comunes/parámetros requeridos
• 3. La validez del formato del parámetro: no se realiza ninguna verificación en el backend
• 4. Los casos de uso normales se diseñan primero, los escenarios anormales (integral)

4.2 Únase a la integración de jenkins lo antes posible
4.3 Informar regularmente sobre el progreso
4.4 Probar informes, enviar informes automáticamente, analizar la causa de la falla del caso de uso
4.5 Registrar la automatización de la interfaz desde el principio hasta el error actual
4.6 Manejo de excepciones

5. Estructura de capa de persistencia
1. Insertar datos directamente en la base de datos

6. Fase de mantenimiento
1. Desarrollar y modificar interfaces, probar sincrónicamente modificar scripts de interfaz
2. Agregar nuevas interfaces, agregar sincrónicamente nuevos casos de uso de interfaz 3. Optimizar
scripts y frameworks diarios

(2) ¿Cómo probar un solo módulo?

Prueba de módulo único: se utiliza principalmente en el trabajo de prueba para verificar la implementación de la interfaz de una sola función comercial o para depurar datos de prueba.

Paso 1: ordenar las cadenas de llamadas ascendentes y descendentes

1) ¿Por qué necesitamos ordenar las cadenas de llamadas ascendentes y descendentes?
En la actualidad, los servicios de back-end de los productos de Internet se implementan básicamente de manera distribuida  . Una interfaz puede llamar a otras interfaces, y también puede ser llamada por otras interfaces. Existen innumerables dependencias entre interfaces.
Obviamente, es imposible hacer un buen trabajo de prueba de interfaz si solo ajusta los parámetros solo. (Los desarrolladores pueden ajustar (tiao) los parámetros de la interfaz por sí mismos, ¿qué más necesitan probar?)
2) ¿Cómo clasificar las cadenas de llamadas ascendentes y descendentes?
1. Mire la wiki del proyecto, los documentos del producto y los documentos de desarrollo
2. Mire el código escrito por el desarrollador, lea el código
3. Resuelva la relación entre las llamadas ascendentes y descendentes y dibuje un diagrama de flujo del sistema. puntos, puede encontrar PM, confirmación de comunicación del desarrollador

Paso 2: escribir casos de prueba de interfaz

Si desea automatizar la interfaz , el caso de prueba de la interfaz también es muy útil.
Aquí hay un ejemplo de un caso de prueba de interfaz:

 

Paso 3: documento de interfaz de prueba e interfaz de depuración

Al comienzo del desarrollo del proyecto, el desarrollo de front-end y el back-end acordarán conjuntamente un conjunto de especificaciones de interfaz, y luego el desarrollo de back-end escribirá los documentos de interfaz, y luego el front-end y back-end pueden llevar a cabo el desarrollo colaborativo de acuerdo con el acuerdo.
Hay varias formas de administrar y editar documentos de interfaz :

• Algunos equipos están acostumbrados a usar wiki o documentos en línea para escribir documentos de interfaz;
• A algunos equipos les gusta usar herramientas de documentación de interfaz profesionales, como: Swagger, Yapi , etc. para generar documentos de interfaz.

La documentación de la interfaz de prueba puede hacer referencia a los siguientes puntos de prueba:

1. Para garantizar que el desarrollo debe proporcionar la documentación de la interfaz . Si el desarrollo no tiene la costumbre de escribir documentos de interfaz, debe presionar al desarrollo para que escriba documentos de interfaz.
2. Verifique si el formato y el contenido del documento de la interfaz están completos , incluidos: URL, método de solicitud, encabezado, parámetros de entrada, valor de retorno, demostración de muestra, etc.
3. Compruebe si el diseño de la interfaz cumple con las especificaciones de la empresa . Incluyendo nombres de interfaz, formato de interfaz, nombres de campo, tipo de campo, código de estado de respuesta, tolerancia a fallas de interfaz, si el campo es redundante, si la interfaz está autenticada, si distinguir versiones, etc.

Cuando el desarrollo de back-end completa el desarrollo de la interfaz, podemos comenzar las pruebas preliminares de la interfaz con anticipación.
Proceder de la siguiente:

1. Implemente el código de back-end en el entorno de prueba .
2. Use cartero o swagger para probar la interfaz mencionada en el documento de la interfaz.

Paso 4: prueba de interfaz frontal y datos simulados (prueba de nivel de interfaz)

Los pasos anteriores son solo para usar la herramienta de prueba para iniciar una solicitud de red para simular la llamada de interfaz.

Pero en un escenario real, la interfaz de la puerta de enlace de búsqueda en realidad se proporciona para que APP/WEB/pequeño programa llame.

También debemos prestar atención a si el proceso de llamadas de front-end es normal . (Debe esperar a que se complete el desarrollo de front-end antes de poder intervenir en la prueba)

Puede usar Charles para capturar las solicitudes enviadas por el front-end,

1. Verifique que los parámetros pasados ​​a la interfaz de llamada frontal sean correctos;
2. Verificar si la respuesta de la interfaz del backend cumple con las expectativas;
3. Después de que el front-end obtenga los datos, si la interacción y la visualización de la interfaz de usuario son correctas.

Cuando algunos datos tienen múltiples estados y los datos son difíciles de construir, podemos usar datos simulados para probar.

Las formas comunes de burlarse de los datos son :

1. Use Fiddler o Charles para manipular solicitudes y respuestas.
2. Si es un lenguaje dinámico como PHP o Python, puede cambiar directamente las condiciones en el código de back-end.
3. Para modificar datos en la base de datos.
4. Use herramientas profesionales de Mock para construir datos, como: EasyMock, TestableMock, Mockjs, etc.

La forma más rápida , por supuesto, es utilizar directamente a Charles para simular .

Paso 5: Cobertura de la lógica empresarial y prueba de la interfaz de back-end (ver registros, códigos)

ver registro

Durante las pruebas comerciales, debemos vigilar el estado del registro de back-end.
A veces, los datos de respuesta de la interfaz son normales, pero el registro de back-end puede estar informando un error,

mira el código

Se recomienda leer el código fuente del desarrollo al realizar pruebas de interfaz.
Leer el código fuente puede brindarle una comprensión más profunda de la implementación de la lógica empresarial.

¿Qué pasa si la cantidad de código es grande?

Déjame contarte un pequeño truco: después de que el desarrollador envíe el código, podemos ver su registro de confirmación en Gitlab , o hacer una diferencia entre su rama de desarrollo y la rama del entorno de producción , para que podamos saber qué ha cambiado.

Paso 6: ajuste del rendimiento de la interfaz (Arthas)

Proceso de solución de problemas  :
(1) Primero intente reproducirlo en la aplicación
(2) Paso a paso para solucionar el motivo de la respuesta lenta de la interfaz a través del seguimiento de Arthas:
ingrese la línea de comando de Arthas

java -jar arthas-boot.jar

El método llamado por la interfaz de seguimiento

trace 类名 方法名

Paso 7: control de versión de interfaz y diffy

Generalmente, la interfaz distinguirá entre versiones.Si la interfaz no está muy estandarizada, o se ha cambiado alguna lógica general, se requiere una prueba de regresión en la versión anterior en este momento.

La forma más estúpida es comparar y probar las versiones anterior y nueva de las dos aplicaciones. También podemos usar la herramienta Diffy para pruebas de regresión.

Paso 8: Comience a automatizar la interfaz

La automatización de la interfaz generalmente se usa en escenarios como la regresión de inspección en línea y la prueba de humo.

Para lograr la automatización de la interfaz, utilice los siguientes métodos:

codificación:

python+pytest+requests se usa actualmente de esta manera. (Pequeño y hermoso, fácil de personalizar)

(3) ¿Cómo probar múltiples asociaciones de módulos?

Asociación de módulo: se refiere a la asociación dinámica de los parámetros de entrada y salida de dos o más API relacionadas en forma de parametrización, para realizar la cobertura de prueba de toda la transacción y lograr la prueba de automatización de interfaz de herramienta básica.

Paso 1: ordenar las cadenas de llamadas ascendentes y descendentes

1) ¿Por qué necesitamos ordenar las cadenas de llamadas ascendentes y descendentes?
En la actualidad, los servicios de back-end de los productos de Internet se implementan básicamente de manera distribuida  . Una interfaz puede llamar a otras interfaces, y también puede ser llamada por otras interfaces. Existen innumerables dependencias entre interfaces.
Obviamente, es imposible hacer un buen trabajo de prueba de interfaz si solo ajusta los parámetros solo. (Los desarrolladores pueden ajustar (tiao) los parámetros de la interfaz por sí mismos, ¿qué más necesitan probar?)
2) ¿Cómo clasificar las cadenas de llamadas ascendentes y descendentes?
1. Mire la wiki del proyecto, los documentos del producto y los documentos de desarrollo
2. Mire el código escrito por el desarrollador, lea el código
3. Resuelva la relación entre las llamadas ascendentes y descendentes y dibuje un diagrama de flujo del sistema. puntos, puede encontrar PM, confirmación de comunicación del desarrollador

Paso 2: escribir casos de prueba de interfaz

Si desea automatizar la interfaz , el caso de prueba de la interfaz también es muy útil.
Aquí hay un ejemplo de un caso de prueba de interfaz:

 

Paso 3: documento de interfaz de prueba e interfaz de depuración

Al comienzo del desarrollo del proyecto, el desarrollo de front-end y el back-end acordarán conjuntamente un conjunto de especificaciones de interfaz, y luego el desarrollo de back-end escribirá los documentos de interfaz, y luego el front-end y back-end pueden llevar a cabo el desarrollo colaborativo de acuerdo con el acuerdo.
Hay varias formas de administrar y editar documentos de interfaz :

• Algunos equipos están acostumbrados a usar wiki o documentos en línea para escribir documentos de interfaz;
• A algunos equipos les gusta usar herramientas de documentación de interfaz profesionales, como: Swagger, Yapi , etc. para generar documentos de interfaz.

La documentación de la interfaz de prueba puede hacer referencia a los siguientes puntos de prueba:

1. Para garantizar que el desarrollo debe proporcionar la documentación de la interfaz . Si el desarrollo no tiene la costumbre de escribir documentos de interfaz, debe presionar al desarrollo para que escriba documentos de interfaz.
2. Verifique si el formato y el contenido del documento de la interfaz están completos , incluidos: URL, método de solicitud, encabezado, parámetros de entrada, valor de retorno, demostración de muestra, etc.
3. Compruebe si el diseño de la interfaz cumple con las especificaciones de la empresa . Incluyendo nombres de interfaz, formato de interfaz, nombres de campo, tipo de campo, código de estado de respuesta, tolerancia a fallas de interfaz, si el campo es redundante, si la interfaz está autenticada, si distinguir versiones, etc.

Cuando el desarrollo de back-end completa el desarrollo de la interfaz, podemos comenzar las pruebas preliminares de la interfaz con anticipación.
Proceder de la siguiente:

1. Implemente el código de back-end en el entorno de prueba .
2. Use cartero o swagger para probar la interfaz mencionada en el documento de la interfaz.

Paso 4: diseño de la escena de la interfaz

Antecedentes : la plataforma existente es relativamente madura para el proceso de prueba automatizado de interfaz única de servicio único, y la demanda de comentarios para la configuración de casos de uso automatizados de servicios cruzados complejos está aumentando. Por lo tanto, se agrega soporte para escenarios de prueba complejos.

¿Qué tipo de caso de uso es adecuado para el escenario
? También puede llamarse flujo comercial, por ejemplo: tome un caso de comercio electrónico, orden de compra-pago-verificar estado de pago-ver permisos-reembolso-verificar estado de reembolso

1. Independientemente de si se trata de aplicaciones cruzadas o no, los pasos tienen fuertes dependencias antes y después
2. Escenarios comerciales centrales, como pedido-pago-rendimiento-reembolso

Con base en los antecedentes anteriores, los puntos de función correspondientes de este proyecto son los siguientes:

• Agregue el concepto de [Scene Set], que es equivalente al [Proyecto] original
• Agregue el concepto de [Escenario de prueba], que es similar al [Conjunto de casos de uso] original
• Desencadenar escenarios de prueba asociados

Paso 5: prueba de interfaz frontal y datos simulados (prueba de nivel de interfaz)

Los pasos anteriores son solo para usar la herramienta de prueba para iniciar una solicitud de red para simular la llamada de interfaz.

Pero en un escenario real, la interfaz de la puerta de enlace de búsqueda en realidad se proporciona para que APP/WEB/pequeño programa llame.

También debemos prestar atención a si el proceso de llamadas de front-end es normal . (Debe esperar a que se complete el desarrollo de front-end antes de poder intervenir en la prueba)

Puede usar Charles para capturar las solicitudes enviadas por el front-end,

1. Verifique que los parámetros pasados ​​a la interfaz de llamada frontal sean correctos;
2. Verificar si la respuesta de la interfaz del backend cumple con las expectativas;
3. Después de que el front-end obtenga los datos, si la interacción y la visualización de la interfaz de usuario son correctas.

Cuando algunos datos tienen múltiples estados y los datos son difíciles de construir, podemos usar datos simulados para probar.

Las formas comunes de burlarse de los datos son :

1. Use Fiddler o Charles para manipular solicitudes y respuestas.
2. Si es un lenguaje dinámico como PHP o Python, puede cambiar directamente las condiciones en el código de back-end.
3. Para modificar datos en la base de datos.
4. Use herramientas profesionales de Mock para construir datos, como: EasyMock, TestableMock, Mockjs, etc.

La forma más rápida , por supuesto, es utilizar directamente a Charles para simular .

Paso 6: Cobertura de lógica empresarial y pruebas de interfaz back-end (ver registros, códigos)

ver registro

Durante las pruebas comerciales, debemos vigilar el estado del registro de back-end.
A veces, los datos de respuesta de la interfaz son normales, pero el registro de back-end puede estar informando un error,

mira el código

Se recomienda leer el código fuente del desarrollo al realizar pruebas de interfaz.
Leer el código fuente puede brindarle una comprensión más profunda de la implementación de la lógica empresarial.

¿Qué pasa si la cantidad de código es grande?

Déjame contarte un pequeño truco: después de que el desarrollador envíe el código, podemos ver su registro de confirmación en Gitlab , o hacer una diferencia entre su rama de desarrollo y la rama del entorno de producción , para que podamos saber qué ha cambiado.

Paso 7: ajuste del rendimiento de la interfaz (Arthas)

Proceso de solución de problemas  :
(1) Primero intente reproducirlo en la aplicación
(2) Paso a paso para solucionar el motivo de la respuesta lenta de la interfaz a través del seguimiento de Arthas:
ingrese la línea de comando de Arthas

java -jar arthas-boot.jar

El método llamado por la interfaz de seguimiento

trace 类名 方法名

Paso 8: Mecanismo de excepción de interfaz (Chaosblade)

Debido a que la interfaz depende de muchos servicios, a menudo es necesario llamar a otras interfaces. Si hay una excepción en el servicio dependiente, debemos considerar si nuestra interfaz es tolerante a fallas o está degradada.

Puede usar Chaosblade para inyectar excepciones. (no obligatorio, pero mejor)

Paso 9: Control de versión de interfaz y diffy

Generalmente, la interfaz distinguirá entre versiones.Si la interfaz no está muy estandarizada, o se ha cambiado alguna lógica general, se requiere una prueba de regresión en la versión anterior en este momento.

La forma más estúpida es comparar y probar las versiones anterior y nueva de las dos aplicaciones. También podemos usar la herramienta Diffy para pruebas de regresión.

Paso 10: Inicie la automatización de la interfaz

La automatización de la interfaz generalmente se usa en escenarios como la regresión de inspección en línea y la prueba de humo.

Para lograr la automatización de la interfaz, utilice los siguientes métodos:

codificación:

python+pytest+requests se usa actualmente de esta manera. (Pequeño y hermoso, fácil de personalizar)