VIDEO INGENIERIA DEL SOFTWARE

PRUEBA DE USABILIDAD Y DE UNIDAD

Usabilidad: Este tipo de prueba se refiere a asegurar de que la interfaz de usuario (o GUI) sea intuitiva, amigable y funcione correctamente.

Unidad: Este tipo de prueba solo aplica a proyectos grandes. Se divide el proyecto a unidades y cada unidad es sometida a prueba individualmente.

texto extraido de la pagina http://robertoyudice.com

PRUEBAS DE REGRESION

Se denominan Pruebas de regresión a cualquier tipo de pruebas de software que intentan descubrir las causas de nuevos errores (bugs), carencias de funcionalidad, o divergencias funcionales con respecto al comportamiento esperado del software, inducidos por cambios recientemente realizados en partes de la aplicación que anteriormente al citado cambio no eran propensas a este tipo de error. Esto implica que el error tratado se reproduce como consecuencia inesperada del citado cambio en el programa.

Este tipo de cambio puede ser debido a prácticas no adecuadas de control de versiones, falta de consideración acerca del ámbito o contexto de producción final y extensibilidad del error que fue corregido (fragilidad de la corrección), o simplemente una consecuencia del rediseño de la aplicación.

Por lo tanto, en la mayoría de las situaciones del desarrollo de software se considera una buena práctica que cuando se localiza y corrige un bug, se grabe una prueba que exponga el bug y se vuelvan a probar regularmente después de los cambios subsiguientes que experimente el programa.

Existen herramientas de software que permiten detectar este tipo de errores de manera parcial o totalmente automatizada, la práctica habitual en programación extrema es que este tipo de pruebas se ejecuten en cada uno de los pasos del ciclo de vida del desarrollo del software.

Las Pruebas de Regresión pueden usarse no solo para probar la corrección de un programa, sino a menudo usarse para rastrear la calidad de su salida.

Por ejemplo en el diseño de un compilador, las pruebas de regresión deben rastrear el tamaño del código, tiempo de simulación, y el tiempo de compilación de las suites de prueba. Cuando quiera que aparece un nuevo build, el proceso de regresión aparece.

texto extraido de la pagina  de http://es.wikipedia.org 

PRUEBA DE (CAJA NEGRA) SISTEMA

En teoría de sistemas y física, se denomina caja negra a aquel elemento que es estudiado desde el punto de vista de las entradas que recibe y las salidas o respuestas que produce, sin tener en cuenta su funcionamiento interno. En otras palabras, de una caja negra nos interesará su forma de interactuar con el medio que le rodea (en ocasiones, otros elementos que también podrían ser cajas negras) entendiendo qué es lo que hace, pero sin dar importancia a cómo lo hace. Por tanto, de una caja negra deben estar muy bien definidas sus entradas y salidas, es decir, su interfaz; en cambio, no se precisa definir ni conocer los detalles internos de su funcionamiento.

CAJA NEGRA Y PROGRAMACION MODULAR

En programación modular, donde un programa (o un algoritmo) es divido en módulos, en la fase de diseño se buscará que cada módulo sea una caja negra dentro del sistema global que es el programa que se pretende desarrollar, de esta manera se consigue una independencia entre los módulos que facilita su implementación separada por un equipo de trabajo donde cada miembro va a encargarse de implementar una parte (un módulo) del programa global; el implementador de un módulo concreto deberá conocer como es la comunicación con los otros módulos (la interfaz), pero no necesitará conocer como trabajan esos otros módulos internamente; en otras palabras, para el desarrollador de un módulo, idealmente, el resto de módulos serán cajas negras.

PRUEBAS DE SOFTWARE

En pruebas de software, conociendo una función específica para la que fue diseñado el producto, se pueden diseñar pruebas que demuestren que dicha función está bien realizada. Dichas pruebas son llevadas a cabo sobre la interfaz del software, es decir, de la función, actuando sobre ella como una caja negra, proporcionando unas entradas y estudiando las salidas para ver si son o no las esperadas.

Texto extraido de la pagina:

http://es.wikipedia.org/

