c

REPÚBLICA BOLIVARIANA DE VENEZUELA

MINISTERIO DEL PODER POPULAR PARA LA DEFENSA
UNIVERSIDAD NACIONAL EXPERIMENTAL POLITÉCNICA
DE LA FUERZA ARMADA
NUCLEO CARACAS CHUAO
IMPLANTACION DE SISTEMA


 


Prof: Elizabeth Arrieche Alumnos:

Navarro Angelo C.I19.633.665

Rojas Kerly C.I 18.994.800

Ruiz Milena C.I 18.599.937
Sanchez Nina C.I 18.465.044
Sulbaran Maria C.I 18.912.703

Caracas, Enero de 2011

c
c
c
c
c
c
 c

c
c
c
c

c
c
 Ý
Ýc

Pág.

Introducción 2

Pruebas de Sistemas 4

º Pruebas de Caja Blanca 6

º Pruebas de Camino Básico 8

º Pruebas de estructura de Control 11

º Pruebas de Caja Negra 16

Conclusión 23

Bibliografía 24c

c c

c
c
c
c
c
c
c
c

Ý 
Ý c

El desarrollo de Sistemas de software implica la realización de una serie de

actividades predispuestas a incorporar errores en la etapa de definición de
requerimientos, de diseño y de desarrollo.

Debido a que estos errores se deben a nuestra habilidad innata de provocar

errores, tenemos que incorporar una actividad que garantice la calidad del
software.
Se estudiara los fundamentos de la prueba del software, que definen los
objetivos fundamentales de la fase de prueba además se estudiara el diseño de
casos de prueba, que se centra en un conjunto de técnicas para que satisfagan los
objetivos globales de la prueba.

Las pruebas deben cumplir con una serie de objetivos donde la prueba es
un proceso de ejecución de un programa con la intención de descubrir un error.

Un buen caso de prueba es aquel que tiene una alta probabilidad de

mostrar un error no descubierto hasta entonces, una prueba tiene éxito si
descubre un error no detectado hasta entonces

El objetivo es diseñar casos de prueba que, sistemáticamente, saquen a la

luz diferentes clases de errores, haciéndolo con la menor cantidad de tiempo y de
esfuerzo. La prueba no puede asegurar la ausencia de errores; sólo puede
demostrar que existen defectos en el software.

El proceso de prueba tiene dos entradas:

c
c
c
c
c
c
La configuración del software que incluye la especificación de requisitos del
software, la especificación del diseño y el código fuente

La configuración de prueba que Incluye un plan y un procedimiento de prueba

Si el funcionamiento del software parece ser correcto y los errores
encontrados son fáciles de corregir, podemos concluir con que:
La calidad y la fiabilidad del software son aceptables, o que las pruebas son
inadecuadas para descubrir errores serios.

Se diseñan diferentes pruebas que tengan la mayor probabilidad de

encontrar el mayor número de errores con la mínima cantidad de esfuerzo y de
tiempo.
Se brindan diferentes tipo de pruebas del sistema haremos énfasis en
algunas como lo son pruebas de caja blanca, pruebas de caja negra, pruebas de
camino básico y pruebas de estructura de control.

En la prueba de la caja negra, los casos de prueba pretenden demostrar

que las funciones del software son operativas, que la entrada se acepta de forma
adecuada y que se produce una salida correcta.

En la prueba de caja blanca se realiza un examen minucioso de los detalles

procedimentales, comprobando los caminos lógicos del programa, comprobando
los bucles y condiciones, y examinado el estado del programa en varios puntos.

c
c
c
c
c
c
c


c
c
 c

Las pruebas del software son un elemento crítico para la garantía de

calidad del software y representa una revisión final de las especificaciones, del
diseño ºde la codificación.

Las pruebas de software, son los procesos que permiten verificar y revelar la
calidad de un producto software. Son utilizadas para identificar posibles fallos de
implementación, calidad, o usabilidad de un programa de ordenador o videojuego.
Básicamente es una fase en el desarrollo de software consistente en probar las
aplicaciones construidas.

