Pruebas de Software

Universidad Nacional San Lus Gonzaga de Ica

Ing. Alonso Morales Loaiza

Qu es el Software?
Objeto de estudio de la
Ingeniera de Software
Producto que disean y
construyen los ingenieros de
software
No es solo el conjunto de
programas ejecutables, sino
tambin la documentacin, los
diagramas, los modelos, el
diccionario de datos

Qu es la Ingeniera de
Software?
Estudio de los principios y
metodologas para desarrollar
y mantener el software.
Zelkowitz.
Es la aplicacin prctica del
conocimiento cientfico en el
diseo y construccin de
programas de computador y la
documentacin apropiada para
desarrollarlos, operarlos y
mantenerlos. Boehm.

Evolucin del Software

Etapa 1: 1950 1965

Esfuerzo en el desarrollo de Hardware

Carencia de mtodos de desarrollo
Software a la medida con baja
distribucin

Etapa 2: 1965 1976

Masificacin de software en empresas

Software de gran extensin
Problemas de mantenimiento
Inicio de las casas de software
CRISIS DEL SOFTWARE

Evolucin del Software

Etapa 3: 1976 1989

Hardware a bajo costo.
Popularizacin de los
computadores personales.
Grandes inversiones en desarrollo
de software.
Etapa 4: 1989 -
Incremento de la demanda de
software.
Se agudiza la crisis del software:
mantenimiento.

Dnde estamos?

Desarrollo de aplicaciones genricas

parametrizadas: ERP (Enterprise Resource
Planning) SAP, JD Edwards
Paradigma orientado a objetos
El software como un producto industrial:
modelos de procesos y de producto
Sistemas basados en el conocimiento:
inteligencia artificial

Casos de estudio

Caso de Estudio: F-18 (1986)

En abril de 1986 un avin de
combate F-18 se estrell por culpa
de un giro descontrolado,
atribuido a una expresin ifthen, para la cual no haba una
expresin else, por considerarse
innecesaria, lo que origin una
excepcin fuera de control del
programa.
Por suerte el piloto pudo salir del
avin a tiempo.

Caso de Estudio: Sistema AEGIS

(1988)

El 3 de julio de 1988, en el golfo

prsico, el USS Vincennes derrib un
jet de pasajeros iran que confundi
con una aeronave iran hostil. El
capitn de la nave orden el
lanzamiento de un misil provocando
la muerte de los 290 tripulantes. Se
consider como causa del accidente
al sistema de radar AEGIS.

Caso de estudio: Therac-25

Diseado para tratamiento de pacientes

por medio de rayos X. Entre 1985-1987
ocasiono la muerte de varios pacientes en
hospitales de USA, por culpa de
radiaciones de alto poder aplicadas de
manera incontrolada. La probable causa
era que para ciertas secuencias de
comandos, los controles de la
computadora llevaban la mquina a un
estado interno errneo y muy peligroso
generando una sobredosis masiva de
radiacin al paciente. La FDA no hacia
revisiones sobre practicas de desarrollo
de software, ni control de calidad del
software en dispositivos mdicos

Caractersticas del software

El software es un producto intangible:
Se desarrolla no se fabrica:

Se deteriora

No es un producto esttico
Debe ser flexible para aceptar modificaciones
Por la labor de mantenimiento
Aparicin de nuevas tecnologas

Se desarrolla a la medida

La mayora de las veces se desarrolla de acuerdo a las

necesidades particulares de los clientes
Aunque ya existen algunas empresas de software que
desarrollan aplicaciones genricas

Proceso de traduccin del software

Traduccin
a partir de una descripcin
verbal dada por el cliente
en un lenguaje de programacin
soportado por el computador,
para obtener un conjunto de
instrucciones de mquina
ejecutadas por el procesador

Proceso de traduccin del

software
Descripcin verbal
del problema
Diagramas y
Modelos propios
De las primeras
etapas de
desarrollo

Anlisis y diseo del

software

Lenguaje de
programacin
Instrucciones
ejecutadas por
el procesador

Documentacin:
Diccionario datos
Manual usuario

Categoras de software
Software de Sistemas
Software de tiempo real
Software para Gestin de
informacin
Software empotrado
Software para PCs
Software basado en la Web
Software de ingeniera y
cientfico
Software de inteligencia artificial

Crisis del software

