[El más detallado de toda la red] Precauciones de prueba automatizadas + resumen de puntos problemáticos, no te desvíes más...

Tabla de contenidos: Introducción

Prefacio

1. ¿Cómo se construye el marco de pruebas automatizadas WEB?

La pila de tecnología que utilizamos para las pruebas de automatización web es:
Python+Selenium+Pytest+Parametrices+Excel+Allure+Jenkins. El marco utiliza controladores de palabras clave basados en Excel, que separan el marco de mantenimiento y el marco de uso. Al realizar pruebas automatizadas, los elementos Las expresiones de posicionamiento y las operaciones a realizar se pueden escribir en Excel, lo que reduce significativamente la dificultad de las pruebas automatizadas.

Funciones principales:
palabras clave incorporadas de uso común para realizar pruebas basadas en palabras clave, con el potencial de actualizarse a BDD;
determina automáticamente el tipo y la versión del navegador, y descarga e inicia automáticamente el controlador de navegador apropiado;
espera automática incorporada para evitar Pruebas de UI en condiciones de error en circunstancias normales;

Al ejecutar js, se realizan interacciones de escena especiales, como clic forzado, entrada forzada, carga de arrastrar y soltar, etc.;
con la cadena como estrategia de aserción central, admite múltiples métodos de aserción como iguales, inclusión, coincidencia regular, combinación de contenidos, etc.,
genera automáticamente un informe de prueba de atractivo, el informe integrado coincide uno a uno con el contenido de Excel;

Admite pruebas paralelas y arquitectura de archivos de prueba distribuidos:

conf # 项目配置 
data # 数据驱动测试文件 
action.py # 关键字驱动封装
case.py # 用例管理和封装
data.py # 数据驱动封装
pages # PO 封装 
report # allure测试报告 
tests # 存放 excel文件作为测试用例框架用法：
1）创建execl文件，每个sheet页看作一个TestSuite
2）在sheet页中申明测试用例，填写测试用例的名称
3）在单元格中填写步骤名、关键字、关键字参数，完成测试步骤

2. ¿Cuál es el valor de las pruebas automatizadas WEB? ¿Por qué necesitamos realizar pruebas automatizadas WEB?

Las pruebas automatizadas web consisten en simular probadores manuales para realizar pruebas funcionales.
Reemplazar las operaciones humanas con la automatización de máquinas.
Se utiliza principalmente para pruebas de humo y pruebas de regresión de las funciones principales del producto.

Comience con las funciones principales del sistema y luego amplíelas lentamente según la situación.
Después de introducir las pruebas automatizadas, puede reemplazar una gran cantidad de trabajos tediosos de pruebas de regresión y liberar a los evaluadores de negocios, lo que les permite concentrarse en módulos de funciones comerciales complejos. Las pruebas automatizadas generalmente automatizan las funciones estabilizadas para garantizar que no habrá errores en funciones previamente estabilizadas. debido a actualizaciones de productos.

3. ¿Cómo implementa la empresa pruebas automatizadas WEB en proyectos?

1) El equipo del proyecto lleva a cabo un análisis de viabilidad de la automatización, incluido ¿hasta qué punto se puede implementar la tasa de automatización?
Consideraciones principales:
si el tiempo del proyecto es relativamente largo y generalmente requiere más de un año de proyectos o productos a largo plazo; si
los requisitos cambiarán con frecuencia;
si el script automatizado se puede utilizar de forma continua y repetida;

2) El equipo del proyecto investigó la selección de herramientas de automatización y demostraciones, principalmente demostrando Selenium y Robotframework. Sería mejor si hubiera demostraciones previas de marcos maduros.

3) Implementar gradualmente la automatización en el proyecto, descubrir problemas y mejorarlos.
Incluye principalmente:
escribir planes de prueba automatizados,
extraer o escribir casos de prueba automatizados,
escribir scripts de marcos de prueba automatizados por parte del líder;

Escriba, depure y mantenga scripts de prueba automatizados (codifique las especificaciones y escriba los scripts de prueba automatizados correspondientes de acuerdo con la división del trabajo, y envíelos al servidor Git después de que la autoprueba no tenga problemas) Pruebas desatendidas de integración continua de Jenkins; scripts de mantenimiento
posteriores
( principalmente porque se agregan casos de uso debido a las actualizaciones de versiones));

4) Procesar, estandarizar y automatizar documentos: el marco de automatización requiere la preparación de documentos de uso y documentos de especificaciones.
5) Generar informes personalizados. Continuar mejorando el marco. y promoverlo en otros proyectos.

4. ¿Cuántos casos hay de automatización web? ¿Cuál es la cobertura? ¿Cuánto tiempo se tarda en ejecutar todo?

