Como prueba, el número de defectos encontrados y la gravedad de los defectos se pueden utilizar como un indicador importante para medir su capacidad. Entonces, ¿cómo podemos encontrar tantos permisos como sea posible y cómo podemos encontrar defectos con alta gravedad antes? Mi entendimiento es confiar en el diseño de casos de prueba.
Como prueba, una de las tareas diarias más comunes es diseñar casos de prueba ¿Qué tipo de casos de prueba son buenos casos de prueba? Tengo entendido que cuantos menos casos de uso y más defectos se encuentren son buenos casos de uso. Los buenos casos de uso están diseñados y son una colección de ideas y métodos de los probadores, no una lista de la lógica y los requisitos de prueba.
Entonces, la pregunta es, ¿cómo podemos diseñar buenos casos de prueba?
1. Varias pautas para el diseño de casos de prueba 1. Diseño de casos de uso = ideas. Enfatice los escenarios de prueba y los métodos de prueba.
2. Prueba paso a paso. Los pasos de prueba mencionados aquí no significan que cada caso de prueba deba especificar los pasos de prueba, sino que se refieren a las áreas donde aparecerán defectos a través del ajuste de los pasos de prueba, y los pasos de prueba deben enfocarse, como agregar operaciones. Simplemente agregar funciones está bien. Sí, pero primero borre un dato, y falla después de agregar los mismos datos. Esto implica pasos operativos.
3. Flujo de casos de uso. Este proceso se basa en un diagrama de flujo comercial completo. Cada sucursal es un afluente. Las solicitudes iniciadas por el negocio final eventualmente fluirán a una sucursal. El proceso consiste en clasificar estas sucursales en escenarios de prueba y cubrir la lógica empresarial cubriendo los escenarios de prueba. .
En segundo lugar, los pasos del diseño de un caso de prueba:
1. Identificar los requisitos originales.
El requisito original es el requisito del usuario (cliente) del software. Solo cuando la base del documento de requisitos + la comprensión esencial puede comprender realmente qué es el requisito para lograr, y utilizar esto como un punto de partida para no desviarse de la esencia del requisito
2. Divida el requisito original.
En la fase de prueba de requisitos, si clasifica los requisitos de acuerdo con la estrategia de prueba de requisitos, debe tener una idea clara de todos los puntos de requisitos. Enumere los puntos de requisitos en esta parte y puede usarlos como puntos de prueba de requisitos aproximados ;
3. Ordene la lógica empresarial.
Hoy en día, más servicios front-end se derivan de los datos devueltos por la interfaz. La mayor parte del front-end es mostrar y calcular algunas respuestas en función de los datos devueltos. Por lo tanto, si diseña casos de prueba para la página, debe pagar atención a la integridad y corrección de los datos de la interfaz El impacto del género en la página y la prueba de la interfaz en sí deben resumirse en el enlace de diseño del caso de prueba de la interfaz.
(1). Cómo manejar la página cuando la interfaz no devuelve datos;
(2). Los parámetros devueltos por la interfaz están incompletos, por ejemplo, el paquete de devolución tiene una estructura de lista, que se utiliza como base para mostrar los datos de la lista en primer plano, pero la lista está vacía;
(3). La interfaz devuelve el nombre del parámetro que no se requiere en el paquete
Hay un principio en este lugar al que se debe prestar atención, es decir, la separación de front-end y back-end y la recopilación de pruebas de front-end y back-end.
(1) Los extremos frontal y posterior están separados, y hay probadores de interfaz dedicados para garantizar la corrección de las funciones de la interfaz. En este momento, como probador de front-end, solo necesita asegurarse de que la página se muestre correctamente cuando los datos devueltos por la interfaz sean correctos; cuando los datos devueltos por la interfaz sean anormales, la página se muestra correctamente; los datos de la interfaz de llamada es correcta;
(2) La mitad frontal y posterior están separadas, y la interfaz también se realiza. Pruebas, pero utilizando herramientas automatizadas para garantizar la corrección y permeabilidad de los parámetros básicos, y la lógica de la interfaz debe ser probado en la etapa anterior. En este momento, como probador de front-end, debe comprender la lógica de implementación de la interfaz, como la lógica de procesamiento de datos, la estructura de almacenamiento, etc. En base a esto, se diseñan los casos de prueba de front-end y, si es necesario, se debe omitir el front-end y se llama directamente a la interfaz para simular la prueba de front-end.
En resumen, el nivel de comprensión de la lógica empresarial depende de la estructura de la empresa. Después de comprender la lógica empresarial, complemente los puntos de prueba de la lógica empresarial correspondientes a los puntos de demanda.
4. Distinguir entre pruebas de página y pruebas de lógica empresarial
4.1. Las pruebas de nivel de página siguen los siguientes métodos:
(1). Prueba de interfaz general: para verificar si la interfaz general es consistente con el dibujo de diseño;
(2). Prueba de elemento de interfaz:
( 3). Verificación de la operación de control: como la verificación de si el control se puede operar y si la operación es normal;
4.2. La prueba del nivel de lógica empresarial (función) sigue los siguientes métodos:
(1). Se debe utilizar el método de análisis de límites en cualquier caso, y hay un problema La mayoría está en el valor límite;
(2). Si es necesario, use el método de división de clases de equivalencia para complementar algunos casos de prueba;
(3). Use la especulación de errores para agregar algunos casos de prueba;
(4 ). Compruebe que se ha diseñado la lógica del programa. Si la cobertura lógica de los casos de prueba no cumple con el estándar de cobertura requerido, deben agregarse suficientes casos de prueba.
Ahora, el software casi siempre utiliza la activación de eventos para controlar el proceso. La escena en la que se produce el evento se activa forma una escena, y el mismo evento Las diferentes secuencias de activación y los resultados del procesamiento forman una secuencia de eventos.
Grupo de intercambio de pruebas de software: 785128166
Cuenta pública de WeChat: Programador Erhei; Después de prestar atención, puede recibir un conjunto de recursos de video de forma gratuita; explique en detalle: pruebas automatizadas de Python, automatización web, automatización de interfaces, automatización de terminales móviles, experiencia de entrevistas y otro contenido relacionado, el valor de los recursos de aprendizaje dependen de su acción, no sea un "coleccionista"
Aquí hay una colección de artículos de productos secos seleccionados para pruebas funcionales: