Parte 15 TestBlack

Diplomado en Calidad en el Software
Pruebas de Cdigo
Juan Antonio Vega Fernndez

Derechos Reservados, 1999
Para el cdigo dado del problema del

tringulo, verifique si el programa hace lo
correcto. Utilice cualquier tcnica que Ud.
conozca y considere til.
Ejercicio
Verificacin de Cdigo

Comparar el cdigo con las especificaciones del

diseo interno.
Examinar el cdigo contra un checklist especfico
para el lenguaje.
Utilizar herramientas de anlisis esttico para
checar el cumplimiento con los requerimientos de
contenido y sintctico.
Actividades de la

Verificar la correspondencia de trminos en el

cdigo con el diccionario de datos y la
especificacin de diseo interna.
Buscar por nuevas condiciones lmite, posibles
cuellos de botella para el rendimientos, y otras
consideraciones internas que puedan formar la
base para pruebas de validacin adicional.
Actividades de la

Errores en la referencia de datos

Se hace referencia a una variable no asignada o no
inicializada?
Errores en la declaracin de datos
Checklist para
Hay variables con nombres similares?

Hay variables con nombres no significativos?
Errores de cmputo
Es la variable a donde se asigna una expresin, de
menor capacidad que la expresin asignada?
Errores en la comparacin
Son manejadas adecuadamente las reglas de
conversin entre datos o variables de tipo
inconsistente?
Errores en el Flujo de Datos
Checklist para
Existe la posibilidad de salir de un ciclo

anticipadamente?

Errores en la Interfaz
Si un mdulo tienen mltiples puntos de entrada:
existe un parmetro que no sea referenciado en el
punto de entrada actual?
Errores de Entrada/Salida
Checklist para
Hay errores gramaticales u ortogrficos en el texto de

salida del programa?
Errores de Portabilidad
Cmo estn organizados o empaquetados los datos?
Introduccin
Mtodos de Caja Negra
Mtodos de Caja Blanca
Actividades de Validacin
Validacin del Software

Introduccin a la
Validacin del Software

(1) Testing se utiliza para mostrar la presencia de

errores, pero nunca su ausencia.
(2) Uno de los problemas ms dificiles de testing
es saber cundo parar.
(3) Evite casos de pruebas no planeados, no
reutilizables y que se pueden arrojar a la basura, a
menos que se est probando un prototipo que
despus se va a arrojar a la basura.
Axiomas de las
Pruebas de Validacin

(4) Una parte necesaria de los casos de prueba es

la definicin del resultado o salida esperada.
Siempre compare cuidadosamente el resultado
actual con el esperado para todos los casos de
prueba.
Axiomas de las

(5) Los casos de prueba deben ser escritos para

condiciones de entrada invlidos e inesperados, al
igual que para condiciones vlidas y esperadas.
Invlido se define como una condicin que est
fuera del conjunto de condiciones vlidas, y
deber ser diagnosticado como tal por el
programa.
Axiomas de las

(6) Los casos de prueba deben ser escritos para

generar condiciones de salida esperadas. Los
testers con menos experiencia tienden a pensar
desde la perspectiva de las entradas. Los testers
con ms experiencia determinan las entradas
requeridas para generar un conjunto prediseado
de salidas. Asegrese de incluir la salida
Invlida en ese conjunto.
Axiomas de las

Axiomas de las
(7) Con la excepcin de las pruebas unitarias y de
integracin, un programa no deber ser probado
por la persona u organizacin que lo desarroll.
(8) El nmero de errores no descubiertos es
directamente proporcional al nmero de errores
descubiertos.

Cmo medimos que tan bien probado fue un

producto?
En que grado nuestros casos de prueba cubren al
producto?
Cmo medimos que tan buen trabajo estamos
haciendo como testers?
Cobertura de Pruebas

Un caso de pruebas . . .
Cubre cierta parte de los requerimientos
Cubre cierta parte de la funcionalidad (Diseo
Funcional)
Cubre cierta parte de la lgica interna del
programa
Lo que se debe hacer es generar suficientes casos
de prueba para cubrir todos los puntos de cada
nivel.
Cobertura de Pruebas

