Diseño de casos de prueba

(1) Tecnología de caja blanca

La prueba de caja blanca es una prueba estructural, por lo que el objeto bajo prueba es básicamente el programa fuente, y los casos de prueba se diseñan en función de la lógica interna de el programa.

⒈Cobertura lógica

El grado de cobertura lógica dentro del programa Cuando hay bucles en el programa, es imposible cubrir todas las rutas. Es necesario diseñar un mayor grado de. Cobertura o casos de prueba para las rutas más representativas. A continuación, analizaremos varias tecnologías de cobertura de uso común basadas en el programa que se muestra en la Figura 7-1.

⑴Cobertura del extracto.

Para aumentar la probabilidad de encontrar errores, cada instrucción del programa debe ejecutarse durante la prueba. La cobertura de declaraciones se refiere al diseño de suficientes casos de prueba para que cada declaración en el programa bajo prueba se ejecute al menos una vez.

Como se muestra en la Figura 7-1, se muestra un diagrama de flujo del programa bajo prueba:

(2) Determinar la cobertura.

La cobertura de decisiones se refiere al diseño de suficientes casos de prueba para que cada expresión de decisión en el programa bajo prueba obtenga un valor "verdadero" y un valor "falso" al menos una vez, de modo que cada rama del programa pase en al menos una vez, por lo que la cobertura de decisión también se denomina cobertura de sucursal.

⑶Cobertura condicional.

La cobertura condicional se refiere al diseño de suficientes casos de prueba para que cada valor posible de cada condición en la expresión de juicio aparezca al menos una vez.

⑷Cobertura de condición de sentencia.

Este estándar de cobertura se refiere a diseñar suficientes casos de prueba para que todos los valores posibles de cada condición de la expresión de juicio aparezcan al menos una vez, y todos los resultados posibles de cada expresión de juicio también aparezcan al menos una vez.

⑸Cobertura combinada condicional.

La cobertura de combinación condicional es un estándar de cobertura relativamente sólido. Se refiere al diseño de suficientes casos de prueba para que todas las combinaciones posibles de valores de las condiciones en cada expresión de juicio aparezcan al menos una vez.

⑹Cobertura de camino.

La cobertura de rutas se refiere al diseño de suficientes casos de prueba para cubrir todas las rutas posibles en el programa bajo prueba.

En las pruebas de cobertura lógica reales, los casos de prueba generalmente se diseñan en función de una cobertura de combinación condicional y luego se agregan algunos casos de uso para cumplir con los estándares de prueba de cobertura de ruta.

⒉Cobertura de bucle

⒊Prueba de ruta básica

(2) Tecnología de caja negra

⒈División de clases de equivalencia

⑴Dividir en clases de equivalencia.

① Cuando la condición de entrada especifica el rango de valores o el número de valores, se puede establecer una clase de equivalencia válida y dos clases de equivalencia no válidas.

② Cuando la condición de entrada especifica un conjunto de valores de entrada o especifica una condición "debe ser", se pueden establecer una clase de equivalencia válida y una clase de equivalencia no válida.

③Cuando la condición de entrada es una cantidad booleana, se puede determinar una clase de equivalencia válida y una clase de equivalencia no válida.

④ Cuando se especifica un conjunto de valores de datos de entrada (suponiendo n), y el programa necesita procesar cada valor de entrada por separado, se pueden establecer n clases de equivalencia válidas y una clase de equivalencia no válida.

⑤ Cuando se especifican las reglas que deben cumplir los datos de entrada, se pueden establecer una clase de equivalencia válida (que se ajuste a las reglas) y varias clases de equivalencia no válidas (que violen las reglas desde diferentes ángulos).

⑥Cuando se sabe que cada elemento en la clase de equivalencia dividida es procesado de manera diferente por el programa, la clase de equivalencia debe dividirse en clases de equivalencia más pequeñas.

⑵Determinar casos de prueba.

①Numerar cada clase de equivalencia.

② Diseñe un caso de prueba para cubrir tantas clases de equivalencia razonables como sea posible que aún no se hayan cubierto. Repita este paso hasta que todas las clases razonablemente equivalentes estén cubiertas por casos de prueba.

③ Diseñe un caso de prueba para que solo cubra una clase de equivalencia no razonable.

⒉Análisis de valores límite

Al diseñar casos de prueba utilizando el método de análisis de valores límite, generalmente se combina con la división de clases de equivalencia. Pero en lugar de seleccionar un ejemplo de una clase de equivalencia como representante, se toma como objetivo clave probar el caso límite y seleccionar datos de prueba que sean exactamente iguales, apenas mayores o simplemente menores que el valor límite.

