EQUIPO 5

INGENIERIA DEL SOFTWARE

ESTRATEGIAS DE PRUEBA DE SOFTWARE
INTEGRANTES:
BLANCAS ALEGRE JOSE LUIS
ILLESCAS FRIAS JESUS ALFREDO
URABNAO RAMIREZ MARIO JOSUE
SIMBRON MONTEJO PILAR

ESTRATEGIAS DE PRUEBA DE SOFTWARE

UNA ESTRATEGIA DE PRUEBA DE SOFTWARE PROPORCIONA
UNA GUIA QUE DESCRIBE LOS PASOS QUE DEBEN REALIZARSE
COMO PARTE DE LA PRUEBA,CUANDO SEPLANEA Y SE LLEVAN A
CABO DICHOS PASOS POR LO TANTO CUALQUIER ESTRATEGIA
DE PRUEBA DEBE INCORPORAR LA PLANIFICACION DE LA
PRUEBA,EL DISEO DE LOS CASOS DE PRUEBA, LA EJECUCION
DE LA PRUEBA Y LA RECOLECCION Y EVALUACION DE LOS
RESULTADOS.

ESTA DEBE SER SUFICIENTE MENTE FLEXIBLE PARA PROMOVER

UN USO PERSONALIZADO DE LA PRUEBA Y SUFICIENTEMENTE
RIGIDA PARA ALENTAR A LA PLANIFICACION

UN ENFOQUE ESTRATEGICO PARA LA PRUEBA

DE SOFTWARE

PARA REALIZAR UNA PRUEBA DEBE REALIZAR REVISIONES TECNICAS

EFECTIVAS (15) AL HACERLO, ELIMINARA MUCHOS ERRRORES ANTES DE
COMEZAR LA PRUEBA

LA PRUEBA COMINEZA EN LOS COMPONETNES Y OPERA HACIA A FUERA,

HACIA LA INTEGRACION DE TODO EL SISTEMA DE COMPUTO

DIFERENTES TECNICAS DE PRUEBA SON ADECUADAS PARA DISTINTES

ENFOQUES DE INGENIERIA DE SOFTWARE Y EN DIFERENTES MOMENTOS EN
EL TIEMPO

LAS PRUEBAS LAS REALIZA EL DESARROLLADOR DEL SOFTWARE Y

PARAPROYECTOS GRANDES UN GRUPO DE PRUEBA INDEPENDIENTE

PRUEBA Y DEPURACION SON LAS ACTIVIDADES DIFERENTES PERO LA

DEPURACION DEBE INCLUIRSE EN CUALQUIER ESTRATEGIA DE PRUEBA

VERIFICACION Y VALIDACION
VERIFICACION SE REFIERE AL CONJKUNTO DE TAREAS
QUE GARANTIZAM QUE EL SOFTWARE IMPLEMENTA
CORRECTAMENTE UNA FUNCION ESPECIFICA
VALIDACION ES UN CONJUNTO DE DIFERENTES TAREAS
QUE SE ASEGURAN QUE EL SOFTWARE QUE SE
CONSTRUYE, SIGUE LOS REQUERIMINETOS DEL CLIENTE

ORGANIZACIN DE LAS PRUEBAS DEL

SOFTWARE
EN TODO PROYECTO DE SOFTWARE HAY UN CONFLICTO DE
INTERESES QUE OCURRE CONFORME COMIENZAN LAS
PRUEBAS.
EL PAPEL DE UN GPI ES REMOVER LOS PROBLEMAS
INHERENTES QUE ESTAN ASOCIADOS CON DEJAR AL
CONSTRUCTOR PROBAR LO QUE CONSTRUYO.

ESTRATEGIAS DE PRUEBA
DEL
SOFTWARE VISION GENERAL (VISION GENERAL)

El proceso de software puede verse como la espiral

Prueba del sistema

Prueba de validacin
Prueba de integracin
Prueba de unidad
Cdigo
Diseo
Requerimientos
Ingeniera del sistemas

Requerimientos

Pruebas de orden superior

Prueba de integracion

Diseo

Codigo