No esta asociada con una poca de

decadencia en la construccin del
software
Se enfoca en inconvenientes que
aparecen cuando se trata de
responder a preguntas como:
Cul es el mtodo ptimo para
desarrollar software?
cmo realizar un mantenimiento eficiente
que permita satisfacer la creciente
demanda de aplicaciones de las
organizaciones?

Mitos del Software

Mitos de Gestin:

Mitos del Cliente:

Siempre lo hemos hecho as y funciona

bien: resistencia al cambio
El software lo har TODO
Hay cosas que no hay que decir, el analista
debe suponerlas
Los detalles se dejan para el final

Mitos de Desarrolladores:

Los mtodos no sirven

Lo nico importante es el cdigo
El proyecto termina con el desarrollo del
software (y la documentacin y el
mantenimiento qu ?)

Ciclo de vida de Un Software

Sistema

Abstracto para el
analista....y posiblemente
para el usuario!

Conocedor del
sistema...an
cuando no lo
tenga muy claro
Usuario

Analista

Definicin
Anlisis
Diseo
Desarrollo
Pruebas
Mantenimiento

Ciclo de vida de Un Software

Fase 1: Definicin = conocer

Estar en contacto constante con el
cliente
Establecer los requisitos
Definir el problema
Determinar los lmites y su interaccin
con el entorno
Es junto con el anlisis la fase ms
importante

Ciclo de vida de Un Software

Fase 2: Anlisis = entender

Objetivo del Software
Para qu el software?

DIAGNOSTICO del sistema

Procesos del sistema

Qu ser resuelto?
Contacto constante con el cliente

Ciclo de vida de Un Software

Fase 3: Diseo =
solucionar

La fase de diseo marca una

transicin desde la descripcin de
cmo debe lucir la solucin
(especificaciones) hacia cmo ser
resuelto el problema von
Mayrhauser.

Solucin planteada, comnmente

en la actualidad, con el Paradigma
Orientado a Objetos

Ciclo de vida de Un Software

Diseo: traza o delineacin de un

edificio o una figura. RAE. La IS
es un arte.

La solucin no se obtiene de ese

recetario que es el mtodo. La
solucin es un planteamiento del
analista, construido gracias al
conocimiento adquirido con ayuda,
ahora s, del mtodo. La IS es una
ciencia.

Ciclo de vida de Un Software

Fase 4: Desarrollar la
solucin

Traducir el diseo al cdigo

Tambin se utiliza el paradigma

orientado a objetos.

Ciclo de vida de Un Software

Fase 5: Pruebas = nada es

perfecto
Verificar el funcionamiento del
sistema desarrollado.
Corregir los errores encontrados.
Hacer mejoras con base en la
apreciacin del cliente.

Ciclo de vida de Un Software

Fase 6: Mantenimiento =
NADA ES PERFECTO

Corregir errores no hallados en la

fase de pruebas.
Mejoras propuestas por el cliente.
Nuevas funciones (cliente o
analista).
Revisin del funcionamiento.
ASEGURAR QUE CONTINE LA
SATISFACCIN DEL CLIENTE

Ciclo de vida de Un Software

NIVEL DE
ABSTRACCIN

DEFINICIN
ANLISIS
DISEO
DESARROLLO

Conclusin y reflexin

El SW es actualmente un elemento de vital

importancia para la humanidad.
El SW esta por doquier: dispositivos
mviles, electrodomsticos, etc.
Dada esta importancia es paradjico que
an los enfoques metodolgicos no hayan
penetrado suficientemente en el desarrollo
Es imperativo que los estudiantes de
ingeniera de sistemas y ciencias afines
entiendan la importancias de estos
enfoques, para garantizar el futuro de las
empresas de software.

CONCEPTO DE CALIDAD EN
SOFTWARE

Cuando se habla de calidad del software se hace referencia

