Pruebas Software 1

5º Ingeniería en Informática
Asignatura: Ingeniería del Software II.
Tema 5. Pruebas del software:

Técnicas y Estrategias.
5.1. Objetivos y límites de las
Unidad II. Garantía de calidad, pruebas.
validación & verificación.
Tema 5. Pruebas del software: Probar un programa completamenteÖ No
Técnicas y Estrategias. existen errores sin descubrir
¿Se puede realizar una prueba completa?
– Programadores junior: todas las posibles
5.1. Objetivos y límites de las
entradas o todas sus secuencias de
pruebas.
5.2 Tipos de pruebas.
ejecución.
5.3 Análisis y seguimiento de – Gestores creen en su existencia
errores. – Compañías de prueba de software: lo
5.4 Documentación y diseño de las prometen
pruebas.
– Herramientas de analisis: venden la
5.5 Planificación de las pruebas.
Hitos y tareas. promesa
5.6 Depuración. – Vendedores: creen que sus productos
están libres de fallos.
Algunos testeadores creen en las pruebas
completas(planificación, tiempo, personal)
Ö inseguridad, culpabilidad
1 2
1
5º Ingeniería en Informática 5º Ingeniería en Informática
Asignatura: Ingeniería del Software II. Asignatura: Ingeniería del Software II.
Tema 5. Pruebas del software: Técnicas y Tema 5. Pruebas del software: Técnicas y
Estrategias. Estrategias.
5.1. Objetivos y límites de las pruebas. 5.1. Objetivos y límites de las pruebas.
Razones para la imposibilidad Razones para la imposibilidad
de prueba completa de prueba completa
No se puede probar las respuesta del No se pueden probar todas las
programa para cada posible entrada. secuencias de ejecución.
– Qué significaría probar cada entrada: – Una secuencia puede ser trazada a través del
Se deben probar todas las entradas válidas. código.
Se deben probar todas las entradas – Dos secuencias diferentes: no ejecutan las
inválidas. mismas sentencias o lo hacen en orden
diferente.
Se deben comprobar todas las entradas
editadas. – Myers, en 1979 describió un programa con un
bucle y unas cuantas condiciones (IF), que
Se deben probar todas las variaciones
ocupaba unas 20 líneas en la mayoría de
temporales de las entradas.
lenguajes. Tenía 100 trillones de secuencias, un
– Qué ocurre si no puedo probar todas las testeador podría probarlo en un billón de años.
entradas de un programa Ö Abandona la – Necesario disponibilidad del código.
prueba completa
– Suponiendo que se puede hacer una
prueba completa. ¿Resuelve esto
nuestro problema?
3 4
2
Tema 5. Pruebas del software: Técnicas y

Estrategias. Tema 5. Pruebas del software: Técnicas y Estrategias.
5.1. Objetivos y límites de las pruebas. 5.1. Objetivos y límites de las pruebas.
Razones para la imposibilidad Objetivo del testeador:
de prueba completa ¿Verificar el programa?
No se pueden encontrar todos los errores Descripción sin sentido
de diseño. Equivocado
– Las especificaciones de diseño a menudo – Estimaciones comunes dicen que el coste
contienen errores(2+2=5) de encontrar y corregir errores en
¿Error que el programa siga una programas fluctúa entre el 40% y 80% del
especificación erronea o que se desvíe? coste total. No se gasta este dinero para
Mala especificación Ö Erróneo. verificar, sino porque el programa no
– No se puede probar completamente un funciona.
programa si no se pueden encontrar – Errores privados y públicos (Beizer, 1984)
todos sus errores de diseño. Errores privados: los que comete el
No se puede comprobar la corrección porgramador (1.5/sentencia).
usando la lógica. Errores públicos. Los que quedan
– Ignorando el número de incógnitas y el cuando el porgramador declara su
tiempo podríamos validar la consistencia, código libre de fallos. (1/100
decidir si está de acuerdo con la sentencias).
especificación, pero ¿es correcta la
especificación?.
5 6
3
Tema 5. Pruebas del software: Técnicas y Estrategias.

