T05 Pruebas Del Software Técnicas y Estrategias

Tema 5.
Pruebas del software: Técnicas y

Estrategias.
1. Objetivos y límites de las pruebas.

2. Tipos de pruebas.
3. Análisis y seguimiento de errores.
4. Documentación y diseño de las
pruebas.
5. Planificación de las pruebas. Hitos y
tareas.
6. Depuración.
Tema 5. Pruebas del SW: Técnicas y Estrategias
1. Objetivos y límites de las pruebas
Probar un programa completamente No existen

errores sin descubrir
¿Se puede realizar una prueba completa?
Programadores junior: todas las posibles entradas o
todas sus secuencias de ejecución.
Gestores creen en su existencia
Compañías de prueba de software: lo prometen
Herramientas de análisis: venden la promesa
Vendedores: creen que sus productos están libres de
fallos.
Algunos testeadores creen en las pruebas
completas(planificación, tiempo, personal)
inseguridad, culpabilidad
2
1
Razones para la imposibilidad de prueba completa
No se puede probar las respuesta del programa para
cada posible entrada.
Qué significaría probar cada entrada:
− Se deben probar todas las entradas válidas.
− Se deben probar todas las entradas inválidas.
− Se deben comprobar todas las entradas editadas.
− Se deben probar todas las variaciones temporales de las
entradas.
¿Qué ocurre si no puedo probar todas las entradas de un
programa? Abandona la prueba completa
3

No se pueden probar todas las secuencias de
ejecución.
Una secuencia puede ser trazada a través del código.
Dos secuencias diferentes: no ejecutan las mismas sentencias
o lo hacen en orden diferente.
Myers, en 1979 describió un programa con un bucle y unas
cuantas condiciones (IF), que ocupaba unas 20 líneas en la
mayoría de lenguajes. Tenía 100 trillones de secuencias, un
testeador podría probarlo en un billón de años.
Necesario disponibilidad del código.
Suponiendo que se puede hacer una prueba
completa. ¿Resuelve esto nuestro problema?
2
No se pueden encontrar todos los errores de diseño.
Las especificaciones de diseño a menudo contienen
errores(2+2=5)
− ¿Error que el programa siga una especificación erronea o
que se desvíe?
− Mala especificación Erróneo.
No se puede probar completamente un programa si
no se pueden encontrar todos sus errores de diseño.
No se puede comprobar la corrección usando la
lógica.
Ignorando el número de incógnitas y el tiempo podríamos
validar la consistencia, decidir si está de acuerdo con la
especificación, pero ¿es correcta la especificación?.
5

Objetivo del testeador: ¿Verificar el programa?
Descripción sin sentido
Equivocado
Estimaciones comunes dicen que el coste de encontrar
y corregir errores en programas fluctúa entre el 40% y
80% del coste total. No se gasta este dinero para
verificar, sino porque el programa no funciona.
Errores privados y públicos (Beizer, 1984)
− Errores privados: los que comete el
porgramador (1.5/sentencia).
− Errores públicos. Los que quedan cuando el
porgramador declara su código libre de fallos.
(1/100 sentencias).
3
Objetivo del testeador: ¿Verificar el programa?
Prepara a los testers para el fallo
Los testeadores no deben querer verificar que un programa se
ejecute correctamente.
− Si se quiere y espera que un programa funcione bien, se
perderán errores.
− Si se espera que falle, se tenderá a detectar más errores.
− Si se penaliza por encontrar errores, se perderán errores.
Fomenta una actitud inefectiva

Entonces, Porqué probar
No podemos encontrar todos los errores.
No podemos probar que el programa es correcto, y no
queremos hacerlo.
Es caro, frustraste y no da ninguna popularidad.
El propósito de probar un programa es encontrar problemas en

7 él.
Una prueba que resuelve un problema es un éxito. Una

prueba que no revela ningún problema es una perdida
de tiempo.
El propósito de encontrar problemas es corregirlos.
Aumento de la calidad.
Se toma una actitud destructiva contra el programa,

pero a largo plazo ese trabajo es constructivo.
herrare humanum est

8
4
2. Tipos de pruebas
Consideraciones comunes a toda prueba
Ciclo completo de las pruebas
Diseño
Diseñode
deCasos
Casosde
de
Test
Test
Casos
Casosde
deTest
Test
Preparar
PrepararDatos
Datosde
de
Test
Test
Datos
Datosde
deTest
Test
Ejecutar
Ejecutarprogr.
progr.con
con
datos
datosde
detest
test
Rdos.
Rdos.Test
Test
Comparar
Compararrdos.
rdos.con
con
Casos
Casosde
deTest
Test
Informes
InformesTest
Test
9
2. Tipos de pruebas
Consideraciones comunes a toda prueba
Caso de prueba: conjunto específico de datos de
entrada y de procedimientos asociados, desarrollados
para probar un caso determinado (secuencia/camino
particular, verificación de un requisito, etc).
deben ser documentados y archivados.
definir el resultado esperado.
comprobar si no hace lo que debe o hace lo que no
debe.
tanto entradas inválidas e inesperadas como esperadas
inspeccionar concienzudamente resultado de cada
prueba
El programador evitará probar sus programas.
Probabilidad de la existencia de nuevos errores en una
sección de un programa es proporcional al número de
errores ya descubiertos.
10
5
2. Tipos de pruebas
Diseño de casos de prueba

Cualquier producto de ingeniería puede comprobarse
de dos formas:
− Conociendo la función específica para la que fue
diseñado (prueba de las funciones) Pruebas de caja
negra
− Conociendo el funcionamiento del producto (prueba de
la operación interna) Pruebas de caja blanca
En el software, pruebas de caja negra son las que
se llevan a cabo sobre la interfaz del software.
Examina aspectos del modelo fundamental del
sistema (funcionalidad operativa, aceptación de
entradas, resultados, etc)
11
2. Tipos de pruebas
Las pruebas de caja blanca se basan en el estudio

