[Pregunta de prueba de software] Una descripción completa del proceso de diseño de un caso de prueba.

Las pruebas de caja negra (también conocidas como pruebas funcionales o pruebas basadas en datos) tratan el objeto de prueba como una caja negra. Cuando se utiliza el método de prueba de caja negra para pruebas dinámicas, es necesario probar las funciones del producto de software y no es necesario probar la estructura interna y el proceso de procesamiento del producto de software.

Los métodos para diseñar casos de prueba utilizando tecnología de caja negra incluyen: división de clases de equivalencia, análisis de valores límite, especulación de errores, diagramas de causa y efecto y estrategias integrales.

Las pruebas de caja negra se centran en probar los requisitos funcionales del software. Es decir, las pruebas de caja negra permiten a los ingenieros de software derivar las condiciones de entrada para ejecutar todos los requisitos funcionales del programa. Las pruebas de caja negra no sustituyen a las pruebas de caja blanca, pero se utilizan para ayudar a las pruebas de caja blanca a encontrar otros tipos de errores.

Las pruebas de caja negra intentan encontrar los siguientes tipos de errores:

1) errores u omisiones funcionales

2) errores de interfaz

4) Errores de rendimiento

5) Errores de inicialización y terminación;

1. Método de diseño de casos de prueba para pruebas de caja negra

·Método de división de clases de equivalencia

·Método de análisis de valores límite

· Error método de especulación

·Método del diagrama causal

·Método de análisis basado en tablas de decisión

·Método de diseño experimental ortogonal

·Método de análisis del diagrama de funciones

División de clases de equivalencia:

Consiste en dividir todos los datos de entrada posibles, es decir, el dominio de entrada del programa en varias partes (subconjuntos), y luego seleccionar de cada subconjunto A Se utiliza una pequeña cantidad de datos representativos como casos de prueba. Este método es un método de diseño de casos de prueba de caja negra importante y comúnmente utilizado.

1) Dividir clases de equivalencia: las clases de equivalencia se refieren a un determinado dominio de entrada. el subconjunto, cada dato de entrada es equivalente para revelar errores en el programa. Es razonable suponer que probar el valor representativo de una clase de equivalencia es equivalente a probar otros valores de esta clase. se puede dividir razonablemente en varias clases de equivalencia, y se toma un dato de cada clase de equivalencia como condición de entrada de la prueba, de modo que se pueda utilizar una pequeña cantidad de datos de prueba representativos para obtener mejores resultados de prueba. dos situaciones diferentes de división: clase de equivalencia válida y clase de equivalencia no válida.

Clase de equivalencia válida: se refiere a la composición de datos de entrada que es razonable y significativa para la especificación del programa. Puede utilizar clases de equivalencia válidas para comprobar si el programa implementa las funciones y el rendimiento especificados en la especificación.

Clases de equivalencia no válidas: la definición de clases de equivalencia válidas es exactamente lo contrario.

Al diseñar casos de prueba, estas dos clases de equivalencia deben considerarse al mismo tiempo porque el software no solo debe recibir datos razonables, sino también soportar pruebas inesperadas. Dichas pruebas pueden garantizar una mayor confiabilidad del software. 2) Métodos para dividir las clases de equivalencia: Los siguientes son seis principios para determinar las clases de equivalencia.

① Cuando las condiciones de entrada especifican el rango de valores o el número de valores, entonces una clase de equivalencia válida y dos clases de equivalencia no válidas se puede establecer.

