MARIANO SEIXO GRUEIRO - Tema 4
–Técnicas de diseño de pruebas
Annotations:
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
Annotations:
í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
Annotations:
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
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”
Annotations:
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
Annotations:
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