⑴ Si la condición de entrada especifica un rango de valores, puede seleccionar datos que sean exactamente iguales al valor límite como un caso de prueba razonable y, al mismo tiempo, seleccionar datos que apenas crucen el valor límite. como un caso de prueba irrazonable. Por ejemplo, el rango de valores de entrada es [1, 100] y valores como 0, 1, 100 y 101 se pueden utilizar como datos de prueba.

⑵ Si la condición de entrada indica el número de datos de entrada, los casos de prueba se diseñan de acuerdo con el número máximo, el número mínimo, 1 menos que el número mínimo, 1 más que el número máximo, etc. Por ejemplo, un archivo de entrada puede incluir entre 1 y 255 registros y luego diseñar casos de prueba para archivos de entrada con 1 registro, 255 registros y 0 registros respectivamente.

⑶ Para cada condición de salida, determine las condiciones límite del valor de salida de acuerdo con los principios anteriores ⑴ o ⑵. Por ejemplo, un sistema de gestión del desempeño de los estudiantes estipula que solo se pueden consultar las calificaciones de varias materias de estudiantes universitarios de nivel 95-98. Se puede diseñar un caso de prueba para que las calificaciones de los estudiantes de una determinada clase o de cuatro estudiantes dentro del rango de consulta. También es necesario diseñar para consultar a los estudiantes de nivel 94, casos de prueba para estudiantes de grado 99 (clase de equivalencia de salida irrazonable).

Dado que el límite del valor de salida no corresponde al límite del valor de entrada, no es necesariamente posible verificar el límite del valor de salida y no es necesariamente posible producir resultados más allá del valor de salida, pero es necesario. Aún así hay que intentarlo.

⑷Si el dominio de entrada o salida proporcionado en la especificación del programa es un conjunto ordenado (como un archivo secuencial, una lista lineal, una lista enlazada, etc.), el primer elemento y el último elemento del conjunto deben ser seleccionados como casos de prueba.

⒊Especulación de errores

Al probar un programa, las personas pueden especular sobre varios errores que pueden existir en el programa basándose en la experiencia o la intuición y, por lo tanto, escribir casos de prueba para verificar estos errores de una manera manera específica, este es el método de adivinación incorrecto.

⒋Diagrama de causa y efecto

Los métodos de análisis del método de división de clases de equivalencia y de valor límite solo consideran la función de prueba de cada dato de entrada de forma aislada, pero no consideran los efectos causados ​​por la combinación de error de múltiples datos de entrada.

⒌Estrategia integral

Cada método puede diseñar un conjunto de ejemplos útiles. Con este conjunto de ejemplos, es fácil encontrar algunos tipos de errores, pero puede que no sea fácil de encontrar. otro tipo de errores. Por lo tanto, en las pruebas reales, se utilizan varios métodos de prueba juntos para formar una estrategia integral. El método de caja negra generalmente se usa para diseñar casos de prueba básicos y luego el método de caja blanca se usa para complementar algunos casos de prueba necesarios. ·Un buen caso de uso es un caso de uso que puede descubrir defectos que no se han descubierto hasta ahora.

En primer lugar, quiero afirmar que esta oración es realmente muy razonable, pero encuentro que muchas personas han entendido mal el significado original de esta oración y están decididas a diseñar para encontrar "difíciles de encontrar". defectos" y caer en la ceguera. Ser unilateral y olvidar el propósito de la prueba da mucho miedo. Tiendo a pensar en los casos de prueba como una colección, y su evaluación solo se puede realizar en una colección de casos de prueba. Las pruebas en sí son una actividad "Vamp; AMp; V". Las pruebas deben garantizar los dos puntos siguientes:

El programa hizo lo que se suponía que debía hacer

El programa no hizo lo que se suponía que no debía hacer

Por lo tanto, los casos de prueba utilizados como base para la prueba La implementación debe Puede cubrir completamente los requisitos de prueba y no debe juzgar la calidad de un solo caso de prueba.

·Los casos de prueba deben registrar toda la información de operación en detalle, de modo que una persona que no haya estado expuesta al sistema también pueda realizar la prueba.