Las pruebas de software se integran dentro de las diferentes fases del ciclo del
software dentro de la Ingeniería de software. Así se ejecuta un programa y
mediante técnicas experimentales se trata de descubrir que errores tiene.

Para determinar el nivel de calidad se deben efectuar unas medidas o pruebas

que permitan comprobar el grado de cumplimiento respecto de las
especificaciones iniciales del sistema.

Hay muchos planteamientos a la hora de abordar el proceso de pruebas de

software, pero para verificar productos complejos de forma efectiva requiere de un
proceso de investigación más que seguir un procedimiento al pie de la letra. Una
definición de "testing" es: å

  
  
 å


 
 å


   
, donde el "tester" (persona que realiza las pruebas) somete el
producto a una serie de acciones inquisitivas, y el producto responde con su
comportamiento como reacción. Por supuesto, nunca se debe testear el software
en un entorno de producción. Es necesario testear los nuevos programas en un

c
c
c
c
c
c
entorno de pruebas separado físicamente del de producción. Para crear un
entorno de pruebas en una máquina independiente de la máquina de producción
es necesario crear las mismas condiciones que en la máquina de producción.
Existen a tal efecto varias herramientas vendidas por los mismos fabricantes de
hardware (IBM, Sun, HP etc.). Esas utilidades reproducen automáticamente las
bases de datos para simular un entorno de producción.

En general, los informáticos distinguen entre errores de programación (o

"bugs") y defectos de forma. En un defecto de forma, el programa no realiza lo que
el usuario espera. Por el contrario, un error de programación puede describirse
como un fallo en la semántica de un programa de ordenador. Éste podría
presentarse, o no, como un defecto de forma si se llegan a dar ciertas condiciones
de cálculo.

Una práctica común es que el proceso de pruebas de un programa sea

realizado por un grupo independiente de "testers" al finalizar su desarrollo y antes
de sacarlo al mercado. Una práctica que viene siendo muy popular es distribuir de
forma gratuita una versión no final del producto para que sean los propios
consumidores los que la prueben. En ambos casos, a la versión del producto en
pruebas y que es anterior a la versión final (o "master") se denomina beta, y a
dicha fase de pruebas, beta testing.

La prueba del software se puede ver como parte importante de garantía de