② Cuando la condición de entrada especifica el conjunto de valores de entrada o especifica la condición "debe ser", se puede 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 (asumiendo 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 establece una clase de equivalencia válida ( conforme a las reglas) y se pueden establecer varias clases de equivalencia inválidas (violando 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, el la clase de equivalencia debe dividirse en clases de equivalencia más pequeñas.

3) Diseñe casos de prueba: después de establecer la clase de equivalencia, puede crear una tabla de clases de equivalencia y enumerar todas las clases de equivalencia divididas:

Condiciones de entrada clase de equivalencia válida clase de equivalencia no válida

... ... ...

... ... ...

Luego, desde las clases de equivalencia divididas, presione los siguientes tres principios para diseñar casos de prueba:

① Especifique un número único para cada clase de equivalencia.

② Diseñe un nuevo caso de prueba para cubrir como Tanto como sea posible que aún no se hayan cubierto clases de equivalencia válidas, repita este paso hasta que se cubran todas las clases de equivalencia válidas.

③Diseñe un nuevo caso de prueba para que solo cubra una clase de equivalencia no válida que no se haya cubierto , Repita este paso hasta cubrir todas las clases de equivalencia no válidas.

Método de análisis de valores límite

El método de análisis de valores límite es un complemento del método de división de clases de equivalencia.

(1) Consideración del método de análisis del valor límite:

La experiencia laboral de pruebas a largo plazo nos dice que se produce una gran cantidad de errores en los límites del rango de entrada o salida, en lugar de en la salida de entrada. rango

Interno, por lo tanto, diseñar casos de prueba para varias condiciones de contorno puede detectar más errores.

Cuando se utiliza el método de análisis de valores de límite para diseñar casos de prueba, primero se deben determinar las condiciones de contorno. El límite es la situación límite en la que se debe centrar la prueba. Los valores que son exactamente iguales, ligeramente mayores o simplemente menores que el límite deben seleccionarse como datos de prueba, en lugar de seleccionar valores típicos o valores arbitrarios. la clase de equivalencia como datos de prueba.

(2) Principios para seleccionar casos de prueba basados ​​en el método de análisis de valores límite:

1) Si la condición de entrada especifica un rango de valores, el valor que justo alcanza el límite de este rango se debe tomar, y se debe tomar el valor que apenas excede este rango. El valor límite se utiliza como datos de entrada de prueba.

2) Si la condición de entrada especifica el número de valores, utilice el número máximo y el número mínimo, uno menor que el número mínimo y uno mayor que el número máximo. El número se utiliza como datos de prueba.

3) De acuerdo con cada condición de salida indicada en. la especificación, utilice el principio anterior 1).

4) De acuerdo con cada condición de salida establecida en la especificación, aplique el principio anterior 2).

5) Si el dominio de entrada o salida El dominio dado en la especificación del programa es un conjunto ordenado, el primer elemento y el último elemento del conjunto deben seleccionarse como casos de prueba.

6) Si se utiliza una estructura de datos interna en el programa, el valor. en el límite de la estructura de datos interna debe seleccionarse como caso de prueba.

7) Analice las especificaciones y descubra otras posibles condiciones de límite.

Método de especulación de errores

Método de especulación de errores: basándose en la experiencia y la intuición, especule sobre todos los posibles errores en el programa, diseñando así casos de prueba de manera específica.

La idea básica del método de especulación de errores: enumere todos los errores posibles en el programa y las situaciones especiales en las que es probable que ocurran, y seleccione casos de prueba basados ​​en ellos. Por ejemplo, los enumerados durante las pruebas unitarias. Muchos errores comunes en los módulos que se han descubierto en pruebas de productos anteriores. , etc., estos son el resumen de la experiencia. Además, la situación en la que los datos de entrada y los datos de salida son 0. El formulario de entrada está en blanco o el formulario de entrada tiene solo una fila. Estos son ejemplos que tienden a ocurrir. las situaciones se pueden seleccionar como casos de prueba.

Método del diagrama causal