5.1. Objetivos y límites de las pruebas. Tema 5. Pruebas del software: Técnicas y Estrategias.
Objetivo del testeador: 5.1. Objetivos y límites de las
¿Verificar el programa? pruebas.
Prepara a los testers para el fallo Una prueba que resuelve un problema es
– Los testeadores no deben querer verificar que un éxito. Una prueba que no revela ningún
un programa se ejecute correctamente. problema es una perdida de tiempo.
Si se quiere y espera que un programa funcione
El propósito de encontrar problemas es
bien, se perderán errores.
Si se espera que falle, se tenderá a detectar más corregirlos.
errores.
Si se penaliza por encontrar errores, se perderán
errores.
Fomenta una actitud inefectiva
Entonces, Porqué probar
– No podemos encontrar todos los errores. Aumento de la calidad.
– No podemos probar que el programa es
correcto, y no queremos hacerlo.
Se toma una actitud destructiva contra el
– Es caro, frustraste y no da ninguna popularidad.
programa, pero a largo plazo ese trabajo
es constructivo.
El propósito de probar un programa es encontrar herrare humanum est

problemas en él.
7 8
4

5.1. Objetivos y límites de las pruebas.
5.1. Objetivos y límites de las pruebas. Consideraciones comunes a
Ciclo completo de las pruebas toda prueba.
Caso de prueba: conjunto específico de
Diseño datos de entrada y de procedimientos
Diseñodede
Casos
Casosde
deTest
Test
asociados, desarrollados para probar un
caso determinado (secuencia/camino
Casos
Casosde
deTest
Test particular, verificación de un requisito, etc).
Preparar – deben ser documentados y archivados.
Preparar
Datos
Datosde
deTest
Test – definir el resultado esperado.
– comprobar si no hace lo que debe o hace lo
Datos
Datosde
deTest
Test que no debe.
– tanto entradas inválidas e inesperadas
Ejecutar
Ejecutar como esperadas
progr.
progr.con
con – inspeccionar concienzudamente resultado
datos
datosdedetest
test de cada prueba
Rdos.
El programador evitará probar sus
Rdos.Test
Test programas.
Probabilidad de la existencia de nuevos
Comparar
Comparar
rdos. errores en una sección de un programa es
rdos.con
con
Casos
Casosde
deTest
Test
proporcional al número de errores ya
descubiertos.
Informes
InformesTest
Test
1
9 0
5
Tema 5. Pruebas del software: Técnicas y

