Pruebas de caja blanca - Historial de revisiones

Yunesky jc.mtz en 13:52 29 abr 2013

2013-04-29T13:52:40Z

Pedropal.pri en 12:57 12 abr 2012

2012-04-12T12:57:31Z

Javiermartin jc en 15:11 10 jun 2011

2011-06-10T15:11:15Z

Olago: Página creada con ''''Prueba de Caja Blanca''' La prueba de caja blanca se basa en el diseño de casos de prueba que usa la estructura de control del diseño procedimental para derivarlos. Mediant...'

2011-06-09T01:51:57Z

Página creada con ''''Prueba de Caja Blanca''' La prueba de caja blanca se basa en el diseño de casos de prueba que usa la estructura de control del diseño procedimental para derivarlos. Mediant...'

Página nueva

'''Prueba de Caja Blanca'''
La prueba de caja blanca se basa en el diseño de casos de prueba que usa la estructura
de control del diseño procedimental para derivarlos. Mediante la prueba de la caja blanca
el ingeniero del software puede obtener casos de prueba que:
1. Garanticen que se ejerciten por lo menos una vez todos los caminos independientes de
cada modulo, programa o método.
2. Ejerciten todas las decisiones lógicas en las vertientes verdadera y falsa.
3. Ejecuten todos los bucles en sus límites operacionales.
4. Ejerciten las estructuras internas de datos para asegurar su validez.
Es por ello que se considera a la prueba de Caja Blanca como uno de los tipos de pruebas
más importantes que se le aplican a los software, logrando como resultado que disminuya
en un gran porciento el número de errores existentes en los sistemas y por ende una
mayor calidad y confiabilidad.
Prueba del camino básico.
La prueba del camino básico es una técnica de prueba de la Caja Blanca propuesta por
Tom McCabe.
Esta técnica permite obtener una medida de la complejidad lógica de un diseño y usar
esta medida como guía para la definición de un conjunto básico.
La idea es derivar casos de prueba a partir de un conjunto dado de caminos
independientes por los cuales puede circular el flujo de control. Para obtener dicho
conjunto de caminos independientes se construye el Grafo de Flujo asociado y se calcula
su complejidad ciclomática. Los pasos que se siguen para aplicar esta técnica son:
1. A partir del diseño o del código fuente, se dibuja el grafo de flujo asociado.
2. Se calcula la complejidad ciclomática del grafo.
3. Se determina un conjunto básico de caminos independientes.
4. Se preparan los casos de prueba que obliguen a la ejecución de cada camino del
conjunto básico.
Los casos de prueba derivados del conjunto básico garantizan que durante la prueba se
ejecuta por lo menos una vez cada sentencia del programa.
== Notación de Grafo de Flujo ==
Para aplicar la técnica del camino básico se debe introducir una sencilla notación para la
representación del flujo de control, el cual puede representarse por un Grafo de Flujo.
Cada nodo del grafo corresponde a una o más sentencias de código fuente. Todo
segmento de código de cualquier programa se puede traducir a un Grafo de Flujo.
Para construir el grafo se debe tener en cuenta la notación para las instrucciones.
Un Grafo de Flujo está formado por 3 componentes fundamentales que ayudan a su
elaboración, comprensión y nos brinda información para confirmar que el trabajo se está
haciendo adecuadamente.
Los componentes son:
=== Nodo ===
Cada círculo representado se denomina nodo del Grafo de Flujo, el cual representa una
o más secuencias procedimentales. Un solo nodo puede corresponder a una secuencia
de procesos o a una sentencia de decisión. Puede ser también que hallan nodos que no
se asocien, se utilizan principalmente al inicio y final del grafo.
=== Aristas ===
Las flechas del grafo se denominan aristas y representan el flujo de control, son
análogas a las representadas en un diagrama de flujo. Una arista debe terminar en un
nodo, incluso aunque el nodo no represente ninguna sentencia procedimental.
=== Regiones ===
Las regiones son las áreas delimitadas por las aristas y nodos. También se incluye el
área exterior del grafo, contando como una región más. Las regiones se enumeran.
La cantidad de regiones es equivalente a la cantidad de caminos independientes del conjunto básico de un programa.
Cualquier representación del diseño procedimental se puede traducir a un grafo de flujo.
Cuando en un diseño se encuentran condiciones compuestas (uno o más operadores AND,
NAND, NOR lógicos en una sentencia condicional), la generación del grafo de flujo se hace
un poco más complicada.