El método de división de clases de equivalencia y el método de análisis de valores límite introducidos anteriormente se centran en las condiciones de entrada, pero no consideran la conexión entre condiciones de entrada, combinaciones mutuas, etc. Considerando la combinación mutua de condiciones de entrada, pueden surgir algunas situaciones nuevas, pero no es fácil verificar la combinación de condiciones de entrada. Incluso si todas las condiciones de entrada se dividen en clases de equivalencia, existen bastantes. pocas combinaciones entre ellos, por lo tanto, es necesario considerar el diseño de casos de prueba en una forma adecuada para describir la combinación de múltiples condiciones y, en consecuencia, generar múltiples acciones. Esto requiere el uso de diagramas de causa y efecto (modelos lógicos). p>

El resultado final generado por el método del diagrama de causa y efecto es una tabla de decisión. Es adecuado para verificar varias combinaciones de condiciones de entrada del programa.

Uso de pasos básicos de causa y efecto para el gráfico. casos de prueba de generación:

(1) En la descripción de la especificación del software de análisis, cuáles son las causas (es decir, condiciones de entrada o clases equivalentes de condiciones de entrada) y cuáles son los resultados (es decir, condiciones de salida), Y asigne un identificador a cada causa y resultado.

(2) Analice la semántica en la descripción de la especificación del software. Encuentre la relación correspondiente entre la causa y el resultado, y entre la causa y la causa. estas relaciones y dibuje un diagrama de causa y efecto.

(3) Debido a restricciones gramaticales o ambientales, algunas combinaciones entre causas y causas y entre causas y resultados no son imposibles para mostrar estos especiales. situaciones, en Utilice algunos símbolos en el diagrama de causa y efecto para indicar restricciones o condiciones limitantes.

(4) Convierta el diagrama de causa y efecto en una tabla de decisiones.

(5) Tome cada columna de la tabla de decisión como base y diseñe casos de prueba.

Los casos de prueba generados a partir del diagrama de causa y efecto (bajo relaciones de combinación locales) incluyen todos los VERDADEROS. y situaciones FALSAS de los datos de entrada, y el número de casos de prueba alcanza

Mínimo, y el número de casos de prueba aumenta linealmente con el aumento en el número de datos de entrada.

La tabla de decisiones se ha utilizado en el método de diagrama de causa y efecto anterior La tabla de decisiones (Tabla de decisiones). ) se utiliza para analizar y expresar la ejecución bajo múltiples condiciones lógicas. Una herramienta para diferentes operaciones. En los primeros días del desarrollo de la programación, las tablas de decisiones se han utilizado como una herramienta auxiliar para escribir programas. múltiples condiciones de una manera concreta y clara.

Una tabla de decisión generalmente consta de cuatro partes.

Condición Stub: enumera todas las condiciones del problema. El orden en el que se enumeran las condiciones no importa.

Código de acción: enumera las posibles acciones especificadas por el problema. No hay restricciones en el orden de estas acciones.

Entrada de condición: Enumera las acciones para ello El valor de la condición de la columna izquierda Valores verdaderos o falsos en todas las situaciones posibles.

Entrada de acción: Enumera las acciones que se deben realizar según varios valores del elemento de condición. .

p>

Regla: el valor específico de cualquier combinación de condiciones y la operación correspondiente que se realizará. Una columna que recorre los elementos de condición y los elementos de acción en la tabla de decisiones es obviamente una regla. , ¿cuántos conjuntos de condiciones se enumeran en la tabla de valores de decisión, es decir, cuántas reglas hay, es decir, cuántas columnas hay para elementos de condición y elementos de acción?

Pasos para establecer un tabla de decisiones: (según las especificaciones del software)

① Determinar las reglas individuales Número Si hay n condiciones Cada condición tiene dos valores (0,1), entonces hay una regla. p>

② Enumere todas las pilas de condiciones y pilas de acciones.

③Complete los elementos de condición.

④Complete los elementos de acción.

⑤Simplificar. Fusionar reglas similares (mismas acciones).

B. Beizer señaló las condiciones para usar tablas de decisión para diseñar casos de prueba:

①Las especificaciones se dan en el forma de tablas de decisión, o se pueden convertir fácilmente en tablas de decisión.

