C11 Testing

Universidad Tecnológica Nacional
Facultad Regional Buenos Aires
Testing
Introducción a la Ingeniería de Software
Dirección de Cátedra:
• Ing. Marcelo Dalceggio
Docentes:
• Ing. Oscar Schivo
Ayudantes:
• Ing. Marcelo Klein
• Ing. Diego Mansilla
• Ing. Silvia Montesanto
• Ing. Marcelo Zucchelli
UNIVERSIDAD TECNOLOGICA NACIONAL INTRODUCCION A LA INGENIERIA DE SOFTWARE

Facultad Regional Buenos Aires
Agenda
1 Introducción
2 Técnicas de Pruebas
3 Tipos de Pruebas
4 Preguntas
2
Facultad Regional Buenos Aires V2.0
1.- Introducción
• ¿Qué persigue la Prueba del SW?

– Básicamente, encontrar fallas en el producto:
• Hacerlo lo mas eficazmente posible

– Encontrar la mayor cantidad de fallas
– No detectar fallas que en realidad no lo son
– Encontrar las mas importantes
• Hacerlo lo mas eficientemente posible

– Hacerlo lo mas rápido posible
– Hacerlo lo mas barato posible
3
1.- Introducción
• El Proceso de la Prueba
Resultado
Requerimiento Análisis Esperado
Casos de
Prueba
Resultado
Estrategia
de la prueba
(Incidentes)
Componente Casos de
a Probar Prueba
Prueba Resultado
Obtenido
– Las pruebas siempre se realizan contra el resultado esperado

– Un incidente puede deberse a:
• Un defecto en el software
• Un defecto en en los casos de prueba
• Un defecto en el ambiente
• Etc..
4
1.- Introducción
• Conceptos Relacionados (I)

– Incidente de Prueba
• Toda ocurrencia de un evento que ocurre durante la ejecución
de una prueba de software que requiere investigación (IEEE
610.12/1990)
• No toda incidencia es una falla.
• Ejemplos:
– Fallas en el producto
– Defectos en los casos
– Equivocaciones al ejecutar las pruebas
– Interpretaciones erróneas
– Dudas
– Etc.
5
1.- Introducción
• Conceptos Relacionados (II)
– Equivocación:
• Una acción humana que produce un resultado incorrecto
– Defecto:
• Paso, proceso, o definición de dato incorrecto
• Ausencia de cierta característica
– Falla:
• Resultado de ejecución incorrecto. Es el producido por el
software distinto al resultado esperado
– Relación entre equivocación, defecto y falla:

• Una equivocación lleva a uno o más defectos, que están
presentes en el código
• Un defecto lleva a cero, una o mas fallas
• La falla es la manifestación del defecto
• Una falla tiene que ver con uno o más defectos
6
1.- Introducción
• Conceptos Relacionados (III)

– Condiciones de Prueba:
• Las condiciones de prueba son descripciones de situaciones
ante las que el sistema debe responder que quieren probarse
– Casos de Prueba:
• Los casos de prueba son lotes de datos necesarios para que
se dé una determinada condición de prueba
– Partición:
• Todos los posibles casos de prueba los dividimos en clases
• Todos los casos de una clase son equivalentes entre si:
• Detectan los mismos defectos
• Con solo ejemplos de cada clase cubrimos todas las pruebas
• El éxito está en en la selección de la partición
7
1.- Introducción
• Economía de la Prueba:
– Se puede invertir mucho esfuerzo en probar

• Probar es el proceso de establecer confianza en que un programa
hace lo que se supone que tiene que hacer
• Ya que nunca voy a poder demostrar que un programa es correcto...
• Continuar probando es una decisión económica
$
Costo de tener
los defectos Costo de probar
% Errores eliminados
8
2.- Técnicas de Prueba
• Black Box Testing:

– Prueba funcional, producida por los datos, o producida por
la entrada/salida
– Prueba lo que el software debería hacer
• Se basa en la definición del módulo a probar (definición
necesaria para construir el módulo)
• Nos desentendemos completamente del comportamiento y
estructura internos del programa
– La prueba de caja negra exhaustiva es imposible de realizar
• Tendría que probar todos los valores posibles de todos los
datos de entrada.
– ¿Qué hacemos?
• Seleccionamos subconjuntos de los datos de entrada posibles,
esperando que cubran un conjunto extenso de otros casos de
prueba posibles
9
• Black Box Testing:

– Criterios:
• Variaciones de Eventos
• Clase de Equivalencia
– De entrada
– De salida
• Condiciones de Borde
• Ingreso de valores de otro tipo
• Integridad del Modelo de datos
– De dominio
?
– De entidad
– De relación function FastExp(x,y:
int): int;
{devuelve x a la y}
10
• White Box Testing:
– Prueba estructural
• Usa la estructura interna del código para derivar los casos de
prueba
– Prueba lo que el software hace

• Se basa en la definición del módulo a probar (definición
necesaria para construir el módulo)
11
• White Box Testing:

function FastExp (x, y: int): int;
% pre: y >= 0
% post: devuelve x a la y
z :int :=1;
while y <> 0 do
if odd(y) then
z := z * x;
y := y - 1
endif;
x := x * x;
y :=y / 2 “¿Qué pasa si y es potencia de 2?”
endwhile “¿Qué pasa si y = 2n -1?”
return(z)
12
• White Box Testing
Programa que calcula

el máximo común divisor begin
entre dos números read(x,y);
while x y do
if x > y
then x := x-y
else y := y-x;
mcd :=x;
end
13
– ¿Cómo derivamos condiciones y casos de prueba del ejemplo ?
• El while sugiere dos condiciones
– x = y, x<>y
• Podemos cubrirlos con los siguientes casos

– [ x = 3, y = 3 ]; [ x = 3, y = 4 ]
– así nos aseguramos de ejecutar el loop principal
• Podemos refinar las condiciones, en función del if

– x = y , x < y, x > y
• Esto puede ser cubierto con los casos

– [ x = 3, y = 3 ]; [ x = 3, y = 4 ]; [ x = 4, y = 3 ]
– y asegurarnos que todas las líneas se ejecutan al menos
una vez
– Esto se llama “Cobertura de Sentencias”

14

– Grados de Cobertura:
• Cobertura de Sentencias
– Prueba cada instrucción
• Cobertura de Decisión
– Pruebo cada salida de los IF, WHILE
• Cobertura de Condición
– Prueba cada expresión lógica (A AND B) de los IF,
WHILE
• Prueba del Camino Básico
15

– Camino Básico:
– Representamos el flujo de control de un programa a través de un
grafo de flujo
secuencia
do while
case, o selección
if then else
múltiple
repeat until
16

– Camino Básico:
• Ejemplo procedimiento ordenar
1 1: do while no queden registros
leer registro;
2: if campo1 del registro =0
2 3: then procesar registro
guardar en buffer
4 3 incrementar contador
4: elsif campo2 del registro =0
6 5
5: then reinicializar contador
6: else procesar registro
7a
guardar en archivo
7a: endif
7b endif
7b:enddo
8 8: end
17

– Complejidad Ciclomática:
• Métrica del software que proporciona una medición

cuantitativa de la complejidad lógica de un programa
– cantidad de caminos independientes
– camino independiente: agrega un nuevo conjunto de
sentencias de procesamiento o una nueva condición
• Formas de calcularla
– número de regiones del grafo
– V(g) = A - N + 2 (A = aristas, N = nodos)
– V(g) = P + 1 (P = cantidad de nodos predicado)
18

procedure media
interface returns media, total.in, total.val;
interface accepts valor, min, max;
type valor [100] is scalar array;
type media, total.in, total.val, min, max, suma is scalar;
type i is integer
1 i = suma = total.in = total.val = 0; 3
do while valor[i]<> -999 and6
total.in <100
4 total.in ++; 5 2
if valor[i] >=min and valor[i] <= max

7 then begin total.val++; suma = suma + valor[i] end;
8 i++
enddo 9 10
if total.val >0
11 then media = suma/total.val
12 else media = -999
endif
13 end media
19
• White Box Testing 1

– Ejemplo:
2
• Camino 1: 1-2-10-11-13
3
• Camino 2: 1-2-10-12-13
• Camino 3: 1-2-3-10-11-13
4
• Camino 4: 1-2-3-4-5-8-9-2...
• Camino 5: 1-2-3-4-5-6-8-9-2...
10 5
• Camino 6: 1-2-3-4-5-6-7-8-9-2...
11 12 6
13 7
20
3.- Tipos de Prueba
• Pruebas y Ciclo de Vida - V-Model

Cons.
Cons.Prueba Prueba
Pruebade Prueba
Requerimiento Prueba de Pruebadede
Requerimiento Sistema Sistema Aceptación
Sistema Sistema Aceptación
Cons. Prueba Prueba

Especificación Cons. Prueba Prueba
Especificación Funcional Funcional
Funcional Funcional
Cons. Prueba Prueba

