Compilación de casos de prueba para el software Python que supera los bytes que acaba de terminar (incluidas las ideas)

La redacción de casos de prueba es la habilidad básica de las pruebas de software; mucha gente piensa que los casos de prueba son el núcleo de las pruebas de software; lo más importante en las pruebas de software es diseñar y generar casos de prueba efectivos; los casos de prueba son la guía para el trabajo de prueba y son necesarios para las pruebas de software Pautas a seguir.

Aquí no discutiremos los diversos puntos de vista anteriores, pero en resumen, puede ver que la habilidad blanda de la escritura de casos de prueba es muy importante y una habilidad necesaria para los probadores.Creo que muchas personas no tienen dudas.

A continuación presentamos la redacción de casos de prueba.
Dividimos la escritura de casos de uso en dos categorías: escritura de casos de uso de caja negra y escritura de casos de uso de caja blanca.

Inserte la descripción de la imagen aquí

La idea general de escribir el título:

Caso de prueba de caja negra (prioridad) + caso de prueba de caja blanca (suplementario) = caso de prueba completo

Estrategia de escritura general:

Para la redacción de casos de prueba, los cuatro métodos comúnmente utilizados son básicamente suficientes, clase de equivalencia, valor límite, método de experimento ortogonal, método de inferencia de error, complementado con método de prueba de escenario, método de conversión de demanda / diseño e ideas de prueba exploratoria , Puede manejar la prueba de la mayoría de los productos. Los productos individuales también deben refinarse y expandirse en cierto punto, y deben discutirse al respecto.

Estrategia de diseño integral utilizando varios métodos de escritura;

1) El método de análisis de valor límite debe usarse en cualquier situación La experiencia muestra que el uso de este método para diseñar casos de prueba tiene la mayor capacidad para encontrar errores de programa.
2) Utilice métodos de división de clases de equivalencia para complementar algunos casos de prueba cuando sea necesario, prestando especial atención a las clases de equivalencia no válidas.
3) Si la descripción de la función del programa contiene una combinación de condiciones de entrada, el método de diagrama de causalidad (o método de tabla de juicio, método de prueba ortogonal) se puede seleccionar desde el principio.
4) Utilice la especulación de errores para agregar algunos casos de prueba, principalmente utilizando la experiencia de prueba.
5) Verifique la cobertura lógica de los casos de prueba diseñados con la lógica del programa. Si no se cumplen los estándares de cobertura requeridos, se deben agregar suficientes casos de prueba; consulte la preparación de casos de uso de caja blanca.
6) Investigar y pensar en los escenarios de aplicación del programa, y ​​agregar casos de prueba en diferentes escenarios; se debe prestar atención a las pruebas del escenario del usuario. Una gran parte de los errores del programa son causados ​​por la diferencia entre el escenario de prueba y el escenario real del usuario.
7) Después de tener una comprensión más profunda de los negocios y los procedimientos, puede dar rienda suelta al pensamiento divergente y al pensamiento exploratorio; no malinterprete las pruebas exploratorias como pruebas sin objetivo. De hecho, las pruebas exploratorias tienen ideas de orientación de prueba muy detalladas.

Parte 1: Escritura de casos de uso de caja negra

Los métodos habituales son los siguientes:

(1) Clase de equivalencia

(2) Valor límite

(3) Diagrama de causa y efecto

(4) Método basado en la tabla de decisiones

(5) Método de experimento ortogonal

(6) Método de mapa de funciones

(7) Método de experimento de escena

(8) Método de inferencia de errores

(9) Transformación de la demanda

(10) Documentos de diseño

(11) Pruebas exploratorias

1. Equivalente a caja negra

Clase de equivalencia: seleccione algunos datos representativos, este tipo de datos es equivalente a otros valores de este tipo, busque el subconjunto más pequeño, puede encontrar la mayor cantidad de errores;

Dos características principales: casos de uso que deben diseñarse, cubren la mayoría de los casos;

Dos tipos de situaciones: clase de equivalencia efectiva, clase de equivalencia no válida;

Convertido en casos de prueba

1. Establecer una lista de clases de equivalencia de acuerdo con las condiciones de entrada, clases de equivalencia válidas y clases de equivalencia no válidas, y enumerar todas las clases de equivalencia;

2. Fije un número para cada clase de equivalencia;

3. Diseñar un caso de prueba para cubrir una o más clases de equivalencia efectivas;

4. Diseñar uno o más casos de prueba para cubrir las restantes clases de equivalencia efectiva;

Escenario de uso: condiciones de entrada (rango de valores / número de valores; valor obligatorio establecido; valor booleano; un conjunto de valores de procesamiento; reglas que deben seguirse; subdividir clases de equivalencia más pequeñas;)

