CBC

Máquina Enigma 

La máquina Enigma fue inventada por un ingeniero alemán, Arthur Scherbius, un experto en electromecánica, quiso aplicar la tecnología existente para mejorar los sistema de criptografía de los ejercitos después de la Primera Guerra Mundial, utilizó el Cifrado de Vignére, un algoritmo de sustitución de unas letras por otras
El mecanismo consistía en una serie de teclas, con las letras del alfabeto, al igual que una máquina de escribir, que en realidad eran interruptores que accionaban los dispositivos eléctricos y hacían mover unos cilindros rotatorios. El funcionamiento, cara al usuario, era bastante sencillo. El operador 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.

Cipher Block Chaining (CBC)

Es un cifrado de bloques de texto plano de clave simétrica que opera un longitud de bits fija, a la cuál se le aplica un XOR con el bloque cifrado  anterior antes de ser cifrado, cada bloque de texto cifrado depende de todo el texto en claro

Cipher feedback (CFB) 

Estos modos de cifrado hacen que el cifrado en bloque opere como flujo de cifrado, se generan bloques de flujo de claves que son operados con XOR y el texto en claro para obtener el texto cifrado.

Distribución de claves

Distribución manual de claves

Utilizan procedimientos de entrega fuera de linea para establecer contraseñas compartidas en parejas o en grupos. Se apoya en métodos tradicionales y la distribución pude ser efectuada solo una vez.

Distribución centralizada de claves

Este tipo de distribución se aplica cuando el intercambio es llevado a cabo sobre la red de comunicación que transmite la información protegida. La entrega se hace mediante una entidad de confianza la cual puede ser un centro de distribución, apoyándose en un centro traductor de claves.

Distribución certificada de claves

La distribución basada en certificados se emplea 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 típicamente como transferencia de claves y acuerdo o intercambio de claves. Este tipo de distribución permite el establecimiento de la PKI (Public Key Infraestructure), la cuál se basa en la creación de certificados digitales e intercambio de claves a través de algoritmos de criptografía asimética.

Métodos de prueba de caja negra

Partición equivalente

Es una técnica de prueba de caja negra que divide el dominio de entrada de un programa en clases de datos de los que se pueden derivar casos de prueba.

El diseño de pruebas se basa en una evaluación de las clases de equivalencia para una condición de entrada.

Una clase de equivalencia representa un conjunto de estados válidos o inválidos para condiciones de entrada, siendo las condiciones de entrada un rango de valores, conjunto de valores o una condición lógica.

Las clases de equivalencia se definen de acuerdo a las siguientes directrices.

-Si un parámetro de entrada debe estar comprendido en cierto rango, con tres clases de equivalencia por debajo, en y encima de.

-Si una entrada requiere un valor concreto, aparecen 3 clases de equivalencia: por debajo, en y encima de.

-Si una entrada requiere un valor de entre los de un conjunto, son 2 clases dentro del conjunto o fuera de el.

-Si una entrada es boolean.

Se aplican los mismos criterios a las salidas esperadas.

Aplicando estas directrices se ejecutan casos de pruebas para cada elemento de datos del campo de entrada a desarrollar. Los casos se seleccionan de forma que ejerciten el mayor número de atributos de cada clase de equivalencia a la vez.

Análisis de valores límite (AVL)

Es la técnica de diseño de pruebas de caja negra en la cual los casos de prueba son diseñados en base a los valores límite que se encuentra en la frontera de una partición equivalente.

Este método se basa en la evidencia experimental de que los errores suelen aparecer con mayor probabilidad los extremos de los campos de entrada aumentando la eficiencia de la prueba.

Método gráfico de prueba

Es una forma de tomar nuestro programa y hacer una representación gráfica del mismo mediante gráfos.

Grafo

Rutas 

1,4,10,11,13

1,4,10,12,13

1,4,(5,6),7,8,9,(2,3),4,10,11,13

1,4,(5,6),7,8,9,(2,3),4,10,12,13

1,4,(5,6),8,(2,3),4,10,11,13