minucioso de los detalles procedimentales.
A primera vista,
− Una prueba de caja blanca nos llevaría a un programa
100% correcto.
− Pero nos encontramos con el problema de las pruebas
completas (o exhaustivas). No podemos generar casos
de prueba para todos los caminos lógicos (secuencias
de ejecución).
− Solución: uso sólo para generar los casos de prueba
más significativos (caminos o estructuras de datos más
importantes).
12
6
2. Tipos de pruebas
Pruebas de caja blanca
Se usan la estructura de control del diseño
procedimental para diseñar los casos de prueba.
¿Por qué utilizar pruebas de caja blanca?:
Los errores lógicos y las suposiciones incorrectas son
inversamente proporcionales a la probabilidad de que se
ejecute un camino del programa.
A menudo creemos que un camino lógico tiene pocas
posibilidades de ejecutarse cuando, de hecho, se puede
ejecutar de forma regular.
Los errores tipográficos son aleatorios.
Testeo estructural, selección adecuada de caminos:
Camino: secuencia de sentencias encadenadas desde la
sentencia inicial del programa hasta su sentencia final
13
2. Tipos de pruebas
Pruebas de caja blanca
No se pueden testear todos los caminos. Criterios de
selección:
Cobertura de sentencias
− Escribir los casos suficientes para que cada sentencia en el
programa se ejecute al menos una vez.
Cobertura de decisión o de ramificación.
− Escribir casos suficientes para que cada decisión, por lo
menos una vez, tenga un resultado verdadero y uno falso.
Cobertura de condición
− Escribir el suficiente número de casos para que cada
condición de toda decisión tenga todos los resultados
posibles.
14
7
2. Tipos de pruebas
Pruebas de caja blanca: Camino Básico
Debemos asegurar que cada uno de los posibles caminos
de un programa sean ejecutados al menos una vez.
Para llegar a obtener esta cobertura se deben realizar las
siguientes acciones:
1. Obtener el grafo de flujo de control asociado al
software.
2. Calcular el número de caminos mediante
ecuaciones algebraicas.
3. Identificación de los caminos para su enumeración.
Elementos utilizados para la construcción de grafo de flujo
son: A
Nodos (sentencias)
Región
Aristas (flujos de control)
A Nodos predicado (condición)
15
2. Tipos de pruebas
Para obtener un grafo de flujo a partir de un lenguaje
de diseño o pseudocódigo, se deben realizar los
siguientes pasos:
Señalar cada una de las condiciones de cada
decisión, tanto en sentencias IF y CASE como en
bucles WHILE o UNTIL.
Agrupar sentencias entre cada dos condiciones,
teniendo en cuenta que las sentencias de finalización
ENDIF, ENDDO, END, etc. constituirán un nuevo
nodo.
Numerar tanto las condiciones como los grupos de
sentencias. Nodos predicados: identificar la condición
con una letra y cada una de las aristas de salida con
el resultado de la condición.
Decisiones que impliquen a varias condiciones:
descomponerlas
16
8
2. Tipos de pruebas
Cálculo del número de caminos mediante ecuaciones algebraicas.
En el caso de grafos simples (sin bucles) se siguen las
siguientes reglas:
Si definimos Nx como el número de caminos que atraviesan x.
A
A A B
B C C
B
Definirían:
Na = Nb + Nc
Na = Nb = Nc
Na = 2 x Nb
17
2. Tipos de pruebas
El cálculo de caminos de un grafo con bucles puede ser ilimitado.
Se define un nuevo concepto:
Camino de prueba: camino de programa que atraviesa,
como máximo una vez el cuerpo de cada bucle encontrado.
Atendiendo a esta definición se puede calcular el número de
caminos de prueba de dos formas:
Rectificación de bucles:
− Pretende eliminar del grafo la arista que forma el bucle,
sustituyéndola por una nueva arista que represente el
encadenamiento de aristas que se producirían al iterar
una vez el bucle.
Ecuaciones algebraicas:
− Se definen nuevas ecuaciones que se asocian a los dos
tipos de bucles posibles (while y until)
Nw = 1 + Na
Un = Na x (1 + Na)
18
9
2. Tipos de pruebas
La complejidad ciclomática es una métrica del
software que proporciona una medición cuantitativa
de la complejidad lógica de un programa.
Conjunto básico de un programa: número de
caminos independientes
− Camino independiente: cualquier camino del programa
que introduce un conjunto de sentencias de proceso o
una nueva condicion
− Asegurar que se ejecuta cada sentencia al menos una
vez y que cada condición se habrá ejecutado en su
vertiente verdadera y falsa
19
2. Tipos de pruebas
La complejidad se puede calcular de tres formas:
El número de regiones del grafo de flujo coincide con
la complejidad ciclomática.
La complejidad ciclomática, V(G), de un grafo de flujo
G se define como
V(G) = A – N + 2
donde A es el número de aristas del grafo de flujo y N
es el número de nodos.
La complejidad ciclomática, V(G), de un grafo de flujo
G también se define como
V(G) = P + 1
donde P es el número de nodos predicado contenidos
en el grafo de flujo G.
20
10
2. Tipos de pruebas
Obtención de casos de prueba:
1. Usando el diseño o el código como base, dibujamos el
correspondiente grafo de flujo.
2. Determinamos la complejidad ciclomática del grafo de
flujo resultante.
3. Determinamos un conjunto básico de caminos
linealmente independientes.
V(G):número de caminos linealmente independientes
de la estructura de control del programa.
4. Preparamos los casos de prueba que forzarán la
ejecución de cada camino del conjunto básico.
Escogemos los datos de forma que las condiciones de
los nodos predicado estén adecuadamente
establecidas con el fin de comprobar cada camino.
21
2. Tipos de pruebas
Pruebas de caja blanca: Prueba Estructura Control
Pruebas de condición
Método de diseño de casos de prueba que ejercita las
condiciones lógicas contenidas en el módulo de un programa.
Prueba de flujo de datos
Selecciona caminos de prueba de un programa de acuerdo
con la ubicación de las definiciones y los usos de las variables
del programa.
Prueba de bucles
Se centra únicamente en la validez de las construcciones de
bucles:
Bucles simples: se les aplican pruebas como pasar por alto el
bucle, pasar una sola vez, pasar n-1, n y n+1 veces.
22
11
2. Tipos de pruebas
Pruebas de caja blanca: Prueba Estructura Control
Prueba de bucles
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.
23
2. Tipos de pruebas
Pruebas de caja negra
Se centran en los requisitos funcionales (y no
funcionales) del software.
Tratan de encontrar errores en las siguientes
categorías:
1. Funciones incorrectas o ausentes.
2. Errores de interfaz.
3. Errores en estructuras de datos o en accesos a bases
de datos externas.
4. Errores de rendimiento.
5. Errores de inicialización y de terminación.
Tienden a aplicarse durante fases posteriores de las
pruebas.
24
12
2. Tipos de pruebas
Pruebas de caja negra
Criterios:
Reducen en un coeficiente >1 el nº de casos de prueba
Casos de prueba informan de presencia o ausencia de
clases de errores asociados con la prueba
Inputs causing
anomalous
Input test data I behaviour
e
System
Outputs which reveal

the presence of
Output test results Oe defects
25
2. Tipos de pruebas
Pruebas caja negra: Clases de equivalencia
Cada caso debe cubrir el máximo número de entradas
Dominio de valores de entrada dividido en un número
finito de clases de equivalencia que cumplan la siguiente
propiedad:
La prueba de un valor representativo
de una clase permite suponer
«razonablemente» que el resultado Invalid inputs Valid inputs
obtenido (existan defectos o no)
será el mismo que el obtenido
probando cualquier otro valor de la System
clase
Lo que hay que hacer es:
1. Identificar clases de equivalencia
2. Crear casos de prueba
Outputs
correspondiente
26
13
2. Tipos de pruebas
Condiciones de las entradas del programa: restricciones
de formato o contenido de los datos de entrada
Condiciones ⇒ identificar clases de equivalencia(Reglas de
identificación):
a) De datos válidos
b) De datos no válidos o erróneos
Usar las clases de equivalencia para identificar casos de
prueba:
1. Asignación de un número único a cada clase de
equivalencia
2. Hasta que todas las clases de equivalencia válidas
hayan sido cubiertas por (incorporadas a) casos de
prueba, escribir un caso que cubra tantas clases válidas
no incorporadas como sea posible
3. Hasta que todas las clases de equivalencia no válidas
hayan sido cubiertas por casos de prueba, escribir un
27 caso para una única clase no válida sin cubrir
2. Tipos de pruebas
Reglas de identificación de clase:
a) Si se especifica un rango de valores para los datos de
entrada, se creará una clase válida y dos clases no válidas
b) Si se especifica un número finito y consecutivo de valores,
se creará una clase válida y dos no válidas
c) Si se especifica una situación del tipo «debe ser» o
booleana (por ejemplo, «el primer carácter debe ser una
letra»), se identifican una clase válida («es una letra») y una
no válida («no es una letra»)
d) Si se especifica un conjunto de valores admitidos y se
sabe que el programa trata de forma diferente cada uno de
ellos, se identifica una clase válida por cada valor y una no
válida
e) Si se sospecha que ciertos elementos de una clase no se
tratan igual que el resto de la misma, deben dividirse en
Clases Menores
28
14
2. Tipos de pruebas
Ejemplo: Aplicación bancaria en la que el operador
debe proporcionar un código, un nombre y una
operación
Habría que diseñar casos de prueba que cubran todas