Ejemplos de clases de equivalencia:

Tome la prueba del triángulo como ejemplo: ingrese 3 números enteros como los tres lados del triángulo y determine el tipo de triángulo a través del programa.

Inserte la descripción de la imagen aquí

2. Valor de límite de caja negra

Valor límite: La llamada condición límite se refiere a aquellos estados en las clases de equivalencia de entrada y salida que están exactamente en el límite, exceden el límite o por debajo del límite;

Dos características: seleccione uno o más elementos para que se hayan probado todos los límites de la clase de equivalencia; en lugar de centrarse solo en las condiciones de entrada, también debe considerar el espacio de resultados (clase de equivalencia de salida) para diseñar casos de prueba;

Las condiciones de contorno pueden ser muy delicadas, por lo que se necesita mucho esfuerzo para determinarlas;

Escenario de uso: Es necesario considerar la entrada + la salida (rango de valores; número de valores; conjunto ordenado; estructura interna de datos; especificaciones de análisis;)

Ejemplos de valores límite:

Tome la prueba del triángulo como ejemplo: ingrese 3 enteros como los tres lados del triángulo, 1 <a, b, c <10, y determine el tipo de triángulo a través del programa;

Inserte la descripción de la imagen aquí

3. Diagrama causal de caja negra

Diagrama de causa y efecto: ingrese una combinación de condiciones para el análisis. Utilice un método sistemático para seleccionar un conjunto eficiente de casos de prueba;

análisis de idea:

1. Analizar la descripción de la especificación, determinar la causa y el resultado, y asignar un identificador;

2. Analizar la semántica de la especificación, averiguar la relación entre causa y causa, y entre causa y efecto, y dibujar un diagrama de causa y efecto;

3. La combinación de algunas causas y causas, o entre causas y resultados, no aparecerá Use letreros para indicar restricciones o condiciones restrictivas;

4. El diagrama de causa y efecto se convierte en una tabla de juicio;

5. Diseñar casos de prueba basados ​​en cada columna de la tabla de juicio;

Escenario de uso: se deben considerar varias combinaciones de condiciones de entrada (una forma adecuada para describir una combinación de múltiples condiciones y, en consecuencia, generar múltiples acciones para el diseño);

4. Cuadro de juicio de caja negra

Tabla de juicio: una herramienta para analizar y expresar la situación de realizar diferentes operaciones en múltiples condiciones lógicas; omitir el dibujo del diagrama de causa y efecto y enumerar directamente todas las combinaciones para la selección;

Idea de análisis: la tabla de decisiones generalmente consta de cuatro partes: pila de condiciones, pila de acciones, elemento de condición y elemento de acción;

Pasos para establecer la tabla de juicio: (según la especificación del software)

Determine el número de reglas; enumere todas las condiciones y las acciones en juego; complete los elementos de condición; complete los elementos de acción para obtener la tabla de juicio inicial; simplifique y combine reglas similares;

== Escenario de uso: clases de control y juegos. La ventaja es que los problemas complejos se pueden enumerar uno a uno según las diversas situaciones posibles, concisos y fáciles de entender, y también se pueden evitar omisiones. La desventaja es que no puede expresar acciones repetidas, como estructuras de bucle.

5. Método de prueba ortogonal de caja negra

Método de experimento ortogonal: cuando se utilizan diagramas de causalidad para diseñar casos de prueba, la relación causal entre las razones de entrada y los resultados de salida a veces es difícil de obtener a partir de la especificación de requisitos de software; a menudo, la relación de causalidad es tan grande que el número de casos de prueba es enorme. Para reducir de manera efectiva y razonable las horas de trabajo y los costos de prueba, se pueden utilizar métodos de diseño experimental ortogonal para diseñar casos de prueba.

análisis de idea:

(1) Extraiga la descripción de la función, la tabla de estado de factor de estructura;

(2) Selección ponderada, tabla de análisis factorial de generación;

(3) Utilice la tabla ortogonal para construir el conjunto de datos de prueba;

Escenario de uso: se deben considerar varias combinaciones de condiciones de entrada (elija puntos apropiados y representativos de una gran cantidad de datos, pruebas razonables y efectivas);

6. Método de experimento de escena de caja negra

Método de experimento de escena: el software casi siempre se activa mediante un evento para controlar el proceso. La escena en la que se activa el evento forma una escena, y diferentes secuencias de activación y resultados de procesamiento del mismo evento forman un flujo de eventos; representan vívidamente la escena cuando se activa el evento. Propicia para el diseño de casos de uso, y los casos de prueba son más fáciles de entender y ejecutar.

