PRINCIPIOS BÁSICOS DE CONSTRUCCIÓN DE SOFTWARE Y TRATAMIENTO DE EXCEPCIONES

Ph.D. Franklin Parrales 1
13/05/2021
Construcción de Software Carrera de Software
PRINCIPIOS BÁSICOS DE
CONSTRUCCIÓN DE
SOFTWARE Y TRATAMIENTO
DE EXCEPCIONES
Unidad 1B
Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo
para uso de los cursos de Construcción de Software

13/05/2021
Objetivo general de la Unidad 1
Identificar los principios básicos del desarrollo de software
y del tratamiento de excepciones en el desarrollo mediante
la aplicación de técnicas usadas en la industria para
construir software seguro.

13/05/2021
Unidad 1: Principios básicos de construcción de
software y tratamiento de excepciones
• Principios básicos del desarrollo de software
• Refactorización del código
• Detección de errores
• Tolerancia a fallos y tratamiento de excepciones
Unidad 1B

13/05/2021

13/05/2021
Referencias
• Myers, et al. (2004),
“The Art of Software
Testing”, Wiley, Estados
Unidos, 2004, ISBN: 0-
471-46912-2

13/05/2021
– Pruebas de software: revisión de tipos de prueba
– Pruebas unitarias
– Depuración del software: importancia, buenas
prácticas, herramientas
– Plan de pruebas y documentación de las pruebas

13/05/2021
Pruebas de software: revisión de tipos
de prueba
1. Introducción a las pruebas
2. Tipos de prueba
3. Niveles de prueba
4. Técnicas de pruebas
5. Diseño de Casos de Prueba
6. Automatización de las pruebas

13/05/2021
Temario
FASES DE LA PRUEBA
• Diseño de las pruebas (¿técnicas?)
• Generación de casos de prueba (¿datos de prueba?)
• Definición del procedimiento de la prueba (¿cómo, donde?)
• Ejecución de la prueba
• Informe de la prueba (¿resultados?)
TÉCNICAS DE PRUEBA
• Pruebas estructurales o de Caja Blanca.
• Pruebas funcionales o de caja negra.
NIVELES DE PRUEBA
• Pruebas unitarias.
• Pruebas de integración.
• Pruebas de sistema.
• Pruebas de aceptación.
• Pruebas de regresión.
Aspectos que
trataremos hoy

13/05/2021
Introducción a las pruebas
Objetivo: repasar las ideas principales
sobre las pruebas del software.

13/05/2021
Bugs y testing
• Confiabilidad (reliability): Probabilidad de que un sistema
de software no cause fallas en condiciones específicas.
– Medido por tiempo de actividad, MTTF (tiempo medio hasta la
falla), datos de fallas.
• Bugs son inevitables en cualquier sistema de software
complejo.
– Estimaciones de la industria: 10-50 errores por 1000 líneas de
código.
– Un error puede ser visible o puede esconderse en su código
hasta mucho más tarde.
• testing: Un intento sistemático de revelar errores.
– Prueba fallida: se demostró un error.
– Prueba aprobada: no se encontró ningún error (para esta
situación particular).

13/05/2021
Ariane 5.
Lanzado por primera vez el 4 de junio de
1996.
Motivo:
Fallo software. La programación no se había probado lo suficiente.
Ariane 5.
36.7 segundos después explotó.
En concreto el fallo fue un trozo de software que habían reutilizado
del Ariane 4, pero que no lo habían probado en el Ariane 5

13/05/2021
Sistemas software:
• Mayor tamaño.
• Mayor complejidad.
• Menor tiempo de desarrollo.
• Mayor calidad.
Pruebas:
• Más importancia y
protagonismo día a día.
• Garantizan la calidad del
software.
• Garantizan la satisfacción
de los requisitos.
• Ahorran tiempo y recurso en
el desarrollo.
• Su objetivo: localizar, para
subsanarlas, el mayor
número de deficiencias lo
antes posible.
Un reto a la
Ingeniería de
Software.

13/05/2021
Verificación dinámica del
comportamiento del
software a partir de un
conjunto finito de casos de
prueba.
Definición de prueba:
Para probar un software
necesitamos ejecutar ese
software.

13/05/2021
comportamiento del software a
partir de un conjunto finito de
casos de prueba.
Definición de prueba:
Dos conceptos muy
relacionados:
Validación: proceso de evaluar un
sistema o componente durante o al
final del proceso de desarrollo para
determinar si satisface los requisitos
especificados.
1
2
Verificación: proceso de evaluar
un sistema o componente para
determinar si los productos de
una determinada fase satisfacen
las condiciones impuestas al
comienzo de la fase.

13/05/2021
comportamiento del
software a partir de un
conjunto finito de casos de
prueba.
Para probar un programa
tenemos que ejecutarlo.
La prueba tiene un límite.
No vale ejecutar el
programa de cualquier
manera.

13/05/2021
Pruebas de Programas
• Pruebas de programas es el proceso de
ejecutar programas con el propósito de
encontrar errores
• Se puede mostrar la presencia de un error
pero no la ausencia [Dijkstra]
• Debería ser visto como el último recurso
para encontrar errores

13/05/2021
Configurar partida:
 El sistema muestra un formulario con todos los
valores configurables.
 El jugador introduce modifica los valores.
 El sistema comprueba la validez de los valores y
vuelve a la pantalla principal.
Acciones
Configuración:
Intentos = 5
Valores = 8
Repetidos = cierto
Valores del prueba Resultado
Una prueba consta, al
menos, de tres
elementos:

13/05/2021
¿Funciona el teléfono?.
Valores de
prueba
Acciones Resultado esperado
123-45-67-89 1. Descolgar auricular.
2. Marcar número de Pepote.
3. Esperar contestación.
(Pepote): “Digameee”.
Veamos un ejemplo sencillo:

13/05/2021
¿Me está bien esta camisa?
Valores de
prueba
Acciones Resultado esperado
Mi cuerpo. 1. Ponerme la camisa.
2. Abrochármela.
3. Moverme un poco.
4. Mirarme al espejo.
Cuidado con la etiqueta o con arrugarla
por si hay que devolverla
Elegancia y confort.
Veamos otro ejemplo sencillo:

13/05/2021
public int suma(int a, int b)
{
return a + b;
}
¿Qué casos de prueba podemos escribir?.
Valores de
prueba
Acciones Resultado
esperado
??? Suma(a, b) ???
Los casos de prueba son
finitos (y cuantos menos,
mejor).

13/05/2021
public int suma(int a, int b)
{
return a + b;
}
¿Qué casos de prueba podemos escribir?.
Valores de
prueba
Acciones Resultado
esperado
0, 0 Suma(a, b) 0
0, b = no 0 Suma(a, b) b
3, 4 Suma(a, b) 7
-2, -8 Suma(a, b) -10
-3, 6 Suma(a, b) 3
Integer.MAX_V
ALUE, 6
Suma(a, b) -2147483643
Y algunas permutaciones más.

13/05/2021
Fase de pruebas
• La fase de pruebas se realiza
una vez integrado cada uno
de los módulos del sistema.
• La fase de pruebas se realiza
de distintas formas tratando
de encontrar la mayoría de
los errores que se encuentran
de manera inherente en el
software.

13/05/2021
Dificultades de las pruebas
• Percepción de algunos desarrolladores y
administradores:
– Las pruebas se consideran un trabajo de novatos.
– Asignado a los miembros del equipo con menos
experiencia.
– Hecho como una ocurrencia tardía (si es que se hace).
• "Mi código es bueno; no tendrá errores. No necesito probarlo".
• "Encontraré los errores ejecutando el programa cliente".
• Limitaciones de lo que las pruebas pueden mostrarle:
– Es imposible probar completamente un sistema.
– Las pruebas no siempre revelan directamente los errores
reales en el código.
– Las pruebas no prueban la ausencia de errores en el
software.

13/05/2021
En conclusión
• Probar es ejecutar casos de prueba.
• Caso de prueba:
entrada + acciones + salida
salida obtenida == salida esperada
salida obtenida != salida esperada
• ¿Un programa que pasa todos sus casos
de prueba es un programa sin errores?.

13/05/2021
En conclusión
No
Las pruebas sólo pueden encontrar
los errores que buscan.
Por esto es tan importante un buen
diseño de pruebas->Plan de pruebas

13/05/2021
de prueba
2. Tipos de prueba

13/05/2021
Tipos de prueba
• Existen muchos tipos de pruebas dependiendo
de la labor y características de cada una de
ellas.
– Pruebas Alfa: se realizan por el usuario final en un
ambiente controlado.
– Pruebas Beta: se realizan por el usuario sin controlar
el ambiente.

13/05/2021
Tipos de prueba
– Pruebas de caja blanca también llamadas
transparentes se concentran en lo que es el
código fuente.

13/05/2021
Tipos de prueba
– Pruebas de segmentos: No se pueden tener
pruebas que abarquen el 100% de los casos
de uso. Se deben realizar pruebas de
segmentos.
• Las pruebas de segmentos son bloques de
instrucciones.
• Es recomendable realizar pruebas de trazado
(assert) para visualizar en donde ocurren los
errores.
• Se recomienda probar lo antes posible cualquier
fragmento de código.

13/05/2021
Tipos de prueba
– Pruebas de caja negra: están orientadas a lo que se
espera realicen los componentes modulares del
sistema.
• Son pruebas funcionales y no interesa como se
realizan las cosas sólo que el resultado obtenido
sea el correcto.
• Se recomienda que sean los usuarios quienes las
realicen.

13/05/2021
Tipos de prueba
– Pruebas de estrés se encargan de observar
el rendimiento de la aplicación sobre cargas
demandantes de trabajo: grandes volúmenes
de datos con poco espacio en disco, 90% de
uso de CPU, múltiples conexiones, etc.

