Mtodo grafico

Este tipo de mtodo de prueba consiste en realizar un grfico de los

procedimientos importantes y sus relaciones, para despus poder disear
una serie de pruebas que cubran todo el grafico.
El grafico se empiezan estableciendo los nodos, que representen los
procedimientos y enlaces que representen las relaciones que existen entre
estos, abarcando de esta forma todo el sistema pudiendo crear as a partir
de este grafico casos de prueba que cubran todas las rutas mostradas en
este
Particin equivalente
Una particin equivalente es una tcnica de prueba de Caja Negra que
divide el dominio de entrada de un programa en clases de datos de los que
se pueden derivar casos de prueba. El diseo de estos casos de prueba para
la particin equivalente se basa en la evaluacin de las clases de
equivalencia.
Para aplicar esta tcnica de prueba se tienen en cuenta los siguientes
pasos:
Se deben identificar las clases de equivalencia lo cual se hace tomando
cada condicin de entrada y aplicndole las directrices antes expuestas.
Para definir las clases de equivalencia hace falta tener en cuenta un
conjunto de reglas:
Si una condicin de entrada especifica un rango, entonces se
confeccionan una clase de equivalencia vlida y 2 invlidas.
Si una condicin de entrada especifica la cantidad de valores,
identificar una clase de equivalencia vlida y dos invlidas.
Si una condicin de entrada especifica un conjunto de valores de
entrada y existen razones para creer que el programa trata en forma
diferente a cada uno de ellos, identificar una clase vlida para cada
uno de ellos y una clase invlida.
Si una condicin de entrada especifica una situacin de tipo debe
ser, identificar una clase vlida y una invlida.
Si existe una razn para creer que el programa no trata de forma
idntica ciertos elementos pertenecientes a una clase, dividirla en
clases de equivalencia menores.
Luego de tener las clases vlidas e invlidas definidas, se procede a definir
los casos de pruebas, pero para ello antes se debe haber asignado un
identificador nico a cada clase de equivalencia. Entonces se pueden definir
los casos teniendo en cuenta lo siguiente:
Escribir un nuevo caso de cubra tantas clases de equivalencia vlidas
no cubiertas como sea posible hasta que todas las clases de
equivalencia hayan sido cubiertas por casos de prueba.
Escribir un nuevo caso de prueba que cubra una y solo una clase de
equivalencia invlida hasta que todas las clases de equivalencias
invlidas hayan sido cubiertas por casos de pruebas.

Con la aplicacin de esa tcnica se obtiene un conjunto de pruebas que

reduce el nmero de casos de pruebas y nos dicen algo sobre la presencia o
ausencia de errores. A menudo se plantea que las pruebas a los software
nunca terminan, simplemente se transfiere del desarrollador al cliente. Cada
vez que el cliente usa el programa est llevando a cabo una prueba.
Aplicando el diseo de casos de pruebas al software en cuestin se puede
conseguir una prueba ms completa y descubrir y corregir el mayor nmero
de errores antes de que comiencen las pruebas del cliente.
ANLISIS DE VALORES LMITE
El anlisis de valores lmite es una tcnica de diseo de casos de prueba
que completa a la particin equivalente.
En lugar de seleccionar cualquier elemento de una clase de equivalencia, el
AVL lleva a la eleccin de casos de prueba en los extremos de la clase. En
lugar de centrarse solamente en las condiciones de entrada, obtiene casos
de prueba tambin para el campo de salida.
Condiciones sublmite:
Una condicin sublmite comn es la tabla de caracteres ASCII
Durante la lectura de los requisitos del sistema, nos encontraremos con una
serie de valores singulares, que marcan diferencias de comportamiento.
Estos valores son claros candidatos a marcar clases de equivalencia: por
abajo y por arriba.
Una vez identificadas las clases de equivalencia significativas en nuestro
mdulo, se procede a coger un valor de cada clase, que no est justamente
al lmite de la clase. Este valor aleatorio, har las veces de cualquier valor
normal que se le pueda pasar en la ejecucin real.
La experiencia muestra que un buen nmero de errores aparecen en torno a
los puntos de cambio de clase de equivalencia. Hay una serie de valores
denominados "frontera" (o valores lmite) que conviene probar, adems de
los elegidos en el prrafo anterior. Usualmente se necesitan 2 valores por
frontera, uno justo abajo y otro justo encima.
Tabla ortogonal
En los procesos de prueba de software y fundamentalmente al realizar
las pruebas de caja negra o pruebas de comportamiento se producen
interacciones entre los procesos o datos de entradas. Cuando el
efecto de un factor depende del nivel de otro factor, se dice que existe
una interaccin entre los factores .
Al planificar las pruebas se encuentran los siguientes factores Tipo de
operacin (Factor A) y la Naturaleza contable de la operacin (Factor
B), los cuales afectan la variable de respuesta (contabilizacin de la
operacin) impidiendo de esta forma realizar correctamente los
comprobantes contables al termino de cada operacin.
Los arreglos ortogonales a utilizar para los casos con interacciones,
son exactamente los mismos que se usan para el caso sin
interacciones.

Al asignar dos factores A y B por ejemplo a ciertas columnas,

automticamente la interaccin de esos dos factores AXB se
reflejar en otra columna del arreglo. Por lo tanto, esta tercera
columna ya no podr ser utilizada para algn otro factor o
interaccin a menos que se pueda suponer la interaccin AXB
como inexistente.
Una interaccin significante que se desee probar, tomar una
columna y en consecuencia un grado de libertad. Por lo tanto, si
deseamos analizar el efecto de seis factores y cuatro de las
interacciones entre ellas, requeriremos por lo menos de diez
grados de libertad, esto es de diez columnas, o sea un arreglo
L16 y no un arreglo L8. Que sera suficiente sin interacciones.
Se deber tener cuidado especial en la manera como se
asignan los factores a las columnas, para que sus interacciones
no se confundan con otros factores principales u otras
interacciones que tambin deseamos probar.
Para probar todas las posibles variantes se observa lo siguiente:
Por lo general existen pocas interacciones dentro de las
mltiples posibles entre factores.
El efecto de las interacciones sobre la variable de respuesta, es
por lo general menor que el efecto de los factores individuales
solos.
Recuerde que algunos arreglos ortogonales, le permiten
analizar un problema sin preocuparse por las interacciones. El
L12 es un ejemplo de ellos.
Se sugiere que, en caso de dudas sobre las interacciones,
siempre sea preferible incluir ms factores, en lugar de
interacciones. Si estas ltimas no son muy fuertes, se pueden
considerar como ruido.
Durante el anlisis de los casos de uso o funcionalidades de cualquier
sistema para determinar los prototipos de interfaces o definirlas desde
fases tempranas del desarrollo del software que se quiere construir, es
importante durante la planificacin de las pruebas de caja negra se
conozcan a priori por parte de los ingenieros de pruebas las
interacciones fundamentales que pudieran afectar el funcionamiento
del software evitando los casos crticos con el propsito de
incrementar la confiabilidad y disminuir los tiempos al planificar las
pruebas.