②Condiciones El orden de las reglas no afectará ni afectará qué operaciones se realizan.

③El orden de las reglas no afectará ni afectará qué operaciones se realizan.

④Siempre que se cumplan las condiciones de una regla y después de determinar la operación a realizar, no es necesario verificar otras reglas.

⑤ Si se cumple una determinada regla y es necesario realizar varias operaciones, el orden de ejecución de estas operaciones no importa.

Ventajas de las pruebas de caja negra

1. Básicamente no hay que encargarse de ello. Si el programa deja de ejecutarse, normalmente es el programa bajo prueba el que falla.

2. Después de diseñar el caso de prueba, el trabajo es divertido, pero por supuesto es más frustrante. determinar la causa del accidente

Desventajas de las pruebas de caja negra

1. El resultado depende del diseño del caso de prueba, y parte del diseño del caso de prueba proviene de la experiencia. Vale la pena aprender de las cosas de OUSPG

2. No existe un concepto de transición de estado. Algunos ejemplos exitosos actuales son básicamente para PDU, y no existe una transición de estado para el programa bajo prueba. p> 3. Para las pruebas sin el concepto de estado, es problemático encontrar y determinar los casos de prueba que hacen que el programa falle. Debe confirmar los posibles casos de prueba circundantes individualmente. En cuanto a las pruebas de estado, es aún más problemático, especialmente si no es un problema causado por un solo caso de prueba. Estos son más prominentes en problemas de montón.

Selección de herramientas de prueba de caja negra (pruebas funcionales)

Entonces, ¿cómo completar las pruebas funcionales de manera eficiente? Sin duda, elegir una herramienta de prueba funcional adecuada y capacitar a un equipo de usuarios de herramientas altamente calificados es crucial. Aunque actualmente existen algunas empresas de servicios de software que no utilizan ninguna herramienta de prueba funcional y participan en proyectos de subcontratación de pruebas funcionales.

A corto plazo, la rentabilidad de estas empresas es aceptable, pero a largo plazo es probable que sean sustituidas por empresas de servicios de software con un mayor grado de automatización.

Actualmente, existen muchas herramientas de software para pruebas funcionales y constantemente se introducen herramientas para diferentes software de arquitectura. La atención se centra aquí en una de las herramientas de prueba automatizadas más típicas, WinRunner de Mercury.

WinRunner es una herramienta de prueba funcional de software de nivel empresarial que se utiliza para verificar si las aplicaciones pueden ejecutarse como se espera. Al capturar, detectar y simular automáticamente las interacciones del usuario, WinRunner puede identificar la mayoría de los defectos funcionales del software, garantizando así que las aplicaciones que abarcan múltiples puntos funcionales y bases de datos se publiquen con la menor cantidad de fallas funcionales posible.

Las características de WinRunner son: en comparación con las pruebas manuales tradicionales, puede completar las pruebas de puntos de función rápidamente y en lotes, puede ejecutar la misma acción para el mismo script de prueba, eliminando así los problemas causados ​​por las pruebas manuales; errores de comprensión, además, puede realizar la misma acción repetidamente y la máquina puede completar la parte más aburrida del trabajo de prueba; admite scripts de prueba de estilo programa, y ​​un ingeniero de pruebas de alta calidad puede usarlo; completar procesos extremadamente complejos Las pruebas, mediante el uso de comodines, macros, declaraciones condicionales, declaraciones de bucle, etc., también pueden completar mejor la reutilización de scripts de prueba y proporcionan un mejor entorno de integración y soporte para la mayoría de los lenguajes de programación; Las tecnologías de Windows, que se basan en aplicaciones de la plataforma Windows, brindan una gran comodidad para implementar pruebas funcionales.

El flujo de trabajo de WinRunner se puede dividir aproximadamente en los siguientes seis pasos:

1. Identifique la GUI de la aplicación