== Complejidad Ciclomática ==
La complejidad ciclomática es una métrica de software extremadamente útil pues proporciona una medición cuantitativa de la complejidad lógica de un programa. El valor calculado como complejidad ciclomática define el número de caminos independientes del conjunto básico de un programa y nos da un límite superior para el número de pruebas que se deben realizar para asegurar que se ejecute cada sentencia al menos una vez. Un camino independiente es cualquier camino del programa que introduce por lo menos
un nuevo conjunto de sentencias de procesamiento o una nueva condición. El camino independiente se debe mover por lo menos por una arista que no haya sido recorrida anteriormente. <ref> PRESSMAN, ROGER S. Ingenieria de Software Un Enfoque Práctico</ref>
== Derivación de casos de prueba ==
Luego de tener elaborados los Grafos de Flujos y los caminos a recorrer, se preparan los
casos de prueba que forzarán la ejecución de cada uno de esos caminos. Se escogen los
datos de forma que las condiciones de los nodos predicados estén adecuadamente
establecidas, con el fin de comprobar cada camino.
Casos de prueba para cada camino.
Camino 1: 1-2-3-5-6.
Escoger algún X y Y tales que cumpla X >= 0 AND Y >= 0.
X = 10 AND Y = 20.
Camino 2: 1-2-4-6.
Escoger algún X tal que se cumpla X < 0.
X = -15.
Luego de confeccionar los casos de prueba se ejecutan cada uno de estos y se comparan
los resultados con los esperados. Una vez terminados todos los casos de prueba, se estará
seguro de que todas las sentencias del programa se han ejecutado por lo menos una vez.
Es importante considerar que algunos caminos no se pueden probar de forma aislada. O
sea, la combinación de datos requeridos para recorrer el camino no se puede obtener con
el flujo normal del programa. En tales casos, estos caminos se prueban como parte de
otra prueba de camino.

== Referencias ==

{{Listaref}}

[[Category:Telemática]]

← Revisión anterior		Revisión del 15:11 10 jun 2011
Línea 1:		Línea 1:
		+	{{Normalizar}}
	'''Prueba de Caja Blanca'''		'''Prueba de Caja Blanca'''
	La prueba de caja blanca se basa en el diseño de casos de prueba que usa la estructura		La prueba de caja blanca se basa en el diseño de casos de prueba que usa la estructura

@@ Línea 77: / Línea 77: @@
 NAND, NOR lógicos en una sentencia condicional), la generación del grafo de flujo se hace
 un poco más complicada.
 == Complejidad Ciclomática ==
@@ Línea 106: / Línea 105: @@
 el flujo normal del programa. En tales casos, estos caminos se prueban como parte de
 otra prueba de camino.
 ==Fuentes==
