5

Click here to load reader

Practica de construccion

Embed Size (px)

Citation preview

Page 1: Practica de construccion
Page 2: Practica de construccion

La actividad de construcción abarca una serie de tareas de codificación y realización de pruebas que conducen al software operativo que está listo para entregarlo al cliente o usuario final. En el trabajo de la ingeniería del software moderna la codificación puede ser

Page 3: Practica de construccion
Page 4: Practica de construccion

En un libro clásico sobre las pruebas realizadas al software, Glen Myers [MYE79] establece una serie de reglas que bien pueden servir como objetivos de las pruebas:

Las pruebas consisten en un proceso en el que se ejecuta un programa con la intención de encontrar un error que aún no se descubre.

Un buen caso de prueba es aquel en el que hay una gran probabilidad de encontrar un error que aún no se descubre.

Una prueba exitosa es aquella que encuentra un error que aún no se descubría.

En un libro clásico sobre las pruebas realizadas al software, Glen Myers [MYE79] establece una serie de reglas que bien pueden servir como objetivos de las pruebas:

Page 5: Practica de construccion

Principio #1: Todas las pruebas deben ser rastreables hasta los requisitos del cliente. El objetivo de las pruebas realizadas al software es descubrir errores.

Principio #1: Todas las pruebas deben ser rastreables hasta los requisitos del cliente. El objetivo de las pruebas realizadas al software es descubrir errores.

Principio #2: Las pruebas se deben planear mucho antes de que comience el proceso de prueba. La planeación de las pruebas puede comenzar tan pronto como el modelo de análisis esté completo. La definición detallada de los casos de prueba puede comenzar en cuanto el modeló de diseño haya sido solidificado.

Principio #3: El principio de Pareto es aplicable para las pruebas de software. Para establecerlo de manera simple, el principio de Pareto implica que 80 por ciento de los errores descubiertos durante las pruebas con probabilidad serán rastreables hasta 20 por ciento de todos los programas.

Principio #4: Las pruebas deben comenzar "en lo pequeño" y progresar hacia "lo grande". Las primeras pruebas que se planean y ejecutan, por lo general, se enfocan en los componentes individuales.

Principio #5: Las pruebas exhaustivas no son posibles. El número de permutaciones entre las rutas, incluso de un programa con un tamaño moderado, es excepcionalmente grande. Por esta razón es imposible ejecutar cada combinación de rutas para las pruebas.