las clases de equivalencia, tanto válidas como inválidas,
y para las inválidas en casos de prueba distintos
29
2. Tipos de pruebas. Pruebas caja negra:

Análisis de Valores Límite
Más que elegir «cualquier» elemento como
representativo de una clase de equivalencia, se
requiere la selección de uno o más elementos tal que
los márgenes se sometan a prueba
Más que concentrarse únicamente en el dominio de
entrada (condiciones de entrada), los casos de prueba
se generan considerando también el espacio de salida
La experiencia indica que los casos de prueba que
exploran las condiciones límite de un programa
producen un mejor resultado para detectar defectos
30
15
Análisis de Valores Límite
AVL complemento de Particiones de Equivalencia. Diferencias:
1. Si una condición de entrada especifica un rango de valores,
se deben generar casos para los extremos del rango y casos
no válidos para situaciones justo más allá de los extremos
2. Si la condición de entrada especifica un número finito y
consecutivo de valores, hay que escribir casos para los
números máximo, mínimo, uno más del máximo y uno
menos del mínimo de valores
3. Usar la regla 1 y 2 para cada condición de salida
− Los valores límite de entrada no generan necesariamente
los valores límite de salida (recuérdese la función seno, por
ejemplo)
− No siempre se pueden generar resultados fuera del rango
de salida(pero es interesante considerarlo)
4. Si la entrada o la salida de un programa es un conjunto
ordenado, los casos se deben concentrar en el primero y en el
último elemento
31

Conjetura de errores
El valor cero es una situación propensa a error tanto en
la salida como en la entrada
En situaciones en las que se introduce un número
variable de valores, conviene centrarse en el caso de
no introducir ningún valor y en el de un solo valor.
También puede ser interesante un lista que tiene todos
los valores iguales
Es recomendable imaginar que el programador pudiera
haber interpretado algo mal en la especificación
También interesa imaginar lo que el usuario puede
introducir como entrada a un programa
Se enumera una lista de posibles equivocaciones
típicas que pueden cometer los desarrolladores y de
situaciones propensas a ciertos errores
...
32
16
2. Tipos de pruebas.
Otros tipos
Testeo orientado a objetos:
Mayor gránulo que las pruebas de caja blanca
Diferentes niveles:
− Operaciones
− Clases de objetos
− Clusters de objetos
– Escenarios o Casos de prueba
Generating Test Cases From Use Cases
(http://www.therationaledge.com/content/jun_01/m
_cases_jh.html)
– Testeo de hilos
– Interacción de Objetos
− Sistema completo
33
2. Tipos de pruebas
Secuencia de eventos
Código de Código de Código de
componente componente componente
Prueba
Prueba de
de Prueba
Prueba de
de Prueba
Prueba de
de
unidad
unidad unidad
unidad ... unidad
unidad
Componente probado
Especificaciones de Prueba
Prueba de
de
diseño integración
integración
Módulos integrados
Requisitos funcionales Prueba
Prueba
del sistema Funcional
Funcional Sistema en
funcionamiento
Otros requisitos del Prueba
Prueba de
de
software Sistema
Sistema Software verificado
y validado
Especificación de Prueba
Prueba de
de
requisitos del cliente aceptación
aceptación
Sistema aceptado
Entorno del usuario
Prueba
Prueba de
de
34 instalación
instalación Sistema en uso!!
17
2. Tipos de pruebas. Estrategias
Pruebas de Unidad
Prueba de la componente software o módulo:
Driver + Stub: sobrecarga de trabajo
− Posponer hasta pruebas de integración
Requisito: Módulo con alto grado de cohesión
Driver
Driver Interfaz
Estructuras de datos locales
Módulo
Módulo Condiciones límites
aaprobar
probar Caminos independientes
Caminos de manejo de errores
Stub
Stub Stub
Stub
Casos
Casos de
de
Casos
Casos de
de
Casos
Prueba
Casos
Prueba de
de
Casos
Prueba
Casos
Prueba de
de
Casos
Prueba
Casos
Prueba de
de
RESULTADOS Prueba
Prueba
Prueba
Prueba
35

Pruebas de Integración
Construir la estructura del programa mientras se hacen
para detectar errores asociados con la interacción.
Dos aproximaciones:
Estrategia incremental:
1. Cada pieza se prueba separadamente (pruebas de
módulo, de unidad o de elemento)
2. Se combinan todos los módulos: pruebas de
integración.
Hacen más fácil la localización de los errores.
Necesario código “driver” ni “stub”
Estrategia de prueba por explosión(big bang)
− los módulos y procesos no se prueban hasta que se
integra el sistema.
No es necesario código “driver” ni “stub”
Difícil aislar la causa del error
36
18
Pruebas top-down versus bottom-up:
Son estrategias incrementales.
El producto debe haber sido diseñado jerárquicamente.
Bottom-up prueban primero los módulos de nivel inferior.
Driver: testear rutinas de menor nivel testear rutinas de
mayor nivel
Test
drivers
Testing
Level N Level N Level N Level N Level N
sequence
Test
drivers
Level N–1 Level N–1 Level N–1
37

Pruebas top-down versus bottom-up:
Top-Down primero los módulos de mayor nivel (no se necesita
código “driver”, sí “stub”):
− Validación arquitectural y demostración del sistema
Testing
Level 1 Level 1 ...
sequence
Level 2 Level 2 Level 2 Level 2
Level 2
stubs
Level 3
stubs
38
19
Pruebas Funcionales y de Sistema
Verificación y Validación
Se verifica un programa comprobándolo contra los
documentos de diseño o especificaciones más próximas.
Si existe una especificación externa se realizan pruebas
funcionales.
Se valida el programa comprobándolo contra los requisitos
de usuario o de sistema. Las pruebas de sistema y de
integración son pruebas de validación.
Validación y Verificación Independiente: hechas por una
empresa independiente
Para una descripción completa de la verificación y
validación: IEEE Standard for Software Verification and
Validation Plans (ANSI/IEEE Standard 1012-1986).
39

Asegurar que el software cumple las necesidades de
los usuarios
Static
verification
Requirements High-level Formal Detailed

Program
specification design specification design
Dynamic
Prototype
validation
40
20
Algunas pruebas ejecutadas durante las pruebas de
funcionalidad y de sistema:
Verificación de la especificación. Pruebas de carga:
Corrección. volumen, stress y
Usabilidad almacenamiento
Condiciones de borde Recuperación ante
errores
Rendimiento
Compatibilidad y
Transiciones entre estados
conversión
Pruebas de uso convencional
Configuración
Tareas de Fondo (background)
Instalabilidad y
Seguridad practicabilidad
Quickies
......
41
2. Tipos de pruebas
Estrategias
Prueba final de aceptación y certificación:
Ejecución de una prueba de aceptación por parte del cliente
cuando entreguemos el producto.
La certificación se realiza por una tercera persona. Se trata
de una prueba breve.
Pruebas release:
En las pruebas de publicación se recogen todos los
elementos que irán al consumidor o al manufacturador, se
comprueba que son todas correctas, se copian y se archiva
la copia. Después se publican
42
21
Pruebas de regresión
Aplicable a pruebas tanto de caja negra como
blanca.
Se usa con dos ideas diferentes (en común tienen la
de reusar pruebas antiguas):
Al encontrar un error y corregirlo, repetir la prueba
que reflejó el problema en primer lugar. Se pueden
crear grupos de pruebas de regresión. Se refleja la
vulnerabilidad de las correcciones.
Cuando se encuentra y corrige un error, se ejecuta
una serie estándar de pruebas para asegurarnos de
que el cambio no perturba nada más.
43
2. Tipos de pruebas
Pruebas dinámicas frente a estáticas:

En una prueba dinámica se ejecuta el código
− Detecta la presencia de errores
En una prueba estática se examina el código. Se prueba sin
ser ejecutado.
Existen muchas herramientas para el análisis estático
(compiladores, lincadores, etc.). También puede realizase por
humanos (revisiones).
44
22
¿Qué es un error reproducible?:

Se puede describir como llevar el programa a un
estado conocido.
Desde ese estado, se pueden especificar una serie
de pasos exactos que muestran el problema.
Para hacer más efectiva la detección de un error
(informe), ésta debe analizarse.
Si el problema es complicado porque requiere un alto
número de pasos o sus consecuencias son difíciles de
describir gastar tiempo con el
Se deben simplificar los informes o dividirlos en una
serie.
45

Objetivos
Encontrar las consecuencias del problema:
Observar las consecuencias más graves de un error.
Cuando un programa falla:
− Lo hace en un estado inesperado
− Lo hace dentro de una rutina de recuperación de errores
Cuando el programa registra un problema, o muestra
basura en pantalla, o cualquier cosa inesperada error
complementario
Encontrar las condiciones más simples y generales
Encontrar caminos alternativos al mismo problema
Encontrar problemas relacionados

46
23
Tácticas para analizar un error reproducible
1. Buscar el paso crítico: No se mira una causa, se miran
sus síntomas.
Buscar:
− Mensajes de error.
− Retardos en el procesamiento.
− Parpadeos en la pantalla.
− Saltos del cursor.
− Múltiples cursores.
− Texto no alineado.
− Caracteres dobles u omitidos.
− Luz de uso cuando el dispositivo no está en uso.
2. Maximizar la visibilidad del comportamiento del
programa.
Herramientas (Depuradores).
Registro de todos los accesos a fichero, pantalla, etc.
Utilizar un terminal lento
47

Tácticas para analizar un error reproducible
3. Una vez encontrado el paso crítico, variar el
comportamiento.
Si sabemos que la secuencia A entonces B entonces
C provoca un error en C, y sabemos que el paso
crítico está en B. Intentar A entonces B entonces D.
Objetivo: encontrar un caso serio
4. Buscar siguientes errores.
Los siguientes errores pueden estar derivados del 1º
Pueden no ser consecuencia directa de éste
5. Variar o anular progresivamente los pasos.
6. Comprobar error en versiones anteriores del programa
7. Buscar la dependencia de configuración.

48
24
Hacer reproducible un error
Error reproducible:
Se debe ser capaz de explicar como llegar a un estado y
como disparar el error.
Se debe escribir todo lo que se recuerde de lo que se
hizo la primera vez e intentar reproducir el error.
Si una vez obtenido el error no se puede reproducir
deberemos tener en cuenta algunas hipótesis:
Condiciones de velocidad.
− Generalmente ejecutamos la prueba por segunda vez
mucho más lento. El error pudo producirse porque el
programa no puede trabajar tan rápido. Volver a realizar la
prueba de forma rápida.
Espoleta retardada.
− Errores que no tiene un impacto inmediato.
49

Detalles olvidados.
− La mejor solución es aplicar un plan paso-a-paso.
Errores de usuario: no hiciste lo que pensaste que
hiciste.
Un efecto del error hace imposible la reproducción.
− Los datos pueden haber sido modificados por la aplicación,
utilizar siempre una copia de los datos.
El error depende del estado de la memoria.
− Ver la cantidad de memoria, la fragmentación, etc. Puede
ayudar a encontrar la condición.
Es un error de estado inicial.
El error se ha basado en datos corruptos.
50
25
El error es un efecto lateral de algún otro problema.
Error hardware intermitente.
Dependencia temporal.
− El error puede depender de la fecha u hora en la que se
realiza la prueba.
Dependencia de los recursos.
Casos especiales en el código.
− La ayuda del programador puede ahorrar mucho tiempo.
Alguien ha jugueteado con tu máquina.
51

Sistema de seguimiento de problemas
El sistema y los procedimientos de seguimiento de
problemas tienen como objetivo hacer que los errores
que deben corregirse, se corrijan.
Un sistema de seguimiento de problemas se
fundamenta en razones políticas:
Posibilita la extracción de métricas y la divulgación de
información.
Conforme se va usando nos muestra asuntos personales
o de control.
El sistema puede monitorizar el rendimiento personal.
...
52
26
Sistema de Seguimiento de Problemas
Las tareas fundamentales del sistema es asegurar que:
Cualquier persona que necesite conocer un problema
debe aprenderlo pronto después de haber sido
notificado.
Ningún error quedará sin corregir porque alguien se
olvidó de el.
Ningún error quedará sin corregir por capricho de un
programador.
Un mínimo número de errores quedarán sin corregir
simplemente por comunicación pobre.
53

Sist. de Seg. Problemas: Estructura
Evaluación
Reproducir Informe
Informedel
delproblema
problema
Reproducir
ooMejorar
Mejorar
Dtor. Proyecto
Marcar“Diseñado”
Marcar “Diseñado” Priorizar
Programadores
Marcar“Aplazado”
Marcar “Aplazado” Investigación
Marcar
Marcar“Irreproducible”
“Irreproducible” Informe
Informecorregido
corregido
Estado:
Estado:Abierto
Abierto ++comentario
comentario
Re -Evaluación
Test
Testsiguientes
siguientes Problema
Problema
Versiones
Versiones Pendiente
Pendiente
54
27
Sist. de Seg. Problemas: Estructura
Problemas que no se han tratado.
Algunos informes se pierden, otros se separan
deliberadamente, otros con baja prioridad son olvidados.
Regla importante: todos deben ser resueltos antes de
que el producto se publique.
Debe ponerse en circulación un informe resumen, cada
una o dos semanas, que liste los errores pendientes para
evitar que se olviden.
Informe de estado del proyecto.
Informe manejable que indica cuantos errores: se han
encontrado, están pendientes, han sido aplazados
comparado con corregidos, etc.
Muestra el progreso de cada semana y los totales,
ayudando a los directores a evaluar la calidad del
esfuerzo de programación, la fiabilidad, la efectividad de
las pruebas, etc.
55
4. Documentación y diseño de las pruebas
El estándar ANSI/IEEE 829-1983 para la

documentación de las pruebas de software define un
plan de pruebas como:
“Un documento que describe el alcance, la aproximación,
los recursos y la planificación y las actividades
necesarias. Identifica elementos de prueba, las
características que deben probarse, las tareas de
prueba, lo que hará cada tarea y cualquier planificación
necesaria para la contención de riesgos”
Generalmente el plan de pruebas será un amplio
documento, construido a partir de documentos menores
agrupados.
56
28
El objetivo general del plan de pruebas: ¿producto o

herramienta?
Se escriben planes de prueba para dos propósitos muy
diferentes y confundirlos sale muy caro.
Como producto: el plan se desarrolla como producto en
si mismo. Su estructura, formato y nivel de detalle están
determinados no únicamente por la efectividad de las
pruebas sino por el cliente.
Como herramienta: un plan de prueba es una
herramienta valiosa hasta el extremo de ayudarnos a
manejar el proyecto de prueba y encontrar errores. Más
allá de eso es una malversación de recursos.
57

Objetivos del plan de pruebas
Facilitar las tareas técnicas de las pruebas.
Aumentar la cobertura de las pruebas.
Evitar repeticiones innecesarias y no olvidar otras.
Analizar el programa y descubrir buenos casos de prueba
rápidamente.
Suministrar una estructura para la prueba final.
Aumentar la eficiencia de las pruebas.
Comprobar su completitud.
Mejorar la comunicación sobre las tareas y los procesos de las
pruebas.
Comunica el pensamiento detrás de la estrategia de prueba.
Provoca reentrada sobre la precisión y cobertura.
Comunica el tamaño del trabajo de prueba.
Provoca reentrada sobre la profundidad y temporización.
Divide el trabajo.
58
29
Objetivos del plan de pruebas
Suministrar estructura para la organización,
planificación y gestión del proyecto de prueba.
Alcanza un acuerdo sobre las tareas de prueba
Identifica las tareas.
Estructura.
Organiza.
Coordina.
Aumenta la responsabilidad personal.
Mide el estado del proyecto y mejora la responsabilidad
del proyecto.
59