calidad del software Proceso (SQA En la SQA, los especialistas y los
interventores de proceso del software toman una visión de conjunto sobre
software y su desarrollo. Examinan y cambian el proceso sí mismo de la
tecnología de dotación lógica para reducir la cantidad de averías que terminen
para arriba en tarifa del defecto. Qué constituye una tarifa aceptable del defecto
depende de la naturaleza del software. Una arcada que el juego video diseñó
simular volar un aeroplano tendría probablemente una tolerancia mucho más
c
c
c
c
c
c
 alta para los defectos que el software usado para controlar un avión de
pasajeros real. Aunque hay cercano los acoplamientos con departamentos de
prueba de la SQA existen a menudo independientemente, y no puede haber
áreas de la SQA en algunas compañías.

Las averías del software ocurren con el proceso siguiente:

Un programador hace error (error), que da lugar a a defecto (avería,

insecto) en el software código de fuente. Si se ejecuta este defecto, en ciertas
situaciones el sistema producirá los resultados incorrectos, causando
a falta.[3] No todos los defectos darán lugar necesariamente a faltas. Por
ejemplo, defectos adentro código muerto la voluntad nunca da lugar a faltas. Un
defecto puede dar vuelta en una falta cuando se cambia el ambiente. Los
ejemplos de estos cambios en el ambiente incluyen el software que es
funcionado en un nuevo hardware plataforma, alteraciones adentroc 
 u
obrando recíprocamente con diverso software.

Un problema con la prueba del software es ése que prueba todas las
combinaciones de entradas y las condiciones previas no son factibles al probar
cualquier cosa con excepción de un producto simple Esto significa que el
número de defectos en un producto de software puede ser muy grande y los
defectos que ocurren son infrecuentemente difíciles de encontrar en la prueba.
Más perceptiblemente, dimensiones del parafunctional de la calidad--por
ejemplo, utilidad, scalability, funcionamiento, compatibilidad, confiabilidad--
puede ser altamente subjetivo; algo que constituye suficiente valor a una
persona puede ser intolerable a otra.


 

La prueba de caja blanca, denominada a veces å

  es
un método de diseño de casos de prueba que usa la estructura de control del
c
c
c
c
c
c
diseño procedimental para obtener los casos de prueba. Mediantelos métodos de
prueba de caja blanca, el ingeniero del software puede obtener casos de prueba
que:

º Ggaranticen que se ejercita por lo menos una vez todos los caminos
independientes de cada módulo;
º Ejerciten todas las decisiones lógicas en sus vertientes verdadera ºfalsa; 
º Ejecuten todos los bucles en sus límites y con sus límites operacionales; 
º Ejerciten las estructuras internas de datos para asegurar su validez. 

La prueba de caja blancadel software se basa en el minucioso examen de los

detalles procedimentales. Se comprueban los caminos lógicos del software
proponiendo casos de prueba que ejerciten conjuntos específicos de condiciones
y/o bucles.
Se puede examinar el estado del programa en varios puntos para determinar si
el estado real coincide con el esperado o mencionado.

A primera vista parecería que una prueba de caja blanca muy profunda nos
llevan a tener programas cien por cien correctos.

Todo lo que tenemos que hacer es definir todos los caminos lógicos,
desarrollar casos de prueba que los ejerciten y evaluar los resultados, es decir,
generar casos de prueba que ejerciten exhaustivamente la lógica del programa.
Desgraciadamente, la prueba exhaustiva presenta ciertos problemas logísticos.
Incluso para pequeños programas, el número de caminos lógicos posibles puede
ser enorme. Por ejemplo, considere un programa de 100 líneas de código en
lenguaje ô c
c c

c
c
c
c
c
c
 Después de la declaración de algunos datos básicos, el programa contiene dos
bucles que se ejecutan de 1 a 20 veces cada uno, dependiendo de las condiciones
especificadas en la entrada. Las principales técnicas de diseño de pruebas de caja
blanca son:

º Pruebas de flujo de control

º Pruebas de flujo de datos
º Pruebas de bifurcación (   )
º Pruebas de caminos básicos
º


 
c

Permite obtener una medida de la complejidad de un diseño procedimental, y

utilizar esta medida como guía para la definición de una serie de caminos básicos
de ejecución, diseñando casos de prueba que garanticen que cada camino se
ejecuta al menos una vez.

 

Secuencia Si-si-no Mientras Repetir-hasta-que Según-Sea

(IF) (While) (Until) (Case)

Donde cada círculo representa una o más sentencias, sin bifurcaciones, en código
fuente.
º !" #
c
c
c
c
c
c
 Cada círculo, denominado nodo del grafo de flujo, representa una o más
sentencias procedimentales. Un solo nodo puede corresponder a una secuencia
de cuadros de proceso y a un rombo de decisión.

Las flechas del grafo de flujo, denominadas aristas o enlaces, representan flujo de
control y son análogas a las flechas del diagrama de flujo. Una arista debe
terminar en un nodo, incluso aunque el nodo.

No represente ninguna sentencia procedimental (por ejemplo, véase el símbolo

para la construcción (Si-entonces-si-no).

Las áreas delimitadas por aristas y nodos se denominan regiones. Cuando

contabilizamoslas regiones incluimos el área exterior del grafo, contando como
otra región más.

$ %

Es una medida que proporciona una idea de la complejidad lógica de un

programa. La complejidad ciclomática coincide con el número de regiones del
grafo de flujo riesgo.

Una vez calculada la complejidad ciclomática de un fragmento de código, se

puede determinar el riesgo que supone utilizando los rangos definidos.

%$ %

Primero introducir una sencilla notación para la representación del flujo de control,
denominada Grafos de Flujo de Control de un programa.

M = Complejidad ciclomática.

c
c
c
c
c
c
E = Número de aristas del grafo. Una arista conecta dos vértices si una sentencia
puede ser ejecutada inmediatamente después de la primera.

N = Número de nodos del grafo correspondientes a sentencias del programa.

P = Número de componentes conexos correspondientes a las diferentes

subrutinas, funciones o métodos. La complejidad ciclomática puede calcularse de
la siguiente manera:
M=E N+P
Una versión simplificada para el cálculo de la Complejidad Ciclomática es la
siguiente:
M = Número de condiciones + 1
Esta última fórmula hay que retocarla si el código a analizar presenta varios
puntos de salida o "returns", pasando a ser:
M = Número de condiciones + Número de retornos o salidas.

&$''%

‡ Obtener el grafo de flujo, a partir del diseño o del código del módulo.
‡ Obtener la complejidad ciclomática del grafo de flujo
‡ Definir el conjunto básico de caminos independientes
‡ Determinar los casos de prueba que permitan la ejecución de cada uno de los
caminos anteriores.
‡ Ejecutar cada caso de prueba y comprobar que los resultados son los esperados.

c
c
c
c

c
c
 




  

La técnica de prueba de camino básico descrita en la parte anterior es una

de las muchas técnicas para la prueba de estructura de control. Aunque la prueba
del camino básico es sencilla y altamente efectiva, no es suficiente por sí sola.

Se trataran algunas variantes de las pruebas de estructura de control Estas

variantes amplían la cobertura de la prueba y mejoran la calidad de la prueba de
caja blanca.

Dentro de las pruebas de estructura de control tenemos

Õ Pruebas de condición

Õ Prueba de flujo de datos

Õ Pruebas de bucles

'!

La prueba de condición es un método de diseño de casos de prueba que

ejercita las condiciones lógicas contenidas en el módulo de un programa. Una
condición simple es una variable lógica o una expresión relacional, posiblemente
precedida con un operador NOT («¬»).

Una expresión relacional toma la siguiente forma

E1 <operador - relacional> E2

Donde E1 y E2, son expresiones aritméticas y <operador-relacional> puede ser ³<,

<=, =,>, >=, ´.

c
c
c
c
c
c
Una condición compuesta está formada por dos o más condiciones simples,
operadores lógicos y paréntesis. Los operadores lógicos permitidos en una
condición compuesta incluye OR («|»), AND («&») y NOT («¬»).

A una expresión sin condiciones relacionales se le denomina expresión lógica.

Si una condición es incorrecta, entonces es incorrecto al menos un componente

de la condición. Así, los tipos de errores de una condición pueden ser:

Õ Error en operador lógico

Õ Error en variable lógica

Õ Error en paréntesis lógico

Õ Error en operador relacional

Õ Error en expresión aritmética

El método de la prueba de condiciones se centra en la prueba de cada una de las

condiciones del programa.

Se han propuesto series de estrategias de prueba de condiciones:

Õ Prueba de ramificaciones: Para una condición compuesta en C, es

necesario ejecutar al menos una vez las ramas verdadera y falsa de C y
cada condición simple de C.

Õ Prueba del dominio: requiere la realización de tres o cuatro pruebas para

una expresión relacional.

Para una expresión relacional de la forma E1 <operador - relacional> E2 se

requieren tres pruebas para comprobar que el valor de E1 es mayor, igual o menor
que el valor de E2.

c
c
c
c
c
c
Por ejemplo si el operador relacional es incorrecto, E1 y E2 son correctos,
entonces estas tres pruebas garantizan la detección de un error del operador
relacional.

Para detectar errores en E1 y E2 la prueba que haga el valor de E1 mayor o menor

que el de E2 debe hacer que la diferencia entre estos dos valores sea lo más
pequeña posible.

' 

 El método de prueba de flujos de datos selecciona caminos de prueba de

un programa de acuerdo con la ubicación de las definiciones y los usos de las
variables del programa.

Las estrategias de pruebas de flujo de datos son útiles para seleccionar caminos
de prueba de un programa que contenga sentencias ' anidados.

Necesitamos conocer la estructura de cada condición o bloque (seleccionando un

camino del programa, determinamos si el camino es factible para el programa).

''

Los bucles son la piedra angular de la inmensa mayoría de los algoritmos

implementados en software

La prueba de bucles es una técnica de prueba de caja blanca que se centra

exclusivamente en la validez de las construcciones de bucles.

Se pueden definir cuatro clases diferentes de bucles:

Õ Bucles simples

Õ Bucles concatenados

Õ Bucles anidados

c
c
c
c
c
c
 Õ Bucles no estructurados

$

A los bucles simples se les debe aplicar el siguiente conjunto de pruebas, donde 
es el número máximo de pasos permitidos por el bucle:

1. Pasar por alto totalmente el bucle

2. Pasar una sola vez por el bucle

3. Pasar dos veces por el bucle

4. Hacer  pasos por el bucle con  

5. Hacer  pasos por el bucle



Si se extendiera el enfoque de pruebas de los bucles simples a los bucles

anidados, el número de posibles pruebas aumentaría geométricamente a medida
que aumenta el nivel de anidamiento. Esto llevaría a un número imprescindible de
pruebas.

Se sugiere un enfoque que ayude a reducir el número de pruebas

1. Comenzar por el bucle mas interior

2. Llevar a cabo las pruebas de bucles simples

3. Progresar hacia fuera, llevando a cabo pruebas para el siguiente bucle

4. Continuar hasta que se hayan probado todos los bucles



c
c
c
c
c
c
Se pueden probar mediante el enfoque definido para los bucles simples, mientras
cada uno de los bucles sea independiente del resto.



Siempre que sea posible, esta clase de bucles se deben rediseñar para que se
ajusten a las construcciones de programación estructurada.

'



c
c
c
c
c
c
Bucles simples Bucles anidados

Bucles concatenados Bucles no estructurados


c
c c  c
 
Las pruebas de caja negra, también denominada prueba de
comportamiento, se centran en los requisitos funcionales del software. O sea, la
prueba de caja negra permite al ingeniero del software obtener conjuntos de
condiciones de entrada que ejerciten completamente todos los requisitos
funcionales de un programa.

Las pruebas de caja negra se llevan a cabo sobre la interfaz del software,
obviando el comportamiento interno y la estructura del programa.
Los casos de prueba de la caja negra pretenden demostrar que:
º Las funciones del software son operativas

c
c
c
c
c
c
 º La entrada se acepta de forma
correcta
º Se produce una salida correcta
º La integridad de la información externa se mantiene

En la prueba de la caja negra, los casos de prueba pretenden demostrar que

las funciones del software son operativas, que la entrada se acepta de forma
adecuada y que se produce una salida correcta.

La prueba de caja negra intenta encontrar errores de las siguientes categorías:

º Funciones incorrectas o ausentes,

º Errores de interfaz,
º Errores en estructuras de datos o en accesos a bases de datos externas,
º Errores de rendimiento y
º Errores de inicialización y de terminación.
A diferencia de la prueba de caja blanca, que se lleva a cabo previamente en el
proceso de prueba, la prueba de caja negra tiende a aplicarse durante fases
posteriores de la prueba. Ya que la prueba de caja negra ignora
intencionadamente la estructura de control, centra su atención en el campo de la
información. Las pruebas se diseñan para responder a las siguientes preguntas:
¿Cómo se prueba la validez funcional?, ¿Cómo se prueba el rendimiento y el
comportamiento del sistema?, ¿Qué clases de entrada compondrán unos buenos
casos de prueba? Entre otras.

Mediante las técnicas de prueba de caja negra se obtiene un conjunto de

casos de prueba que satisfacen los siguientes criterios:

c
c
c
c
c
c
 º Casos de prueba que reducen, en un coeficiente que es mayor que uno, el
número de casos de prueba adicionales que se deben diseñar para
alcanzar una prueba razonable

º Casos de prueba que nos dicen algo sobre la presencia o ausencia de

clases de errores en lugar de errores asociados solamente con la prueba
que estamos realizando.

 
 


Õ
 
 

Los métodos de prueba basados en grafos exploran las relaciones entre los
objetos del programa y su comportamiento.

En este método se debe entender los objetos (objetos de datos, objetos de

programa tales como módulos o colecciones de sentencias del lenguaje de
programación) que se modelan en el software y las relaciones que conectan a
estos objetos. Una vez que se ha llevado a cabo esto, el siguiente paso es definir
una serie de pruebas que verifiquen que todos los objetos tienen entre ellos las
relaciones esperadas. En este método:

Se crea un grafo de objetos importantes y sus relaciones con una colección de


 que representan objetos;   que representan las relaciones entre los
objetos; å


que describen las propiedades de un nodo por ejemplo,
un valor específi
de datos o comportamiento de estado y å
 ces que
describen alguna característica de un enlace.

c
c
c
c

c
c
 Se diseña una serie de pruebas que cubran el grafo de manera que se
ejerciten todos los objetos y sus relaciones para descubrir errores.

En esta figura se muestra una representación simbólica de un grafo. Los nodos

se representan como círculos conectados por enlaces que toman diferentes
formas.

Un enlace dirigido (representado por una flecha) indica que una relación se
mueve sólo en una dirección. Un enlace bidireccional, también denominado enlace
simétrico, implica que la relación se aplica en ambos sentidos. Los enlaces
paralelos se usan cuando se establecen diferentes relaciones entre los nodos del
grafo.

Ejemplo:
Consideremos una parte de un grafo de una aplicación de un procesador de texto
donde:

Objeto n°1 = !()**

Objeto n° 2 = *
Objeto n° += ,


En la figura, una selección del menú en archivo nuevo genera una ventana del
documento.
c
c
c
c

c
c
El peso del nodo de ventana del documento proporciona una lista de los atributos
de la ventana que se esperan cuando se genera una ventana. El peso del enlace
indica que la ventana se tiene que generar en menos de 1.0 segundos. Un enlace
no dirigido establece una relación simétrica entre selección en el menú de archivo
nuevo y texto del documento, y los enlaces paralelos indican las relaciones entre
la ventana del documento y el texto del documento. En realidad, se debería
generar un grafo bastante más detallado como precursor al diseño de casos de
prueba. El ingeniero del software obtiene entonces casos de prueba atravesando
el grafo y cubriendo cada una de las relaciones mostradas. Estos casos de prueba
están diseñados para intentar encontrar errores en alguna de las relaciones.

Ejemplo de un grafo.


º  -
.  

La partición equivalente divide el campo de entrada en clases de datos que

tienden a ejercitar determinadas funciones del software.

c
c
c
c


c
c
 La partición equivalente se dirige a la definición de casos de prueba que
descubran clases de errores, reduciendo así el número total de casos de prueba
que hay que desarrollar. 

El objetivo de partición equivalente es reducir el posible conjunto de casos de

prueba en uno más pequeño, un conjunto manejable que evalúe bien el software.
Se toma un riesgo porque se escoge no probar todo. Así que se necesita tener
mucho cuidado al escoger las clases

El diseño de casos de prueba para la partición equivalente se basa en una

evaluación de las clases de equivalencia para una condición de entrada.

Una clase de equivalencia representa un conjunto de estados válidos o no

válidospara condiciones de entrada. Típicamente, unacondición de entrada es un
valor numérico específico, un rango de valores, un conjunto de valores
relacionados ouna condición lógica. Las clases de equivalencia se puedendefinir
de acuerdo con las siguientes directrices:

‘# Si una condición de entrada especifica un  
 se define una clase de
equivalencia válida y dos noválidas.
 
/#Si una condición de entrada requiere un valor específico, se define una clase
de equivalencia válida y dos no válidas.

+#Si una condición de entrada especifica un miembro de un conjunto, se define
una clase de equivalencia válida y una no válida.

0#Si una condición de entrada es lógica, se define una clase de equivalencia
válida y una no válida, es decir verdadero o falso.

c
c
c
c

c
c
Ejemplo:

Consideremos los datos contenidos en una aplicación de automatización bancaria.

El usuario puede «llamar» al banco usando su ordenador personal, dar su
contraseña de seis dígitos y continuar con una serie de órdenes tecleadas que
desencadenarán varias funciones bancarias. El software proporcionado por la
aplicación bancaria acepta datos de la siguiente forma:

Código de área: En blanco ó un número de 3 dígitos

Prefijo: Número de 3 dígitos que no comience por 0 ó 1
Sufijo: Número de 4 dígitos
Contraseña: valor alfanumérico de 6 dígitos
Ordenes: "Comprobar", "Depositar", "Pagar factura", etc.

Las condiciones de entrada relacionadas con cada elemento de la aplicación

bancaria se pueden especificar como:
Código de área: Condición de entrada lógica - el código de área puede estar o no
presente
Condición de entrada rango - valores definidos entre 200 y 999
Prefijo: Condición de entrada rango - valor especificado > 200
Sufijo: Condición de entrada valor- longitud de 4 dígitos
Contraseña: Condición de entrada lógica - la palabra clave puede estar o no
presente
Condición de entrada valor - cadena de seis caracteres
Orden: Condición de entrada conjunto, contenida en las órdenes listadas
anteriormente.
Aplicando las directrices para la obtención de clases de equivalencia, se pueden
desarrollar y ejecutar casos de prueba para cada elemento de datos del campo de

c
c
c
c

c
c
entrada. Los casos de prueba se seleccionan de forma que se ejercite el mayor
número de atributos de cada clase de equivalencia a la vez.

º  .   

 

El análisis de valores límite es una técnica de diseño de casos de prueba que
completa a la partición equivalente. En lugar de seleccionar cualquier elemento de
una clase de equivalencia, el análisis de valores limites lleva a la elección de
casos de prueba en los extremos de la clase. En lugar de centrarse solamente en
las condiciones de entrada, el análisis de valores limites obtiene casos de prueba
también para el campo de salida. El análisis de valores límite prueba la habilidad
del programa para manejar datos que se encuentran en los límites aceptables. Los
casos de prueba para el análisis de valores limites es muy parecida a las que
proporciona la participación equivalente.



El principal objetivo del diseño de casos de prueba es obtener un conjunto

de pruebas que tengan la mayor probabilidad de descubrir los defectos del
sistema. Para llevar a cabo este objetivo, se usan diferentes categorías de
técnicas de diseño de casos de prueba: prueba de caja blanca, prueba de caja
negra, pruebas del camino básico y pruebas de estructura de control.

Las pruebas de caja blanca se centran en la estructura de control del

programa. Se obtienen casos de prueba que aseguren que durante la prueba se
han ejecutado, por lo menos una vez, todas las sentencias del programa ºque se
ejercitan todas las condiciones lógicas. La prueba del camino básico, una técnica
de caja blanca, hace uso de grafos de programa (o matrices de grafos) para
obtener el conjunto de pruebas linealmente independientes que aseguren la total
cobertura. La prueba de condiciones y del flujo de datos ejercita más aún la lógica

c
c
c
c

c
c
del programa y la prueba de los bucles complementa a otras técnicas de caja
blanca, proporcionando un procedimiento para ejercitar bucles de distintos grados
de complejidad.

Las pruebas de caja negra son diseñadas para validar los requisitos
funcionales sin fijarse en el funcionamiento interno de un programa. Las técnicas
de prueba de caja negra se centran en el ámbito de información de un programa,
de forma que se proporcione una cobertura completa de prueba. Los métodos de
prueba basados en grafos exploran las relaciones entre los objetos del programa y
su comportamiento. La partición equivalente divide el campo de entrada en clases
de datos que tienden a ejercitar determinadas funciones del software. El análisis
de valores límite prueba la habilidad del programa para manejar datos que se
encuentran en los límites aceptables.
c
ÝÝ Ý c

Roger S. Pressman. 2002

Ý  Ý c
c
 c c cÝ#-!
Mac Graw Gill.

España Madrid

   

c
c
c
c

c
c