NIVELES DE LAS PRUEBAS DE SOFTWARE

CAJA BLANCA
Es un mtodo de pruebas de software que pone a prueba las estructuras
internas o funcionamiento de una aplicacin, en lugar de su funcionalidad. En
pruebas de caja blanca una perspectiva interna del sistema, as como
conocimientos de programacin, se utilizan para el diseo de casos de prueba.
El probador escoge entradas para ejercer caminos a travs del cdigo y
determinar las salidas apropiadas.
Se realiza cuando el tester accede al cdigo fuente de la aplicacin y en
consecuencia a los diferentes algoritmos y estructuras de datos utilizadas. La
implementacin de este tipo de pruebas requiere habilidades de programacin,
un conocimiento del framework de desarrollo y un cierto conocimiento
funcional que permita conocer qu misin tienen determinadas clases y
mtodos.

Entre las tcnicas de caja blanca ms conocidas tenemos la cobertura que

consiste bsicamente en la verificacin de que todos los caminos lgicos de la
aplicacin son alcanzables tericamente en funcin de los diferentes valores de
entradas de los parmetros. Este tipo de pruebas, se automatizan con la
ejecucin de pruebas unitarias.
Otra tcnica bastante conocida es la Mutation Testing que se suele utilizar para
verificar la bondad de los mtodos de testing utilizados. Se basa
principalmente en realizar ligeras modificaciones en el programa que daran
lugar a un comportamiento anmalo del mismo (resultados distintos) y verificar
si la estrategia de testing utilizada es capaz de detectar estos cambios.
Ejemplos de estos pequeos cambios lo podemos tener modificando el
operador en las guardas de sentencias selectivas o iterativas, eliminando
sentencias, etc
Una de las tcnicas de caja blanca ms conocida es el anlisis esttico de
cdigo que tiene como objetivo principal evaluar (directa o indirectamente)
la deuda tcnica del software o lo que es lo mismo, evaluar el grado de
mantenibilidad del sistema
La mantenibilidad del sistema es una caracterstica a la que no se suele
dedicar suficiente atencin, al fin y al cabo lo importante es que el sistema
funcione (algo de lo que estoy totalmente de acuerdo), pero que una vez que
se consigue debe ser compatible con el hecho de que el sistema sea escalable
y pueda ser modificado a un coste razonable.
VENTAJAS
TRANSPARENCIA
Por qu los analistas pueden ver el cdigo fuente mientras el programa se
est probando, cada lnea de cdigo se puede analizar, al menos tericamente.
Tiempo y presupuesto a menudo dictan cmo se analiza a fondo el cdigo. Si el
software parece estar funcionando segn lo previsto, las pruebas de caja
blanca puede validar o no el cdigo en s funciona como estaba previsto. Por

ejemplo, piezas intiles de cdigo, caminos innecesarios entre las operaciones

y prdidas de memoria se pueden detectar cuando un analista puede ver el
cdigo fuente.
SEGURIDAD
La seguridad es un factor importante en el diseo de la mayora de los
programas de software - para el mismo software, y otro software que
interacta con el sistema que lo hospeda. Si el software se ha probado el uso
de tcticas y mtodos que pueden ser utilizados por los hackers, el
comportamiento del cdigo se puede controlar mediante las pruebas de caja
blanca, luego se analiza en busca de vulnerabilidades que podran ser
explotadas despus de que el software ha sido puesto en libertad. Basndose
nicamente en las pruebas de caja negro no siempre se revelan la
vulnerabilidad por debajo de la capa de interfaz.
OPORTUNIDAD
Ser capaz de lanzar un nuevo software en el momento oportuno es una
consideracin importante en cada proyecto. Por qu las pruebas de caja
blanca no requiere la interfaz de usuario que est terminado, la prueba se
puede realizar bajo se encuentra todava en la fase de desarrollo, la interfaz
grfica de usuario. Como resultado, los problemas de software pueden ser
detectados y tratados con mucha anterior. Cada problema se detecta y se fija
antes de que el producto acabado reduce la cantidad de tiempo que de otra
manera sera necesaria durante la fase de pruebas de recuadro negro.
BENEFICIOS ECONMICOS
Las pruebas de caja blanca puede ser ms caro que las pruebas de recuadro
negro, porque las habilidades necesarias para analizar el cdigo fuente.
Probadores caja blanca necesita una formacin en lenguaje de programacin,
mientras que los negros caja probador suelen ser especialistas en garanta de
calidad que slo necesitan saber cmo utilizar la interfaz de usuario. Sin
embargo, en el ciclo global de desarrollo de productos, pruebas de caja blanca
puede dar lugar a un ahorro significativo en el programa si se detectan
defectos mediante pruebas de caja blanca, mientras que el producto an est
en fase de desarrollo.

