¿Cómo hacer pruebas automatizadas? Proceso de prueba automatizado empresarial real, clasificación de prueba automatizada...

Contenido: Guía

prefacio

Proceso de prueba de automatización empresarial

El proceso de prueba automatizado incluye cuatro etapas: análisis y planificación de la prueba, diseño y desarrollo de la prueba, ejecución de la prueba y resumen de la prueba.

1. Análisis y plan de prueba
Análisis de viabilidad automatizado:
antes de realizar la prueba de automatización de la demanda, es necesario confirmar si se puede implementar la automatización de la prueba y, si es necesario, realizar un análisis de demostración de muestreo (como la participación de sistemas de terceros, etc.).

Las pruebas automatizadas deben seguir los siguientes requisitos previos:

Cambios poco frecuentes en los requisitos:
el ciclo del proyecto es un período de tiempo suficientemente largo;
los scripts de prueba automatizados se pueden reutilizar en la etapa posterior;
el análisis de demostración de muestra es para realizar un análisis de viabilidad más profundo del caso de la entidad, la selección de la demostración, generalmente directamente seleccione el caso de uso de fumar y escríbalo como una secuencia de comandos de prueba Después de la ejecución, verifique si la secuencia de comandos se puede ejecutar y aprobar, y si todos los puntos de prueba diseñados están cubiertos;

Análisis de requisitos de prueba:
después de confirmar que la prueba automatizada de requisitos es factible, clasifique los requisitos y divida los puntos de función que se pueden automatizar. Los puntos de función son demasiado complicados y se dedicará mucho tiempo a la escritura de guiones, lo que perderá la intención original de automatización;

En esta etapa, para determinar la cobertura de prueba automatizada y la granularidad de prueba automatizada, el principio es aumentar la cobertura de prueba automatizada tanto como sea posible durante el ciclo del proyecto;

2. Desarrollar un plan de prueba.
El plan de prueba incluye principalmente los siguientes contenidos:
Acceso y salida: el punto de tiempo de la intervención de la prueba automatizada, y cuando se alcanza el estándar, la prueba automatizada finaliza.
Alcance de la prueba: determinar la prioridad de los requisitos de la prueba y cronograma del alcance del negocio
: en qué momento ¿cuál es el resultado?
evaluación de riesgos: estimar los riesgos en el proceso del proyecto y brindar soluciones
recursos necesarios: personal, software, hardware, documentos y otros recursos necesarios para las pruebas
acuerdo de trabajo: la división de mano de obra para personal específico

3. Diseño y desarrollo
de pruebas Diseño de casos de prueba:
primero diseñe el caso de prueba, después de que se escriba el caso de prueba, revise el caso de uso y luego desarrolle el script de prueba después de que se apruebe la revisión.

Los principios a seguir en el proceso de diseño de casos de prueba automatizados:
un caso de uso es un escenario completo, que cubre el proceso comercial principal;
se da prioridad a la implementación de casos de prueba positivos, complementados con casos de uso inverso importantes individuales;
los casos de uso de computación de datos necesitan estar en los datos Los resultados esperados se proporcionan en el controlador para la comparación;
los casos de uso para las clases recién agregadas y modificadas necesitan volver a consultar y comparar los resultados de la consulta después de que la adición y la modificación sean exitosas;
intente evitar la dependencia entre los casos de uso;
después de que se prueban los casos de uso, los escenarios de prueba deben restaurarse (borrado de datos, etc.) para no afectar la ejecución de otros casos de uso;

4. Desarrollo de scripts y control de versiones
De acuerdo con los casos de prueba escritos, escriba los scripts de prueba automatizados correspondientes. La escritura de los scripts de prueba sigue las especificaciones de desarrollo de scripts. Durante el proceso de escritura, la mantenibilidad, la reutilización, la simplicidad y la solidez de los scripts deben ser considerado

Al mismo tiempo, preste atención para garantizar la estructura y la consistencia del proyecto de automatización.Después de desarrollar el script, debe ejecutarse con éxito al menos tres veces antes de que se pueda considerar que el script no tiene problemas.

Antes de escribir scripts el mismo día, extraiga el código maestro de la rama localmente para asegurarse de que el código local sea la última versión. Después de completar la escritura y la depuración del script el mismo día, súbalo a su propia rama y luego unifique Merge to la rama principal

5. Ejecución de la prueba
Cuando se haya completado la prueba del sistema de requisitos iterativos (por ejemplo, después de que el requisito iterativo se publique en línea), use el método de activación de tareas de la herramienta Jenkins para ejecutar el script sin supervisión.

Los errores efectivos encontrados durante el proceso de ejecución se registran en Huawei Cloud y se envían a los desarrolladores correspondientes para su reparación. El título tiene el prefijo [Prueba automatizada] para su posterior seguimiento y procesamiento.

Después de que los desarrolladores solucionen el ERROR, deben realizar una prueba de regresión en el ERROR. Si el plan de modificación del problema se desvía de los requisitos originales, los casos de uso y los scripts deben modificarse antes de la prueba de regresión.

6. Resumen de prueba
Resuma los resultados de las pruebas automatizadas, cuente los errores encontrados y sus causas, y envíe documentos de informe de prueba

7. Informe de prueba automatizado
Resumen del funcionamiento de la versión: cobertura de prueba automatizada, tasa de aprobación, tasa de defectos y datos de calidad en comparación con la versión anterior cada vez que se lanza una nueva función

Resumen de operaciones diarias: seguimiento automatizado de la calidad de las pruebas posteriores al lanzamiento, análisis de problemas y determinación de las causas de los defectos
.