13/05/2021
Tipos de prueba
• Existen otros tipos de prueba como:
– Pruebas de unidad: se encargan de un
módulo de software en particular.
– Pruebas de Integración: son pruebas que se
realizan con dos o más módulos trabajando
en conjunto.
– Pruebas de aceptación: están más
involucradas en el concepto en sí que en el
desarrollo.

13/05/2021
Recuerde que…
• Las pruebas ayudan al aseguramiento de
calidad pero no garantizan que un
software esté 100% libre de errores.

13/05/2021
Pruebas generales de software
Prueba Unitaria
• Ejecutar cada módulo
• Particionar, definir los casos de prueba.
• Comparar el resultado
Prueba de Regresión
• Identificar errores introducidos por la
combinación de programas probados
unitariamente.
• Determina cómo la base de datos de
prueba será cargada
• Utilizar la técnica down-top.
Pruebas de Humo
• Detectar los errores en realeases
tempranos y de manera fácil
• su objetivo es probar el sistema
constantemente buscando que saque
“humo”
• Realizar una integración de todo el sistema
cada cierto periodo (se recomienda un día,
máximo una semana)
Pruebas del Sistema
• Asegurar la apropiada navegación dentro
del sistema, ingreso de datos,
procesamiento y recuperación.
• deben enfocarse en requisitos que puedan
ser tomados directamente de casos de uso
y reglas y funciones de negocios
• Ejecute cada caso de uso, flujo básico o
función utilizando datos válidos e inválidos

13/05/2021
Pruebas de Stress
• Verificar que el sistema funciona
apropiadamente y sin errores
• Las pruebas de stress se proponen encontrar
errores debidos a recursos bajos o completitud
de recursos
• Use los scripts utilizados en las pruebas de
desempeño
Pruebas de desempeño
• Validar el tiempo de respuesta para las
transacciones
• Miden tiempos de respuesta, índices de
procesamiento de transacciones y otros
requisitos sensibles al tiempo
• Modifique archivos de datos (para incrementar
el número de transacciones) o los scripts para
incrementar el número de veces que ocurre
cada transacción
Pruebas de carga
• Validar el tiempo de respuesta para las
transacciones
• Miden tiempos de respuesta, índices de
procesamiento de transacciones y otros
requisitos sensibles al tiempo
• Modifique archivos de datos (para incrementar
el número de transacciones) o los scripts para
incrementar el número de veces que ocurre
cada transacción
Pruebas de volumen
• Verificar el tamaño de la BD, el equipo si es
suficiente etc.
• Las pruebas de volumen hacen referencia a
grandes cantidades de datos para determinar
los límites en que se causa que el Sistema
falle
• Deben usarse múltiples clientes, ya sea
corriendo las mismas pruebas o pruebas
complementarias para producir el peor caso
de volumen

13/05/2021
Pruebas de Recuperación y Tolerancia a fallas
• Verificar que los procesos de recuperación
(manual o automática) restauran
apropiadamente la Base de datos
• Estas pruebas aseguran que una aplicación o
sistema se recupere de una variedad de
anomalías de hardware, software o red con
pérdidas de datos o fallas de integridad.
• Se deben utilizar las pruebas creadas para la
Funcionalidad del sistema y Procesos de
Negocios para crear una serie de
transacciones
Prueba de Múltiples Sitios
• Detectar fallas en configuraciones y
comunicaciones de datos entre múltiples sitios
• El propósito de esta prueba es evaluar el
correcto funcionamiento del sistema o
subsistema en múltiples instalaciones.
• Consistencia, empaquetamiento,
sincronización
Prueba de Compatibilidad y Conversión
• Buscar problemas de compatibilidad y
conversión en los sistemas
• El propósito es demostrar que los objetivos de
compatibilidad no han sido logrados y que los
procedimientos de conversión no funcionan.
• Compatibilidad entre programas y Conversión
de datos
Pruebas de Integridad de Datos y Base de
Datos
• Asegurar que los métodos de acceso y
procesos funcionan adecuadamente y sin
ocasionar corrupción de datos.
• La Base de datos y los procesos de Base de
datos deben ser probados como sistemas
separados del proyecto
• Invoque cada método de acceso y proceso de
la Base de datos, utilizando en cada uno datos
válidos e inválidos. Analizar la BD.

13/05/2021
Pruebas de Seguridad y Control de Acceso
• Nivel de seguridad de la aplicación: Verifica
que un actor solo pueda acceder a las
funciones y datos que su usuario tiene
permitido
• Seguridad del sistema, incluyendo acceso a
datos o Funciones de negocios e incluyendo
accesos remotos
• Funciones / Seguridad de Datos: Identificar
cada tipo de usuario y las funciones y datos a
los que se debe autorizar.
Pruebas del Ciclo del Negocio
• Asegurar que el sistema funciona de acuerdo
con el modelo de negocios emulando todos
los eventos en el tiempo y en función del
tiempo.
• Deberían emular las actividades ejecutadas en
el a través del tiempo. Debería identificarse un
periodo, como por ejemplo un año, y las
transacciones y actividades que podrían
ocurrir durante un periodo
• Ejecute cada caso de uso, flujo básico o
función utilizando datos válidos e inválidos…
Pruebas de GUI
• La navegación, Los objetos de la ventana y
características, tales como menús, medidas,
posiciones, estados y focos
• La prueba de interfaz de usuario verifica la
interacción del usuario con el software
• Pruebas de crear / modificar cada ventana
para verificar la adecuada navegación y
estado de los objetos.
Pruebas de Configuración
• Validar y verificar que el cliente del sistema
funciona apropiadamente en las estaciones de
trabajo recomendadas.
• Estas pruebas verifican la operación del
sistema en diferentes configuraciones de
hardware y software
• Incluya la apertura o cierre de varias
aplicaciones Microsoft, como Excel y Word (o
algún tipo de software similar a la que se está
probando)

13/05/2021
Prueba de Estilo
• Comprobar que la aplicación sigue los
estándares de estilo propios del cliente.
• Se entienden como tales el formato de las
ventanas, colores corporativos, tipos de letra
etc.
• Se realiza una navegación por la aplicación
verificando si se cumplen con los estándares
de GUI del cliente.
Prueba de Aceptación
• Determinación por parte del cliente de la
aceptación o rechazo del sistema
desarrollado.
• La prueba de aceptación es ejecutada antes
de que la aplicación sea instalada dentro de
un ambiente de producción
• Realización de los documentos de planes de
prueba de aceptación y especificación de los
mismos, basados en los criterios de
aceptación del cliente.
Prueba de Instalación
• Verificar y validar que el sistema se instala
apropiadamente en cada cliente, bajo las
siguientes condiciones: Instalaciones nuevas y
actualizaciones
• El primero es asegurar que el sistema puede
ser instalado en todas las configuraciones
posibles .El segundo propósito verificar que,
una vez instalado, el sistema opera
correctamente.
• Diseñar scripts para validar las condiciones de
la máquina a instalar.
Prueba de Documentación y Procedimiento
• Evaluar la documentación del usuario
• Evaluar la exactitud y claridad de la
documentación del usuario y para determinar
si el manual de procedimientos trabajará
correctamente como una parte integral del
sistema.
• Revisar la documentación del proyecto contra
las funcionalidades del sistema y su
configuración física.

13/05/2021
Pruebas Funcionales
• Se asegura la trabajo apropiado de los
requisitos funcionales, incluyendo la
navegación, entrada de datos, procesamiento
y obtención de resultados
• Las pruebas Funcionales deben enfocarse en
los requisitos funcionales Diseñar scripts para
validar las condiciones de la máquina a
instalar
• Que los resultados esperados ocurran cuando
se usen datos válidos.
Prueba de Usabilidad
• Determinar la usabilidad del sistema.
• Determina cuán bien el usuario podrá usar y
entender la aplicación. Identifica las áreas de
diseño que hacen al sistema de difícil uso para
el usuario.
• Verificar que la aplicación no presenta los
siguientes problemas de usabilidad típicos:
sistema es demasiado complejo ,
recuperación de errores es pobre ,
procedimientos no son simples ni obvios
Prueba de Campo
• Correr el sistema en el ambiente real para
encontrar errores y validar el producto contra
sus especificaciones originales.
• Realizar un subconjunto válido de pruebas de
sistema.
• Determinar que pruebas de sistema serán
corridas para validar el sistema en producción.
Pruebas Alfa
• Prueba de aceptación para detectar errores en
el sistema bajo un ambiente controlado.
• La verificación involucra la ejecución de partes
o todo del sistema en ambientes simulados,
con el fin de encontrar errores.
• Se llevan a cabo en el lugar en donde fue
desarrollado el sistema

13/05/2021
Pruebas Beta
• Realizar la validación del sistema por parte del
usuario.
• Prueba de aceptación donde La validación (o
pruebas beta) involucra el uso del software en
un ambiente real.
• Se selecciona un grupo de usuarios que
ponen a trabajar el sistema en un ambiente
real. Usan el sistema en sus actividades
cotidianas, procesan transacciones y
producen salidas normales del sistema

13/05/2021
de prueba
2. Tipos de prueba

13/05/2021
Repaso: Definiciones
• Requerimientos: “¿Qué hace el producto?”
– Expresado sin ambigüedad y de forma verificable
• Arquitectura: “¿Cómo está hecho?” (descripto en el
nivel de abstracción más alto)
– Ej.: Diagrama de bloques; flujo de datos entre estos
• Diseño Detallado: “¿Cómo está hecho?” (descripto en
un nivel de abstracción intermedio)
– Ej.: Especificación de las interfases; descripción detallada
de la operación
• Implementación: “¿Cómo está hecho?” (descripto en
nivel de abstracción bajo)
– Ej.: Código; esquemático; dibujo del circuito impreso
• Integración de módulos diseñados separadamente
– Ej.: Hardware y software
• Verificación: “¿Funciona como debe?”