Direccin
de la
prueba

Prueba de
unidad

Aspectos
estratgicos

 Especifican los requerimientos del producto en forma

cuantificable mucho antes de comenzar.
establecen de manera explicita los objetivos de las pruebas
Entienden a los usuarios de software
Y desarrollan un perfil para cada categoria de usuario
Desarrollan un plan de prueba que enfatice pruebas de ciclo
rpido

ESTRATEGIA DE PRUEBAS PARA SOFTWARE

CONVENCIONAL
Existen muchas estrategias que pueden usarse para probar el
software. En un extremo pueden esperarse hasta que el sistema
este completamente construido y luego realizar las pruebas
sobre el sistema total, con la esperanza de encontrar errores.

PRUEBA DE UNIDAD
La prueba de unidad enfoca los esfuerzos de verificacin en la
unidad mas pequea del diseo de software.
La interfaz de modulo se prueba para garantizar que la
informacin fluya de manera adecuada hacia y desde la unidad
del software que se esta probando.

modulo

Interfaz
Estructuras de
datos locales,
condiciones de
frontera, rutas
independientes
Rutas de manejo
de erros

Casos de
prueba

PROCEDIMIENTOS DE PRUEBA DE UNIDAD

Las pruebas de unidad por lo general se consideran

como adjuntas al paso de condicin.
en las mayoras de las aplicaciones, un controlador
no es mas que un programa principal que acepta
casos de prueba

controlador

Modulo que
se va a
probar

representant
e

Interfaz
Estructuras de datos
locales, condiciones de
frontera, rutas
independientes
Rutas de manejo de
erros

Casos
de
prueba

representant
e

resultado

PRUEBAS DE INTEGRACIN

Las pruebas de integracin son una tcnica

sistemtica para construir la arquitectura del software
mientras se llevan a cabo pruebas para descubrir
errores asociados con la interfaz

INTEGRACIN DESCENDENTE
Es un enfoque incremental a la construccin de la arquitectura
de software.
Los mdulos se integran al moverse hacia abajo a travs de la
jerarqua del control, comenzando con modulo de control
principal.

M1

M2

M5

M8

M3

M6

M7

M4

INTEGRACION ASCENDENTE
La prueba de integracin ascendente comineza la construccin
y la prueba con mdulos atmicos (con componentes en los
niveles inferiores dentro de la estructura del programa) puesto
que estos componentes se integran de abajo hacia arriba

Los pasos para una estrategia de integracin ascendente son:

1. Los componentes en el nivel inferior
2. Se escribe un controlador
3. Se prueba el grupo
4. Los controladores se remueven y los grupos se combinan
movindolos hacia arriba en la estructura del programa

Mc

Ma

D1

Mb

D2

D3

 Prueba de regresin
1. Una muestra representativa de pruebas que ejercitara todas las
funciones de software
2. Pruebas adicionales que se enfocan en las funciones del
software que probablemente resulten afectadas por el cambio
3. Pruebas que se enfocan en los componentes del software que
cambiaron

 Prueba de humo
1. Los componentes de software traducidos en codigos se integran
en una construccin
2. Se disea una serie de pruebas para exponer los errores que
evitaran a la construccin. realizar adecuadamente su funcin.
3. La construccin se integra con otras construcciones y todo el
producto se somete en prueba de humo diariamente .

 Los beneficios de la prueba de humo son:

1.
2.
3.
4.

Se minimiza el riesgo de integracin.

La calidad del producto final mejora.
El diagnostico y la correccin de errores se simplifican.
El progreso es mas fcil de valorar .

 Opciones estratgicas.
Producto de trabajo de las pruebas de integracin.
1. Interaccin con el usuario.
2. Procesamiento de sensores.
3. Funciones de comunicacin.
4. Procesamiento de alarma.

Cada una de estas fases de la prueba de integracin delinea una

amplia categora funcional dentro del software y tienen un dominio
especifico dentro de la arquitectura del software.
Integridad de interfaz.
Validez funcional.
Contenido de la informacin.
Rendimiento.

ESTRATEGIAS DE PRUEBA DE SOFTWARE