Un solo informe estadístico automatizado, que cuenta la información detallada de un solo script de ejecución, dividido en estadísticas de fallas y todas las estadísticas e información de revisión de registros;

Informe estadístico automatizado único, información detallada de un caso de uso único, incluidos puntos de control, pasos de ejecución;
finalmente, mantener, optimizar y archivar scripts y casos de prueba para informes de prueba;

Clasificación de pruebas automatizadas

1. Prueba unitaria
La prueba unitaria necesita probar la capa DAO y la capa de Servicio. La prueba unitaria de la capa basada en datos garantiza principalmente la corrección y la racionalidad del script SQL, y la prueba unitaria de la capa de Servicio garantiza principalmente la corrección de la lógica de una sola función función

Las dependencias externas de la prueba unitaria se pueden simular y devolver a través del marco Mock (Mockito, etc.), de modo que la prueba automatizada se pueda ejecutar en cualquier momento y en cualquier lugar tanto como sea posible. capa de pruebas automatizadas es la más alta

2. La prueba de interfaz de servicio (prueba de integración)
en la prueba de interfaz de capa de servicio se enfoca en si las funciones de entrada y salida de una interfaz son correctas, así como la prueba lógica del proceso comercial. La automatización de la prueba inicial comenzó tarde y el la tasa de cobertura de código no fue alta, por lo que la etapa inicial La estrategia de automatización de la interfaz es aumentar la cobertura de escenarios comerciales

Priorice la cobertura de los escenarios comerciales centrales:
los datos de los que depende la interfaz eligen el método de usar el valor de retorno de la interfaz;
temporalmente no haga simulacros entre sistemas y considere más dependencias entre sistemas;
priorice la cobertura de la escena y luego considere el código cobertura;

Esto puede aumentar rápidamente la cobertura de los escenarios comerciales y, al mismo tiempo, la interfaz API escrita se puede usar incluso si el proceso comercial del producto cambia en la etapa posterior (la lógica de la interfaz de la capa de la interfaz de usuario permanece sin cambios). de esta manera tener menores costos de mantenimiento en la etapa posterior.

La prueba de interfaz es completada por el probador. Durante la prueba de interfaz, el probador no necesita tener una comprensión muy detallada de la implementación del código de interfaz interna. El script escrito refleja la clasificación de la relación entre diferentes interfaces y módulos, y la cobertura del proceso comercial central es mayor en la etapa posterior.La cobertura se puede aumentar para una sola interfaz en el caso de

Desacoplamiento de las dependencias de la interfaz, como cambiar los datos de las interfaces de llamadas para insertarlos directamente en la base de datos,
refinar y dividir gradualmente los escenarios comerciales,
cambiar gradualmente de las pruebas automatizadas a nivel del sistema a las pruebas automatizadas de caja gris y caja blanca;

3.
La capa de prueba de la página de la interfaz de usuario es principalmente la lógica de visualización de la página y la verificación de integración del front-end de la interfaz y el servicio. Es necesario realizar una prueba de automatización de la interfaz de usuario adecuada, ya que la automatización de la interfaz de usuario puede realizar un trabajo repetitivo para los probadores cuando la versión se itera y devuelto Liberar la fuerza de trabajo.

Solo automatice la cobertura de las funciones principales y mejore la capacidad de mantenimiento de la secuencia de comandos tanto como sea posible.
Las secuencias de comandos de prueba de automatización de la interfaz de usuario siguen el patrón de diseño del objeto de página;
reducen la dependencia de los datos de fondo a través de la simulación de datos;

Las pruebas de la interfaz de usuario las realizan los evaluadores. Después de cubrir la escena central, no es necesario invertir demasiada energía y recursos en la capa de la interfaz de usuario, ya que la interfaz de la interfaz de usuario es la capa con la mayor frecuencia de cambios, y los costos de mantenimiento posteriores también lo son. alto

Integración continua
Con pruebas automatizadas en todos los niveles, es necesario establecer un sistema de integración continua

Automatización de procesos para mejorar la eficiencia de la automatización
Temporización y ejecución repetida cuantitativa para maximizar el valor de los scripts de prueba automatizados

Propósito:
envío de código para ejecutar automáticamente pruebas unitarias;
implementar automáticamente el entorno general después de que pasen las pruebas unitarias;
ejecutar automáticamente pruebas de automatización integradas (Servicio/UI);
generar automáticamente informes de prueba detallados para la construcción y notificar automáticamente al personal relevante;

Puede promover el desarrollo de la cobertura de pruebas unitarias, formular especificaciones de escritura de guiones de automatización de interfaz, aumentar la legibilidad, la eficacia y la reutilización del código, y hacer que el diseño de guiones esté lo más lejos posible de la dependencia de la prueba, la versión preliminar y tres en línea. datos ambientales, aumentar la cobertura de las pruebas de automatización de la interfaz de usuario del proceso empresarial central en un tiempo controlable

Cuando las pruebas automatizadas en todos los niveles están relativamente maduras, las actividades como la recopilación automática de cobertura de código, la inspección estática de código y otras actividades de desplazamiento a la izquierda, así como la recopilación y el monitoreo de datos y errores en línea (rendimiento de la interfaz, tasa de fallas y usuarios). análisis de comportamiento) se puede agregar más tarde, etc.) para probar actividades de cambio a la derecha, construir una plataforma de prueba que se ajuste al estilo de la empresa, etc.

El siguiente es el diagrama de sistema de arquitectura de conocimiento de aprendizaje de ingeniero de prueba de software más completo en 2023 que compilé