la conjunto de cualidades que determinan su utilidad. Es el
grado en que un software cumple con los requisitos
especificados. (eficiencia, flexibilidad, correccin,
mantenimiento, seguridad e integridad.

CONCEPTO DE CALIDAD EN
SOFTWARE
La Calidad del software es medible y varia segn el tipo
de sistema y de programa, por ejemplo: no es lo mismo
un software para control de viajes especiales el cual
debe ser confiable a un nivel de cero errores, que un
software elaborado para la implementacin de un
sistema de calidad
(investigacin).

CONCEPTO DE CALIDAD EN
SOFTWARE
Esta calidad puede ser
inspeccionada al finalizar el
producto, pero normalmente es
mas costoso que realizarlo
durante las diferentes etapas
del ciclo de vida de produccin
del producto

BENEFICIOS

Organizacin
Control
Trazabilidad del servicio
Mejora continua
Imagen frente a los clientes
Definicin de la responsabilidad y
autoridad y por ende de la
competencia
del personal

MODELOS PARA
CALIDAD EN SOFTWARE

MODELOS PARA CALIDAD EN

SOFTWARE
La obtencin de un software con
calidad implica la utilizacin de
modelos o procedimientos
estndares para el anlisis, diseo,
desarrollo y prueba del software que
permitan uniformar la filosofa de
trabajo, para lograr una mayor
confiabilidad, mantenibilidad y
facilidad de prueba, a la vez que
eleven la productividad, tanto para
la labor de desarrollo como para el
control de la calidad del software

MODELOS PARA CALIDAD EN

SOFTWARE
En todos los diferentes modelos para
conseguir una certificacin, no solo
es necesario que la metodologa o la
documentacin de los procesos
cumpla con los requisitos del
modelo, sino que es necesario
adems, que existan suficientes
evidencias que demuestren el uso
consistente y sistemtico de las
prcticas definidas en la
organizacin.

MODELOS PARA CALIDAD EN

SOFTWARE
Por esta razn, el objetivo principal de
acciones de mejora, no reside tanto en
obtener la certificacin en alguno de los
niveles del modelo, sino en implantar
unos procesos que, independientemente
del reconocimiento de cara a clientes y
proveedores, mejoran sustancialmente la
calidad y el desempeo de los resultados
y del propio proceso en estudio

MODELOS PARA CALIDAD EN

SOFTWARE

El modelo a seleccionar depende

de lo que se quiera lograr y de
la forma de trabajo. La cantidad
de modelos que se tienen
actualmente es muy variada

MODELOS PARA CALIDAD EN

SOFTWARE
Entre los mas destacados estan:
CMM (Capability Maturity Model).
Orientado a mejora de procesos en
diferentes niveles de madurez, mas
hacia proyectos especficos

Gestin de calidad: Un modelo

enfocado al estilo de gerencia de la
empresa ha sido exitoso por su
adaptabilidad a cualquier tipo de
organizacin y definido mediante las
normas ISO 9000

MODELO DE LA CAPACIDAD DE
MADURACIN (CMM)

Conceptos de gestin aplicados a los

procesos y mejora de la calidad del
desarrollo y mantenimiento del
software.

Estudia los procesos y define el nivel

de madurez de la organizacin segn
una escala de cinco niveles.

Obliga a la revisin constante

Modelo CMM: Objetivos

Objetivo 1: Determinar el nivel de

madurez del Proceso de Desarrollo
que permita establecer un indicador
de Calidad del proceso. (5 Niveles
de Madurez)

Objetivo 2: Servir de gua en el

Proceso de Desarrollo permitiendo la
Mejora Continua de la organizacin
-> Control de Procesos

NIVELES DE CMM

Proceso Desarrollo Software

NIVEL 2: Repetible
Gestin de Requisitos
Planificacin del Proyecto
Seguimiento y Supervisin del
Proyecto Software
Gestin de Subcontratacin del
Software Garanta de Calidad del
Software
Gestin de Configuracin del
Software

Proceso Desarrollo Software

Nivel 3: Definido
Enfoque del proceso de la
organizacin
Definicin del proceso de
organizacin
Programa de formacin
Gestin de integracin del
software
Ingeniera de productos software
Coordinacin entre grupos
Revisiones peridicas

Proceso Desarrollo Software

Nivel 4: Gestionado
Gestin cuantitativa del proceso
Gestin de calidad del software

Nivel 5: Optimizacin
Prevencin de defectos
Gestin de la tecnologa
Gestin de cambios en el proceso

Verificacin y Validacin
Asegurar

que el
sistema de software
cumpla las necesidades
del usuario

Objetivos
Introducir la verificacin y
validacin de software
Describir las fases del proceso
de pruebas
Explicar la importancia de la
planeacin de las pruebas
Describir varias estrategias
complementarias de pruebas

Tpicos
El proceso de pruebas
Planeacin de pruebas
Estrategias de pruebas

Verificacin vs validacin
Verificacin:
"Se esta construyendo
adecuadamente el producto"
El software debe estar conforme
a sus especificaciones
Validacin:
"Se esta construyendo el
producto adecuado"
El software debe hacer lo que el
usuario requiere

El proceso V & V
Es todo un proceso del ciclo de
vida - V & V debe aplicarse en
cada fase del proceso de
software
Tiene dos objetivos principales

El descubrimiento de defectos en
el sistema
La aseveracin de si el sistema es
til o no en una determinada
situacin operacional

Verificacin dinmica y esttica

Verificacin dinmica Se refiere a

el ejercicio y observacin del
comportamiento del producto
(prueba)

Verificacin esttica Se refiere al

anlisis de la representacin
esttica del sistema para descubrir
problemas

V&V esttica y dinmica

Static
verification

Requirements
specification

Prototype

High-level
design

Formal
specification

Detailed
design

Program

Dynamic
validation

Prueba de programas
Puede revelar la presencia de
errores no su ausencia
Una prueba exitosa consiste en
descubrir uno o mas errores
Solo se considera la tcnica de
validacin para requerimientos
no-funcionales
De se usada en conjunto con la
verificacin esttica

Tipos de pruebas

Pruebas estadsticas

Pruebas diseadas para reflejar la frecuencia

de las entradas del usuario. Usadas para
estimacin de la confiabilidad.
Cubiertas en el capitulo 18 - Confiabilidad del
Software

Prueba de defectos

Pruebas diseadas para descubrir defectos en

el sistema
Un prueba de defectos exitosa es aquella que
revela la presencia de defectos en el sistema
Cubierta en el capitulo 23. Prueba de
defectos.

Prueba y depuracin

La prueba de defectos y la depuracin son

distintos procesos
La prueba de defectos se refiere a la
confirmacin de la presencia de errores
La depuracin se refiere a la localizacin y
reparacin de estos errores
La depuracin involucra la formulacin de una
hiptesis acerca del comportamiento del
programa y la prueba de la hiptesis para
encontrar los errores en el sistema

El proceso de depuracin

Locate
error

Design
error repair

Repair
error

Re-test
program

Fases de pruebas

Pruebas de Unidades

Prueba de mdulos

prueba de colecciones de mdulos integrados en subsistemas

Prueba del sistema

prueba de conjuntos de componentes dependientes

Prueba de sub-sistemas

prueba de componentes individuales

prueba del sistema completo ante de su entrega

Prueba de aceptacin

pruebas de los usuario para verificar que el sistema

cumple con los requerimientos. Llamado en ocasiones
prueba alfa.

El proceso de pruebas
Unit
testing
Module
testing
Sub-system
testing
System
testing
Acceptance
testing

Component
testing

Integration testing

User
testing

Prueba de sistemas
orientados a objetos

Son sistemas con menor acoplamiento

fuerte. Los objetos no estn
necesariamente integrados en subsistemas
Prueba de cluster. Prueba de un grupo
de objetos cooperantes
Prueba de hilos (threads). Prueba un
hilo de procesamiento mientras
transcurre de objeto a objeto. Discutido
posteriormente en la prueba de
sistemas de tiempo real.

Planeacin de pruebas y
planificacin (scheduling)

Describe las fases principales del

proceso de pruebas
Describe el seguimiento de las pruebas
a los requerimientos
Estimar la planificacin general y el
alojamiento de recursos
Describir las relaciones con otros planes
del proyecto
Describir el mtodo usado para archivar
los resultados de las pruebas

El plan de pruebas

El proceso de pruebas
El seguimiento (traceability) de los
requerimientos
Componentes probados
El calendario de las pruebas
Los procedimientos para archivar
pruebas
Los requerimientos del hardware y
software
Las restricciones

El modelo V de
desarrollo
Requ ir ement s
s pecifi cat io n

Sy st em
s pecifi cat io n

Sy st em
i nt eg rat io n
t es t pl an

Accep tan ce
t es t pl an

Servi ce

Sy stem
d es ig n

Accep tan ce
t es t

Det ail ed
d es ig n

Su b-s ys tem
i nt eg rat io n
t es t pl an

Sy stem
i nt eg ratio n t est

Su b-s ys tem
i nt eg rat io n t est

Mo du le an d
u ni t co de
and t ess

Estrategias de pruebas

Las estrategias de pruebas son formas

de enfocar el proceso de pruebas
Distintas estrategias pueden aplicarse
para las distintas fases del proceso de
pruebas
Estrategias consideradas

Pruebas top-down
Pruebas bottom-up
Prueba de Hilos (Thread)
Prueba de estres
Prueba Back-to-back

Prueba incremental
A

T1

T1

A
T1

T2

T2
T2

T3
T3

C
T4

T3
C

T4
T5

D
Test sequence
1

Test sequence
2

Test sequence
3

Prueba top-down
Level 1

Testing
sequence

Level 2
Le vel 2
stubs

Le vel 3
stubs

Level 1

Level 2

Le vel 2

. ..

Level 2

Prueba top-down

Comienza con los altos niveles del sistema

y sigue hacia los niveles inferiores
Es una estrategia de pruebas que es usada
junto con el desarrollo top-down
Descubre errores arquitecturales
Puede requerir cierta infraestructura de
sistema antes de llevar a cabo las pruebas
Puede ser difcil desarrollar stubs de
programas

Pruebas bottom-up
Test
drivers
Level N

Test
drivers

Level N

Level N1

Le vel N

Level N1

Level N

Level N

Level N1

Testing
sequence

Pruebas bottom-up

Son necesarias para componentes

crticos
Comienza con los niveles inferiores y
se mueven hacia los niveles
superiores del sistema
requiere drivers de prueba a
implementarse
Solo encuentra problemas de diseo
hasta muy avanzado el proceso
Es apropiado para sistemas
orientados a objetos

Prueba de Hilos (Thread)

Apropiados para sistemas de tiempo real y

sistemas orientados a objetos
Se basan el prueba y operacin lo cual
involucra una secuencia de pasos de
procesamiento los cuales comparten su
ejecucin en el sistema
Comienza con un hilo de un evento y sigue
hacia mltiples hilos de eventos
La prueba completa de hilos no es posible
debido al gran numero de combinaciones

Interacciones entre
procesos
I1 (P2)

I1 (P1)
I2 (P1)

P1
P2

I3 (P1)
I1 (P3)

P5
O1 (P4)

P3
P4

O2 (P4)

O1
(P5)

Prueba de Hilos (Thread)

I1
(P3)

P3

P2

P4

O1
(P4)

I1
(P1)
I2
(P1)
I3
(P1)

P1

P2

P5

O1
(P5)

Prueba de mltiples
hilos
I1 (P2)
I1 (P1)
I2 (P1)

P1

P2

P5

I3 (P1)
P4

O2 (P4)

O1 (P5)

Prueba de estres

Ejercita el sistema mas all de los limites

mximos de carga del sistema. Esta prueba
causa que los defectos surjan
Al estresar el sistema se prueba el
comportamiento de las fallas. La prueba de
estres verifica perdidas inaceptables de
servicio o datos
Particularmente relevante en sistemas
distribuidos que presentan una degradacin
severa cuando la red se sobre carga

Pruebas back-to-back

Presenta las mismas pruebas para

distintas versiones del sistema y
compara las salidas. Distintas salidas
implican problemas potenciales
Reduce el costo de examinar los
resultados de las pruebas.
Comparacin automtica de
resultados
Es posible cuando un prototipo esta
disponible o con pruebas de
regresin de una nueva versin del
sistema

Pruebas back-to-back
Test data

Program
version A

Program
version B

Results
comparator

Difference report

Resumen

Verificacin y validacin no son lo mismo

Las pruebas son usadas para establecer la
presencia de defectos
Las actividades necesarias en las pruebas
son prueba de unidades, prueba de
mdulos, prueba de sub-sistemas, prueba
de integracin y prueba de aceptacin
Las clases de los objetos deben ser
probadas en los sistemas orientados a
objetos

Resumen

Las pruebas deben ser planificadas

como parte del proceso de
planeacin. Deben estar disponibles
los recursos necesarios
Deben disearse planes de pruebas
para guiar el proceso de pruebas
Las estrategias de pruebas son :
pruebas top-down, pruebas bottomup, pruebas de estres, pruebas de
hilos y pruebas back-to-back