¿Qué son los casos de prueba?
-
Casos legales
-
Centro de capacitación en tecnología avanzada Zhongke Yonglian
El caso de prueba es A Conjunto de entradas de prueba, condiciones de ejecución y resultados esperados escritos con un objetivo específico en mente, para probar la ruta de un programa o verificar que cumple con requisitos específicos.
Actualmente no existe una definición clásica de casos de prueba. En términos generales, se refiere a la descripción de una tarea de prueba de un producto de software específico, que incorpora el plan, el método, la tecnología y la estrategia de prueba. El contenido incluye objetivos de prueba, entorno de prueba, datos de entrada, pasos de prueba, resultados esperados, scripts de prueba, etc. y formar un documento.
Los diferentes tipos de software tienen diferentes casos de prueba. A diferencia de los sistemas, herramientas, controles y software de juegos, las necesidades de los usuarios del software de gestión son más inconsistentes y cambian cada vez más rápido. El autor se dedica principalmente a probar software de gestión empresarial. Por lo tanto, nuestro enfoque es separar los datos de prueba y los scripts de prueba de los casos de prueba. Los casos de prueba suelen ser planes de prueba diseñados para las funciones, reglas comerciales y procesamiento comercial de productos de software. La prueba de cada función específica o ruta de operación del software constituye un caso de prueba.
Con el desarrollo de la industria de software de China, las pruebas de software también se están desarrollando. Desde las pruebas iniciales a tiempo parcial de los programadores de software hasta el establecimiento de departamentos de pruebas independientes a tiempo completo en empresas de software. El trabajo de pruebas también ha evolucionado desde pruebas simples hasta pruebas formales, que incluyen: preparación de planes de prueba, redacción de casos de prueba, preparación de datos de prueba, redacción de guiones de prueba, implementación de pruebas, evaluación de pruebas, etc. Los métodos de prueba han evolucionado desde pruebas puramente manuales hasta un énfasis igual en las pruebas manuales y automáticas, y existe una tendencia hacia empresas de pruebas profesionales de terceros.
La medida más poderosa para garantizar la satisfacción del usuario final con el software es aclarar sus expectativas, validando así esas expectativas y confirmando su validez. Los casos de prueba reflejan los requisitos que deben verificarse. Sin embargo, diferentes evaluadores pueden verificar estos requisitos de diferentes maneras. Por ejemplo, la ejecución del software para verificar su funcionalidad y rendimiento se puede realizar mediante un probador utilizando tecnología de prueba automática; los pasos de apagado de un sistema informático se pueden realizar mediante pruebas y observación manuales; sin embargo, la participación de mercado y los datos de ventas (y la demanda del producto); Esto sólo se puede lograr mediante la evaluación de datos de ventas competitivas y de productos.
Dado que puede no ser posible (o necesario) verificar todos los requisitos, la capacidad de seleccionar los requisitos más apropiados o críticos para las pruebas está relacionada con el éxito o el fracaso del proyecto. Elegir qué requisitos validar será el resultado de sopesar el costo, el riesgo y la necesidad de validar los requisitos.
La identificación de casos de prueba es importante por los siguientes motivos.
Los casos de prueba son la base para diseñar y desarrollar el proceso de prueba.
La "profundidad" de las pruebas es proporcional al número de casos de prueba. Debido a que cada caso de prueba refleja un escenario, condición o flujo de eventos diferente en el producto, a medida que aumenta el número de casos de prueba, obtendrá más confianza en la calidad del producto y el proceso de prueba.
Uno de los principales métodos de evaluación para juzgar la integridad de las pruebas es la cobertura basada en requisitos, que se basa en la cantidad de casos de prueba identificados, implementados y/o ejecutados. Una afirmación como: "Se han ejecutado y verificado 95 de los casos de prueba clave" es mucho más significativa que "Hemos completado 95 de las pruebas".
La carga de trabajo de prueba es proporcional al número de casos de prueba. A partir de casos de prueba completos y detallados, se puede estimar con mayor precisión el progreso temporal de cada fase sucesiva del ciclo de prueba.
El tipo de diseño y desarrollo de pruebas y los recursos necesarios están controlados principalmente por casos de prueba.
Los casos de prueba generalmente se clasifican según sus tipos de prueba o requisitos de prueba asociados, y cambiarán en consecuencia a medida que cambien los tipos y requisitos. La mejor solución es compilar al menos dos casos de prueba para cada requisito de prueba:
Un caso de prueba se utiliza para demostrar que se ha cumplido el requisito, generalmente llamado caso de prueba positivo;
El otro Un caso de prueba refleja condiciones o datos inaceptables, anormales o inesperados y se utiliza para demostrar que los requisitos sólo pueden satisfacerse bajo las condiciones requeridas. Este caso de prueba se denomina caso de prueba negativo.
En primer lugar, los casos de prueba son el núcleo de las pruebas de software.
La importancia de las pruebas de software es incuestionable. Sin embargo, cómo completar la prueba en el menor tiempo con la menor inversión de mano de obra y recursos materiales, descubrir los defectos del sistema de software y garantizar la excelente calidad del software es el objetivo que las empresas de software exploran y persiguen. Cada producto de software o proyecto de desarrollo de software requiere un excelente plan y método de prueba.
Hay muchos factores que afectan las pruebas de software, como la complejidad del software en sí, la calidad de los desarrolladores (incluido el personal de análisis, diseño, programación y pruebas), la aplicación de métodos y tecnologías de prueba, etc. . Porque algunos factores existen objetivamente y son inevitables. Algunos factores son volátiles e inestables, por ejemplo, el equipo de desarrollo es fluido, las personas con experiencia se van y las nuevas personas continúan uniéndose al trabajo de una persona específica también se verá afectada por las emociones, etc. ¿Cómo garantizar la estabilidad de la calidad de las pruebas de software? Con los casos de prueba, no importa quién realice las pruebas, pueden garantizar la calidad de la prueba haciendo referencia a los casos de prueba. El impacto de los factores humanos se puede minimizar. Incluso si el caso de prueba inicial no está bien pensado, se mejorará a medida que avance la prueba y se actualice la versión del software.
Por lo tanto, el diseño y redacción de casos de prueba es lo más importante en las actividades de prueba de software. Los casos de prueba son una guía para el trabajo de prueba y un criterio que se debe seguir para las pruebas de software. Esta es también la garantía fundamental para la calidad estable de las pruebas de software.
En segundo lugar, prepare casos de prueba
Este artículo presenta principalmente algunos métodos específicos para escribir casos de prueba.
1. Documento de caso de prueba
La redacción de documentos de caso de prueba requiere una plantilla de documento y debe cumplir con las especificaciones internas. La documentación de los casos de prueba estará sujeta al software de gestión de casos de prueba.
Los casos de prueba para productos de software o proyectos de desarrollo de software generalmente se forman en documentos de casos de prueba basados en módulos de software o subsistemas del producto, pero esta no es una regla absoluta.
El documento del caso de prueba consta de una introducción y casos de prueba. La parte de introducción escribe el propósito de la prueba, el alcance de la prueba, los términos definidos, los documentos de referencia, la descripción general, etc. La sección de casos de prueba enumera cada caso de prueba uno por uno. Cada caso de prueba específico incluirá los siguientes detalles: número de caso de uso, nombre del caso de uso, nivel de prueba, criterios de entrada, pasos de verificación, resultados esperados (incluidos criterios de evaluación), criterios de salida, comentarios, etc. El contenido anterior cubre los elementos básicos de los casos de prueba: indicadores de prueba, entorno de prueba, entradas de prueba, operaciones de prueba, resultados esperados y criterios de evaluación.
2. Configuración de casos de prueba
Nuestros primeros casos de prueba se configuraron por función. Posteriormente, se introdujo el método de análisis de ruta para establecer casos de uso basados en la ruta. Lo que ha evolucionado es que los casos de uso se configuran en un patrón híbrido de funciones y rutas.
La prueba por función es la más sencilla y cada función se prueba utilizando una especificación de caso de uso.
Para los módulos de programa con operaciones complejas, la implementación de sus funciones es interactiva, estrechamente relacionada y entrelazada, y puede evolucionar hacia una gran cantidad de cambios. Sin un análisis lógico riguroso, las omisiones son inevitables. El análisis de ruta es un buen método y su mayor ventaja es que puede evitar pruebas perdidas.
Pero el método de análisis de ruta también tiene limitaciones. Hay más de una docena de rutas en un módulo de mantenimiento de diccionario muy sencillo. No es de extrañar que un módulo complejo tenga entre decenas y cientos de rutas. Los autores creen que esta es una escala adecuada para el análisis de rutas. Si un subsistema tiene diez o más módulos, estos módulos están interrelacionados. Si se vuelve a utilizar el método de análisis de ruta, el número de rutas aumenta geométricamente y alcanza más de 5 dígitos, y no se puede utilizar. Entonces, las rutas de prueba o los casos de prueba entre módulos del subsistema aún deben resolverse utilizando métodos tradicionales. Aquí es donde entra en juego la configuración de casos de uso basados en una combinación de características y rutas.
3. Diseñar casos de prueba
Los casos de prueba se pueden dividir en eventos básicos, eventos alternativos y eventos anormales. Al diseñar casos de uso para eventos básicos, consulte la especificación del caso de uso (o especificación de diseño) y, mediante el análisis de ruta, diseñe casos de prueba basados en funciones y operaciones relacionadas. Para funciones aisladas, los casos de prueba se diseñan directamente en función de la función. Los casos de prueba para eventos básicos deben contener toda la funcionalidad requerida con una cobertura de 100.
Diseñar casos de uso para eventos alternativos y de excepción es mucho más complejo y difícil.
Por ejemplo, la codificación de un diccionario es única y no se puede repetir. La prueba debe verificar que ya existan restricciones en los códigos del diccionario en el sumador del diccionario. Si hay duplicación de código, se debe informar un error y el texto del error debe ser correcto. Los documentos que a menudo se forman durante las fases de diseño y codificación no analizan ni describen eventos alternativos y eventos anormales con suficiente detalle. La prueba en sí requiere la verificación de todos los eventos no básicos y el descubrimiento de defectos de software tanto como sea posible.
Los métodos básicos comúnmente utilizados en las pruebas de software se pueden utilizar para diseñar casos de prueba, como el método de división de clases de equivalencia, el método de análisis de valores límite, el método de inferencia de errores, el método de diagrama de causa y efecto, el método de cobertura lógica, etc. Se utilizan diferentes métodos dependiendo de las diferentes propiedades del software. Cómo utilizar de manera flexible varios métodos básicos para diseñar casos de prueba completos y, en última instancia, exponer defectos ocultos depende de la rica experiencia y el diseño cuidadoso de los diseñadores de pruebas.
En tercer lugar, el papel de los casos de prueba en las pruebas de software
1. Guiar la implementación de las pruebas
Los casos de prueba son principalmente adecuados para pruebas de integración, pruebas de sistemas y prueba de regresión. Durante las pruebas, los casos de prueba se utilizan como estándar de prueba y los evaluadores deben seguir estrictamente los casos de prueba y los pasos de prueba para implementar las pruebas una por una. Y registre la situación de la prueba en el software de gestión de casos de prueba para generar automáticamente documentos de resultados de la prueba.
De acuerdo con el nivel de prueba de los casos de prueba, qué casos de uso deben probarse mediante pruebas de integración y qué casos de uso deben probarse mediante pruebas del sistema y pruebas de regresión, estos se han dejado claro al diseñar los casos de prueba. y los evaluadores no pueden ser arbitrarios al implementar las pruebas.
2. Planificar la preparación de los datos de prueba
En nuestra práctica, los datos de prueba se separan de los casos de prueba. Prepare uno o más conjuntos de datos de prueba originales y resultados de pruebas estándar basados en casos de prueba. Especialmente para que los conjuntos de datos, como los informes de prueba, sean correctos, es muy necesario preparar los datos de prueba de acuerdo con la planificación del caso de prueba.
Además de los datos normales, también se debe diseñar una gran cantidad de datos de bordes y datos de error de acuerdo con los casos de prueba.
3. Escriba el script de prueba "Especificación de diseño"
Para mejorar la eficiencia de las pruebas, las pruebas de software han desarrollado vigorosamente las pruebas automatizadas. La tarea central de las pruebas automatizadas es escribir guiones de prueba. Si la programación de software en ingeniería de software debe tener especificaciones de diseño, entonces las especificaciones de diseño de los scripts de prueba son casos de prueba.
4. Puntos de referencia de medición para evaluar los resultados de las pruebas
Después de completar la implementación de la prueba, es necesario evaluar los resultados de la prueba y preparar un informe de prueba. Se necesitan algunos resultados cuantitativos para juzgar si las pruebas del software se han completado y medir la calidad de las pruebas. Ejemplo: ¿Qué es la cobertura de pruebas, tasa de aprobación, tasa de aprobación de pruebas importantes, etc.? El punto de referencia estadístico anterior era un módulo de software o un punto de función, que era demasiado aproximado. Usar casos de prueba como puntos de referencia de medición es más preciso y efectivo.
5. Estándares para el análisis de defectos
Al recopilar defectos y comparar casos de prueba con la base de datos de defectos, analícelos para confirmar si los defectos se han omitido o se han reproducido. Las pruebas faltantes reflejan la imperfección de los casos de prueba, y los casos de prueba correspondientes deben complementarse de inmediato, mejorando en última instancia la calidad del software paso a paso. Ya existen casos de prueba correspondientes, que reflejan problemas en la implementación de pruebas o procesamiento de cambios.
Cuarto tema relacionado
1. Revisión de casos de prueba
Los casos de prueba son los criterios para las pruebas de software, pero no se convierten en criterios una vez escritos. . Durante el proceso de diseño y redacción de casos de prueba, se debe organizar una revisión por pares. Una vez completada la preparación, se debe organizar una revisión de expertos y solo se podrá utilizar después de aprobarla. El comité de revisión puede estar formado por líderes de proyecto, evaluadores, programadores, analistas y diseñadores, y también puede incluir representantes de los clientes.
2. Modificación y actualización de casos de prueba
Los casos de prueba deben mejorarse después de su registro. Principalmente por tres razones: en primer lugar, se descubrió durante el proceso de prueba que el diseño de los casos de prueba estaba mal considerado y necesitaba mejoras; en segundo lugar, los defectos del software se informaron después de que el software fue entregado y utilizado, y los defectos fueron causados por lagunas en el software; los casos de prueba; en tercer lugar, el software en sí. Con nuevas funciones y actualizaciones de la versión del software, los casos de prueba también deben modificarse y actualizarse.
En términos generales, se pueden realizar pequeñas modificaciones y mejoras en el documento del caso de prueba original, pero el documento debe tener un registro de los cambios.
Cuando se actualiza la versión del software, normalmente también se deben actualizar los casos de prueba.
3. Software de gestión de casos de prueba
El uso de casos de prueba también requiere un software de gestión de casos de prueba. Tiene tres funciones principales: en primer lugar, puede importar automáticamente los contenidos clave del documento del caso de prueba, como el número, el nombre, etc., a la base de datos de gestión para formar un registro que corresponda completamente al documento del caso de prueba; se utiliza para ingresar las condiciones de la prueba a tiempo durante la implementación de la prueba. En tercer lugar, la documentación de los resultados de la prueba se genera automáticamente, incluida cada métrica de la prueba, tablas de cobertura de la prueba y una lista de casos de prueba que pasaron o no la prueba.
Con el software de gestión, los evaluadores pueden escribir fácilmente registros de pruebas diarios o generar informes de pruebas de software.
Diseño verbal (abreviatura de verbo) de casos de prueba
(A) Tecnología de caja blanca
La prueba de caja blanca es una prueba estructurada, por lo que la prueba El objeto Es básicamente el programa fuente y los casos de prueba se diseñan en función de la lógica interna del programa.
1. Cobertura lógica
El grado de cobertura lógica dentro del programa Cuando hay bucles en el programa, es imposible cubrir todas las rutas. Es necesario diseñar un caso de prueba que cubra los caminos más representativos con alta cobertura. Con base en el programa que se muestra en la Figura 7-1, se analizan varias técnicas de superposición comunes.
(1) Cobertura del extracto.
Para aumentar la probabilidad de encontrar errores, cada instrucción del programa debe ejecutarse durante la prueba. La cobertura de declaraciones se refiere al diseño de suficientes casos de prueba para que cada declaración en el programa bajo prueba pueda ejecutarse al menos una vez.
Como se muestra en la Figura 7-1, es un diagrama de flujo del programa bajo prueba:
(2) Determinar la cobertura.
La cobertura de decisiones se refiere al diseño de suficientes casos de prueba para que cada expresión de decisión en el programa bajo prueba pueda obtener al menos un valor "verdadero" y un valor "falso", de modo que cada rama del programa pase. al menos una vez. Por lo tanto, la cobertura de decisiones también se denomina cobertura de sucursales.
(3) Cobertura condicional.
La cobertura condicional se refiere al diseño de suficientes casos de prueba para que todos los valores posibles de cada condición en la expresión de juicio aparezcan al menos una vez.
(4) Juicio/prueba de condición.
El criterio de cobertura se refiere a diseñar suficientes casos de prueba para que todos los valores posibles de cada condición de la expresión de decisión aparezcan al menos una vez, y todos los resultados posibles de cada expresión de decisión también aparezcan al menos una vez.
(5) Cobertura combinada de condiciones.
La cobertura de combinación condicional es un estándar de cobertura sólido, que se refiere a diseñar suficientes casos de prueba para que la combinación de varios valores posibles de las condiciones en cada expresión de decisión aparezca al menos una vez.
(6) Cobertura de caminos.
La cobertura de rutas se refiere al diseño de suficientes casos de prueba para cubrir todas las rutas posibles en el programa bajo prueba.
En las pruebas de cobertura lógica reales, los casos de prueba generalmente se diseñan en función de la cobertura de combinación condicional y luego se agregan algunos casos de prueba para lograr los estándares de prueba de cobertura de ruta.
2. Cobertura de bucle
3. Pruebas de ruta básicas
(B) Tecnología de caja negra
1. p>
(1) Dividir clases de equivalencia.
① Si la condición de entrada especifica el rango de valores o el número de valores. Luego se puede determinar una clase de equivalencia razonable (el valor o número de entrada está dentro del rango) y dos clases de equivalencia no razonables (el valor o número de entrada es menor que el valor mínimo del rango o mayor que el valor máximo del rango).
(2) Si se especifica un conjunto de valores para los datos de entrada y el programa trata diferentes valores de entrada de manera diferente, entonces cada valor de entrada permitido es una clase de equivalencia razonable, y también hay equivalencias no razonables. clases.class (no se permite ningún valor de entrada).
(3) Si se especifican las reglas que deben seguir los datos de entrada, se pueden determinar una clase de equivalencia razonable (que se ajuste a las reglas) y varias clases de equivalencia irrazonables (que violen las reglas desde todos los ángulos).
④ Si los elementos de la clase de equivalencia dividida se tratan de manera diferente en el programa, entonces la clase de equivalencia debe dividirse en clases de equivalencia más pequeñas.
(2) Determinar casos de prueba.
①Numerar cada clase de equivalencia.
② Diseñe un caso de prueba para cubrir tantas clases de equivalencia razonables como sea posible. Repita este paso hasta que todas las clases de equivalencia razonables estén cubiertas por casos de prueba.
③ Diseñe un caso de prueba que solo cubra una clase de equivalencia no razonable.
2. Análisis de valores límite
Al diseñar casos de prueba, el análisis de valores límite generalmente se combina con la división de clases de equivalencia. Pero no selecciona un ejemplo de la clase de equivalencia como representante, sino que toma el límite de prueba como objeto de enfoque y selecciona datos de prueba que son exactamente iguales, apenas mayores o menores que el valor del límite.
(1) Si la condición de entrada especifica un rango de valores, puede seleccionar datos justo iguales al valor límite como un caso de prueba razonable, o puede seleccionar datos justo más allá del valor límite como un caso de prueba no razonable . Si el rango de valores de entrada es [1, 100], los valores de 0, 1, 100 y 101 se pueden utilizar como datos de prueba.
(2) Si la condición de entrada indica el número de datos de entrada, el caso de prueba se diseña en función del número máximo, el número mínimo, 1 menos que el número mínimo y 1 mayor que el número máximo. . Por ejemplo, un archivo de entrada puede contener entre 1 y 255 registros y luego diseñar casos de prueba para archivos de entrada que contengan 1 registro, 255 registros y 0 registros respectivamente.
(3) Para cada condición de salida, determine el límite del valor de salida de acuerdo con los principios anteriores (1) o (2) respectivamente. Por ejemplo, un sistema de gestión del desempeño de los estudiantes estipula que solo se pueden consultar los puntajes de los estudiantes universitarios en los grados 95 a 98 y se pueden diseñar casos de prueba. De esta manera, es necesario diseñar los puntajes de los estudiantes de una determinada clase o cuatro. clases dentro del rango de consulta (clases de equivalencia de salida irrazonables).
Debido a que el límite del valor de salida no corresponde al límite del valor de entrada, es posible que no sea posible verificar el límite del valor de salida, ni producir resultados que excedan el valor de salida. pero debes intentarlo nuevamente si es necesario.
(4) Si los campos de entrada o salida proporcionados en la especificación del programa son conjuntos ordenados (como archivos secuenciales, listas lineales, listas enlazadas, etc.), el primer y último elemento del conjunto deben ser seleccionados como casos de prueba.
3. Especulación incorrecta
Al probar un programa, las personas pueden inferir varios errores que pueden existir en el programa basándose en la experiencia o la intuición y, por lo tanto, escribir casos de prueba específicos para verificar estos errores. , este es el método de inferencia de errores.
4. Diagrama de causa y efecto
Los métodos de análisis del método de división de clases de equivalencia y de valor límite solo consideran la función de prueba de cada dato de entrada de forma aislada y no consideran los efectos de múltiples combinaciones de datos de entrada.
5. Estrategia integral
Cada método puede diseñar un conjunto de ejemplos útiles y es fácil encontrar un tipo de error, pero puede que no sea fácil encontrar otro tipo de error. error. Por lo tanto, en las pruebas reales, se combinan varios métodos de prueba para formar una estrategia integral. Por lo general, el método de caja negra se utiliza primero para diseñar casos de prueba básicos y luego el método de caja blanca para complementar algunos casos de prueba necesarios.
Sexto, malentendidos en el diseño de casos de prueba
(Fuente: Guanhe Examination Network)
Es bueno utilizar casos de uso que puedan descubrir defectos que aún no se han descubierto. Se han descubierto casos de uso;
En primer lugar, debo decir que esta oración realmente tiene sentido, pero encuentro que muchas personas malinterpretan el significado original de esta oración y están obsesionadas con diseñar y descubrir "difíciles". "Encontrar defectos" y caer en Ser ciegamente unilateral y olvidar el propósito de las pruebas da mucho miedo. Tiendo a pensar en un caso de prueba como una colección, y su evaluación solo se puede realizar en la colección de casos de prueba. El examen en sí es una especie de "V; AMpv". La prueba debe garantizar los dos puntos siguientes:
El programa hace lo que debe hacer.
El programa no hizo nada que no debía hacer.
Por lo tanto, como base de la implementación de la prueba, los casos de prueba deben poder cubrir completamente los requisitos de la prueba y no deben juzgarse sobre un solo caso de prueba.
El caso de prueba debe registrar toda la información de operación en detalle para que una persona que no haya estado expuesta al sistema pueda probarlo.
No sé si alguna empresa nacional; Realmente puedo hacer esto, o no sé si alguna empresa nacional puede escribir cada caso de prueba con tanto detalle.
En mi experiencia en pruebas, he tenido muchas preguntas sobre el detalle y la complejidad de las descripciones de los casos de prueba. Está escrito de forma tan sencilla que nadie puede ejecutarlo excepto usted mismo. La redacción es demasiado detallada y el tiempo dedicado al mantenimiento de los casos de prueba (no olvide que los casos de prueba son dinámicos. Una vez que el entorno de prueba, los requisitos, el diseño y la realidad cambian, los casos de prueba también deben cambiar en consecuencia) es realmente sorprendente. En la actualidad, puede resultar difícil para la mayoría de las empresas de software nacionales hacer esto debido a la falta de recursos de prueba. Pero me encontré con algunos jefes o líderes de proyecto, o incluso los propios ingenieros de pruebas. Independientemente de los recursos reales, deben escribir un caso de uso que "las personas que nunca han estado expuestas al sistema puedan probarlo".
Antes de discutir este tema, podemos considerar el propósito de las pruebas. El propósito de las pruebas es encontrar tantos defectos en el programa como sea posible. La actividad de prueba en sí también puede considerarse como un proyecto, que debe alcanzar los objetivos tanto como sea posible bajo las condiciones de recursos dadas. Según mi experiencia personal, la mayoría de las empresas de software nacionales no tienen recursos suficientes para realizar pruebas, por lo que los objetivos de la prueba deben definirse claramente durante la etapa de planificación de la prueba y todo debe centrarse en los objetivos de la prueba.
Además de las limitaciones de recursos, el nivel de detalle en los casos de prueba también debe determinarse según sea necesario. Si el ejecutor del caso de prueba, el diseñador del caso de prueba y las personas involucradas en las actividades de prueba tienen un conocimiento profundo del sistema, no es necesario describir el caso de prueba con demasiado detalle. La función de los documentos es la comunicación, siempre que se pueda lograr el propósito de la comunicación, está bien. En los proyectos en los que actúo como director de pruebas, durante la etapa de planificación de pruebas, el diseño de la prueba generalmente demora entre 30 y 40 días. El ingeniero de diseño de pruebas puede determinar los detalles de los casos de prueba de acuerdo con las necesidades del proyecto. El personal relevante involucrado en la revisión del caso de prueba realizará inspecciones.
El diseño de casos de prueba es algo que se hace de una vez por todas;
No creo que nadie aquí reconozca esta frase, pero en situaciones reales, a menudo podemos encontrar la sombra de esto. idea. Una vez participé en un proyecto donde los requisitos y el diseño del software se habían cambiado muchas veces, pero los casos de prueba no se habían modificado en absoluto. El resultado directo es que los nuevos ingenieros de pruebas se pierden al ejecutar casos de prueba, y el resultado indirecto es que los casos de prueba se convierten en una pila de papel de desecho. Después de verse plagados de informes de errores no válidos varias veces, los desarrolladores dan la espalda a los evaluadores.
Este ejemplo puede ser extremo, pero en el proceso de desarrollo real, no es raro que los casos de prueba no estén sincronizados con los requisitos y diseños. Los documentos de casos de prueba son documentos "vivos" que los ingenieros de pruebas deben tener en cuenta.
Los casos de prueba no deben contener datos reales;
Un caso de prueba es "un conjunto de entradas, condiciones de ejecución y resultados esperados", y sin duda debe incluir datos de entrada claros y resultados esperados. . Un caso de prueba sin datos de prueba es, en el mejor de los casos, sólo instructivo y no tiene ejecutabilidad. Por supuesto, incluir datos de entrada en casos de prueba traerá problemas como el mantenimiento y la sincronización con el entorno de prueba. En este sentido, el libro "Pruebas efectivas de software" proporciona casos de prueba detallados y métodos de mantenimiento de datos de prueba para su referencia.
No se requieren medios de verificación obvios en los casos de prueba;
He visto muchos casos de prueba escritos por ingenieros de pruebas en los que el "resultado esperado" solo se describe como el comportamiento visible del programa. . De hecho, los "resultados esperados" significan más que sólo el comportamiento visible de un programa. Por ejemplo, para el sistema de pedidos, si ingresa los datos del pedido y hace clic en Aceptar, el sistema le indicará "Pedido exitoso". ¿Es este un caso de uso completo? ¿La salida del sistema de "pedido exitoso" debería ser nuestro único método de verificación? Aparentemente no. El éxito del pedido depende de si se actualiza el registro de datos correspondiente. Por lo tanto, en tal caso de uso, también se debe incluir un medio explícito para verificar los resultados de la prueba: ejecutar una declaración de consulta en la base de datos para ver si los resultados de la consulta son consistentes con las expectativas.
7. Generar casos de prueba a partir de casos de uso.
Los casos de prueba utilizados para las pruebas funcionales provienen de los casos de uso del objetivo de prueba. Los casos de prueba deben compilarse para cada escenario de caso de uso. El escenario del caso de uso debe identificarse describiendo la ruta del caso de uso, que debe atravesar todos los procesos básicos y opcionales desde el principio hasta el final del caso de uso.
Por ejemplo, cada ruta diferente del caso de uso en la siguiente figura refleja el flujo básico y el flujo opcional, ambos representados por flechas. El flujo básico está representado por una línea recta negra, que es el camino más sencillo a través del caso de uso. Cada proceso alternativo comienza con un proceso básico y luego ejecuta el proceso alternativo bajo ciertas condiciones. Un flujo alternativo puede volver a unirse al flujo base (Flujos alternativos 1 y 3), o puede originarse a partir de otro flujo alternativo (Flujo alternativo 2), o terminar el caso de uso sin volver a unirse a un flujo (Flujos alternativos 2 y 4).
Ejemplo de flujo de eventos para un caso de uso
Al seguir las posibles rutas para cada caso de uso en el diagrama anterior, se pueden identificar diferentes escenarios de casos de uso. A partir del proceso básico y luego combinando el proceso básico con procesos alternativos, se pueden determinar los siguientes escenarios de casos de uso:
Escenario 1 Flujo Básico
Escenario 2 Flujo Básico Flujo Alternativo 1
p>
Escenario 3 Flujo básico flujo alternativo 1 Flujo alternativo 2
Escenario 4 Flujo básico flujo alternativo 3
Escenario 5 Flujo básico flujo alternativo 3 Corriente alternativa 1
Escenario 6 Corriente básica Corriente alternativa 3 Corriente alternativa 1 Corriente alternativa 2
Escenario 7 Corriente básica Corriente alternativa 4
Escenario 8 Corriente básica Flujo alternativo 3 Flujo alternativo 4
Nota: Por conveniencia, los escenarios 5, 6 y 8 solo describen la situación en la que el bucle que se muestra en el flujo alternativo 3 se ejecuta una vez.
La generación de casos de prueba para cada escenario se realiza identificando condiciones específicas que conducirán a la ejecución de un escenario de caso de uso específico.
Por ejemplo, supongamos que el caso de uso descrito en el diagrama anterior define el proceso alternativo 3 de la siguiente manera:
"Si el monto en USD ingresado en el paso 2 'Ingresar monto de retiro' anterior excede saldo de la cuenta actual, se producirá este flujo de eventos. El sistema mostrará un mensaje de advertencia y luego volverá a unirse al proceso básico y realizará el paso 2 "Ingresar monto de retiro" anterior. En este momento, el cliente del banco puede ingresar un nuevo monto de retiro. p>
Con base en esto, puede comenzar a identificar los casos de prueba que necesita usar para realizar el proceso alternativo 3:
ID del caso de prueba Condiciones del escenario Resultado esperado
TC x Escenario 4 No. Paso 2: Monto del retiro > Saldo de la cuenta Vuelva a unirse al flujo básico en el paso 2.
TC y Escenario 4 Paso 2 - Monto de Retiro
TC z Escenario 4, Paso 2 - Monto de Retiro = Saldo de Cuenta No ejecute el proceso alternativo 3 y ejecute el proceso básico.
Nota: El caso de prueba que se muestra arriba es muy simple porque no se proporciona información adicional. Los casos de prueba rara vez son tan simples.
El siguiente es un ejemplo más realista de cómo generar casos de prueba a partir de casos de uso.
Ejemplo:
Protagonista y caso de uso de un cajero automático.
La siguiente tabla contiene el proceso básico y algunos procesos alternativos para el caso de retiro en la figura anterior:
El comienzo de este caso de uso es que el cajero automático está listo.
Prepárese para retirar dinero: el cliente inserta la tarjeta bancaria en el lector de tarjetas del cajero automático.
Verificar tarjeta bancaria: el cajero automático lee el código de cuenta de la banda magnética de la tarjeta bancaria para comprobar si es una tarjeta bancaria aceptable.
Ingresar PIN-ATM requiere que los clientes ingresen un código PIN (4 dígitos).
Verificar código de cuenta y PIN: verifique el código de cuenta y el PIN para determinar si la cuenta es válida y si el PIN ingresado es correcto para la cuenta. Para este flujo de eventos, la cuenta es válida y el PIN de esta cuenta es correcto.
Opciones de cajero automático: el cajero automático muestra las diversas opciones disponibles en la máquina. En este flujo de eventos, los clientes del banco normalmente seleccionan "Retirar".
Ingresar monto: el monto a retirar del cajero automático. Para este flujo de eventos, el cliente debe seleccionar un monto preestablecido ($10, $20, $50 o $100).
Autorización: el cajero automático inicia el proceso de verificación enviando el ID de la tarjeta, el PIN, el monto y la información de la cuenta como una transacción al sistema bancario. Para este flujo de eventos, el sistema bancario está en línea y responde a la solicitud de autorización, aprueba la finalización del proceso de retiro y actualiza el saldo de la cuenta en consecuencia.
Emitir moneda - proporcionar efectivo.
Pagar la tarjeta bancaria: la tarjeta bancaria ha sido devuelta.
Recibos: imprima recibos y entréguelos a los clientes. El cajero automático también actualizará sus registros internos en consecuencia.
Al finalizar el caso de uso, el cajero automático vuelve a estar listo.
Proceso alternativo 1-Proceso básico para invalidación de tarjeta bancaria Paso 2-Verificar la tarjeta bancaria Si la tarjeta no es válida, devolverla y notificar mensajes relevantes.
Proceso alternativo dos - Cajero automático sin efectivo - Opción cajero automático En el quinto paso del proceso básico, si el cajero automático es sin efectivo, la opción "Retiro" no estará disponible.
El proceso alternativo La escasez de efectivo en el cajero automático se incluye en el Paso 6 del proceso básico: ingresar el monto. Si el monto en el cajero automático es menor que el monto solicitado para retiro, se mostrará un mensaje apropiado y el proceso básico se reincorporará al paso 6: Ingresar monto.
Proceso alternativo 4: PIN incorrecto en el proceso básico Paso 4: verificar la cuenta y el PIN; el cliente tiene tres oportunidades para ingresar el PIN.
Si el PIN se ingresa incorrectamente, el cajero automático mostrará el mensaje correspondiente; si todavía hay una oportunidad de ingresar, este flujo de eventos se reincorporará al flujo básico en el paso 3: Ingresar el PIN.
Si el último PIN intentado sigue siendo incorrecto, el cajero automático retendrá la tarjeta, el cajero automático volverá al estado listo y el caso de uso finalizará.
Flujo Alternativo 5 - La cuenta no existe en el Flujo Básico Paso 4 - Verificar cuenta y PIN. Si el código devuelto por el sistema bancario indica que no se puede encontrar la cuenta o que los retiros de la cuenta están prohibidos, el cajero automático muestra un mensaje apropiado y se reincorpora al proceso básico en el paso 9: Devolución a la tarjeta bancaria.
Proceso opcional 6-proceso básico paso 7-el monto del libro en la autorización es insuficiente, el sistema bancario devuelve un código que indica que el saldo de la cuenta es menor que el monto ingresado en el proceso básico paso 6-ingrese el monto, y luego el cajero automático muestra un mensaje apropiado y vuelve a unirse al proceso básico ingresando el monto en el paso 6-
Proceso alternativo 7 - Monto máximo de retiro diario alcanzado En el proceso básico Paso 7 - Autorización, el sistema bancario devuelve un código que indica que el cliente ha excedido o excederá el monto máximo permitido para retirar dentro de 24 horas, y Luego, el cajero automático muestra la información adecuada y vuelve a unirse al proceso básico en el Paso 6: Ingresar el monto.
Proceso alternativo Al mismo tiempo, se envía un mensaje de alerta apropiado al sistema bancario indicando que el cajero automático ha sido suspendido.
El cliente puede decidir dar por terminada la transacción (salir) en cualquier momento. Cuando finalice la transacción, se retirará la tarjeta bancaria.
El cajero automático de flujo z-"tilt-up" opcional contiene una serie de sensores para monitorear diversas funciones, como detectores de energía, manómetros en diferentes puertas y entradas, y detectores de movimiento. En cualquier momento, si alguien