Tipos de pruebas a cubrir en el plan de pruebas
Pruebas de caja blanca:
Los programadores ya realizan las pruebas de caja blanca.
Las pruebas de caja blanca no nos dan información sobre:
Errores relacionados con el tiempo.
Condiciones de error no detectadas.
Condiciones especiales de los datos.
Invalidez de la información mostrada por pantalla.
Inconsistencias en la interfaz de usuario.
Interacción con tareas en background.
Fallos de configuración/compatibilidad.
Incapacidad de soportar el volumen de carga o fallos hard.
Las pruebas de caja blanca son débiles y deben planificarse en la
etapa de codificación.
60
30
Tipos de pruebas a cubrir en el plan de pruebas
Pruebas de caja negra:
Áreas de prueba más importantes en el plan:
− pruebas de aceptación (curarse en salud)
− flujo de control (flujo de control visible)
− flujo de datos y de integridad
− configuración/compatibilidad
− pruebas de stress
− interfaz de usuario
− regresión
− rendimiento
− defectos potenciales
− pruebas beta
− pruebas release
− utilidad (¿el programa satisfará las expectativas del
cliente?).
61

Estrategias para desarrollar documentos TstPln
Evolutiva.
Semejante al método evolutivo de desarrollo de software.
Se añaden secciones al plan de pruebas, se profundiza
en determinadas áreas (por prioridad) hasta que se
finaliza la prueba del producto.
Generalmente es más efectivo que el de cascada.
Se adapta mejor si el proceso software es también
evolutivo (se diseña conforme se va aprendiendo).
62
31
Estrategias para desarrollar documentos TstPln
Inicial.
Aunque la evolución es buena, debemos comenzar a
diseñar un plan (básico) sin experiencia.
Revisión completa de la documentación. Comenzar
comparando el comportamiento del programa contra la
documentación de usuario y la especificación si existe.
Listar superficialmente las funciones. Incluir lo que se
supone que el programa debe hacer y probarlo.
Analizar las entradas, límites, ignorando la mayoría de
interacciones. Probar los límites razonables donde se
introduzcan datos. Si el programa aguanta probar límites
más amplios.
En resumen, comenzar con los fundamentos, probar el
programa aunque no sea de una forma muy profunda y
añadir profundidad.
63

Añadir profundidad al TSTPLN
Dónde:
Errores más probables (los chinches viven en colonias).
Errores más visibles.
Áreas del programa usadas más frecuentemente.
Áreas distintivas del programa.
Áreas más difíciles de corregir.
Áreas más entendidas por ti.
Mecanismos:
Se añade profundidad creando o extendiendo los
Componentes del Plan Pruebas (listas, árboles de
decisión, lista de funciones, gráficos de borde, matrices
de test, etc).
64
32
Documentación:
¿Quién usara esta documentación?
− Un documento es válido únicamente si el lector puede
entenderlo. Se deben adaptar a la sofisticación necesaria.
Dependiendo del destinatario del documento podemos
distinguir hasta 7 posibilidades:
− Notas personales
− Notas para otro miembro del equipo
− Notas para otro testeador experimentado
− Notas para ser usadas en la próxima release
− Scripts de prueba para testeadores inexpertos
− Notas para el gestor
− Seguimiento y auditoria legal
65

Tipos de documentos de prueba
Describiremos algunos de los documentos del estandar
IEEE Standard 829-1983 for Software Test
Documentation: guía para el plan de pruebas
Plan
Plande
de
Documentación Pruebas
Pruebas
Especificación
Especificaciónyy Especificación
Diseño Especificaciónyy
Diseñode
delas
lasTest
Test Diseño
Diseñode
delas
lasTest
Test
Especificación
Especificación
Especificación
Especificación
CasoEspecificación
Caso de Prueba
Especificación
de Prueba
Especificación
Especificaciónde
de Caso
Caso de
de Prueba
Prueba
Caso
Casode dePrueba
Prueba
Procedimiento
Procedimientode
dePruebas
Pruebas
Ejecución
Ejecución
66 Informes
33
Plan de prueba
Resumen del esfuerzo de prueba del producto:
documento único o en secciones
Secciones definidas por el estandar IEEE:
− Identificador del plan. Nombre o número.
− Introducción. Incluye referencias a documentos estandar,
planes del producto a alto nivel.
− Elementos de prueba. Un elemento de prueba es un
elemento de software (función, módulo, característica, etc)
que debe probarse.
− Características que se debe probar. Referencias
cruzadas a las especificaciones de diseño.
67

Plan de prueba: Secciones
− Características que no se van a probar. Cuales y por
qué.
− Aproximación. Describe la aproximación que se va a
utilizar: quien la hace, actividades principales, técnicas y
herramientas para cada grupo/característica.
¿Cómo se decidirá si un grupo de características se ha
probado satisfactoriamente?.
− Criterios para decidir si pasa/falla un elemento.
Cómo decide un testeador cuando el programa falla o
pasa una prueba dada.
− Criterios de suspensión y reanudación. Lista de
cualquier cosa que pueda causar el paro de las pruebas
hasta que se solucione. ¿Qué se debe hacer para
volver a comenzar?. ¿Qué pruebas se deben hacer en
este punto?.
68
34
Lista de funciones (No IEEE).

Criterio de aceptación en prueba(No IEEE).
Prueba breve que debe pasar el programa cuando se
envía al grupo de pruebas. Si la pasa se produce un ciclo
de prueba completo, de otra forma se rechaza como
demasiado inestable.
Especificación del diseño de las pruebas.
Cómo se probará una característica o grupo de ellas.
Incluye:
− Identificador de la especificación de diseño.
− Característica que se va a probar.
− Aproximaciones de refinamiento.
− Identificación de las pruebas.
− Criterios de aceptación/fallo.
69

Especificación de los casos de prueba.
Identificador de la especificación
Elementos de prueba.
Especificaciones de entrada (consideración temporal)
Especificaciones de salida (tiempos de respuesta)
Necesidades ambientales
Requisitos procedurales especiales
Dependencias entre casos
Especificación de procedimientos de prueba:
Etapas para ejecutar un conjunto de casos de prueba y analizar su
resultado
Identificador de la especificación de procedimiento.
Propósito.
Requisitos especiales.
Pasos del procedimiento
70
35
Informe de transmisión de elementos de prueba: Acompaña
cualquier entrega para prueba. Nos cuenta qué es lo que nos están
dando.Incluye:
Identificador
Elementos transmitidos
Localización
Estado
Aprobación
Scripts de prueba (No IEEE).
Instrucciones generales.
Getting started.
Descripción paso por paso del procedimiento de cada prueba.
Casillas de marcado para cada paso y resultado.
Espacio abundante para describir el comportamiento que fuese
extraño o no entendido
71

Log de prueba: Registro cronológico de las ejecuciones de pruebas y
eventos ocurridos.
Identificador del log.
Descripción. Qué se está probando, incluyendo versión,
donde se hace, hardware y cualquier información de
configuración.
Entradas de eventos y actividades: ¿qué ocurrió?
Informe de incidencias.
Informe resumen de pruebas: Resumen de las series de pruebas
del tipo deseado.
− Identificador del informe.
− Resumen.
− Variaciones.
− Valoración de la exhaustividad.
− Resumen de resultados.
− Evaluación.
− Resumen de actividades (tiempo de máquina usado).
72 − Aprobación.
36
Documentación insertada en ficheros de datos y control.