17.5 ESTRATEGIAS DE PRUEBA PARA WEBAPPS

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

El modelo de contenido para la webapp se revisa para descubrir errores.

El modelo de interfaz se revisa para garantizar que todos los casos de uso pueden adecuarse.
El modelo de diseo para la webapp se revisa para descubrir errores de navegacin.
La interfaz de usuario se prueba para descubrir errores en los mecanismos de presentacin y/o
navegacin.
A cada componente funcional se le aplica una prueba de unidad.
Se prueba la navegacin a lo largo de toda la arquitectura.
La webapp se implementa en varias configuraciones ambientales diferentes y se prueba en su
compatibilidad con cada configuracin.
Las pruebas de seguridad se realizan con la intencin de explotar vulnerabilidades en la
Webapp o dentro de su ambiente.
Se realizan pruebas de rendimiento.
La webapp se prueba mediante una poblacin de usuarios finales controlada y monitoreada. Los
resultados de su interaccin con el sistema se evalan por errores de contenido y navegacin,
preocupaciones de facilidad de uso, preocupaciones de compatibilidad, as como confiabilidad y
rendimiento de la webapp.

17.6 PRUEBAS DE VALIDACIN

Las pruebas de validacin comienzan en la culminacin de las pruebas de
integracin, cuando se ejercitaron componentes individuales, el software est
completamente ensamblado como un paquete y los errores de interfaz se
descubrieron y corrigieron. En el nivel de validacin o de sistema, desaparece la
distincin entre software convencional, software orientado a objetos y webapps. Las
pruebas se enfocan en las acciones visibles y las salidas del sistema reconocibles
por el usuario final.

La validacin es exitosa cuando el software funciona en una forma que cumpla con
las expectativas razonables del cliente. En este punto, un desarrollador de software
curtido en la batalla puede protestar: quin o qu es el rbitro de las expectativas
razonables?. Si se desarroll una Especificacin de requerimientos de software, en
ella se describen todos los atributos del software visibles para el usuario; contiene
una seccin de Criterios de validacin que forman la base para un enfoque de
pruebas de validacin.

17.6.1 CRITERIOS DE PRUEBAS DE VALIDACIN

La validacin del software se logra a travs de una serie de pruebas que demuestran conformidad
con los requerimientos.
Un PROCEDIMIENTO DE PRUEBA define
UN PLAN DE PRUEBA subraya las
casos de prueba especficos que se disean
clases de pruebas que se van a
para garantizar que: se satisfacen todos los
realizar
requerimientos de funcionamiento, se logran
todas las caractersticas de comportamiento,
Despus de realizar cada caso de prueba de
todo el contenido es preciso y se presenta de
validacin, existen dos posibles condiciones:
manera adecuada, se logran todos los
La caracterstica de funcin o rendimiento se
requerimientos
de
rendimiento,
la
conforma de acuerdo con las especificaciones
documentacin es correcta y se satisfacen la
y se acepta.
facilidad de uso y otros requerimientos (por
Se descubre una desviacin de la
ejemplo, transportabilidad, compatibilidad,
especificacin y se crea una lista de
recuperacin de error, mantenimiento).
deficiencias.

17.6.2 REVISIN DE LA CONFIGURACIN

Un elemento importante del proceso de validacin es una revisin de la

configuracin. La intencin es garantizar que todos los elementos de la
configuracin del software se desarrollaron de manera adecuada, y que
se cataloga y se tiene el detalle necesario para reforzar las actividades de
apoyo. La revisin de la configuracin, en ocasiones llamada auditora, se
estudia con ms detalle en el captulo 22.

17.6.3 PRUEBAS ALFA Y BETA