13/05/2021
Repaso: Ciclo de Vida Tipo “V”
• Es una evolución del
anterior. En este, la
verificación se desglosa
en etapas de nivel de
abstracción creciente.
Análisis y
Definición de los
Requerimientos
Diseño de la
Arquitectura del
Sistema
Diseño Detallado Testeo de cada
unidad (unit test)
Instalación,
Operación y
Mantenimiento
Prueba de
Aceptación
Prueba de
Integración
Implementación de
cada unidad
Plan de Pruebas
para Cada Unidad
Plan de Pruebas
de Integración
Plan de Pruebas de
Aceptación
❑ En cada etapa de
diseño se crea un
plan de pruebas,
que es el que guía la
etapa de validación
que le corresponde.

13/05/2021
Niveles de Pruebas
• Prueba de unidad (unit testing)
– Se testean unidades individuales de código (software o
hardware) separadamente.
• …por medio de sus interfaces, en un lenguaje de programación
(C, etc.)
– Es el primer paso de un enfoque bottom-up de testeo,
como el que propone el modelo V.
• Prueba de integración (integration testing)
– Se testean los módulos anteriores en conjunto, o sea,
una vez “conectados” entre sí.
• …también por medio de sus interfaces en C u otro lenguaje.
• Prueba de aceptación (acceptance testing o system
testing)
– Se testea que el conjunto cumpla los requerimientos.
– Se lo hace por medio de las interfaces del producto final
• Interfaces al usuario, etc.

13/05/2021
Niveles de Pruebas
• También se pueden aplicar pruebas
aleatorias. Lo ideal es poder utilizar un
framework de pruebas.

13/05/2021
Niveles de prueba
P
r
o
c
e
s
o
d
e
d
e
s
a
r
r
o
l
l
o
P
r
o
c
e
s
o
d
e
p
r
u
e
b
a
Pruebas
unitárias
Pruebas de
integración
Pruebas de
sistema
Pruebas de
aceptación
Componentes
aislados
Verifican
Interacción
entre
componentes
Verifican
Requisitos del
sistema
Necesidades
de los
usuarios
Verifican
Verifican
Pruebas de
implantación
Paso a
producción
Verifican

13/05/2021
Pruebas unitarias
Cuando: Durante la
construcción del sistema.
Objetivo: Prueban el
diseño y el
comportamiento de cada
uno de los componentes
una vez construidos.
Cobertura
CruiseControl
XUnit
TestNG
Cactus
jMock
EasyMock
muJava
CoView
Herramientas:

13/05/2021
Pruebas unitarias
Técnicas:
– Análisis de caminos.
– Partición de categorías.
– Mutaciones.
– Algoritmos genéricos.
En general, han sido muy
estudiadas.

13/05/2021
Pruebas de integración
Herramientas:
Las mismas, vamos
sustituyendo los mocks
por las clases reales y, si
es necesario, escribiendo
más casos de prueba.
Cuando: Durante la
construcción del sistema
Objetivo: Comprueban la
correcta unión de los
componentes entre sí a través
de sus interfaces, y si cumplen
con la funcionalidad
establecida

13/05/2021
Pruebas de integración
Técnicas:
Arriba abajo:
El primer componente que se prueba es el primero
de la jerarquía (A). Una de las ventajas es que las
interfaces entre los distintos componentes se
prueban en una fase temprana y con frecuencia.
Abajo a arriba:
Se prueban primero los componentes de más bajo
nivel (E, F) Este tipo de enfoque permite un
desarrollo más en paralelo, pero presenta mayores
dificultades a la hora de planificar y de gestionar.

13/05/2021
Pruebas de sistema
Herramientas:
Cuando: Durante la
construcción del sistema
(partes completas).
Objetivo: Prueban a fondo el
sistema, comprobando su
funcionalidad e integridad
globalmente, en un entorno lo
más parecido posible al
entorno final de producción.
Herramientas:
Técnicas: probar el sistema como
lo hará el usuario final.
JMeter
The Grinch
Avignon
JWebTest Selenium
Abbot
Marathon
HttpUnit
GUItar

13/05/2021
Pruebas de implantación
Herramientas:
Cuando: Durante la implantación
en el entrono de producción.
.
Objetivo: Comprueban el correcto
funcionamiento del sistema dentro
del entorno real de producción
(rendimiento, copias de seguridad,
etc.).
Herramientas:
Las mismas. Las pruebas se vuelven
a ejecutar en el entorno real de
producción y se añaden nuevas
pruebas.
.

13/05/2021
Pruebas de aceptación
Herramientas:
Cuando: Después de la
implantación en el entorno de
producción.
Objetivo: Verifican que el
sistema cumple con todos los
requisitos indicados y permite
que los usuarios del sistema den
el visto bueno definitivo.
Herramientas:
Las mismas. Las pruebas se vuelven
a ejecutar en el entorno real de
producción y se añaden nuevas
pruebas.

13/05/2021
Pruebas de regresión
Cuando: Durante el
mantenimiento del sistema.
Objetivo: Comprobar que los
cambios sobre un componente
de un sistema de información,
no introducen un
comportamiento no deseado o
errores adicionales en otros
componentes no modificados
Herramientas:
Las mismas.

13/05/2021
Características de una buena
prueba
• Ha de tener una alta probabilidad de encontrar un fallo.
Cuanto más, mejor.
• No debe ser redundante. Si ya funciona, no lo
probamos más.
• Debe ser la “mejor de la cosecha”. Si tenemos donde
elegir, elegimos la mejor.
• No debería ser ni demasiado sencilla ni demasiado
compleja. Si es muy sencilla no aporta nada, si es
muy compleja a lo mejor no sabemos lo que ha
fallado.

13/05/2021
de prueba
2. Tipos de prueba

13/05/2021
Pruebas de caja negra, gris y blanca
Caja negra
… requirimientos
Salida real
comparada
con la
salida requerida
Caja blanca
Caja gris
… requirimientos &
elementos claves de
diseño
Entrada determinada por.. Resultado
…elementos
del diseño
Confirmación del
comportamiento
esperado
Como para
las pruebas de
caja negra y
blanca

13/05/2021
Técnicas de Prueba
• Caja blanca o pruebas estructurales
– El conocimiento del diseño interno del
software se usa para desarrollar los casos de
pruebas
• Caja negra o pruebas funcionales
– Los casos de prueba son diseñados basados
sólo en la especificación externa del software
• Pruebas basadas en escenarios o casos
de uso
– Actuar como un usuario final y crear
escenarios reales para detectar errores

13/05/2021
Técnicas de Prueba (2)
• Pruebas Selectivas
– Generar más casos de prueba para las
funciones o componentes que son más
usados
– Probar más rigurosamente las funciones o
componentes más críticos
– Generar mas casos de prueba para las
funciones o componentes más complejos

13/05/2021
de prueba
2. Tipos de prueba

13/05/2021
Conceptos
• Espacio de Prueba
– Conjunto de todos los posibles casos de
Prueba
• Pruebas de subdominios
– Subconjuntos del espacio de Prueba
• Línea de Prueba (Test Suite)
– Conjunto de casos de prueba que serán
ejecutados en una fase

13/05/2021
Conceptos (2)
• Testbed/Test Harness
– Software adicional desarrollado para soportar
la ejecución de los casos de prueba
• Prueba de Cubrimiento
– Grado en el cual los casos de prueba “pasan”
por el código siendo probado

13/05/2021
Posibilidades de entradas para las pruebas
0%
25%
principal
$100 $100M
1%
20%
Infinidad de valores ilegales:
elija una muestra finita.
Infinidad de valores legales:
elija una muestra finita.
estimación de
inflación
tasa de
interés

13/05/2021
Pruebas: particiones y límites de entrada
tasa de
interés
0%
25%
principal
$100 $100M
estimación de
inflación
límites (bordes)
1%
20%
Particiones
equivalentes
Una
región
ilegal
Rango de
entradas válidas

13/05/2021
Rangos de prueba: casos elementales
1. Dentro del rango
2. En los límites
del rango
3. Fuera del rango
(“illegal”)
rango

13/05/2021
Estructura del Espacio de Pruebas
• Taxonomía de los Casos de Prueba
– Pruebas Funcionales: considerar solamente entradas
válidas al sistema y condiciones normales de
operación.
– Pruebas de Robustez: considerar datos de entrada
inválidos, secuencias invalidas de
comandos/acciones, etc.
– Pruebas de Frontera: considerar valores/tamaños
mínimos y máximos para datos de entrada, carga del
sistema mínima y máxima, etc.
– Pruebas de tolerancia a fallas: considerar
condiciones anormales de operación, fallas hardware
y software de la plataforma computacional sobre la
que funciona el software en prueba.

13/05/2021
Diseño de los Casos de Prueba
• Hacer una lista de los propósitos de
Prueba
– Usar la taxonomía de los casos de prueba
como guía

13/05/2021
Diseño de los Casos de Prueba (2)
• Por cada propósito de Prueba, hacer una
lista de casos de prueba
– Construir una versión preliminar de la lista de
casos de prueba a partir de los escenarios típicos
relacionados con el propósito de prueba
– Enriquecer la lista de casos de prueba,
analizando las posibles variaciones o casos
especiales de los escenarios considerados
– Complementar la lista de casos de prueba,
analizando posibles casos que puedan revelar
errores, usando como guía la siguiente lista de
chequeo:

13/05/2021
– Cuales son los errores típicos encontrados en
productos similares probados en el pasado, y que
casos de prueba se usaron para revelarlos?
– En pruebas del sistema y pruebas de aceptación,
qué casos es probable que los desarrolladores
hubieran pasado por alto (desde el punto de vista
del experto del negocio o dominio de aplicación)?
– En pruebas de unidad y pruebas de integración,
qué características complejas del diseño
pudieron haber sido implementadas de forma
incorrecta?

13/05/2021
– En pruebas del sistema y pruebas de
aceptación, qué aspectos complejos acerca
de los requerimientos pudieron haber sido
mal interpretados por los desarrolladores?
– Qué casos triviales pudieran haber sido no
tenidos en cuenta en la implementación?

13/05/2021
• Para cada caso de prueba, especificar los
pasos para realizar la prueba y los
criterios de aceptación de la prueba, tal
como se indica en el formato:

13/05/2021
• Caso de uso
– Procedimiento
• Criterios de aceptación
– Procedimiento
• Criterios de aceptación
– ...
• Caso de uso
– ...
• ...

13/05/2021
• Para cada caso de prueba se debe
especificar
– Instrucciones de prueba: lista de pasos a seguir
por los usuarios encargados de ejecutar la
prueba.
– Criterios de aceptación: lista de condiciones
(predicados) que deben satisfacerse para
determinar el éxito de la prueba, incluyendo
restricciones sobre los datos de salida
esperados, y condiciones que deben cumplirse
en el estado interno del sistema (ej. valores de
algunas tablas) después de ejecutar el caso de
prueba.

13/05/2021
de prueba
2. Tipos de prueba

13/05/2021
Automatización de las pruebas
“No sirven para nada”
“Engaño”
“Pérdida de tiempo”
“Descartadas al primer cambio”
“Imposibles de mantener”
“Moda”
¿Por qué?.
Algunas palabras que hemos escuchado hablando de pruebas.

13/05/2021
Las pruebas son polémicas:
– No son parte de la solución.
– No se las entregamos a nuestros clientes.
– Incluso pueden darles a nuestros clientes una
mala impresión.
– Nuestros clientes no nos las pagan.
– Difíciles de mantener.
Sin embargo, las pruebas son
imprescindibles.
La automatización nos permite reducir costes.

13/05/2021
¿Qué significa automatizar?.
¿Qué podemos automatizar?.
En este caso concreto: realizar de manera
automática mediante herramientas software.
Diseño de las pruebas
Codificación de las pruebas
Ejecución de las pruebas
Evaluación de resultados
Lo más habitual, muchas
técnicas y herramientas
Menos habitual, pocas
técnicas y herramientas.

13/05/2021
Ventajas de la automatización:
– Mayor rapidez de ejecución.
– Menos recursos.
– Evitamos pruebas obsoletas

13/05/2021
Inconvenientes:
– ¡Muy pocas herramientas!.
– Necesitan una “base” a menudo inexistente.
– Un conjunto pobre de pruebas.

13/05/2021
Cuando automatizar y cuando no
automatizar.
Bien Mal.
Gastamos más en la
automatización que en la
pruebas en sí.
No buscamos automatizarlo
absolutamente todo.
Tenemos modelos y
documentación del sistema.
Construimos el sistema
sobre la marcha.
Nosotros controlamos las
herramientas de prueba.
Las herramientas de prueba
nos controlan a nosotros.

13/05/2021

13/05/2021
Pruebas Unitarias
Cuando: Durante la
construcción del sistema.
Objetivo: Prueban el
diseño y el
comportamiento de cada
uno de los componentes
una vez construidos.
Cobertura
CruiseControl
XUnit
TestNG
Cactus
jMock
EasyMock
muJava
CoView
Herramientas:

13/05/2021
Pruebas Unitarias
• Descripción
– Su propósito es encontrar errores en la
lógica, datos o algoritmos en componentes o
subsistemas individuales
– Realizado por los desarrolladores del
componente
– Técnica de prueba: Caja blanca

13/05/2021
Pruebas Unitarias
• Guías para generar casos de prueba
– Tratar de detectar errores en los algoritmos y la
lógica
– Tratar de detectar errores en la manipulación de
las estructuras de datos
– Tratar de detectar errores en el llamado a otros
módulos
– Identificar todos los caminos posibles del módulo
y tratar de hacer casos de prueba que los cubran
– Tratar de detectar errores usando datos límites

13/05/2021
Pruebas Unitarias
• Busca errores en un subsistema de forma aislada.
– Generalmente, un "subsistema" significa una clase u objeto en
particular.
– La biblioteca de Java JUnit nos ayuda a realizar fácilmente
pruebas unitarias.
• La idea básica:
– Para una clase determinada Foo, cree otra clase FooTest
para probarla, que contenga varios métodos de "caso de
prueba" para ejecutar.
– Cada método busca resultados particulares y pasa / falla.
• JUnit proporciona comandos "assert" para ayudarnos a
escribir pruebas.
– La idea: coloque llamadas de aserción en sus métodos de
prueba para verificar las cosas que espera que sean ciertas.
Si no es así, la prueba fallará.

13/05/2021
JUnit y Eclipse
• Para agregar JUnit a un Proyecto en Eclipse, haga
click en:
– Project → Properties → Build Path → Libraries →
Add Library... → JUnit → JUnit 4 → Finish
• Para crear un caso de test:
– Clic derecho sobre un
paquete y escoja New → Test
Case
– o clic File → New →
JUnit Test Case
– Eclipse puede crear stubs de
pruebas de métodos para
usted.

13/05/2021
Ejecutando una prueba en Eclipse
• Haga clic derecho en Eclipse
Package Explorer; escoger:
Run As → JUnit Test
• La barra JUnit mostrará green si
el código pasa todas las pruebas,
red si alguna falla.
• El seguimiento de fallas (Failure
Trace) muestra qué pruebas
fallaron, si las hubo, y por qué.

13/05/2021
La anotación @test
import org.junit.*;
import static org.junit.Assert.*;
public class name {
...
@Test
public void name() { // a test case method
...
}
}
– Un método con @Test se marca como un caso de prueba JUnit.
• Todos los métodos @Test se ejecutan cuando JUnit ejecuta su
clase de prueba.
– La anotación @test le dice a la JVM que el siguiente
método es una prueba. Esta anotación es necesaria antes
de cada método de prueba.

13/05/2021
La anotación @test
• Usaremos una clase calculator para demostrar las
capacidades básicas de JUnit. Por ahora, nuestra clase
calculator se ve así:
public class Calculator {
float add(float a, float b) {
return a + b;
}
int divide(int a, int b) {
return a/b;
}
}
• Esta clase no hace nada especial, pero nos permitirá
realizar las pruebas. Según las convenciones de
nomenclatura, nace la clase CalculatorTest:
class CalculatorTest {
@Test
void additionTest() {
Calculator calc = new Calculator();
assertEquals(2, calc.add(1,1), "The output should be the sum of the two arguments");
}
}

13/05/2021
El método assertEquals()
• Este y todos los métodos de "aserción" funcionan
de manera similar:
– afirman (es decir, se aseguran) de que todo lo que
estamos comprobando es cierto.
– En este caso, estamos afirmando que los dos
argumentos que pasamos son iguales, en caso de
que no lo sean, la prueba fallará.
– Es muy importante entender que assertEquals()
realmente usa el método .equals() y no el operador
==.
– Hay un método JUnit separado llamado
assertSame() que usa == en lugar de .equals().

13/05/2021
Un ejemplo de Java
class Money {
private int fAmount;
private String fCurrency;
public Money(int amount, String currency) {
fAmount= amount;
fCurrency= currency;
}
public int amount() {
return fAmount;
}
public String currency() {
return fCurrency;
}
}
public Money add(Money m) {
return new Money(amount()+m.amount(), currency());
}

13/05/2021
Prueba unitaria add () con JUnit
La prueba unitaria MoneyTest prueba que la suma de
dos Moneys con la misma moneda contiene un valor que
es la suma de los valores de los dos Moneys
import org.junit.Test;
public class MoneyTest {
@Test public void simpleAdd() {
Money m12CHF= new Money(12, "CHF");
Money m14CHF= new Money(14, "CHF");
Money expected= new Money(26, "CHF");
Money observed= m12CHF.add(m14CHF);
assertTrue(expected.equals(observed));
}
}
Assertion: Returns True if parameter of
type Boolean evaluates to True
Calling the SUT
Method
Static import of Assertion package
(Older JUnit versions used inheritance)

13/05/2021
JUnit assertion methods
• A cada método también se le puede pasar una
cadena para mostrar si falla:
– Ej.: assertEquals("message", expected,
actual)
assertTrue(test) fails if the boolean test is false
assertFalse(test) fails if the boolean test is true
assertEquals(expected, actual) fails if the values are not equal
assertSame(expected, actual) fails if the values are not the same (by ==)
assertNotSame(expected, actual) fails if the values are the same (by ==)
assertNull(value) fails if the given value is not null
assertNotNull(value) fails if the given value is null
fail() causes current test to immediately fail

13/05/2021
ArrayIntList JUnit test
import org.junit.*;
public class TestArrayIntList {
@Test
public void testAddGet1() {
ArrayIntList list = new ArrayIntList();
list.add(42);
list.add(-3);
list.add(15);
assertEquals(42, list.get(0));
assertEquals(-3, list.get(1));
assertEquals(15, list.get(2));
}
@Test
public void testIsEmpty() {
assertTrue(list.isEmpty());
list.add(123);
assertFalse(list.isEmpty());
list.remove(0);
assertTrue(list.isEmpty());
}
...

13/05/2021
¿Qué esta mal aquí?
public class DateTest {
@Test
public void test1() {
Date d = new Date(2050, 2, 15);
d.addDays(4);
assertEquals(d.getYear(), 2050);
assertEquals(d.getMonth(), 2);
assertEquals(d.getDay(), 19);
}
@Test
Date d = new Date(2050, 2, 15);
d.addDays(14);
assertEquals(d.getYear(), 2050);
assertEquals(d.getMonth(), 3);
assertEquals(d.getDay(), 1);
}
}