Caja Negra
Se realizan a partir de las especificaciones del diseo
funcional sin importar la estructura interna del
programa.
En la prctica es importante probar, o al menos hacer
los planes de prueba, de los requerimientos y el diseo
funcional sin tener mucho conocimiento del cdigo.
El conocer el cdigo contamina la manera como se ven
los requerimientos.
Estrategias de Pruebas

Caja Blanca
Se realizan a partir de las especificaciones del diseo
interno y del cdigo.
Estas pruebas no detectan funciones faltantes u
omisiones.
Son necesarias para probar rutas lgicas que no son
discernibles en la funcionalidad externa (ejem. una
funcin matemtica que tiene dos algoritmos diferentes
dependiendo de los datos).
Estrategias de Pruebas

De dnde sacamos los casos de prueba que

validan al cdigo?
Documento de los requerimientos
Documento del diseo funcional
Documento del diseo interno
La fuente de las Pruebas

Pruebas basadas en requerimientos

Estrategia de Caja Negra
Pruebas funcionales
Estrategia de Caja Negra
Estrategias de Validacin
Pruebas internas
Estrategia de Caja Blanca
Definicin de Resultados
Si el resultado esperado no est especificado, es muy
fcil interpretar el resultado obtendio como el
correcto
El ojo ve lo que quiere ver. (Myers, 1979).
Requerimientos de las
Repeticin
Si un error no se puede repetir, no es error.
Es muy difcil en un ambiente de
multiprocesamiento (o multi-hilos) asncrono.
Una prueba
(i) Una actividad en la cual el sistema o
componente es ejecutado bajo condiciones
especficas, los resultados son observados o
grabados, y se hace una evaluacin de
algunos aspectos del sistema o componente.
(ii) Un conjunto de uno o ms casos de pruebas.
Definiciones de la IEEE/ANSI

Un caso de prueba
(i) Un conjunto de entradas de prueba,
condiciones de ejecucin, y resultados
esperados desarrollados para un objetivo
particular.
(ii) La entidad ms pequea que siempre es
ejecutada como una unidad, de principio a
fin.

Un procedimiento de prueba
(i) Las instrucciones detalladas para la
implantacin, ejecucin y evaluacin de los
resultados para un caso de pruebas dado.
(ii) Un caso de pruebas puede ser usado en uno
o ms procedimientos de prueba.

Mtodos de Caja Negra
Particin de Equivalencias
Anlisis de valores lmite
Adivinar errores
Grafos causa efecto
Pruebas de sintxis
Pruebas de Transicin de
estados
Matriz de Grafos
Mtodos de Caja Blanca

Cobertura de sentencias
Cobertura de decisiones
Cobertura de condiciones
Cobertura de rutas
Mtodos de Validacin

Particin de Equivalencia

Es un proceso sistemtico que identifica un conjunto de

clases interesantes de condiciones de entrada a ser
probados.
Cada clase es representativa o cubre un conjunto
grande de otras pruebas.
Si se aplica particin, el producto se comportar de la
misma manera para todos los miembros de las clases.
El objetivo es minimizar el nmero de casos de prueba
requeridos para cubrir las condiciones de entrada.
Particin de Equivalencias

(1) Identificar las Clases de Equivalencia

(CE)
(2) Identificar los Casos de Prueba
Pasos para la
Particin de Pruebas

Para cada entrada externa:

(1) Si la entrada especifica un rango de valores
vlidos, define una CE vlida (dentro del
rango) y dos CE invlidas (una fuera de
cada lmite del rango).
Identificacin de
Clases de Equivalencia
Ejemplo: Si la entrada requiere un mes en el rango de

1-12, define un mes vlido, uno <1, y otro >12.
(2) Si la entrada especifica un nmero (N)

de valores vlidos, define una CE vlida
y dos CE invlidas , una <N y otra >N.
Identificacin de
Ejemplo: En el programa del tringulo, define un