DESVENTAJAS
Aunque las pruebas de caja blanca tienen grandes ventajas, no es perfecta y
contiene algunas desventajas:

1. Pruebas de caja blanca aporta complejidad a las pruebas porque para

ser capaz de probar todos los aspectos importantes del programa, debe
tener un gran conocimiento del programa.
2. Pruebas de caja blanca requiere un programador con un alto nivel de
conocimiento debido a la complejidad del nivel de pruebas que hay que
hacer.
3. En algunas ocasiones, no es realista para poder probar todas las
condiciones existentes solo de la aplicacin y algunas condiciones sern
probados.
VALIDACION Y VERIFICACION
La validacin y verificacin (V y V) de software se define como un conjunto de
procedimientos, actividades, tcnicas y herramientas que se utilizan,
paralelamente al desarrollo, para asegurar que un producto de software
cumpla con los requerimientos planteados por los usuarios finales.
La visin del desarrollo de software, formada por un conjunto de fases, no slo
facilita el desarrollo, sino tambin el esfuerzo de la V y V. Se puede dividir el
esfuerzo de V y V indicando las actividades, procedimientos y tcnicas a
emplear en cada fase del ciclo de vida. Para ello es necesario definir un Plan
de Verificacin y Validacin de software al inicio del proyecto que determine
estas actividades.
OBJETIVOS
Detectar y corregir los defectos tan pronto como sea posible en el ciclo
de vida del software.
Disminuir los riesgos, las desviaciones sobre los presupuestos y sobre el
programa de tiempos.
Mejorar la calidad y fiabilidad del software.
Mejorar la visibilidad de la gestin del proceso de desarrollo.
Valorar rpidamente los cambios propuestos y sus consecuencias.
La validacin tiene por objetivo determinar la correccin del producto final con
respecto a las necesidades planteadas por los usuarios finales y, La verificacin
tiene por objetivo demostrar la consistencia y correccin del software entre las
fases del ciclo de desarrollo de un proyecto.

Se clasifican en 2 grandes grupos:

INSPECCIONES DE SOFTWARE: analizan y comprueban las representaciones

del sistema (los diagramas de diseo, el cdigo fuente del programa). Se aplica
a todas las etapas del proceso de desarrollo y se complementan con algn tipo
de anlisis automtico del texto fuente y documentos asociados. Son tcnicas
de verificacin y validacin estticas, no requieren que el sistema se ejecute.
PRUEBAS DE SOFTWARE: consisten en comparar datos tericos con los
resultados del software utilizando series de datos de prueba, se examinan los
resultados del software y su comportamiento operacional para comprobar que
se desempee conforme a lo requerido. Es una tcnica dinmica de la
verificacin y validacin ya que requiere disponer de un prototipo ejecutable
del sistema.
Lo que buscamos descubrir con ambos tipos de pruebas son:
Defectos (bug): un defecto en el software como, por ejemplo, un proceso,
una definicin de datos o un paso de procesamiento incorrectos en un
programa.
Fallos (failure): La incapacidad de un sistema o de alguno de sus
componentes para realizar las funciones requeridas dentro de los requisitos de
rendimiento especificados.

