Zusammenfassung der Ressource
MARIANO SEIXO GRUEIRO - Tema 4
–Técnicas de diseño de pruebas
Anmerkungen:
- El análisis y diseño de pruebas es la segunda fase del proceso de las pruebas de software
- Proceso de desarrollo de
pruebas (SE CREAN DOCUMENTOS)
- 1) Identificar las CONDICIONES de test
1) Decidir una CONDICIÓN de prueba
- Condición de prueba: podemos comprobar con una prueba o un
conjunto de pruebas. PONER UNA CONDICIÓN DE RETIRAR O NO
25.000 EUROS O EL MIRAR SI LA PUERTA ESTÁ ABIERTA O NO ANTES DE
SALIR DA CLASE
Anmerkungen:
- ítem o evento de un componente o sistema que podría ser verificado por uno o más casos de prueba( por ejemplo, una función, transacción, característica, atributo de calidad o elemento estructural).
- Test DESIGN specification
- 2) Especificar los CASOS de test
2) Diseñar un CASO de prueba
- Caso de prueba: punto de partida para
test, aplica valores y deja en un punto
final. PE 25000 EUROS CARGO, UN CASO
CONCRETO, ES UNA ACCIÓN. O SI ME DICEN QUE SALGA DE CLASE
Anmerkungen:
- conjunto de valores de entrada, precondiciones de ejecución, resultados esperados y post condiciones deejecución desarrollados para un objetivo particular o una condición de test, como ejercitar un aparte de un programa o verificar el cumplimiento de un requisito específico.
- Test CASE specification
- 3) Especificar los PROCESOS de test
3) Escribir un PROCEDIMIENTO (o
script) para ejecutar la prueba
- Test PROCEDURE specification
- PROCESO DE PRUEBA: seria el realizar todas las acciones de los casos con las condiciones
- IEEE 829 propone cómo deben ser estos documentos
- ESTÁNDAR IEEE 829: PLANTILLA DE ESPECIFICACIÓN DE CASOS DE PRUEBA
- IDENTIFICADOR de caso de test
- ITEMS de pruebas.
- ESPECIFICACIONES ENTRADA (entradas, usuarios, archivos, etc.).
- ESPECIFICACIONES SALIDA (resultados esperados -incluyendo
pantallas por ejemplo-, archivos, tiempo, etc.).
- NECESIDADES DEL ENTORNO (hardware, software, personas, etc.).
- REQUISITOS ESPECIALES del procedimiento (permisos, operadores, etc.).
- DEPENDENCIA entre casos (si es necesario, para establecer condiciones previas).
- Categorías de técnicas de diseño de casos de prueba
- Técnicas basadas en ESPECIFICACIONES, de
CAJA NEGRA o COMPORTAMIENTO
- CARACTERISTICAS CAJA NEGRA
- No utilizan ninguna información
sobre la estructura interna del
componente o sistema a probar
- derivan los CASOS DE PRUEBA directamente de las
especificaciones o de otro modelo disponible del
sistema. La fuente de información empleada
esla “base de las pruebas o tests”.
- DOCUMENTACIÓN es muy informal o inexistente,
lo que provoca que deba crearse algún tipo de
modelo que ayude a diseñar las pruebas
- Especificaciones= lo que el sistema
debe hacer (funcional y no funcional)
Diseño= cómo debe hacerlo
- procedimiento para derivar y/o seleccionar casos de
prueba basados en un análisis de la especificación.
- Técnica 1: PARTICIONES EQUIVALENTES
- las ENTRADAS o INPUTS para un programa se pueden agrupar en grupos de INPUTS similares.
- Cada uno de estos grupos es una “partición de equivalencia”
Anmerkungen:
- Cada uno de estos grupos es una “partición de equivalencia ”porque todos los valores que forman el grupo son equivalentes entre sí por lo que respecta al programa
- VÁLIDAS
Anmerkungen:
- grupos de valores válidos para el programa
- NO VÁLIDAS
- particiones de los RESULTADOS o OUTPUTS
- particiones basadas en mayor conocimiento del programa
- es suficiente con probar con uno
de los valores como representante de
la partición (en general,
buscando un valor intermedio).
- Técnica 2: ANÁLISIS DE VALORES LÍMITE
- Los errores tienden a
concentrarse en los límites de las
particiones (debido a los bucles)
- encaja bien con técnica de las particiones, ya
que estas tienen límites, en los que
podemos encontrar valores límite
(válidos y no válidos)
- 2 enfoques
- 2 valores límites: límite de la
partición y el siguiente valor
dentro de la partición
- 3 valores límites: límitedelapartición y los
dos siguientes valores (dentro y fuera de
la partición). Especialmente con este
enfoque, valores límite de un apartición se
pueden repetir en otra.
- Técnica 3: Prueba de TABLAS DE DECISIÓN
- Las especificaciones suelen contener “reglas de
negocio” para definirlas funciones del sistema y las
condiciones bajo las que cada función opera
- probar que cada combinación de las
condiciones que se, así que debemos
contemplar todas las posibles decisiones
- tabla de decisión: lista todas las
condiciones de entrada (solo faltan los outputs)
- imitando las posibles combinaciones a aquellas que corresponden
a reglas de negocio, por lo que estrictamente deberíamos hablar de
“tablas de decisión de entradas limitadas”
- se eliminan las columnas repetidas o que no aporten nada
- Técnica 4: Test deTRANSICIÓN DE ESTADOS
- sistemas cuyo comportamiento
depende de un “estado” presente y
pasado, en los que hay transiciones
entre estados
- diagramas de transición de estados
- Círculos (estados): el
sistema, cuando está
en un estado,
permanece en él a
menos que algún
evento suceda y
provoque un cambio
de estado
- Flechas (transiciones): los
eventos o acciones que provocan
cambios de estados ( y a veces
OUTPUTS)
- Círculo doble o una
flecha sin origen suelen
marcar el estado inicial
- Técnica 5: Prueba de CASOS DE USO
- especificar la funcionalidad basada en
definir usos típicos de un software
- útiles en las PRUEBAS DE ACEPTACIÓN, ya que
se corresponden con USOS TÍPICOS del software,
- útiles en PRUEBAS DE SISTEMA al probar la
comunicación entre varios módulos
- CAMINO o PATH (RUTA o camino) principal a seguir
y uno o varios caminos ALTERNATIVOS más
relacionados con condiciones extrañas o errores.
- Técnicas basadas en la ESTRUCTURA,
ESTRUCTURALES o de CAJA BLANCA
- Técnicas basadas en la ESTRUCTURA o de CAJA BLANCA
- test de SENTENCIAS ó prueba de SENTENCIAS para
COMPROBAR cobertura de SENTENCIAS
- probar sentencias concretas
- % sentencias es la cobertura del test
- 100% COBERTURA DE SENTENCIAS no
implica se hayan realizado todas las
pruebas necesarias
- en ejemplo a>b se prueba que se cumpla
- test de DECISIONES ó pruebas de DECISIONES para COMPROBAR
cobertura de DECISIÓN ó
cobertura de CONDICIÓN
- probar condición cierta y también falsa
- El % de resultados de decisiones probadas
es la COBERTURA de la prueba (COBERTURA DE DECISIÓN O
- prueba la SENTENCIA
y lo contrario también
- en ejemplo a>b que se
cumpla y lo contrario
también (TODO LO QUE NO
SEA A>B, como A<B O A=B)
- otras técnicas
- en todos los casos puede
definirse cobertura (p.e.,de
interfaces entre componentes o de
opciones del menú probadas).
- otras técnicas disponibles que
examinan más y en escenarios
más complejos.
- sirven para pruebas en varios NIVELES
- COMPONENTES (lo más habitual): para probar
estructuras del código (decisiones , bucles ,
quetodo el código se ejecuta, etc.).
- STATEMENT COBERTURE
- DECISION / BRANCH / COVERAGE
- Basadas en la derivación de casos de
prueba directamente de la estructura
de un componente o sistema