Estrategias. Tema 5. Pruebas del software: Técnicas y Estrategias.
5.2. Tipos de pruebas. 5.2. Tipos de pruebas.
Diseño de casos de prueba Las pruebas de caja blanca se basan
– Cualquier producto de ingeniería puede en el estudio minucioso de los detalles
comprobarse de dos formas: procedimentales.
Conociendo la función específica para la – A primera vista,
que fue diseñado (prueba de las Una prueba de caja blanca nos llevaría a
funciones) Î Pruebas de caja negra un programa 100% correcto.
Conociendo el funcionamiento del Pero nos encontramos con el problema
producto (prueba de la operación interna) de las pruebas completas (o
Î Pruebas de caja blanca exhaustivas). No podemos generar
En el software, pruebas de caja negra casos de prueba para todos los caminos
son las que se llevan a cabo sobre la lógicos (secuencias de ejecución).
interfaz del software. Solución: uso sólo para generar los
casos de prueba más significativos
– Examina aspectos del modelo (caminos o estructuras de datos más
fundamental del sistema (funcionalidad importantes).
operativa, aceptación de entradas,
resultados, etc)
1 1
1 2
6
Tema 5. Pruebas del software: Técnicas y Estrategias. Tema 5. Pruebas del software: Técnicas y Estrategias.
Pruebas de caja blanca Pruebas de caja blanca
Se usan la estructura de control del diseño No se pueden testear todos los caminos.
procedimental para diseñar los casos de Criterios de selección:
prueba. – Cobertura de sentencias
¿Por qué utilizar pruebas de caja blanca?: Escribir los casos suficientes para que cada
– Los errores lógicos y las suposiciones sentencia en el programa se ejecute al
menos una vez.
incorrectas son inversamente
proporcionales a la probabilidad de que se – Cobertura de decisión o de ramificación.
ejecute un camino del programa. Escribir casos suficientes para que cada
decisión, por lo menos una vez, tenga un
– A menudo creemos que un camino lógico
resultado verdadero y uno falso.
tiene pocas posibilidades de ejecutarse
cuando, de hecho, se puede ejecutar de – Cobertura de condición
forma regular. Escribir el suficiente número de casos para
que cada condición de toda decisión tenga
– Los errores tipográficos son aleatorios.
todos los resultados posibles.
Testeo estructural, selección adecuada de
caminos:
– Camino: secuencia de sentencias
encadenadas desde la sentencia inicial del
1 programa hasta su sentencia final 1
3 4
7
Cobertura de caminos Cobertura de caminos
Debemos asegurar que cada uno de Para obtener un grafo de flujo a partir de
los posibles caminos de un programa un lenguaje de diseño o pseudocódigo,
sean ejecutados al menos una vez. se deben realizar los siguientes pasos:
Para llegar a obtener esta cobertura – Señalar cada una de las condiciones de
se deben realizar las siguientes cada decisión, tanto en sentencias IF y
acciones: CASE como en bucles WHILE o UNTIL.
1. Obtener el grafo de flujo de control
– Agrupar sentencias entre cada dos
asociado al software.
condiciones, teniendo en cuenta que las
2. Calcular el número de caminos
sentencias de finalización ENDIF,
mediante ecuaciones algebraicas.
ENDDO, END, etc. constituirán un nuevo
3. Identificación de los caminos para su
nodo.
enumeración.
– Numerar tanto las condiciones como los
Elementos utilizados para la
grupos de sentencias. Nodos predicados:
construcción de grafo de flujo son:
identificar la condición con una letra y
cada una de las aristas de salida con el
A
resultado de la condición.
Nodos (sentencias)
– Decisiones que impliquen a varias
Región
Aristas (flujos de control) condiciones: descomponerlas
1 A Nodos predicado (condición) 1
5 6
8
Cobertura de caminos Cobertura de caminos
Cálculo del número de caminos mediante El cálculo para caminos de un grafo con
ecuaciones algebraicas. bucles puede ser ilimitado.
En el caso de grafos simples (sin Se define un nuevo concepto:
bucles) se siguen las siguientes reglas: – Camino de prueba: camino de programa
que atraviesa, como máximo una vez el
Si definimos Nx como el número de cuerpo de cada bucle encontrado.
caminos que atraviesan x. Atendiendo a esta definición se puede
calcular el número de caminos de
A prueba de dos formas:
A A B – Rectificación de bucles:
Pretende eliminar del grafo la arista que
forma el bucle, sustituyéndola por una
B C C
nueva arista que represente el
B encadenamiento de aristas que se
producirían al iterar una vez el bucle.
Definirían: – Ecuaciones algebraicas:
Se definen nuevas ecuaciones que se
Na = Nb + Nc asocian a los dos tipos de bucles posibles
Na = Nb = Nc (while y until)
Nw = 1 + Na
1 Na = 2 x Nb 1 Un = Na x (1 + Na)
7 8
9
Prueba del camino básico Prueba del camino básico
La complejidad ciclomática es una La complejidad se puede calcular de
métrica del software que proporciona tres formas:
una medición cuantitativa de la – El número de regiones del grafo de flujo
complejidad lógica de un programa. coincide con la complejidad ciclomática.
– Conjunto básico de un programa: – La complejidad ciclomática, V(G), de un
número de caminos independientes grafo de flujo G se define como
Camino independiente: cualquier camino V(G) = A – N + 2
del programa que introduce un conjunto
donde A es el número de aristas del
de sentencias de proceso o una nueva
grafo de flujo y N es el número de
condicion
nodos.
Asegurar que se ejecuta cada sentencia
al menos una vez y que cada condición – La complejidad ciclomática, V(G), de un
se habrá ejecutado en su vertiente grafo de flujo G también se define como
verdadera y falsa V(G) = P + 1
donde P es el número de nodos
predicado contenidos en el grafo de flujo
G.
1 2
9 0
10
Prueba del camino básico Prueba de la estructura de control
Obtención de casos de prueba: Pruebas de condición
1. Usando el diseño o el código como Método de diseño de casos de prueba que
ejercita las condiciones lógicas contenidas en
base, dibujamos el correspondiente el módulo de un programa.
grafo de flujo.
Prueba de flujo de datos
2. Determinamos la complejidad Selecciona caminos de prueba de un programa
ciclomática del grafo de flujo de acuerdo con la ubicación de las definiciones
resultante. y los usos de las variables del programa.
3. Determinamos un conjunto básico de Prueba de bucles
caminos linealmente independientes. Se centra únicamente en la validez de las
V(G):número de caminos linealmente construcciones de bucles:
independientes de la estructura de Bucles simples: se les aplican pruebas como
pasar por alto el bucle, pasar una sola vez,
control del programa. pasar n-1, n y n+1 veces.
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
2 establecidas con el fin de comprobar 2
1 cada camino. 2
11

