Prefacio
Lo que hago más recientemente es diseñar casos de prueba y revisar casos de prueba, así que no pude evitar pensar en una pregunta clásica: ¿Cómo diseñar casos de prueba excelentes?
Los zapatos de algunos niños pueden sentir un poco de desaprobación cuando ven este problema, ¿en qué pensar? ¿Quién no sabe cómo diseñar casos de prueba cuando realiza pruebas?
Pero según mi experiencia personal y algunos contactos, esta habilidad básica de prueba no es tan fácil de hacer bien. Muchas personas pueden pensar que esto es demasiado básico y, a menudo, es más fácil ignorarlo, y les gusta buscar superestructuras como varios lenguajes de desarrollo, pruebas automatizadas y plataformas de prueba.
En mi opinión, las pruebas comerciales son la base y se utilizan otras pilas de tecnología para mejorar la eficiencia, y la prioridad es clara. Por otro lado, sólo comprendiendo a fondo el negocio podremos explorar mejor áreas donde se puede mejorar la eficiencia.
Bien, volvamos al tema. Hablemos brevemente sobre cómo diseñar casos de prueba según mi comprensión personal. Bienvenido a Exchange.
Cómo diseñar casos de prueba
1. Documentos de requisitos de investigación.
En términos generales, el proceso de prueba correcto debe ser: revisión de requisitos->diseño de caso de prueba->diseño de plan de prueba->entorno de prueba\preparación de datos->ejecutar el caso de uso para la prueba después de proponer la prueba y verificar si hay fugas y llenar los vacíos, de modo que Estudie detenidamente el documento de requisitos. Es la máxima prioridad.
En términos generales, los puntos funcionales del producto se definirán en el documento de requisitos. Primero podemos leer el artículo completo para obtener una impresión general de toda la función del producto y luego comenzar a profundizar en los detalles del producto desde múltiples ángulos para descubrir cosas valiosas. cosas:
Puntos de función explícita del producto: Esto es muy simple, es el contenido claramente definido en el producto.
Puntos de función implícitos del producto: puntos de función que no están claramente definidos por el producto pero que estarán involucrados.
Puntos de pregunta: Los requisitos no están claramente definidos o implica la confirmación de algunos alcances de prueba, etc.
Una vez que se genera el documento de requisitos, los departamentos relevantes generalmente generarán otros documentos auxiliares, como documentos de interacción UE y páginas de diseño de UI, que pueden ayudarnos a visualizar mejor el producto y diseñar mejor casos de prueba.
2. Comprender el desarrollo y el diseño.
Una vez determinados los requisitos, el desarrollo generalmente comenzará con el desarrollo y el diseño. Por lo general, hay algunos resultados como diseño de arquitectura, diagramas de flujo, diagramas de secuencia, documentos de interfaz, etc. No ignore estos documentos, creo que son muy valiosos.
Recuerde: incluso si está realizando pruebas de caja negra, no trate el sistema bajo prueba como una gran caja negra.
Debe tener una comprensión clara de la arquitectura interna, los enlaces de transmisión detrás de los datos, la separación de lectura y escritura de la base de datos, la configuración del middleware de mensajes Kafka, la distribución jerárquica del sistema de caché, la integración de terceros. sistemas, etc
Tomemos como ejemplo el negocio de control de automóviles en el que he estado ocupado recientemente: cuando hace clic para abrir la puerta en la aplicación móvil, ¿cómo llega este comando a la terminal del automóvil y cómo la terminal del automóvil devuelve el resultado? Debe saber por qué servicios y middleware pasa todo el enlace; de lo contrario, no se puede decir que esté realmente familiarizado con este negocio. Si no está realmente familiarizado con el negocio, ¿cómo puede realmente diseñar un caso de prueba excelente?
Los casos de uso diseñados únicamente en función de los puntos de demanda de prueba solo pueden cubrir la capa "superficial" y, a menudo, no cubren el flujo de procesamiento interno y el procesamiento ramal, y es probable que se pasen por alto defectos en las piezas que no están cubiertas.
Además, podemos comprender las ideas de implementación del desarrollo y los niños capaces pueden mirar directamente el código de desarrollo. Si no puede verlo, también puede comprender el proceso de implementación comunicándose con los desarrolladores, lo cual es de gran ayuda para nosotros.
A veces, cuando los desarrolladores le cuentan sobre el proceso de implementación, pueden incluso descubrir conscientemente algunos problemas.
Sin embargo, no debemos diseñar casos de prueba basados enteramente en la implementación del código desarrollado, sino en los requisitos originales.
3. Método de diseño de casos de uso
Ahora que sabe lo suficiente, comience a diseñar casos de prueba. Primero escribimos un mapa cerebral para registrar ideas y puntos problemáticos y, finalmente, escribimos la versión Excel de los casos de prueba. En general, es posible que Internet tradicional no requiera escribir Excel, lo que depende de las diferentes regulaciones de la empresa.
Sin embargo, no importa qué forma utilice, aún debe utilizar algunos métodos para diseñar su caso. Estos son los tres métodos de diseño de casos de prueba más utilizados:
Método de división de clases de equivalencia
Valor límite
Método de inferencia de errores
Por supuesto, aquí solo se enumeran estos tres, creo que son los más utilizados, al menos para la mayoría de los escenarios de prueba de software. Excepto en algunos campos específicos, también se utilizan el método del diagrama de causa y efecto, el método de análisis basado en tablas de decisión, el método de diseño experimental ortogonal, etc., pero no se enumeran aquí.
El método depende de qué tan bien puedas aplicarlo. Recuerda hacer preguntas similares a los candidatos durante la entrevista. El método es claro y lógico. Algunas personas comenzarán a dudar si les das un ejemplo específico. Estas son habilidades básicas que no son suficiente Rendimiento sólido.
4. Expansión multiángulo
Una vez diseñados los puntos funcionales básicos, es hora de ampliarlos desde más perspectivas y explorar algunas necesidades ocultas. Por ejemplo:
-
Función: interacción con otros módulos, si las pruebas de integración son suficientes
-
Rendimiento: ¿La interfaz involucrada tiene escenarios de presión, escenarios de concurrencia, etc.?
-
Seguridad: cifrado de la transmisión/almacenamiento de datos, si se debe desensibilizar, etc.
-
Compatibilidad: si diferentes dispositivos, diferentes sistemas y diferentes pantallas se muestran bien, cubriendo los modelos principales del mercado.
-
Facilidad de uso: si la función es amigable para los amigos, si el mensaje es amigable, etc.
Finalmente me gustaría agradecer a todos los que leyeron atentamente mi artículo, la reciprocidad siempre es necesaria, aunque no es algo muy valioso, si puedes usarlo, puedes tomarlo directamente:
Esta información debería ser el almacén de preparación más completo y completo para los amigos [de pruebas de software]. Este almacén también ha acompañado a decenas de miles de ingenieros de pruebas en el viaje más difícil. ¡Espero que también pueda ayudarlo a usted!