Prefacio:
Postman es una herramienta de prueba de interfaz simple y liviana. Como probador, es indispensable lidiar con las interfaces. A veces es prueba funcional + prueba de interfaz, a veces prueba de interfaz pura. El objetivo final de la prueba de interfaz es poner todos los campos en la interfaz Se prueban la eficacia y la tolerancia a fallos. Etc.
1. La pantalla básica de la interfaz.
Lo anterior es una visualización general de la interfaz. La imagen de la derecha muestra los métodos de solicitud comunes de la interfaz.
2. Generación de datos de prueba por lotes (el primer paso de la prueba automatizada)
La generación por lotes de datos de prueba se ha explicado en detalle en mis dos últimos blogs: https://blog.csdn.net/u013521274/article/details/110005978
Finalmente, se generará un archivo csv, que contiene muchos datos de prueba.
3. Prueba automatizada de la interfaz del cartero
3.1 Construya una columna de datos csv y resuelva problemas comunes
Pregunta 1: cuando se construyen los datos, no hay ningún problema con los datos csv en sí, pero si el campo de ID en los datos supera los 32 bits y luego se abre con Excel o wps , se utilizará de forma predeterminada un tipo numérico en lugar de una cadena , y los datos de identificación serán. Existe en forma de notación científica, lo que hace que los datos se deformen y no se puedan utilizar. Los detalles se pueden ver en las dos figuras siguientes.
Para resolver el problema anterior, cuando no se recomienda usar la buena estructura de datos en general (sin importar la forma de la buena estructura de datos) en Excel o wps abiertos, se usarán algunos editores comunes como editpius notpad ++, Bloc de notas para abrir.
Pregunta 2: Problemas de compatibilidad de datos del cartero,
Al importar datos csv a cartero y prepararse para realizar pruebas de datos por lotes, debido a los propios problemas del cartero, también habrá un problema . Los datos se convierten en un problema de notación científica, que se puede ver en la vista previa del cartero. Por ejemplo, como se muestra en la siguiente figura.
Para resolver el problema dos ,
La única forma de ampliar es agregar comillas dobles a todos los datos con un ID de datos que exceda los 32 bits para resolver este problema. No se preocupe por las comillas dobles que agregamos cuando el cartero lee los datos, el cartero los ignorará automáticamente. Como se muestra abajo
El problema de los datos está resuelto y luego ingresaré al tema, pruebas automatizadas.
3.2 pruebas automatizadas del cartero
Paso 1: En el cuerpo de la solicitud , cambie los parámetros fijos a nombres de variables. Los nombres de las variables deben corresponder a los nombres de las columnas en el archivo csv, para asegurar la entrada normal de datos.
Paso 2 : En el cuerpo de la solicitud, escriba el código en el Script de solicitud previa y pase los parámetros. (Nota: Más tarde descubrí que esta parte se puede omitir)
//这里的传参代码可写可不写，在body中写好就能自动的获取响应的字段
pm.environment.set("PersonID", data.PersonID);
pm.environment.set("InfoKind", data.InfoKind);
pm.environment.set("SourceID", data.SourceID);
pm.environment.set("DeviceID", data.DeviceID);
pm.environment.set("LocationMarkTime", data.LocationMarkTime);
pm.environment.set("PersonAppearTime", data.PersonAppearTime);
pm.environment.set("PersonDisAppearTime", data.PersonDisAppearTime);
Paso 3: en el cuerpo de la solicitud, escribe una aserción en Prueba
El papel de la aserción es verificar si nuestros resultados esperados son consistentes con los resultados de la ejecución real de la prueba El campo más importante es la verificación del campo StatusCode . Generalmente 0 significa normal.
Afirmar que la función del código es obtener el cuerpo de la respuesta en varios campos de datos que queremos que se devuelvan. Entonces compare.
//is equal to a string ---success
pm.test("断言 StatusString： ok 正常", function () {
var jsonData =JSON.parse(responseBody);
pm.expect(jsonData.ResponseStatusListObject.ResponseStatusObject[0].StatusString).to.equals("OK， 正常");
});
//验证状态--success
var data = JSON.parse(responseBody);
var status = data.ResponseStatusListObject.ResponseStatusObject[0].StatusCode;
tests[status] = true;
//验证状态码是否为0 --success
pm.test("断言 响应体状态码 0", function () {
var jsonData =JSON.parse(responseBody);
pm.expect(jsonData.ResponseStatusListObject.ResponseStatusObject[0].StatusCode).to.eql(0);
});
#以上的断言一般情况下使用一个就可以*/
Nota: El problema aquí es la escritura del código de aserción. El anidamiento y la estructura del cuerpo de respuesta de diferentes proyectos son diferentes, lo que conduce a diferentes estructuras de código cuando obtenemos el código de estado.
También pisé muchos pozos aquí, leí mucha información y muchos blogs. Finalmente, se resumen algunos métodos.
Algunos blogs de uso común están organizados, como: satisfacer la adquisición del código de estado de uso común
https://blog.csdn.net/rechel000/article/details/105136425
https://www.cnblogs.com/xiaozhuxiaozhu/articles/12732608.html
Si la estructura del cuerpo de la respuesta es demasiado complicada y no está seguro, puede probar la herramienta de formato json , tome el código de estado de la figura anterior como ejemplo.
De esta manera, podemos usar el código de estructura json de StatusCode en la figura anterior para obtener cualquier campo en la aserción claramente.
El enlace del formato json anterior para obtener es: http://www.bejson.com/
3.3 Ejecución automatizada de datos de prueba
3.3.1 Abra la carpeta en el proyecto y haga clic en Ejecutar
3.3.2 Importar datos csv y ejecutar la prueba
3.3.3 Ver resultados de ejecución de datos de prueba
Como se muestra en la figura anterior, la verificación de las tres afirmaciones indica que los datos se han ejecutado y pasado.
En segundo lugar, el cartero tiene la función de exportar informes de prueba, pero no es hermoso en formato json. Para generar informes de prueba HTML, es necesario instalar otros componentes. No hablaré de eso aquí.
Si tiene alguna pregunta, deje un mensaje, debe responder cuando lo vea.