Ejercicio de Cipher Block Chaining

A continuación se presenta un ejercicio del CBC (Cipher Block Chaining). En este caso, tomando

como dato a cifrar uno en hexadecimal, que luego es convertido a binario y ya sobre el cuál se trabaja.

Para poder llevar a cabo el cifrado, el dato en binario se divide en bloques de 8 bits, a los cuales se les denomina "p", después se prosigue llevando a cabo el cifrado de cada uno de los bloques comenzando por p1, donde primero se le realiza un XOR con el vector de inicialización (IV) para después hacer un FES con las claves de AND1, OR2 y NOT, con lo que se obtiene C1, posteriormente se cifra el siguiente bloque, pero en este caso haciendo XOR con la C anterior y después aplicando un FES con las mismas operaciones clave y obteniendo así la siguiente C.

Todo ese proceso se repite ocho veces hasta obtener las 8 Cs.

Ahora para el descifrado, se parte de la primer C, se le aplica un FES inverso para descifrarla y al resultado se le hace un XOR con el vector de inicialización, que por resultado debe dar el bloque que se cifró, es decir las Ps, para las siguientes Cs, se aplica el mismo proceso, sólo que haciendo el XOR con la C anterior. Y finalmente para comprobar esto, cada descifrado tiene que dar exactamente lo mismo que cada una de las P.

Con esto queda realizado el CBC de manera exitosa.

La maquina enigma y el cifrado por bloques

Maquina Enigma.

La máquina Enigma fue inventada por un ingeniero alemán, Arthur Scherbius, Su idea consistía en aplicar el Cifrado de Vigenère, es decir se aplicaba un algoritmo de sustitución de unas letras por otras.

Al no contar con recursos para fabricarla, se asoció con Willie Korn quien tenía una compañía llamada Enigma Chiffiermaschinen AG en Berlín. Mejoraron el diseño y en 1923 la presentaron en la Exhibición Postal Internacional de Berlín para el cifrado de secretos comerciales.

La máquina enigma era electromecánica, es decir que una parte de su funcionamiento era mecánica, mientras que la otra era eléctrica, consistía en una serie de teclas con las letras del alfabeto, similar a una máquina de escribir, que en realidad eran interruptores que accionaban los dispositivos eléctricos y hacían mover unos cilindros rotatorios. Desde el punto de vista del operador, la forma en que funcionaba era bastante simple, tenía que teclear las letras de su mensaje y anotar las letras que devolvía la máquina (a través de un alfabeto que se iba iluminando).

El código a usar se fijaba con las posiciones de los cilindros que constaban, cada uno, de 26 cables que se conectaban al teclado pero, con la particularidad, que el primer cilindro giraba un veintiseisavo de vuelta después de cada pulsación, de tal manera que la posición de las conexiones iba cambiando con cada entrada del teclado, obteniendo un cifrado polialfabético.

Sumado a esto, el segundo cilindro sólo daba un giro cuando el primero había completado 26 giros y el tercero cuando el segundo había dado sus 26 y añadió la posibilidad de que los rodillos pudiesen ser intercambiados de posición, de manera que el número de posibilidades aumentase hasta tener 105,456 alfabetos.

Además, el sistema contaba con 6 cables de conexión que también permitían introducir modificaciones dado que podrían conectarse a 26 lugares (representando a las 16 letras del alfabeto de Enigma) lo que producía 100.391.791.500 maneras distintas de conectar los cables que unidos a los 105.456 alfabetos daba un total de:

3,283,883,513,796,974,198,700,882,069,882,752,878,379,955,261,095,623,
685,444,055,315,226,006,433,616,627,409,666,933,182,371,154,802,769,920,000,000,000 posibilidades distintas de codificación.

En 1933 Alemania nacionalizó a la compañía creadora de ésta máquina, y posteriormente procedió a armar a todo su ejército con ella, además de agregarle un cuarto cilindro para complicar aún más el intento de descifrar los mensajes.

Desde que obtuvieron esta máquina, el ejército nazi obtuvo una gran ventaja debido a que sus códigos eran prácticamente indescifrables y así tomaban la ventaja en el campo de batalla al poder envíarse mensajes sin el temor de que los aliados los interceptáran y los descifraran.

Sin embargo y a pesar de todos los mecanismos que utilizaba la máquina enigma, eventualmente fue vencida debido a los principales factores:

• Al haber sido en un inicio un producto comercial que fue presentado al público dentro de lo que cabe, la información de cómo operaba de manera esencial era conocida.
• La codificación de un mensaje obligaba al operador a introducir 3 letras dos veces cuando se iniciaba el mensaje, en un estilo de bandera, el ejército nazi no modificaba esa secuencia, por lo que se convirtió en una constante que aprovecharon los aliados para descifrar los códigos.
• Los aliados lograron capturar un submarino Alemán, con lo cual lograron obtener una máquina enigma y el libro de claves, pero hicieron la captura para el público como que el submarino se terminó hundiendo para así evitar que cambiaran las claves.

Debido a todos esos factores es que fue posible para los aliados derrotar a la máquina enigma y descifrar los mensajes de los alemanes, éstos intentaron recuperar la ventaja con su sucesora, la M4, pero los aliados crearon un computador llamado "Colossus" que fue diseñado para descifrar sus mensajes.

Al final de día, la máquina enigma terminó teniendo una mayor repercusión de lo que se podría pensar, dado que más allá de su uso militar, fue la causante de la creación de las primeras computadoras, que ya en el futuro se convertirían el todo lo que conocemos hoy en día.

Cifrado por bloques.

Una unidad de cifrado por bloques es una unidad de cifrado de clave simétrica que opera en grupos de bits de longitud fija (bloques), aplicándoles una transformación invariante.

Cuando se hace el cifrado, se toma como entrada un bloque de texto plano (o claro) y produce un bloque cifrado de igual tamaño. La transformación exacta es controlada utilizando una segunda entrada, ésta es la clave secreta dada por el usuario. Para realizar el proceso inverso (descifrado), se ingresa un bloque de texto cifrado y se produce el texto plano original.

El cifrado por bloques es diferente al cifrado por flujo (stream ciphers) debido a que, en este último, se opera en dígitos individuales, uno tras otro, y la transformación varía durante el proceso de cifrado.

 

Un ejemplo de cifrado por bloques conocido, es el llamado DES (Data Encryption Standard), que fue un diseño de unidad de cifrado por bloques de gran influencia. Fue desarrollado y publicado por IBM y se volvió un estándar en 1977, éste tuvo un sucesor, el Advanced Encryption Standard (AES), que fue adoptado en 2001.

Funcionamiento del cifrado por bloques.

Se emplean bloques de tamaño fijo del texto en claro y se crea un bloque de tamaño fijo de texto cifrado, por lo general de igual tamaño que la entrada. Dicho tamaño de bloque debe ser grande, para evitar ataques de texto cifrado, mientras que la asignación de bloques de entrada a bloques de salida debe ser uno a uno, para que el proceso reversible y parezca aleatorio. 

Para la asignación de bloques, los algoritmos de cifrado simétrico realizan sustituciones y permutaciones en el texto en claro hasta obtener el texto cifrado. La sustitución es el reemplazo de un valor de entrada por otro de los posibles valores de salida. La permutación es un tipo especial de sustitución en el que los bits de un bloque de entrada son reordenados para producir el bloque cifrado, esto es para preservar las estadísticas del bloque de entrada (el número de unos y ceros). 

Finalmente, los algoritmos de cifrado por bloques iterativos funcionan aplicando una transformación (función de rotación) sucesivas veces a un bloque de texto en claro. La cantidad de "rotaciones" depende del nivel de seguridad buscado. Se aplica una misma función a los datos usando una subclave obtenida de la clave secreta original dada por el usuario. 

Para implementar un algoritmo por bloques, se necesita romper el texto de entrada en bloques de longitud fija. Esto puede hacerse de cuatro formas: 

• ECB (Electronic Code Book).
• CBC (Cipher Block Chaining). 
• OFB (Output Feedback Mode). 
• CFB (Cipher Feedback Mode) 

CBC (Cipher Block Chaining) 

En el Cipher Block Chaining, a cada bloque de texto plano se le aplica la operación XOR con el bloque cifrado anterior antes de ser cifrado. De esta forma, cada bloque de texto cifrado depende de todo el texto en claro procesado hasta este punto. Para hacer cada mensaje único se utiliza asimismo un vector de inicialización. Es útil para transmisiones orientadas a bloques. Sin embargo, debido a este tipo de funcionamiento, no es posible realizar operaciones de cifrado en paralelo sobre varios bloques por esta dependencia de cada bloque con la operación del anterior.

CFR (Cipher Feedback).

Para comprender la forma en que funciona el CFR, es necesario primero conocer el funcionamiento del OFB (Output Feedback Mode) y a su vez, para éste es necesario el CTR (Counter Mode).

CTR simula un cifrado de flujo. Es decir, se usa un cifrado de bloque para producir un flujo pseudo aleatorio conocido como keystream. Este flujo se combina con el texto plano mediante XOR dando lugar al cifrado.

Para generar el keystream se cifra un contador combinado con un número aleatorio ("nonce") mediante ECB (Electronic Code Book Mode) y se va incrementando. El valor del contador puede ser públicamente conocido, y es necesario que el valor de nonce + contador lo conozcan ambos lados de la comunicación.

Una de las ventajas que ofrece es la posibilidad de precalcular el keystream (y/o trabajar en paralelo).

Como desventajas hay que tener en cuenta que reutilizar un contador en la misma clave puede ser desastroso, pues se generará de nuevo el mismo keystream. Modificar bits en el texto plano es muy sencillo, porque al modificar un bit del cifrado se modificará el bit del texto plano correspondiente (Bit-flipping attacks). Debido a esto es aconsejable usar el modo de cifrado junto con una verificación de la integridad del mensaje.

Ahora, la forma en la que funciona el OFB es muy similar al CTR, nada más que el keystream se genera cifrando el bloque anterior del keystream, dando lugar al siguiente bloque. El primer bloque de keystream se crea cifrando un vector de inicialización IV.

Conociendo esto, ya puede entenderse que el CFB funciona de manera similar a los dos anteriores, únicamente que para producir el keystream se cifra el último bloque de cifrado, en lugar del último bloque del keystream como hace OFB, pero por todo lo demás comparte las vulnerabilidades de éste, y por lo tanto del CTR.


Método de distribución de claves.

La distribución de claves es una de las partes más delicadas con las que se debe de lidiar al momento de trabajar con este tipo de sistemas, dado que si se lleva a cabo de una manera inadecuada, todo el trabajo que se hizo en el cifrado, valdría para absolutamente nada, debido a que se conocerían las llaves para obtener toda la información de lo que se quiere proteger.

El
 protocolo
 
IEEE802.10 muestra
 tres
 tipos 
de
 técnicas 
de 
distribución
 de 
claves, 
las
 cuales
 son:
 distribución
 
 manual
 de
 claves,
 distribución
 centralizada
 de
 claves
 y
 distribución
 certificada
 de 
claves.
Distribución manual de claves.

Las
 técnicas
 de
 distribución
 manual
 de
 claves
 utilizan
 procedimientos
 de
 entrega
 fuera
 de
 línea
 para
 establecer 
contraseñas 
compartidas
 en
 parejas
 o
 en 
grupos,
 esto
 es,
 se
 apoyan
 en 
métodos
 tradicionales 
(seguridad
 física
 y
 de 
confianza,
 correos 
seguros).

Distribución centralizada de claves.

Este
 tipo
 de
 distribución
 se
 hace
 necesaria 
cuando
 se
 requiere
 que
 ésta
 se
 lleve
 a
cabo
 sobre
 la
 misma
 red
 de
 comunicación
 donde
 se
 está
 transmitiendo
 la
 información
 que
 se
 va
 a
 proteger,
 cuando
 se
 necesita
 establecer
 contraseñas
 seguras
 entre
 parejas
 o
 en
 multidifusión
 entre
 entidades
 en
 comunicación
 y
 que
 se
 realice
 de
 manera
 automática,
 entonces
 la
 entrega 
se
 hace
 mediante
 una
 tercera
 entidad
 de
 confianza
 la
 cual
 puede
 ser
 un
 centro
 de
 distribución
 y
 trabajar
 conjuntamente
 con
 un
 centro
 traductor
 de
 claves.

Distribución certificada de claves.

Se 
emplea
 principalmente para
 realizar
 comunicaciones
 seguras 
entre
 parejas
 de
 interlocutores.
 En
 este
 contexto
 se
 identifican
 principalmente
 dos
 clases
 de
 técnicas
 de
 distribución:
 las
 cuales
 se
 conocen
 normalmente 
como
 transferencia
 de
 claves
 y
 acuerdo
 o
 intercambio
 de 
claves.

• Transferencia de Claves: La 
entrega
 o
 distribución 
se
 realiza
 a
 través
 de
 un
 criptosistema
 público
 a
través 
del
 cual
 se
 cifra 
una 
clave 
generada 
localmente
 en
 la 
entidad
 u 
organismo
 encargado
 de
 esta
 tarea
 así,
 la 
clave
 viajará
 protegida 
hasta
 la 
entidad 
remota
 de
 gestión
 de
 claves
 para
 su 
uso.
• Acuerdo o Intercambio de Claves: 
La
 clave
 a 
utilizar 
para
 la
 comunicación
 se 
genera
 con
 la
 participación
 de 
las
 entidades
 involucradas, 
