¿Qué son las pruebas de interfaz? Tipos y ejemplos

¿Qué son las pruebas de interfaz?

Prueba de interfaz Se define como un tipo de prueba de software que verifica si la comunicación entre dos sistemas de software diferentes se realiza correctamente.

Una conexión que integra dos componentes se denomina interfaz. En el mundo informático, esta interfaz puede ser cualquier cosa, como API, servicios web, etc. Las pruebas de estos servicios o interfaces de conexión se conocen como pruebas de interfaz.

Una interfaz es en realidad un software que consta de conjuntos de comandos, mensajes y otros atributos que permiten la comunicación entre un dispositivo y un usuario.

El punto importante es que una interfaz tiene una contract: un formato de solicitud acordado, un formato de respuesta acordado, un conjunto acordado de códigos de error y un tiempo de espera acordado. Ejercicios de prueba de interfaz que contract de ambos lados, por lo que un cambio realizado por un equipo no rompe silenciosamente al otro. Debido a que la mayor parte de este tráfico nunca llega a una pantalla, los defectos que encuentra son invisibles para prueba de caja negra realizado únicamente a través de la interfaz de usuario.

Cómo hacer pruebas de interfaz

Las pruebas de interfaz incluyen pruebas de dos segmentos principales:

1. Interfaz de servidor web y servidor de aplicaciones
2. Interfaz del servidor de aplicaciones y del servidor de bases de datos.

Para los escenarios mencionados anteriormente, las pruebas de interfaz se realizan para

• Verificar que los servidores se ejecuten correctamente o no
• Los errores se manejan correctamente o devuelven un mensaje de error para cualquier consulta realizada por una aplicación.
• Compruebe los resultados cuando se restablece la conexión a un servidor web en el medio

El diagrama que aparece a continuación muestra esos dos segmentos como una sola cadena, donde el navegador se comunica con el servidor web, el servidor web se comunica con el servidor de aplicaciones y el servidor de aplicaciones se comunica con el servidor de bases de datos.

En la práctica, un probador trabaja a través de esa cadena salto por salto. Cada salto se realiza primero con una solicitud válida, luego con una solicitud mal formada y, finalmente, con el extremo lejano deliberadamente no disponible, de modo que tanto la ruta de éxito como la ruta de fallo se registren en el mismo sistema. caso de prueba.

Ejemplo de prueba de interfaz

Supongamos que para cualquier aplicación xyz, la interfaz toma XML archivo como entrada y entrega JSON archivo como salida. Para probar la interfaz de esta aplicación, solo se requieren las especificaciones del formato de archivo XML y del formato de archivo JSON.

Con la ayuda de estas especificaciones, podemos crear archivos XML de entrada de ejemplo e introducirlos en la interfaz. Posteriormente, la validación de los archivos de entrada (XML) y salida (JSON) según los requisitos constituye la prueba de la interfaz.

Fíjese en lo que no necesita el ejemplo: ni pantalla, ni interfaz de usuario, ni conocimiento del código interno. Dos especificaciones de formato son suficientes para escribir las pruebas, por lo que las pruebas de interfaz pueden comenzar mucho antes de que exista la interfaz de usuario.

¿Por qué realizar pruebas de interfaz?

Se realizan pruebas de interfaz

• Para garantizar que los usuarios finales o los clientes no encuentren ningún problema al utilizar un producto de software en particular.
• Identificar a qué áreas de aplicaciones suelen acceder los usuarios finales y comprobar también su facilidad de uso.
• Para verificar los requisitos de seguridad mientras la comunicación se propaga entre los sistemas.
• Para comprobar si una solución es capaz de manejar fallas de red entre un servidor de aplicaciones y un sitio web

También existe un argumento económico. Corregir un defecto en el formato de una solicitud es barato mientras los dos sistemas aún se están conectando, pero costoso una vez que un sistema posterior ya ha almacenado los datos mal formados.

Tipos de pruebas de interfaz

Durante la prueba de interfaz, se realizan varios tipos de pruebas en la interfaz que pueden incluir

• Flujo de trabajo: Garantiza que el motor de interfaz maneje sus flujos de trabajo estándar como se esperaba.
• Casos extremos: valores inesperados: Esto se tiene en cuenta cuando las pruebas incluyen fecha, mes y día invertidos.
• Pruebas de rendimiento, carga y red: Una interfaz de alto volumen puede requerir más Prueba de carga que una interfaz de bajo volumen, dependiendo del motor de la interfaz y la infraestructura de conectividad
• Sistemas individuales: Esto incluye probar cada sistema individualmente. Por ejemplo, el sistema de facturación y el sistema de gestión de inventario de la tienda minorista deberían poder funcionar por separado.

El primer elemento está lo suficientemente cerca de pruebas de flujo de trabajo para reutilizar sus escenarios, y el último elemento se superpone con prueba de módulos, puesto que un sistema que falla por sí solo volverá a fallar una vez conectado.

Estrategia de prueba de interfaz