No sé si alguna empresa nacional realmente puede hacer esto, o en otras palabras, no sé si alguna empresa nacional puede escribir cada caso de prueba con tanto detalle. En mi experiencia en pruebas, he tenido muchas dudas sobre el detalle y la complejidad de las descripciones de los casos de prueba. Escríbalo de manera demasiado simple y nadie podrá ejecutarlo excepto usted. Escríbalo con demasiado detalle y se consumirá en el mantenimiento de casos de prueba (no olvide que los casos de prueba son dinámicos. Una vez que se conocen el entorno de prueba, los requisitos, el diseño y la implementación). Si cambia, los casos de prueba (todos deben cambiar en consecuencia), el tiempo requerido es realmente asombroso. En la actualidad, la mayoría de las empresas de software nacionales no tienen recursos de prueba suficientes y puede ser difícil de lograr.

Pero me he encontrado con algunos jefes o líderes de proyectos, o incluso los propios ingenieros de pruebas, que ignoran por completo la situación real de los recursos y deben escribir casos de uso que "las personas que no han estado expuestas al sistema también puedan probar".

Antes de discutir este tema, primero podemos considerar el propósito de las pruebas. El propósito de las pruebas es descubrir tantos defectos en el programa como sea posible. La actividad de prueba en sí también puede considerarse como un proyecto y, según mis condiciones personales, también debe lograr el objetivo tanto como sea posible. experiencia, la mayoría del software nacional Los recursos de prueba de la empresa son insuficientes, por lo que debemos aclarar los objetivos de las pruebas durante la etapa de planificación de las pruebas, y todo debe centrarse en los objetivos de las pruebas.

Además de las limitaciones de recursos, el nivel de detalle de los casos de prueba también debe determinarse según sea necesario. Si el ejecutor del caso de prueba, el diseñador del caso de prueba y las personas involucradas en las actividades de prueba tienen un conocimiento profundo del sistema, entonces el caso de prueba no necesita ser demasiado detallado. comunicar, siempre y cuando se pueda lograr el propósito de la comunicación. En los proyectos en los que me desempeño como gerente de pruebas, durante la etapa de planificación de pruebas, el diseño de la prueba generalmente toma entre 30 y 40 minutos. El ingeniero de diseño de pruebas puede determinar el nivel de detalle de los casos de uso de acuerdo con las necesidades del proyecto. Las personas relevantes lo comprobarán.

·El diseño de casos de prueba es algo que se hace de una vez por todas.

No creo que nadie esté de acuerdo con esta afirmación, pero en situaciones reales, a menudo se puede encontrar la sombra de esta idea. Una vez trabajé en un proyecto donde los requisitos y el diseño del software habían cambiado muchas veces, pero los casos de prueba no se habían modificado en absoluto. El resultado directo es que los ingenieros de pruebas recién incorporados no saben cómo ejecutar los casos de prueba. La consecuencia indirecta es que los casos de prueba se convierten en un montón de papel usado. Los desarrolladores desdeñan a los evaluadores después de ser interrumpidos repetidamente por informes de defectos no válidos. .

Este ejemplo puede ser un poco extremo, pero no es raro que los casos de prueba no estén sincronizados con los requisitos y diseños en el proceso de desarrollo real. Los documentos de los casos de prueba son documentos "vivos", lo cual debería serlo. Reconocido por los ingenieros de pruebas.

·Los casos de prueba no deben contener datos reales.

Un caso de prueba es "un conjunto de entradas, condiciones de ejecución y resultados esperados". No hay duda de que debe incluir datos de entrada claros y los casos de uso sin datos de prueba sólo tienen un significado instructivo. mejores y no son ejecutables. Por supuesto, la inclusión de datos de entrada en casos de prueba traerá problemas como el mantenimiento y la sincronización con el entorno de prueba. Respecto a esto, el libro "Effective Software TeST" proporciona casos de prueba detallados y métodos de mantenimiento de datos de prueba, que puede consultar. .

·No se requieren métodos de verificación obvios en los casos de prueba.

He visto muchos casos de prueba escritos por ingenieros de pruebas en los que el "resultado esperado" solo se describe como el comportamiento visible del programa. De hecho, el significado de "resultado esperado" no es solo lo visible. comportamiento del programa. Por ejemplo, para un sistema de pedidos, después de ingresar los datos del pedido y hacer clic en el botón "Aceptar", el sistema muestra "Pedido exitoso". ¿La salida del sistema de "pedido exitoso" debería ser nuestro único método de verificación? Aparentemente no. Si la orden es exitosa también requiere verificar si el registro de datos correspondiente se ha actualizado. Por lo tanto, en tal caso de uso, también debe incluir métodos de verificación explícitos para los resultados de la prueba: ejecutar la declaración de consulta en la base de datos para ver si los resultados de la consulta. son los esperados. Los casos de prueba utilizados para las pruebas funcionales se derivan de los casos de uso del objetivo de la prueba. Se deben preparar casos de prueba para cada escenario de caso de uso. El escenario de caso de uso se determina describiendo la ruta que fluye a través del caso de uso, que atraviesa todos los flujos básicos y alternativos en el caso de uso desde el principio hasta el final.