Arquitectura Cons. Prueba Prueba
Arquitectura Integración Integración
Integración Integración
Prueba
Prueba
de
deRegresión
Regresión
Diseño
Diseño Cons.
Cons.Prueba
Prueba Prueba
Prueba
Detallado Unitaria Unitaria
Detallado Unitaria Unitaria
Codificación
Codificación
21
3.- Tipos de Prueba
• Pruebas Unitarias
– Prueba el componente en forma independiente
– Generalmente lo realiza el área que construyó el módulo
– Se basa en el diseño detallado
– Comienza una vez codificado, compilado y revisado el

módulo
– Los módulos altamente cohesivos son los más sencillos de

probar
22
3.- Tipos de Prueba
• Pruebas de Integración
– Es un técnica sistemática para construir la estructura del
programa mientras que voy probando las interacciones
Grupo 4
Grupo 1 Grupo 2 Grupo 3
23
3.- Tipos de Prueba
• Pruebas de Regresión
– Pruebas orientadas a verificar que, luego de introducido un
cambio en el código, la funcionalidad original no se modificó
• Tengo que probar lo nuevo y lo viejo”
• Por eso necesitamos guardar los casos de prueba

(registrarlos)
24
3.- Tipos de Prueba
• Pruebas de Sistema
– Una vez integrado debo probar el software como conjunto y
en conjunto con el resto del “Sistema”
– Debemos probar en un ambiente similar al real:

• Hay otras aplicaciones
• Hay hardware y otros equipos
– Tipos de Pruebas de Sistema

• Pruebas de Recuperación
• Prueba de Seguridad
• Prueba de Resistencia (Stress)
• Prueba de Rendimiento (Volumen y Performance)
25
3.- Tipos de Prueba
• Pruebas de Aceptación de Usuario

– User Acceptance Test (UAT)
– Pruebas realizadas por los usuarios para verificar que el
sistema se ajusta a sus requerimientos
• Los casos de prueba están basados en la especificación de

requerimientos
• Es una técnica de caja negra
26
4.-Preguntas
Testing is never finished, only abandoned.

Encyclopedia of Software Engineering
27
Material
• Lectura Obligatoria
– Ninguna
• Material Complementario
– Managing the Software Process
• Watts S. Humphrey - Addison Wesley - ISBN: 0-201-18095-2 (1990)
• Capítulo 11
• Herramientas Relacionadas
– LoadRunner - Mercury
– WinRunner (HP)
– Rational Functional Tester (IBM)
– Jmeter (http://jakarta.apache.org/jmeter/)
– Jira (Bug trucking)
– Bugzilla (Bug trucking)
28

C11 Testing

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

C11 Testing

Cargado por

Copyright:

Formatos disponibles

Universidad Tecnológica Nacional

Facultad Regional Buenos Aires

UNIVERSIDAD TECNOLOGICA NACIONAL INTRODUCCION A LA INGENIERIA DE SOFTWARE

• ¿Qué persigue la Prueba del SW?

• Hacerlo lo mas eficazmente posible

• Hacerlo lo mas eficientemente posible

– Las pruebas siempre se realizan contra el resultado esperado

• Conceptos Relacionados (I)

– Relación entre equivocación, defecto y falla:

• Conceptos Relacionados (III)

– Se puede invertir mucho esfuerzo en probar

• Black Box Testing:

• Black Box Testing:

• White Box Testing:

– Prueba lo que el software hace

• White Box Testing:

• White Box Testing

Programa que calcula

• Podemos cubrirlos con los siguientes casos

• Podemos refinar las condiciones, en función del if

• Esto puede ser cubierto con los casos

– Esto se llama “Cobertura de Sentencias”

• White Box Testing

• Prueba del Camino Básico

• White Box Testing

• White Box Testing

• White Box Testing

• Métrica del software que proporciona una medición

• White Box Testing

if valor[i] >=min and valor[i] <= max

• White Box Testing 1

• Pruebas y Ciclo de Vida - V-Model

Cons. Prueba Prueba

Cons. Prueba Prueba

– Generalmente lo realiza el área que construyó el módulo

– Se basa en el diseño detallado

– Comienza una vez codificado, compilado y revisado el

– Los módulos altamente cohesivos son los más sencillos de

• Tengo que probar lo nuevo y lo viejo”

• Por eso necesitamos guardar los casos de prueba

– Debemos probar en un ambiente similar al real:

– Tipos de Pruebas de Sistema

• Pruebas de Aceptación de Usuario

• Los casos de prueba están basados en la especificación de

• Es una técnica de caja negra

Testing is never finished, only abandoned.

También podría gustarte