1. Los elementos básicos del caso de prueba (4): entorno de prueba, pasos de operación, datos de prueba, resultados esperados
(Los elementos esenciales de un caso de prueba no requieren resultados de ejecución)
Caso de prueba (Test Case) es un conjunto de colecciones proporcionadas al sistema bajo prueba con el fin de implementar la prueba .
Este conjunto incluye: entorno de prueba, pasos de operación, datos de prueba, resultados esperados (título, número de serie, importancia, prioridad, método de operación) y otros elementos.
por ejemplo: al igual que los casos de uso en el DO en línea
- Entorno de prueba: LeetCode nos proporciona un entorno de prueba: como sistema Windows + navegador Chrome.
- Datos de prueba: Niuke.com puede ingresar datos de prueba por sí mismo, y el fondo también proporciona datos de prueba.
- Pasos de la operación: Escriba el código y haga clic en Enviar.
- Resultado esperado: haga clic en enviar, la tasa de aprobación es del 100%. Si el resultado esperado es el mismo que el resultado real, el caso de prueba pasa; de lo contrario, falla.
Los casos de prueba resuelven dos problemas principales: qué probar y cómo probar.
Un buen caso de prueba es que una persona que no está familiarizada con el negocio puede probar rápidamente según el caso de uso.
Criterios para evaluar casos de prueba:
- Los casos de uso se expresan claramente sin ambigüedad.
- El caso de uso es altamente operable.
- La entrada y la salida del caso de uso son claras.
- Un caso de uso tiene un solo resultado esperado.
- La mantenibilidad de los casos de uso es buena.
- Los casos de uso tienen una alta cobertura de requisitos.
2. Los beneficios de los casos de prueba
No se sabe cuántos casos de prueba escribir para un proyecto, dependiendo de la dificultad y los requisitos del proyecto.
Sin embargo, el diseño de casos de prueba es un trabajo laborioso y que requiere mucho tiempo, y a menudo lleva más tiempo diseñar casos de prueba que ejecutarlos. Entonces, ¿por qué escribir? razón:
- Los casos de prueba son la base para el ejecutor de pruebas.
- Los casos de prueba evalúan la cobertura de requisitos.
- Los casos de prueba pueden mejorar la eficiencia del trabajo de los evaluadores/reducir los problemas repetitivos del trabajo de los evaluadores. Reutilización, significado de referencia.
- Los casos de prueba son la base para construir pruebas automatizadas. [La automatización es liberar las manos de los evaluadores y dejar que el código ejecute la prueba en lugar de los humanos]
3. Método de diseño de casos de prueba (basado en pruebas de caja negra)
3.1 Diseñar casos de prueba basados en requisitos
Diseñar casos de prueba basados en requisitos es la base del diseño y desarrollo de pruebas.El primer paso es analizar los requisitos de prueba y verificar si los requisitos son correctos, completos, inequívocos y lógicamente coherentes. Sobre la base de los requisitos correctos, refine los requisitos de prueba, extraiga cada punto de prueba o elemento de prueba de los requisitos de prueba y luego diseñe el caso de prueba de acuerdo con cada punto de prueba.
Al analizar los requisitos de las pruebas, generalmente se divide en requisitos de pruebas funcionales y requisitos de pruebas no funcionales.
3.1.2 Análisis de prueba de requisitos funcionales
Para las pruebas funcionales, se pueden usar diagramas de bloques funcionales para ayudar al análisis de requisitos de prueba. En resumen, los requisitos de las pruebas funcionales suelen incluir los siguientes aspectos.
- Verificación de cada interfaz funcional del sistema.
- Utilice el negocio para encadenar funciones para realizar pruebas.
- Consistencia funcional, prueba interactiva (operación interactiva multifuncional).
- Entrada diferente del sistema, prueba de datos comerciales de salida de resultados.
- La operación incorrecta de la función, la prueba de la operación anormal (perteneciente a la prueba negativa).
- La verificación de algoritmos utilizada en la implementación de funciones a veces requiere una revisión del código.
- La facilidad de uso de las operaciones del usuario y la experiencia del usuario a menudo se verifican simultáneamente con las pruebas funcionales.
Para requisitos específicos, las funciones del sistema se pueden descomponer en varios módulos funcionales de acuerdo con la clasificación comercial, el rol del usuario o el área de operación del usuario, y luego se realiza el análisis de requisitos de prueba de acuerdo con los módulos funcionales. De acuerdo con la división de módulos funcionales, la división de módulos de negocios es la práctica más común.
Ejemplo 1: A continuación se analizan los requisitos de un sistema de calendario simple
El diagrama de bloques funcional del calendario analizado según el diseño funcional de la interfaz web es el siguiente:
También es posible usar un mapa mental, que es más conveniente y efectivo, y solo presenta los resultados del análisis de los requisitos de la prueba, lo que puede respaldar mejor la coherencia de las ideas del análisis de la prueba.
Ejemplo 2: A continuación se toma el terminal móvil de disco en la nube de Baidu como ejemplo para analizar la función
Al realizar un análisis de la demanda, se deben aplicar reglas comerciales como: ¿Existe algún límite para el tamaño de los archivos cargados?, ¿Cuántos archivos se deben cargar a la vez, por ejemplo, menos de 100?, ¿Cuántas capas tiene una carpeta como máximo?, etc.
Ejemplo 3:
3.1.3 Análisis de pruebas de requisitos no funcionales
Las pruebas de requisitos no funcionales implican principalmente rendimiento, seguridad, confiabilidad, compatibilidad, facilidad de mantenimiento y portabilidad, etc. Desde la perspectiva del análisis de requisitos de prueba, cada tipo de prueba característica no funcional debe analizarse por separado de acuerdo con los requisitos. Puede haber una influencia mutua entre ellos, por ejemplo, cuanto mayor sea la seguridad, es más probable que traiga mayores desafíos para la usabilidad y el rendimiento.
Lo que quiero explicar aquí es que para cada sistema de software de aplicación existen los requisitos de calidad de las características no funcionales, pero los diferentes tipos de proyectos tienen requisitos diferentes para cada característica no funcional. Esto debe basarse en proyectos específicos, necesidades específicas y Se analizan las características de las diferentes aplicaciones del producto.
- Software de cliente puro, como software de procesamiento de texto (Word, PPT), software de reproducción de medios (audio/video) (computadora integrada), etc. Este tipo de software tiene los requisitos más bajos para las pruebas funcionales del sistema, pero tiene ciertos requisitos de compatibilidad, estabilidad y portabilidad.
- Sistema de aplicación cliente/servidor (C/S) dentro de la empresa. Por ejemplo, el correo electrónico, los sistemas de mensajería instantánea (Fei Q, Enterprise QQ), etc., son más complejos que el cliente puro en términos de requisitos de prueba de funciones del sistema, que requieren funciones correctas y buena estabilidad. Pero en general, los requisitos de rendimiento, seguridad y compatibilidad no son altos.
- Sistemas de aplicaciones de red complejos y a gran escala externos, como comercio electrónico, banca en línea, sitios de video (Tencent, Youku), etc., además de los requisitos de prueba funcional de sistemas complejos, el rendimiento, seguridad, compatibilidad, tolerancia a fallas , y la fiabilidad del sistema, etc. tienen altas exigencias.
Además, para los sistemas de aplicaciones de nivel empresarial a gran escala, debido a los diferentes modos de aplicación y arquitecturas del sistema (distribuido, microservicios, etc.), debemos combinar la arquitectura y los modos de aplicación para analizar específicamente los requisitos de prueba no funcionales, especialmente la escalabilidad, la confiabilidad , seguridad, etc La arquitectura técnica tiene poco impacto en las funciones, pero las pruebas no funcionales requieren un análisis arquitectónico en profundidad para comprender mejor el alcance y el método de prueba.
ejemplo:
¿Cómo simular una red?
Con la ayuda de herramientas:
- Charles (usado más en la empresa)
- Violinista
3.2 Método de diseño específico
① Clase de equivalencia
De acuerdo con los requisitos, la entrada (se considerará la salida en casos especiales) se divide en varias clases de equivalencia, y se selecciona un caso de prueba de la clase de equivalencia, si este caso de prueba pasa la prueba, se considera que la equivalencia representada clase se pasa la prueba De esta manera se puede lograr la mayor cobertura funcional posible con menos casos de prueba, lo que resuelve el problema de que no se pueden realizar pruebas exhaustivas.
Clasificación de clase de equivalencia:
- Clase de equivalencia efectiva: El conjunto de insumos que satisfacen las necesidades del usuario.
- Clase de equivalencia no válida: un conjunto de entrada que no satisface las necesidades del usuario.
La clase de equivalencia solo considera la clasificación del dominio de entrada y no considera la combinación del dominio de entrada, lo que requiere otros métodos de diseño y suplementos.
Pasos para diseñar casos de prueba con pensamiento de clase de equivalencia:
- Entender completamente los requisitos.
- Divida las clases de equivalencia válidas y divida las clases de equivalencia no válidas.
- Extraiga datos de la clase de equivalencia efectiva para diseñar un caso de prueba y extraiga datos de una clase de equivalencia no válida para diseñar un caso de prueba.
ejemplo:
② Valor límite
El análisis de valor límite es un método de prueba de caja negra para probar el valor límite de entrada o salida. Por lo general, el método de análisis de valor límite se utiliza como complemento del método de partición de clases de equivalencia.En este caso, los casos de prueba provienen del límite de la clase de equivalencia.
- 6 < nombre de usuario.longitud < 15
- 7 <= nombre de usuario.longitud <= 14
(ambos son equivalentes)
División de punto límite:
- Punto superior: Un punto en el límite.
- Punto interior: Un punto dentro del límite (cualquiera de ellos).
- Desde el punto: un punto cerca del valor límite (el punto más cercano al punto superior fuera del intervalo cerrado y el punto más cercano al punto superior en el intervalo abierto).
Ejemplo 1: [6, 15]
- Puntuación máxima: 6, 15
- Punto interior: 12 (7~14 son aceptables)
- Fuera de punto: 5, 16
Ejemplo 2: (6, 15]
- Puntuación máxima: 6, 15
- Punto interno: 12 (6 ~ 14 son todos aceptables)
- Fuera de punto: 7, 16
Pasos para los casos de prueba de diseño de valor límite:
- Entender completamente los requisitos.
- Encuentre el punto límite.
- Diseño de casos de prueba para puntos límite.
ejemplo:
③Método de la tabla de decisiones (diagrama de causa y efecto)
Las tablas de decisión son otra herramienta para expresar juicios lógicos.
relación:
- y:
- o:
- Identidad:
- No: