ANLISIS DINMICO DEL SOFTWARE: PRUEBAS

1. Conceptos Generales de Evaluacin

Anlisis dinmico del software: pruebas

1.1.
-

1.2.

Introduccin
Objetivos ideal de la Ingeniera del Software.
o Sistemas de calidad.
o Dentro de presupuesto
o A tiempo
Necesidad de la evaluacin

Coste de reparacin del software

1.3.

Papel de las pruebas de sw

Actividades de control y garanta de calidad del software:

1.4.

Preventivas: Buenos hbitos de construccin del software.

Correctivas (Evaluacin de sw):
o Anlisis esttico
Cualquier producto sw
o Anlisis dinmico
Solamente cdigo
Error, falta y fallo
Error: Los del ser humano.
Falta: Error escrito en algn producto software.
Fallo: El software no se comporta del modo deseado.

2. Introduccin a las Pruebas de Software

2.1.

Niveles de madurez
Nivel 0: Prueba es igual a depuracin.
Nivel 1: Demostrar que el software funciona.
Nivel 2: Demostrar que el software no funciona.
Nivel 3: Reducir el riesgo de que el software no funcione.
Nivel 4: La prueba es una disciplina mental que conduce a
software de bajo riesgo.

2.2.
-

Definicin de prueba
Proceso de ejecutar un programa o sistema con la intencin de
encontrar defectos.
Cualquier actividad dirigida a evaluar un atributo o capacidad de
un programa o sistema y determinar que alcanza los resultados
requeridos.

2.3.
Principios de las pruebas
Las pruebas son el proceso de ejecutar un programa/ sistema con
la intencin de descubrir defectos en el software.
Se deben definir las salidas o resultados esperados de los casos
de prueba.
Los casos de prueba se escriben para condiciones de entradas
vlidas/no vlidas y esperadas/inesperadas.
Un programador debe evitar probar su propio programa.
Un equipo no debe probar sus propios programas.
La probabilidad de la existencia de ms defectos en una parte del
software es proporcional al nmero de defectos ya encontrados
en dicha parte.
Una razn para la prueba es prevenir deficiencias antes de que
ocurran.
La prueba est basada en el riesgo.
2.4.

El proceso de pruebas
Diseo de las pruebas.
Generacin y especificacin de los casos de prueba.
Definicin de los procedimientos de la prueba.
Ejecucin de los casos de prueba.
Comparacin de los resultados obtenidos con los esperados.
Identificacin de fallos en el sistema.
Realizacin de un informe de la prueba.
Identificacin y correccin de las faltas que causaban los fallos.

3. Tcnicas de Pruebas de Software

3.1.
Problemtica
La prueba exhaustiva no es viable.
Necesidad de predecir de forma precisa la calidad del sistema
software.
Necesidad de tcnicas que ayuden a la seleccin de casos de
prueba.

3.2.

Clasificacin de familias

3.3.
Tcnicas aleatorias
El programa se ve como una caja negra.
o Puramente aleatorias. Seleccionan casos al azar.
o Atendiendo a la intuicin.
o Atendiendo a algn perfil de operacin.
3.4.

Tcnicas de flujo de control

El programa se ve como una caja blanca.

o Cobertura de sentencias.
o Cobertura de decisin.
o Cobertura de condicin.
o Cobertura de decisin/condicin.
o Cobertura de condicin mltiple
Prueba del camino bsico
Camino: Secuencia de sentencias encadenadas desde la entrada
del programa hasta su salida.
Disea casos para caminos independientes:
o Todas las sentencias se ejecutan al menos una vez.
o Las condiciones son probadas para valores verdadero y falso.
Se basa en la medida de complejidad ciclomtica de Mc Cabe.
Elementos para representar el programa como grafo de flujo.
Clculo de la complejidad ciclomtica.
Se debe determinacin de un conjunto bsico de caminos
linealmente independientes.
Derivacin de los casos de prueba: Cada caso de prueba se
disear de tal modo, que corresponda a cada uno de los caminos
elegidos.
PROBLEMA: El nmero ciclomtico no da idea acerca de la
complejidad de los datos.
3.5.
Tcnicas de flujo de datos
El programa se ve como una caja blanca.
Se generan casos atendiendo al flujo de los datos por el programa.
Definiciones:
Camino simple.

 Camino libre de bucles.

Camino completo.
Camino libre de definiciones (i,j).
3.6.

Tcnicas de mutacin

El programa se ve como una caja blanca.