PRUEBA DE INTEGRACIN
El proceso de integracin del sistema implica construir este a partir de sus
componentes y probar el sistema resultante para encontrar problemas que
pueden surgir debido a la integracin de los componentes. Los componentes
que se integran pueden ser componentes comerciales, componentes
reutilizables que han sido adaptados a un sistema particular, o componentes
nuevos desarrollados. Para muchos sistemas grandes, es probable que usen los
tres tipos de componentes. La prueba de integracin comprueba que estos
componentes funcionen realmente juntos, son llamados correctamente y
transfieren los datos correctos en el tiempo preciso a travs de sus interfaces.
La integracin del sistema implica identificar grupos de componentes que
proporcionan alguna funcionalidad del sistema e integrar estos aadiendo
cdigos para hacer que funcione conjuntamente. Algunas veces, Esto se
denomina integracin descendente.

 INTEGRACIN EN PROFUNDIDAD: integra todos los mdulos de un

camino de control principal de la estructura.
Por ejemplo, si se elige el camino de la izquierda se integrarn
primero los mdulos M1, M2 y M5. A continuacin, se integrar M8 o
M6. A continuacin se construyen los caminos de control central y
derecho.
INTEGRACIN ANCHURA: incorpora todos los mdulos directamente
subordinados a cada nivel, movindose por la estructura de forma
horizontal.
Por ejemplo, Los primeros mdulos que se integran son M2, M3 y M4.
A continuacin, sigue el siguiente nivel de control, M5, M6, M7 y por
ltimo M8.
De forma alternativa, pueden integrarse primero los componentes de
infraestructura que proporcionan servicios comunes, tales como el acceso a
bases de datos y redes, y a continuacin pueden aadirse los componentes
funcionales. Esta es la integracin ascendente.

Se combinan los mdulos para formar los grupos 1,2 y 3. Cada uno de los
grupos se somete a prueba mediante un controlador (mostrado como un
bloque punteado). Los mdulos de los grupos 1 y 2 son subordinados Ma. Los
controladores D1 y D2 se eliminan y los grupos interaccionan directamente con
Ma. De forma similar, se elimina el controlador D3 del grupo 3 antes de la
integracin con el mdulo Mb. Tanto Ma como Mb se integraran finalmente con
el mdulo Mc y as sucesivamente.
En la prctica, para muchos sistemas, la estrategia de integracin es una
mezcla para ambas, aadiendo en incrementos componentes de
infraestructura y componentes funcionales. En ambas aproximaciones de
integracin, normalmente tiene que desarrollarse cdigo adicional para simular
otros componentes y permitir que el sistema se ejecute.
La principal dificultad que surge durante las pruebas de integracin es la
localizacin de los errores. Existen interacciones complejas entre los
componentes del sistema, y cuando se descubra una salida anmala, puede
resultar difcil identificar donde ha ocurrido el error. Para hacer ms fcil la
localizacin de errores, siempre debera utilizarse una aproximacin
incremental para la integracin y pruebas del sistema.
La prueba de Integracin tiene dos enfoques:

Integracin No-Incremental

Todos los componentes se integran al mismo tiempo y el resultado

integrado se prueba.
Este enfoque no es efectivo por que cuando se produce un error,
ste se puede asociar a diferentes componentes.
Integracin Incremental
Es cuando probamos un mdulo y lo integramos con los que ya
estn probados.
Tiene la ventaja de que los errores encontrados generalmente
estn asociados con el nuevo mdulo que se acaba de integrar.