La cantidad de casos de prueba de automatización WEB depende de la cantidad de casos de prueba funcionales. La cobertura de casos de uso de automatización es generalmente de aproximadamente el 30% de los casos de prueba funcionales y se necesitan
entre 30 y 60 minutos para completar la ejecución de todos los casos de uso de automatización WEB.

5. ¿Cómo diseñar casos de prueba automatizados web?

Los casos de prueba automatizados WEB se extraen de casos de prueba manuales, principalmente casos de humo y casos de prueba de regresión. La selección de casos de prueba automatizados requiere más atención al rigor de los casos de uso. Al seleccionar casos de uso, siga los siguientes principios:

Priorizar los casos de uso que cubran los procesos comerciales centrales del producto;
seleccionar casos de uso que requieran ejecución repetida o funciones de verificación engorrosas, como la verificación de campo y la verificación rápida de la información; dar
prioridad a los casos de prueba directos, los casos de uso inversos son generalmente complejos y grandes en número;
no seleccione casos de uso donde el proceso sea demasiado complejo (excepto el proceso principal);

6. ¿Cómo garantizar (mejorar) la estabilidad de las pruebas automatizadas?

La estabilidad de las pruebas automatizadas se refleja principalmente en dos aspectos: uno es la estabilidad del posicionamiento de los elementos y el otro es la estabilidad de las dependencias entre casos de uso: Problemas de estabilidad del posicionamiento de los elementos:

1) Intente usar expresiones xpath con rutas relativas;
2) Coloque los elementos usando espera inteligente + espera de visualización para evitar el problema de que los elementos no se carguen;
3) Agregue un mecanismo de reintento después de que la ejecución del script falle para mejorar la estabilidad del caso de uso;
4) Casos de uso Después de la ejecución, restaure el escenario de prueba para evitar afectar la ejecución de otros casos de uso;
5) Intente garantizar un entorno de prueba separado para evitar la ejecución simultánea de otras pruebas;

Problemas de estabilidad de dependencia entre casos de uso:
intente evitar dependencias entre casos de uso, y los casos de uso se pueden ejecutar de forma independiente tanto como sea posible; deje que cada caso de uso comience a ejecutarse desde una página común, como la página de inicio, que requiere posprocesamiento en el marco de prueba De esta manera, cada caso de uso volverá a la página de inicio después de la ejecución.

7. ¿Las pruebas automatizadas encuentran muchos errores?

No muchos, porque los casos de uso de la automatización WEB son funciones básicas que han sido probadas por el equipo del proyecto anterior, y luego se escriben y ejecutan los scripts automatizados, principalmente para garantizar que las funciones que han pasado la prueba no se vean afectadas. por las nuevas funciones después de actualizar la nueva versión, lo que provoca errores en las funciones básicas originales.

8. ¿Qué es el modo PO? ¿Por qué usarlo?

Modelo PO, el nombre completo es Modelo de objetos de página, denominado PO, es el modelo de objetos de página.

Significa tratar una página como un objeto, los elementos de la página son los atributos del objeto y las operaciones de la página son los comportamientos (métodos) del objeto.

El modo PO generalmente utiliza una arquitectura de tres capas, que son: capa de encapsulación base BasePage, capa de objeto de página PO y capa de caso de prueba TestCase.

El uso del modo PO puede hacer que nuestros casos de prueba sean más simples y claros. En muchos casos, podemos encapsular muchos métodos de operaciones comerciales en el objeto de la página y el script de prueba solo necesita llamar a los métodos relevantes. La otra es que si un elemento de la página cambia, solo necesitamos modificar la posición del elemento y los métodos relacionados del objeto de la página, sin modificar otros scripts. Aumentar la mantenibilidad del código.

9. ¿Entiendes lo basado en datos y lo basado en palabras clave?

Basado en datos consiste en leer los datos de prueba de entrada y salida de un determinado archivo de datos (como un archivo Excel, un archivo Csv, un archivo YAML, etc.) y luego pasarlos al script de prueba automatizado a través de métodos basados en datos (ddt, parametrizar, etc.).

Durante todo el proceso, los scripts de prueba automatizados realizan lecturas de datos, cambios de estado de pruebas, juicios de resultados, etc., logrando así la separación de datos y código, este enfoque se denomina basado en datos.

Basado en palabras clave se basa en la idea orientada a objetos. La misma lógica empresarial se escribirá en una función como una palabra clave que será invocada por diferentes scripts de prueba. Cuando todas las pruebas de lógica empresarial se pueden combinar mediante funciones escritas, se trata de un marco basado en palabras clave.

