Diseo de Sistemas de Informacin 2

Ayudanta II
Alejandro Reyes Cooke
Mail: alejandro.reyes.cooke@gmail.com
Msn: zirks90@hotmail.com
http://zirks.ublog.cl

Bien se dice popularmente que en el arte de desarrollar software, el peor riesgo

es fracasar por no construir el producto correcto.

- Pruebas del Sistema.

- Pruebas de Componente (Unitarias).
- Diseo de casos de prueba.
- Prueba de Aceptacin.

El objetivo de esta etapa es descubrir defectos probando componentes de programas. Las dos
actividades fundamentales son las pruebas de componentes (probar partes del sistema) y la
prueba del sistema (probar el sistema por completo).

El proceso de pruebas tiene dos objetivos:

1- Demostrar al cliente y al desarrollador que el software satisface los requerimientos.

2- Para descubrir defectos en el software en que el comportamiento de ste es incorrecto,
no deseable o no cumple con su especificacin.

Por lo tanto, el primer objetivo se refiere a las pruebas de validacin. En las que se espera que el
sistema funcione correctamente usando un conjunto de casos de prueba que reflejan el uso
esperado. El segundo objetivo conduce a la prueba de defectos, en los que los casos de prueba se
disean para exponer los defectos.

El xito de una prueba de defectos es aquella que muestra que un defecto hace que el sistema
funciona incorrectamente, una prueba exitosa de validacin, es aquella en que el sistema funciona
correctamente.
Los diagramas de secuencia son utilizados para identificar entradas y salidas que tienen que
crearse para las pruebas.
Diseo de Casos de Prueba:

- Se selecciona una caracterstica del sistema o componente que se est probando.

- Se selecciona un conjunto de entradas que ejecutan dicha caracterstica.
- Documenta las salidas esperadas o rangos de salida.
- Si es posible, se disea una prueba automatizada que pruebe las salidas reales y esperadas
son las mismas.

Existen varias aproximaciones que pueden seguirse para disear casos de prueba:

1. Pruebas basadas en requerimientos: en donde los casos de prueba se disean para probar
requerimientos del sistema.
2. Pruebas de particiones: en donde se identifican particiones de entrada y salida y se
disean pruebas para que el sistema ejecute entradas de todas las particiones y genere
salidas en todas las particiones.
3. Pruebas Estructurales: en donde se utiliza el conocimiento de la estructura del programa
para disear pruebas que ejecuten todas las partes del programa.

Tipos de Prueba:

A: Por el Desarrollador:

1. Segn la Orientacin: Pruebas Funcionales, se utiliza como base los Manuales de usuario y
de Sistemas. Son las pruebas ms comunes. Pruebas de Desempeo, probar que los
tiempos de respuesta sean los especificados. Pruebas de Resistencia, probar que el
comportamiento del producto en situaciones de estrs o sobrecarga sea el especificado.
Pruebas de Rendimiento, probar el comportamiento del producto dentro del contexto de
un sistema integrado a su entorno, Pruebas de seguridad, etc.
2. Segn el Objetivo: Pruebas de Interfaces, probar que el producto se comunica
adecuadamente con el mundo que lo rodea, con otros softwares, con hardware, etc.
Pruebas de Operabilidad, probar que el producto es operable y que los procedimientos
de operacin estn bien definidos. Pruebas de Instalacin, probar que el producto es
instalable y/o transportable.
3. Segn el Punto de vista: Pruebas Positivas, probar la respuesta del producto ante una
entrada o un estimulo correcto. Pruebas Negativas, probar la respuesta del producto ante
una entrada o un estmulo incorrecto.
4. Segn el Ejecutor: Pruebas de Escritorio, corresponden a las pruebas unitarias. Pruebas
tipo Big-Bang, las realiza el cliente o usuario, sin ningn plan ni idea formalmente
concebida la mayora de las veces. Pruebas Formales, corresponden a las pruebas de
integracin de sistemas.
 5. Segn el Enfoque: Pruebas de Caja Blanca (Se conoce bien el sistema), Pruebas de caja
Negra (Orientado a requerimientos funcionales), Pruebas de Caja Gris.
6. Segn el Nivel: Pruebas unitarias, se realizan una vez finalizada la construccin o
programacin de cada componente. Pruebas de Integracin, se realizan en etapas de
integracin una vez que todos los componentes a integrar estn en control de
configuracin del proyecto. Pruebas de Sistema, participa el cliente como testigo.
7. Segn el Lugar: Pruebas Alfa (Se invita al usuario al lugar de desarrollo), Pruebas Beta
(Vienen despus de las Beta, y se desarrollan en el ambiente del cliente).

Qu sucedera, si les entregramos a nuestros usuarios un sistema que funciona correctamente

en nuestro escritorio, pero no en el del cliente?

B: Por el Cliente:

1. Las pruebas de aceptacin, son realizadas por el cliente o usuario del sistema. Es por ello
que solo se entrega