Virtualmente, es imposible que un desarrollador de software prevea cmo usar el cliente
realmente un programa. Las instrucciones para usarlo pueden malinterpretarse; regularmente
pueden usarse combinaciones extraas de datos; la salida que pareca clara a quien realiz la
prueba puede ser ininteligible para un usuario.
Cuando se construye software a la medida para un cliente, se realiza una serie de pruebas de
aceptacin a fin de permitir al cliente validar todos los requerimientos. Realizada por el usuario
final en lugar de por los ingenieros de software, una prueba de aceptacin puede variar desde una
prueba de conduccin informal hasta una serie de pruebas planificadas y ejecutadas
sistemticamente. De hecho, la prueba de aceptacin puede realizarse durante un periodo de
semanas o meses, y mediante ella descubrir errores acumulados que con el tiempo puedan
degradar el sistema.
Si el software se desarrolla como un producto que va a ser usado por muchos clientes, no es
prctico realizar pruebas de aceptacin formales con cada uno de ellos. La mayora de los
constructores de productos de software usan un proceso llamado prueba alfa y prueba beta para
descubrir errores que al parecer slo el usuario final es capaz de encontrar.

17.6.3 PRUEBAS ALFA Y BETA

En ocasiones se realiza una variacin de la prueba beta,

llamada prueba de aceptacin del cliente, cuando el software
se entrega a un cliente bajo contrato. El cliente realiza una
serie de pruebas especficas con la intencin de descubrir
errores antes de aceptar el software del desarrollador. En
algunos casos (por ejemplo, un gran corporativo o sistema
gubernamental) la prueba de aceptacin puede ser muy formal
y abarcar muchos das o incluso semanas de prueba.

PUEBAS DEL SISTEMA

Estas pruebas quedan fuera del mbito del proceso de software y no

se llevan a cabo exclusivamente por parte de ingenieros de
software.
Sin embargo los pasos que se toman durante el diseo de la prueba
de software pueden mejorar enormemente la probabilidad de
integracin exitosa de software en el sistema
Un problema clsico en la prueba del sistema es el dedo
acusador, esto ocurre cuando se descubre un error y los
desarrolladores de diferentes elementos del sistema se culpan unos
a otros por el problema, en lugar de abandonarse a tal sentido,
deben anticiparse los potenciales problemas del interfaz.

COMO EVITAR PROBLEMAS DE INTERFAZ?

1.-Disear rutas de manejo de error que prueben toda la
informacin proveniente de otros elementos del sistema.
2.-realizar una serie de pruebas que simulen los datos
malos u otros errores potenciales en la interfaz del
software.
3.-Registrar el resultado de las pruebas para usar como
evidencia si ocurre el dedo acusador.
4.-participar en la planificacin y diseo de pruebas del
sistema para garantizar que el software se pruebe de
manera adecuada.

PRUEBAS DE RECUPERACIN

Los sistemas basados en computadora deben recuperarse de fallas y

reanudar el procesamiento con poco o ningn tiempo de inactividad. En
algunos casos un sistema debe ser tolerante a las fallas.

En caso de ocurrir algn tipo de falla el desarrollador debe realizar una serie
de procedimientos para la restauracin del sistema.

Una vez recuperado el sistema el desarrollador debe

cerciorarse que el sistema fue restaurado de forma
eficiente, para ello debe seguir ciertos procesos, ejemplo:

Verificar que los procesos de recuperacin (manual o

automtica) restauraron apropiadamente la base de
datos.
Estas pruebas aseguran que una aplicacin o sistema
se recupere de una variedad de anomalas de hardware,
software o red con perdidas de datos o fallas de
integridad.

PRUEBA DE SEGURIDAD.
OBJETIVO:
NIVEL DE SEGURIDAD DE LA APLICACIN: VERIFICA
QUE UN ACTOR SOLO PUEDA ACCEDER A LAS
FUNCIONES Y DATOS QUE SU USUARIO TIENE
PERMITIDO.
NIVEL DE SEGURIDAD DEL SISTEMA: VERIFICAR
QUE SOLO LOS ACTORES CON ACCESO AL SISTEMA
Y A LA APLICACIN ESTN HABILITADOS PARA
ACCEDERLA.
REAS:
SEGURIDAD DEL SISTEMA, INCLUYENDO
ACCESO A DATOS O FUNCIONES DE NEGOCIOS.
SEGURIDAD DEL SISTEMA, INCLUYENDO
INGRESOS Y ACCESOS REMOTOS AL SISTEMA