esto
 es,
 la
 entidad 
que 
requiere 
dicha 
clave
 y
 la
 encargada
 de
 la 
generación 
de 
claves
 (la
 entidad 
local
 y
 la
 entidad 
remota).

http://hipertextual.com/2011/07/la-maquina-enigma-el-sistema-de-cifrado-que-puso-en-jaque-a-europa

http://www.alegsa.com.ar/Dic/cifrado%20por%20bloques.php

http://enciclopediateleco.blogspot.mx/2014/12/modos-de-operacion-ecb-cbc-cfb-ofb-y.html

http://dlerch.blogspot.mx/2007/07/modos-de-cifrado-ecb-cbc-ctr-ofb-y-cfb.html

http://www.openboxer.260mb.com/asignaturas/criptografia/distribucionDeClaves.pdf?ckattempt=1

Pruebas de Caja Negra

La prueba de caja negra lo que permite obtener es un conjunto de condiciones de entrada para así poder probar los funcionamientos de un sistema. A diferencia de la caja blanca que se enfoca en analizar cada uno de los caminos que puede recorrer el programa y ver qué hace en cada uno de ellos, en la caja negra, como bien dice su nombre, no se va a poder observar qué es lo que ocurre dentro de la caja (programa), sólo se va a poder observar qué es lo que entra y qué es lo que sale. Es debido a esto que este tipo de pruebas tienen ese nombre, y podría considerarse que son complementarias entre si, normalmente llevando a cabo primero la de caja blanca y después la de caja negra.

La utilidad de las pruebas de caja negra es bastante notoria, y dentro de las utilidades que ofrece, se encuentra el encontrar:

• Funciones incorrectas o ausentes.
• Errores de interfaz.
• Errores en estructuras de datos o en accesos a las Bases de Datos externas.
• Errores de rendimiento.
• Errores de inicialización y terminación.

Dentro de las pruebas de caja negra, existen principalmente 4 técnicas para llevarlas a cabo:

• Método Gráfico.
• Partición Equivalente.
• Análisis de Valores Límite.
• Tabla Ortogonal

Método Gráfico.

El método gráfico de caja negra, como bien dice su nombre se basa en tomar el programa en cuestión y hacer una representación gráfica del mismo, con la diferencia respecto a la caja blanca, de que aquí el enfoque va a ser principalmente a los objetos que conforman el programa y lógicamente, las entradas y las salidas.

Existen 5 tipos de modelados que se pueden utilizar en esta técnica, los cuales son:

• Modelado del flujo de transacción: Los nodos representan los pasos de alguna transacción, y los enlaces representan las conexiones lógicas entre los pasos.
• Modelado de estado finito: Los nodos representan diferentes estados del software observables por el usuario, y los enlaces representan las transiciones que ocurren para moverse de estado a estado.
• Modelado de flujo de datos: Los nodos son objetos de datos y los enlaces son las transformaciones que ocurren para convertir un objeto de datos en otro.
• Modelado de Planificación: Los nodos son objetos de programa y los enlaces son las conexiones secuenciales entre esos objetos. Los pesos de enlace se usan para especificar los tiempos de ejecución requeridos al ejecutarse el programa.
• Gráfica Causa-efecto: La gráfica Causa-efecto representa una ayuda gráfica en seleccionar, de una manera sistemática, un gran conjunto de casos de prueba. Tiene un efecto secundario beneficioso en precisar estados incompletos y ambigüedades en la especificación. Un gráfico de causa- efecto es un lenguaje formal al cual se traduce una especificación.

Con estos 5 tipos de modelados, es posible utilizar la técnica del método gráfico de una manera versátil y así permitir que se adapte a nuestras necesidades.

Partición Equivalente.

Lo que se hace en esta técnica, es dividir los datos de entrada en clases de equivalencia, esto quiere decir que dependiendo del tipo de dato que teóricamente acepta el programa, se creen clases de equivalencia de datos que sean válidos para lo que está esperando el programa e inválidos para el mismo:

1. Si una condición de entrada específica un rango de datos, existen 3 clases de equivalencia; dentro del rango (válido), debajo del rango (inválido) y por encima del rango (inválido).
2. Si la condición de entrada especifica un valor, existen 3 clases de equivalencia; el valor (válido), debajo del valor (inválido) y por encima del valor (inválido).
3. Si la condición de entrada especifica a un miembro de un conjunto, existen 2 clases de equivalencia; dentro del conjunto (válido) y fuera del conjunto (inválido).
4. Si la condición es booleana, existen 2 clases de equivalencia, verdadero y falso.

Análisis de Valores Límite.

