Tema1 pruebasSistemasSoftware PDF

IngenieradelSo8wareII
Tema01.ConstruccinyPruebasdeSo8ware
CarlosBlancoBueno
DPTO.DEMATEMTICAS,ESTADSTICAY
COMPUTACIN
carlos.blanco@unican.es
EstetemasepublicabajoLicencia:
CreaOveCommonsBYNCSA3.0
Objetivos
Construccin del Software

Comprender que construir software engloba muchas ms actividades que
la de escribir cdigo
Conocer los principios de la construccin de software y las actividades
ms significativas
Verificacin y Validacin
Conocer el papel que juegan la verificacin y validacin del software yy,
dentro de ellas, las pruebas
Pruebas
Tener una visin general de los niveles, clases, tcnicas y actividades de
pruebas del software
Pruebas OO
Aprender las principales estrategias y mtodos de pruebas para sistemas
OO
Aprender a disear casos de pruebas para OO
Carlos Blanco- IS2 1.2
Contenido
1. Construccin del Software 4. Pruebas de Sistemas OO
Conceptos Introduccin
Principios Estrategias para sistemas OO
Proceso de Construccin Diseo de casos de prueba OO
Mtodos de ppruebas OO
2
2. Verificacin y Validacin
Objetivos
Actividades
Tcnicas
3. Pruebas
Conceptos
Proceso de Pruebas
Niveles de Prueba
Estrategia de Aplicacin
Tcnicas de Prueba

Bibliografa
Bibliografa
Piattini (2007).
(2007) (Cap.
(Cap 10)
Sommerville (2005). (Captulo 22 y 23)
Jacobson,, I.,, Booch,, G.,, and Rumbaugh,g , J. (2000):
( ) El Proceso
Unificado de Desarrollo. Addison-Wesley. (Captulo 11)
Pressman, R. (2005): Ingeniera del Software: Un Enfoque Prctico. 6
Edicin. McGraw
McGraw-Hill.
Hill. (Captulos 13 y 14)
Pfleeger (2002). (Caps. 7, 8 y 9)
IEEE Computer Society (2004). SWEBOK - Guide to the Software
E i
Engineering
i Body
B d off Knowledge,
K l d 2004.
2004 (C
(Captulos
t l 4 y 5)
http://www.swebok.org/

1.Construccin
1. Construccin
Se refiere a la creacin detallada de software operativo

mediante una combinacin
de
Codificacin
Verificacin
Pruebas Unitarias y de Integracin
Depuracin
Diseo Construccin Pruebas

1.Construccin
Diseo Construccin Pruebas
Los lmites entre Construccin,

Construccin Diseo y Pruebas varan
dependiendo del ciclo de vida que se usa en cada proyecto
Aunque
q bastante esfuerzo de diseo p puede realizarse antes de
empezar las actividades de construccin, otro debe de realizarse en
paralelo
Igualmente, algunos tipos de pruebas se realizan durante la
construccin, mientras que otras se hacen a posteriori
Durante la Construccin se generan las cantidades ms

grandes de artefactos software (ficheros de cdigo,
contenidos, casos de prueba, etc.)
Esto origina necesidades de gestin de configuracin
1.Construccin
Lenguajes de Construccin
Formas de especificar una solucin a un problema ejecutable por una
computadora
Pueden ser de varias clases:
De
D CConfiguracin
fi i
Permiten elegir entre un conjunto predefinido de opciones para crear
instalaciones de software nuevas o particularizadas (ej. ficheros de
configuracin de Windows o UNIX)
De Toolkits
Permiten construir aplicaciones a partir de un Toolkit (conjunto
integrado piezas reutilizables de aplicacin especfica)
- Scripts: definidos de forma explcita. (ej. JavaScript).
- APIs: definidos de forma implcita, ya que se implican a partir de la
interfaz pblica de un Toolkit. (ej. API de Office).
De Programacin
Tipos de notaciones: Lingstica (cadenas de texto con palabras),
Formal (expresiones de tipo matemtico), Visual (smbolos grficos)

1.Construccin
Relacin de los modelos con el cdigo fuente
Ingeniera directa
Refactori-
zacin
Transformacin
de Modelos
I
Ingeniera
i inversa
i
Modelos Cdigo Fuente

1.Construccin - Principios
Los principios fundamentales de la construccin de

software son:
Minimizar la Complejidad
Anticipar los Cambios
Pensar en la Verificacin posterior
Aplicar Estndares



software son:
Minimizar la Complejidad
Escribiendo cdigo sencillo y fcil de leer
Utilizando estndares
Tcnicas de codificacin
Tcnicas de aseguramiento de calidad
Anticipar los Cambios
El software se ve afectado por los cambios en su entorno y est
destinado a cambiar a lo largo del tiempo
Aplicacin de tcnicas especficas


software son:
Pensar en la Verificacin posterior
Construir de forma que los fallos puedan ser encontrados lo antes
posible (al codificar, hacer pruebas u operar el sistema)
Tcnicas:
Seguir estndares de codificacin
Hacer pruebas unitarias
Organizar
g el cdigo
g para
p soportar
p pruebas
p automatizadas
Restringir el uso de tcnicas complejas


software son:
Aplicar Estndares
Directamente a la construccin del software:
Formatos de comunicacin (documentos, contenidos).
Versiones estndares de lenguajes de programacin (Java, C++, C#,).
Reglas de codificacin (nombres de variables,
variables comentarios,).
comentarios )
Notaciones de diagramas (UML,).
Intercambio entre herramientas (XLM,).
En
E un proyecto:
t
Externos: propuestos por organismos de estandarizacin (ISO, ANSI,
AENOR), consorcios industriales (OMG), asociaciones profesionales (IEEE,
ACM).
ACM)
Internos: creados por la propia organizacin.

1.Construccin - Proceso
Desde una perspectiva de proceso,

los esfuerzos ms significativos que se realizan durante la
construccin de software son:
Planificacin
Manejo de Excepciones
Codificacin
C difi i
Pruebas
Aseguramiento de Calidad
Reutilizacin
Integracin

Planificacin
Elegir el mtodo de construccin
Granularidad y alcance con el que se realizan los requisitos
Orden en el que se abordan
Establecer el orden en el que los componentes se crean e integran
Asignar tareas de construccin a personas especficas
Manejo de Excepciones
Mientras se construye un edificio, los albailes deben hacer pequeos
ajustes respecto de los planos
De igual forma, los constructores de software deben hacer
modificaciones y ajustes,
j , unas veces pequeas
p q y otras no tanto,,
respecto de los detalles del diseo de un software

Codificacin
La escritura del cdigo fuente es el principal esfuerzo de construccin
de software
Aplicar tcnicas para crear cdigo fuente comprensible (reglas de asignacin

de nombres y de formato del cdigo, clases, tipos enumerados, constantes
etiquetadas,)
q , )
Manejar condiciones de error (errores previstos e imprevistos, excepciones)
Prevenir brechas de seguridad a nivel de cdigo (llenado de buffers, overflow
de ndices de vectores
vectores, ))
Uso eficiente de recursos escasos (hilos, bloqueos en bases de datos, )
Organizar
g el cdigo
g fuente ((sentencias,, rutinas,, clases,, paquetes,
p q , ))
Documentar el cdigo

Pruebas
Frecuentemente realizadas p por los mismos que
q escriben el cdigo
g
El propsito de estas pruebas es reducir el tiempo entre el momento
en el que los fallos se insertan en el cdigo y el momento en que son
detectados.
Pruebas Unitarias
Pruebas de Integracin
Tcnicas para asegurar la calidad del cdigo

Pruebas (Unitarias y de Integracin)
Escribir las pruebas primero (test first development)
Ejecucin lnea a lnea (code stepping)
Uso de aserciones
Depuracin (debugging)
Revisiones
Anlisis esttico

Reutilizacin
Implica ms cosas que crear y usar bibliotecas de activos
Es necesario oficializar la prctica de reutilizacin integrndola en los
ciclos de vida y metodologas de los proyectos
A ti
Activos reutilizables:
tili bl
Planes de proyecto, Estimaciones de coste
Especificaciones de requisitos, Arquitecturas, Diseos, Interfaces
Cdi fuente
Cdigo f t (libreras,
(lib componentes,)
t )
Documentacin de usuario y tcnica, Casos de prueba, Datos,
Integracin
g
De rutinas, clases, componentes y sub-sistemas construidos de forma
separada, y con otro(s) sistema(s)
Para ello puede ser necesario:
Planificar la secuencia en que se integrarn los componentes
Crear andamios para soportar versiones provisionales
Determinar el nivel de pruebas y aseguramiento de calidad realizado sobre los componentes
antes de su integracin
2.Verificacin y Validacin
2. Verificacin y Validacin
VV es un conjunto de procedimientos, actividades,

tcnicas
y herramientas que se utilizan, paralelamente al
desarrollo de software, para asegurar que un producto
software resuelve el problema inicialmente planteado
Las pruebas son una familia de tcnicas de VV

Objetivos de la VV:
Acta
A t sobre
b los
l productos
d t intermedios
i t di que se generan durante
d t ell
desarrollo para:
Detectar y corregir cuanto antes sus defectos y las
desviaciones respecto al objetivo fijado
Disminuir los riesgos,
riesgos las desviaciones sobre los
presupuestos y sobre el calendario o programa de tiempos
del proyecto
Mejorar la calidad y fiabilidad del software
Valorar rpidamente los cambios propuestos y sus
consecuencias

2.Verificacin y Validacin IEEE 1012-2004: IEEE Standard for
Software Verification and Validation
1. Propsito
2. Documentos de referencia
3. Definiciones
4. Visin general de la verificacin y validacin

La visin del desarrollo de 4.1 Organizacin
software como un conjunto de 4.2 Programa de tiempos
4.3 Esquema de integridad de software
fases con posibles 4.4 Resumen de recursos
realimentaciones facilita la VV 4.5 Responsabilidades
4.6 Herramientas, tcnicas y metodologas
5. Verificacin y validacin en el ciclo de vida
5.1 Gestin de la VV
Al inicio del proyecto es 5 2 VV en el proceso de adquisicin
5.2
necesario hacer un 5.3 VV en el proceso de suministro
5.4 VV en el proceso de desarrollo:
Plan de VV del Software 5.4.1 VV de la fase de concepto
5.4.2 VV de la fase de requisitos
(estructura del plan segn el estndar 5 4 3 VV de la fase de diseo
5.4.3
IEEE 1012) 5.4.4 VV de la fase de implementacin
5.4.5 VV de la fase de pruebas
5.4.6 VV de la fase de instalacin
Las actividades de VV se
5.5 VV de la fase de operacin
5 6 VV ddell mantenimiento
5.6 i i
realizan de forma iterativa 6. Informes de la VV del software
7. Procedimientos administrativos de la VV
durante el desarrollo 7.1 Informe y resolucin de anomalas
7.2 Poltica de iteracin de tareas
7.3 Poltica de desviacin
7.4 Procedimientos de control
7.5 Estndares, prcticas y convenciones.
Carlos Blanco- IS2 8. Requisitos de documentacin para la VV
Actividades de VV
VERIFICACIN VALIDACIN
Estamos construyendo Estamos construyendo el
correctamente el producto correcto?
producto?
El software
ft Estar
E t conforme
f a su Hacer llo que ell usuario
H i
debe especificacin realmente quiere
Objetivo Demostrar la consistencia, Determinar la correccin del
complecin y correccin de los producto final respecto a las
artefactos de las distintas necesidades del usuario
fases (productos intermedios)
Tcnica ms Revisiones Pruebas
utilizada

Tcnicas Estticas (Revisiones) vs Dinmicas (Pruebas)
Revisiones
Especificacin Diseo Especificacin Diseo

Cdigo
De Requisitos Arquitectural Formal Detallado
Prototipo Pruebas

Las revisiones software pueden ser

Informales
No hay procedimientos definidos, por lo que la revisin se realiza de la
forma ms flexible posible.
Ventajas menor coste y esfuerzo,
f preparacin
corta, etc.
Desventajas Detectan menos defectos
Semi formales
Semi-formales
Se definen unos procedimientos mnimos a seguir (walkthroughs)
Formales (Inspecciones)
Se define completamente el proceso
Revisin en detalle, por una persona o grupo distintos del autor, para:
Verificar si el producto se ajusta a sus especificaciones o atributos de
calidad y a los estndares utilizados en la empresa
Sealar las desviaciones sobre los estndares y las especificaciones
Recopilar
p datos qque realimenten inspecciones
p posteriores
p (defectos
(
recogidos, esfuerzo empleado, etc.)

Informes de
Inspeccin
Ejemplo de
Formulario

3.Pruebas
3. Pruebas
La manera adecuada de enfrentarse al reto de la

calidad es la prevencin
! Mas vale pprevenir qque curar !
Las pruebas son tcnicas de comprobacin dinmica

Siempre implican la ejecucin del programa
Permiten:
Evaluar la calidad de un producto
Mejorarlo identificando defectos y problemas

3.Pruebas - Conceptos
Ideas preconcebidas sobre las Pruebas:
Pueden detectar las pruebas la ausencia de errores?
Se puede realizar una prueba exhaustiva del software

(probar todas las posibilidades de su funcionamiento)?
Cundo se descubre un error la prueba ha tenido xito o

ha fracasado?

Limitaciones Tericas y Prcticas de las Pruebas

Aforismo j s a Probar
o s o de Dijkstra: oba programas
p og a as sirva
s a para
pa a demostrar
de ost a laa presencia
p ese c a de
errores, pero nunca para demostrar su ausencia.
En el mundo real no es posible hacer pruebas completas
Se considera que existen infinitos casos de prueba y hay que buscar un equilibrio
(recursos y tiempo limitados)
Seleccin de los valores de entrada
Seleccin de un conjunto finito de casos de prueba
El criterio de seleccin depende de la tcnica de pruebas
No siempre son suficientes, ya que un sistema complejo podra reaccionar de
distinta manera ante una misma entrada dependiendo de su estado
Comparacin de la salida obtenida con la esperada
Decidir si los resultados observados son aceptables o no
Segn expectativas de los usuarios, especificaciones, requisitos,
Orculo
Agente (humano o no) que decide cuando un programa acta correctamente en una
prueba dada, emitiendo un veredicto de correcto o fallo
Relacin entre Error, Defecto y Fallo:

Error Sistema de gestin de aeropuerto
Equivocacin
d l programador
del d
2+2=5
Accidente
(
(seguridad)
id d)
Defecto (calidad)
S Aproximacin
S.Aproximacin
Xyx//
???
Fallo (fiabilidad)

Ejemplo de las dificultades que se presentan
if (A+B+C)/3 == A
then print ((A
A, B y C son iguales
iguales))
else print (A, B y C no son iguales)
Son suficientes estos dos casos de prueba?

Caso 1: A=5; B=5; C=5;
Caso 2: A=2; B=3; C=7;
Cules otros seran necesarios en caso negativo?

3.Pruebas - Proceso

3.Pruebas - Niveles
El mbito o destino de las pruebas del software

puede variar en tres niveles:
Un mdulo nico
PRUEBAS UNITARIAS
Un grupo de mdulos (relacionados por propsito, uso,
comportamiento o estructura)
PRUEBAS DE INTEGRACIN
Un sistema completo
PRUEBAS DE SISTEMA

3.Pruebas - Niveles
Pruebas Unitarias
Verifican el funcionamiento aislado de piezas de software que
pueden ser probadas de forma separada
Subprogramas/Mdulos individuales
Componente que incluye varios subprogramas/mdulos
Estas pruebas suelen llevarse a cabo con:
Acceso al cdigo fuente probado
Ayuda de herramientas de depuracin
Participacin (opcional) de los programadores que escribieron el cdigo

3.Pruebas - Niveles
Pruebas Unitarias
De dnde obtener buenos casos de prueba unitarias?
De las mquinas o diagramas de estado

3.Pruebas - Niveles
Verifican la interaccin entre componentes del sistema software
Estrategias:
Guiadas por la arquitectura
Los componentes se integran segn hilos de funcionalidad
Incremental
Se combina el siguiente mdulo que se debe probar con el conjunto de
mdulos
d l que ya han
h sido
id probados
b d
Incremental Ascendente ((Bottom-Up)

p) A
1. Se comienza por los mdulos hoja (pruebas unitarias)
2. Se combinan los mdulos segn la jerarqua
3. Se repite en niveles superiores B C D
I
Incremental
t lDDescendente
d t (Top-Down)
(T D )
Primero en profundidad, completando ramas del rbol E F G
Primero en anchura, completando niveles de jerarqua

3.Pruebas - Niveles
Incremental Ascendente (Bottom-Up)
(Bottom Up)
1. Unitarias de E, F, G y D
2. Integracin de (B con E), (C con F) y (C con G)
3. Integracin de (A con B), (A con C) y (A con D)
3 fase A
2 fase B C D
1 fase E F G
Incremental Descendente (Top-Down)

Primero en profundidad, completando ramas del rbol
(A, B, E, C, F, G, D)
Primero en anchura, completando niveles de jerarqua
(A, B, C, D, E, F, G)
3.Pruebas - Niveles
Pruebas de Sistema
Verifican el comportamiento del sistema en su conjunto
Los fallos funcionales se suelen detectar en los otros dos niveles
anteriores (unitarias e integracin)
Este nivel es ms adecuado para comprobar requisitos no
funcionales
Seguridad,
Seguridad Velocidad,
Velocidad Exactitud
Exactitud, Fiabilidad
Tambin se prueban:
Interfaces externos con otros sistemas
Utilidades
Unidades fsicas
Entorno operativo

3.Pruebas Clasificacin segn finalidad
Clasificacin de pruebas segn su finalidad:

Comprueban que las especificaciones funcionales estn
implementadas correctamente
Pruebas Unitarias y de Integracin
Comprueban los requisitos no funcionales
Pruebas de Sistema
Comprueban el comportamiento del sistema frente a los requisitos
del cliente (suele participar el mismo cliente o los usuarios)
Pruebas de Aceptacin
Comprueban el comportamiento del sistema frente a los requisitos de
configuracin hardware
Pruebas de Instalacin
Pruebas en grupos pequeos de usuarios potenciales antes de la
difusin del software
Pruebas alfa (en la misma empresa) y beta (fuera)

3.Pruebas Estrategia de Aplicacin
Relacin entre las Actividades de Desarrollo y las Pruebas

En qu orden han de escribirse y de realizarse las
actividades de pruebas ?

3.Pruebas Estrategia de Aplicacin
Relacin entre las Actividades de Desarrollo y las Pruebas

En qu orden han de escribirse y de realizarse las
actividades de pruebas ?
Pruebas de
Requisitos
aceptacin
Diseo arquitectnico Pruebas de sistema
Escribir Ejecutar
pruebas pruebas
Diseo detallado Pruebas de integracin
Cdigo Pruebas unitarias

3.Pruebas Tcnicas
Tcnicas de Prueba
Principio bsico:
Intentar ser lo ms sistemtico posible en identificar un conjunto
representativo de comportamientos del programa
Determinados por subclases del dominio de entradas
entradas, escenarios,
escenarios estados
estados,
Objetivo
romper el programa, encontrar el mayor nmero de fallos posible
De forma general, existen dos enfoques diferentes:
Caja Negra (Funcional)
Los casos de prueba se basan slo en el comportamiento de entrada/salida
Caja Blanca (Estructural)
Basadas en informacin sobre cmo el software ha sido diseado o codificado
Caja negra Caja blanca

Entrada Salida Entrada Salida
Funciones

3.Pruebas Tcnicas
Caja Negra
Orientadas a los requisitos funcionales
x1 y1
x2 f y2
xn yn
yi=f(xi), para todo i?

Buscan asegurar que:
Se ha ingresado toda clase de entrada
Que la salida observada = esperada

3.Pruebas Tcnicas
Particionamiento Equivalente
Ell dominio
d de
d las
l entradas
d se divide
d d en subconjuntos
b
equivalentes respecto de una relacin especificada
(clases de equivalencia):
La prueba de un valor representativo de una clase permite
suponer razonablemente que el resultado obtenido ser el
mismo que para otro valor de la clase
Se realiza un conjunto representativo de casos de prueba
para cada
d clase
l de
d equivalencia
i l i

3.Pruebas Tcnicas
Ejemplo:
j l Entrada
d de
d un Programa
Cdigo de rea: Nmero de tres cifras que no comienza ni por 0 ni
por 1
Nombre: Seis caracteres
Orden: cheque, depsito, pago factura, retirada de fondos
Condicin de entrada Clases vlidas Clases invlidas

Cdigo
g rea
Nombre para identificar la

operacin
Orden

3.Pruebas Tcnicas
Ejemplo:
j l Entrada
d de
d un Programa
Cdigo de rea: Nmero de tres cifras que no comienza ni por 0 ni
por 1
Nombre: Seis caracteres
Orden: cheque, depsito, pago factura, retirada de fondos
Condicin de entrada Clases vlidas Clases invlidas

Cdigo
g rea ((1)) 200cdigo
g 999 ( ) cdigo
(2) g <200
(3) cdigo >999
(4) no es nmero
Nombre para identificar la (5) seis caracteres (6) menos de 6 caracteres
operacin (7) ms de 6 caracteres
Orden (8) cheque (12) ninguna orden vlida
(9) depsito
(10) pago factura
(11) retirada de fondos
3.Pruebas Tcnicas
Anlisis de Valores Lmite

Similar
S l a lal anterior pero los
l valores
l de
d entrada
d de
d los
l
casos de prueba se eligen en las cercanas de los lmites
de los dominios de entrada de las variables
Suposicin: Muchos defectos tienden a concentrarse
cerca de los valores extremos de las entradas
Extensin: Pruebas de Robustez, con casos fuera de los
dominios de entrada
Si aplicamos AVL en el ejemplo anterior qu valores para

los casos de prueba seleccionaramos?

3.Pruebas Tcnicas
Caja Blanca
De alguna
D l manera, me interesa
i t conocer la
l cobertura
b t alcanzada
l d por
mis casos de prueba dentro de la unidad de prueba
x1 y1
x2 y2
xn yn

3.Pruebas Tcnicas
Criterios de Cobertura:
Cobertura de sentencias.
sentencias Que cada sentencia se ejecute al menos una vez.
vez
Cobertura de decisiones. Que cada decisin tenga, por lo menos una vez, un
resultado verdadero y, al menos una vez,, uno falso.
Cobertura de condiciones. Que cada condicin de cada decisin adopte el
valor verdadero al menos una vez y el falso al menos una vez.
Criterio de decisin/condicin. Que se cumplan a la vez el criterio de
condiciones y el de decisiones.
Criterio de condicin mltiple. La evaluacin de las condiciones de cada
decisin no se realiza de forma simultnea.
Descomposicin de then then

(a=1) (c=4)
una Decisin (a=1) and (c=4)
Multicondicional
else
l else

3.Pruebas Tcnicas
Grafos de Flujo
Utilizados para la representacin del flujo de control
La estructura de control sirve de base para obtener los casos de prueba
El diseo de casos de p
prueba tiene que
q estar basado en la eleccin de caminos
importantes que ofrezcan una seguridad aceptable de que se descubren defectos
x x
Secuencia Si x entonces
entonces... Hacer hasta x Mientras x hacer...
Hacer... hacer
(If x then...else...) (Do...until x) (While x do...)
3.Pruebas Tcnicas
Grafo de Flujo de un Programa (Pseudocdigo)

Abrir archivo;; 1
WHILE (haya registros) DO
2
IF (cliente) THEN
Mostrar cliente; 3
ELSE
Mostrar registro; 4 5
ENDIF;
Incrementar registro; 6
ENDWHILE;
Cerrar archivos. 7
Complejidad ciclomtica:
Indicador del nmero de caminos independientes de un grafo
Lmite mnimo de nmero de casos de prueba para un programa
Clculo de complejidad ciclomtica Posible conjunto de caminos

V(G) = arcos nodos + 2 127
V(G) = nmero de regiones cerradas 12346
V(G) = nmero de nodos condicin + 1 12356

3.Pruebas Tcnicas

Abrir archivos;
Leer archivo ventas, al final indicar no ms registros;
Limpiar lnea de impresin;
WHILE (haya registros ventas) DO
Total nacional = 0;
Total extranjero = 0;
WHILE (haya reg. ventas) y (mismo producto)
IF (nacional) THEN
Sumar venta nacional a total nacional
ELSE
Sumar venta extranjero a total extranjero
ENDIF;
ENDWHILE;
Escribir lnea de listado;
Limpiar rea de impresin;
ENDWHILE;
Cerrar archivos.

3.Pruebas Tcnicas
Ab i archivos;
Abrir hi 1
Limpiar lnea de impresin; 2
WHILE (haya registros ventas) DO
T t l nacional
Total i l = 0;
0
3
Total extranjero = 0;
WHILE (haya reg. ventas) y (mismo producto) 4
IF (nacional) THEN
S
Sumar venta
t nacional
i l a total
t t l nacional
i l 5
ELSE
Sumar venta extranjero a total extranjero 6
ENDIF;
L
Leer archivo
hi ventas,
t all final
fi l indicar
i di no ms
registros;
it 7a 7b
ENDWHILE;
Escribir lnea de listado; 8,9
Limpiar rea de impresin;
ENDWHILE
ENDWHILE;
10,11
Cerrar archivos.
12,13

3.Pruebas Tcnicas
Complejidad Ciclomtica
2
V(G)
( ) = a n + 2 = 14 11 + 2 = 5 3
V(G) = regiones = 5
V(G) = condiciones + 1 = 5 4
Un posible conjunto de caminos 5

1 2 (12, 13)
1 2 3 4 (10, 11) 2 6
1 2 3 4 5 (10, 11) 2
1 2 3 4 5 6 7a
7 (8,
(8 9) 7a 7b
1 2 3 4 5 6 7b (8, 9)
8,9
10,11
12,13

3.Pruebas Tcnicas
Otro criterio ms preciso clasifica las tcnicas de prueba segn la fuente a

partir de la que son generados los casos de prueba:
Experiencia del ingeniero de pruebas El campo de uso

Ad-hoc Perfil operacional
Exploratorias
E l i SRET (guiadas por objetivos de fiabilidad)
Especificaciones La naturaleza de la aplicacin
Particionamiento equivalente Orientado a Objetos
Anlisis
de valores lmite
Basado en Componentes
Tablas de decisin Basado en Web
Mquinas de estados finitos Interfaz de Usuario
Especificacin formal P
Programas C
Concurrentes
Aleatorias Conformidad de Protocolos
Estructura del cdigo Sistemas en Tiempo Real
Flujo de control Sistemas Crticos (seguridad)
Flujo de datos
Defectos que se quieren descubrir
Conjetura de errores
Mutacin
3.Pruebas Tcnicas
Basadas en la Experiencia
Add Hoc
Las pruebas dependen totalmente de la habilidad, intuicin y
experiencia con programas similares del ingeniero de pruebas
Exploratorias
A la vez, se lleva a cabo aprendizaje, diseo de pruebas y
ejecucin de pruebas
Las pruebas se disean, ejecutan y modifican de forma dinmica,
sobre
b la l marcha h
La eficiencia depende fundamentalmente del conocimiento del
ingeniero
g de pruebas
p

3.Pruebas Tcnicas
Basadas en la Especificacin
Tablas de Decisin

Se usan tablas de decisin para representar relaciones lgicas
entre condiciones (entradas) y acciones (salidas)
Los casos de prueba se derivan sistemticamente de cada
combinacin de condiciones y acciones
Mquinas de Estados Finitos
Los programas se modelan como mquinas de estados finitos
Los casos de prueba pueden ser seleccionados de forma que
cubren los estados y las transiciones entre ellos

3.Pruebas Tcnicas
Basadas en la Especificacin
Especificacin Formal
Disponer de las especificaciones en un lenguaje formal permite
la derivacin automtica de casos de prueba
A la vez, se provee una salida de referencia (orculo) para
chequear los resultados de las pruebas
Basadas en Modelos
Basadas en Especificaciones Algebraicas
Aleatorias
Las Pruebas son generadas de forma plenamente aleatoria
Requiere el conocimiento del dominio de las entradas
Generacin aleatoria de datos de entrada con la secuencia y la
frecuencia con las que podran aparecer en la prctica

3.Pruebas Tcnicas
Basadas en el Cdigo
Flujo
l j de
d Control
C l
Se usan criterios que buscan cubrir todas las sentencias o bloques
de sentencias de un programa
El criterio ms fuerte es la prueba de caminos (testing path)
Ejecucin de todos los caminos de flujo de control entrada-salida
Otros criterios menos exigentes:
Prueba de sentencias
Prueba de ramas (branch)
Prueba de condiciones/decisiones
Los resultados de estas pruebas se establecen en porcentaje de
cobertura

3.Pruebas Tcnicas
Basadas en el Cdigo
Flujo
l j de
d Datos
El diagrama de flujo de control es anotado con informacin sobre
cmo se definen
definen, usan y eliminan las variables del programa
El criterio ms fuerte busca probar todos los caminos de
definicin-uso:
Para cada variable, se debe ejecutar cada segmento de camino de
flujo de control desde la definicin de la variable a su uso
Criterios menos exigentes:
g
Prueba de todas las definiciones
Prueba de todos los usos

3.Pruebas Tcnicas
Basadas en Defectos
in
inventan
entan los casos de p
prueba
eba con el objeti
objetivo
o de desc
descubrir
b i catego
categoras
as
de defectos probables o previstos
Conjetura de Errores
Los casos de prueba se disean intentando descubrir los defectos
ms plausibles del programa
1 Enumerar una lista de posibles equivocaciones que pueden
1.
cometer los desarrolladores y de las situaciones propensas a ciertos
errores
Ejemplo: El valor cero es una situacin propensa a error
2. Generar los casos de prueba en base a dicha lista (se suelen
corresponder con defectos que aparecen comnmente y no con
aspectos
p funcionales))
Fuente: Historia de defectos en proyectos previos

3.Pruebas Tcnicas
Basadas en Defectos
Mutacin
i
Un mutante es una versin ligeramente modificada de un
programa La diferencia es un pequeo cambio sintctico
programa.
Cada caso de prueba se aplica al original y a los mutantes
generados
Asuncin: Mirando defectos sintcticos sencillos se encuentran
defectos reales ms complejos
Para ser eficiente se requieren muchos mutantes
mutantes, que deben ser
generados automticamente de forma sistemtica
Hay herramientas disponibles para ello

3.Pruebas Tcnicas
Basadas en el Uso
Perfil
fil Operacional
O i l
Se reproduce y se prueba el entorno operativo en que deber
funcionar el programa
Se trata de inferir, a partir de los resultados observados, la futura
fiabilidad del software cuando est en uso
SRET (Software Reliability Engineered Testing)
Mtodo en el cual las pruebas son diseadas y guiadas por
objetivos
bj ti de
d fiabilidad
fi bilid d y criticidad
iti id d de
d las
l diferentes
dif t
funcionalidades

4.Pruebas OO
4. Pruebas de Sistemas OO
Introduccin Diseo de Casos de Prueba
P b d
Pruebas de Unidad
U id d Ni el de Clases
Nivel
Caja negra Azar
Particin
Caja blanca
Nivel de Interclases
Proceso de pruebas unitarias
Azar
Diseo por valores interesantes Particin
Criterios de cobertura 1-wise y 2-wise Escenario
Pruebas de Integracin Comportamiento
Por hilos, uso y agrupamiento
Pruebas de Validacin

4.Pruebas OO
Ideas
LLas pruebas
b del
d l diseo
di ded sistemas
i t estructurados
t t d son distintasdi ti t a los
l
sistemas orientados a objetos debido a las caractersticas particulares
de cada uno
No todas las pruebas se realizan sobre artefactos software, sino
tambin sobre los modelos
E llos sistemas
En i t software
ft OO
OO, las
l pruebas
b son:
Unitarias
de Integracin
de Validacin
Para los sistemas reales, es importante minimizar el nmero de
casos de prueba que se realizan

4.Pruebas OO
La OO introduce nuevos aspectos

La naturaleza
l de
d los
l programas OO cambian
b las
l
estrategias y tcticas de prueba
Reutilizacin
Reutilizacin, abstraccin,
abstraccin conexiones y relaciones entre clases,
clases
diseo del sistema, diseo de objetos hasta su implementacin.
Arquitectura software OO
Subsistemas organizados por capas que encapsulan clases que
colaboran entre s
Necesario probar el sistema OO en diferentes niveles
En cada etapa
p los modelos pueden
p probarse
p para
p descubrir errores
y evitar que se propaguen a la siguiente iteracin

4.Pruebas OO
Paso inicial: verificacin de modelos de anlisis y diseo

Antes q
que el cdigo,
g , se generan
g los modelos de anlisis y diseo del sistema
Son similares en estructura y contenido al programa OO, por tanto las pruebas
comienzan con la revisin de estos modelos
Para los modelos de anlisis y diseo hay que comprobar:

Exactitud
qu
q es? Conformidad del modelo con el dominio del p problema
cmo se comprueba? Evaluacin de los expertos en el tema
Complecin
qu es?
es El modelo
ode o incluye
c uye todas las
as partes
pa tes necesarias
ecesa as pa
para
a su co
correcta
ecta
definicin (nombre de los mtodos, tipos de datos, parmetros..)
cmo se comprueba? Evaluacin de los expertos en el tema
Consistencia
qu es? Las relaciones entre las entidades se respetan en todas las
partes del modelo
cmo se comprueba? Listas de comprobacin

4.Pruebas OO Pruebas Unidad
Pruebas de Pruebas de Pruebas de

unidad integracin validacin
Pruebas de unidad
cul es el concepto ms parecido a mdulo en OO?
La clase
cmo se pprueban las clases?
Con casos de prueba
qu
q es un caso de prueba
p en este caso?
1. Construccin de una instancia de la clase que se va probar
2. Ejecucin de una serie de servicios sobre sta
3 Comprobacin
3. C b i del
d l resultado
lt d (orculo)
( l )


Pruebas de unidad
Las pruebas de unidad en OO se realizan:
Nivel de clase Nivel de mtodo
Pruebas de:
1) Probando cada uno de los mtodos 1) Caja negra
2)) Usando distintos niveles de cobertura 2) Caja blanca


Pruebas de unidad (a nivel de mtodo)

Pruebas de caja negra
x EQ
y IS
f ES
z
NT
Entrada:
d longitud
l d lados
l d
(x, y, z)
Salida: tipo triangulo

EQ (Equilatero)
IS (Isosceles)
ES (Escaleno)
NT (No
( triangulo)
l )


Pruebas de unidad (a nivel de mtodo)

Pruebas de caja blanca
Idea: realizar un seguimiento

g del cdigo
g fuente segn
g se van ejecutando
j los
casos de prueba
Conocer cunto cdigo se ha recorrido
Determinar un valor cuantitativo de la cobertura segn el criterio usado
(sentencias, decisiones, condiciones,)
Encontrar fragmentos del programa que no son ejecutados por los casos de prueba
Crear casos de prueba adicionales que incrementen la cobertura


Proceso para
pruebas Unitarias
La id
L idea es combinar
bi llos
mtodos de caja negra
con los de caja blanca

Diseo de casos de prueba (Valores interesantes)

Para disear correctamente los casos de p
prueba,, stos debern usar
valores interesantes
Se considera un valor interesante aquel que permita recorrer la
mayor cantidad posible de cdigo fuente
En funcin del criterio de cobertura elegido
Obtencin de valores interesantes
Para un ejemplo real, el conjunto de valores a probar para conseguir cobertura
total de sentencias puede ser muy grande
P
Para proponer valores
l podemos
d ayudarnos
d de
d tcnicas
i como
Clases de equivalencia
Dividir el dominio de entrada en clases de equivalencia con valores que
provocan un mismo
i comportamiento
t i t
Valores lmite
Complementa a la anterior, seleccionando valores lmite en vez de cualquier
valor de la clase de equivalencia

Valores interesantes
Qu conjuntos de tres valores recorren
todas las sentencias del mtodo getTipo()?
(i, j, k)
(2,2,2)
(0,2,4)
((2,3,5)
, , ) 100%
(2,3,4) cobertura de
(2,5,2) sentencias
(2 2 5)
(2,2,5)
(5,2,2)
(2,2,4)

( ?, ?, ?)
1.72
Criterios de cobertura para valores interesantes:

Grado en que los diferentes valores interesantes
seleccionados se utilizan en la batera de casos de prueba:
1-wise:
Se satisface cuando cada valor interesante de cada parmetro se
incluye al menos en un caso de prueba
2-wise:
Se satisface cuando cada par de valores interesantes se incluye al
menos en un caso de prueba


1-wise
Se satisface cuando cada valor interesante de cada parmetro se
incluye al menos en un caso de prueba
Ejemplo:
Ej l
Valores interesantes para cada lado del tringulo {0,1,2,3,4,5}
Habra que probar con cada uno de esos valores al menos una vez en cada
posicin:
Empezamos con un caso, por ejemplo (0,1,2) i j k
Marcamos los valores en la tabla 0 0 0

para no repetirlos en los siguientes casos 1 1 1
2 2 2
Seguimos tomando valores sin repetir
(1,0,3) (2,3,4) (3,4,5) (4,5,0) (5,2,1) 3 3 3
4 4 4
Hasta que todos los valores hayan sido
5 5 5
seleccionados una vez

