Vous êtes sur la page 1sur 4

Prueba de Software: Caja Negra

En el siguiente ensayo se espera dar a conocer el testing mediante el método de caja negra, la
cual es muy usado en el software por su agilidad ya que solo se encarga de la parte del diseño
y un buen ordenamiento de datos de entrada y la buena función del programa, sin tener que
llegar a lo interno que sería el código.

Es una forma rápida de saber si un software es ejecutado correctamente y no dispone de fallas


las cuales interrumpirían en la ejecución de dicho software.

Una prueba basada en la caja negra es aquella que está diseñada a partir de la especificación
del sistema. Esa es una definición un tanto circular e inútil. Es más útil recordar que otros
nombres comunes para las pruebas basadas en la especificación son las pruebas de caja negra
o las pruebas de comportamiento. Intuitivamente, podemos pensar en una prueba de caja
negra, como una donde se supone que debería comportarse. (Black, 2011)

Por otro lado, también es definido por Pressman como pruebas de caja negra, también
llamadas pruebas de comportamiento, se enfocan en los requerimientos funcionales del
software; es decir, las técnicas de prueba de caja negra le permiten derivar conjuntos de
condiciones de entrada que revisarán por completo todos los requerimientos funcionales para
un programa. Las pruebas de caja negra no son una alternativa para las técnicas de caja blanca.
En vez de ello, es un enfoque complementario que es probable que descubra una clase de
errores diferente que los métodos de caja blanca. (Pressman, 2010)

El desarrollo del testeo mediante el método de caja negra, se llevan a cabo sobre la interfaz del
software obviando el comportamiento interno y la estructura del programa, solo basando en la
ejecución en sí y los óptimos resultados.

Nos basamos únicamente en la observación de entradas y salidas del sistema, estamos


siguiendo un enfoque de caja negra. Efectivamente, ese caso sería como considerar que el
sistema es una caja a la cual no podemos mirar su interior. (Toledo, 2014)

Los casos de prueba de caja negra pretenden demostrar entre otras cosas las funciones de
software que sean operativas, la entrada se acepta de forma correcta, salida de forma correcta
y la integridad de la información externa se mantiene.

Las características de caja negra se aplica a cualquier sistema, programa o modulo para una
visión exclusiva de las entradas y salidas, sin tener en cuenta los detalles que se realizan en el
proceso.

Algunas consideraciones o enfoques que se tienen que tener encuentra dentro del plan.

Las pruebas se llevan a cabo sobre la interfaz del sistema, se sentra en los requisitos
funcionales del software, no se necesita conocer el código, intenta encotrar errores de las
siguientes características como las funciones incorrectas, ausentes, errores de interfaz, errores
en estructura de datos o acceso a base de datos, errores de rendimiento y de iniciazion y
terminación.

El primer paso en la prueba de caja negra es entender los objetos que se modelan en software
y las relaciones que conectan a dichos objetos. Una vez logrado esto, el siguiente paso es
definir una serie de pruebas que verifiquen “que todos los objetos tengan la relación mutua
esperada”. Dicho de otra forma, la prueba de software comienza con la creación de un gráfico
de objetos importantes y sus relaciones, y luego diseña una serie de pruebas que cubrirán el
gráfico, de modo que cada objeto y relación se revise y se descubran errores. (Pressman, 2010)

También se puede usar el grafo de causa – efecto, esta técnica de casos de prueba proporciona
una concisa representación de las condiciones lógicas y sus correspondientes acciones. La
técnica consta de una serie de acciones, el cual, lo primero que se necesita hacer es, listar un
módulo para las causas, que son las condiciones de entrada, y los efectos son acciones. Se
prosigue con desarrollar el grafo de causa y efecto, para después pasar a una tabla de
decisiones con el grafo establecido, para al final obtener las reglas de la tabla de decisión a
casos de prueba.

Siguiendo con el proceso se necesita crear un gráfico; una colección de nodos que representan
objetos, enlaces entra las relaciones de los objetos, nodos que describan las propiedades.

Pasado en desarrollo anterior ahora vemos la partición equivalente, este método consiste en
realizar agrupaciones de clases por comportamientos, se agrupan entonces los datos de
entrada y de salida en clases diferentes en la que todos los componentes de cada clase están
relacionados por su comportamiento. Cada una de estas clases será llamada una partición de
equivalencia en la que el programa posee el mismo comportamiento indiferente de cuál sea la
entrada. Se debe seleccionar un elemento representativo de la clase, donde se supone que, si
la agrupación es correcta, el sistema tendrá el mismo comportamiento para cualquier otro
valor. Por otro lado, Pressman no dice que la partición de equivalencia es un método de
prueba de caja negra que divide el dominio de entrada de un programa en clases de datos de
los que pueden derivarse casos de prueba. Un caso de prueba ideal descubre de primera mano
una clase de errores que de otro modo podrían requerir la ejecución de muchos casos de
prueba antes de observar el error general. (Pressman, 2010)

El particionamiento de equivalencias es la identificación de alguna entrada, salida,


