Prefacio
Hoy quiero hablar con usted sobre casos de prueba. Este artículo está escrito principalmente para socios de prueba, porque encuentro que todavía hay muchos amigos que no saben cómo comenzar cuando se encuentran con la escritura de casos de prueba. usted al respecto Solo una charla rápida, este artículo es principalmente para pruebas funcionales.
Al final de este artículo, el autor te ha preparado una sorpresa.
1. ¿Qué es un caso de prueba?
Un caso de prueba es un conjunto de entradas de prueba, condiciones de ejecución y resultados esperados compilados para un objetivo especial con el fin de probar la ruta de un programa o verificar si se cumple un requisito específico.
En términos sencillos: significa describir los pasos operativos de nuestro sistema de prueba en palabras de acuerdo con un formato determinado.
2. ¿Cuáles son los beneficios de escribir casos de prueba?
1. Aclara tus pensamientos y evita omisiones
Esto es lo que creemos que es el punto más importante: si el proyecto que probamos es grande y complejo, podemos subdividir las funciones del proyecto y organizar las ideas de nuestro sistema de prueba escribiendo casos de uso de acuerdo con cada función para evitar perder las funciones que se van a realizar. punto probado.
2. Seguimiento del progreso de la prueba
Al escribir casos de prueba y ejecutar casos de prueba, podemos conocer claramente el progreso de nuestras pruebas.
3. Referencia histórica
En los proyectos en los que trabajamos, puede haber muchas funciones que sean iguales o similares. Hemos diseñado casos de prueba para dichas funciones para que podamos usarlas como referencia cuando encontremos funciones similares en el futuro.
4. Repetibilidad
Cuando probamos un sistema, no podemos simplemente probarlo una vez por una sola persona. Se requieren varias personas para probarlo repetidamente. Luego necesitamos casos de prueba para estandarizar y guiar nuestro comportamiento de prueba.
3. Método de caso de prueba
Bien, ahora que sabemos qué es un caso de prueba y por qué deberíamos escribirlo, ¿cómo deberíamos escribirlo? No hay forma de empezar. Antes de escribir casos de prueba, primero aprendemos varios métodos, que son nuestros principios rectores para escribir casos de prueba.
1. División de clases de equivalencia
Un subconjunto del dominio de entrada en el que los datos de entrada son equivalentes a la hora de revelar errores en el programa. Si hay un cuadro de entrada que requiere la entrada de números del 1 al 10000, es imposible para nosotros probar todos los números. Nuestras entradas de 5 y 6 para verificar y exponer los errores en el cuadro de entrada pueden considerarse equivalentes. Luego, en este momento podemos extraer aleatoriamente algunos datos para su verificación. Tales como: 10, 99, 7777...
Clases de equivalencia: clases de equivalencia válidas y clases de equivalencia no válidas
El cuadro de entrada requiere la entrada de un número del 1 al 10000
Clases de equivalencia válidas: Puede ingresar un número entre 1-10000 para verificar, como por ejemplo: 2, 5, 99, 8495...
Clase de equivalencia no válida: Puede ingresar cualquier carácter distinto de 1-10000 para verificación, como: 20000, letras, guiones bajos, símbolos especiales, espacios, retornos de carro...
2. Valor límite
Los valores límite son un complemento de las clases de equivalencia. La experiencia de las pruebas nos dice que se producen una gran cantidad de errores en los valores límite de entrada y salida. Tomemos el ejemplo anterior: un cuadro de entrada requiere la entrada de un número entre 1 y 10000. Necesitamos probar si excede este rango, como: 0, -1, -2, 1000, 10001... etc., para determinar si excede nuestro rango.
3. Diagrama de causa y efecto
El producto final generado por el método del diagrama causal es una tabla de decisión, que es adecuada para verificar varias combinaciones de condiciones de entrada del programa. Por ejemplo: Razón: A = 0, B = 0. Como resultado, puedo determinar: A = B. Para ser precisos, es una idea causal. Implícitamente guiará nuestras pruebas. Por supuesto, para evitar perder cosas, podemos dibujar las relaciones causales en el sistema con imágenes. Sin embargo, si el sistema es grande y complejo, será una tarea laboriosa. jeje.
4. Método de adivinación incorrecto
Basándonos en la experiencia y la intuición, podemos especular sobre posibles errores en el sistema y diseñar casos de prueba de forma específica.
5. Otros
Hay muchos métodos para diseñar casos de prueba. Nosotros comúnmente usamos los métodos anteriores. Otros métodos incluyen: diagrama de transición de estado, método de análisis de procesos, método de verificación ortogonal, etc.
4. Formato y elementos de los casos de prueba.
Un caso de prueba debe incluir: número, título, escenario de prueba, pasos de prueba y resultados esperados.
Por supuesto, también puedes añadir algunas otras opciones, como: prioridad, fase de prueba…
Nota: El formato anterior está tomado del "Método de prueba de software de Microsoft". Puede que no sea adecuado para usted. Solo quiero que todos comprendan el formato de prueba.
Respecto al almacenamiento y gestión de casos de prueba:
1. El sistema de gestión de proyectos viene con gestión de casos de uso. Generalmente, los casos de uso están vinculados al proyecto, tienen un formato fijo, búsqueda, modificación y otras funciones, y son muy convenientes de usar. Por ejemplo: gestión de proyectos ZenTao, control de calidad, libre de errores, etc., todos tienen funciones de gestión de casos de uso.
2. Administrado a través del formulario de documento world\Excel, la ventaja de esto es que usted mismo puede definir el formato de los casos de prueba.
Ejemplo de caso de prueba
Ahora que casi hemos comprendido los conocimientos básicos, veamos un caso de prueba específico. Tendremos una comprensión más profunda.
Nota: Este no es un caso de prueba completo y el formato no es fijo. Puede escribir casos de prueba de diseño según sus propias necesidades.
Aparte de lo anterior, también necesitamos conocer los casos de prueba.
5. ¿Cuándo podemos diseñar casos de prueba?
Cuando el documento de análisis de requisitos del proyecto se compila de acuerdo con las necesidades del cliente, podemos escribir casos de prueba basados en el documento de requisitos. Sin embargo, en general, los documentos de requisitos de nuestros proyectos (la mayoría de las pequeñas empresas en China) son muy "rudimentarios", por lo que es difícil diseñar casos de prueba basados en los documentos de requisitos.
Tenemos que esperar hasta que los desarrolladores del proyecto desarrollen el proyecto y nos proporcionen los documentos del sistema, el entorno de implementación y la estructura de la base de datos (si el sistema involucra una base de datos), y eliminamos estos documentos para diseñar casos de prueba.
6. Revisión y actualización de casos de prueba.
Una vez completado el diseño del caso de prueba que diseñamos, ¿está completo? ¿Cumple con el sistema? ¿Cumplir con los requisitos del cliente? Una revisión de los casos de uso es esencial. En cuanto a los métodos de revisión, diferentes empresas tienen procesos diferentes.
Los casos de prueba que escribimos no permanecen sin cambios después de la revisión. A medida que los requisitos cambian y las funciones mejoran, los casos de prueba, por supuesto, también deberán actualizarse y cambiarse.
7. ¿En qué circunstancias no es adecuado escribir casos de prueba?
1. Tiempo de archivo
Si pruebo una función rápidamente y solo necesito probarla una vez, es más problemático y lleva mucho tiempo cuando diseñamos casos de prueba. No es necesario escribir casos de prueba en este momento.
2. La demanda cambia mucho y con frecuencia
Las funciones requeridas cambian con mucha frecuencia y en gran medida. Los casos de prueba escritos antes no se pueden usar en absoluto y deben reescribirse. No es necesario diseñar casos de prueba en este momento.
3. El tiempo del proyecto no lo permite.
Este no es un enfoque muy amable. Si no hay una necesidad urgente de entregarlo a los clientes, trate de no hacerlo; por supuesto, si es solo para exhibición o uso de prueba para los clientes, puede complementar y mejorar los casos de prueba más adelante. .
No escriba casos de prueba que estén incompletos o incomprensibles para otros, ya que no tendrían sentido.