5.2. Tipos de pruebas. Tema 5. Pruebas del software: Técnicas y Estrategias.
Pruebas de caja blanca 5.2. Tipos de pruebas.
Prueba de la estructura de control Pruebas de caja negra
Prueba de bucles Se centran en los requisitos funcionales
Bucles anidados: se utilizan otros del software.
enfoques para reducir la complejidad (por Tratan de encontrar errores en las
ejemplo, pruebas simples en bucles siguientes categorias:
internos manteniendo parámetros de 1. Funciones incorrectas o ausentes.
iteración para bucles externos). 2. Errores de interfaz.
Bucles concatenados: pueden ser simples 3. Errores en estructuras de datos o en
o mantener dependencia (bucles accesos a bases de datos externas.
anidados). 4. Errores de rendimiento.
Bucles no estructurados: rediseño. 5. Errores de inicialización y de terminación.
Tienden a aplicarse durante fases
posteriores de las pruebas.
2 2
3 4
12

5.2. Tipos de pruebas.
5.2. Tipos de pruebas. Pruebas de caja negra
Pruebas de caja negra Secuencia de eventos
Secuencia usual de eventos para pruebas – Pruebas funcionales, de sistema,
de caja negra: verificación y validación:
Se verifica un programa comprobandolo
– Planificación de las pruebas: contra los documentos de diseño o
puede comenzar en cuanto se especifiquen especificaciones más próximas. Si existe
los requisitos de la aplicación. una especificación externa se realizan
pruebas funcionales.
– Pruebas de aceptación:
Se valida el programa comprobandolo contra
cada vez que se reciba una nueva versión del los requisitos de usuario o de sistema. Las
programa, comprobar cuando es pruebas de sistema y de integración son
suficientemente estable para la batería de pruebas de validación.
pruebas. Validación y Verificación Independiente:
– Aseguramiento de estabilidad inicial: hechas por una empresa independiente
No se intenta encontrar errores Para una descripción completa de la
verificación y validación: IEEE Standard for
Decidir en que áreas del programa se va a Software Verification and Validation Plans
confiar. Si el programa parece débil en un (ANSI/IEEE Standard 1012-1986).
área, se probará más duramente y se Algunas pruebas ejecutadas durante las
planificará un mayor tiempo. pruebas de funcionalidad y de sistema:
Verificación de la especificación.
Corrección.
Usabilidad.
2 2
5 6
13
Pruebas de caja negra Pruebas de caja negra
Secuencia de eventos Secuencia de eventos
Condiciones de borde – Pruebas de integridad y de publicación
Rendimiento (release):
Transiciones entre estados En las pruebas de publicación se recogen todos los
Pruebas de uso convencional elementos que irán al consumidor o al
Pruebas de carga: manufacturador, se comprueba que son todas
– volumen, stress y almacenamiento correctas, se copian y se archiva la copia.
Tareas de Fondo (background) Después se publican.
Recuperación ante errores Las pruebas de integridad son pruebas de
Seguridad publicación más rigurosas. Proporciona una
Compatibilidad y conversión última oportunidad para pensar las cosas antes
Configuración de enviar el producto al exterior.
Instalabilidad y practicabilidad Intentan anticipar cualquier crítica que pueda
aparecer en la revisión del producto (sólo una
Quickies
persona senior, posiblemente independiente,
– Pruebas Beta: compara el producto y sus requerimientos más
Cuando el programa y la documentación recientes, lo compara con otros productos, etc).
parece estable, es hora de adquirir – Prueba final de aceptación y certificación:
información del usuario (feedback). En el Ejecución de una prueba de aceptación por parte
beta test, las personas que serán del cliente cuando entreguemos el producto.
usuarios del producto lo usarán de alguna La certificación se realiza por una tercera persona.
2 forma para hacer comentarios. 2 Se trata de una prueba breve.
7 8
14