Por ejemplo, cada ruta diferente a través de un caso de uso en la siguiente figura refleja un flujo básico y un flujo alternativo, ambos representados por flechas. Un flujo elemental está representado por una línea recta negra y es el camino más simple a través de un caso de uso. Cada flujo alternativo comienza con un flujo básico y luego el flujo alternativo se ejecuta bajo ciertas condiciones.

Un flujo alternativo puede volver a unirse al flujo base (Flujos alternativos 1 y 3), originarse a partir de otro flujo alternativo (Flujo alternativo 2) o terminar el caso de uso sin volver a unirse a un flujo (Flujo alternativo 2 y 4).

Ejemplo de flujo de eventos para un caso de uso

Al seguir cada ruta posible a través del caso de uso en el diagrama anterior, se pueden identificar diferentes escenarios de casos de uso. A partir del flujo básico y luego combinando el flujo básico y los flujos alternativos, se pueden determinar los siguientes escenarios de casos de uso:

Escenario 1 Flujo básico

Escenario 2 Flujo básico Flujo alternativo 1

Escenario 3 Flujo básico flujo alternativo 1 Flujo alternativo 2

Escenario 4 Flujo básico flujo alternativo 3

Escenario 5 Flujo básico flujo alternativo 3 Flujo alternativo 1

Escenario 6 Flujo Básico Flujo Alternativo 3 Flujo Alternativo 1 Flujo Alternativo 2

Escenario 7 Flujo Básico Flujo Alternativo 4

Escenario 8 Flujo Básico Flujo Alternativo 3 Flujo Alternativo 4

Nota: Por conveniencia, los Escenarios 5, 6 y 8 solo describen la situación en la que el bucle indicado por el Flujo alternativo 3 se ejecuta una vez.

La generación de casos de prueba para cada escenario se logra determinando una condición específica que conducirá a la ejecución de un escenario de caso de uso específico.

Por ejemplo, supongamos que el caso de uso descrito anteriormente especifica lo siguiente para el flujo alternativo 3:

"Si el monto en USD ingresado en el paso 2 'Ingresar monto de retiro' anterior excede el monto actual saldo de la cuenta, se produce este flujo de eventos. El sistema mostrará un mensaje de advertencia, luego volverá a unirse al flujo básico y realizará el paso 2 anterior 'Ingresar el monto del retiro' nuevamente. En este momento, el cliente del banco puede ingresar el nuevo monto del retiro.

De acuerdo con esto, puede comenzar a determinar los casos de prueba que deben usarse para ejecutar el flujo alternativo 3:

ID del caso de prueba Condiciones del escenario Resultados esperados

TC x Escenario 4 Paso 2 - Monto de retiro gt; el saldo de la cuenta se reincorpora al flujo básico en el paso 2

TC y Escenario 4 Paso 2 - Monto de retiro lt; flujo básico

TC z Escenario 4 Paso 2 - Monto del retiro = Saldo de la cuenta No ejecute el flujo alternativo 3, ejecute el flujo básico

Nota: Dado que no se proporciona otra información, los casos de prueba mostrados arriba son muy simples. Los casos de prueba rara vez son tan simples.

El siguiente es un ejemplo más realista de cómo generar casos de prueba a partir de casos de uso.

Ejemplo:

Protagonistas y casos de uso de un cajero automático.

La siguiente tabla contiene el flujo básico y algunos flujos alternativos para el caso de uso de retiro de efectivo en la figura anterior:

Este caso de uso comienza con el cajero automático en estado listo.

Prepárese para retirar dinero: el cliente inserta su tarjeta bancaria en el lector de tarjetas del cajero automático.

Verificar la tarjeta - El cajero automático lee el código de cuenta de la banda magnética de la tarjeta y comprueba si es una tarjeta que puede ser aceptada.

Ingrese PIN: el cajero automático requiere que el cliente ingrese un PIN (4 dígitos).

Verifique el código de cuenta y el PIN: verifique el código de cuenta y el PIN para determinar si la cuenta es válida y si el PIN ingresado es correcto ¿Esta cuenta es correcta? Para este flujo de eventos, la cuenta es válida y el PIN es correcto para esta cuenta.