Se generan mutantes atendiendo a las posibles faltas existentes en el
programa.
Se utiliza el conjunto de operadores de mutacin asociado al lenguaje
de programacin utilizado.
Generacin de casos de prueba a partir de los mutantes obtenidos.
Se generan tantos casos de prueba como mutantes se quieran
matar.
Tcnicas.
o Mutacin fuerte.
o Mutacin dbil.
o Mutacin selectiva.
3.7.

Tcnicas funcionales

El programa se ve como una caja negra.

Se realizan pruebas sobre la interfaz del programa.
No es necesario conocer la lgica del programa, nicamente la
funcionalidad que debe tener.
Intentan ejecutar casos de prueba relativos a posibles faltas en el
programa.
Divisin del dominio de entrada en clases vlidas y no vlidas.
Clases de equivalencia
Se examina cada condicin de entrada y se divide en dos o ms
grupos, identificando dos tipos de clases:
o Clases de equivalencia vlidas.
o Clases de equivalencia no vlidas.
Se suelen representar mediante tablas.
Proceso heurstico.
Identificacin de casos de prueba
Para la tcnica de particin en clases de equivalencia:
o Asignar un nmero nico a cada clase de equivalencia.
o Escribir un caso que cubra tantas clases vlidas no incorporadas
como sea posible hasta que se cubran todas las clases de
equivalencia vlidas. N
o Escribir un caso que cubra una sola clase no vlida no incorporada
hasta que se cubran todas las clases de equivalencia no vlidas.
Para el anlisis de valores lmite:
o Condiciones lmite: Aquellas que se hallan en los mrgenes de
las clases de equivalencia tanto de entrada como de salida.
o Se seleccionan uno o ms elementos tal que los mrgenes de la
clase se sometan a prueba.

4. Organizacin de las Pruebas de Software

4.1.
Problemtica
La depuracin se complica a medida que aumenta el tamao del
software.
Necesidad de abordar la etapa de pruebas en fases para facilitar
dicha tarea.
Se comenzar a nivel de mdulo y se progresar hacia el sistema
completo.
4.2.
Pruebas unitarias
Objetivo: Comprobar los productos resultantes de la codificacin.
Cada mdulo se prueba por separado y por la persona que lo
cre.
4.3.
Pruebas de integracin
Objetivo: Comprobar los productos del diseo.
Tipos de integracin
o Incremental.
o No incremental
Tipos de Pruebas de integracin
Incremental Ascendente.
Incremental Descendente.
No Incremental.
4.4.
Pruebas de sistema
Objetivo: Comprobar que el sistema integrado de hardware y
software cumple con los requisitos especificados.
Se realizan primero en la plataforma de desarrollo -> .
Luego en la Plataforma del cliente ->
4.5.
Pruebas de aceptacin
Objetivo: Comprobar que el sistema cubre las necesidades de los
usuarios finales.
Participacin activa del usuario.
Estn enfocadas para probar los requisitos de usuario.
4.6.
Pruebas de regresin
Regresin: Repeticin selectiva de pruebas para detectar fallos
introducidos durante la modificacin de un sistema o componente.
4.7.
Tipos de organizaciones
La organizacin de las pruebas depende del ciclo de vida
utilizado.
Ciclo de vida en cascada => Aplicacin trivial.
4.8.

Resumen

EJEMPLO CASO DE PRUEBAS Y DATOS DE PRUEBA

N

Nombre

Objetivo

Actor

01

Registrar
Proyecto

Usuario que
registro el
proyecto

02

Modificar
Proyecto

Registrar la informacin
necesaria de un nuevo
proyecto para la asignacin
del presupuesto.
Permitir al usuario modificar
la informacin del proyecto.

03

Visualizar
Proyectos.

Permitir que el encargado

del presupuesto, usuario y
directivos puedan visualizar
la informacin que posee el
Proyecto.

04

Congelar
Proyectos

Desactivar el proyecto ya
sea por falta de presupuesto
o por nueva planificacin.

05

Eliminar
Proyectos

Eliminar el registro de un
proyecto para poder ingresar
nueva informacin
Caso de Prueba
Elaborado por: Pez Jahir

Usuario que
registro el
proyecto
Usuario que
registro el
proyecto,
directivo,
encargado
de
presupuesto
.
Directivo
encargado y
Usuario que
registro el
proyecto
Usuario que
registro el
proyecto
001

Responsa
ble
Luis Ushia

Alexis
Males
Henry
Suntaxi

Jahir Pez