5.2. Tipos de pruebas.
5.2. Tipos de pruebas. Comparación de tipos de
Secuencia de eventos pruebas
Código de Código de Código de Pruebas incrementales frente a

componente componente componente pruebas de explosión (big bang):
– En una estrategia incremental cada pieza
Prueba Prueba
Prueba de
de Prueba
Prueba de
se prueba separadamente. La prueba de
Prueba de
de de
unidad unidad
unidad ... unidad piezas individuales de un proceso o
unidad unidad
programa se llaman pruebas de
Componente probado módulo, de unidad o de elemento.
Especificaciones Prueba
Prueba de
de
de diseño integración
integración Una vez probadas individualmente
Módulos integrados algunas se prueban juntas. Se llaman
Requisitos
Prueba
Prueba pruebas de integración.
funcionales del
sistema Funcional
Funcional Las pruebas incrementales hacen más
Sistema en
funcionamiento fácil la localización de los errores.
Otros requisitos Prueba
Prueba de
de
del software – En una estrategia de prueba por
rendimiento
rendimiento
Software verificado explosión, los módulos y procesos no se
y validado
Especificación de
Prueba
prueban hasta que se integra el sistema.
requisitos del Prueba de
de
cliente aceptación
aceptación No es necesario código “driver”.
Sistema aceptado
Entorno del Prueba
Prueba de
de
2 usuario instalación
instalación 3
Sistema en uso!!
9 0
15
Comparación de tipos de Comparación de tipos de
pruebas pruebas
Pruebas top-down versus bottom-up: Pruebas de regresión:
Son estrategias incrementales. El producto debe – Aplicable a pruebas tanto de caja negra
haber sido diseñado jerárquicamente. como blanca.
– Las pruebas bottom-up prueban primero los – Se usa con dos ideas diferentes (en
módulos de nivel inferior. común tienen la de reusar pruebas
Driver para testear las rutinas de menor nivelÎ antiguas):
testear rutinas de mayor nivel
Al encontrar un error y corregirlo, repetir
– En las pruebas top-down, son probados primero la prueba que reflejó el problema en
los módulos de mayor nivel (no se necesita primer lugar. Se pueden crear grupos de
código “driver”, sí “stub”). pruebas de regresión. Se refleja la
Pruebas dinámicas frente a estáticas: vulnerabilidad de las correcciones.
– En una prueba dinámica se ejecuta el código. Cuando se encuentra y corrige un error,
– En una prueba estática se examina el código. se ejecuta una serie estándar de pruebas
Se prueba sin ser ejecutado. para asegurarnos de que el cambio no
perturba nada más.
Existen muchas herramientas para el análisis
estático (compiladores, lincadores, etc.).
También puede realizase por humanos
(revisiones).
3 3
1 2
16
5.3. Análisis y seguimiento de 5.3. Análisis y seguimiento de
errores. errores.
¿Qué es un error reproducible?: Encontrar las consecuencias del problema:
– Se puede describir como llevar el programa a un
estado conocido.
– Observar las consecuencias más graves de
– Desde ese estado, se pueden especificar una
un error. Esto estimulará a todo el mundo
serie de pasos exactos que muestran el para que se corrija.
problema. – Cuando un programa falla:
Para hacer más efectiva la detección de un error Lo hace en un estado inesperado
(informe), ésta debe analizarse.
Si el estado es inesperado, el siguiente
Si el problema es complicado porque requiere un
alto número de pasos o sus consecuencias son código hará suposiciones incorrectas,
difíciles de describir Î gastar tiempo con el. produciéndose más errores.
Se deben simplificar los informes o dividirlos en una Lo hace dentro de una rutina de
serie. recuperación de errores
Los objetivos de este análisis de un error Las rutinas de recuperación ante errores son
reproducible: con frecuencia las menos probadas.
– Encontrar las consecuencias más serias del Generalmente tienen problemas más graves
problema. que el que nos ha llevado allí.
– Encontrar las condiciones más simples, cortas y – Cuando el programa registra un problema,
generales de disparar el error.
o muestra basura en pantalla, o cualquier
– Encontrar caminos alternativos para el mismo
error. cosa inesperadaÎ error complementario
3 – Encontrar problemas relacionados. 3
3 4
17
5.3. Análisis y seguimiento de 5.3. Análisis y seguimiento de
errores. errores.
Encontrar las condiciones más simples y Encontrar caminos alternativos al mismo
generales : problema:
– Algunos errores aparecen únicamente – Disparar un error puede llevar muchos
cuando se introduce una compleja serie de pasos. Esto puede hacer pensar que es
errores o respuestas indeseadas. tan complicado que el usuario no lo va a
– La corrección de los errores involucra unas percibir.
compensaciones: – Se puede contrarrestar esta impresión
Si entender y corregir un error requiere un mostrando varios caminos al mismo
mínimo esfuerzo, alguien lo corregirá. problema.
Si la corrección requiere mucho tiempo y Indica que el problema es más grave.
esfuerzo, el programador no mostrará – Si varios caminos nos llevan al mismo
voluntad para corregirlo. error, algo tendrán en común.
Si aparece durante el uso normal del
programa, se mostrará mayor interés.
Si parece que nadie verá el problema, el
interés será bajo.
– Encontrar modos simples de reproducir un
problema hace el trabajo más fácil y rápido
3 al programador. 3
5 6
18

