Caractersticas de la pruebas

Las pruebas no aseguran que no halla defectos en el software, lo nico que

hace demuestra que estos existen en el software. El objetivo de disear
pruebas es que muestren los errores, aplicando la menor cantidad de
tiempo y esfuerzo.
Para mejorar la eficacia de esto, o sea tener mayor probabilidad de
encontrar errores es recomendable que las pruebas sean realizadas por un
equipo independiente al que desarrollo del software ya que
inconscientemente este ultimo podra no realizar bien las pruebas ya que
querra demostrar que su software funciona sin falla alguna, lo cual podra
evitar que la prueba no tenga xito.
Las caractersticas de una prueba son:

Una buena prueba tiene una alta probabilidad de encontrar

un error.
Tener una alta probabilidad de encontrar un error, para esto
el realizador debe tener conocimiento sobre el software,
visualizando como y en que sentido este puede fallar.
Una buena prueba no es redundante.
No debe ser redundante, cada una de las pruebas deben
tener un propsito diferente en cuanto al encontrar errores
especficos, no debe realizarse la misma prueba una y otra
vez.
Una buena prueba no debe ser demasiado simple o
demasiado compleja.
No debe ser ni demasiado sencilla ni demasiado compleja.
Con tal de poder encontrar todos los errores de un software
las pruebas no deben realizarse como la unin de varias, es
decir cada prueba debe realizarse por separado ya que al
momento de detectar un error con este conjunto de
pruebas este podra estar escondiendo o enmascarando
otros errores.
Una buena prueba debe ser la mejor de la camada.
Cuando se tiene un grupo de pruebas que tienen el mismo
objetivo seria intil usarlas todas es por eso que debe usarse
la que tenga mas posibilidades de encontrar errores.

La comprobabilidad del software significa simplemente saber con cuanta

facilidad puede probarse. Las siguientes caractersticas conducen a un
software comprobable:
Fundamentos (caractersticas) de una prueba de software:

Operatividad
Cuando un sistema se disea teniendo como objetivo la
operatividad habr pocos errores lo que hara que se puedan
realizar la pruebas de manera que se consiga avanzar con
ellas.
Observabilidad

Se pueden observar los procesos, variables y datos que se

ejecutan asi como los errores, y se puede observar el cdigo
fuente facilmente
Controlabilidad
Todo, el software el proceso, el cdigo y las pruebas pueden
ejecutarse a travs de diferentes entradas y salidas en
cualquier parte del software; es decir se tiene un control total
del software.
Descomponibilidad
El sistema se construye por modulos independientes en
cuanto a funcionalidad unos de los otros por lo cual pueden
probarse uno por uno e indepentientemente.
Simplicidad
El programa es simple en cuanto a su construccin (se hace
por modulos para evitar que los fallos se propaguen a otras
partes), funcionalidad (es lo minimo que se necesita para
satisfacer correctamente los requerimientos) y cdigo (se
define un cdigo para inspeccionar y mantener el codigo).
Estabilidad
El software no se viene abajo con las fallas, se mantiene
estable ante ellas, en el momento en que se realizan cambios
en el software estos no perturban las pruebas anteriores.
Comprensibilidad
Se entiende el software en todos sus componentes, internos y
externos.

Tcnicas de Caja Blanca o Estructurales

Se basan en un examen detallado de los procedimientos del cdigo a
evaluar, por lo que es necesario conocer la lgica del programa ya que se
esta es la que se analiza y comprueba en este tipo de prueba; se le conoce
tambin como Tcnicas de Caja Transparente o de Cristal.
Este mtodo se centra en cmo disear los casos de prueba atendiendo al
comportamiento interno y la estructura del programa o sea se disear los
casos a partir de las funciones que deben tener cada uno de los procesos
del programa.
Se examina as la lgica interna del programa sin considerar los aspectos de
rendimiento. El objetivo de la tcnica es disear casos de prueba para que
se ejecuten, al menos una vez, todas las sentencias del programa, y todas
las condiciones tanto verdaderas como falsas. Puede ser imposible realizar
una prueba exhaustiva de todos los caminos de un programa. Por ello se
han definido distintos criterios de cobertura lgica, que permiten decidir qu
sentencias o caminos se deben examinar con los casos de prueba.
Estos criterios son:
Cobertura de Sentencias: Se escriben casos de prueba suficientes
para que cada sentencia en el programa se ejecute, al menos, una
vez.

 Cobertura de Decisin: Se escriben casos de prueba suficientes para

que cada decisin en el programa se ejecute una vez con resultado
verdadero y otra con el falso.
Cobertura de Condiciones: Se escriben casos de prueba suficientes
para que cada condicin en una decisin tenga una vez resultado
verdadero y otra falso.
Cobertura Decisin/Condicin: Se escriben casos de prueba
suficientes para que cada condicin en una decisin tome todas las
posibles salidas, al menos una vez, y cada decisin tome todas las
posibles salidas, al menos una vez.
Cobertura de Condicin Mltiple: Se escriben casos de prueba
suficientes para que todas las combinaciones posibles de resultados
de cada condicin se invoquen al menos una vez.
Cobertura de Caminos: Se escriben casos de prueba suficientes para
que se ejecuten todos los caminos de un programa. Entendiendo
camino como una secuencia de sentencias encadenadas desde la
entrada del programa hasta su salida.

Tcnicas de Caja Negra o funcionales

Realizan pruebas sobre la interfaz del programa a probar, entendiendo por
interfaz las entradas y salidas de dicho programa.
No es necesario conocer la lgica del programa, nicamente la
funcionalidad que debe realizar con lo cual pretenden comprobar si estos
cumplen con los requerimientos especficos para el programa tanto
funcionales como no funcionales tambin conocidas como Pruebas de
Comportamiento.
Estas pruebas se basan en la especificacin del programa o componente a
ser probado para elaborar los casos de prueba. El componente se ve como
una Caja Negra cuyo comportamiento slo puede ser determinado
estudiando sus entradas y las salidas obtenidas a partir de ellas.
No obstante, como el estudio de todas las posibles entradas y salidas de un
programa sera impracticable se selecciona un conjunto de ellas sobre las
que se realizan las pruebas.
Para seleccionar el conjunto de entradas y salidas sobre las que trabajar,
hay que tener en cuenta que en todo programa existe un conjunto de
entradas que causan un comportamiento errneo en nuestro sistema, y
como consecuencia producen una serie de salidas que revelan la presencia
de defectos.
Entonces, dado que la prueba exhaustiva es imposible, el objetivo final es
pues, encontrar una serie de datos de entrada cuya probabilidad de
pertenecer al conjunto de entradas que causan dicho comportamiento
errneo sea lo ms alto posible.
Al igual que ocurra con las tcnicas de Caja Blanca, para confeccionar los
casos de prueba de Caja Negra existen distintos criterios. Algunos de ellos
son:

 Particiones de Equivalencia.
Anlisis de Valores Lmite.
Mtodos Basados en Grafos.
Pruebas de Comparacin.
Anlisis Causa-Efecto.