PRUEBA DE (CAJA BLANCA) SISTEMA

En programación, se denomina cajas blancas a un tipo de pruebas de software que se realiza sobre las funciones internas de un módulo. Así como las pruebas de caja negra ejercitan los requisitos funcionales desde el exterior del módulo, las de caja blanca están dirigidas a las funciones internas. Entre las técnicas usadas se encuentran; la cobertura de caminos (pruebas que hagan que se recorran todos los posibles caminos de ejecución), pruebas sobre las expresiones lógico-aritméticas, pruebas de camino de datos (definición-uso de variables), comprobación de bucles (se verifican los bucles para 0,1 y n iteraciones, y luego para las iteraciones máximas, máximas menos uno y más uno.

Las pruebas de caja blanca se llevan a cabo en primer lugar, sobre un módulo concreto, para luego realizar las de caja negra sobre varios subsistemas (integración).

En los sistemas orientados a objetos, las pruebas de caja blanca pueden aplicarse a los métodos de la clase, pero según varias opiniones, ese esfuerzo debería dedicarse a otro tipo de pruebas más especializadas (un argumento podría ser que los métodos de una clase suelen ser menos complejos que los de una función de programación estructurada).

Este concepto también es utilizado de manera análoga en la teoría general de sistemas.

 El anterio texto fue extraido de http://es.wikipedia.org/

PRUEBA DE VALIDACION

Las pruebas de validación en la ingeniería de software son el proceso de revisión que el sistema de software producido cumple con las especificaciones y que cumple su cometido. Es normalmente una parte del proceso de pruebas de software de un proyecto, que también utiliza técnicas tales como evaluaciones, inspecciones, y tutoriales. La validación es el proceso de comprobar lo que se ha especificado es lo que el usuario realmente quería.

Se trata de evaluar el sistema o parte de este durante o al final del desarrollo para determinar si satisface los requisitos iniciales. La pregunta a realizarse es: ¿Es esto lo que el cliente quiere?.

ENFOQUES A LA VERIFICACION

• Dinámica de verificación, también conocido como ensayos o experimentación.
• Estática de verificación, también conocido como análisis.

 TIPOS:

• Pruebas de aceptación: desarrolladas por el cliente.
• Pruebas alfa realizadas por el usuario con el desarrollador como observador en un entorno controlado (simulación de un entorno de producción).
• Pruebas beta: realizadas por el usuario en su entorno de trabajo y sin observadores.

CARACTERISTICAS

Comprobar que se satisfacen los requisitos:

• Se usan la mismas técnicas, pero con otro objetivo.
• No hay programas de prueba, sino sólo el código final de la aplicación.
• Se prueba el programa completo.
• Uno o varios casos de prueba por cada requisito o caso de uso especificado.
• Se prueba también rendimiento, capacidad, etc. (y no sólo resultados correctos).
• Pruebas alfa (desarrolladores) y beta (usuarios).

El anterior texto fue extraido de la siguiente pagina

http://es.wikipedia.org/

PRUEBAS FUNCIONALES

Una prueba funcional es una prueba basada en la ejecución, revisión y retroalimentación de las funcionalidades previamente diseñadas para el software. La pruebas funcionales se hacen mediante el diseño de modelos de prueba que buscan evaluar cada una de las opciones con las que cuenta el paquete informático.

  texto extraido de   http://es.wikipedia.org/

PRUEBA UNITARIA

una prueba unitaria es una forma de probar el correcto funcionamiento de un módulo de código. Esto sirve para asegurar que cada uno de los módulos funcione correctamente por separado. Luego, con las Pruebas de Integración, se podrá asegurar el correcto funcionamiento del sistema o subsistema en cuestión.

La idea es escribir casos de prueba para cada función no trivial o método en el módulo de forma que cada caso sea independiente del resto.

CARACTERISTICAS

Para que una prueba unitaria sea buena se deben cumplir los siguientes requisitos:

• Automatizable: no debería requerirse una intervención manual. Esto es especialmente útil para integración continua.
• Completas: deben cubrir la mayor cantidad de código.
• Repetibles o Reutilizables: no se deben crear pruebas que sólo puedan ser ejecutadas una sola vez. También es útil para integración continua.
• Independientes: la ejecución de una prueba no debe afectar a la ejecución de otra.
• Profesionales: las pruebas deben ser consideradas igual que el código, con la misma profesionalidad, documentación, etc.

Aunque estos requisitos no tienen que ser cumplidos al pie de la letra, se recomienda seguirlos o de lo contrario las pruebas pierden parte de su función.

VENTAJAS

El objetivo de las pruebas unitarias es aislar cada parte del programa y mostrar que las partes individuales son correctas. Proporcionan un contrato escrito que el trozo de código debe satisfacer. Estas pruebas aisladas proporcionan cinco ventajas básicas:

1. Fomentan el cambio: Las pruebas unitarias facilitan que el programador cambie el código para mejorar su estructura (lo que se ha dado en llamar refactorización), puesto que permiten hacer pruebas sobre los cambios y así asegurarse de que los nuevos cambios no han introducido errores.
2. Simplifica la integración: Puesto que permiten llegar a la fase de integración con un grado alto de seguridad de que el código está funcionando correctamente. De esta manera se facilitan laspruebas de integración.
3. Documenta el código: Las propias pruebas son documentación del código puesto que ahí se puede ver cómo utilizarlo.
4. Separación de la interfaz y la implementación: Dado que la única interacción entre los casos de prueba y las unidades bajo prueba son las interfaces de estas últimas, se puede cambiar cualquiera de los dos sin afectar al otro, a veces usando objetos mock (mock object) para simular el comportamiento de objetos complejos.
5. Los errores están más acotados y son más fáciles de localizar: dado que tenemos pruebas unitarias que pueden desenmascararlos.

TIPOS DE PRUEBAS

Las pruebas de software, en inglés testing son los procesos que permiten verificar y revelar la calidad de un producto software. Son utilizadas para identificar posibles fallos de implementación, calidad, o usabilidad de un programa de ordenador o videojuego. Básicamente es una fase en el desarrollo de software consistente en probar las aplicaciones construidas.

Las pruebas de software se integran dentro de las diferentes fases del ciclo del software dentro de la Ingeniería de software. Así se ejecuta un programa y mediante técnicas experimentales se trata de descubrir que errores tiene.

Para determinar el nivel de calidad se deben efectuar unas medidas o pruebas que permitan comprobar el grado de cumplimiento respecto de las especificaciones iniciales del sistema.

El testing puede probar la presencia de errores pero no la ausencia de ellos.

El proceso de prueba es un proceso técnico especializado de investigación que requiere de profesionales altamente capacitados en lenguajes de desarrollo, métodos y técnicas de pruebas y herramientas especializadas. El conocimiento que debe manejar un ingeniero de prueba es muchas veces superior al del desarrollador de software.

Tipos de pruebas

 

• 
  
  Pruebas unitarias
• 
  
  Pruebas funcionales
• 
  
  Pruebas de validación
• 
  
  Pruebas de sistema
• 
  
  Caja blanca (sistemas)
• 
  
  Caja negra (sistemas)
• 
  
  Pruebas de aceptación
• 
  
  Pruebas de regresión
• 
  
  Pruebas de carga
• 
  
  Pruebas de prestaciones
• 
  
  Pruebas de recorrido
• 
  
  Pruebas de mutación

anterior texto ha sido extraido de

http://robertoyudice.com

DISEÑO DE DATOS

El diseño de datos transforma el modelo de campo de información,

creado durante el análisis, en las estructuras de datos que se van a

requerir para implementar el software.

El diseño de datos es la primera de las tres actividades de diseño realizadas

durante la ingeniería del software. El impacto de la estructura de datos sobre la

estructura de programa y la complejidad procedimental, hace que el diseño de

datos tenga una gran influencia en la calidad del software.

Los conceptos de ocultamiento de información y de abstracción de datos

conforman la base de los métodos de diseño de datos.

Según Wasserman “La actividad principal durante la fase de diseño de datos es”

la selección de las representaciones lógicas de las estructuras de datos,

identificados durante las fases de definición y especificación de requerimientos.

Una actividad importante durante el diseño es la de identificar los módulos de

programa que deben operar directamente sobre las estructuras de datos. De

esta forma, puede restringirse el ámbito del efecto de las decisiones concretas

de diseño de datos.

Los datos bien diseñados conducen a:

􀂃 Mejor estructura de programa

􀂃 Modularidad efectiva

􀂃 Complejidad procedimental reducida

 •Algunas recomendaciones para el diseño de datos son:

•Definir todas las posibles operaciones a realizar sobre los datos.

•Se deben refinar las estructuras de datos hasta tener representaciones de bajo nivel. 

•Se deben desarrollar bibliotecas útiles para la manipulación de datos.

•El lenguaje de implementación debe soportar tipos de datos abstractos.

•Se debe tener cuidado a la hora de diseñar diccionarios de datos, para que no se tengan “basureros de datos” en lugar de almacenes de datos.

 este articulo fue extraido de la siguiente pagina:     http   //indalog.ual.es/

DISEÑO DE INTERFAZ

El diseño de interfaz de usuario o ingeniería de la interfaz es el diseño de computadoras, aplicaciones, máquinas, dispositivos de comunicación móvil, aplicaciones de software, y sitios web enfocado en la experiencia de usuario y la interacción.

Normalmente es una actividad multidisciplinar que involucra a varias ramas del diseño y el conocimiento como el diseño gráfico, industrial, web, de software y la ergonomía; y está implicado en un amplio rango de proyectos, desde sistemas para computadoras, vehículos hasta aviones comerciales.

Su objetivo es que las aplicaciones o los objetos sean más atractivos y además, hacer que la interacción con el usuario sea lo más intuitiva posible, conocido como el diseño centrado en el usuario. En este sentido las disciplinas del diseño industrial y gráfico se encargan de que la actividad a desarrollar se comunique y aprenda lo más rápidamente, a través de recursos como la gráfica, los pictogramas, los estereotipos y la simbología, todo sin afectar el funcionamiento técnico eficiente.

Esta es la parte visual del programa y la que más aprecia el usuario final.

El usuario final quiere algo agradable, amigable, fácil de usar, completo pero sencillo, estándar y personalizable. Los programas deben tener un diseño homogéneo.

Se debe tener en cuenta el tamaño de las ventanas, de la fuente, los colores, los fondos, la usabilidad, la ergonomía, etc.

También hacer parte de la interfaz los reportes, los archivos de salida y en general cualquier exposición del programa a nuestros sentidos.

El ejemplo:  más simple es el de los botones de cerrar, maximizar etc. en una ventana. Debería ser sencillo el hacer click sobre ellos, para que sea fácil manejar las ventanas. Estos son los candidatos ideales para ser colocados en las esquinas. Pero hay muy pocos gestores de ventanas que hagan esto: la mayor parte de los temas para Metacity no lo hacen, XFCE4 tampoco. Solo es necesario mover los botones un pixel hacia arriba y a la derecha y el usuario podría cerrar la ventana sin siquiera tener que mirar.

Figura 4: Barra de desplazamiento
a un pixel del borde.

Otro ejemplo son las barras de desplazamiento. En la mayor parte de las aplicaciones de mi escritorio el borde derecho de la barra de desplazamiento se encuentra a un pixel del borde de la pantalla cuando la ventana está maximizada, haciendo que el tamaño del control decrezca de una zona sencilla de pulsar de tamaño virtualmente infinito a una pequeña zona de 10 pixels de ancho con la que se necesitan unos pocos segundos extras para hacer click cada vez que quiero desplazar el contenido de la ventana.
Para resumir este punto:

1. Los controles más utilizados deben ser más grandes y ser distinguibles fácilmente
2. Utiliza los bordes y esquinas de la pantalla para hacer que tus controles sean virtualmente infinitos
3. Nunca, nunca coloques los controles a un pixel de distancia del borde de la pantalla o de una esquina

elemento extraido de la siguiente pagina : .wwww.mundogeek.net