Tema 5. Pruebas del software: Técnicas y Estrategias. 5.3. Análisis y seguimiento de errores.
5.3. Análisis y seguimiento de Tácticas para analizar un error
errores. reproducible
Encontrar problemas relacionados: Buscar el paso crítico.
– Buscar otros lugares donde se hace algo – No se mira una causa, se miran sus
similar a lo que produjo un error. síntomas.
– Un error nos proporciona la oportunidad de – Los síntomas menores son a veces la
probar las rutinas de recuperación o el primera manifestación del error.
código normal en un estado inusual. – Buscar:
Se encontrarán errores similares. 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.
3 3
7 8
19
Tema 5. Pruebas del software:
Técnicas y Estrategias.

5.3. Análisis y seguimiento de
5.3. Análisis y seguimiento de errores. errores.
Tácticas para analizar un error Tácticas para analizar un error
reproducible reproducible
Maximizar la visibilidad del Una vez encontrado el paso crítico, variar
comportamiento del programa. el comportamiento.
– Cuantos más aspectos del comportamiento Si sabemos que la secuencia A entonces
del programa puedan hacerse visibles, más B entonces C provoca un error en C, y
cosas se podrán ver y con mayor sabemos que el paso crítico está en B.
probabilidad se encontrará el paso crítico. Intentar A entonces B entonces D.
¾ Herramientas (Depuradores).
– Objetivo: encontrar un caso serio.
¾ Registro de todos los accesos a fichero,
Buscar siguientes errores.
pantalla, etc.
Incluso cuando no conozcamos el paso crítico,
¾ Utilizar un terminal lento.
una vez encontrado el error, seguir ejecutando
el programa momentáneamente:
– Los siguientes errores pueden estar
derivados del primero (no serán
reproducibles una vez subsanado el
primero).
– Pueden no ser consecuencia directa de
éste (se deben probar diferentes caminos).
3 4
9 0
20