13/05/2021
Assertions bien estructurados
@Test
Date d = new Date(2050, 2, 15);
d.addDays(4);
assertEquals(2050, d.getYear()); // el valor esperado
assertEquals(2, d.getMonth()); // debe aparecer
assertEquals(19, d.getDay()); // a la DERECHA
}
@Test
Date d = new Date(2050, 2, 15);
d.addDays(14);
assertEquals("year after +14 days", 2050, d.getYear());
assertEquals("month after +14 days", 3, d.getMonth());
assertEquals("day after +14 days", 1, d.getDay());
} // test cases should usually have messages explaining
} // what is being checked, for better failure output

13/05/2021
Objetos de respuesta esperados
@Test
Date d = new Date(2050, 2, 15);
d.addDays(4);
Date expected = new Date(2050, 2, 19);
assertEquals(expected, d); // use an expected answer
} // object to minimize tests
// (Date must have toString
@Test // and equals methods)
Date d = new Date(2050, 2, 15);
d.addDays(14);
assertEquals("date after +14 days", expected, d);
}
}

13/05/2021
Nombrando los casos de prueba
@Test
public void test_addDays_withinSameMonth_1() {
Date actual = new Date(2050, 2, 15);
actual.addDays(4);
assertEquals("date after +4 days", expected, actual);
}
// give test case methods really long descriptive names
@Test
public void test_addDays_wrapToNextMonth_2() {
actual.addDays(14);
assertEquals("date after +14 days", expected, actual);
}
// give descriptive names to expected/actual values
}

13/05/2021
@Test
public void test_addDays_addJustOneDay_1() {
actual.addDays(1);
assertEquals(
"should have gotten " + expected + "n" +
" but instead got " + actualn",
expected, actual);
}
...
}

13/05/2021
Buenos mensajes de retroalimentación
@Test
public void test_addDays_addJustOneDay_1() {
actual.addDays(1);
assertEquals("adding one day to 2050/2/15",
expected, actual);
}
...
}
// JUnit will already show
// the expected and actual
// values in its output;
//
// don't need to repeat them
// in the assertion message

13/05/2021
Tests con un límite de tiempo (timeout)
@Test(timeout = 5000)
public void name() { ... }
– El comportamiento del método anterior se considerará como
erroneo si no termina de ejecutarse dentro de 5000 ms
private static final int TIMEOUT = 2000;
...
@Test(timeout = TIMEOUT)
– Times out / fails after 2000 ms

13/05/2021
Tiempos de espera generalizados
@Test(timeout = DEFAULT_TIMEOUT)
public void test_addDays_withinSameMonth_1() {
Date d = new Date(2050, 2, 15);
d.addDays(4);
}
public void test_addDays_wrapToNextMonth_2() {
Date d = new Date(2050, 2, 15);
d.addDays(14);
}
// almost every test should have a timeout so it can't
// lead to an infinite loop; good to set a default, too
private static final int DEFAULT_TIMEOUT = 2000;
}

13/05/2021
Prueba de excepciones
@Test(expected = ExceptionType.class)
public void name() {
...
}
– Pasará la prueba si se lanza la excepción dada.
• Si no se lanza la excepción, la prueba falla.
• Use esto para probar los errores esperados.
@Test(expected = ArrayIndexOutOfBoundsException.class)
public void testBadIndex() {
list.get(4); // should fail
}

13/05/2021
Configuración y desmontaje
@Before
@After
– métodos para ejecutar antes / después de que se
llame a cada método de caso de prueba
@BeforeClass
public static void name() { ... }
@AfterClass
public static void name() { ... }
– métodos para ejecutar una vez antes / después de
que se ejecute toda la clase de prueba

13/05/2021
Consejos para las pruebas
• No puedes probar todas las posibles entradas,
valores de parámetros, etc.
– Por lo tanto, debe pensar en un conjunto limitado de
pruebas que probablemente expongan errores (bugs).
• Piense en casos límite
– positive; zero; negative numbers
– justo en el borde de una matriz o tamaño de colección
• Piense en casos vacíos y casos de error
– 0, -1, null; una empty list o array
• Pruebe combinaciones de comportamientos
– tal vez agregar generalmente funciona, pero falla después
de llamar a eliminar
– hacer múltiples llamadas; tal vez el tamaño falle solo la
segunda vez

13/05/2021
// test every day of the year
@Test(timeout = 10000)
public void tortureTest() {
Date date = new Date(2050, 1, 1);
int month = 1;
int day = 1;
for (int i = 1; i < 365; i++) {
date.addDays(1);
if (day < DAYS_PER_MONTH[month]) {day++;}
else {month++; day=1;}
assertEquals(new Date(2050, month, day), date);
}
}
private static final int[] DAYS_PER_MONTH = {
0, 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31
}; // Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
}

13/05/2021
Pruebas confiables
• Pruebe una cosa a la vez por método de prueba.
– 10 pruebas pequeñas son mucho mejores que 1 prueba
10 veces más grande.
• Cada método de prueba debe tener pocas (probablemente 1)
afirmaciones (asserts).
– Si afirmas muchas cosas, la primera que falla detiene la
prueba.
– No sabrá si fue una afirmación posterior la que ha fallado.
• Las pruebas deben evitar la lógica.
– Minimiza el uso de if/else, loops, switch, etc.
– Evita el try/catch
• Si se supone que debe lanzarse una excepción, use expected= ... si
no, deje que JUnit lo atrape (catch).
• Las pruebas de tortura están bien, pero solo además de las
pruebas simples.

13/05/2021
Aplastando la redundancia
public void addDays_withinSameMonth_1() {
addHelper(2050, 2, 15, +4, 2050, 2, 19);
}
public void addDays_wrapToNextMonth_2() {
addHelper(2050, 2, 15, +14, 2050, 3, 1);
}
// use lots of helpers to make actual tests extremely short
private void addHelper(int y1, int m1, int d1, int add,
int y2, int m2, int d2) {
Date act = new Date(y, m, d);
actual.addDays(add);
Date exp = new Date(y2, m2, d2);
assertEquals("after +" + add + " days", exp, act);
}
// can also use "parameterized tests" in some frameworks
...

13/05/2021
Ayudantes (helpers) flexibles
public void addDays_multipleCalls_wrapToNextMonth2x() {
Date d = addHelper(2050, 2, 15, +14, 2050, 3, 1);
addhelper(d, +32, 2050, 4, 2);
addhelper(d, +98, 2050, 7, 9);
}
// Helpers can box you in; hard to test many calls/combine.
// Create variations that allow better flexibility
private Date addHelper(int y1, int m1, int d1, int add,
Date date = new Date(y, m, d);
addHelper(date, add, y2, m2, d2);
return d;
}
private void addHelper(Date date, int add,
date.addDays(add);
Date expect = new Date(y2, m2, d2);
assertEquals("date after +" + add + " days", expect, d);
}
...

13/05/2021
Pruebas de regresión
• Regresión Cuando una característica que solía funcionar, ya
no funciona.
– Es probable que suceda cuando el código cambia y crece con el
tiempo.
– Una nueva función / corrección puede causar un nuevo error o
reintroducir un error antiguo.
• Pruebas de regresión: Volver a ejecutar pruebas unitarias
anteriores después de un cambio.
– A menudo se realiza mediante scripts durante las pruebas
automatizadas.
– Se utiliza para garantizar que los errores corregidos antiguos aún
se solucionen.
– Le da a su aplicación un nivel mínimo de funcionalidad de trabajo.
• Muchos productos tienen un conjunto de pruebas de registro
obligatorias que deben pasar antes de que se pueda agregar
el código a un repositorio de código fuente.

13/05/2021
Test-driven development
(Desarrollo impulsado por pruebas)
• Las pruebas unitarias se pueden escribir después,
durante o incluso antes de la codificación.
– test-driven development: Escribe pruebas, luego
escribe código para aprobarlas.
• Imagina que nos gustaría agregar un método
subtractWeeks para una clase Date, que
desplaza una fecha hacia atrás en el tiempo por el
número dado de semanas.
• Escriba código para probar este método antes de
que se haya escrito el código del comportamiento.
– Luego, una vez que implemente el método, ud. sabrá si
funciona.

13/05/2021
Tests y estructuras de datos
• ¿Necesita pasar muchos arrays? Usa array literals
public void exampleMethod(int[] values) { ... }
...
exampleMethod(new int[] {1, 2, 3, 4});
exampleMethod(new int[] {5, 6, 7});
• ¿Necesita un quick ArrayList? Pruebe Arrays.asList
List<Integer> list = Arrays.asList(7, 4, -2, 3, 9, 18);
• ¿Necesita un quick set, queue, etc.? Muchas colecciones
pueden tomar la forma de lista
Set<Integer> list = new HashSet<Integer>(
Arrays.asList(7, 4, -2, 9));

13/05/2021
Recordando: Arrays
• En Java, las matrices multidimensionales son en realidad matrices
de matrices. Estos, como era de esperar, se ven y actúan como
matrices multidimensionales regulares.
• Para declarar una variable de matriz multidimensional, especifique
cada índice adicional utilizando otro conjunto de corchetes. Por
ejemplo, lo siguiente declara una variable de matriz bidimensional
llamada twoDim. Esto creará una matriz del tamaño 2x3 en la
memoria.
int twoDim[][] = new int[2][3];
Valor del
elemento
índice del
elemento