1,4,(5,6),8,(2,3),4,10,12,13

Pruebas caja negra y caja blanca

Pruebas de caja negra
Las pruebas de caja negra se hacen desde la interfaz del software con datos de entrada y de salida.

• Se centran en los requisitos funcionales.
• Se enfocan en entradas y salidas de datos.
• Prueban el rendimiento del sistema.
• Comprueban los valores limites.
• Se realizan desde el exterior de un módulo.

Pruebas de caja blanca.
Las pruebas de caja blanca se realizan desde el interior programa o sea el código fuente comprobando la lógica de este.

• Se encargan de verificar que la lógica funcione tal como esta definida.
• Se realizan sobre las funciones internas de un módulo.
• Pueden aplicarse a los métodos de la clase.
• Seguimiento del código fuente determinando de manera concreta de los errores que se producen.

Características de pruebas

1. Debe ser fácil.
• Sencillez de pruebas
2. Operatividad
• Facilidad en implementación
3. Observable
• Que se puedan conocer los errores de la prueba
4. Controlable
• Que se decida hasta donde se realiza la pruebas
5. Capacidad de descomposición.
• Digamos que se pueda dividir en distintas formas como factorizar productos
6. Simple
• Hacer pruebas solo a lo necesario
7. Estable
• Evitar gran cantidad de cambios
8. Facilidad de comprensión
• Mayor probabilidad de encontrar errores

Conclusión 

Tanto las pruebas de caja negra y de caja blanca deben aplicarse en conjunto, ya que una evalua los errores desde el código fuente y otra que la relación entre las entradas y salidas. Pero con ellas no se garantiza que un software jamas falle, tan solo se disminuye el riesgo de estas.

Pruebas de sistema

Pruebas de resistencia a una bicicleta

Problema / Parte de la bicicleta	Pruebas de resistencia
Capacidad de personas o peso de la bicicleta.	Ver cuántas personas o peso aguanta la bicicleta hasta que se dañen los rayos o la cámara de la llanta.
Frenos de la bicicleta.	Probar hasta qué punto sirven los frenos eficazmente dependiendo de la velocidad de rotación de la llanta.
Resistencia de la cadena.	Probar las revoluciones máximas que puede soportar la cadena sin zafarse del engranaje.
Manubrio.	Mover el manubrio hasta su punto máximo dependiendo del tipo de bicicleta.
Llantas.	Con que objetos se pueden ponchar fácilmente
Amortiguador.	Probar la capacidad de absorción de este en distintos terrenos.
Caídas o choques.	Tirar la bicicleta de distintas formas y provocar colisiones, analizar el daño que recibe y la gravedad de este.

Balderas Acevés Lidia Lizbeth 

Rodríguez Albarrán Victor Hugo

Sánchez Caballero Alberto

Torres Díaz Raymundo.

Ensayo

Ensayo.

Introducción.

En el proceso de desarrollo de software hay muchas cosas importantes que se deben llevar a cabo, una es seguir el ciclo de vida del software que describe los pasos necesarios que se deben realizar al pie de la letra para poder asegurar que nuestro producto tenga calidad.

Dentro del ciclo de vida el software existen otros procesos una de ellas son las pruebas, estas con el objetivo de buscar errores en el sistema y, que cumpla con los requisitos del cliente funcionando correctamente.

Desarrollo.

Ciclo de vida del software con pruebas.

El ciclo de vida de software describe el desarrollo de software desde el inicio hasta el final. El propósito de este proceso es definir las distintas fases intermedias que se requieren para validar el desarrollo de la aplicación, es decir, para garantizar que el software cumpla con los requisitos para la aplicación y verificación de los procedimientos de desarrollo asegurándose que las pruebas utilizadas son apropiadas garantizando la calidad del software.

Pruebas

Las pruebas son un conjunto de actividades en las que se incluyen técnicas y métodos específicos de casos de prueba con el objetivo de encontrar errores en el producto para poder solucionarlos.

Verificación y validación.