Eduardo
Vera

Cdigo de Identificacin:

Registrar Proyecto: CP01

Nombre del Proyecto:

APLICACIN WEB PARA AGILITAR EL SEGUIMIENTO

PRESUPUESTARIO DEL PLAN OPERATIVO ANUAL
POA DE LA UNIVERSIDAD DE LAS FUERZAS
ARMADAS ESPE.

Descripcin (Alcance y
Objetivos):
Requisitos asociados
Variables de Entrada
(Inputs):
Flujo normal del evento

Se mostrara el formulario en el cual el usuario deber

llenar los campos para registrar el proyecto

Resultado esperado:

Flujo alterno
Resultado alternativo
esperado:

RF001
Verificacin del navegador (webkit)
1.- Ingresar el url ej. localhost/ al browser del
navegador.
2.- Verifica si el navegador soporta la tecnologa
html.
3.- Muestra el formulario del registro de proyecto
Muestra el formulario, as como tambin todos los
mdulos para la insercin de datos por parte del
usuario
En caso de que la url no sea ingresada de manera
correcta, la aplicacin no se mostrar.
En caso de que el navegador no tenga soporte para
webkit simplemente no se mostrar la interfaz de
usuario y se presentar un mensaje Your browser
does not appear to support HTML5. Try upgrading
your browser to the latest version..
Evaluacin de prueba

Fecha de Ejecucin:
Ejecutado por:
Lugar de ejecucin
Resultados obtenidos
Observaciones:
Gravedad del error:
Notas del programador
Estado:
Acciones de correccin:
Corregido por:

Reporte de Errores e Inconsistencias

Nombre del
Aplicacin Web para agilitar el seguimiento
Proyecto:
presupuestario del Plan Operativo Anual POA de la
Universidad de las Fuerzas Armadas ESPE
Fecha de pruebas: 01-06-2014
Mdulos:
Mdulo gestin de Informacin del Proyecto.
Analista:
Ing.
Responsable:
Jahir Pez
Alexis Males
Henry Suntaxi
Eduardo Vera
Luis Ushia
Fecha de revisin: 06-07-2016
Identifi Descripcin de prueba.
Descripcin del
Acciones
cacin
error.
de
Caso
correccin
Prueba
CP-001
Se mostr el formulario en el
El Tamao de la letra
N/A
cual el usuario deber
es muy pequea y los
ingresar la informacin para
colores muy llamativos
registrar un nuevo proyecto

PRUEBA CAJA BLANCA

CDIGO FUENTE

DIAGRAMA DE FLUJO

GRAFO

RUTAS
R1: 1,2,3,4,6,7
R2: 1,2,3,4,5,3,4,6,7

COMPLEJIDAD CICLOMATICA
Se puede calcular de las siguientes formas:

V(G) = nmero de nodos predicados(decisiones)+1 = 2

V(G) = A N + 2 = 7 7 + 2 = 2
DONDE:
P: Nmero de nodos predicado
A: Nmero de aristas
N: Nmero de nodos

PRUEBA CAJA BLANCA

Ingresar proyecto
Requisito tomado para las pruebas de caja negra: Requisito Funcional
1 (RF001)
Una vez que se haya ingresado a la aplicacin desde la web, procedemos a
ingresar la informacin de un nuevo proyecto.

Una vez ingresado a la informacin se presentara de la siguiente manera:

Entrada de datos para el registro de un proyecto:

Palabras.
Frases.
Letras.
Fechas.
Nmeros

Si no se ingres correctamente la informacin o desea desecharla

podr eliminar la informacin ingresada

Si la informacin ingresada es correcta y acorde a lo que desea el

usuario podr enviarla a los diferentes directivos para su posterior
asignacin o negacin de presupuesto:

PRUEBA DE COBERTURA
Validacin de campos ingresar proyectos
CDIGO FUENTE

GRAFO

1 Cobertura de sentencia Co
Sentencia 1: 1, 2, 3, 4, 5, 6
Sentencia 2: 1, 5, 6

CO=

Numero de sentencias visitadas

3
100= 100=50
Numero total de sentencias
6

2 Cobertura de rama Cb
Rama 1: 1, 2, 3, 4, 6
Rama 2: 5, 6
Cr

Numero de ramas visitadas

5
100= 100=0.83
Numero total de ramas
6

3 Cobertura de camino Cpt

Camino 1: 1erecha
Camino 2: Izquierda
Cc

Numero de caminos visitados

1
100= 100=50
Numero total de caminos
2