Consulta Pruebas de caja negra y blanca

Luis Andrés Pérez Cordón

Docente
Fanny Mojica

Grupo: AR
Universidad de Pamplona
Modelamiento de Sistemas de Información
Villa del Rosario2018
 1. Técnicas de prueba

Las técnicas más comunes aplicadas en los procesos de prueba tiene el objetivo de
seleccionar buenos casos de prueba esto es casos que tengan una probabilidad
alta de descubrir un error tradicionalmente se ha considerado dos enfoques
complementarios para seleccionar casos de prueba, denominados caja blanca y
caja negra. Las técnicas de caja blanca también denominados pruebas
estructurales utilizan el código fuente del programa y especialmente su estructura
de control para seleccionar casos de pruebas por otro lado las técnicas de caja
negra o funcional obtienen casos a partir de los requisitos funcionales del programa
a probar por lo que no se tiene en cuenta la forma en que se codifica esa
funcionalidad sino que se consideran únicamente las entradas y salidas. [6]
 2. Pruebas de Caja Blanca

Que se basan en un minucioso examen de los detalles procedimentales del código

a evaluar, por lo que es necesario conocer la lógica del programa.[1]

Figura 1 representación de pruebas de caja blanca

A este tipo de técnicas se le conoce también como Técnicas de Caja Transparente

o de Cristal. Este método se centra en cómo diseñar los casos de prueba atendiendo
al comportamiento interno y la estructura del programa. Se examina así la lógica
interna del programa sin considerar los aspectos de rendimiento. El objetivo de la
técnica es diseñar casos de prueba para que se ejecuten, al menos una vez, todas
las sentencias del programa, y todas las condiciones tanto en su vertiente verdadera
como falsa. Como se ha indicado ya, puede ser impracticable realizar una prueba
exhaustiva de todos los caminos de un programa.[1]
Las principales técnicas de diseño de pruebas de caja blanca son [5]:

 Prueba de flujo de control: En estas pruebas se quiere encontrar errores en

la parte lógica del programa, utilizando las condiciones simples operador-
relación o con condiciones complejas.[5]

 Prueba de Datos: Por medio de esta herramienta se hace la selección más

adecuada del flujo de datos, para llegar a una resolución correcta, esto para
probar las variables y definiciones en el programa.[5]

 Prueba de Bifurcación. Como lo dice su título, es ligado a una bifurcación o

para bucles. Con ella podemos definir si algún bucle está correctamente
implementado y si las líneas de código donde exista una condición es la
mejor opción o si debería ser cambiada.[5]

 Prueba de Caminos básicos: Esta prueba lo que demuestra es el conjunto

de pasos base del programa, lo que quiere lograr es que cada sentencia de
código se ejecute mínimo una vez.[5]
 3. Pruebas de Caja Negra
Que realizan pruebas sobre la interfaz del programa a probar, entendiendo por
interfaz las entradas y salidas de dicho programa. No es necesario conocer la lógica
del programa, únicamente la funcionalidad que debe realizar.[1]
Como se puede observar en la figura 2 la caja negra únicamente necesitan saber el
objetivo o funcionalidad que el código ha de proporcionar

Figura 2 Representación de pruebas de caja negra

También conocidas como Pruebas de Comportamiento, estas pruebas se basan en

la especificación del programa o componente a ser probado para elaborar los casos
de prueba. El componente se ve como una “Caja Negra” cuyo comportamiento sólo
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 sería impracticable se selecciona un conjunto de ellas sobre las que se
realizan las pruebas. [1]
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 erróneo 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 erróneo sea lo más alto posible. Al igual que ocurría
con las técnicas de Caja Blanca, para confeccionar los casos de prueba de Caja
Negra existen distintos criterios. Algunos de ellos son[1]:
3.1 Particiones de Equivalencia: La partición de equivalencia es un método de
prueba de Caja Negra que divide el campo de entrada de un programa en clases de
datos de los que se pueden derivar casos de prueba. La partición equivalente se
dirige a una 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. En otras
palabras, este método intenta dividir el dominio de entrada de un programa en un
número finito de clases de equivalencia. De tal modo que se pueda asumir
razonablemente que una prueba realizada con un valor representativo de cada clase
es equivalente a una prueba realzada con cualquier otro valor de dicha clase. Esto
quiere decir que si el caso de prueba correspondiente a una clase de equivalencia
detecta un error, el resto de los casos de prueba de dicha clase de equivalencia
deben detectar el mismo error. Y viceversa, si un caso de prueba no ha detectado
ningún error, es de esperar que ninguno de los casos de prueba correspondientes
a la misma clase de equivalencia encuentre ningún error.[1]