caso con tres valores (1, 3, 3), otro con dos o menos
valores (1, 3) y otro con cuatro o ms
valores
(1, 2, 3, 4).
(3) Si la entrada especifica un conjunto de

valores vlidos, define una CE
vlida
(dentro del conjunto) y otra
CE invlidas (fuera del conjunto).
Identificacin de
Ejemplo: Si un programa requiere un nombre del

conjunto [HUGO, PACO, LUIS], selecciona un
nombre vlido [HUGO], y otro invlido [PANCHO].
(4) Si hay razones para creer que el

programa trata cada valor de entrada
diferente, entonces hay que definir una
CE vlida para cada entrada vlida.
Identificacin de
Ejemplo: Si un programa que recibe un nmero trata

a los pares de una forma y a los impares de otra. Hay
que definir un nmero vlido par y otro vlido impar.
(5) Si la entrada especifica una situacin

obligatoria, define una CE vlida y otra
invlida.
Identificacin de
Ejemplo: Si el primer caracter de una entrada tiene

que ser cualquier letra del alfabeto, define una
entrada con un primer caracter que sea letra del
alfabeto (H567634) y otra entrada con un primer
caracter numrico (1234567).
(6) Si hay alguna razn para creer que los

elementos en una CE no son tratados de
manera idntica, subdivide la CE en
clases ms pequeas.
Identificacin de
Ejemplo: Para el programa de los nmeros pares e

impares, una CE son los pares y otra CE son los
impares.
(1) Asignar un nmero nico a cada CE

(2) Hasta que todas las CE vlidas hayan sido
cubiertas por casos de prueba:
Identificacin
de los Casos de Prueba
Escribe un nuevo caso de prueba cubriendo tantas CE

no cubiertas como sea posible.

(3) Hasta que todas las CE invlidas hayan sido

cubiertas por casos de prueba:
Escribe un nuevo caso de prueba que cubra una y solo
una CE no cubierta.
(4) Si se prueban mltiples CE invlidas en el

mismo caso de prueba, algunas de estas
pruebas nunca van a ser ejecutadas porque la
primera prueba puede enmascarar otras
pruebas o terminar la ejecucin del caso de
prueba.
Identificacin
de los Casos de Prueba

Anlisis de Valores Lmite

Es una variante y refinamiento de la particin de

equivalencia con dos diferencias principales:
(1) En lugar de seleccionar cualquier elemento en una
clase de equivalencia como representativo, los
elementos son seleccionados de manera que cada orilla
de la CE sea probada.
(2) En vez de concentrarse exclusivamente en
condiciones de entrada, se exploran las condiciones de
salida definiendo las CE de salida.

Si una entrada especifica un rango de valores

vlidos, escribe casos de prueba para los lmites
del rango y para las condiciones justo fuera de los
lmites.
Gua para el
Ejemplo: Si el programa requiere una entrada que

sea un nmero real en el rango de 0.0 a 90.0, escribe
casos de prueba para 0.0, 90.0, -0.0001, y 90.0001.
Si para una entrada se especifica un nmero de

valores vlidos, escribe casos de prueba para los
nmero lmite de entradas y para las condiciones
justo fuera de los lmites.
Ejemplo: Si el programa requiere de dos a cinco datos
de entradas, escribir casos de prueba para 2, 5, 1, y 6
datos de entrada.
Gua para el
Usar estos dos lineamientos para cada condicin

de salida.
Realice la Particin de Equivalencia y el

Anlisis de Valores Lmite para el Diseo
Funcional siguiente. Trabaje en equipos
pequeos de 2 3 personas. Utilice el
formato includo para la Particin de
Equivalencias.
Ejercicio

Es un enfoque prctico basado en la intuicin y

experiencia del tester para identificar pruebas que
se considere probables que muestren errores. Las
historias de defectos pueden ser tiles; hay una
alta probabilidad de que los errores que han
aparecido en el pasado, puedan volver a aparecer.
Adivinar Errores
listas o strings vacos o nulos

cero ocurrencias o instancias
nmeros negativos
Es un enfoque sistemtico para explorar