Comentarios en ficheros de entrada para una prueba.
Comentarios en ficheros de control.
Ventajas: no se desactualizan, van junto con los
procedimientos o datos de prueba.
Cuidado, este tipo de documentación no está
estandarizada.
No generar demasiado papel. Seleccionar los

documento que nos interesen.
73

Componentes del Plan Pruebas
Componentes del Plan Pruebas:
listas,
tablas,
esquemas
matrices.
Generalmente la información que se introduce en estos
elementos proviene de la especificación, de manuales
de usuario, de entrevistas con los programadores y en
su mayoría de la experiencia con el programa.
74
37
Componentes del Plan Pruebas: Listas
Listas de informes y pantallas de entradas de datos:
Informes que puede imprimir o visualizar el programa y de
pantallas (incluidos cuadros de diálogo) listas de variables
que se deben imprimir o que el usuario puede introducir.
Estas listas nos permiten probar cada uno de los elementos o
distribuir tareas.
Listas de variables de entrada y salida:
Se deben listar todas las variables que se impriman en
informes, que se muestren en pantalla o que se envíen a otro
computador.
Ejemplos:
− Aplicación para seguimiento de problemas: Numero de informe,
Nombre de programa, Release, Versión, Tipo de informe, etc.
− Si el programa lee de disco o base de datos, encontrar la
estructura (preguntarlo al gestor del proyecto) y hacer también una
lista con cada una de las variables que se leen.
75

Algunas características de estas listas son:
− No indican dónde encontrar las variables, ésta información
se guarda en una tabla.
− No indican los valores válidos o inválidos para cada
variable. Para eso están los gráficos de borde.
− No identifican relaciones entre valores de entrada y salida.
Para especificar estas relaciones se utilizan tablas de datos
de entrada/salida.
Base para construcciones más complejas diseño de las
primeras pruebas.
No se debe esperar construir listas completas durante la
primera revisión del programa.
76
38
Listas de características y funciones:
Lista de todas las funciones visibles por el usuario:
− comandos, opciones de menú, etc
Representa la lista de funciones de alto nivel.
En sucesivas revisiones se pueden listar las
subfunciones y subsubfunciones.
Es útil como una lista para el chequeo de las
características más importantes.
77

Listas de mensajes de error:
Todos los mensajes de error que puede generar el programa.
Si no se puede obtener del gestor del proyecto se puede
buscar en los archivos de recursos o lugar del código donde se
encuentren.
Se debe poner el programa en situación de mostrar cada uno
de los mensajes de error:
− correcto, apropiado y recuperable.
Manejo de errores: detectar errores.
Lista de archivos de programa:
Comprobar versiones de los archivos suministradosdetectar
cambios que quizá se hallan pasado por alto y comprobar que
los archivos son los correctos antes de distribución
Lista de hardware compatible:
Ordenadores, impresoras, y cualquier tipo de dispositivo que
se soporte.
78
39
Lista de software compatible:
Programas con los que puede interactuar nuestro programa:
compatibilidad.
Expandir la lista a una tabla: áreas de compatibilidad (en
memoria, ficheros, mensajes, etc.).
Lista de sistemas operativos compatibles:
Se deben listar todos los sistemas, utilidades, interfaces y
drivers con los que va a ser compatible: tabla con las pruebas y
versiones.
Factura de materiales:
Lista de todo lo que se debe entregar al cliente: no olvidar
revisar ningún componente del producto.
Lista de documentos públicos:
Lista cualquier documento sobre el programa que puede ver
cualquiera fuera de la compañía (documentación, advertencias,
cartas, etc.). Sirve para comprobar la documentación antes de
distribuir el producto.
79

Componentes del Plan Pruebas: Tablas
Mostrar relaciones
Tabla de informes
Ejemplo:
− Seguimiento de problemas: si tenemos un programa que nos
imprime automáticamente los informes, y en los días apropiados:
lista de informes + columnas con información sobre cuando y
cuantas copias se imprimen.
80
40
Tabla de variables de entrada y variables de salida.
Tabla de Entrada/Salida
81

Existen tres tipos de tablas:
− Las que muestran todas las variables de entrada, cómo se usan,
dónde aparecen y como afectan a los resultados intermedios y
finales.
− Las que muestran todas las variables de salida, y de dónde
vienen.
− Las que muestran todos los pasos visibles de proceso.
Aquellos de los que puedo extraer las entradas y salidas. Para
cada etapa se listan las variables de entrada y salida.
Decisión: Dos formas de representación
Tablas: Muestran la lógica del programa. Cada entrada
muestra Y o N dependiendo de si el programa hará una cosa u
otra.
Cualquier tabla puede redibujarse como un árbol de decisión.
Mucha gente puede encontrar los árboles de decisión más
legibles que las tablas de decisión.
82
41
83

Tabla de convenciones de teclado.
Son tablas normalmente extensas al estilo de una hoja de cálculo.
Ayuda a revelar inconsistencias en la interfaz de usuario. En la
columna izquierda se listan caracteres individuales y en columnas
sucesivas se listan los efectos de introducir un carácter en varios
estados o cuadros de diálogo.
Tabla de compatibilidad de impresora.
Tabla de bordes.
Clase de equivalencia: Un grupo de pruebas es una clase de
equivalencia si se cree que:
− Todas prueban el mismo concepto.
− Si una prueba captura un error, los demás probablemente también lo harán.
− Si una prueba no detecta ningún error, las demás probablemente tampoco
lo harán.
84
42
C am po C la s e d e C la s e d e e q u i v a le n c ia C a s o s e s p e c ia le s y
e q u iv a l e n c ia in v a lid a d e b o rd e
v a lid a
In fo r m e d e l 0 -9 9 9 9 <0 0
p r o b le m a >9999 9999
D u p lic a r c u a lq u ie r o tr o U n n ú m e ro d e s p u é s
in fo r m e de 9999
C u a lq u ie r n o - d íg ito -0 0 0 1
Se debe usar una o dos pruebas para cada clase de

equivalencia, siendo las mejores las que están en los
bordes de la clase.
− Los programas que fallan con valores no borde suelen
fallar en los bordes también.
− Se deben probar ambos lados de cada clase de
equivalencia, por ejemplo, si el rango válido es 1..9999,
los casos de prueba para la clase válida serían 1 y
9999, mientras que los casos para la clase inválida
serían 0 y 10000.
85

Componentes del Plan Pruebas: Esquemas
Las listas se pueden desarrollar hasta cualquier nivel de
completitud y detalle: aproximación incremental
(recomendable)
Existen herramientas que permiten una reorganización o
relleno de la lista más completo (en vez de procesadores de
texto).
Evolución de las listas de funciones:
Listar las funciones visibles de nivel superior (comandos,
acciones, opciones de menú).
Profundizar en la lista con subfunciones (todas las opciones o
elecciones del menú).
Mostrar subfunciones hasta su nivel inferior. (Cada línea
representará una elección parametrizada, algo que va a
ejecutar).
Listar las condiciones de entrada y salida para cada función y
subfunción.
Listar todas las entradas que afectan a una función.
86
43
Borrador de la lista de funciones:
87

Borrador de la lista de funciones(sección 3):
88
44
Componentes del Plan Pruebas: Matrices
Una matriz es como una tabla pero:
La función de una matriz es coleccionar datos. Proporciona
una estructura para probar el efecto de combinar dos o más
variables, circunstancias, tipos de hardware o eventos. Las
filas y columnas representan condiciones de prueba.
Matrices de entrada/salida de disco:
Es un ejemplo clásico de uso. Suponiendo que un programa
tenga las opciones:
− Guardar, Guardar como e Imprimir a disco.
− Puede ocurrir que: el disco esté lleno, casi lleno, protegido contra
escritura, devuelve time-out, falla el suministro, se pulsa el teclado
mientras se lee o escribe, se mueve o pulsa el ratón.
− Utilizando una o varias matrices podríamos guiar las pruebas.
Disco de baja densidad
Operación Lleno Casi lleno Protegido Timeout Suminist. Teclado Ratón
Guardar
Guardar como
89 Imprimir en disco