análisis de idea:

Cada camino refleja el flujo básico y el flujo alternativo, el flujo básico es el camino más simple, el flujo alternativo parte del flujo básico y se agregará y ejecutará bajo ciertas condiciones Puede haber muchas situaciones;

Escenario de uso (0 significa flujo básico): 0; 0 + 1; 0 + 1 + 2; 0 + 3; 0 + 3 + 1; 0 + 3 + 1 + 2; 0 + 4; 0 + 3 + 4; ...

Inserte la descripción de la imagen aquí

7. Método de inferencia de errores

Método de inferencia de errores: basado en la experiencia y la intuición para inferir todos los posibles errores en el programa, con el fin de diseñar casos de prueba de manera focalizada; se basa principalmente en los hábitos del usuario y problemas comunes en el programa de prueba.

análisis de idea:

(1) Enumere todos los posibles errores en el programa y situaciones especiales que son propensas a errores, y seleccione casos de prueba basados ​​en estas situaciones;

(2) Preste atención a la acumulación y al intercambio;

Escenario de uso: un método que se utilizará en cualquier prueba y en cualquier escenario.

Existe un conjunto de casos de prueba de uso común como referencia.

Ejemplo: verificación de entrada digital, números de entrada (número positivo, número negativo, valor cero, precisión simple, precisión doble), cadena, valor en blanco, valor nulo, valor crítico respectivamente; para entrada ilegal, el sistema proporcionará la información necesaria para el juicio. ;

8. Método de conversión de caja negra-demanda

Método de transformación de requisitos: de acuerdo con los requisitos, realice análisis de requisitos y escriba casos de prueba.

análisis de idea:

(1) Convertir la demanda en un mapa mental;

(2) Considere cuidadosamente el significado de cada palabra;

(3) Combinar con los escenarios y propósitos de uso del usuario;

(4) Diseñe estrictamente cada caso de uso;

(5) Se puede establecer un modelo para la conversión de la demanda;

Escenario de uso: un método que se utilizará en cualquier prueba y en cualquier escenario.

Nota: el impacto de los cambios en los requisitos; el impacto de las desviaciones en la comprensión de los requisitos; el impacto de las ambigüedades en los requisitos, etc .;

9. Documento de diseño de caja negra

Documento de diseño: consulte el documento de diseño, puede comprender el proceso de diseño interno y el mecanismo de procesamiento del sistema de software, comparar los casos de prueba escritos y agregar las funciones y módulos correspondientes;

análisis de idea:

(1) Lea los documentos de diseño con atención;

(2) Comunicarse con el personal relevante para realizar el mecanismo;

(3) Combinar el método de escritura de casos de prueba y comparar los casos de uso escritos anteriormente;

Escenario de uso: un método que se utilizará en cualquier prueba y en cualquier escenario.

Nota: la exactitud de la documentación de diseño, la desviación de la comprensión de la documentación de diseño;

10. Método de prueba exploratorio de caja negra

Método de prueba exploratorio: puntos de prueba con creatividad infinita, pruebas exploratorias sin fin; debemos utilizar conocimientos, tecnología y medidas de contingencia a la vanguardia de las pruebas para encontrar defectos en el producto;

análisis de idea:

Pruebas exploratorias locales, pruebas exploratorias globales, pruebas exploratorias mixtas;

Escenario de uso: un método que se utilizará en cualquier prueba y en cualquier escenario. Al igual que la itinerancia, la búsqueda libre de defectos en el software, el futuro de las pruebas de software debe contar con pruebas exploratorias.

Parte 2: Cómo escribir casos de uso de White Box

Inserte la descripción de la imagen aquí

La idea básica:

El primer paso es dibujar un diagrama de flujo;

El segundo paso es determinar el caso de prueba de acuerdo con el método de análisis de ruta;

El tercer paso utiliza el método de clase de equivalencia / valor límite para determinar los datos del caso de prueba

El cuarto paso se complementa de acuerdo con la situación real (como proceso predeterminado, proceso especial, etc.)

Estrategia básica:

1. El criterio de cobertura de la declaración es básicamente inútil. El criterio de cobertura lógica más fuerte es la cobertura de juicio o cobertura de condición, por lo general la cobertura de juicio puede satisfacer la cobertura de declaración; cobertura de declaración <cobertura de juicio <cobertura de condición;

2. En términos de cobertura de bucle, la prueba de ruta completa no se ajusta a la realidad;

Haga clic en el enlace para unirse al chat grupal [grupo de intercambio de pruebas automatizadas de Python]

Supongo que te gusta

Origin blog.csdn.net/jin19990112/article/details/108730936
Recomendado
Clasificación