En WinRunner, podemos usar GUI Spy para identificar varios objetos GUI. Después de la identificación, WinRunner los almacenará en el archivo de mapa GUI. Proporciona dos modos de archivo de mapa GUI: archivo de mapa GUI global y archivo de mapa GUI por prueba. La mayor diferencia es que este último genera un archivo GUI para cada script de prueba, que se puede crear, almacenar y cargar automáticamente. Se recomienda que los principiantes elijan este modo. Sin embargo, este modo no es fácil de describir los cambios de objetos y su eficiencia es relativamente baja. Por lo tanto, el primero es una mejor opción para un probador experimentado. Solo genera un archivo GUI compartido, lo que hace que los scripts de prueba sean más fáciles de mantener. eficiente.

2． Crear un script de prueba

Al crear un script de prueba, generalmente se registra primero y luego el TSL requerido (un lenguaje de script de prueba similar al lenguaje C) se agrega manualmente al script grabado. Hay dos modos para grabar guiones: Sensible al contexto y Analógico. La elección se basa principalmente en si se simula la trayectoria del mouse. Generalmente se usa analógico cuando se requiere reproducción. Durante el proceso de grabación, estos dos modos se pueden cambiar entre sí mediante la tecla F2.

Si observa la escala y los puntos de función del software moderno, podrá comprender que las pruebas funcionales ya han superado la etapa en la que se pueden completar escribiendo manualmente en el teclado y haciendo clic con el mouse. Las pruebas de rendimiento son un medio eficaz para controlar el rendimiento del sistema y desempeñan un papel importante en la verificación de la capacidad del software, la planificación de la capacidad, el ajuste del rendimiento y la reparación de defectos.

3. Depurar scripts de prueba

Hay una barra de herramientas de depuración dedicada en WinRunner para depurar scripts de prueba. Puede utilizar pasos, pausas, puntos de interrupción, etc. para controlar y realizar un seguimiento del script de prueba y ver varios valores de variables.

4． Ejecute el script de prueba en la nueva versión de la aplicación

Cuando se lance una nueva versión de la aplicación, probaremos varias funciones de la aplicación, incluidas las nuevas. Por supuesto, es imposible volver a ejecutarlas. Registre y escriba todas las funciones en este momento. Podemos utilizar scripts existentes y ejecutar estos scripts de prueba en lotes para probar si los puntos de función antiguos funcionan correctamente. Cada script de prueba se puede cargar mediante un comando de llamada. También puede agregar varios scripts TSL al comando de llamada para aumentar las capacidades por lotes.

5． Analizar los resultados de las pruebas

Analizar los resultados de las pruebas es lo más importante de todo el proceso de prueba. A través del análisis, se pueden descubrir varios defectos funcionales de la aplicación. Después de ejecutar un script de prueba, se generará un informe de prueba. A partir de este informe de prueba, podemos encontrar los defectos funcionales de la aplicación, la diferencia entre los resultados reales y los resultados esperados y los errores generados durante la prueba. , etc.

6. Informar defectos (defecto)

Después de analizar el informe de prueba, informe varios defectos de la aplicación de acuerdo con el proceso de prueba y luego envíe estos defectos a la persona designada para su modificación y mantenimiento.

Métodos de prueba funcionales comúnmente utilizados

Las pruebas funcionales consisten en verificar cada función del producto. De acuerdo con los casos de prueba funcionales, pruebe uno por uno para verificar si el producto cumple con las funciones requeridas. por el usuario. Los métodos de prueba más utilizados son los siguientes:

1. Verificación del enlace de la página: si cada enlace tiene una página correspondiente y si el cambio entre páginas es correcto.

2. Verificación de relevancia: ¿eliminar/agregar un elemento tendrá un impacto en otros elementos? Si es así, ¿son correctos estos impactos?

3. Compruebe si las funciones del botón son correctas: como actualizar, cancelar, eliminar, guardar y otras funciones.