Como dice su nombre, esta técnica maneja los valores límite que puede aceptar el programa, de cierta forma es algo similar a la partición equivalente, nada más que en este caso los datos de entrada con los que se trabajan se encuentran al borde de lo que puede aceptar el programa antes de provocar un error en su funcionamiento (aunque también puede utilizar los que están fuera de lo que puede aceptar, pero se acercan a ello), por ejemplo si un programa aceptara valores desde 1 hasta 10, el análisis de valores límite crearía los casos de prueba en base a los valores límite, es decir, tomando como datos 1 y 10, además de posiblemente, un 0.99 y un 10.1111, dado que así probaría los valores límite de la clase de equivalencia inválida para el programa.

Una característica que no debe olvidarse es que como se observó, en esencia se puede decir que el análisis de valores límite lo que hace es probar los extremos de cada clase de equivalencia que se podrían obtener para el programa.

Tabla Ortogonal.

Existen programas en donde el número de parámetros de entrada es pequeño y los valores de cada uno de los parámetros está claramente delimitado (es decir, no sé tiene que lidiar con un gran rango de posibilidades de datos de entrada). Cuando estas posibilidades son muy pocas, la prueba de tabla ortogonal permite proporcionar una buena cobertura de pruebas con bastantes menos casos de prueba que en la estrategia exhaustiva, esto debido más que otra cosa a que resultaría innecesario llevar a cabo una precisamente porque las posibilidades de entrada y salida del programa son muy pocas.

Fuentes:

http://www.innosupport.net/index.php?id=2084&L=6

http://www.innosupport.net/index.php?id=2080&L=6

http://www.ecured.cu/index.php/Pruebas_de_caja_negra

http://avanzada.idict.cu/index.php/avanzada/article/view/357

Prueba aplicada a un pseudocódigo

El siguiente es el pseudocódigo al cual se le aplicará la prueba, en particular la prueba de caja blanca:

Como puede verse, este pseudocódigo describe un proceso que acepta variables, les aplica procesos y al final devuelve otras.

Ahora, como se van a indicar con número cada proceso que lleva a cabo el código, el pseudocódigo marcado quedaría así:

Lo primero que debe de hacerse para aplicar la prueba es tomar este pseudocódigo y representar el proceso que describe de manera gráfica, en un principio a manera de diagrama de flujo y con cada uno de sus componentes con su numero de proceso (Se debe tener en cuenta que la union de los if, cuanta como el final del if, por lo tanto de un proceso.):

Con esto ya puede verse de manera gráfica cómo funciona el programa, ahora el siguiente paso es pasar el diagrama de flujo a un grafo utilizando nodos para representar cada proceso del programa:

Ya con este grafo, lo que se debe de hacer para aplicar la prueba de caja blanca, es analizar el grafo para determinar el número de caminos que existen en el proceso, con el objetivo de saber cuántos caminos tiene en total (complejidad ciclomática) y así determinar qué datos deben de ingresarse para recorrer cada camino y así probar la funcionalidad de los mismos.

1. 1, 4, 10, 11, 13
2. 1, 4, 10, 12, 13
3. 1, 4, 5, 8, 9, 2, 4, 10, 11, 13
4. 1, 4, 5, 6, 7, 8, 9, 2, 3, 4, 10, 11, 13
5. 1, 4, 5, 8, 9, 2, 4, 10, 12, 13
6. 1, 4, 5, 6, 7, 8, 9, 2, 3, 4, 10, 12, 13

Como se puede observar, existen 6 caminos que el programa puede recorrer durante su ejecución y llegar hasta el final, sin embargo algo que debe de tenerse en cuenta, es que es posible encontrar más caminos, pero éstos van a volverse redundantes en el sentido de que una secuencia del camino se va a repetir, y por lo tanto ya no sería válido.

Ahora una vez que tenemos los caminos, lo que se debe hacer es determinar los datos que deben de ingresarse para que el programa recorra todos los caminos.

Al analizar el programa, puede verse que acepta cuatro datos: valor, minimo, maximo y suma, sin embargo se puede observar que después se declara la variable de valor como un arreglo y se le dice que sus valores van a ser de 1 a 100, mientras que con suma, en una línea se iguala a 0, por lo tanto no tiene importancia qué valores se ingresen en estos campos, los únicos que sí importan es mínimo y máximo, sin embargo con estos dos campos sólo pueden recorrerse dos caminos:

• mínimo: 2, maximo: 5
• minimo: 0, maximo: 99

Como el resto de los caminos dependen de las condiciones de total.entrada y el valor de la variable valor en la posición i, para poder recorrerlos va a ser necesario forzar ciertas variables o condiciones, en este caso sería:

• total.entrada = 99
• total.entrada = 101
• i = -999
• i = -1000

Forzando esas condiciones, ya es posible recorrer el resto de caminos porque ya se pueden manipular las condicionales, y con esto se recorren todos los caminos y se verifica que cada uno de ellos funcione, es decir así ya se aplicó la prueba de caja blanca.

Características de las Pruebas

Las pruebas que se deben llevar a cabo a lo largo del desarrollo de un software, además de tener una clasificación en base a su función y un orden en el que deben llevarse a cabo, también poseen ciertas características generales que se aplican a todas, las cuales si se cumplen satisfactoriamente facilitan la aplicación de esas pruebas, e incrementan su efectividad.

Esas características son:

1. Ser fácil: Como su nombre lo dice, simplemente indica que la prueba debe de ser fácil de llevarse a cabo, o aplicarse.
2. Tener operatividad: Este aspecto quiere decir que mientras mejor hecha y más compleja sea la prueba en sí, va  a ser más fácil poder aplicarla para que encuentre los errores rápidamente.
3. Ser observable: Se refiere a que mientras se esté llevando a cabo una prueba, ésta va a tener entradas, salidas y uno o varios procesos, el ser observable quiere decir que todos estos elemento se saben y pueden analizarse.
4. Controlable: El que la prueba sea controlable indica que se tiene acceso y por lo tanto se pueden modificar las variables con las que ésta esté trabajando según vaya siendo necesario.
5. Capacidad de Descomposición: De la misma forma que un sistema está formado por módulos, la capacidad de descomposición de las pruebas quieren decir que sea capaz de probar módulos independientes de manera independiente, es decir que el resultado de la prueba de un módulo no afecte al de los demás.
6. Simple: Se refiere a que esté hecha de manera tal que hacer el set de pruebas y aplicarlo para ponerla en funcionamiento no sea complicado y se pueda llevar a cabo con rapidez.
7. Estable: Quiere decir que aunque se tengan que llevar a cabo ajustes o cambios ya sea en el sistema que se está probando o en la prueba en sí, ésta siga funcionando adecuadamente o que no sea necesario rehacerla completamente desde cero.
8. Facilidad de Comprensión: De manera sencilla, esta característica quiere decir que la prueba debe de ser fácil de entender en el sentido de entender qué es lo que está probando y de qué forma lo está haciendo.

Si una prueba cumple con todas estas características, será mucho más probable que su efectividad esté garantizada y cumpla correctamente con su función.

Ahora hablaremos un poco de dos pruebas en específico que están enfocadas a un aspecto que se menciona en la tercer característica, las entradas, salidas y procesos. Estas son las llamadas "Pruebas de Caja Blanca" y "Pruebas de Caja Negra":

Prueba de Caja Blanca.

La prueba de caja blanca se basa en el diseño y uso de casos de prueba que estén hechos en base al software o sistema a probar, es debido a esto que la prueba de caja blanca ofrece las siguientes características:

1. Garantizar que se ejecuten por lo menos una vez todos los caminos independientes de cada módulo.
2. Llevar a cabo todas las ramificaciones lógicas de verdadero o falso.
3. Ejecutar todos los bucles en sus límites operacionales.
4. Ejecutar estructuras internas de datos para garantizar su validez.

Estas características de la prueba de caja blanca nos dan a entender que al diseñar los casos de prueba en base al propio diseño de lo que se va a probar, se puedan recorrer todos los caminos que de los que disponga para asegurar que funcionen correctamente. Existe una técnica para llevar a cabo esta prueba, conocido como "Prueba del camino básico".

Prueba de camino básico.

Esta prueba en una técnica desarrollada por Tom McCabe para llevar a cabo pruebas de caja blanca, la idea del camino básico es primero comprender el diseño del sistema y representarlo a manera de grafo, para que ya con éste se puedan diseñar los casos de prueba que fuercen cada camino. Los pasos a seguir son los siguientes:

1. A partir del diseño o código fuente, hacer la representación gráfica del flujo en cuestión a manera de grafo.
2. Calcular la complejidad ciclomática del grafo.
3. Determinar conjunto básico de caminos independientes.
4. Preparar los casos de prueba que obliguen a la ejecución de cada camino del conjunto básico.

Ejecutando cada uno de los pasos, se logra hacer una prueba que ejecute cada camino que puede seguir el programa, es decir una prueba de caja blanca.

En el primer paso se necesita crear un grafo del flujo del programa utilizando su diseño o código fuente, este grafo tiene 3 elementos fundamentales para su construcción:

• Nodo: Básicamente representa una o más secuencias procedimentales, una sentencia de decisión o una secuencia de procesos.
• Aristas: Son las flechas que se utilizan para unir cada nodo y representan el flujo de control del programa.
• Regiones: Son las áreas delimitadas por las aristas y nodos, contando también el área del exterior del grafo, cada una de estas regiones se enumeran y el numero de regiones es equivalente a la cantidad de caminos independientes del conjunto básico de un programa.

Otro aspecto que se debe conocer es la denominada "Complejidad Ciclomática", ésta es una métrica del software que proporciona una medición cuantitativa de la complejidad lógica de un programa, en esencia el valor que nos dé indica el límite superior para el número de pruebas que se deben realizar para asegurar que se ejecute cada sentencia por lo menos una vez.

Prueba de Caja Negra.

La prueba de caja negra permite obtener un conjunto de condiciones de entrada que lleven a cabo completamente todos los requisitos funcionales de un programa, en ellas se ignora la estructura de control, sino que se concentra en los requisitos funcionales del sistema y los ejecuta.

Se considera como un complemento a la prueba de caja blanca, y dentro de las características que ofrece se encuentra el permitir encontrar:

1. Funciones incorrectas o ausentes.
2. Errores de Interfaz.
3. Errores en estructuras de datos o en accesos a las bases de datos externas.
4. Errores de rendimiento.
5. Errores de inicialización y terminación.

Para preparar los casos de prueba necesarios, se necesitan un número de datos que ayuden a la ejecución de los casos y que le permitan al sistema correr en todas sus variantes, estos datos pueden ser válidos o inválidos dependiendo de si se quiere encontrar un error o probar una funcionalidad.

Para desarrollar una prueba de caja negra existen diversas técnicas, algunas de ellas son:

• Técnica de la Partición de Equivalencia: Divide el campo de entrada en clases de datos que ejecutan determinadas funciones del software.
• Técnica del Análisis de Valores Límite: Prueba la habilidad del programa de manejar datos que se encuentren dentro de los límites aceptables.
• Técnica de Grafos de Causa-Efecto: Permite validar complejos conjuntos de acciones y condiciones.

La técnica más utilizada en las prueba de caja negra es la de partición de equivalencia, dado que permite examinar los valores válidos e inválidos de las entradas existentes en el software y así descubrir más rápidamente errores que podrían tomar más tiempo de encontrar utilizando otro método.

Con esto se puede concluir que las pruebas de caja negra y blanca son complementarias entre si, mientras que la primera se enfoca en las entradas y las salidas, la segunda se enfoca en los caminos que sigue el programa en cada caso, así en conjunto son una prueba muy completa del diseño y funcionalidad de un programa.

http://gemini.udistrital.edu.co/comunidad/grupos/arquisoft/fileadmin/Estudiantes/Pruebas/HTML%20-%20Pruebas%20de%20software/node27.html

http://testingfuncional.wordpress.com/2011/03/12/%C2%BFtesting-funcional-o-pruebas-de-caja-negra/

http://www.ecured.cu/index.php/Pruebas_de_caja_blanca

PRESSMAN, ROGER S. Ingenieria de Software Un Enfoque Práctico

Prueba de resistencia a una bicicleta

Dentro de las pruebas que se llevan a cabo en un software, se encuentra una llamada "Prueba de Resistencia", esta prueba como su nombre dice, se refiere a probar la capacidad de resistencia del software, principalmente frente a la sobrecarga de información y solicitudes para poder lidiar con ello sin colapsar, sin embargo para ilustrar de manera más sencilla este tipo de prueba, se llevará a cabo con una bicicleta.

Una prueba de resistencia con una bicicleta se podría llevar a cabo de dos formas:

• Desde el punto de vista del fabricante.
• Desde el punto de vista del comprador.

Fabricante

La prueba de resistencia que llevaría a cabo el fabricante sería durante la construcción de la bicicleta, y lo que se llevaría a cabo sería someter a la bicicleta a distintas situaciones "extremas", esto se refiere a:

• Choques con distintos materiales.
• Resistencia de las cadenas.
• Aguante de las llantas.
• Aguante de frenos.
• etc.

En esencia lo que haría esta prueba sería someter a la bicicleta, o más específicamente a cada una de sus partes a una situación "extrema", en la cual esa parte en específico tiene que lograr cumplir con la función sin romperse, por ejemplo el esqueleto de la bicicleta debería de aguantar choques contra metal, paredes de distintos materiales, autos, etc, intentar frenar a velocidades muy altas, someter a las llantas a distintas superficies, etc. Toda aquella situación a la que se podría enfrentar una bicicleta una vez esté en las manos del comprador, todo esto con el objetivo de ver hasta dónde es capaz de aguantar cada una de sus partes, o la bicicleta entera antes de descomponerse.