La estrategia de pruebas de interfaz es un método utilizado para probar interfaces con pruebas comunes, independientemente de la implementación. Podemos usar abstract casos de prueba y crear instancias concretas del caso de prueba para cada implementación de la estrategia de prueba de interfaz. La base/abstracLos casos de prueba t realizan pruebas independientes de la implementación, mientras que las pruebas concretas se encargan de instanciar los objetos a probar y realizar pruebas específicas de la implementación.

La recompensa de esa estructura es la reutilización. Cuando aparece una tercera implementación de la misma interfaz, el abstract suite se ejecuta sobre él sin cambios, y solo es necesario escribir el código de instanciación. La misma idea se aplica a mayor escala en prueba de componentes, donde una con compartidatracEl conjunto de pruebas t se ejecuta contra cada componente que afirma satisfacerlo.

Herramientas de prueba de interfaz

Dado que una interfaz no tiene pantalla, las herramientas deben construir las solicitudes directamente y realizar comprobaciones sobre las respuestas sin procesar. Los equipos suelen combinar tres categorías de herramientas.

• Clientes API y constructores de solicitudes: Herramientas tales como Postman, SoapUIInsomnia y Hoppscotch envían llamadas REST, SOAP o GraphQL, las almacenan como colecciones reutilizables y realizan comprobaciones sobre los códigos de estado, los encabezados y los cuerpos de las respuestas.
• CodeBibliotecas de pruebas de nivel: Las bibliotecas que se ejecutan dentro del conjunto de pruebas existente permiten que las comprobaciones de interfaz coexistan con las pruebas unitarias y se ejecuten en cada compilación, lo que evita que queden desactualizadas.
• Herramientas de carga y protocolo: Una herramienta como JMeter maneja la misma interfaz a volumen, que es lo que convierte una verificación funcional en pruebas de rendimiento de la conexión.
• Virtualización de servicios y simulaciones: Un enlace alternativo para el extremo opuesto permite probar un lado mientras el otro no está disponible, no está terminado o es demasiado caro para llamarlo repetidamente.

La selección importa menos que la cobertura. Cualquiera que sea el cliente elegido, el conjunto de solicitudes debe almacenarse en el control de versiones junto con el código, de modo que un cambio en la interfaz y un cambio en sus pruebas lleguen en la misma confirmación. Los detalles de la categoría más amplia se tratan en Pruebas de API.

Lista de verificación y mejores prácticas para pruebas de interfaz

Una breve lista de verificación garantiza una cobertura de interfaz precisa entre versiones. Revísala para cada conexión, en lugar de para la aplicación en su conjunto.

• Contract primero: Confirme que los esquemas de solicitud y respuesta coinciden con la especificación publicada, campo por campo, incluyendo los tipos de datos y los campos opcionales.
• Valores límite: Enviar cargas útiles vacías, campos de longitud máxima, conjuntos de caracteres inesperados y formatos de fecha invertidos.
• Rutas de error: Verifica que cada error devuelva un código y un mensaje significativos en lugar de una pila. traco un éxito silencioso.
• Tiempos de espera y reintentos: Interrumpa la conexión a mitad de la solicitud y confirme que quien realiza la llamada vuelve a intentarlo de forma segura sin duplicar la transacción.
• Seguridad: Verifique la autenticación, la autorización y el cifrado del enlace, y confirme que los mensajes de error no revelen información interna.
• Consistencia de los datos: Lea el registro desde el otro lado y confirme que no se truncó, recodificó ni reordenó nada durante la transmisión.
• Volumen: Repita la llamada con mayor tráfico bajo carga concurrente y observe si se agota el grupo de conexiones.

Tres prácticas hacen que esta lista de verificación sea repetible. Primero, automatice el conjunto de pruebas y ejecútelo en cada compilación, ya que las interfaces cambian de forma más silenciosa que las pantallas. Segundo, registre la solicitud y la respuesta completas para cada fallo, puesto que un defecto de interfaz es casi imposible de reproducir a partir de una captura de pantalla. Tercero, mantenga el conjunto de pruebas independiente de los datos de prueba creados por otros conjuntos, de modo que un fallo apunte a la interfaz y no a un registro faltante.

Estos controles se integran naturalmente dentro del plan más amplio descrito en tipos de pruebas de softwarey se ejecutan antes de que se ejerzan las mismas conexiones de extremo a extremo durante prueba del sistema.

Pruebas de interfaz versus pruebas de integración

Ambos términos están relacionados, no son opuestos: las pruebas de interfaz son la parte del trabajo de integración que se centra en la conexión en sí. La siguiente tabla muestra el énfasis de cada una.

Cualquier persona nueva en la disciplina más amplia encontrará los niveles circundantes descritos en pruebas de integración y en general pruebas de software introducción, mientras que la terminología utilizada arriba proviene de estándar Ingeniería de software práctica. Para los sistemas orientados al navegador, las mismas conexiones se vuelven a ejercer eventualmente durante pruebas de aplicaciones web.

Preguntas Frecuentes