PRUEBAS DE HUMO
Esta prueba es utilizada cuando se ha desarrollado un producto software
empaquetado. Es diseado como un mecanismo para proyectos crticos por
tiempo, permitiendo que el equipo de software valore su proyecto sobre una
base slida. La prueba de humo comprende las siguientes actividades:
Los componentes software que han sido traducidos al cdigo se integran
en una construccin. Una construccin incluye fichas de datos,
libreras, mdulos reutilizables y componentes de ingeniera que se
requieren para implementar una o ms funciones del producto.
Se disea una serie de pruebas para descubrir errores que impiden a la
construccin realizar su funcin adecuadamente. El objetivo ser
descubrir errores bloqueantes que tengan la mayor probabilidad de
impedir al proyecto de software el cumplimiento de su planificacin.
Es habitual en la prueba de humo que la construccin se integre con
otras construcciones y que se aplica una prueba de humo al producto
completo. La integracin puede hacerse bien de forma descendente o
ascendente.
La prueba de humo facilita una serie de beneficios cuando se aplica sobre
proyectos de ingeniera de software complejos y crticos por su duracin:

Se minimiza los riesgos de integracin.

Se perfecciona la calidad del producto final.
Se simplifican el diagnstico y la correccin de errores.
El progreso es fcil de observar.

PRUEBAS DE REGRESION
La prueba de regresin consiste en volver a ejecutar un subconjunto de
pruebas que se han llevado a cabo anteriormente para asegurarse de que los
cambios no han propagado efectos colaterales no deseados. La prueba de

regresin es la actividad que ayuda a asegurar que los cambios no introducen

un comportamiento no deseado o errores adicionales.
El conjunto de pruebas de regresin contiene tres clases diferentes de casos de
prueba:
1. Una muestra representativa de pruebas que ejercite todas las funciones
del software.
2. Pruebas adicionales que se centran en las funciones del software que se
van a ver probablemente afectadas por el cambio.
3. Pruebas que se centran en los componentes del software que han
cambiado.
PRUEBAS DE OPERACIN
Consisten en comprobar la correcta implementacin de los procedimientos de
operacin, incluyendo la planificacin y control de trabajos, arranque y re
arranque del sistema.
PRUEBAS DE CONFIGURACION
Estas pruebas verifican la operacin del sistema en diferentes configuraciones
de hardware y software. En la mayora de los ambientes de produccin, las
especificaciones para las estaciones de trabajo, equipos de red y servidores
pueden variar. Las estaciones pueden tener diferentes versiones de software
instaladas (Sistemas Operativos, Drivers, etc.) y en cualquier momento,
pueden llegar a utilizarse diferentes combinaciones.
Con frecuencia, el nmero de configuraciones posibles es demasiado grande
para intentar una prueba de cada una de ellas, pero el programa debe
probarse al menos con cada tipo de dispositivo y con las configuraciones
mnima y mxima posibles.
PRUEBAS DE INSTALACION

Las pruebas de instalacin tienen dos propsitos. El primero es asegurar que el

sistema puede ser instalado en todas las configuraciones posibles, tales como
nuevas
instalaciones,
actualizaciones,
instalaciones
completas
o
personalizadas, y bajo condiciones normales o anormales; estas ltimas
incluyen insuficiente espacio en disco, falta de privilegios para algunas tareas,
etc.
El segundo propsito es verificar que, una vez instalado, el sistema opera
correctamente. Esto usualmente implica correr un nmero significativo de
pruebas de Funcionalidad.

Los objetivos de las pruebas de instalacin son:

Verificar y validar que el sistema se instala apropiadamente en cada
cliente, bajo las siguientes condiciones:
Instalaciones nuevas, nuevas mquinas a las que nunca se les ha
instalado el sistema.
Actualizar mquinas previamente instaladas con el sistema.
Instalar versiones viejas en mquinas previamente instaladas con el
sistema.