3.2 Análisis de Valores Límite: Esta técnica nos lleva a elegir los casos de prueba
que ejerciten los valores límite. Por lo tanto, el análisis de valores límite
complementa la técnica de partición de equivalencia de manera que [1]:
 En lugar de seleccionar cualquier caso de prueba de las clases válidas e
inválidas, se eligen los casos de prueba en los extremos.
 En lugar de centrase sólo en el dominio de entrada, los casos de prueba se
diseñan también considerando el dominio de salida
Las pautas para desarrollar casos de prueba con esta técnica son:
 Si una condición de entrada especifica un rango de valores, se diseñarán casos
de prueba para los dos límites del rango, y otros dos casos para situaciones
justo por debajo y por encima de los extremos.
 Si una condición de entrada especifica un número de valores, se diseñan dos
casos de prueba para los valores mínimo y máximo, además de otros dos casos
de prueba para valores justo por encima del máximo y justo por debajo del
mínimo. - Aplicar las reglas anteriores a los datos de salida.
 Si la entrada o salida de un programa es un conjunto ordenado, habrá que
prestar atención a los elementos primero y último del conjunto.

3.3 Métodos Basados en Grafos: 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.[2]
En este método:
1. Se crea un grafo de objetos importantes y sus relaciones.
2. 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
3.4 Pruebas de Comparación: es la técnica de diseño pruebas de caja negra, en
la cual los casos de prueba son diseñados para ejecutar combinaciones de entradas
usando el concepto de cobertura de determinación de condición.[3]

3.5 Análisis Causa-Efecto: es una técnica que permite al encargado de la prueba

validar complejos conjuntos de acciones y condiciones.[4]
Dentro del método de Caja Negra la técnica de la Partición de Equivalencia es una
de las más efectivas pues permite examinar los valores válidos e inválidos de las
entradas existentes en el software, descubre de forma inmediata una clase de
errores que, de otro modo, requerirían la ejecución de muchos casos antes de
detectar el error genérico. La partición equivalente se dirige a la definición de
casos de pruebas que descubran clases de errores, reduciendo así en número de
clases de prueba que hay que desarrollar.[4]
 BIBLIOGRAFIA

[1] TÉCNICAS DE EVALUACIÓN DINÁMICA

http://www.lsi.us.es/docencia/get.php?id=361

[2] Scribd. Pruebas de caja negra (2018)

https://es.scribd.com/document/54979451/Pruebas-de-Caja-Negra

[3] Globe , Pruebas de comparación elemental

https://www.globetesting.com/pruebas-de-comparacion-elemental/

[4] Ecured , Pruebas de caja negra

https://www.ecured.cu/Pruebas_de_caja_negra

[5] Monografias.com, Ingenieria del software: prueba de la caja blanca y camino

básico
http://www.monografias.com/docs113/ingenieria-software-prueba-caja-blanca-y-
camino-basico/ingenieria-software-prueba-caja-blanca-y-camino-basico.shtml

[6] Javier Tuya, Isabel Ramos Román, Javier Dolado Cosín, técnicas cuantitativas
para la gestión de la ingeniería de software
https://books.google.com.co/books?id=PZQoZ9KTNaEC&pg=PA46&lpg=PA46&dq
=Las+t%C3%A9cnicas+m%C3%A1s+comunes+aplicadas+en+los+procesos+de+
prueba+tiene+el+objetivo+de+seleccionar+buenos+casos+de+prueba+esto+es+ca
sos+que+tengan+una+probabilidad+alta+de+descubrir+un+error+tradicionalmente
+se+ha+considerado+dos+enfoques+complementarios+para+seleccionar+casos+
de+prueba,+denominados+caja+blanca+y+caja+negra.+Las+t%C3%A9cnicas+de
+caja+blanca+tambi%C3%A9n+denominados+pruebas+estructurales+utilizan+el+
c%C3%B3digo+fuente+del+programa+y+especialmente+su+estructura+de+contro
l+para+seleccionar+casos+de+pruebas+por+otro+lado+las+t%C3%A9cnicas+de+
caja+negra+o+funcional+obtienen+casos+a+partir+de+los+requisitos+funcionales
+del+programa+a+probar+por+lo+que+no+se+tiene+en+cuenta+la+forma+en+qu
e+se+codifica+esa+funcionalidad+sino+que+se+consideran+%C3%BAnicamente+
las+entradas+y+salidas&source=bl&ots=P0WK0CeiH1&sig=0hipmMkMZJmj2mqY
ETpb4UeRMoM&hl=es&sa=X&ved=0ahUKEwjx8rLarKnbAhVRrlkKHUi9CjYQ6AEI
JzAA#v=onepage&q&f=false