Gaba en Montevideo

solo puedo elegir entre .net, genexus o java. wtf!

Tags: botica by gaba
No Comments »

Es el proceso de analiss y pruebas para asegurar que el programa que se esta desarrollando satisface su especificacion y entrega de la funcionalidad esperada por las personas que pagan por el software.

Validacion: Estamos construyendo el producto correcto?
Verificacion: Estamos construyendo el producto correctamente?

Dentro del proceso de V&V existen dos aproximaciones complementarias para el analisis y comprobacion de  los sistemas:

1. Inspecciones de Software : analizan y comprueban las representaciones del sistema tales como el documento de requerimientos, los diagramas de disenioo y el codigo fuente del programa. Tecnica statica de V&V.
2. Pruebas del Software: implica ejecutaar una implementacion del software con datos de prueba. Tecnica dinamica de V&V.

Tags: facultad, ingenieria de software by gaba
No Comments »

“las pruebas solo pueden demostrar la presencia de errores, no su ausencia”
Dijikstra

Objetivos

• Demostrar a l@s desarrollador@s y al cliente que el software satisface sus requerimientos.
• Descubrir defectos en el software en que el comportamiento de este es incorrecto, no deseable o no cumple su especificacion.

La mayoria de los tratamientos de pruebas comienzan con las pruebas de componentes y a continuacion se realizan las pruebas del sistema.

Pruebas del Sistema

Implican integrar dos o mas componentes que implementan funciones del sistema y a continuacion se prueba este sistema integrado. Existen dos fases:

1. Pruebas de integracion - se tiene acceso al codigo fuente y se intentan buscar defectos del sistema. cuando se encuentra uno se intenta solucionarlo.
2. Pruebas de entregas - se prueba el sistema como si fuera una caja  negra y como si fuera lo que se va a entregar al cliente.

Pruebas de integracion

• Integracion descendente: cuando se crea un esqueleto y se le va agregando los componentes.
• Integracion ascendente: se integran los componentes que proporcionan servicios comunes.

Pruebas de entregas o pruebas funcionales

Es el proceso de probar una entrega del sistema que sera distribuida a los clientes. Hay guias (Whittaker, 2002) que pueden incrementar la probabilidad que las pruebas de defectos tengan exito. Por ejemplo, elegir entradas que fuerzen a que el sistema genere todos los mensajes de error.

Pruebas de rendimiento o estress

Una vez que el sistema se ha integrado, se puede probar rendimiento y fiabilidad. Implica planificar una serie de pruebas en las que la carga se va incrementando regularmente hasta que el rendimiento del sistema se hace inaceptable.

Pruebas de Componentes o Pruebas de Unidad

Es el proceso de probar los componentes individuales en el sistema. El objetivo es encontrar defectos en los componentes. Usualmente l@s encargad@s de las pruebas de componentes son l@s desarrollador@s de las mismas.
Tipos de componentes a probar

1. Funciones individualles o metodos dentro de un objeto
2. Clases de objetos que tienen varios atributos y metodos
3. Componentes compuestos formados por diferentes objetos o funciones

Pruebas de Interfaces

Muchos componentes en un sistema no son simples funciones u ojbetos, sino que componentes compuestos formados por varios objetos que interactuan. Las pruebas sobre estos componentes se hacen a traves de sus interfaces definidas, probando que esta se comporta como fue especificado.

Diseno de Casos de Pruebas

El objetivo del proceso de disenio de casos de prueba (entradas y salidas esperadas) es crear un conjunto de casos de prueba que sean efectivos descuriendo defectos en los programas y muestren que el sistema satisface sus requerimientos.
Para diseniar un caso de prueba, se selecciona una caracteristica del sistema o componente que se esta probando. Se selecciona un conjunto de entradas qeu ejecutan dicha caracteriztica, documenta las salidas esperadas o rangos de salida.

Pruebas basadas en requerimientos

Los casos de prueba se disenian para probar los requerimientos del sistema. Las pruebas basadas en requerimientos son pruebas de validacion en lugar de pruebas de defectos.

Pruebas de particiones

Los datos de entrada y resultados de salida se pueden agrupar en varias clases diferetnes qeu tienen caracteristicas comunes, estas clases se denominan particiones de equivalencia o dominio. Se espera que el programa se comporte igual para todos los miembros de una clase. Se disenian los casos de pruebas para que se usen entradas de todas las particiones y se generen salidas de todas las particiones.

Pruebas estructurales o de caja blanca

Se crean casos de prueba para que se ejecute cada linea de codigo una vez.

Pruebas de Caminos

Son una estrategia de pruebas estructurales cuyo objetivo es probar cada camino de ejecucion independiente en un componente o programa.

Fuente: “Ingenieria de Software” de Ian Sommerville

Tags: facultad, ingenieria de software by gaba
No Comments »