comportamiento o algún entorno que necesita probar. Luego usted divide el conjunto de todos
los valores, comportamientos, configuraciones, opciones o lo que usted tiene como
subconjuntos y espera que el sistema los maneje de manera equivalente. (Black, 2011)

El diseño de los 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. Luego de introducir los conceptos en la
sección prudente del grafico establecido se establecen las relaciones

Ahora, en este punto, usted crea sus casos de prueba. Para construir las pruebas para las
entradas, las salidas, las configuraciones o las opciones válidas o lo que sea con lo que esté
trabajando, seleccione un valor de cada partición de equivalencia válida, a continuación, defina
el resultado esperado en esa situación. Repita este proceso hasta que haya seleccionado al
menos un valor representativo para cada partición de equivalencia válida en todas las clases
de equivalencia que ha creado. (Black, 2011)

Una secuencia de transacciones en un diálogo entre un actor y una componente o sistema con
un resultado tangible, donde un actor puede ser un usuario o cualquier cosa que pueda
intercambiar información con el sistema.

Luego de hacer este procedimiento se puede pasar o ejecutar el análisis de valor de frontera
que es una técnica de diseño de casos de prueba que complementan la partición de
equivalencia. En lugar de seleccionar algún elemento de una clase de equivalencia, conduce a
la selección de casos de prueba en los “bordes” de la clase. En lugar de enfocarse
exclusivamente en las condiciones de entrada; también deriva casos de prueba a partir del
dominio de salida.

La experiencia muestra que los casos de prueba que exploran las condiciones límite producen
mejor resultado que aquellos que no lo hacen. Las condicione límite son aquellas que se hayan
en los márgenes de la clase de equivalencia, tanto de entrada como de salida. Por ello, se ha
desarrollado el análisis de valores límite como técnica de prueba. Esta técnica nos lleva a elegir
los casos de prueba que ejerciten los valores límite.

Hay muchos casos donde podría seleccionar más de un valor representativo. Por ejemplo, en
el caso de las clases definidas en conjuntos que están ordenados, podría seleccionar dos
valores para cada clase, específicamente aquellos en el límite superior e inferior de cada clase.
Estos valores se denominan valores límite, y hablaremos más acerca de esta técnica en un
momento. (Black, 2011)

Para el resto de las particiones de equivalencia, seleccione un valor válido. La razón de esta
regla es que, si prueba valores inválidos juntos, no podrá estar seguro de que una entrada,
salida, comportamiento o lo que sea por alguna razón específica serán tratados
correctamente. Por supuesto, si sospecha que ciertos valores inválidos van a interactuar,
puede añadir pruebas para ello, pero asegúrese de que también ha probado individualmente
cada valor inválido. (Black, 2011)

Conjetura de errores:

Las pruebas nos llevan a descubrir errores, que en la mayoría de los casos son de tipo
funcional, es decir, del tipo: “el sistema debería hacer tal cosa y hace tal otra”. La depuración
es la corrección de errores que sólo afectan a la programación, porque no provienen de
errores previos en el análisis o en el diseño. A veces la depuración se hace luego de la entrega
del sistema al cliente y es parte del mantenimiento.

Hemos dicho ya que los errores que aparezcan en estos tipos de pruebas van a llevar a la larga
a una depuración, en la medida en que sean errores de codificación. Para llegar a ello, no
obstante, se requiere determinar el módulo donde se produjo el error. Esta tarea, en
apariencia dificultosa, puede facilitarse considerablemente si trabajamos con un entorno de
desarrollo que nos permita recorrer el código en modo de depuración sin necesidad de entrar
en todos los módulos. Como ya dijimos, podemos encontrarnos, y es más habitual en esta
etapa, con errores de análisis o diseño, pero no estudiaremos esto aquí.

Podemos concluir con que a la hora de realizar pruebas de caja negra se esperar, hacer una
cobertura completa, pero, no es suficiente, siempre hay que combinarlas con pruebas de
integración, ya que por mucho que funcione los datos de entrada y salida, por dentro o en
terceros sistemas, pueden existir defectos que no se están teniendo en cuenta. Estos fallos
pueden no acarrear problemas a corto plazo, pero a lo largo del tiempo pueden dificultar el
software.

Pero el hecho de usar el testing de caja negra, posibilita validar el sistema de forma rápido y
sencilla ya que es muy ágil cuando el sistema es amplio, aparte informa si el sistema no actúa
según especificaciones, y dado que su función es solo gráfica y ágil no necesita conocer el
código del sistema
Y en contra sería el escaso control en la cobertura e imposibilidad practica de las pruebas, no
hay método para determinar las entradas a probar, no controla la dependencia entre entradas,
la calidad de las pruebas está determinada por el ingenio del tester.

Bibliography
Black, R. (2011). Fundamento de Pruebas de Software. Estados Unidos: Editorial RBCS.inc.

Pressman, R. S. (2010). Ingenieria de Software Septima Edicion. New York: McGRAW-HILL


INTERAMERICANA EDITORES.

Toledo, F. (2014). Introduccíon a las Pruebas de Sistemas de Informacion. Montevideo: Abstra.

Vous aimerez peut-être aussi