¿Qué es un caso de prueba?
--------- ----
Caso de prueba
---- ---------- ----
Centro de Capacitación Técnica Avanzada CYL
Un caso de prueba es un conjunto de entradas de prueba, condiciones de ejecución y resultados esperados preparados para un objetivo específico, con el propósito de probar el ruta o verificación del programa Si se cumplen requisitos específicos.
El caso de prueba (TESt CASe) no tiene una definición clásica. A menudo se lo denomina una descripción de las tareas de prueba realizadas en un producto de software específico, que incorpora procedimientos, métodos, técnicas y estrategias de prueba. Su contenido incluye objetivos de prueba, entorno de prueba, datos de entrada, pasos de prueba, resultados esperados, guiones de prueba, etc., y forma un documento.
Las diferentes categorías de software tienen diferentes casos de prueba. Por ejemplo, a diferencia del software del sistema, el software de herramientas, el software de control y el software de juegos, las necesidades del usuario 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 más programas 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 y la madurez de la industria del software de China, las pruebas de software también están en constante desarrollo. 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 también han evolucionado desde pruebas puramente manuales a un énfasis igual en las pruebas manuales y automáticas, y ha habido una tendencia hacia empresas de pruebas profesionales de terceros.
La forma más eficaz de satisfacer a los usuarios finales con software es establecer claramente sus expectativas para que puedan ser verificadas y validadas. Los casos de prueba reflejan los requisitos que deben verificarse. Sin embargo, diferentes evaluadores pueden realizar la verificación de estos requisitos de diferentes maneras. Por ejemplo, los evaluadores pueden ejecutar el software para verificar su funcionalidad y rendimiento utilizando técnicas de prueba automatizadas; los pasos de apagado del sistema informático se pueden lograr mediante pruebas y observación manuales; sin embargo, la participación de mercado y los datos de ventas (así como los requisitos del producto) solo pueden realizarse; puede lograrse a través de Complete mediante la evaluación de datos de productos y ventas competitivas.
Dado que no es posible (o no es responsabilidad) verificar todos los requisitos, la capacidad de seleccionar los requisitos más apropiados o críticos para las pruebas puede determinar el éxito o el fracaso del proyecto. Elegir qué requisitos validar es una compensación entre costo, riesgo y la necesidad de validar los requisitos.
Identificar casos de prueba es importante por varias razones.
Los casos de prueba son la base para diseñar y desarrollar procesos de prueba.
La "profundidad" de las pruebas es directamente 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 a través del producto, a medida que aumenta el número de casos de prueba, más confianza tendrá en la calidad de su producto y su proceso de prueba.
Una de las principales medidas de integridad de las pruebas es la cobertura de requisitos, que a su vez se basa en la cantidad de casos de prueba que se han identificado, implementado y/o ejecutado. Una afirmación como "se han ejecutado y verificado 95 de los casos de prueba críticos" es más significativa que "se han completado 95 de nuestras pruebas".
El esfuerzo de prueba es proporcional al número de casos de prueba. Basándose en casos de prueba completos y detallados, se puede estimar con mayor precisión el tiempo de cada etapa del ciclo de prueba.
El tipo de diseño y desarrollo de pruebas y los recursos necesarios están controlados en gran medida por los casos de prueba.
Los casos de prueba generalmente se clasifican según el tipo de prueba o los requisitos de prueba asociados con ellos, y cambiarán en consecuencia.
La mejor solución es desarrollar 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, lo que a menudo se denomina caso de prueba positivo;
El otro Un caso de prueba que refleja condiciones o datos inaceptables, anormales o inesperados y se utiliza para demostrar que un requisito sólo puede cumplirse en las condiciones esperadas se denomina caso de prueba negativo.
Los casos de prueba son el núcleo de las pruebas de software
La importancia de las pruebas de software está fuera de toda duda. Sin embargo, cómo completar la prueba en el menor tiempo con la mínima inversión de mano de obra y recursos materiales, descubrir defectos en el 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 necesita un conjunto de excelentes planes y métodos 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 análisis, el diseño, la programación y los probadores), el uso de métodos y tecnologías de prueba, etc. Porque algunos factores son objetivos e inevitables. Algunos factores son volátiles e inestables, como el equipo de desarrollo es fluido, las personas con experiencia se van y constantemente se agrega gente nueva, el trabajo de una persona específica también se verá afectado por las emociones, etc. ¿Cómo garantizar la estabilidad de la calidad de las pruebas de software? Con los casos de prueba, sin importar quién realice la prueba, la calidad de la prueba se puede garantizar 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á continuamente a medida que avancen las pruebas y se actualice la versión del software.
Por lo tanto, diseñar y escribir casos de prueba es la tarea más importante en las actividades de prueba de software. Los casos de prueba son pautas para el trabajo de prueba y las pruebas de software deben seguir las pautas. Es la garantía fundamental para la estabilidad de la calidad de las pruebas de software.
2. Escribir casos de prueba
Céntrese en algunos métodos específicos para escribir casos de prueba.
1. Documento de caso de prueba
El documento de caso de prueba debe ser una plantilla de documento escrito y debe cumplir con las especificaciones internas. La documentación de casos de prueba está 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 organizan en documentos de casos de prueba según los módulos de software o subsistemas del producto, pero este no siempre es el caso.
El documento de caso de prueba consta de dos partes: introducción y casos de prueba. La introducción incluye el propósito de la prueba, el alcance de la prueba, definiciones de términos, documentos de referencia, 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, nombre del caso, nivel de prueba, criterios de entrada, pasos de verificación, resultados esperados (incluidos los criterios de evaluación), criterios de salida, comentarios, etc. Lo anterior cubre los elementos básicos de los casos de prueba: índice de prueba, entorno de prueba, entrada de prueba, operación 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. Más tarde, introdujimos el método de análisis de ruta para establecer casos de uso por ruta. Actualmente, ha evolucionado hacia un modelo híbrido de configuración de casos de uso por función y ruta.
La prueba por función es la más sencilla, recorriendo cada función según la especificación del caso de uso.
Para módulos de programa con operaciones complejas, la implementación de cada función es interactiva, estrechamente relacionada y entrelazada, y puede evolucionar hacia una gran cantidad de cambios. Sin un análisis lógico estricto, las omisiones son inevitables. El análisis de ruta es un buen método y su mayor ventaja es que puede evitar omitir pruebas.
Pero el análisis de rutas también tiene limitaciones. En un módulo de mantenimiento de diccionario muy simple, hay más de diez rutas. No sorprende que los módulos complejos tengan entre decenas y cientos de rutas. El autor cree que esta es una escala más apropiada para utilizar el análisis de ruta. Si un subsistema tiene más de diez o más módulos, estos módulos están relacionados entre sí. Luego, al utilizar el análisis de rutas, el número de rutas aumentará exponencialmente, alcanzará más de 5 dígitos y quedará inutilizable. 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 el patrón híbrido de configurar casos de uso por función y ruta.
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 de eventos básicos, debe consultar la especificación del caso de uso (o especificación de diseño) y diseñar casos de prueba de acuerdo con el método de análisis de ruta basado en funciones y operaciones relevantes. Para funciones aisladas, los casos de prueba deben diseñarse directamente por función. Los casos de prueba para eventos básicos deben contener todas las funciones necesarias que deben implementarse con una cobertura de 100.
Diseñar casos de uso para eventos de sustitución y excepción es mucho más complejo y difícil. Por ejemplo, los códigos del diccionario son únicos y no se permite la duplicación. La prueba necesita verificar que las restricciones en el código del diccionario ya existen en el sumador del diccionario; si el código está duplicado, se debe informar un error y que el texto del error es correcto. La documentación producida durante las fases de diseño y codificación a menudo no es lo suficientemente detallada como para permitir el análisis de eventos alternativos y anómalos. La prueba en sí requiere la verificación de todos los eventos no esenciales mientras se intenta encontrar defectos del software.
Puede utilizar los métodos básicos comúnmente utilizados en las pruebas de software: método de división de clases de equivalencia, método de análisis de valores límite, método de especulación de errores, método de diagrama de causa y efecto y método de cobertura lógica para diseñar casos de prueba. Se utilizan diferentes métodos según la naturaleza 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 del diseñador de pruebas.
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 pruebas de regresión. . Al implementar pruebas, los casos de prueba sirven como estándares de prueba y los evaluadores deben seguir estrictamente los elementos de prueba y los pasos de prueba en los casos 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.
Según el nivel de prueba de los casos de prueba, las pruebas de integración deben probarse en esas circunstancias, las pruebas del sistema y las pruebas de regresión deben probarse en esas circunstancias, se ha especificado claramente al diseñar los casos de prueba y las pruebas de las pruebas de implementación El personal no puede realizar cambios a voluntad.
2. Planificar la preparación de los datos de prueba
En nuestra práctica, los datos de prueba y los casos de prueba están separados. Prepare uno o varios conjuntos de datos sin procesar de prueba y resultados de pruebas estándar de acuerdo con el paquete de casos de prueba. Especialmente cuando se prueba la exactitud de conjuntos de datos como informes, los datos de prueba deben prepararse de acuerdo con el plan 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. "Especificaciones de diseño" para escribir scripts de prueba
Para mejorar la eficiencia de las pruebas, las pruebas de software han desarrollado vigorosamente las pruebas automatizadas. La tarea principal de las pruebas automatizadas es escribir scripts 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 para los scripts de prueba son casos de prueba.
4. Puntos de referencia métricos para evaluar los resultados de las pruebas
Después de completar la implementación de la prueba, debe evaluar los resultados de la prueba y escribir un informe de prueba. Para determinar si las pruebas de software están completas, medir la calidad de las pruebas requiere algunos resultados cuantitativos. Por ejemplo: cuál es la cobertura de la prueba, cuál es la tasa de aprobación de la prueba, cuál es la tasa de aprobación de la prueba importante, etc. Los puntos de referencia estadísticos anteriores eran módulos de software o puntos de función, que eran demasiado aproximados. Usar casos de prueba como puntos de referencia de medición es más preciso y efectivo.
5. Criterios para analizar defectos
Al recopilar defectos y compararlos con casos de prueba y bases de datos de defectos, podemos analizar y confirmar si se trata de una prueba fallida o una recurrencia del defecto. . Las pruebas faltantes reflejan la imperfección de los casos de prueba, y los casos de prueba correspondientes deben complementarse de inmediato para lograr en última instancia el propósito de mejorar gradualmente la calidad del software. La ausencia de casos de prueba correspondientes refleja problemas con la ejecución de pruebas o el procesamiento de cambios.
4. Cuestiones relacionadas
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 compilados. La revisión por pares debe organizarse durante el proceso de diseño y redacción de casos de prueba. Una vez completada la preparación, se debe organizar una revisión de expertos y solo se podrá utilizar después de aprobar la revisión. El comité de revisión puede estar compuesto por líderes de proyecto, pruebas, programación, análisis, diseño y otro personal relevante, y también se puede invitar a participar a representantes de los clientes.
2. Modificación y actualización de casos de prueba
Los casos de prueba deben mejorarse continuamente una vez documentados. Las razones provienen principalmente de tres aspectos: primero, durante el proceso de prueba, se encontró que los casos de prueba diseñados no estaban bien pensados y necesitaban mejoras; segundo, los defectos del software reportados durante la entrega y el uso del software, y los casos de prueba causados por; los defectos tenían lagunas; en tercer lugar, para nuevas funciones del software en sí y actualizaciones de la versión del software, los casos de prueba deben modificarse y actualizarse.
En circunstancias normales, basta con realizar pequeñas modificaciones y mejoras en los casos de prueba originales, pero debe quedar un registro de las modificaciones en el documento. Cuando se actualiza la versión del software, los casos de prueba generalmente deben compilarse y actualizarse a la versión actualizada.
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. Sus funciones principales son tres: primero, importa automáticamente los contenidos clave del documento del caso de prueba, como el número, el nombre, etc., a la base de datos de administración para formar un registro que corresponde completamente al caso de prueba y al documento del caso de prueba; en segundo lugar, registra la situación de la prueba de manera oportuna para la implementación de la prueba; en tercer lugar, finalmente, se realiza la generación automática de documentos de resultados de la prueba, incluida la tabla de indicadores de la prueba, la tabla de cobertura de la prueba y la lista de casos de prueba de pruebas aprobadas o fallidas; .
A través del software de gestión, los evaluadores pueden escribir fácilmente registros de prueba diarios o producir informes de prueba de software.
V. Diseño de casos de prueba
(1) Tecnología de caja blanca
Las pruebas de caja blanca son pruebas estructurales, por lo que el objeto bajo prueba es básicamente el programa fuente. Diseñar casos de prueba basados en 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. Debe diseñarse para tener una. mayor grado de cobertura o Casos de prueba que cubren las rutas más representativas. Con base en el programa que se muestra en la Figura 7-1, a continuación se analizan varias tecnologías de cobertura 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 se ejecute al menos una vez.
La Figura 7-1 muestra el diagrama de flujo del programa bajo prueba:
(2) Cobertura del juicio.
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 obtenga al menos un valor "verdadero" y un valor "falso", de modo que cada rama del programa pase en al menos una vez, por lo que la cobertura de decisión también se denomina cobertura de sucursal. Por lo tanto, la cobertura de decisiones también se denomina cobertura de sucursales.
(3) Cobertura de condición.
La cobertura condicional se refiere al diseño de suficientes casos de prueba para que cada valor posible de cada condición en la expresión de decisión ocurra al menos una vez.
(4) Sentencia/prueba condicional.
Este estándar de cobertura se refiere a diseñar 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, y para que todos los resultados posibles de cada expresión de juicio también aparezcan al menos una vez. una vez.
(5) Cobertura combinada de condiciones.
La cobertura de combinación condicional es un estándar de cobertura más sólido. Se refiere a diseñar suficientes casos de prueba para que todas las combinaciones posibles de valores de las condiciones en cada expresión de juicio aparezcan 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, el diseño de casos de prueba generalmente se basa en una cobertura combinada condicional, complementada con algunos casos de uso, para lograr el estándar de prueba de cobertura de ruta.
2. Cobertura de bucle
3. Pruebas de ruta básicas
(2) Tecnología de caja negra
1. p>
(1) División de clases de equivalencia.
(1) Si la condición de entrada especifica un rango de valores o una cantidad de valores. Entonces se pueden establecer una clase de equivalencia razonable (el valor de entrada o el valor numérico está dentro de este rango) y dos clases de equivalencia no razonables (el valor de entrada o el valor numérico es menor que el valor mínimo de este rango o mayor que el valor máximo de este rango). determinado.
② Si se especifica un conjunto de valores de datos de entrada y el programa procesa diferentes valores de entrada de manera diferente, entonces cada valor de entrada permitido es una clase de equivalencia razonable. Hay una clase de equivalencia razonable diferente. (cualquier valor de entrada que no esté permitido).
3) Si especifica reglas que deben cumplir los datos de entrada, puede determinar una clase de equivalencia razonable (que se ajuste a las reglas) y varias clases de equivalencia irrazonables (que violen las reglas desde varias perspectivas).
④ Si los elementos de la clase de equivalencia dividida se tratan de manera diferente en el programa, la clase de equivalencia debe dividirse en clases de equivalencia más pequeñas.
(2) Determinar casos de prueba.
(1) Numerar cada clase de equivalencia.
② Diseñe un caso de prueba para cubrir tantas clases de equivalencia razonables como sea posible que aún no se hayan cubierto. Repita este paso hasta que los casos de prueba cubran todas las clases de equivalencia razonables.
3) Diseñar un caso de prueba de modo que solo cubra una clase de equivalencia no razonable.
2. Análisis de valores límite
Al diseñar casos de prueba, el uso del análisis de valores límite generalmente se combina con la división de clases de equivalencia. Sin embargo, en lugar de tomar cualquier instancia en la clase de equivalencia como representante, toma el valor límite del caso de prueba como objetivo de enfoque y selecciona si los datos de prueba son exactamente iguales, exactamente mayores o exactamente menores que el valor límite. .
(1) Si la condición de entrada especifica un rango numérico, puede seleccionar datos que sean exactamente iguales al valor límite como un caso de prueba razonable, o puede seleccionar datos que simplemente crucen el valor límite como un caso de prueba irrazonable. Por ejemplo, si el rango de valores de entrada es [1, 100], puede utilizar los valores 0, 1, 100, 101, etc. como datos de prueba.
(2) Si la condición de entrada indica el número de datos de entrada, los casos de prueba se diseñan de acuerdo con el número máximo, el número mínimo, menor que el número mínimo 1, mayor que el número máximo 1, etc. . Por ejemplo, un archivo de entrada puede contener entre 1 y 255 registros y luego diseñar casos de prueba para 1 registro, 255 registros y 0 registros en el archivo de entrada.
(3) De acuerdo con los principios anteriores (1) o (2), determine las condiciones de contorno del valor de salida de cada condición de salida. Por ejemplo, un sistema de gestión del desempeño de los estudiantes estipula que solo puede consultar los puntajes de los estudiantes universitarios en los grados 95 a 98. Puede diseñar un caso de prueba para consultar los puntajes de una clase o cuatro estudiantes, pero también necesita diseñar una consulta. para consultar las puntuaciones de los estudiantes en los grados 94 y 99. Casos de prueba para las calificaciones (clases de equivalencia de resultados irrazonables).
Dado 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 puede producir resultados que excedan el valor de salida. pero aun así deberías intentarlo si es necesario.
(4) Si el dominio de entrada o salida proporcionado en la descripción del programa es un conjunto ordenado (como un archivo secuencial, una lista lineal, una lista enlazada, etc.), el primer elemento y el último elemento de se debe seleccionar el conjunto. Un elemento sirve como caso de prueba.
3. Método de especulación de errores
En un programa de prueba, las personas pueden especular que puede haber varios errores en el programa basándose en la experiencia o la intuición y, por lo tanto, escribir casos de prueba para verificar. de manera específica. Estos errores son suposiciones erróneas.
4. Diagrama de causa y efecto
El método de división de clases de equivalencia y el método de análisis del método de valor límite consideran la función de prueba de un único dato de entrada de forma aislada, sin considerar la combinación de error de entrada múltiple.
5. Estrategias combinadas
Cada enfoque puede producir un conjunto de ejemplos útiles que facilitan la detección de un tipo de error, pero pueden no ser fáciles de detectar otro tipo de error. . Por lo tanto, en las pruebas reales, se deben utilizar varios métodos de prueba conjuntamente 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.
6. Malentendidos en el diseño de casos de prueba
(Fuente: Guanghe Test Network
--Es un buen caso de uso encontrar casos de uso sin defectos encontrados. hasta ahora;
Lo primero de lo que estoy seguro es que esta oración es realmente muy razonable, pero descubrí que muchas personas han malinterpretado el significado original de esta oración y están decididas a diseñar un producto que pueda encontrar. "Defectos difíciles de encontrar" Casos de uso, caer en la unilateralidad ciega y olvidar cuál es el propósito de las pruebas, es terrible. Tiendo a pensar que los casos de prueba son una colección de entendimientos y su evaluación solo se puede realizar en. la colección de casos de prueba es una actividad "Vamp; AMp; V" en sí misma. Las pruebas deben garantizar los dos puntos siguientes:
El programa hace lo que debe hacer
. El programa no hace lo que no debe hacer Cosas
El programa no hace lo que no debe hacer
El programa no hace lo que no debe hacer
El programa no hace lo que no debe hacer
El programa no hace lo que no debe hacer
El programa no hace lo que no debe hacer
p>El programa no hace lo que no debe hacer
El programa no hace lo que se supone que debe hacer
Por lo tanto, los casos de prueba son la base de la implementación de la prueba y deben cubrirse completamente. Los requisitos de prueba no pueden juzgarse por un solo caso de prueba.
El caso de prueba debe registrar toda la información de la operación en detalle, de modo que una persona que no haya estado expuesta al sistema también puede realizar la prueba;
No sé si alguna empresa nacional realmente ha hecho esto, o no sé si alguna empresa nacional puede escribir cada caso de prueba en Tal detalle En mi experiencia de prueba, el nivel de detalle en la descripción del caso de prueba es muy alto. Si está escrito de manera demasiado simple, nadie puede ejecutarlo excepto usted. , Se necesitará tiempo para mantener el caso de prueba (no olvide que el caso de prueba es dinámico. Una vez que el entorno de prueba, los requisitos, el diseño y la implementación cambian, los casos de prueba también cambiarán en consecuencia). Es realmente sorprendente. La mayoría de las empresas de software nacionales que actualmente carecen de recursos de prueba pueden ser difíciles de lograr, pero he entrado en contacto con muchos de esos jefes o líderes de proyectos, e incluso algunos de los propios ingenieros de pruebas no consideran la situación real de los recursos. Casos de prueba que pueden ser probados por personas que nunca han tocado el sistema.
Antes de discutir este tema, primero consideremos las pruebas. El propósito de las pruebas es encontrar tantos defectos en el programa como sea posible. La actividad de prueba puede considerarse como un proyecto y también debe lograr tantos objetivos como sea posible en las condiciones de recursos dadas. Según mi experiencia personal, la mayoría de las empresas de software nacionales no tienen suficientes recursos de prueba, por lo que debemos aclarar las pruebas. objetivos durante la etapa de planificación de la prueba y todo debe centrarse en los objetivos de la prueba.