5.3. Análisis y seguimiento de errores.
Tácticas para analizar un error 5.3. Análisis y seguimiento de errores.
reproducible Hacer reproducible un error
Variar o anular progresivamente los Un error es reproducible únicamente si
pasos. alguien es capaz de hacer lo que dices y
Si el problema es complejo probar que
ocurre al suprimir o cambiar algunos pasos obtener lo obtienes.
Î podemos deshacernos de algunos – Se debe ser capaz de explicar como llegar
pasos. a un estado y como disparar el error.
Probar las condiciones de borde.
Se debe escribir todo lo que se recuerde
Comprobar el error en versiones
anteriores del programa. de lo que se hizo la primera vez e intentar
Nos puede indicar que el error ha sido reproducir el error.
producido por un cambio. Más importante al Si una vez obtenido el error no se puede
final del proyecto.
reproducir deberemos tener en cuenta
Buscar la dependencia de configuración.
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.
4 4
1 2
21
5.3. Análisis y seguimiento de errores. 5.3. Análisis y seguimiento de errores.
Hacer reproducible un error Hacer reproducible un error
– Detalles olvidados. – El error es un efecto lateral de algún otro
La mejor solución es aplicar un plan paso-a- problema.
paso. – Error hardware intermitente.
– Errores de usuario: no hiciste lo que – Dependencia temporal.
pensaste que hiciste. El error puede depender de la fecha u hora
– Un efecto del error hace imposible la en la que se realiza la prueba.
reproducción. – Dependencia de los recursos.
Los datos pueden haber sido modificados – Espoleta retardada.
por la aplicación, utilizar siempre una copia
Errores que no tiene un impacto inmediato.
de los datos.
– Casos especiales en el código.
– El error depende del estado de la memoria.
La ayuda del programador puede ahorrar
Ver la cantidad de memoria, la
mucho tiempo.
fragmentación, etc. Puede ayudar a
encontrar la condición. – Alguien ha jugueteado con tu máquina.
– Es un error de estado inicial.
– El error se ha basado en datos corruptos.
4 4
3 4
22

Pruebas Software 1

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Pruebas Software 1

Cargado por

Copyright:

Formatos disponibles

5º Ingeniería en Informática

Asignatura: Ingeniería del Software II.

Tema 5. Pruebas del software:

Tema 5. Pruebas del software: Técnicas y

Tema 5. Pruebas del software: Técnicas y Estrategias.

El propósito de probar un programa es encontrar herrare humanum est

Tema 5. Pruebas del software: Técnicas y Estrategias.

Tema 5. Pruebas del software: Técnicas y

Tema 5. Pruebas del software: Técnicas y Estrategias.

Tema 5. Pruebas del software: Técnicas y Estrategias.

Tema 5. Pruebas del software: Técnicas y Estrategias.

Código de Código de Código de Pruebas incrementales frente a

Tema 5. Pruebas del software: Técnicas y Estrategias.

Tema 5. Pruebas del software: Técnicas y Estrategias.

Tema 5. Pruebas del software: Técnicas y Estrategias.

También podría gustarte

Pruebas Software 1

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Pruebas Software 1

Cargado por

Copyright:

Formatos disponibles

5º Ingeniería en Informática

Asignatura: Ingeniería del Software II.

Tema 5. Pruebas del software:

Tema 5. Pruebas del software: Técnicas y

Tema 5. Pruebas del software: Técnicas y Estrategias.

El propósito de probar un programa es encontrar herrare humanum est

Tema 5. Pruebas del software: Técnicas y Estrategias.

Tema 5. Pruebas del software: Técnicas y

Tema 5. Pruebas del software: Técnicas y Estrategias.

Tema 5. Pruebas del software: Técnicas y Estrategias.

Tema 5. Pruebas del software: Técnicas y Estrategias.

Código de Código de Código de  Pruebas incrementales frente a

Tema 5. Pruebas del software: Técnicas y Estrategias.

Tema 5. Pruebas del software: Técnicas y Estrategias.

Tema 5. Pruebas del software: Técnicas y Estrategias.

También podría gustarte

Código de Código de Código de Pruebas incrementales frente a