T2 Pruebas: Técnicas y estrategias Flashcards
Prueba de software
Verificación dinámica del comportamiento de un programa sobre un conjunto finito de casos de prueba, apropiadamente seleccionados desde el dominio usualmente infinito de ejecuciones contra el comportamiento esperado
Defecto (defect, fault, «bug»)
Un problema que si no es corregido podría causar que una aplicación o bien fallara o produjera resultados incorrectos. Es la causa de un mal funcionamiento.
Fallo (failure)
Un evento por el cual un sistema o componente no realiza
la función requerida dentro de los límites especificados. El mal funcionamiento.
Especificación de casos de prueba
Un conjunto de entradas de prueba, condiciones de
ejecución y resultados esperados desarrollados para un objetivo particular tal como ejecutar un camino particular de un programa o verificar el cumplimiento de un requisito específico. Deben describir valores esperados y especificados para la prueba, comprobar entradas válidas e inválidas, y inspeccionar al detalle los resultados documentándolos.
Aproximación para las pruebas
Un método particular que será empleado para seleccionar los valores de un caso de prueba particular.
Diseño de pruebas
Documentación especificando los detalles de la aproximación de pruebas para una característica o combinación de características e identificando las pruebas asociadas.
Banco de pruebas
Entorno que contiene todo el hardware y software necesario para testear un componente software o un sistema software
Software En Prueba
Sistema software o componente
software que se va a probar
Clasificación de las técnicas de prueba
Caja blanca (también caja de cristal) si las pruebas están basadas en
información acerca de cómo el software ha sido diseñado o
codificado, o caja negra si los casos de prueba se basan sólo en el
comportamiento de entrada/salida del software
Caja blanca
Pruebas que tienen en cuenta los
mecanismos internos de un sistema o componente Para diseñar los casos de prueba, el tester tiene que conocer la estructura interna del SUT. Las pruebas de caja blanca consumen mucho tiempo: se aplican a porciones pequeñas del software, como por ejemplo un módulo o una función. Útiles para revelar defectos en el diseño y estructuras de control, en la lógica y secuencias, o en la inicialización o en el flujo de datos
Análisis de cobertura y criterios de adecuación
Análisis de cobertura en qué medida los casos de prueba satisfacen el criterio de adecuación de las pruebas.
Tres criterios:
Criterio de adecuación de sentencias: todas las sentencias del SUT son ejecutadas al menos una vez
Criterio de adecuación de decisión: los casos de prueba tienen que ser diseñados de manera que cada decisión será ejecutada con todas las posibles salidas al menos una vez.
Criterio de adecuación de condición: los casos de prueba son diseñados para que
cada condición individual en cada predicado compuesto considere todos los posibles valores al menos una vez.
Cuanto más exigente sea el criterio de cobertura, mayor será el número
de casos de prueba que tienen que ser desarrollados para asegurar una cobertura completa
Análisis de cobertura y criterios de adecuación
Análisis de cobertura en qué medida los casos de prueban satisfacen el
criterio de adecuación de las pruebas. Tres criterios:
Criterio de adecuación de sentencias: todas las sentencias del SUT son ejecutadas
al menos una vez
Criterio de adecuación de decisión: los casos de prueba tienen que ser diseñados
de manera que cada decisión será ejecutada con todas las posibles salidas al menos una
vez. Criterio de adecuación de condición: los casos de prueba son diseñados para que
cada condición individual en cada predicado compuesto considere todos los posibles
valores al menos una vez.
Cuanto más exigente sea el criterio de cobertura, mayor será el número
de casos de prueba que tienen que ser desarrollados para asegurar una cobertura completa
CAJA BLANCA- Prueba de flujo de datos.
Una variable está definida en una sentencia cuando su valor es
asignado o cambiado y es utilizada cuando su valor es utilizado en una sentencia sin cambiarlo. Un camino def-use es un camino desde una definición a un uso de
una variable. Un uso-predicado (p-use) es cuando una variable es utilizada en un predicado. Un uso-computacional (c-use) es cuando la variable es utilizada como parte de un cálculo. All def, all uses, all p-uses, all c-uses/some p-uses, all p-uses/some c-uses, all def-use
Prueba de bucles.
Bucles simples: dado un bucle simple que puede tener un
rango de 0 a n iteraciones, los casos de prueba deberían
desarrollarse para que haya: 0 it, 1 it, 2 it, m it, donde las it sean m>n, n-1 it, n it, y n+1 it si es posible.
Bucles anidados: se
utilizan otros enfoques para
reducir la complejidad por
ejemplo, pruebas simples en
bucles internos
manteniendo parámetros
de iteración para bucles
externos.
Bucles concatenados:
pueden ser simples o
mantener dependencia:
bucles anidados.
Bucles no
estructurados: rediseño.
Caja Negra
El tester considera el SUT como una caja negra. No tiene conocimiento de su estructura interna, sólo conoce lo que hace el SUT.El tester proporciona entradas al SUT, ejecuta la prueba y entonces determina si las salidas son equivalentes a las proporcionadas en la
especificación.