@@ Línea 114: / Línea 117: @@
 [http://www.lab.dit.upm.es/~lprg/material/apuntes/pruebas/testing.htm Prueba de programas: Prueba del camino y caja blanca y negra]<br>
 [http://research.microsoft.com/en-us/projects/pex/ Pruebas de caja blanca para programas de plataforma .NET]<br>
 [[Category:Telemática]]

@@ Línea 1: / Línea 1: @@
 '''Prueba de Caja Blanca'''
 La prueba de caja blanca se basa en el diseño de casos de prueba que usa la estructura
 de control del diseño procedimental para derivarlos. Mediante la prueba de la caja blanca
 el ingeniero del software puede obtener casos de prueba que:
-. Garanticen que se ejerciten por lo menos una vez todos los caminos independientes de
+# Garanticen que se ejerciten por lo menos una vez todos los caminos independientes de cada módulo, programa o método.
-cada modulo, programa o método.
+# Ejerciten todas las decisiones lógicas en las vertientes verdadera y falsa.
-. Ejerciten todas las decisiones lógicas en las vertientes verdadera y falsa.
+# Ejecuten todos los bucles en sus límites operacionales.
-. Ejecuten todos los bucles en sus límites operacionales.
+# Ejerciten las estructuras internas de datos para asegurar su validez.
-. Ejerciten las estructuras internas de datos para asegurar su validez.
 Es por ello que se considera a la prueba de Caja Blanca como uno de los tipos de pruebas
 más importantes que se le aplican a los software, logrando como resultado que disminuya
 en un gran porciento el número de errores existentes en los sistemas y por ende una
 mayor calidad y confiabilidad.
-Prueba del camino básico.
 La prueba del camino básico es una técnica de prueba de la Caja Blanca propuesta por
-Tom McCabe.
+[[Tom McCabe]].
 Esta técnica permite obtener una medida de la complejidad lógica de un diseño y usar
 esta medida como guía para la definición de un conjunto básico.
 La idea es derivar casos de prueba a partir de un conjunto dado de caminos
 independientes por los cuales puede circular el flujo de control. Para obtener dicho
 conjunto de caminos independientes se construye el Grafo de Flujo asociado y se calcula
 su complejidad ciclomática. Los pasos que se siguen para aplicar esta técnica son:
-. A partir del diseño o del código fuente, se dibuja el grafo de flujo asociado.
-. Se calcula la complejidad ciclomática del grafo.
+# A partir del diseño o del código fuente, se dibuja el grafo de flujo asociado.
-. Se determina un conjunto básico de caminos independientes.
+# Se calcula la complejidad ciclomática del grafo.
-. Se preparan los casos de prueba que obliguen a la ejecución de cada camino del
+# Se determina un conjunto básico de caminos independientes.
-conjunto básico.
+# Se preparan los casos de prueba que obliguen a la ejecución de cada camino del conjunto básico.
 Los casos de prueba derivados del conjunto básico garantizan que durante la prueba se
 ejecuta por lo menos una vez cada sentencia del programa.
 == Notación de Grafo de Flujo ==
 Para aplicar la técnica del camino básico se debe introducir una sencilla notación para la
 representación del flujo de control, el cual puede representarse por un Grafo de Flujo.
@@ Línea 38: / Línea 51: @@
 elaboración, comprensión y nos brinda información para confirmar que el trabajo se está
 haciendo adecuadamente.
 Los componentes son:
 === Nodo ===
 Cada círculo representado se denomina nodo del Grafo de Flujo, el cual representa una
 o más secuencias procedimentales. Un solo nodo puede corresponder a una secuencia
 de procesos o a una sentencia de decisión. Puede ser también que hallan nodos que no
 se asocien, se utilizan principalmente al inicio y final del grafo.
 === Aristas ===
 Las flechas del grafo se denominan aristas y representan el flujo de control, son
 análogas a las representadas en un diagrama de flujo. Una arista debe terminar en un
 nodo, incluso aunque el nodo no represente ninguna sentencia procedimental.
 === Regiones ===
 Las regiones son las áreas delimitadas por las aristas y nodos. También se incluye el
 área exterior del grafo, contando como una región más. Las regiones se enumeran.
 La cantidad de regiones es equivalente a la cantidad de caminos independientes del conjunto básico de un programa.
 Cualquier representación del diseño procedimental se puede traducir a un grafo de flujo.
 Cuando en un diseño se encuentran condiciones compuestas (uno o más operadores AND,
 NAND, NOR lógicos en una sentencia condicional), la generación del grafo de flujo se hace
 un poco más complicada.
 == Complejidad Ciclomática ==
 La complejidad ciclomática es una métrica de software extremadamente útil pues proporciona una medición cuantitativa de la complejidad lógica de un programa. El valor calculado como complejidad ciclomática define el número de caminos independientes del conjunto básico de un programa y nos da un límite superior para el número de pruebas que se deben realizar para asegurar que se ejecute cada sentencia al menos una vez. Un camino independiente es cualquier camino del programa que introduce por lo menos
-un nuevo conjunto de sentencias de procesamiento o una nueva condición. El camino independiente se debe mover por lo menos por una arista que no haya sido recorrida anteriormente. <ref>  PRESSMAN, ROGER S. Ingenieria de Software Un Enfoque Práctico</ref>
+La complejidad ciclomática es una métrica de software extremadamente útil pues proporciona una medición cuantitativa de la complejidad lógica de un programa. El valor calculado como complejidad ciclomática define el número de caminos independientes del conjunto básico de un programa y nos da un límite superior para el número de pruebas que se deben realizar para asegurar que se ejecute cada sentencia al menos una vez. Un camino independiente es cualquier camino del programa que introduce por lo menos un nuevo conjunto de sentencias de procesamiento o una nueva condición. El camino independiente se debe mover por lo menos por una arista que no haya sido recorrida anteriormente. <ref>  PRESSMAN, ROGER S. Ingenieria de Software Un Enfoque Práctico</ref>
 == Derivación de casos de prueba ==
 Luego de tener elaborados los Grafos de Flujos y los caminos a recorrer, se preparan los
 casos de prueba que forzarán la ejecución de cada uno de esos caminos. Se escogen los
 datos de forma que las condiciones de los nodos predicados estén adecuadamente
 establecidas, con el fin de comprobar cada camino.
 Casos de prueba para cada camino.
 Camino 1: 1-2-3-5-6.
 Escoger algún X y Y tales que cumpla X >= 0 AND Y >= 0.
@@ Línea 72: / Línea 98: @@
 Escoger algún X tal que se cumpla X < 0.
 X = -15.
 Luego de confeccionar los casos de prueba se ejecutan cada uno de estos y se comparan
 los resultados con los esperados. Una vez terminados todos los casos de prueba, se estará
@@ Línea 79: / Línea 106: @@
 el flujo normal del programa. En tales casos, estos caminos se prueban como parte de
 otra prueba de camino.
 == Referencias ==