¿Un artículo de 4000 palabras le enseña cómo garantizar la cobertura de las pruebas de interfaz?

Los estudiantes que tengan la suerte de leer este artículo, lean este artículo detenidamente (recuerden leerlo varias veces), ya que este artículo puede mejorar sus habilidades de prueba de interfaz.

Escrito en el frente _ primero debe hablar sobre el estado de la interfaz en el campo de prueba:

En la aplicación actual de habilidades prácticas de prueba en las empresas, las pruebas funcionales y las pruebas de interfaz son las más utilizadas . Pero 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 primarios e intermedios . Por lo tanto, siempre que los evaluadores comprendan las pruebas de interfaz, pueden encontrar un trabajo con un buen salario.

Por lo tanto, los trabajadores de prueba (es decir, el control de calidad a los ojos del interrogador) deben hacer todo lo posible para mejorar su fuerza de prueba de interfaz.

de vuelta al punto

Si desea mejorar la cobertura de código de las pruebas de interfaz. En primer lugar, debe conocer los motivos de la baja cobertura de código y luego puede tomar mejores medidas para mejorar la cobertura de código. Lo explicaré en 4 partes. [Compartir notas de estudio al final del artículo]

1. ¿Por qué la 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 del método de caso de prueba de interfaz, se proporciona un ejemplo.
4. Análisis de las dificultades que se pueden encontrar para asegurar la cobertura de las pruebas 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 se preocupan por la lógica interna de la interfaz. Simplemente diseñe diferentes combinaciones de parámetros como casos de uso según su propio entendimiento.

De hecho, el tema ya ha expuesto 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 relativamente 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:

以http协议为例

单接口：

  验证 URL
    * 针对URL 路径上存在一些特殊的path需要验证

  验证 查询参数，请求头、请求体参数
    * 针对参数：正则类的参数校验（正常和异常数据）
    * 针对业务：单接口功能覆盖（正向需求和反向需求）

  验证 响应数据
    * 正常接口响应覆盖
    * 异常接口响应覆盖（错误信息）

  验证 业务场景：
    * 覆盖应用的业务场景
    * 通过接口，模拟用户可能的操作流程

Este diseño de caja negra para pruebas de interfaz a menudo pasa por alto las siguientes cuatro categorías:

Clasificación de omisión 1. Omisión de escena causada por pruebas poco claras o no estándar

Si las ideas de diseño del caso de prueba de la interfaz no son claras o no son estándar, es fácil pasar por alto los escenarios. Es decir, como se mencionó anteriormente, hay omisiones en los escenarios que debe cubrir 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 variada 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. Y las tareas asincrónicas fallan, se reintentan y recuperan periódicamente estos procesos asincrónicos, que pueden pasarse por alto. Por lo tanto, reduce la cobertura del código.

2. La interfaz involucra transacciones

Cuando una interfaz involucra transacciones, el diseño de casos de prueba de interfaz convencional generalmente solo activa el proceso de transacción normal. Sin embargo, 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, también hay algunos escenarios de prueba que son fáciles de pasar por alto. Tome los bloqueos de lectura y escritura como ejemplo (coexistencia de lectura y lectura, no coexistencia de lectura y escritura y 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 estos escenarios están cubiertos, es difícil cubrir el escenario de esperar después de que el bloqueo haya caducado y no se haya podido 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é, es fácil ignorar el impacto del almacenamiento en caché en el diseño de casos de prueba de interfaz convencionales y no verifica específicamente el almacenamiento en caché de la interfaz. Esto también reduce la cobertura del código.

Clasificación de omisión 3. Ignorar escenas anormales

En teoría, cada interfaz puede tener escenarios anormales

Cuando hay algunos escenarios anormales en la interfaz, se lanza el error del marco, que generalmente no está permitido. En otras palabras, los programadores generalmente tienen que lidiar con escenarios anormales que pueden aparecer en la interfaz. Algunos escenarios son duros y difí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 el 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 el retorno de otros servicios puede expirar, y este servicio generalmente no espera todo. el tiempo.

Escenario 2: tiempo de espera de conexión de la 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 está almacenado 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.

Falta clasificación 4. Otros relacionados - configuración del 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 se puede cubrir, es necesario habilitar y probar al vendedor correspondiente para cubrir este tipo de código.
Configuración de tareas programadas
Establezca la política de ejecución de tareas programadas según la configuración. Algunas tareas programadas procesan datos en diferentes estados. Si no se prueba un determinado modo de tarea, o si la cobertura del estado de datos en un determinado modo está incompleta, se perderá la escena lateral. 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 permitir que los probadores que no entienden el código prueben mejor la interfaz y cubran 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 es una mejor solución. Medidas específicas: estandarice el método y el proceso de diseño de casos de uso, y los probadores básicos pueden ser competentes.

Solución 2. Cubrir puntos de bifurcación especiales, escenarios anormales y escenarios relacionados con la configuración del proyecto en la interfaz

Si desea cubrir estos escenarios a partir de casos de uso de diseño de interfaz, debe conocer y comprender estas lógicas comerciales. Para lograr este objetivo, se puede garantizar a partir de los siguientes 4 pasos.

Además de proporcionar documentos de interfaz, el desarrollo también proporciona documentos de implementación de interfaz , en los que se debe describir claramente el proceso de implementación de la interfaz. Por ejemplo, se deben explicar claramente los elementos de configuración, tareas asíncronas, transacciones, bloqueos, cachés, etc. involucrados en la interfaz. Lo mejor es poder generar un diagrama de flujo o un diagrama de tiempos. Esto es fundamental, puede ayudar en gran medida a los evaluadores sin código a comprender el negocio de la interfaz y los detalles de implementación.
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 aprender solos, los evaluadores pueden encontrar más desarrolladores correspondientes para comprender la implementación comercial.
Si los requisitos cambian o la implementación del negocio cambia, comunique y actualice los documentos relevantes de manera oportuna.
Los probadores diseñan casos de prueba en función de su comprensión de la implementación comercial para cubrir 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, se proporciona un ejemplo.

Ejemplo 1. Asincrónica task_take eliminación por lotes como ejemplo

Con el fin de brindar a los usuarios una buena experiencia en el proyecto, es muy común que algunas interfaces eliminen clases para tener 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), 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 supuesta de eliminar datos