PRUEBAS DE LA DOCUMENTACION
Las pruebas de sistema tambin se refieren a la exactitud de la documentacin
del usuario. Una manera de lograr esto es utilizar la documentacin para
determinar la representacin de los casos anteriores de prueba del sistema.
Cuales quiera de los ejemplos ilustrados en la documentacin se deben probar
y hacer parte de los casos y alimentarlos al programa.
El objetivo de esta prueba es evaluar la exactitud y claridad de la
documentacin del usuario y para determinar si el manual de procedimientos
trabajar correctamente como una parte integral del sistema. Muchos defectos
son identificados cuando un probador competente chequea totalmente los
manuales y documentacin del usuario.
Muchos programas son parte de sistemas mayores, no completamente
automatizados, que contienen procedimientos realizados por operadores.
Cualquier procedimiento humano, tal como los que llevan a cabo el operador,
el administrador de la base de datos, o el usuario de terminal, debe ser
probado durante la prueba de sistemas.
PRUEBAS DE RECUPERACION Y TOLERANCIA A FALLAS
Estas pruebas aseguran que una aplicacin o sistema se recupere de una variedad de anomalas
de hardware, software o red con prdidas de datos o fallas de integridad.
Las pruebas de tolerancia a fallas aseguran que, para aquellos sistemas que deben mantenerse
corriendo, cuando una condicin de falla ocurre, los sistemas alternos o de respaldo pueden tomar
control del sistema sin prdida de datos o transacciones.

Las pruebas de recuperacin son contrarias a las pruebas en que la aplicacin o sistema es
expuesto a condiciones extremas (o condiciones simuladas), tales como fallas en dispositivos en
entrada/salida o llaves o apuntadores invlidos de base de datos. Los procesos de recuperacin se
invocan y la aplicacin es monitoreada y/o inspeccionada para verificar que stos mecanismos se
han ejecutado en forma apropiada.
Esta prueba evala las caractersticas de contingencia construidas en el sistema para procesar
interrupciones y para volver a puntos especficos en el ciclo de procesamiento del sistema. La
recuperacin debe ser considerada en el proceso de diseo. Errores de programacin o de datos
pueden ser incorporados ex profeso en un sistema para determinar si se puede recuperar de ellos.
Las fallas de equipo (por ejemplo errores de paridad en memoria, errores en dispositivos de
entrada/salida) pueden ser simuladas.

El objetivo de esta prueba es determinar la habilidad del sistema para recuperarse de una falla de
hardware o software.
Verificar

que

los

procesos

de

recuperacin

(manual

automtica)

restauran

apropiadamente la Base de datos, aplicaciones y sistemas, y los llevan a un estado

conocido o deseado.
Los siguientes tipos de condiciones deben incluirse en la prueba:

Interrupcin de electricidad en el cliente.

Interrupcin de electricidad en el servidor

Interrupcin en la comunicacin hacia el servidor (cadas de red)

Interrupcin en la comunicacin con los controladores de disco.

Ciclos

incompletos

(procesos

de

consultas

interrumpidos,

procesos

de

sincronizacin de datos interrumpidos)

Llaves o apuntadores de base de datos invlidos

Elementos corruptos o invlidos en la base de datos.

PRUEBAS DE TENSION

La prueba de tensin es poner al programa a grandes cargas o tensiones. Esto

no se debe confundir c on la prueba de volumen; una gran tensin es
volumen mximo de datos, o de actividad, en un tiempo corto. Una analoga

sera evaluar a un mecangrafo. Una prueba de volumen se determinara si el

mecangrafo hiciera frente a un bosquejo de un informe grande; una prueba
de tensin se determinara si el mecangrafo puede mecanografiar a un ndice
de 50 palabras por minuto.
PRUEBAS DE COMPATIBILADAD Y CONVERSION
El propsito es demostrar que los objetivos de compatibilidad no han sido
logrados y que los procedimientos de conversin no funcionan. La mayora de
los programas que se desarrollan no son completamente nuevos; con
frecuencia son reemplazos de partes deficientes, ya sea de sistemas de
procesamiento de datos, o sistemas manuales. Como tales, los programas
tienen a menudo objetivos especficos con respecto a su compatibilidad y a sus
procedimientos de conversin con el sistema existente.

PRUEBAS GUI (INTERFAZ GRAFICA DE USUARIO)

La prueba de interfaz de usuario verifica la interaccin del usuario con el