Componentes del Plan Pruebas: Matrices
Otras matrices relacionadas con el hardware: permiten
comprobar, por ejemplo, las impresoras contra la cantidad de
memoria necesaria para imprimir.
Matrices de entorno: muestran versiones de sistema
operativo, lenguaje, país, etc frente a otras variables de
entorno o características.
Matrices de combinación de entradas: puesto que algunos
errores aparecen únicamente cuando se da una combinación
de eventos, por lo que se pueden hacer matrices para probar
variables supuestamente independientes.
Matrices de mensajes de error y teclado: pruebas para
comprobar respuesta a comandos dentro de mensajes de
error.
90
45
5. Planificación de las pruebas. Hitos y tareas.
Equilibrio en el desarrollo de software

El objetivo del jefe de proyecto es conseguir un producto
de calidad y en los límites de tiempo, lo que suele
resultar imposible.
Para mantener el proyecto bajo control, el jefe del
proyecto debe mantener el equilibrio entre:
− Fiabilidad del producto vendido.
− El número y profundidad de características.
− Coste de más trabajo en el proyecto.
− Fecha de distribución.
La metodología usada en el proyecto tendrá una gran
influencia en la flexibilidad cuando se aproxime el límite
de entrega (deadline).
91
5 Planificación de las pruebas. Hitos y tareas.
Equilibrio en el desarrollo de software

Algunas restricciones comunes a toda metodología:
− Fiabilidad. El jefe de proyecto siempre puede vender el
producto antes, a un coste de desarrollo menor y con un
montón de errores La decisión de distribuir el producto es
siempre la decisión de distribuir un producto con fallos.
¡No hay final a la etapa de prueba!
− Características: se ha codificado o diseñado mal, o su
coste se planificó mal: quitarla del producto (jefe de
proyecto)
¡Si la característica era importante, perjudicará la
satisfacción del usuario!
− Dinero. Nuevas herramientas, consultores, plantilla, etc.
Inconvenientes: más problemas de comunicación
92
46
− Fecha de venta. Si el proyecto sobrepasa la

planificación retrasar la distribución. Costes:
– Coste directo de continuar el desarrollo. Estímulo al
personal.
– Coste de la ventana de oportunidades.
– Coste gastado en marketing.
– Coste de oportunidades alternativas.
– Ausencia de ingresos actuales.
93

Modelos de desarrollo de software.
El jefe de proyecto tenderá a seleccionar un modelo
que le permita flexibilidad en las áreas más proclives a
cambiar.
Metodología tradicional en cascada.
Cada tarea comienza cuando se ha finalizado la anterior
completamente.
Hace el trabajo de prueba más fácil (buen estándar en
papel).
Fuerza a tomar decisiones al comienzo, cuando no
conocemos el producto o los competidores.
94
47
Cuando el proyecto se retrasa, las restricciones de la
metodología afectadas:
− Características: Requisitos & especificaciones
terminadosCaracterísticas codificadas. Opciones:
eliminarla o rediseñarla.
− Dinero: puede resultar fácil añadir programadores, puede
seguir documentos escritos.
− Fecha de entrega: postergarla para conseguir todo lo
planificado
− Fiabilidad: terminar las pruebas y entregar el producto en
fecha ante estabilidad “aceptable”
El modelo en cascada produce resultados muy malos si se
sobrepasa la planificación.
95

Metodología evolutiva.
Inclusión progresiva de características al corazón del
producto.
Para cada producto hay un rango de posibles
implementaciones: desde el mínimo hasta el ideal.
El mínimo requiere muy poco esfuerzo de prueba.
Cuando se añaden características o grupos de ellas se
inicia un nuevo ciclo de prueba.
Continuamente se está desarrollando un producto que
puede venderse/usarse.
Mejor comprensión de la tasa de progresión del proyecto
Mayor refinamiento
El coste de prueba suele ser alto.
96
48
Cuando el proyecto se retrasa, las restricciones de la
metodología afectadas:
− Características: fácil quitarlas una vez superada la fase mínima.
Todo el trabajo se refleja en el producto
− Dinero: se puede gastar dinero para añadir más características. El
diseño puede resultar un cuello de botella.
− Fecha de entrega: se dispone de flexibilidad para retrasar la
fecha o venderlo.
− Fiabilidad: es alta. El producto es estable antes de introducir
nuevas características.
Se puede estropear un proyecto evolutivo:
− Continuar generación de código y no solucionar problemas
− Pensando que no se necesita demasiada planificación inicial.
− Mala información de las características del producto para el
marketing
− No asignar recursos de prueba
97

Algunas implicaciones del modelo en cascada:
Revisar pronto la interfaz de usuario (¿prototipos?) no
pruebas de usabilidad al final del proyecto
Temprana escritura del plan de prueba análisis de las
especificaciones.
No se puede comenzar a probar hasta tarde Planificar
el trabajo
Fase de pruebas = punto crítico
Informe semanal de errores críticos Retrasar la
entrega
98
49
Por el contrario, algunas implicaciones del modelo
evolutivo:
Planificar plantilla para probar muy pronto. Comenzar a
realizar las pruebas de fiabilidad tan pronto como se
alcance el primer nivel.
Planificar oleadas de pruebas de usabilidad conforme el
proyecto crezca.
Planificar escribir el plan de prueba progresivamente.
Planificar hacer las pruebas más potentes tan pronto
como sea posible. El jefe de proyecto puede parar el
desarrollo en cualquier momento.
99

Ciclo completo
Plan Configuración
Planificación Pruebas
Planificación Diseño
Diseño Pruebas Criterios
de
dePruebas
Pruebas de
dePruebas
Pruebas Ejecución
Ejecución Compleción:
de
dePruebas
Pruebas Terminación
Información Configuración
Información SW Software
Proyecto Notificación
Defectos Resultados
Correcciones
Desarrollo
Desarrollo
Depuración Errores
Depuración Evaluación
Evaluación
Actividades Estadística
Preventivas Errores
Resultados
Predicción Análisis
Análisis Esperados
Fiabilidad de
deerrores
errores
100
50
Un ejemplo: RUP
Plan Pruebas
101

Costes relacionados con la calidad.
Costes de prevención, búsqueda y manejo de errores y
fallos.
El coste de las pruebas es menor que el de tratar
errores descubiertos por usuarios.
Justificación documentada de la reducción de gastos:
Ajustar un equipo de pruebas a una metodología
necesita una asignación que debe justificarse
(tiempo/dinero).
Otras tareas que necesitan justificación: análisis de las
llamadas de soporte técnico, automatización de los casos
de prueba, compatibilidad con impresoras, conducción
de pruebas beta externas.
102
51
Costes relacionados con la calidad.
Categorías de costes de calidad:
Prevención (5%-10%).
Evaluación (20%-25%).
Fallos internos (65%-75%). Gestión de errores
detectados durante el desarrollo y pruebas
Fallos externos. Gestión de errores detectados por los
clientes.
Los grupos de QA suelen recoger sistemáticamente

información de los costes relacionados con la calidad.
Grupo de prueba: estimaciones.
103

Línea temporal del desarrollo.
Generalmente el jefe de proyecto publicará la
planificación del proyecto, que contendrá una serie de
hitos:
Alfa: sinónimo de software preliminar pero usable
Beta: producto casi terminado.
Cualquiera que sea el trabajo en teoría, la aproximación