Comprador

Del lado del comprador, la prueba de resistencia que éste podría aplicar sobre la bicicleta sería más que otra cosa, someter a la misma al uso más intenso que éste podría aplicarle, porque desde el punto de vista del comprador, la resistencia que va a requerir de la bicicleta es que soporte el uso que éste le va a dar, por lo que la forma en la que probaría la resistencia de la bicicleta sería simplemente utilizándola, tal ves con el agregado de darle el uso más intenso que podría presentarse en circunstancias especiales, pero más allá de eso, el comprador no puede realmente hacer mucho más en cuanto a pruebas de resistencia, más que otra cosa porque no lo necesita.

Pruebas de Software

Para poder hablar de las "Pruebas de Software", primero es necesario conocer el proceso mediante el cual son desarrollados los softwares, a este proceso que no solo incluye su periodo de desarrollo, sino también su implementación y manutención, se le llama "Ciclo de Vida del Software" y puede resumirse en la siguiente ilustración:

Pruebas.

Ya una vez conociendo en qué momento de la vida del software se llevan a cabo las pruebas, se puede hablar de que las pruebas pueden entenderse como actividades que se planean con anticipación y se llevan a cabo de forma sistemática, pero al aplicarse al software, necesitan de un plan de pruebas de software, Éstos son procesos en el que se ejecuta un programa con la intención de encontrar un error que aún  o se descubre.

Verificación y Validación.

Cuando se está desarrollando un software y se van aplicando las pruebas, algo que nunca debe perderse de vista es que constantemente debe de llevarse a cabo validaciones y verificaciones, pero ¿Qué significan estos dos conceptos?

• Validación: En el ámbito del software, la validación es el proceso de revisión al que se somente un programa para comprobar que cumple con sus especificaciones. Esto se realiza con la intención de confirmar que el programa permita llevar a cabo las tareas que sus potenciales usuarios esperan de ella. Éste concepto puede sintetizarse con la pregunta: ¿Se está construyendo el producto correcto?
• Verificación: Tiene su raíz en el latin "Veriticare" que está compuesto por dos partes: "veritas" (verdadero), y "facere" (hacer). Con esto se entiende que verificación es la acción de verificar, que es comprobar o examinar la verdad de algo, y suele ser un proceso que se realiza para revisar si una determinada cosa está cumpliendo con los requisitos y normas previstos, se puede sintetizar con la siguiente pregunta: ¿Se está construyendo correctamente el producto?

Tipos de Pruebas:

• Pruebas de Unidad:
• Son pruebas que lo que hacen es probar una unidad estructural de un código y tienen las siguientes características:
• Unitarias: Prueban únicamente pequeñas cantidades del código.
• Independiente: No debe depender ni afectar a otras pruebas unitarias.
• Prueba métodos públicos: De otra manera la prueba sería frágil a cambios en la implementación y no se podría utilizar en pruebas de regresión.
• Automatizable: La prueba no debería requerir intervención manual.
• Repetición y Predecible: No debe incidir el orden y las veces que se repita la prueba, el resultado debe ser siempre el mismo.
• Profesionales: Deben tener la misma importancia y cuidado que el mismo código.
• Pruebas de Integración:
• Su propósito es probar grupos de unidades relacionadas para verificar su operación conjunta, por lo que su énfasis está en la interacción de las partes, no en cada parte individual, gracias a esto son capaces de identificar problemas de interfaces entre unidades y la falta de coherencia entre lo que se espera de una unidad y lo que se ofrece.
• Pruebas de Validación:
• Como su nombre lo indica, son pruebas cuyo objetivo es validar lo que se está haciendo, en este caso el software o proyecto, y esta validación debe de llevarse a cabo con la persona que quiere ese software, es decir el cliente para que éste confirme o desmienta que el software en desarrollo cumpla con sus requerimientos y especificaciones.
• Pruebas de Sistema:
• Como dice su nombre, el propósito de este tipo de pruebas es poner a prueba el sistema ya en su totalidad, con todas las partes que deben de intervenir en él, tanto la parte de codificación y funcionamiento de cada uno de sus módulos, pasando por la integración de éstos para que funcionen como uno solo, hasta la parte de la interacción de los usuarios con el sistema, podría decirse que lo se hace es probar al sistema en su "ambiente natural".