Escrito en el frente_Asegúrese de hablar sobre el estado de la interfaz en el campo de prueba:
En la aplicación actual de las habilidades prácticas de prueba en las empresas, las pruebas funcionales y las pruebas de interfaz son las más utilizadas. Sin embargo, en comparación con las pruebas funcionales, la brecha de las pruebas de interfaz es muy grande.
Y las pruebas de interfaz tienen un estatus muy alto en el campo de las pruebas, y es la línea divisoria entre los ingenieros de pruebas de software junior e intermedios . Por lo tanto, siempre que los probadores comprendan las pruebas de interfaz, pueden encontrar trabajos con muy buenos salarios.
Por lo tanto, los trabajadores de prueba (es decir, QA a los ojos del interrogador) deben hacer todo lo posible para mejorar sus capacidades de prueba de interfaz.
Si desea mejorar la cobertura de código de las pruebas de interfaz. En primer lugar, debemos conocer las razones de la baja cobertura de código, para que podamos tomar mejores medidas para mejorar la cobertura de código. Después de analizar cuidadosamente los escenarios de aplicación complementados por el tema, explicaré la pregunta del tema en 4 partes.
1. ¿Por qué la tasa de cobertura de código es baja para las pruebas de interfaz convencionales?
2. ¿Cómo mejorar la cobertura del código?
3. Para facilitar la comprensión de los métodos de casos de prueba de interfaz, se dan ejemplos.
4. Analizar las dificultades que se pueden encontrar para asegurar la cobertura de la prueba de interfaz.
1. ¿Por qué la tasa de cobertura de código es baja en las pruebas de interfaz convencionales?
El control de calidad de la interfaz sigue siendo una caja negra. Los QA no prestan atención a la lógica interna de la interfaz. Simplemente diseñe diferentes combinaciones de parámetros según su propio entendimiento como casos de uso.
De hecho, el tema ha revelado la causa raíz de la baja cobertura de código. Para las pruebas de interfaz, este tipo de pensamiento de diseño de caso de prueba de caja negra es bastante común.
Tomemos un escenario de interfaz simple como ejemplo para ver el diseño del caso de prueba de los probadores de caja negra:
Tome el protocolo http como ejemplo
Interfaz única:
Validar URL
* Hay algunas rutas especiales en la ruta de la URL que deben validarse
Valide los parámetros de consulta, el encabezado de la solicitud, los parámetros del cuerpo de la solicitud
* Para parámetros: verificación de parámetros de clase regular (datos normales y anormales)
* Para empresas: cobertura de función de interfaz única (requisitos directos e inversos)
Validar datos de respuesta
* Cobertura de respuesta de interfaz normal
* Cobertura de respuesta de interfaz anormal (información de error)
Verificar el escenario de negocio:
* Cubrir el escenario de negocio de la aplicación
* Simular el posible proceso de operación del usuario a través de la interfaz
Este tipo de diseño de caja negra se ocupa de las pruebas de interfaz y, a menudo, pasa por alto las siguientes cuatro categorías:
Clasificación de omisiones 1. Omisiones de escena causadas por pruebas poco claras o irregulares
Si las ideas de diseño de los casos de prueba de interfaz no son claras o estandarizadas, es fácil perderse la escena. Es decir, hay omisiones en los escenarios que deberían ser cubiertos por el pensamiento de diseño de casos de prueba de caja negra, lo que definitivamente reducirá la cobertura del código.
Falta la clasificación 2, que involucra ramas que no son fáciles de cubrir
La lógica de implementación de la interfaz es diversa e involucra muchas ramas, algunos puntos comunes se enumeran a continuación. Espero que agregues más.
1. La interfaz involucra tareas asíncronas
Cuando la interfaz implica tareas asincrónicas. Las ideas de diseño de casos de prueba de interfaz convencionales generalmente solo activan la ejecución normal de tareas asincrónicas. Sin embargo, es posible que se pasen por alto los procesos asincrónicos, como el error de tarea asincrónica, el reintento y la sincronización. Reduciendo así la cobertura del código.
2. La interfaz involucra transacciones
Cuando una interfaz involucra una transacción, el diseño de caso de prueba de interfaz convencional generalmente solo activa el proceso de transacción normal. Los desarrolladores reales han realizado algunas implementaciones comerciales especiales para el paso específico de reversión y el procesamiento requerido después de la reversión. Estos escenarios son fáciles de pasar por alto y también afectan la cobertura del código.
3. La interfaz implica bloqueos
Cuando una interfaz involucra bloqueos, es fácil pasar por alto algunos escenarios de prueba. Tome los bloqueos de lectura y escritura como ejemplo (coexistencia de lectura y lectura, no coexistencia de lectura y escritura, no coexistencia de escritura y escritura). Es probable que el diseño de casos de prueba de interfaz convencional pase por alto algunos escenarios de coexistencia de lectura-lectura, no coexistencia de lectura-escritura y no coexistencia de escritura-escritura. Incluso si se cubren estos escenarios, es difícil cubrir los escenarios de esperar después de que caduque el bloqueo y no poder adquirir el bloqueo. Obviamente, esto reduce la cobertura del código.
4. La interfaz implica el almacenamiento en caché
Es común usar tecnología de almacenamiento en caché en las interfaces, especialmente en las interfaces de consulta. Como la consulta por lotes. Si la interfaz implica el almacenamiento en caché, el diseño de caso de prueba de interfaz convencional puede ignorar fácilmente el impacto del almacenamiento en caché y no hay una verificación específica relacionada con el almacenamiento en caché de la interfaz. Esto también reduce la cobertura del código.
Omisión Clasificación 3. Ignorar Escenas Anormales
Teóricamente hablando, cada interfaz puede tener escenarios anormales
Cuando hay algunos escenarios anormales en la interfaz, se arroja un error del marco, que generalmente no está permitido. En otras palabras, los programadores generalmente tienen que lidiar con escenarios de excepción que pueden ocurrir en la interfaz. Hay algunos escenarios duros que no son fáciles de ver y los probadores son fáciles de ignorar. Una vez que no haya cobertura, definitivamente reducirá la cobertura del código. Por ejemplo:
Escenario 1: la interfaz descendente devuelve un tiempo de espera
Cuando un servicio ascendente llama a una interfaz proporcionada por este servicio, este servicio necesita acceder a otros servicios al procesar este negocio de interfaz, y la devolución de otros servicios puede agotarse, y este servicio generalmente no espera para siempre.
Escenario 2: tiempo de espera de conexión de base de datos
Cuando una determinada interfaz necesita operar datos, el rendimiento del servidor de la base de datos es seguro y debe haber algunos escenarios de excepción de la base de datos. Para estos escenarios, el desarrollo generalmente realiza algún procesamiento de código.
Escenario 3: excepción del servidor de caché
Algún estado de inicio de sesión del usuario, si se guarda en el servicio de caché. Si el servicio de caché es anormal o se reinicia, muchas interfaces se verán afectadas. Estos escenarios también necesitan ser cubiertos.
Clasificación de omisión 4. Otra configuración relacionada con el proyecto
La lógica empresarial de muchos proyectos se puede controlar a través de la configuración, que también es muy común. Si algunas funciones están habilitadas, el modo de inicio y el control de contenido comercial específico se pueden manejar mediante elementos de configuración.
Por ejemplo:
Configuración del interruptor de habilitación de funciones
Si el interruptor está apagado, el código comercial de esta función no debe cubrirse, debe ser encendido y probado por el vendedor correspondiente, para que este tipo de código pueda cubrirse.
Configuración de tareas de temporización
Establezca la política de ejecución de tareas programadas de acuerdo con la configuración. Algunas tareas programadas procesan datos en diferentes estados. Si no se prueba un determinado modo de tarea, o si el estado de los datos de un determinado modo no se cubre por completo, se perderá la escena. Reducir la cobertura de código.
En segundo lugar, ¿cómo mejorar la cobertura del código?
Idea general: por las razones analizadas en la primera parte, tome algunas medidas para hacer todo lo posible para que nuestros evaluadores que no entienden el código puedan probar mejor la interfaz y cubrir estos escenarios. En última instancia, mejore la cobertura del código.
Solución 1. Omisión de escenarios de prueba de caja negra
Este tipo de omisión de escena es relativamente fácil de resolver. Medidas específicas: estandarizar el método y el proceso de diseño de casos de uso, y los probadores básicos son competentes.
Solución 2. Cubrir los puntos de bifurcación especiales en la interfaz, escenarios de excepción y escenarios relacionados con la configuración del proyecto
Si desea cubrir estos escenarios desde los casos de uso del diseño de la interfaz, debe conocer y comprender estas lógicas comerciales. Para lograr este objetivo, se puede garantizar a partir de los siguientes 4 pasos.
1. El desarrollo no solo proporciona documentos de interfaz, sino que también proporciona documentos de implementación de interfaz, y el proceso de implementación de la interfaz debe describirse claramente en los documentos. Por ejemplo, se deben indicar claramente los elementos de configuración, las tareas asíncronas, las transacciones, los bloqueos, las cachés, etc. que intervienen en la interfaz. Lo mejor es poder generar un diagrama de flujo o un diagrama de secuencia. Este punto es muy crítico, lo que puede ayudar mucho a los evaluadores sin una base de código para comprender el negocio de la interfaz y los detalles de implementación.
2. Además de participar en la revisión de requisitos, los evaluadores dominan los requisitos del proyecto. También es necesario participar en la reunión de revisión del diseño de requisitos de desarrollo para profundizar la comprensión comercial específica de la interfaz. Dado que es difícil para los evaluadores leer y estudiar solos, los evaluadores pueden encontrar más desarrolladores correspondientes para comprender la implementación comercial.
3. Si los requisitos cambian o la implementación comercial cambia, comunique y actualice los documentos relevantes de manera oportuna.
4. Los probadores diseñan casos de prueba basados en el dominio de la implementación comercial, cubriendo los escenarios comerciales de implementación de la interfaz.
3. Para facilitar la comprensión del método de mejora de la cobertura del código, dé un ejemplo
Ejemplo 1. Tarea asincrónica tomando como ejemplo la eliminación por lotes
Para brindar a los usuarios una buena experiencia en el proyecto, es muy común que algunas interfaces de eliminación tengan tareas de eliminación asíncronas.
Por ejemplo: eliminación por lotes de pedidos (una empresa de comercio electrónico), eliminación por lotes de archivos (un disco determinado), etc. Muchos de estos servicios de eliminación por lotes de datos se implementan a través de tareas asíncronas.
Escribamos aproximadamente la lógica hipotética de eliminar datos
analizar:
Cobertura de casos de prueba de interfaz convencional, es fácil ignorar otras ramas de estas tareas asincrónicas. La razón también es muy simple, QA no conoce estas lógicas. Estos escenarios tampoco son fáciles de desencadenar al llamar a la interfaz.
Si el desarrollador proporciona este diagrama de flujo, los probadores pueden diseñar casos de prueba basados en el diagrama de flujo para cubrir todas las ramas.
Ejemplo de escenario:
Error de escritura de tarea asíncrona
La escritura de datos se puede evitar escribiendo datos fijos de usuarios fijos por adelantado (manejo como conflictos de clave principal)
Modifique el número de conexiones de base de datos y elimine interfaces en lotes
La ejecución de la tarea asíncrona falló
Los datos incorrectos se pueden preestablecer de antemano, lo que resulta en una falla de ejecución (faltan algunos campos, algunos valores de campo son datos incorrectos)
Ejemplo 2. Transacción
En el proyecto, hay algunas implementaciones de interfaz que involucran algunas transacciones, lo cual también es muy común.
analizar:
En el proceso de diseño de casos de prueba de interfaz, considere que en todo el proceso comercial, intente cubrir las excepciones en cada paso tanto como sea posible y diseñe diferentes escenarios de prueba para cubrir todo el proceso comercial.
Ejemplo de escenario:
Se produjo una excepción en la transacción y la reversión se realizó correctamente.
Ejemplo 3. Cerraduras
En los proyectos, las operaciones de múltiples terminales también son relativamente comunes, como el lado web, el lado de la aplicación, los programas pequeños, etc. Luego habrá algunos escenarios donde la interfaz opera en la misma parte de los datos.
Análisis:
al diseñar casos de prueba de interfaz, se deben considerar escenarios relacionados con bloqueos para mejorar la cobertura del código.
Ejemplo de escenario:
adquirir un candado
sin candado
adquirir bloqueo de escritura
adquirir bloqueo de lectura
existe un bloqueo de escritura
adquirir bloqueo de lectura
adquirir bloqueo de escritura
existe un bloqueo de lectura
adquirir bloqueo de lectura
adquirir bloqueo de escritura
liberar bloqueo
leer bloqueo
Liberado con éxito la cerradura
No se pudo liberar el bloqueo
bloqueo de escritura
Liberado con éxito la cerradura
No se pudo liberar el bloqueo
Ejemplo 4. Cronometraje de tareas
Si el proyecto necesita procesar datos en lotes, generalmente optará por implementarlos a través de tareas programadas durante los períodos de menor actividad.
Por ejemplo: migración de versión de datos, limpieza de datos caducados, etc.
analizar:
Al probar la interfaz del servidor, también se deben verificar estas tareas programadas. Puede mejorar efectivamente la cobertura del código.
Aquí enfatizamos principalmente el estado de los datos de la ejecución de la tarea. Para garantizar la exhaustividad de los datos, los datos representativos de todo el ciclo de vida deben existir y deben tener una cierta magnitud, de modo que se pueda cubrir la lógica de procesamiento de la tarea.
Ejemplo de escenario:
Si la tarea cronometrada está activada
Si se ejecuta la tarea programada
Antes de que se ejecute la tarea, ¿los datos son completos (cubriendo todos los tipos del ciclo de vida completo)?
4. Análisis de las dificultades que se pueden encontrar para asegurar la cobertura de la prueba de interfaz
Dificultad 1. Los documentos de implementación de la interfaz proporcionados por el desarrollo no están estandarizados
Los documentos de desarrollo e implementación deben tener ciertas plantillas y especificaciones de escritura, y los desarrolladores están estrictamente obligados a generar documentos. Debe haber medidas de control.
Dificultad 2. Dificultad de comprensión para los probadores
La documentación debe centrarse en la descripción del proceso y menos en el código.
Esto se puede cultivar, y la dificultad no es particularmente grande. A menos que este probador no quiera progresar.
Dificultad 3. Los casos de uso diseñados no pueden ser probados
Hay algunos escenarios anormales y es realmente difícil implementar la prueba, puede pedir ayuda.
Ahora siento cada vez más que, como probador, al diseñar un caso de uso, no hay necesidad de considerar si la prueba se puede realizar. Incapaz de probar, principalmente debido a la falta de habilidades. Por lo tanto, el caso de uso se diseña normalmente y la ejecución del caso de uso puede ser asistida por un gran jefe.
5. Resumen final
requisitos de implementación específicos
Los desarrolladores transforman la lógica de implementación de la interfaz del pensamiento del código en la descripción del documento. Esta es la premisa de la base sin código para entender el negocio del proyecto. Los documentos deben estar estandarizados, las revisiones deben ser claras y los cambios deben sincronizarse de manera oportuna.
Los evaluadores deben fortalecer sus estudios, leer documentos, aprender de las revisiones, consultar el desarrollo y comprender la implementación comercial.
Los probadores tienen un conocimiento profundo del negocio, luego diseñan escenarios de prueba más completos e implementan pruebas.
significado
Se mejora la tasa de cobertura de código y, naturalmente, el proyecto se prueba de forma más completa. Puede encontrar más problemas ocultos.
Puede permitir que los evaluadores que no tienen capacidad de codificación crezcan rápidamente y hagan un buen trabajo de prueba.
Estandariza el proceso de desarrollo e implementación, y también juega un cierto papel en la promoción del desarrollo y la gestión del proyecto.
defecto
Será difícil de implementar al principio, especialmente para operaciones interdepartamentales.
Habrá más costos de comunicación para las pruebas y el desarrollo.
[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é]
1. De la entrada al dominio de la programación en Python
2. Proyecto de automatización de interfaz de combate real.
3. Combate real del proyecto de automatización web
4. Combate real del proyecto de automatización de aplicaciones
5. Hoja de vida de los fabricantes de primer nivel
6. Probar y desarrollar el sistema DevOps
7. Herramientas de prueba automatizadas de uso común
Ocho, prueba de rendimiento JMeter
9. Resumen (pequeña sorpresa al final)
la vida es larga así que agregue aceite. Cada esfuerzo no será defraudado, mientras perseveres, habrá recompensas al final. Valora tu tiempo y persigue tus sueños. No olvides la intención original, sigue adelante. ¡Tu futuro está en tus manos!
La vida es corta, el tiempo es precioso, no podemos predecir lo que sucederá en el futuro, pero podemos captar el momento presente. Aprecia cada día y trabaja duro para hacerte más fuerte y mejor. Creencia firme, búsqueda persistente, ¡el éxito eventualmente te pertenecerá!
Solo desafiándote constantemente a ti mismo puedes superarte constantemente. Persista en perseguir sus sueños y avance con valentía, y descubrirá que el proceso de lucha es tan hermoso y valioso. ¡Cree en ti mismo, puedes hacerlo!
