En comparación con la prueba funcional del punto de partida, la "prueba de interfaz" es profesional y alta, lo que hace que algunos probadores junior sean "desalentadores". No se preocupe, de hecho, la prueba de interfaz también es un tipo de prueba funcional, que es una prueba funcional para interfaces.
Escrito en el frente: este artículo se refiere al "Avance y práctica de la tecnología de pila completa para ingenieros de prueba" escrito por el Sr. Ru Bingsheng, y se elimina y complementa según mi propio entendimiento.
1. ¿Qué es la prueba de interfaz?
La interfaz del software se refiere a la interfaz para la interacción entre los diferentes módulos del software.Lo que solemos llamar API (Interfaz de programación de aplicaciones) es el acuerdo para la conexión entre los diferentes módulos del sistema de software.
La prueba de interfaz es la prueba de la interfaz de cada módulo del software.
2. ¿Por qué debemos prestar atención a las pruebas de interfaz?
En los últimos años, la escala del software se ha vuelto cada vez más grande, y el sistema de software se ha vuelto cada vez más complejo.La robustez y la tolerancia a fallas del sistema no se pueden garantizar solo a partir de la prueba de la interfaz de usuario, y cuanto antes se presente el problema se encuentra, menor será el costo de reparación. La siguiente figura es un modelo de pirámide de prueba de software tradicional propuesto por Mike Cohn:
El modelo de la pirámide nos dice:
Cuanto más bajo sea el nivel de prueba, más fácil será localizar el problema;
Cuanto mayor sea el nivel de prueba, mayor será el costo de mantenimiento;
Cuanto mayor sea el nivel de prueba, mayor será el costo de reparación.
Sin embargo, dado que los productos de Internet buscan funciones rápidamente y se conectan en línea, básicamente no hay tiempo adicional para que los desarrolladores o evaluadores realicen suficientes pruebas unitarias; el tiempo para las pruebas unitarias está reservado en el tiempo, y las iteraciones frecuentes también harán que las pruebas unitarias sean de bajo nivel. .El estado de escritura constante. Por lo tanto, las pruebas unitarias de productos de Internet también tienen ciertas estrategias específicas, que generalmente cubren las pruebas unitarias de módulos centrales con negocios y servicios relativamente estables. En este caso, las pruebas de API se vuelven especialmente importantes. Las razones principales son las siguientes:
- La eficiencia de desarrollo, depuración y ejecución de los casos de prueba de API es relativamente alta
- La API es relativamente estable
- La estabilidad de ejecución de los casos de prueba de API es mucho mayor que la de las pruebas de GUI
- Muchos productos de Internet ahora adoptan la arquitectura de microservicios Bajo esta arquitectura, si la prueba API de cada servicio se realiza bien, la calidad del producto en general estará garantizada.
Por lo tanto, los productos de Internet generalmente adoptan una estrategia de prueba en forma de diamante:
3. ¿Cuáles son los beneficios de las pruebas de interfaz?
La sección anterior introdujo por qué debemos prestar atención a las pruebas de interfaz ¿Cuáles son los beneficios de hacer pruebas de interfaz?
Realice el desplazamiento de la prueba hacia la izquierda.
La prueba GUI de la interfaz de usuario es para simular el comportamiento de usuarios reales que utilizan el software. Se encuentra en la parte superior de la prueba. Después de encontrar un problema, el costo de localizarlo y repararlo es relativamente alto. Las pruebas de API pueden realizar el cambio a la izquierda de la prueba, es decir, los proyectos separados de front-end y back-end. Cuando se completa el desarrollo de back-end, la prueba de interfaz se puede llevar a cabo sin esperar al front-end. Puede garantizar que los problemas se detecten lo antes posible y que se reduzca el costo de reparar los problemas.
Reducir el costo de mantenimiento
En comparación con la interfaz de usuario, la interfaz es relativamente estable y el costo de mantenimiento es bajo
para mejorar la eficiencia de la prueba.Por
un lado, debido a que la interfaz no depende de ninguna operación en la interfaz durante la ejecución, su estabilidad de ejecución es mucho mayor que el de la GUI, por lo que se puede automatizar y mejorar. Eficiencia de prueba;
por otro lado, algunos casos de uso de interfaz de uso común se pueden convertir en pequeñas herramientas (o ejecutar scripts directamente), y algunos datos de preparación y construcción los escenarios durante el proceso de prueba se pueden usar directamente; además, es necesario repetirlos
Los escenarios de regresión ejecutados pueden ejecutar directamente los casos de uso.
Propicio para la ubicación de errores
Obviamente, los problemas que se encuentran a través de la interfaz son problemas de back-end, y puede encontrar directamente al desarrollador responsable de la interfaz; si el problema solo se encuentra en la interfaz de usuario, puede encontrar directamente al desarrollador de front-end . Esta estrategia de prueba puede aclarar el alcance de los errores, reducir el costo de la ubicación de errores
y garantizar la seguridad, la solidez y la tolerancia a fallas del sistema.
Algunas entradas que no se pueden realizar a través de la interfaz de usuario se pueden realizar fácilmente a través de la interfaz. Por ejemplo, en lo que es el pensamiento de prueba: las habilidades básicas de los ingenieros de prueba, el ejemplo del pago del saldo de WeChat es de la escena:
Solo desde la interfaz de usuario, no se pueden ingresar números negativos y números no completos; pero desde el punto de vista de la interfaz, estos valores se pueden usar como parámetros de entrada.
4. ¿Cómo diseñar y organizar casos de prueba de interfaz?
Primero, aclare el alcance de las pruebas de interfaz. Como se mencionó en la segunda sección, debido a la "rapidez" de Internet, las pruebas de API se han vuelto particularmente importantes. ¿Pero no es necesario probar todas las API? --No. Al igual que las pruebas unitarias, las pruebas de API también deben tener en cuenta el rendimiento de los costos, por lo que generalmente elegimos módulos comerciales centrales para las pruebas de API. Dado que los módulos centrales de diferentes negocios son diferentes, no se discutirán aquí.
Recién presentado, la prueba de interfaz es una prueba funcional para la interfaz. Por lo tanto, los principios de diseño de casos de uso de las pruebas de interfaz y las pruebas funcionales son los mismos: el análisis de escenarios debe usar el pensamiento de prueba de manera flexible (qué es el pensamiento de prueba: las habilidades básicas de los ingenieros de prueba), los métodos de diseño de casos de uso comúnmente utilizados son la división de clase de equivalencia, límite valor, etc. (Debe aprender para comenzar con las pruebas de software: cómo diseñar casos de prueba). ¿Cuáles son las diferencias entre los dos?
1) Los objetos de prueba son diferentes
Pruebas funcionales: prueba principalmente las funciones específicas de la aplicación
Prueba de interfaz: prueba principalmente si la entrada y la salida de la interfaz entre los módulos de la aplicación cumplen con las expectativas
2) El propósito de la prueba es diferente
Pruebas funcionales: garantizar que la funcionalidad específica de la aplicación sea coherente con el documento de requisitos
Prueba de interfaz: pruebe si la entrada y la salida de la interfaz entre los módulos de la aplicación cumplen con las expectativas y si la interacción con otros módulos es correcta
3) El enfoque de la prueba es diferente
Pruebas funcionales: enfoque en la interfaz de usuario y la funcionalidad
Pruebas de interfaz: enfoque en la lógica de negocios
4) Diferentes herramientas de prueba
Pruebas funcionales: principalmente operación directa manual de la interfaz de usuario
Pruebas de interfaz: necesita usar herramientas de prueba de interfaz, como cartero, jmeter, etc., más para implementar conjuntos de pruebas basadas en código
5) Las extensiones de prueba son diferentes
Pruebas funcionales: la interfaz de usuario cambia con frecuencia y se pueden realizar suficientes pruebas exploratorias
Pruebas de interfaz: la interfaz es relativamente estable, lo que favorece la automatización para garantizar la lógica comercial. Por ejemplo, la refactorización de la interfaz de usuario, si la interfaz permanece sin cambios, la interfaz de usuario se puede cambiar a voluntad y, al mismo tiempo, la automatización de la interfaz implementada se utiliza para garantizar la lógica comercial. Pero la "automatización" en sí misma no escala y no puede reemplazar las pruebas exploratorias con pruebas manuales.
4.1 Prueba de una sola interfaz
A través de las secciones anteriores, hemos aprendido que la interfaz es el acuerdo entre diferentes módulos del sistema de software. Por lo tanto, las pruebas de interfaz están más estandarizadas, generalmente tres pasos estándar:
- Preparar datos de prueba
- hacer una solicitud
- Verificar el resultado de la respuesta
Los puntos a los que se debe prestar atención durante las pruebas de interfaz son:
- Dirección URL: URL de interfaz específica
- Método de solicitud: GET, POST, PUT, DELETE, etc.
- Encabezado de solicitud (Header): La información del encabezado que se lleva al enviar la solicitud. Por lo general, alguna información de autenticación: autenticación/cookie, formato de datos de respuesta: tipo de contenido, etc. Por supuesto, los datos de respuesta también devolverán información de encabezado.
- Parámetros de solicitud (Parámetro): GET está en forma de pares clave-valor, y los parámetros POST están en el cuerpo
- Contenido de respuesta (Response): el código de retorno y el contenido de retorno de la interfaz, es decir, la salida. Esta parte generalmente se verifica.
4.2 Prueba de múltiples interfaces
En escenarios comerciales reales, por lo general, una sola operación de front-end puede desencadenar una serie de llamadas de API de back-end, por lo que los casos de prueba de API generalmente no son una sola llamada de API, sino una serie, y a menudo deben usarse en la última llamada de API. El resultado devuelto por una llamada a la API también debe determinar qué API se debe llamar más adelante en función del resultado devuelto de la llamada a la API anterior. Por lo tanto, la resolución de estos dos problemas afecta directamente la realización de casos de prueba de múltiples interfaces.
¿Cómo obtener de manera eficiente la secuencia de llamadas a la API desencadenadas por una sola operación de front-end?
Pregúntele al desarrollador
Este es el método más directo. Pero a menudo preguntarle a uno molestará a los desarrolladores, y el otro parecerá que no somos lo suficientemente profesionales.
Leer y desarrollar código
requiere cierta base de programación
3. Consulte los documentos de diseño detallado del desarrollador
Generalmente, los documentos de diseño detallado más estandarizados o los documentos de interfaz tendrán diagramas lógicos de negocios que indican la secuencia de llamadas entre interfaces.
4. Captura de paquetes
Puede usar herramientas de captura de paquetes como Fiddler para obtenerlo usted mismo sin depender de los desarrolladores.
5. Ver registros
A través de registros basados en el comportamiento del usuario, se pueden obtener secuencias de llamadas a la API.
¿Cómo usar el resultado devuelto por la llamada API anterior en la última llamada API?
La inspección manual
es naturalmente posible, pero la eficiencia es relativamente baja.
Implementación automatizada
La estandarización de la interfaz permite la automatización de la verificación y referencia de los resultados, lo que no solo puede verificar el proceso comercial, sino también mejorar la eficiencia de la verificación.
Si usa cartero, puede generar automáticamente códigos de verificación. Sin embargo, cuando es necesario ejecutar con frecuencia una gran cantidad de casos de prueba, las pruebas API basadas en interfaz, como Postman, no pueden satisfacer las necesidades. Entonces surgió un marco de prueba de API basado en código. Los típicos son OkHttp y Unirest basados en Java, http.client y Requests basados en Python, Native y Request basados en Node.js, etc. Algunas grandes empresas también desarrollarán su propio marco de prueba de API en combinación con su propio negocio. Cada marco tiene sus propias ventajas y desventajas, y las ideas están interrelacionadas. La idea general es la siguiente:
Se extrae el proceso principal del negocio, y cada proceso principal corresponde a un conjunto de pruebas, es decir, el conjunto de pruebas se
puede agregar al conjunto de pruebas del proceso principal para algunos escenarios anormales, que no afectarán el resultado final; a El conjunto de pruebas también se puede establecer por separado para reducir el impacto de la interferencia con el proceso comercial principal;
los parámetros que admiten múltiples valores se pueden cruzar en diferentes conjuntos de pruebas (método experimental ortogonal)
5. Preguntas comunes de la entrevista
- ¿Qué interfaz de protocolo se utiliza en el proyecto?
- Consejo: Generalmente, hay HTTP, HTTPS, RPC, etc. Luego continuaré haciendo preguntas basadas en las respuestas ~
- ¿Qué métodos de solicitud tiene la interfaz HTTP?
- Consejos: comúnmente utilizados GET, POST, PUT, DELETE, etc.
- El código de retorno de la interfaz HTTP
- Consejos: 2xx, 3xx, 4xx, 5xx
- ¿Cuáles son los beneficios de las pruebas de interfaz?
- ¿Cómo se realizan las pruebas de interfaz?
- Consejo: Vuelva al proceso y al diseño.
- ¿Cuáles son los encabezados de solicitud de uso común y para qué sirven los encabezados de solicitud?
- La diferencia entre cookie y sesión, UA, etc.
- ¿Cómo distinguir los errores de front-end y back-end?
6. Pensamiento y conclusión
Las pruebas de interfaz son cada vez más importantes en el trabajo de los ingenieros de pruebas, por lo que también es una habilidad necesaria para los TE profesionales.
Este artículo presenta brevemente los antecedentes y las ventajas de las pruebas de interfaz, y también menciona brevemente la parte de diseño y organización, y no se utilizan herramientas ni marcos de diseño. De hecho, si desea hablar sobre esta parte en detalle, cada herramienta y cada marco es un gran tema. Este artículo solo proporciona una idea simple, y cada probador necesita pensar más y resumir más.
Si tengo la oportunidad, lentamente resumiré y compartiré ~ ¡Fighting! ¡Animémonos unos a otros!
Por último, me gustaría agradecer a todos los que han leído detenidamente mi artículo. La reciprocidad siempre es necesaria. Aunque no es algo muy valioso, si puede usarlo, puede llevárselo directamente: [Recopilado al final del artículo ]
[El siguiente es el diagrama de sistema de arquitectura de conocimiento de aprendizaje de ingeniero de prueba de software más completo + conjunto completo de materiales que compilé en 2023]
1. De la entrada al dominio de la programación en Python
2. Proyecto de automatización de interfaz de combate real.
3. Combate real del proyecto de automatización web
4. Combate real del proyecto de automatización de aplicaciones
5. Hoja de vida de los fabricantes de primer nivel
6. Probar y desarrollar el sistema DevOps
7. Herramientas de prueba automatizadas de uso común
Ocho, prueba de rendimiento JMeter
9. Resumen (pequeña sorpresa al final)
la vida es larga así que agregue aceite. Cada esfuerzo no será defraudado, mientras perseveres, habrá recompensas al final. Valora tu tiempo y persigue tus sueños. No olvides la intención original, sigue adelante. ¡Tu futuro está en tus manos!
La vida es corta, el tiempo es precioso, no podemos predecir lo que sucederá en el futuro, pero podemos captar el momento presente. Aprecia cada día y trabaja duro para hacerte más fuerte y mejor. Creencia firme, búsqueda persistente, ¡el éxito eventualmente te pertenecerá!
Solo desafiándote constantemente a ti mismo puedes superarte constantemente. Persista en perseguir sus sueños y avance con valentía, y descubrirá que el proceso de lucha es tan hermoso y valioso. ¡Cree en ti mismo, puedes hacerlo!