Hable acerca de la prueba de inicio de sesión
Tal vez dirás que el objeto de prueba de "inicio de sesión de usuario" es demasiado simple, solo quiero encontrar un usuario, dejar que ingrese el nombre de usuario y la contraseña en la interfaz y luego haga clic en el botón "confirmar" para verificar si el inicio de sesión es exitoso . De hecho, esto constituye el caso de prueba más básico y típico, que también es el escenario más típico cuando los usuarios finales usan el sistema.
Pero como ingeniero de pruebas, su objetivo es garantizar que la función del sistema en diversos escenarios de aplicación cumpla con los requisitos de diseño, por lo que debe considerar casos de prueba más y más completos, de modo que pueda basarse en el "inicio de sesión del usuario" Descripción de requisitos funcionales, combinada con métodos equivalentes de división de clase y análisis de valor límite para diseñar una serie de casos de prueba.
Clase de equivalencia, valor límite
Entonces, ¿cuáles son los métodos de análisis de división de clase de equivalencia y valor límite? Primero, ambos pertenecen a los métodos de prueba de caja negra más comúnmente utilizados, más típicos y más importantes.
El método de división de clase de equivalencia consiste en dividir todos los datos de entrada posibles en varios subconjuntos. En cada subconjunto, si algún dato de entrada tiene el mismo efecto al revelar posibles errores en el programa, dicho subconjunto constituye un igual Categoría de precio Más adelante, siempre que se seleccione un valor aleatoriamente de cada clase de equivalencia para la prueba, se puede usar una pequeña cantidad de entrada de prueba representativa para obtener mejores resultados de cobertura de prueba.
El método de análisis del valor límite es seleccionar los valores límite de entrada y salida para la prueba. Debido a que una gran cantidad de errores de software usualmente ocurren en el límite del rango de entrada o salida, es necesario enfocarse en la prueba del valor límite, por lo general, elija el valor que sea exactamente igual, justo arriba o debajo del límite como datos de prueba. De la metodología se puede ver que el análisis del valor límite es complementario a la división de clases de equivalencia, por lo que estos dos métodos de prueba a menudo se usan en combinación
Ahora, para la función "inicio de sesión de usuario", basada en la división de clase de equivalencia y los métodos de análisis de valor límite, los casos de prueba que diseñamos incluyen:
después de enumerar estos casos de prueba, es posible que ya se sienta más satisfecho porque siente que ha realizado su propia prueba El conocimiento se utiliza en el diseño de estos casos de uso.
De hecho, el conjunto anterior de casos de prueba ya cubre los principales escenarios de prueba funcional. Pero a los ojos de un excelente ingeniero de pruebas, estos casos de uso solo pueden alcanzar estándares que apenas pasan.
¿Qué? ¿Acabo de aprobarlo? Si tiene esta idea, le sugiero que piense detenidamente antes de continuar leyendo el siguiente contenido. ¿Es necesario expandir realmente estos casos de prueba?
Ahora, comparta más casos de prueba que agregarán ingenieros de prueba experimentados:
Después de leer estos casos de uso, podría decir: "Wow, hay tantos puntos que deben probarse para una función de inicio de sesión simple". Sin embargo, no se conforme, la prueba de la función de "inicio de sesión de usuario" aún no ha terminado.
Aunque el conjunto de casos de prueba mejorado ha mejorado mucho en comparación con la cobertura de prueba anterior, desde la perspectiva de los probadores senior, hay muchos casos de uso que deben diseñarse.
Como dije, es posible que haya encontrado que todo el diseño del caso de prueba anterior se basa en la verificación de requisitos funcionales explícitos, en otras palabras, estos casos de prueba se verifican directamente para la funcionalidad de la función de "inicio de sesión de usuario". Y probado.
Sin embargo, además de los requisitos funcionales explícitos, otros requisitos no funcionales, es decir, requisitos funcionales implícitos, también son críticos para un sistema de software de excelente calidad. El significado de los requisitos funcionales explícitos puede entenderse muy literalmente, refiriéndose a las funciones específicas que el propio software necesita implementar, como "los usuarios normales pueden iniciar sesión con éxito con el nombre de usuario y la contraseña correctos", "no registrado El usuario no puede iniciar sesión "etc., que son descripciones explícitas típicas de requisitos funcionales.
¿Qué es un requisito no funcional? Desde la perspectiva de las pruebas de software, los requisitos no funcionales implican principalmente tres aspectos: seguridad, rendimiento y compatibilidad. En todo el diseño de caso de prueba anterior, no hemos considerado la prueba de requisitos no funcionales en absoluto, pero estos son a menudo los factores clave que determinan la calidad del software.
Después de comprender la importancia de las pruebas de requisitos no funcionales, primero puede pensar qué casos de prueba necesita diseñar, y luego ver qué casos de uso daré, creo que de esta manera lo ayudará más.
Caso de prueba de seguridad:
Casos de prueba de rendimiento:
Casos de prueba de compatibilidad:
Hablando de eso, ¿todavía crees que la prueba de función de "inicio de sesión de usuario" es muy simple y sin valor? Una prueba funcional aparentemente simple en realidad cubre tantos casos de prueba, además de cubrir requisitos funcionales claros, Hay muchos otros requisitos no funcionales que deben considerarse.
Además, a través del diseño de estos casos de prueba, también puede encontrar que un excelente ingeniero de pruebas debe tener un conocimiento muy amplio, si no puede tener una comprensión profunda del diseño del sistema bajo prueba, no entienda los principios básicos de los ataques de seguridad, no El dominio de los métodos de diseño básicos de las pruebas de rendimiento dificulta el diseño de casos de prueba "específicos".
A través de la prueba de función "inicio de sesión de usuario" en este ejemplo, espero que pueda estimularlo a pensar más sobre la prueba y abrir sus ideas para diseñar casos de prueba, a fin de lograr el efecto de tirar un ladrillo.
Después de leer estos casos de prueba, puede decir que todavía faltan algunos puntos de prueba que no están cubiertos, y los puntos de prueba de esta función no son lo suficientemente completos.
La inagotabilidad de las pruebas significa que, en la mayoría de los casos, es imposible realizar pruebas exhaustivas.
La llamada "prueba exhaustiva" se refiere a un método de prueba que incluye todas las combinaciones posibles de valores de entrada de software y requisitos previos. El sistema que completa la prueba exhaustiva no debe dejar defectos de software desconocidos. Porque si hay defectos de software desconocidos, puede encontrarlos haciendo más pruebas, lo que significa que sus pruebas no se han agotado.
Sin embargo, en la gran mayoría de las prácticas de ingeniería de software, las pruebas están limitadas por el tiempo y los costos económicos, y es imposible agotar todas las combinaciones posibles. En cambio, se adopta un modelo basado en el riesgo y el alcance de la prueba se selecciona con cierto énfasis Y diseñe casos de prueba para encontrar un equilibrio entre el riesgo de defectos y los costos de I + D.
Resumen
Primero, para las pruebas de software de alta calidad, el diseño de casos de uso no solo necesita considerar requisitos funcionales explícitos explícitos, sino que también implica una serie de requisitos no funcionales como la compatibilidad, la seguridad y el rendimiento. La calidad juega un papel decisivo.
En segundo lugar, un excelente ingeniero de pruebas debe tener un amplio conocimiento para diseñar casos de prueba específicos que sean más fáciles de encontrar.
Finalmente, el diseño del caso de uso de las pruebas de software es inagotable. En la práctica de la ingeniería, es difícil evitar el tiempo y los costos económicos. Por lo tanto, los ingenieros de pruebas excelentes necesitan equilibrar el riesgo de defectos y los costos de I + D.
————————————————
Declaración de derechos de autor: Este artículo es un artículo original del bloguero de CSDN "yinlin330", siguiendo el acuerdo de derechos de autor CC 4.0 BY-SA, adjunte el enlace original y esta declaración .
Enlace original: https://blog.csdn.net/yinlin330/article/details/90607335