2 wise
2-wise
Se satisface cuando cada par de valores interesantes se incluye al
menos en un caso de prueba
A partir de esta tabla, habr que ir

construyendo casos de prueba que
vayan visitando cada par de valores el
menor nmero posible de veces
Ejemplo:
-Tomamos el caso (0,0,0) y marcamos
los 3 p
pares de arriba de la tabla
- Tomamos el (0,1,1) y marcamos los
pares (i=0,j=1), (i=0, k=1) y (j=1, k=1)
-

4.Pruebas OO Pruebas Integracin
Pruebas de integracin
Mismas estrategias que en estructurado?

No, porque OO no tiene una estructura de control jerrquico
N
Nuevos paradigmas
di en OO:
OO
Pruebas basadas en hilos
Integra las clases requeridas para responder a una entrada o suceso del sistema
(di
(diagramas de
d secuencia i de
d UML)
Cada hilo se integra y prueba individualmente
Pruebas basadas en el uso

Se comienza probando las clases ms independientes
Se contina con las ms dependientes hasta probar todo el sistema
Pruebas de agrupamiento
Se selecciona un agrupamiento de clases colaboradoras
Se prueba diseando las clases de pruebas que revelan errores en las
colaboraciones

4.Pruebas OO Pruebas Integracin
Pruebas de integracin (hilos)

Puede haber varias secuencias diferentes dependiendo,
p , por
p ejemplo,
j p , del
estado inicial del sistema y de la entrada del actor
En el ejemplo Si no hubiera facturas muchos mensajes no seran enviados
El caso de pruebas que se deriva de un diagrama de secuencia debera
describir cmo probar una secuencia interesante en el diagrama, tomando el
estado inicial del sistema
1.77
4.Pruebas OO Pruebas Validacin
Pruebas de validacin
Se centra en acciones visibles al usuario y salidas reconocibles
desde el sistema
Los casos de prueba se obtienen a partir de los casos de uso
(son parte del modelo de anlisis)
Ya que tienen una gran similitud de errores con los revelados en
l requisitos
los i it de
d interaccin
i t i del
d l usuario
i
Qu mtodos de prueba se utilizan?

Caja negra

4.Pruebas OO Pruebas Validacin
Ejemplo de prueba de Validacin:

Caso de Prueba: Pagar 300 por una Bicicleta de Montaa
E t d
Entrada:
-Existe pedido vlido de Bicicleta de Montaa y se ha enviado a un vendedor
-El precio es 300 incluyendo gastos envo
-El comprador
p ha recibido una confirmacin de ppedido (ID
( 12345))
-El comprador ha recibido una factura de 300 y que debera estar en el estado pendiente.
-La factura debera apuntar a una cuenta (22-222-2222) la cual debera recibir el dinero. Esta cuenta tiene
un saldo de 963.000 y su titular debera ser el vendedor
-La
L cuentat 11-111-1111
11 111 1111 ddell comprador
d tiene
ti un saldo
ld de
d 350
Resultado:
- El estado de la factura debera ser puesto a cerrada, indicando as que ha sido pagada.
- Saldo
S ld dde lla cuenta 11-111-1111
11 111 1111 = 50
- Saldo de la cuenta 22-222-2222= 963.350
Condiciones:
- No
N se permite
it que otras
t instancias
i t i accedan
d a las
l cuentas
t durante
d t ell caso de
d prueba
b

4.Pruebas OO Diseo de Casos
Diseo de casos de prueba

Prueba convencional
Entrada Proceso Salida
P
Prueba
b OO
Secuencia de operaciones para probar los estados de la clase
Hay que tener en cuenta:

1. Identificar cada caso de prueba y asociarlo explcitamente con la clase a
p
probar
2. Declarar el propsito de la prueba
3. Desarrollar una lista de pasos a seguir
Declarar una lista de estados del objeto a probar
Lista de mensajes y operaciones que se ejecutarn
Lista de excepciones que pueden ocurrir
Lista de condiciones externas necesarias para conducir las pruebas
Informacin adicional para facilitar la comprensin e implementacin
Mtodos de diseo de casos de prueba

A nivel de clases
Verificacin al azar
Pruebas de particin
Particin basada en estados
Particin basada en atributos
Particin basada en categoras
g
A nivel de interclases
Verificacin al azar
P b d
Pruebas de particin
ti i
Basadas en el escenario
Pruebas de comportamiento

Mtodos a nivel de clase

Verificacin
ifi i all azar:
Consiste en probar en orden aleatorio diferentes
secuencias
i vlidas
lid de
d operaciones
i
Ejemplo:
Para un sistema bancario
bancario, un orden aleatorio de operaciones sera
abrir-configurar-depositar-retirar-cerrar

Mtodos a nivel de clase

Pruebas de particin:
Particin basada en estados:
Clasifica las operaciones de clase en base a su habilidad de cambiar el
estado
t d d de la
l clase
l
Ejemplo:
Para la clase cuenta de un sistema bancario, las operaciones depositar o
retirar cambian el estado,, las de consulta de saldo no
Particin basada en atributos:
Clasifica las operaciones basada en los atributos que usa
Ejemplo:
Operaciones que hacen uso del atributo LimiteCredito y las que no
Particin basada en categoras:
Clasifica las operaciones de acuerdo a la funcin genrica que llevan a
cabo
Ejemplo:
Operaciones de inicializacin (abrir, configurar), operaciones de consulta
(saldo, resumen)

Mtodos a nivel de interclase

Es necesario verificar las colaboraciones entre las clases
Tcnica de seleccin al azar (= que a nivel de clase)
Tcnica de particin (= que a nivel de clase)
Tcnica basada en el escenario
Para cada clase cliente,
cliente generar secuencias de operaciones al azar.
azar
As se enviarn mensajes a otras clases servidoras
Para cada mensaje determinar la clase colaboradora y la operacin
correspondiente en el servidor
Para cada operacin invocada por el servidor determinar los mensajes
que transmite
Para cada mensaje determinar el siguiente nivel de operaciones
invocadas e incorporarlas a la secuencia de pruebas

Mtodos a nivel de interclase

Tcnica
b
basada
d en los
l modelos
d l ded comportamiento
Los diagramas de transicin de estados pueden derivar una
secuencia de pruebas
Se persigue alcanzar una cobertura total de estados
La secuencia de operaciones debe causar que la clase haga
transiciones por todos los estados
Ejemplo:
abrir-preparar
abrir preparar cuenta-depositar-retiro-cerrar
cuenta depositar retiro cerrar

Tema1 pruebasSistemasSoftware PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tema1 pruebasSistemasSoftware PDF

Cargado por

Copyright:

Formatos disponibles

IngenieradelSo8wareII

Construccin del Software

Carlos Blanco- IS2 1.3

Carlos Blanco- IS2 1.4

Se refiere a la creacin detallada de software operativo

Diseo Construccin Pruebas

Carlos Blanco- IS2 1.5

Diseo Construccin Pruebas

Los lmites entre Construccin,

Durante la Construccin se generan las cantidades ms

Carlos Blanco- IS2 1.7

Relacin de los modelos con el cdigo fuente

Modelos Cdigo Fuente

Carlos Blanco- IS2 1.8

Los principios fundamentales de la construccin de

Carlos Blanco- IS2 1.9

Los principios fundamentales de la construccin de

Carlos Blanco- IS2 1.10

Los principios fundamentales de la construccin de

Carlos Blanco- IS2 1.11

Los principios fundamentales de la construccin de

Carlos Blanco- IS2 1.12

Desde una perspectiva de proceso,

Carlos Blanco- IS2 1.13

Carlos Blanco- IS2 1.14

Aplicar tcnicas para crear cdigo fuente comprensible (reglas de asignacin

Carlos Blanco- IS2 1.15

Tcnicas para asegurar la calidad del cdigo

Carlos Blanco- IS2 1.16

VV es un conjunto de procedimientos, actividades,

Carlos Blanco- IS2 1.18

Carlos Blanco- IS2 1.19

4. Visin general de la verificacin y validacin

Carlos Blanco- IS2 1.21

Tcnicas Estticas (Revisiones) vs Dinmicas (Pruebas)

Especificacin Diseo Especificacin Diseo

Carlos Blanco- IS2 1.22

Las revisiones software pueden ser

Carlos Blanco- IS2 1.23

Carlos Blanco- IS2 1.24

La manera adecuada de enfrentarse al reto de la

Las pruebas son tcnicas de comprobacin dinmica

Carlos Blanco- IS2 1.25

Ideas preconcebidas sobre las Pruebas:

Pueden detectar las pruebas la ausencia de errores?

Se puede realizar una prueba exhaustiva del software

Cundo se descubre un error la prueba ha tenido xito o

Carlos Blanco- IS2 1.26

Limitaciones Tericas y Prcticas de las Pruebas

Relacin entre Error, Defecto y Fallo:

Carlos Blanco- IS2 1.28

Ejemplo de las dificultades que se presentan

Son suficientes estos dos casos de prueba?

Carlos Blanco- IS2 1.29

Carlos Blanco- IS2 1.30

El mbito o destino de las pruebas del software

Carlos Blanco- IS2 1.31

Carlos Blanco- IS2 1.32

Carlos Blanco- IS2 1.33

Incremental Ascendente ((Bottom-Up)

Carlos Blanco- IS2 1.34

Incremental Descendente (Top-Down)

Carlos Blanco- IS2 1.36