Opciones de cajero automático: Cajero automático muestra las diversas opciones disponibles en la máquina. En este flujo de eventos, un cliente del banco normalmente selecciona "Retirar".

Ingrese monto: el monto a retirar del cajero automático. Para este flujo de eventos, el cliente selecciona un monto preestablecido ($10, $20, $50 o $100).

Autorización: el cajero automático inicia el proceso de verificación enviando el ID de la tarjeta, el PIN, el monto y la información de la cuenta como una transacción al sistema bancario.

Para este flujo de eventos, el sistema bancario está en línea y responde a la solicitud de autorización, autoriza la finalización del retiro y actualiza el saldo de la cuenta en consecuencia.

Efectivo: proporciona efectivo.

Devolución a tarjeta bancaria - Se devuelve la tarjeta bancaria.

Recibos: imprima recibos y entréguelos a los clientes. El cajero automático también actualiza los registros internos en consecuencia.

Al final del caso de uso, el cajero automático vuelve al estado listo.

Flujo alternativo 1 - La tarjeta bancaria no es válida En el paso 2 del flujo básico - Se verifica la tarjeta bancaria, si la tarjeta no es válida, se devuelve la tarjeta y se notifica un mensaje relacionado.

Flujo Alternativo 2 - No hay efectivo en el cajero automático En el Flujo Básico Paso 5 - Opción Cajero Automático, si no hay efectivo en el cajero automático, la opción "Retirar" no estará disponible.

Flujo Alternativo 3 - Efectivo Insuficiente en Cajero Automático En Flujo Básico Paso 6 - Ingrese el monto, si el monto en el cajero automático es menor al monto solicitado para retirar, se mostrará un mensaje correspondiente y en el paso 6 - Reincorporarse al flujo básico donde se ingresa el monto.

Flujo alternativo 4: PIN incorrecto En el paso 4 del flujo básico: verificar la cuenta y el PIN, el cliente tiene tres oportunidades para ingresar el PIN.

Si el PIN se ingresa incorrectamente, el cajero automático muestra un mensaje apropiado; si todavía hay una oportunidad de ingresar, este flujo de eventos se reincorpora al flujo básico en el paso 3: Ingresar el PIN.

Si el último PIN intentado sigue siendo incorrecto, el cajero automático retendrá la tarjeta y el cajero automático volverá al estado listo y el caso de uso finalizará.

Flujo alternativo 5 - La cuenta no existe En el flujo básico Paso 4 - Verificar la cuenta y el PIN, cajero automático si el sistema bancario devuelve un código que indica que no se puede encontrar la cuenta o que los retiros de la cuenta están prohibidos Mostrar el mensaje apropiado y vuelva a unirse al flujo básico en el Paso 9: Regresar a la tarjeta.

Flujo Alternativo 6 - Monto de Cuenta Insuficiente En el Flujo Básico Paso 7 - Autorización, el sistema bancario devuelve un código que indica que el saldo de la cuenta es menor que el monto ingresado en el Flujo Básico Paso 6 - Ingresa el Monto, el cajero automático muestra el mensaje Apropiado y vuelve a unirse al flujo básico en el paso 6: Ingresar monto.

Flujo Alternativo 7 - Monto Máximo de Retiro Diario Alcanzado En el Flujo Básico Paso 7 - Autorización, el sistema bancario devuelve un código que indica que incluyendo esta solicitud de retiro, el cliente ha excedido o excederá el límite dentro de 24 El monto máximo Si se le permite retirar dinero en una hora, el cajero automático muestra el mensaje apropiado y se reincorpora al flujo básico en el Paso 6: Ingresar monto.

Flujo Alternativo x - Error de Registro Si en el Flujo Básico Paso 10 - Recibo, el registro no se puede actualizar, el cajero automático entra en "Modo Seguro" en el que se suspende toda funcionalidad. También se envía un mensaje de alerta apropiado al sistema bancario indicando que el cajero automático ha sido suspendido.

Flujo alternativo y - Salida El cliente podrá decidir finalizar la transacción (salida) en cualquier momento. Se finaliza la transacción y se retira la tarjeta bancaria.

Alternative Flow z - ATM "Amartillado" contiene una gran cantidad de sensores para monitorear diversas funciones, como detectores de energía, manómetros en diferentes puertas y entradas y salidas, y detectores de movimiento. Si en algún momento un cliente actúa violentamente, se inician las medidas adecuadas.