4. Verificación de la longitud de la cadena: ingrese contenido que exceda la longitud de la cadena especificada por los requisitos para ver si el sistema verifica la longitud de la cadena y si habrá un error.

5. Verificación de tipo de carácter: ingrese otros tipos de contenido donde se debe ingresar el tipo de contenido especificado (como ingresar otros tipos de caracteres donde se deben ingresar números enteros) y vea si el sistema verifica el tipo de carácter y si se informa un error.

6. Verificación de signos de puntuación: el contenido de entrada incluye varios signos de puntuación, especialmente espacios, varias comillas y la tecla Intro. Compruebe si el procesamiento de caracteres chinos es correcto.

7. : En un sistema que puede ingresar chino Ingrese chino y vea si hay caracteres confusos o errores.

8. se muestra lo completado., se muestra ¿La información es consistente con la agregada?

Información duplicada: ingrese nombres o ID duplicados en alguna información que deba nombrarse y el nombre debe ser único. Vea si el sistema lo maneja y si se informará un error. Los nombres duplicados incluyen si el sistema maneja la distinción entre mayúsculas y minúsculas y los espacios antes y después del contenido de entrada se procesan correctamente.

10. En algunos lugares donde se puede eliminar información múltiple a la vez, no seleccione ninguna información y presione "eliminar" para ver cómo lo maneja el sistema y si habrá algún error, luego seleccione una o más información para eliminar y ver si; se procesa correctamente.

11. Verifique si agregar y modificar información es consistente: Verifique si agregar y modificar información es consistente ¿Son consistentes los requisitos? Por ejemplo, si agrega un elemento requerido, la modificación también debería ser obligatoria. ; si agrega un elemento que se especifica como un número entero, la modificación también debe ser un número entero.

12. Compruebe si hay nombres duplicados al modificar: cambie el elemento que no puede tener el mismo nombre al contenido existente. y vea si se procesará y se informará un error. Al mismo tiempo, también debe prestar atención a si se informará un error con el mismo nombre que el suyo.

13. formulario repetidamente: uno Para los registros que se han enviado correctamente, envíelos nuevamente después de regresar para ver si el sistema los ha procesado.

14. Compruebe si la tecla Atrás se usa varias veces: donde hay Atrás, Atrás, regrese a la página original, luego Atrás, repita varias veces para ver si hay un error.

15. Verificación de búsqueda: ingrese el contenido existente y no existente del sistema donde hay una función de búsqueda para ver si los resultados de la búsqueda son correctos. Si puede ingresar múltiples condiciones de búsqueda, puede agregar condiciones razonables e irrazonables en. al mismo tiempo para ver si el procesamiento del sistema es correcto

16. Posición de entrada de información: preste atención a si el cursor y la información ingresada saltarán a otros lugares al ingresar información donde permanece el cursor.

p>

17. Verifique la carga y descarga de archivos: si la función de carga y descarga de archivos está implementada y si los archivos cargados se pueden abrir. ¿Cuáles son las regulaciones sobre el formato de los archivos cargados, si el sistema tiene información explicativa y verifique si el sistema puede hacerlo?

18. Verificación de elementos requeridos: si el sistema ha procesado los elementos que deben completarse si no se completan y si hay un mensaje de aviso para los elementos requeridos, como agregar * delante. de los elementos requeridos

19. Comprobación de teclas de acceso directo: si se admiten teclas de acceso directo comunes, como Ctrl C Ctrl V Retroceso, etc., y si existen restricciones en los accesos directos para algunos campos que no lo permiten. entrada de información, como selección de personas y selección de fechas.

20. Verificación de la tecla Enter: presione la tecla Enter directamente después de ingresar para ver cómo lo maneja el sistema y si se informará un error. ¡Bienvenido *** para discutir! Si tienes tiempo, visita el laboratorio de TI y Tiantian Software Testing Network