software. El objetivo es asegurar que la interfaz tiene apropiada navegacin a
travs de las diferentes funcionalidades. Adicionalmente, las pruebas de
interfaz aseguran que los objetos de la interfaz a ser probada se encuentran
dentro de los estndares de la industria
Verifica lo siguiente:

La navegacin a travs de los objetos de la prueba reflejan las

funcionalidades del negocio y requisitos, se realiza una navegacin
ventana por ventana, usando los modos de acceso (tabuladores,
movimientos del mouse, teclas rpidas, etc.)

Los objetos de la ventana y caractersticas, tales como mens, medidas,

posiciones, estados y focos se verifican conforme a los estndares.
PRUEBAS DE ESTILO

Se entienden como tales el formato de las ventanas, colores corporativos, tipos

de letra etc. Comprobar que la aplicacin sigue los estndares de estilo propios
del cliente
PRUEBAS DE ACEPTACION
La prueba de aceptacin es ejecutada antes de que la aplicacin sea instalada dentro de un
ambiente de produccin. La prueba de aceptacin es generalmente desarrollada y ejecutada por el
cliente o un especialista de la aplicacin y es conducida a determinar como el sistema satisface sus
criterios de aceptacin validando los requisitos que han sido levantados para el desarrollo,
incluyendo a documentacin y procesos de negocio.
Basado en esta prueba el cliente determina si acepta o rechaza el sistema
Estas pruebas estn destinadas a probar que el producto est listo para el uso operativo. Suelen
ser un subconjunto de las Pruebas de Sistema.
Sirve para que el usuario pueda validar si el producto final se ajusta a los requisitos fijados, es
decir, si el producto est listo para ser implantado para el uso operativo en el entorno del usuario.
Esta prueba es complementada por la prueba de estilo.

PRUEBAS ALFA Y BETA

Cuando se construye software a medida para un cliente, se lleva a cabo una
serie de pruebas de aceptacin para permitir que el cliente valide todos los
requisitos. La mayora de los desarrolladores de productos de software llevan a
cabo un proceso denominado pruebas alfa y beta para descubrir errores que
parezca que slo el usuario final puede descubrir.
1. PRUEBAS ALFA
Se lleva a cabo, por un cliente, en el lugar de desarrollo. Se usa el software de
forma natural con el desarrollador como observador del usuario y registrando
los errores y problemas de uso. Las pruebas alfa se llevan a cabo en un entorno
controlado.
Las pruebas -alfa consisten en invitar al cliente a que pruebe el sistema en el
entorno de desarrollo. Se trabaja en un entorno controlado y el cliente siempre
tiene un experto a mano para ayudarle a usar el sistema. El desarrollador va
registrando los errores detectados y los problemas de uso.
2. PRUEBAS BETA
A en el entorno del cliente. En este caso, el cliente se queda a solas con el
producto y trata de encontrarle fallos de los que informa al desarrollador.

Se llevan a cabo por los usuarios finales del software en los lugares de trabajo
de los clientes. A diferencia de la prueba alfa, el desarrollador no est presente
normalmente. As, la prueba beta es una aplicacin en vivo del software en un
entorno que no puede ser controlado por el desarrollador. El cliente registra
todos los problemas que encuentra durante la prueba beta e informa a
intervalos regulares al desarrollador.

https://jummp.wordpress.com/2011/05/21/testing-de-caja-blanca-white-boxtesting/

http://many-how.com/articulos/computadoras/programacionordenadores/article-158.html

http://docsetools.com/articulos-educativos/article_11483.html

https://leonardosc.files.wordpress.com/.../
software..doc

verificacion-y-validacion-de-

http://juankenny.blogspot.com/2012/08/vvs-la-verificacion-y-validacionde.html

http://datateca.unad.edu.co/contenidos/301404/301404_ContenidoEnLinea/l
eccin_43__prueba_de_integracin.html

http://ing-sw.blogspot.com/2005/04/tipos-de-pruebas-de-software.html

http://es.slideshare.net/abnergerardo/pruebas-de-sistemas-y-aceptacion23663195