eliminación por lotes

analizar:

Cobertura de casos de prueba de interfaz regular, 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 se desencadenan fácilmente cuando se llama a la interfaz.

Si el desarrollador proporciona este diagrama de flujo, el evaluador puede diseñar completamente el caso de prueba de acuerdo con el diagrama de flujo, cubriendo 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 (procesamiento como conflicto de clave principal)
- Modifique la cantidad de conexiones de la base de datos y ejecute la interfaz de eliminación en lotes
La ejecución de la tarea asíncrona falló
- Los datos de error se pueden preestablecer de antemano, lo que hace que la ejecución falle (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.

asuntos

analizar:

En el proceso de diseño de casos de prueba de interfaz, considere cubrir las excepciones en cada paso tanto como sea posible en todo el proceso comercial y diseñe diferentes escenarios de prueba para cubrir todo el proceso comercial.

Ejemplo de escenario:

Se produjo una excepción dentro de la transacción y la reversión se realizó correctamente.

Ejemplo 3. Bloqueo

En el proyecto, las operaciones de múltiples terminales también son relativamente comunes, como el lado web, el lado de la aplicación y el subprograma. Luego habrá algunos escenarios donde la interfaz opera en la misma parte de los datos .

Cerrar con llave

analizar:

Al diseñar casos de prueba de interfaz, considere escenarios relacionados con bloqueos para mejorar la cobertura del código.

Ejemplo de escenario:

adquirir bloqueo
- 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
  - Liberar el bloqueo con éxito
  - No se pudo liberar el bloqueo
- bloqueo de escritura
  - Liberar el bloqueo con éxito
  - No se pudo liberar el bloqueo

Ejemplo 4. Tarea programada

Si hay un proyecto que necesita procesar datos en lotes, generalmente se implementará a través de tareas cronometradas durante los períodos de menor actividad.

Por ejemplo: migración de versión de datos, limpieza de datos caducados, etc.

tarea cronometrada

analizar:

Al probar la interfaz del servidor, también se deben verificar estas tareas de temporización. Puede mejorar efectivamente la cobertura del código.

El énfasis principal aquí está en el estado de los datos de la ejecución de la tarea. Para garantizar la exhaustividad de los datos, la representación de datos de todo el ciclo de vida debe existir y debe ser de cierta magnitud, de modo que se pueda cubrir la lógica de procesamiento de la tarea. .

Ejemplo de escenario:

Si se inicia la tarea programada
Si se ejecuta la tarea programada
Antes de que se ejecute la tarea, ¿los datos son completos (cubriendo todos los tipos de datos a lo largo del ciclo de vida)?

4. Análisis de las dificultades que pueden surgir para garantizar la cobertura de las pruebas de interfaz

Dificultad 1. El documento de implementación de la interfaz proporcionado por el desarrollo no está estandarizado

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. Tener medidas de control.

Dificultad 2. Los probadores tienen dificultad para entender

Los documentos deben 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. El caso de uso diseñado no se puede probar

Hay algunos escenarios anormales, 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 implementar. No puedo probar, principalmente debido a mi falta de habilidades. Por lo tanto, el caso de uso normalmente se diseña y la ejecución del caso de uso puede ser asistida por un jefe.

V. Resumen final

requisitos de implementación específicos

- Los desarrolladores transforman la lógica de implementación de la interfaz de ideas de código en descripciones de documentos. 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 su aprendizaje a través de la lectura de documentos, el aprendizaje de revisión, el desarrollo de consultoría y la comprensión de la implementación comercial.
- Los probadores obtienen una comprensión profunda del negocio, luego diseñan escenarios de prueba más completos e implementan las pruebas.

significado

- Se mejora la cobertura del código y, naturalmente, el proyecto se prueba de forma más completa. Se pueden encontrar más problemas ocultos.
- Puede permitir que los evaluadores sin capacidad de codificación crezcan rápidamente y realicen pruebas bien.
- Estandariza el proceso de desarrollo e implementación, y también promueve el desarrollo y la gestión del proyecto.

defecto

- Será difícil de implementar al principio, especialmente en operaciones interdepartamentales.
- Hay más costos de comunicación para las pruebas y el desarrollo.

Finalmente, me gustaría agradecer a todos los que leyeron mi artículo detenidamente. Observando el ascenso y la atención de los fanáticos durante todo el camino, siempre existe la necesidad de un intercambio de cortesía. Aunque no es algo muy valioso, si puede usarlo, Puedes tomarlo directamente.

Estos materiales deben ser el almacén de preparación más amplio y completo para los amigos que hacen [pruebas de software]. Este almacén también me ha acompañado a través del viaje más difícil. ¡Espero que también pueda ayudarlos! Todo debe hacerse lo antes posible, especialmente en la industria de la tecnología, y la base técnica debe mejorarse. Espero ser de ayuda…….