La verificación y la validación abarcan una amplia lista de actividades que aseguran la calidad del software. Las pruebas tienen un papel muy importante en validación y verificación siendo la mejor forma de evaluar la calidad y corregir errores.

¿Qué es validación?

La validación es un proceso que se realiza antes de la entrega del producto al cliente con el objetivo de determinar si el producto satisface sus especificaciones, o sea si cumple con los requerimientos y necesidades del cliente.

¿Qué es verificación?

Se refiere al proceso de determinar si un flujo de trabajo se ha llevado a cabo en forma correcta.

El proceso de ambas es un ciclo vital y debe aplicarse en cada etapa del desarrollo del software.

Pruebas de unidad.

Las pruebas unitarias tienen como objetivo verificar la funcionalidad y estructura de cada componente individualmente que ha sido codificado, para probar los subprogramas, subrutinas, los procedimientos individuales o las clases del programa. Es decir, probar los bloques desarrollado más pequeños del programa, que probar inicialmente el software en su totalidad.

Hay tres razones para llevar a cabo este tipo de pruebas. Primero, porque son una forma de manejar los elementos de prueba ya integrados puesto que se centra la atención desde el inicio en las unidades más pequeñas. Segundo, porque la prueba de unidad facilita la búsqueda y eliminación de errores. Y tercero, las pruebas de unidad introducen paralelismo en el proceso de pruebas del software permitiendo probar distintos módulos simultáneamente.

Pruebas de integración.

Las pruebas de integración son para corroborar el correcto ensamblaje entre los distintos componentes, una vez que han sido probados unitariamente, con el propósito de comprobar la correcta interacción con las interfaces, la funcionalidad establecida y se ajustan a los requisitos no funcionales.

Los tipos de integración son:

·         Integración incremental: Se combina el siguiente componente que se debe probar con el conjunto de componente que ya están probados y se va incrementando progresivamente el número de componentes a probar.

·         Integración no incremental: Se prueba cada componente por separado y después se integran todos de una vez realizando pruebas pertinentes.

Pruebas de validación.

El objetivo de estas pruebas es validar que un sistema cumple con el funcionamiento esperado y permitir al usuario que el sistema determine su aceptación, desde el punto de vista de su funcionalidad y rendimiento.

Estas pruebas son definidas por el usuario del sistema y preparadas por el equipo de desarrollo, aunque la ejecución y aprobación corresponden al usuario.

La validación del sistema se obtienen con pruebas de caja negra que demuestren conformidad con los requisitos y que se recogen en el plan de pruebas, el cuál define las verificaciones a realizar y los casos de prueba asociados.

Pruebas de sistema.

Las pruebas de sistema buscan discrepancias en el programa y sus requerimientos, enfocándose en los errores hechos durante la transición de proceso al diseñar la especificación funcional, esto hace a las pruebas del sistema un proceso vital de pruebas, ya que es un paso en el ciclo de desarrollo propenso a la mayor parte de los errores.

Conclusiones.

El objetivo principal de un software, es satisfacer las necesidades del cliente con sus respectivos requerimientos. Por esa razón hay la necesidad de seguir un proceso para cumplir con tal objetivo, siendo esté proceso el ciclo de vida del software.

Este ciclo unifica desde el análisis del problema hasta la entrega del producto, las pruebas son una parte fundamental de todo el desarrollo para comprobar que el producto haga los que el cliente requiere y funcione correctamente.

Todo el proceso en conjunto aseguran que el producto sea un software de calidad permitiendo la satisfacción del cliente.

Referencias.

(Marzo 14, 2015).Verificación y validación de software. Fecha de consulta (Septiembre 26, 2015)

http://mmedia1.fi-b.unam.mx/material/t1046/tutorial/tutorial-VV.pdf

Herrera Gonzalez Carlos Arturo, (Mayo 2012). "Estrategias de aplicación de prueba de unidad, de integración, sistema y de aceptación". Fecha de consulta (Septiembre 26, 2015)

http://es.slideshare.net/carlblakc/estrategias-de-aplicacin-de-prueba-de-unidad-integracin-sistema-y-de-aceptacin