Estándares de documentación del plan de prueba API
Tengo una pregunta para probadores de API con experiencia, especialmente para aquellos que trabajan en grandes organizaciones. Me han encomendado la tarea de identificar los estándares de la industria para la documentación de los planes de prueba de API. Hasta ahora, he descubierto que el estándar IEEE 829 y el ISO 29119 podrían usarse para informar las pruebas de software en general.
Sin embargo, ¿existen mejores prácticas, pautas o estándares para documentar los planes de prueba de API específicamente que pueda recomendar a partir de su experiencia?
Respuestas
Mi opinión personal:
A un nivel alto
Pruebe los puntos finales de la API, los códigos de estado y los datos con pruebas Smoke, Happy y Sad
En un nivel detallado, es necesario hacer las siguientes preguntas.
Las respuestas guiarán qué y cómo probar.
- ¿Qué documentación existe?
- ¿Qué funcionalidad proporciona?
- ¿Es compatible con la concurrencia?
- ¿Qué son los puntos finales de la API?
- ¿La API es interna o externa?
- ¿Qué puntos finales son idempotentes?
- ¿Son los puntos finales sin estado o con estado?
- ¿Algún flujo de trabajo * 1 varía según el cliente?
- ¿Existen requisitos de desempeño?
- ¿Los puntos finales de API constituyen un flujo de trabajo?
- ¿Qué validaciones se esperan para los datos?
- ¿Qué sistema o biblioteca hay detrás de la API?
- ¿Necesitamos burlarnos de los servicios dependientes?
- ¿Restringe el tráfico, también conocido como límite de velocidad?
- ¿Qué enfoque de control de versiones (si lo hay) se utiliza?
- ¿La API admite varios idiomas?
- Si ya usa SOAPui, ¿cómo se integra?
- ¿La API está restringida a un país o región?
- ¿Ofrece resguardos de clientes en idiomas específicos?
- ¿Qué códigos de estado se esperan para determinados puntos finales?
- ¿Qué formato y estructura de dominio existe para los datos?
- ¿La API usa HATEOS * 2 para la auto documentación?
- ¿Qué tipo de validación / prueba de datos se puede realizar?
- ¿Qué API es compatible con el marco de prueba que estoy usando?
- ¿Qué acciones se realizan, por ejemplo, OBTENER, PONER, PUBLICAR, etc.?
- ¿Necesitamos preparar datos o servicios de prueba dependientes?
- ¿Qué enfoques sin API se necesitarán para verificar los datos?
- ¿Existen definiciones de API, por ejemplo, WADL, WSDL, Thrift?
- ¿Qué enfoques sin API se necesitarán para preparar los datos?
- ¿Qué mecanismo de autorización ("qué") (si lo hay) se utilizará?
- ¿Qué mecanismo de autenticación ("quién") (si lo hay) se utilizará?
- ¿Quién lo utilizará, programadores externos u otro módulo interno?
- ¿Qué formato (s): SOAP, REST, GraphQL, Thrift, ProtoBuffer, Otro?
* 1 Los flujos de trabajo a menudo requieren varias llamadas a la API y pueden tener dependencias entre ellas
* 2 HATEOS: hipertexto como motor del estado de la aplicación, que permite el autodescubrimiento de una API