13/05/2021
Recordando: Array literals
• El literal null utilizado para representar la ausencia de un objeto
también se puede utilizar para representar la ausencia de una
matriz. Por ejemplo:
String [] name = null;
• Además del literal null, Java también define una sintaxis especial
que le permite especificar valores de matriz literalmente en sus
programas. Esta sintaxis solo se puede utilizar cuando se declara
una variable de tipo matriz. Combina la creación del objeto de
matriz con la inicialización de los elementos de la matriz:
String[] daysOfWeek = {“Sunday”, “Monday”, “Tuesday”, “Wednesday”,
“Thursday”, “Friday”, “Saturday”};
– Esto crea una matriz que contiene el elemento de siete cadenas que
representan los días de la semana dentro de las llaves.
– Tenga en cuenta que no usamos la nueva palabra clave ni especificamos el tipo
de matriz en esta sintaxis literal de matriz. El tipo está implícito en la declaración
de variable de la que forma parte el inicializador.
– Además, la longitud de la matriz no se especifica explícitamente con esta
sintaxis; se determina implícitamente contando el número de elementos
enumerados entre las llaves.

13/05/2021
// shared Date object to test with (saves memory!!1)
private static Date DATE;
public void addDays_sameMonth() {
DATE = new Date(2050, 2, 15); // first test;
addhelper(DATE, +4, 2050, 2, 19); // DATE = 2/15 here
}
public void addDays_nextMonthWrap() { // second test;
addhelper(DATE, +10, 2050, 3, 1); // DATE = 2/19 here
}
public void addDays_multipleCalls() { // third test;
addDays_sameMonth(); // go back to 2/19;
addhelper(DATE, +1, 2050, 2, 20); // test two calls
addhelper(DATE, +1, 2050, 2, 21);
}
...
}

13/05/2021
Test case "smells"
• Las pruebas deben ser autónomas y no preocuparse entre
sí.
• "Smells" (bad things to avoid) in tests:
– Constrained test order: Test A must run before Test B.
(usually a misguided attempt to test order/flow)
– Tests call each other: Test A calls Test B's method
(calling a shared helper is OK, though)
– Mutable shared state: Tests A/B both use a shared
object.
(If A breaks it, what happens to B?)

13/05/2021
Test suites
• test suite: Una clase que ejecuta muchos JUnit tests.
– Una forma sencilla de ejecutar todas las pruebas de su aplicación a
la vez.
import org.junit.runner.*;
import org.junit.runners.*;
@RunWith(Suite.class)
@Suite.SuiteClasses({
TestCaseName.class,
TestCaseName.class,
...
TestCaseName.class,
})
public class name {}

13/05/2021
Test suite example
import org.junit.runner.*;
import org.junit.runners.*;
@RunWith(Suite.class)
@Suite.SuiteClasses({
WeekdayTest.class,
TimeTest.class,
CourseTest.class,
ScheduleTest.class,
CourseComparatorsTest.class
})
public class HW2Tests {}

13/05/2021
JUnit summary
• Tests need failure atomicity (ability to know exactly what
failed).
– Each test should have a clear, long, descriptive name.
– Assertions should always have clear messages to know what failed.
– Write many small tests, not one big test.
• Each test should have roughly just 1 assertion at its end.
• Always use a timeout parameter to every test.
• Test for expected errors / exceptions.
• Choose a descriptive assert method, not always assertTrue.
• Choose representative test cases from equivalent input
classes.
• Avoid complex logic in test methods if possible.
• Use helpers, @Before to reduce redundancy between tests.

13/05/2021

13/05/2021
Depuración del software
• Una vez identificado los errores en la fase de pruebas,
se procede a corregirlos. A esta fase se le llama
depuración.
• Depuración: Es la detección, corrección y eliminación
de errores de software.
• En la fase de depuración también se arreglan detalles
superficiales del software además de optimizar y mejorar
algunos procesos.
• El proceso de depuración
1. Estudio de los síntomas del error
2. Determinación de las causas
3. Corrección
4. Prueba.

13/05/2021
Depuración
• El tener un plan de pruebas ayuda a clarificar el
proceso de depuración.
• El plan de pruebas debe de estar mucho antes
de la construcción del software.
• Al realizar la depuración de un programa existe
la posibilidad de un 50% de cometer otro error.
• Es recomendable realizar pruebas de trazado
(assert) para visualizar en donde ocurren los
errores.
• Se recomienda probar lo antes posible cualquier
fragmento de código.

13/05/2021
Depuración
• La mayoría de los IDEs modernos
presentan frameworks para la depuración
desde el clásico step by step o step over
sobre cada uno de los módulos hasta la
realización de pruebas de unidad.
• Entre las más famosas destacan JUnit
para realizar pruebas de unidad en Java.

13/05/2021
Depurador (debugger)
• Un depurador es una herramienta que permite
intervenir durante la ejecución de un programa, para
saber cómo se está ejecutando.
• El depurador permite:
– Ejecutar paso a paso un programa (stepping).
– Establecer puntos de detención (breakpoints).
– Examinar el contenido de las variables y objetos.
– Conocer el encadenamiento de llamadas de
procedimientos.
– Retomar la ejecución hasta un nuevo punto de detención.
• En este curso usaran el depurador que trae
incorporado el IDE de su preferencia (Netbeans,
Eclipse, etc).

13/05/2021
Depuración por Inducción
• Se siguen los siguientes pasos:
1. Localizar los datos pertinentes
2. Organizar los datos
3. Estudiar las relaciones
4. Divisar las hipótesis
5. Probar las hipótesis
6. Corregir el error

13/05/2021
Depuración por Deducción
• Se siguen los siguientes pasos:
1. Enumerar las posibles causas
2. Usar procedimientos de eliminación
3. Refinar las hipótesis restantes
4. Probar las hipótesis restantes
5. Si no se pueden probar las hipótesis entonces
coleccionar más datos y repetir el proceso
6. En caso contrario corregir el error

13/05/2021
Preparar Casos
de Prueba
Ejecutar Casos
de Prueba
Seleccionar y Priorizar los
errores para corrección
Corregir
Congelar versión del
Sw para Pruebas
Errors
Detectados?
Version
Acceptada
NO
SI
Verificar Correcciones Congelar versión
corregida del Sw
Hacer Pruebas Totales o
parciales de Regresión
Proceso de Pruebas de Programas

13/05/2021
Proceso de Pruebas de Programas:
Depuración
Diagnosticar
Error
Planificar Cambios
Actualizar Diseño Arquitec.
Actualizar Diseño Detallado
Actualizar
código
Actualizar Requerimientos
Probar los
Cambios
Seleccionar casos de
prueba para probar
los cambios
Selecionar casos de
Prueba para Pruebas de
Regresión
Pruebas de Regresión
?

13/05/2021
Depuración manual
• Cuando no se dispone de un depurador, se debe recurrir a la
depuración manual. Esta consiste en preparar el programa
para poder conocer como se está ejecutando el programa.
• La técnica más usual de depuración de programas consiste
en colocar println's en puntos estratégicos del programa para
desplegar el contenido de las variables.
• Siga las siguientes recomendaciones para establecer estos
puntos estratégicos:
– Dentro de un while, siempre coloque algún println que
permita detectar cuando cayó en un ciclo infinito su programa
(un loop). Despliegue el valor de contadores, datos leídos de un
archivo, acumuladores, etc.
– Al inicio de una función o procedimiento, despliegue el valor de
los parámetros recibidos y al retornar despliegue el valor
retornado (mediante return).
– En un if, despliegue cuál de las ramas se tomó: la que
corresponde a la condición verdadera o el else.