Garantiza:
Que los usuarios estn restringidos a funciones especficas o su acceso est
limitado nicamente a los datos que est autorizado a acceder.
Que solo aquellos usuarios autorizados a acceder al sistema son capaces de
ejecutar las funciones del sistema .
Tambin garantiza Objetivos especficos de seguridad de cada sistema.

Tcnicas:
1.-Identificar cada tipo de usuario y las
funciones y datos a los que se debe autorizar.
2.-Crear pruebas para cada tipo de usuario y
verificar cada permiso, creando transacciones
especficas para cada tipo de usuario.
3.-Modificar tipos de usuarios y volver a
ejecutar las pruebas.

PRUEBAS DE ESFUERZO
Las pruebas de esfuerzo estn diseadas para confrontar
un sistema con situaciones anormales, estas pruebas
ejecuta un sistemas de tal manera que requiera una
frecuencia o un volumen anormal de recursos del mismo
sistema.
La persona que aplica esta prueba trata de sobre cargar el
programa.
Una variante de la prueba de resistencia es una tcnica
denominada prueba de sensibilidad.

PRUEBAS DE RENDIMIENTO
La pruebas de rendimiento estan diseadas
para probar el desempeo del software en
tiempo de ejecucin dentro del contexto de un
sistema integrado
Se aplica en todos los pasos del proceso de la
prueba incluso al nivel de la unidad, el
desempeo de un modulo individual
debe
evaluarse mientras se realizan las pruebas.

PRUEBAS DE DESPLIEGUE
En muchos casos el software debe ejecutarse en varias plataformas y bajo mas
de un entorno de sistema operativo.
La prueba de despliegue, en ocasiones llamada prueba de configuracin, ejercita
el software en cada entorno en el que debo operar, adems examina todos los
procedimientos de instalacin y el software de instalacin especializado.

EL ARTE DE LA DEPURACION
LA DEPURACION OCURRE COMO
CONSECUENCIA DE LAS PRUEBAS EXITOSAS
ESTO ES CUANDO EN UN CASO DE PRUEBA
SE DESCUBRE UN ERROR LA DEPURACION
ES EL PROCESO QUE DA COMO RESULTADO
LA REMOCION DEL ERRO

EL PROCESO DE DEPURACION

LA DEPURACION NO ES UNA PRUEBA PERO

ESTA OCURRE CON FRECUENCIA COMO
CONSECUENCIA DE UNA PRUEBA.

RR
O
C

EC
SP
SO
AS

CA

PUEBRAS
DE
REGRESION

US

PR

UE
BA
S

Casos
de
prueba

HO

AD
IC
IO
N

SA

AL
ES

RESULTADOS

NE
O
I
C

DEPURACION

CAUSAS
IDENTIFICADA
S

CONSIDERACIONES PSICOLOGICAS
ESTRATEGIAS DE DEPURACION

ESXISTEN 3 ESTRATEGIAS DE DEPURACION 1)FUERZA BRUTA,

2)VUELTA ATRS(BACKTRACKING), 3)ELIMINACION DE CAUSAS
TACTICAS DE DEPURACION
DEPURACION AUTOMATIZADA
EL FACTOR HUMANO

 CORRECCION DEL ERROR

UNA VEZ ENCONTRADO EL ERROR DEBE CORREGIRSE PERO
COMO YA SE SEALO LA CORRECCION DE UN ERROR PUEDE
INTRODUCIR OTROS ERRORES Y POR TANTO HACER MAS
DAO QUE BIEN.
VAN VLECK SUGIERE 3 PREGUNTAS SIMPLES QUE DEBEN
PLANTEARSE ANTES DE HACER LA CORRECION

1.

LA CAUSA DEL ERROR SE REPRODUCE EN OTRA PARTE

DEL PROGRAMA?

2.

QUE SIGUIENTE ERROR PUEDE INTRODUCIRSE CON LA

CORRECCION QUE ESTA A PUNTO DE REALIZAR?

3.

QUE DEBIO HACERSE PARA EVITAR ESTE ERROR DESDE

EL PRINCIPIO?