En este momento, el desarrollo de casos de prueba se convierte en una combinación de datos de prueba y palabras clave, y este trabajo combinado se simplifica en una tarea de llenado de formulario con la que todos están familiarizados, para finalmente lograr un efecto en el que toda la prueba esté impulsada por datos. y palabras clave. .

10. ¿Qué bibliotecas de Python se utilizan principalmente en el proceso de prueba automatizado? ¿Qué excepciones ha encontrado?

Pruebas web automatizadas:
webdriver, WebDriverWait, By, os, xlrd, xlwt, unittest/pytest, time, logging, HTMLTestRunner, etc.

Pruebas automatizadas de interfaz:
solicitudes, tiempo, registro, json, csv, jsonpath, pyyaml, re, unittest/pytest, allure

Las excepciones comunes incluyen las siguientes:

NoSuchElementException： 没有如此元素异常
NoSuchAttributeException ： 没有如此属性异常
NoSuchFrameException ： 没有如此frame异常
ElementNotSelectableException ：元素不能选择异常
ElementNotVisibleException ：元素不可见异常
Element not visible at this point ：在当前点元素不可见
TimeoutException ： 超时异常；

11. ¿Qué errores se encontraron durante el proceso de prueba de la interfaz?¿Cuántos? (En otras palabras: ¿hay algún problema con la prueba de interfaz?)

La mayoría de los errores descubiertos durante las pruebas de la interfaz están relacionados con problemas como que la interfaz no devuelve los resultados acordados, los parámetros están vacíos, la longitud del parámetro o la verificación del tipo, los valores límite de los parámetros, la lógica del código, los errores de datos o no devuelven mensajes de error razonables.

1) En general, se encontrarán muchos errores al realizar pruebas de interfaz durante la fase de depuración conjunta de front-end y back-end (al desarrollar y escribir código antes, todos los datos ajax no eran los datos reales devueltos por el back-end, sino Los datos falsos simulados por nosotros mismos a través de la interfaz simulada. Después de escribir el código de front-end y la interfaz de back-end, debemos eliminar los datos simulados e intentar usar los datos proporcionados por el back-end para Realice una depuración conjunta del front-end y el front-end. Este proceso se denomina conexión de interfaz del front-end y el front-end. Tune.)

Casos de error de la interfaz de depuración conjunta de front-end y back-end:
por ejemplo 1: interfaz de página de lista de consultas, el front-end quiere paginar, Mock escribe tres datos de prueba, ¿hay algún problema con la paginación al llamar a la interfaz de back-end?
Por ejemplo 2: la autenticación no se considera cuando el front-end accede a datos simulados. No hay permiso para acceder a la interfaz real del backend.

2) Luego, cuando se realice la prueba de interfaz durante las fases de prueba de humo de interfaz y prueba de regresión, habrá menos errores.
Casos de error de interfaz general:
por ejemplo 1: agregue una nueva interfaz de promoción y el monto total del descuento se puede guardar con éxito incluso si está vacío. La razón es que el código de fondo no realiza un juicio de valor nulo sobre el descuento total. parámetro de cantidad.

Por ejemplo 2: en la interfaz de la lista de actividades, a los datos de actividad consultados les falta el primer elemento. La razón es que el número de secuencia inicial pasado en la condición límite en SQL es 1 en lugar de 0.

Por ejemplo 3: Actualizar la interfaz de actividad, la interfaz indica que la actualización se realizó correctamente, pero el campo update_time en la base de datos no se actualiza a la última hora. La razón es que el desarrollador olvidó actualizar este campo. Por ejemplo 4: Por ejemplo , en la interfaz de pedido, el parámetro de precio del producto es 300 yuanes, luego al enviar el pedido, cambié el precio del producto a 3 yuanes, pero el back-end no lo verificó. Para ser más cruel, ¿Cambié el precio a -3 y mi saldo aún aumentó?

Caso de error de autenticación de interfaz:
por ejemplo 1: por ejemplo, si modifica la interfaz de información del producto, solo se puede modificar el permiso del vendedor. Puedo modificarlo con éxito si lo subo a un usuario normal, y puedo modificarlo con éxito si lo subo a un usuario normal. súbelo a otro usuario vendedor.

Por ejemplo 2: antes había una interfaz de entrega y el sistema posterior agregó la verificación del período de validez de la tarjeta de identificación, lo que provocó que la llamada de interfaz del sistema bajo prueba no funcionara. Los problemas se descubrieron a través de la automatización y el impacto en el sistema bajo prueba. fue evaluado oportunamente.

El siguiente es el diagrama del sistema de arquitectura de conocimiento de aprendizaje de ingenieros de pruebas de software más completo que compilé en 2023.