13/05/2021
Depuración manual
• Para que resulte más fácil la depuración, comience ejecutando su
programa con poquísimos datos. Nunca olvide, incluir datos que
representen las condiciones de borde del programa. Por ejemplo:
n=0, el archivo esta vacío, etc.
• La biblioteca del curso incluye mecanismos para poder grabar
todos los mensajes que aparecen en la pantalla. Para hacer
esto, utilice la opción -l al ejecutar su programa: java Run -l
MiPrograma
• Su programa se ejecutará igual que antes, pero además creará un
archivo de nombre console.log que contiene todos los mensajes
que aparecieron en pantalla durante la ejecución del programa.
Esto resulta muy útil, pues las 24 líneas de la pantalla se hacen
escasas con tanto despliegue con println.
• Cuando Ud. estime que su programa funciona adecuadamente,
comente los println que introdujo para efectos de depuración (es
decir agregue // para transformalos en comentarios). No los borre,
porque más tarde podría darse cuenta que su programa todavía no
funciona completamente como debería.

13/05/2021

13/05/2021
Motivación
Toda actividad de construcción (codificación) es
susceptible de cometer errores dado que se trata de una
actividad humana.
https://www.youtube.com/watch?v=0R1dBtcvaiM

13/05/2021
Plan de pruebas: Introducción
Permite tener una planeación de la aplicación de las
pruebas y el tipo de pruebas que harán que el sistema
funcione correctamente
Al momento de liberarse por completo, se crea
seguridad en los usuarios finales de que el sistema no
fallará
Existen dos actividades fundamentales para la etapa
de pruebas: las pruebas de componentes y las
pruebas del sistema
• En la primera se prueban las partes del sistema por separado
• En la segunda se prueban los componentes ya integrados, el
sistema como un todo

13/05/2021
Plan de pruebas: objetivos
• Demostrar al desarrollador y al cliente que el
software satisface sus requerimientos. En este
caso, se debe tener por lo menos una prueba para
cada requerimiento que se haya documentado.
• Para describir defectos en el software en el que el
comportamiento de éste es incorrecto.
– Se contemplan comportamientos indeseables en el
sistema, tales como: caídas en el sistema, cálculos
incorrectos, entre otros.

13/05/2021
Plan de pruebas: Características deseables
• A continuación se mencionan algunas
características deseables que deben contener los
planes de prueba:
– Diseñar un caso de prueba para cada funcionalidad del
software.
– Establecer como mínimo un caso de prueba de datos
correcto.
– Establecer como mínimo un caso de prueba de datos
incorrecto.
• Ejemplo: Caso de Prueba de un módulo de raíz cuadrada.
– Qué el usuario ingrese un número mayor que 0.
– Qué el usuario ingrese un número 0
– Qué el usuario ingrese un número menor que 0.

13/05/2021
Estándar IEEE 829 para un plan de
pruebas
• Esta norma IEEE std. 829 – 2008 es
compatible con todos los procesos del ciclo
de vida del software, incluyendo las fases de
adquisición, suministro, desarrollo, operación
y mantenimiento.
• Esta norma es compatible con todos los
modelos de ciclo de vida del software.

13/05/2021
Estándar IEEE 829 para un plan de
pruebas
Temas IEEE 829 Contenido
Nombre del plan de pruebas:
• Ítems a probar
• Características a ser
probadas
• Características que no se
van a probar
Esta sección define el alcance del sistema bajo
prueba, si los componentes no son
completamente nuevos o es una versión
incompleta o un incremento. Es importante
especificar cuáles características o componentes
no van a ser probados.
Enfoque
Provee un overview de la estrategia a utilizar en
las pruebas y del proceso de pruebas.
Casos de prueba
Esta sección resume e incorpora por referencia el
plan de pruebas, diseño de pruebas individuales,
especificaciones de casos de prueba,
especificaciones de procedimientos y los
resultados de las pruebas.

13/05/2021
IEEE 829 Subject Contenido
Tareas
Consiste en la división de las tareas para aplicar
las pruebas al sistema
Requerimientos de ambiente
Define las herramientas necesarias para la
automatización de las pruebas, hardware,
software y lugar para aplicarlas.
Responsabilidades
Define a quién le pertenece cada parte del
proceso de pruebas
Personal necesario y
entrenamiento
Se necesitará entrenamiento de los inspectores /
desarrolladores en cuanto al diseño de pruebas,
herramientas, ambiente, etc.
Planificación Fechas de inicio, hitos, completaciones, etc.
Riesgos y contingencias
¿Qué puede fallar? ¿Qué cosas fueron
asumidas? ¿Qué se puede hacer si un problema
mayor ocurre?
Aprobación Determinar quién debe aprobar y revisar el plan

13/05/2021
Plantilla de casos
de prueba IEEE
829

13/05/2021
Aplicación del estándar
• Es genérico para cubrir todos los tipos de
prueba
• Los documentos pueden adaptarse
• La idea es que cualquiera que se una al
proyecto sepa qué documentos se usan y
para qué

13/05/2021
El Plan de pruebas incluye…
• Objetivo del Plan
• Objetivo de las Pruebas
• Marco del Plan de Pruebas
• Alcance del Plan de Pruebas
• Descripción del módulo para pruebas
• Definición y Desarrollo de pruebas
• Resultados de las Pruebas
• Casos de Prueba:
– Se le llama así al diseño de entradas y salidas esperadas
para probar el sistema. El objetivo de su diseño es crear
un conjunto de casos de prueba que sean efectivos para
descubrir defectos en los programas y muestren que el
sistema cumple con los requerimientos

13/05/2021
El Plan de pruebas incluye…
• Programación de la aplicación de las pruebas
– Cronograma en Project
• Seguimiento y reporte por defectos:
– Se debe contar con un formato en donde se vayan
anotando los defectos encontrados en cada uno de
los módulos del sistema y de forma global, también
se reportarán las correcciones realizadas así como el
responsable de hacerlo con la finalidad de dar un
correcto seguimiento a los resultados de las pruebas

13/05/2021
Guía para la elaboración del plan de
pruebas
• Se necesita especificar las salidas o resultados
esperados.
• Los casos de prueba deben escribirse con
condiciones de entrada que son inválidas e
inesperadas, así como también aquellas que son
válidas y esperadas.
• Examinar un programa para verificar que hace lo
que deba de hacer es sólo parte de la prueba, la
otra mitad es asegurarse que el programa no
haga lo que no deba de hacer.
• No realizar planeaciones asumiendo que no se
encontrarán errores.

13/05/2021
pruebas
Objetivo:
Condición de Entrada:
Fecha de Prueba: Ciclo de Prueba:
Escenario Nro. Paso Acción Datos de Entrada Resultado Esperado
Exito
Frascaso
Observación
Escenario 1 1
2
3
4
5
6
7
8
Escenario 2

13/05/2021
pruebas
Código CP-001
Caso de prueba Ingreso a la aplicación a través de un login
Responsable Desarrolladores
Descripción de la
prueba
• Se ingresa el correo electrónico valido.
• Se ingresa contraseña valida.
• Hacer clic en el botón entrar.
Requisito previo Haber creado un nuevo usuario.
Resultado
esperado
El usuario será redirigido a la página principal de la aplicación.
Resultado
obtenido
Se ha iniciado sesión correctamente.
Estado Exitoso
Observaciones
Más sencillo, este será el formato que utilizaremos…

13/05/2021
pruebas
• La probabilidad de la existencia de mas errores en
una sección de un programa es proporcional al
número de errores encontrados en esa sección.
• Se debe de realizar una lista de verificación para
inspecciones de prueba que contenga los siguientes
puntos:
– Datos
– Declaración de datos
– Errores computacionales
– Errores de comparación
– Errores de control de flujo
– Errores de Interface
– Errores de Entrada/Salida

13/05/2021
pruebas
• Se pueden utilizar métodos deductivos e
inductivos para la prueba de software.
• La realización de pruebas es una actividad
extremadamente creativa e intelectualmente
retadora.
– Un programador debe de evitar probar sus
propios programas.
– Una organización no debe de probar sus propios
programas.
– Inspeccionar los resultados obtenidos de cada
prueba.

13/05/2021
Plan de Pruebas
• Se recomienda utilizar la metodología y
formatos del estándar IEEE 829 para
documentación de pruebas de software:
• Pasos que incluye:
– Identificador de plan de pruebas (se muestra el
estándar a seguir para el nombre de las pruebas)
– Introducción (en que consiste las pruebas del
sistema)
– Elementos a probar
– Características a ser probadas
– Características que no se probarán

13/05/2021
Plan de Pruebas
– Enfoque
– Criterio de fallo o aceptación de los elementos
– Criterio de Suspensión y Reanudación de
requerimientos
– Entregables de las pruebas
– Tareas de las pruebas
– Necesidades del entorno
– Responsabilidades
– Equipo y necesidades de capacitación
– Agenda
– Riesgos y contingencias
– Acuerdos

13/05/2021
Plan de Pruebas
• A las pruebas se les ha empezado a
llamar de manera formal verificación y
validación (curso de octavo semestre XD).
• Existen metodologías más robustas como
el TMMI (Test Maturity Model)

13/05/2021
Plan de pruebas

13/05/2021
Tipos
de
documento
1. Preparación de
pruebas
1. Plan de pruebas
2. Especificación del diseño
de pruebas
3. Especificación de casos
de prueba
4. Procedimientos de
prueba
5. Reporte de transmisión
de ítems de pruebas
2. Ejecución de
las pruebas
6. Log de pruebas
7. Reporte de incidentes de
pruebas
3. Término de las
pruebas
Reporte de las pruebas

13/05/2021
Ejemplo

13/05/2021
Documento 1. Plan de pruebas
• Documento eje sobre el cual se desarrollan
las pruebas
• Describe:
– Alcance
– Enfoque
– Recursos
– Calendarización de actividades de prueba
• Identifica los ítems y características a probar
• Identifica las tareas de prueba a desarrollar,
los responsables de cada tarea y los riesgos
asociados

13/05/2021
Documento 2. Especificación del
diseño de pruebas
• Se determina QUÉ necesita ser probado
• Se determina cómo sería una prueba
exitosa
• Se deriva de los requerimientos

13/05/2021
Documento 3. Especificación de casos
de prueba
• Valores exactos de entrada y otros que se
requieran
• Valores exactos de salida y cambios del
sistema esperados
• Pasos para ejecutar las pruebas

13/05/2021
Documento 4. Procedimientos de
prueba
• Describe cómo el tester ejecutará
físicamente la prueba y los pasos
necesarios

13/05/2021
Documento 5. Reporte de transmisión
de ítems de pruebas
• Describe los ítems para prueba
– Dónde encontrarlos y da la aprobación para
su liberación
• Garantiza al tester de que los ítems están
listos para ser probados

13/05/2021
Documento 6. Log de pruebas
• Registra los detalles sobre qué casos de
pruebas se han ejecutado, en qué orden y
sus resultados (pass/fail)
• Si hay inconformidades, se levanta o
actualiza un reporte de incidentes

13/05/2021
Documento 7. Reporte de incidentes
de prueba
• Descripción de los detalles encontrados
cuando la prueba no pasó

13/05/2021
Documento 8. Reporte de pruebas
• Resume la información importante sobre
las pruebas:
– Evaluación de qué tan bien se realizaron las
pruebas
– Número de incidentes reportados
– Evaluación sobre la calidad del sistema
• Gracias a este documento se decide si la
calidad del sistema es suficiente para
continuar

13/05/2021

13/05/2021
Bibliografía consultada
• I. Sommerville, “Ingeniería
de software”, 7ma Edición,
Cap.20

13/05/2021
Objetivos
• Explicar cómo la tolerancia a fallos y la
prevención de defectos de contribuir al
desarrollo de sistemas confiables.
• Describir las características de los procesos
de software confiable.
• Introducir las técnicas de programación para
la prevención de defectos.
• Describir los mecanismos de tolerancia a
fallos y el uso de la diversidad y la
redundancia.

13/05/2021
– Seguridad, fiabilidad y confiabilidad
– Confiabilidad del software
– Programación confiable
– Prevención de fallos
– Manejo de excepciones
– Tolerancia a fallos
– Arquitecturas tolerante a fallos

13/05/2021
Seguridad y fiabilidad
◆ Un sistema es seguro si no se pueden producir situaciones que
puedan causar muertes, heridas, enfermedades, ni daños en los
equipos ni en el ambiente
Un accidente (mishap) es un suceso imprevisto que puede
producir daños inadmisibles
◆ Un sistema es fiable si cumple sus especificaciones
◆ Seguridad y fiabilidad pueden estar en conflicto
La seguridad es la probabilidad de que no se produzcan
situaciones que puedan conducir a accidentes,
independientemente de que se cumpla la especificación o no

13/05/2021
Confiabilidad
◆ La confiabilidad (dependability) es una propiedad de los
sistemas que permite confiar justificadamente en el servicio
que proporcionan
◆ Tiene varios aspectos
confiabilidad
disponibilidad
de utilización
disponibilidad
servicio
disponible
continuamente
fiabilidad
no hay
situaciones
catastróficas
seguridad
no hay fugas
de información
no autorizadas
confidencialidad
no hay
alteraciones
de información
integridad
aptitud para
reparaciones
y cambios
mantenibilidad

13/05/2021

13/05/2021
Confiabilidad del Software
• En general, los clientes de software esperan
que todos los software sean confiables.
• Sin embargo, para aplicaciones no críticas,
pueden estar dispuestos a aceptar algunas
fallas o defectos en el sistema.
• Para algunas aplicaciones, sin embargo, los
requerimientos de confiabilidad son muy
altos y las técnicas especiales de ingeniería
de software puede ser utilizado para lograr
este objetivo.

13/05/2021
Confiabilidad del Software
• Prevención de fallos:
– El sistema está desarrollado de tal manera que se evitan
errores humanos y, por lo tanto, se minimizan las fallas del
sistema.
– El proceso de desarrollo está organizado para que las
fallas en el sistema se detecten y reparen antes de la
entrega al cliente.
• Detección de fallos:
– Las técnicas de verificación y validación se utilizan para
descubrir y eliminar fallas en un sistema antes de su
implementación.
• Tolerancia a fallos:
– El sistema está diseñado para que las fallas en el software
entregado no provoquen fallas en el sistema.

13/05/2021
Diversidad y Redundancia
• Redundancia: mantener más de 1 versión de un
componente crítico disponibles para que si uno falla,
entonces esté disponible una copia de seguridad.
• Diversidad: proporcionar la misma funcionalidad de
diferentes maneras para que no falle de la misma
manera.
• Sin embargo, agregar la diversidad y la redundancia
añade complejidad, aumentando con ello las
posibilidades de error.
• Algunos ingenieros abogan por la simplicidad y usan
la V&V extensa como una ruta más efectiva hacia la
confiabilidad del software.

13/05/2021
Ejemplos de Diversidad y Redundancia
• Redundancia. Donde la disponibilidad es
crítica (por ejemplo, en sistemas de comercio
electrónico), las empresas suelen mantener
servidores de apoyo y cambian a estos de
forma automática si se produce un fallo.
• Diversidad. Para proporcionar la resistencia
contra los ataques externos, se puede
implementar diferentes servidores usando
diferentes sistemas operativos (por ejemplo,
Windows y Linux).

13/05/2021
Software Libre de Fallos
• Los métodos actuales de la ingeniería de software
permiten ahora a la producción de software libre de
defectos, al menos para los sistemas relativamente
pequeños.
• Fallos de software libre: un programa informático
que se ajuste a sus especificaciones.
– No significa que el software siempre se lleva a cabo
correctamente ya que puede haber errores de
especificación.
– El costo de producir de software libre de fallos es muy
alto. Sólo es rentable en situaciones excepcionales.
– A menudo es más barato que aceptar los defectos del
software y pagar por sus consecuencias de gastar los
recursos en el desarrollo de software libre de fallos.

13/05/2021
Costo de Eliminación de Errores

13/05/2021
Procesos confiables
• Para asegurar un número mínimo de fallas
de software, es importante tener un repetible
proceso de software bien definido.
• Un proceso repetible bien definido es aquel
que no depende enteramente de las
habilidades individuales; más bien puede ser
llevado a cabo por diferentes personas.
• Para la detección, es evidente que las
actividades del proceso debe incluir un
esfuerzo significativo dedicado a la
verificación y validación

13/05/2021
Características de Procesos confiables
Documentable El proceso debe tener un modelo de proceso definido que establece las
actividades en el proceso y la documentación que se vaya a producir
durante estas actividades.
Normalizado Es el conjunto completo de normas de desarrollo de software que define
cómo el software se va a producir y documentados deben estar
disponibles.
Auditables El proceso debe ser comprensible para la gente, aparte de los participantes
del proceso que se puede comprobar que las normas de procesos se están
siguiendo y hacer sugerencias para la mejora de procesos.
Diversos El proceso debe incluir la verificación de redundantes y diversas
actividades de validación.
Robusto El proceso debe ser capaz de recuperarse de los fracasos de las actividades
de proceso individual.

13/05/2021

13/05/2021
Programación confiable
• Usar construcciones y técnicas de
programación que contribuyan a evitar
fallas y tolerancia a fallas
– Diseño debe favorecer la simplicidad;
– Proteger la información del acceso no
autorizado;
– Minimizar el uso de construcciones de
programación inseguras.

13/05/2021
Protección de la información
• La información solo debe estar expuesta a aquellas
partes del programa que necesitan acceder a ella.
Esto implica la creación de objetos o tipos de datos
abstractos que mantienen el estado y que
proporcionan operaciones en ese estado.
• Esto evita fallas por tres razones:
– se reduce la probabilidad de corrupción accidental de
información;
– la información está rodeada de un “firewall" para que sea
menos probable que los problemas se propaguen a otras
partes del programa;
– como toda la información está localizada, es menos
probable que cometa errores y es más probable que los
revisores de código encuentren errores.

13/05/2021
Programación Segura
• Los fallos en los programas suelen ser una
consecuencia de los errores cometidos por
los programadores
• Estos errores se producen porque la gente
pierde la pista de las relaciones entre las
variables del programa.
• Algunas construcciones de programación son
más propensas a errores de los demás para
evitar su uso reduce los errores del
programador

13/05/2021
Programación Estructurada
• Se propuso por primera vez en 1968 como un enfoque
de desarrollo que hace que los programas más fácil
de entender y que evita errores de programación.
• Programación sin GOTO.
• Mientras que los bucles y si las declaraciones como
las declaraciones de control solamente.
• Diseño Top-down.
• Un hecho importante porque promueve el
pensamiento y la discusión acerca de la
programación.

13/05/2021
Construcción Propensa al Error
(programación estructurada)
• Números de punto flotante
– Inherentemente imprecisos. La imprecisión puede dar lugar a
comparaciones válidas.
• Punteros
– Los punteros que apuntan a áreas incorrectas de memoria puede dañar
los datos. El Aliasing puede hacer que los programas sean difíciles de
entender y cambiar.
• Aliasing
– El uso de más de 1 nombre para referirse a la variable de un mismo
estado.
• Asignación dinámica de memoria
– Asignación de tiempo de ejecución puede ocasionar desbordamiento de
memoria.
• Paralelismo
– Puede dar lugar a errores de sincronización sutil imprevistos debido a la
interacción entre los procesos paralelos.

13/05/2021
Construcción Propensa al Error
• Interrupciones
– Las interrupciones pueden causar una operación crítica que terminar y
hacer un programa difícil de entender.
• Herencia
– El código no es localizado. Esto puede resultar en comportamiento
inesperado cuando se realizan cambios y los problemas de
comprensión.
• Recursión
– Los errores en la recursividad puede causar una sobrecargar de
memoria
• Matrices sin límites
– Los fallos de desbordamiento de búfer puede producirse si no hay
control de la envolvente en las matrices.
• Procesamiento de entrada por defecto
– Una acción de entrada que se produce independientemente de la
entrada.

13/05/2021

13/05/2021
Objetivos de la prevención y tolerancia a Faltas
• Tratar de anticipar faltas y manejarlas de forma de
minimizar los efectos negativos y maximizar la
seguridad
Falta: el error cometido por una persona se traduce en una
falta en un producto de software (o productos)
Falla: desvío del sistema del comportamiento requerido
No toda falta produce una falla, las condiciones para que
una falta resulte en falla pueden no producirse nunca
• Prevenir o tolerar faltas para evitar fallas,
construyendo el sistema para que reaccione de
manera aceptable

PRINCIPIOS BÁSICOS DE CONSTRUCCIÓN DE SOFTWARE Y TRATAMIENTO DE EXCEPCIONES

PRINCIPIOS BÁSICOS DE CONSTRUCCIÓN DE SOFTWARE Y TRATAMIENTO DE EXCEPCIONES

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a PRINCIPIOS BÁSICOS DE CONSTRUCCIÓN DE SOFTWARE Y TRATAMIENTO DE EXCEPCIONES

Similar a PRINCIPIOS BÁSICOS DE CONSTRUCCIÓN DE SOFTWARE Y TRATAMIENTO DE EXCEPCIONES (20)

Más de Franklin Parrales Bravo

Más de Franklin Parrales Bravo (20)

Último

Último (20)

PRINCIPIOS BÁSICOS DE CONSTRUCCIÓN DE SOFTWARE Y TRATAMIENTO DE EXCEPCIONES