práctica conlleva un conjunto de acuerdos:
planificación
responsabilidades
104
52
Línea temporal del desarrollo
Diseño
Diseñodel
delproducto
producto
Fragmentos
Fragmentosde
decódigo:
código:1ª
1ªfuncionalidad
funcionalidad
Casi
CasiAlpha
Alpha
Software
SoftwareAlpha
Alpha
Pre-Beta
Pre-Beta
Beta
Beta
Interfaz
Interfazde
deusuario
usuariocongelada
congelada
Pre-final
Pre-final
Test
Testde
deIntegridad
IntegridadFinal
Final
Entrega
Entrega
105
6. Depuración
No es una tarea propia de la prueba, se produce como

consecuencia de una prueba efectiva.
IEEE Std 729: “Proceso de localizar, analizar y corregir
los defectos que se sospecha que contiene el software”.
Pressman: “Proceso mental mal comprendido que
conecta un síntoma con una causa”.
Casos
Casosde
deTest
Test
Ejecutar
Ejecutar
Rdos.
Rdos.Test
Test
Depuración
Depuración
Síntomas
Síntomas
106
53
6. Depuración
Es un proceso difícil (psicología humana), debido a las

siguientes características:
El síntoma y la causa pueden estar separado entre sí.
El síntoma puede desaparecer (temporalmente) al
corregir otro error.
El síntoma puede estar producido por algo que no sea un
error propiamente dicho.
El síntoma puede producirse por un error humano.
El síntoma puede ser debido a problemas de tiempo y no
de funcionales.
Puede ser difícil reproducir las condiciones de entrada.
El síntoma puede aparecer de forma intermitente.
107
6. Depuración
La presión para corregir un error puede forzar a

introducir más.
El objetivo es localizar y corregir un error, combinando
la evaluación del sistema y una gran cantidad de
intuición (y suerte).
En general, la clasificación de enfoques de depuración
es la propuesta por Myers (1979):
Sin análisis previo.
− Por la fuerza bruta.
Con análisis previo.
− Método de vuelta atrás (backtracking).
− Método de eliminación de la causa.
108
54
6. Depuración
Depuración por fuerza bruta.

Aplicable únicamente cuando los demás fallan. Los más
utilizados y los menos eficientes.
Métodos:
− Volcado de memoria.
− Inserción de sentencias de escritura.
− Herramientas de depuración.
Se confía en que en algún lugar de la información
generada se encuentre una pista que nos haga ver la
causa del error.
Depuración por vuelta atrás.
Consiste en recorrer hacia atrás la lógica del programa.
Debido al aumento de caminos conforme se aumentan
las líneas de código únicamente es practicable en
programas pequeños.
109
6. Depuración
Depuración por eliminación de causa.

Consta de dos etapas:
− Se organizan los datos obtenidos en la prueba para intentar
concluir una hipótesis de causa.
− Se utiliza la deducción o inducción para confirmar o revocar
dicha hipótesis.
Eliminación de causa por deducción.
− Tras analizar los datos disponibles se enumeran las
posibles causas que han podido provocar el error.
− Se eliminan las que se consideren imposibles tras un
examen detallado.
− Si no quedan causas posibles se recogen nuevos datos de
la prueba para elaborar nuevas causas.
− Se refinan las hipótesis supervivientes y se prueban
ejecutando ciertos casos específicos.
− Si las pruebas confirman la hipótesis se corrige el error, de
lo contrario se recogen nuevos datos.
110
55
6. Depuración
Eliminación de causa por inducción.

− Localizar los datos relacionados con los síntomas del error.
− Se organizan en tablas que muestran las características de
los datos clasificados. Se estudian para analizar las
relaciones entre los datos.
− Se genera una hipótesis de la causa que puede haber
provocado el error. Si no es posible se generan más datos y
si aparecen varias se comprueban.
− Se prueban las hipótesis. Si no se aceptan deben idearse
más, pero si se acepta ya se puede corregir el error.
111
6. Depuración
Consejos prácticos
Localizar el error:
− Analizar la información y no utilizar un enfoque
aleatorio de búsqueda.
− Al llegar a un punto muerto, o pasar a otra cosa o
describir el problema a otra persona.
− Usar herramientas de depuración solo como recurso
complementario, no único.
− No experimentar cambiando el programa.
− Deben atacarse los errores individualmente.
− Debe fijarse la atención en los datos manejados en el
programa y no sólo en la lógica del proceso.
112
56
6. Depuración
Consejos prácticos
Corregir el error:
− Donde hay un error suele haber más.
− Lo que debe corregirse el error, no enmascarar los
síntomas.
− La probabilidad de corregir un error no es total, deben
revisarse las correcciones.
− Es frecuente crear nuevos errores al corregir deprisa y
sin cautela.
− La corrección debe situarnos en la fase del ciclo de
vida al que afecte el error, generalmente la fase de
diseño.
113
57

T05 Pruebas Del Software Técnicas y Estrategias

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

T05 Pruebas Del Software Técnicas y Estrategias

Diunggah oleh

Hak Cipta:

Format Tersedia

Tema 5.

Pruebas del software: Técnicas y

1. Objetivos y límites de las pruebas.

1. Objetivos y límites de las pruebas

Probar un programa completamente No existen

1. Objetivos y límites de las pruebas

1. Objetivos y límites de las pruebas

Fomenta una actitud inefectiva

El propósito de probar un programa es encontrar problemas en

1. Objetivos y límites de las pruebas

Una prueba que resuelve un problema es un éxito. Una

Se toma una actitud destructiva contra el programa,

herrare humanum est

Diseño de casos de prueba

Las pruebas de caja blanca se basan en el estudio

A Nodos predicado (condición)

Outputs which reveal

Habría que diseñar casos de prueba que cubran todas

2. Tipos de pruebas. Pruebas caja negra:

2. Tipos de pruebas. Pruebas caja negra:

2. Tipos de pruebas. Estrategias

2. Tipos de pruebas. Estrategias

Level 2 Level 2 Level 2 Level 2

2. Tipos de pruebas. Estrategias

Requirements High-level Formal Detailed

Pruebas dinámicas frente a estáticas:

¿Qué es un error reproducible?:

3. Análisis y seguimiento de errores.

Encontrar caminos alternativos al mismo problema

Encontrar problemas relacionados

3. Análisis y seguimiento de errores.

6. Comprobar error en versiones anteriores del programa

7. Buscar la dependencia de configuración.

3. Análisis y seguimiento de errores.

3. Análisis y seguimiento de errores.

3. Análisis y seguimiento de errores.

4. Documentación y diseño de las pruebas

El estándar ANSI/IEEE 829-1983 para la

El objetivo general del plan de pruebas: ¿producto o

4. Documentación y diseño de las pruebas

4. Documentación y diseño de las pruebas

4. Documentación y diseño de las pruebas

4. Documentación y diseño de las pruebas

4. Documentación y diseño de las pruebas

4. Documentación y diseño de las pruebas

Lista de funciones (No IEEE).

4. Documentación y diseño de las pruebas

4. Documentación y diseño de las pruebas

Documentación insertada en ficheros de datos y control.

No generar demasiado papel. Seleccionar los

4. Documentación y diseño de las pruebas

4. Documentación y diseño de las pruebas

4. Documentación y diseño de las pruebas

4. Documentación y diseño de las pruebas

4. Documentación y diseño de las pruebas

4. Documentación y diseño de las pruebas

Se debe usar una o dos pruebas para cada clase de

4. Documentación y diseño de las pruebas

4. Documentación y diseño de las pruebas

4. Documentación y diseño de las pruebas

Equilibrio en el desarrollo de software

5 Planificación de las pruebas. Hitos y tareas.

Equilibrio en el desarrollo de software

− Fecha de venta. Si el proyecto sobrepasa la