La recopilación de datos y los informes solo contarán cómo se diseñan los casos de prueba cada dos días.

Primero: La base es clara.

Como todos sabemos, primero se establece un proyecto y luego se analizan los requisitos a través de una serie de acciones. Después del análisis de requisitos de anoche, se pueden realizar pruebas para probar los requisitos y luego se pueden escribir casos de prueba. Por lo tanto, la base para escribir casos de prueba son los requisitos. Eso es demasiado general. Da un ejemplo. Un sistema pasa por una serie de acciones como análisis de requisitos, diseño detallado y diseño de módulos en la etapa inicial, y finalmente genera descripciones detalladas de requisitos y documentos de diseño detallados. En estos documentos se describen detalladamente todos los puntos de requisitos y funciones, así como descripciones técnicas detalladas. El siguiente trabajo es cómo convertir estos puntos de función y puntos de demanda en puntos de prueba. Esto requiere un buen análisis de la demanda de prueba y un buen plan de prueba para generar puntos de prueba comprobables. Esto también refleja la necesidad de mensurabilidad.

Supongamos que después del trabajo preliminar, se analiza que el sistema tiene 5 módulos, 50 puntos de función principal, 500 puntos de demanda específicos y finalmente se generan 5000 puntos de prueba. Bien, entonces escribiremos 5000 casos de prueba. En tercer lugar, un caso de prueba solo puede corresponder a un punto de prueba, y la relación entre los puntos de prueba y los casos de uso es de 1 a 1. Un punto de demanda puede corresponder a múltiples casos de uso, y la relación entre los puntos de prueba y los casos de uso es de 1 a muchos; . El propósito de esto es estadísticamente hablando.

Segundo: Propósito claro

El caso de uso tiene un propósito de prueba, es decir, tiene un propósito claro y un solo propósito. No importa cuántos pasos hayan dado antes, todos están tratando de encontrar el camino hacia este objetivo. Las funciones tienen niveles de mayor a menor, y lo mismo ocurre cuando hacemos casos de prueba. De lo contrario, ¿cómo definir la prioridad de los casos de uso? Al probar el punto de función más pequeño, todos los demás puntos de función de la capa superior que admiten este punto de función son correctos de forma predeterminada. Esta es nuestra expectativa, por lo que en el paso de prueba no necesitamos considerar los datos de prueba específicamente para la función de la capa superior. , solo necesitamos Como forma correcta de encontrar el punto de función actual. En otras palabras, el punto de función que desea probar requiere 10 conexiones para encontrarlo, por lo que deberíamos haber diseñado los casos de uso para las primeras 9 conexiones antes, y está bien corregir de forma predeterminada en 10 conexiones. Los primeros 9 pasos de este caso de uso solo le indican cómo encontrar el paso 10. Eso es todo.

En tercer lugar, es conveniente para las estadísticas.

Los casos de prueba son de gran importancia para el control de calidad y la evaluación de todo el proceso de prueba.

En primer lugar, puede realizar un análisis de cobertura de requisitos de prueba. De esta manera, si se escriben varios puntos de prueba para un caso de uso, el análisis de cobertura de requisitos no se puede completar, o al menos va en contra de las reglas.

En segundo lugar, realice un análisis de la tasa de éxito del caso de uso. Un caso de uso con múltiples puntos de prueba definitivamente reducirá la cantidad de casos de uso y aumentará en gran medida la tasa de falla de los casos de uso. Entonces, ¿qué significa la tasa de éxito de sus casos de uso?

También puede analizar qué módulo tiene más problemas a través de la división de módulos, y puede haber más problemas (porque diferentes programadores tienen diferentes habilidades y a los defectos les gusta distribuirse juntos, como todos saben). Los módulos con más problemas requieren más pruebas o son el foco del siguiente paso de prueba. Si sus estadísticas son inexactas, los resultados serán engañosos.

En tercer lugar, realizar un análisis de defectos. Si un caso de uso falla, se produce un defecto. Si se escriben varios puntos de prueba en un caso de uso, estos puntos de prueba también se devolverán cuando se devuelvan, y usted también devolverá algunos puntos de prueba que pueden no estar relacionados con defectos.

Con más detalle, me gustaría presentarles el sitio web del China IT Laboratory, que tiene mucha información.