combinanciones de condiciones de entrada. Es un
mtodo rigoroso para transformar una especificacin
en lenguaje natural a una especificacin en lenguaje
formal.
Es muy til en la verificacin del diseo funcional pero
es muy difcil y consume mucho tiempo al
implementarlo.
Es una propuesta prctica cuando hay una
herramienta que convierte el grafo en una tabla de
decisiones.
Grafos Causa-Efecto

Se aplica a programas que tienen un lenguaje que

define los datos o acciones, por ejemplo el
lenguaje de la lnea de comandos de un sistema
operativo.
Pruebas de Sintaxis

Identificar el lenguaje
Definir la sintaxis formalmente
Prueba los casos vlidos siguiendo un grafo de
definicin.
Prueba nivel por nivel haciendo un error a la vez.
Prueba casos invlidos.
Automatiza la creacin y ejecucin de las pruebas.
Pasos para prueba de sintaxis

Es un mtodo analtico que utiliza mquinas

de estado finito para disear pruebas que
tienen funciones de control similares pero
diferentes.
Tambin se utiliza principalmente para la
verificacin funcional.
Pruebas de
Transicin de Estados

Es una representacin ms simple de un

grafo para organizar datos.
Cada fila representa un nodo del grafo.
Cada columna representa un nodo del grafo.
M(i,j) define la relacin entre el nodo i y el
nodo j.
Generalmente es una matriz dispersa.
Matriz de Grafos


Parte 15 TestBlack

Cargado por

Información del documento

Descripción:

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Descripción:

Copyright:

Formatos disponibles

Parte 15 TestBlack

Cargado por

Descripción:

Copyright:

Formatos disponibles

Diplomado en Calidad en el Software

Juan Antonio Vega Fernndez

Para el cdigo dado del problema del

Diplomado en Calidad en el Software

Juan Antonio Vega Fernndez

Comparar el cdigo con las especificaciones del

Diplomado en Calidad en el Software

Juan Antonio Vega Fernndez

Verificar la correspondencia de trminos en el

Diplomado en Calidad en el Software

Juan Antonio Vega Fernndez

Errores en la referencia de datos

Errores en la declaracin de datos

Diplomado en Calidad en el Software

Hay variables con nombres similares?

Errores en el Flujo de Datos

Diplomado en Calidad en el Software

Existe la posibilidad de salir de un ciclo

Juan Antonio Vega Fernndez

Diplomado en Calidad en el Software

Hay errores gramaticales u ortogrficos en el texto de

Diplomado en Calidad en el Software

Validacin del Software

Juan Antonio Vega Fernndez

Diplomado en Calidad en el Software

Juan Antonio Vega Fernndez

(1) Testing se utiliza para mostrar la presencia de

Diplomado en Calidad en el Software

Juan Antonio Vega Fernndez

(4) Una parte necesaria de los casos de prueba es

Diplomado en Calidad en el Software

Juan Antonio Vega Fernndez

(5) Los casos de prueba deben ser escritos para

Diplomado en Calidad en el Software

Juan Antonio Vega Fernndez

(6) Los casos de prueba deben ser escritos para

Diplomado en Calidad en el Software

Juan Antonio Vega Fernndez

Juan Antonio Vega Fernndez

Cmo medimos que tan bien probado fue un

Diplomado en Calidad en el Software

Juan Antonio Vega Fernndez

Diplomado en Calidad en el Software

Juan Antonio Vega Fernndez

Diplomado en Calidad en el Software

Juan Antonio Vega Fernndez

Diplomado en Calidad en el Software

Juan Antonio Vega Fernndez

De dnde sacamos los casos de prueba que

Diplomado en Calidad en el Software

La fuente de las Pruebas

Juan Antonio Vega Fernndez

Pruebas basadas en requerimientos

Diplomado en Calidad en el Software

Diplomado en Calidad en el Software

Diplomado en Calidad en el Software

Juan Antonio Vega Fernndez

Diplomado en Calidad en el Software

Juan Antonio Vega Fernndez

Diplomado en Calidad en el Software

Juan Antonio Vega Fernndez