1. ¿Qué es una interfaz?
Interfaz: principalmente la parte que interactúa e interactúa entre submódulos o subsistemas.
La interfaz mencionada aquí es, en un sentido amplio, el protocolo entre el cliente y el servicio back-end; la interfaz de comunicación entre complementos; la interfaz entre módulos; los métodos proporcionados por una clase pueden entenderse como interfaces.
Prueba de interfaz: se refiere a la prueba de la interfaz entre módulos o sistemas.
2. Errores y problemas que se encuentran a menudo en las pruebas de interfaz
(1) Manejo inadecuado de los parámetros entrantes, lo que hace que el programa se bloquee;
(2) Desborde de tipos, lo que resulta en lectura y escritura de datos inconsistentes;
(3) Los permisos de objeto no se han verificado Puede acceder a información sensible de otros usuarios;
(4) Manejo inadecuado del estado, lo que genera confusión en la lógica;
(5) Verificación lógica incompleta y aprovechamiento de lagunas para obtener beneficios ilegítimos.
3. Ideas de diseño de casos de uso El diseño de casos de uso de las
pruebas de interfaz considera principalmente tres aspectos del procesamiento de entrada y de interfaz, y de salida:
(1) Para la entrada, se puede diseñar de acuerdo con el tipo de parámetro;
(2) Para el procesamiento de interfaz, se puede diseñar de acuerdo con la lógica;
(3) Para la salida, el análisis y el diseño se pueden llevar a cabo en función de los resultados.
3.0 Plantilla de caso de uso
3.1 Diseño de entrada
Para una interfaz, la entrada es un parámetro de entrada. Los tipos de parámetros comunes son:
(1) Tipo numérico (int, long, float, double, etc.)
(2) Tipo de cadena
(3) Matriz o lista vinculada
(4) La estructura de
estructura (struct) es una combinación de algunos elementos, los elementos reales También es numérico, de cadena, matriz o lista vinculada.
A continuación se describe en detalle el diseño de casos de uso de tres tipos de parámetros: numérico, cadena, matriz o lista vinculada.
3.1.1
Parámetros numéricos Los parámetros numéricos consideran principalmente los siguientes aspectos del diseño:
si el parámetro especifica el rango de valores, debe considerar el rango de valores de la clase de equivalencia, fuera del rango de valores, y el límite del valor. Si es necesario, Puede atravesar los valores en el rango de valores.
Por ejemplo, la interfaz para verificar los permisos: TaskChecker.checkTask (int taskID) El rango de valores de taskID es 1-35, luego el diseño considera:
1-35范围内和范围外的值；
1-35的边界：0，1,35,36；
**类型的特殊值：-1,0
数据类型的边界值：int的最小值最大值；**
因为1-35代码的权限ID不同，可能需要遍历1-35的每个值。
Problemas y riesgos comunes: el
manejo inadecuado de valores especiales hace que el programa se cierre de manera anormal; el
límite de tipo desborda el
valor fuera del rango de valores no devuelve información de error correcta, etc.
3.1.2 Tipo de
cadena Los parámetros de tipo de cadena consideran principalmente la longitud y el contenido de la cadena :
por ejemplo, la interfaz DateUtil.getDayOfDDHH (String ddhh), que es el reloj de alarma de configuración de conversión de interfaz, se puede considerar
para casos de uso: la longitud es de 4 dígitos, que es menos de 4 dígitos. Más de 4 dígitos;
valor límite: la longitud máxima de la cadena;
valor especial: carácter vacío; el
tipo de contenido de la cadena se puede considerar: número, no número;
carácter especial.
**如果是输入用户输入且其他用户可见的内容，则还需要考虑敏感字是否被正常过滤。**
Posibles problemas y riesgos: El
tipo de programa no específico entrante sale de forma anormal. Los
caracteres ultralargos no se procesan, lo que resulta en un almacenamiento y visualización anormales.
Otros caracteres sensibles que son visibles para el usuario.
3.1.3 Tipo de matriz o lista vinculada
Cuando el tipo de parámetro es una matriz o una lista vinculada, se pueden considerar casos de uso:
por ejemplo, la interfaz submitTask (int [] ID de tarea) para el envío de tareas por lotes, consideraciones de diseño de casos de uso de parámetros:
valor normal: 1-5 permisos, fuera de rango: 6 permisos;
valor límite : El valor límite de 1-35, la solicitud permite los valores máximo y mínimo;
valor especial: 0;
ID legal e ilegal;
ID duplicado, etc.
Posibles problemas y riesgos: el
programa se cierra de forma anormal cuando hay 0 elementos; el
resultado es anormal si los elementos duplicados no se eliminan durante el procesamiento.
3.2 Para el diseño lógico Si la
interfaz necesita algún procesamiento lógico, entonces el caso de uso del diseño lógico se puede analizar desde las siguientes perspectivas.
3.2.1 Análisis de las condiciones de restricción
(1) Restricciones numéricas: restricciones de puntuación, restricciones de monedas de oro, restricciones de nivel, etc.
Por ejemplo: el intercambio de monedas Q requiere puntos> 50 para participar.
(2) Restricción de estado: estado de inicio de sesión, etc.
Por ejemplo: para sincronizar la información del usuario, primero debe iniciar sesión en su cuenta.
(3) Restricciones de relación: relación ligada, relación de amistad, etc.
Por ejemplo, la función antifraude para miembros de la familia solo puede consultar la información de llamadas entrantes de miembros de la familia vinculados.
(4) Restricciones de permisos: administradores, etc.
Las pruebas de restricción se encuentran a menudo en pruebas funcionales y son más importantes en las pruebas de interfaz. Su importancia es que cuando el usuario realiza una operación, la condición de restricción puede haberse realizado en la parte frontal de la operación, por lo que el usuario no puede activar directamente la solicitud de esta interfaz. Pero, de hecho, si existen otros medios: como errores en la interfaz de usuario o llamadas directas a la interfaz a través de medios técnicos, entonces es particularmente importante si la interfaz está restringida para estas condiciones.
Por ejemplo, un ejemplo común: se necesitan 200 puntos para intercambiar monedas 5Q, pero no tengo suficientes puntos, por lo que el botón de canje es gris y no se puede hacer clic:
Los usuarios normales no pueden operarlo, pero el intercambio es en realidad una interfaz del backend. ¿Si omite la restricción de los botones de la página y llama directamente a la interfaz del backend para intercambiar? ¿Se puede canjear? Por supuesto, las expectativas no son convertibles. Por lo tanto, el límite numérico de la integral debe probarse para la interfaz, y es muy importante.
Otras restricciones son similares:
restricción de tiempo: antes de las 22:00;
restricción numérica: 200 puntos; límite de 5;
restricción de estado: iniciar sesión en el administrador de teléfonos móviles;
y otras restricciones son similares.
Problemas y riesgos comunes:
Juicio insuficiente de las condiciones de restricción, lo que lleva a los usuarios a obtener beneficios a través de medios especiales.
3.2.2 Análisis del objetivo de la
operación La operación suele estar dirigida al objetivo, por ejemplo, el usuario vincula un número de teléfono, el número de teléfono es el objetivo de la operación y las tarifas de llamada y el tráfico de este número de teléfono también son el objetivo.
El análisis de objetos es principalmente para operar con objetos legales e ilegales. Por ejemplo, el siguiente caso de uso: el
usuario A pregunta sobre la factura telefónica de P1: el
usuario A pregunta sobre el tráfico del teléfono P1; el
usuario A pregunta sobre la factura telefónica del teléfono P2; el
usuario A pregunta sobre el tráfico del teléfono P2.
En el procesamiento lógico en segundo plano, si se ha vinculado un teléfono, la factura del teléfono y el tráfico se pueden consultar desde el punto de vista del segundo plano. Pero en el lado del usuario, debería ser el teléfono vinculado a A, para que A pueda preguntar sobre el cargo de llamada del teléfono. Por lo tanto, la prueba de objetos similares también es esencial.
Problemas y riesgos comunes: los
usuarios pueden acceder a otra información del usuario e información sensible que no está dentro de la autoridad, para usar esta información para obtener beneficios
3.2.3 Análisis de transición de estado
La lógica bajo prueba se puede abstraer en una máquina de estado, y cada estado cambia de un estado a otro según la lógica funcional. Si interrumpimos esta secuencia y cambiamos de un estado a otro que no está en el siguiente, entonces la lógica se interrumpirá y se producirán problemas de lógica.
El cambio de un determinado estado a un nuevo estado depende de la interfaz de transición. Para una interfaz de conversión, se determina el estado de entrada, como Fun23, esta función solo puede convertir el estado 2 en el estado 3, pero no el estado 1 en el estado 3. Entonces, los puntos de prueba pueden ser:
(1) Cuando el estado es el estado 2, llame a la interfaz Fun23 () y el estado cambia al estado 3;
(2) Cuando el estado es 1, 3, etc., llame a la interfaz Fun23 () y el estado no se puede cambiar.
Por ejemplo, cuando se realiza una tarea, la tarea tiene tres estados: no recibido, recibido pero no enviado y completado.
Entonces se puede diseñar así:
(1) Cambio de estado normal: estado no reclamado, después de recibir la tarea, se convierte en el estado recibido; después de recibir la tarea y enviarla, se convierte en el estado completado; después de completar la tarea, puede recibir la tarea nuevamente.
(2) Cambio de estado anormal: envíe la tarea sin recibir la tarea y cumpla con las condiciones de la tarea; recibiendo la tarea nuevamente cuando se haya recibido, etc.
Problemas y riesgos comunes:
se pueden utilizar métodos especiales para lograr un estado que de otro modo sería imposible, buscando así beneficios.
3.2.4 Análisis de secuencia temporal
En algunas actividades complejas, una actividad se lleva a cabo mediante una serie de acciones en un orden específico, estas acciones forman un flujo de acciones, solo ejecutando en este orden se puede obtener el resultado esperado.
En el proceso normal, estas acciones se llevan a cabo secuencialmente de acuerdo con la llamada del programa, y no serán interrumpidas En la prueba de interfaz, es necesario considerar si habrá problemas si no se instala la temporización.
Por ejemplo, el cliente activa la sincronización de datos del cliente, durante la cual el usuario no puede intervenir en la sincronización. Lo que se puede ver durante la prueba funcional es si la sincronización se puede realizar con normalidad, y un análisis más detallado, el proceso de sincronización en realidad implica un conjunto de acciones:
Puede verse en el diagrama de secuencia que hay 3 interfaces en segundo plano: iniciar sesión para obtener el ID de usuario, informar datos locales e informar conflictos locales. Las tres interfaces deben llamarse y ejecutarse en secuencia para completar la sincronización. Luego, en la prueba de interfaz, puede considerar interrumpir la secuencia de ejecución de las interfaces anteriores para ejecutar, cuál será el resultado y si habrá una excepción. Por ejemplo: después de obtener el ID de usuario, los datos locales no se informan pero el conflicto local se informa directamente.
Problemas y riesgos comunes: después
de la ejecución no secuencial, los datos serán anormales y también pueden aparecer otras anormalidades del programa.
Obtenga beneficios al interrumpir el orden
3.3 Diseño para salida Diseñar
para salida es en realidad analizar los resultados devueltos por la interfaz.
3.3.1 Para el resultado de salida
Puede que solo haya un resultado correcto del procesamiento de la interfaz, pero hay muchos casos y muchos valores en el resultado de devolución de la excepción de error. Si sabe que hay muchos tipos de resultados, puede diseñar casos de uso para diferentes resultados. Por ejemplo, cuando enviamos una tarea integral, generalmente pensamos en devolver la corrección y el error. Los errores pueden pensar en: tarea no válida, estado de inicio de sesión no válido, pero es posible que no pueda cubrir completamente todos los códigos de error, y la interfaz devuelve el código de retorno definido para diseñar más Ejemplo:
Anular el código de retorno también es una idea del diseño de casos de uso.
Problemas y riesgos comunes:
(1) El procesamiento insuficiente de errores en el front-end genera excepciones en el front-end;
(2) El manejo inadecuado de los mensajes de error hace que los usuarios vean códigos de error oscuros;
(3) Los mensajes de error incorrectos hacen que los usuarios no sepan qué salió mal, Cómo resolver.
3.3.2 Tiempo de espera de la
interfaz La interfaz normalmente regresa, entonces, ¿qué pasa si la interfaz no regresa? Es decir, el procesamiento después del tiempo de espera de la interfaz también es una parte de la prueba que debe considerarse. Si el tiempo de espera no se maneja correctamente, puede causar los siguientes problemas:
(1) No se realizó ningún procesamiento de tiempo de espera, lo que provocó el bloqueo de todo el proceso
(2) Después del tiempo de espera, se recibió la interfaz devuelta, lo que provocó una confusión lógica
3.4 Otro diseño de prueba
3.4.1 Prueba de interfaz
obsoleta El protocolo obsoleto se refiere a la definición anterior, pero debido a cambios en los requisitos u otras razones, no se utiliza la versión actual. Aunque estas interfaces ya no se utilizan, es posible que el código no se haya eliminado a tiempo. Si utiliza medios técnicos para llamar a estas interfaces, puede obtener beneficios adicionales.
Por ejemplo, si hay una tarea de limpieza antes de la tarea, reemplace la tarea de limpieza con una tarea de descarga en un requisito de versión. En la nueva versión del cliente, la interfaz para completar la tarea de limpieza ya no se llama; pero si la interfaz no está cerrada, el usuario puede continuar solicitando la interfaz submitTask (int taskID) para completar la tarea de limpieza y ganar puntos.
Por lo tanto, al considerar la compatibilidad con la versión anterior, la nueva versión también debe verificar las interfaces obsoletas relacionadas para evitar que los usuarios obtengan beneficios adicionales.
3.4.2 Análisis de la racionalidad del diseño de
la interfaz Si la definición de la interfaz es razonable se puede analizar a partir de los siguientes aspectos:
(1) Si los campos de la interfaz son redundantes;
(2) Si la interfaz es redundante;
(3) Si la interfaz devuelve la información esperada por el llamador. ;
(4) si la definición de la interfaz para satisfacer las necesidades de todas las llamadas;
(5) si la definición de la interfaz conveniente para la llamada.
3.5 Un ejemplo completo
El siguiente es un ejemplo completo para analizar cómo utilizar el diseño de la interfaz a través del método anterior.
Un módulo proporciona una interfaz a otros módulos y los usuarios solicitan tareas. La interfaz se define de la siguiente manera:
4. Resumen
En el método de diseño de casos de uso de la interfaz, el diseño de entrada y salida es universal y ambos están disponibles durante el diseño de la interfaz. Para el diseño de la lógica de la interfaz, se pueden aplicar uno o más métodos adecuados Al diseñar los casos de uso de la interfaz, se debe seleccionar el método más adecuado para cubrir la lógica bajo prueba.