Access Pruebas Al Sistema

1.-El proceso de pruebas en el ciclo de vida

2.-El plan de pruebas

3.-Automatización de las pruebas

4.-Pruebas unitarias

5.-Pruebas de integración

6.-Pruebas de sistema

1.-LA IMPORTANCIA DE LAS PRUEBAS EN

EL CICLO DE VIDA

La fase de pruebas es una de las más costosas del ciclo de vida software. En

sentido estricto, deben realizarse pruebas de todos los artefactos generados durante

la construcción de un producto software, lo que incluye las especificaciones

de requisitos, casos de uso, diagramas de diversos tipos y, por supuesto, el

código fuente y el resto de elementos que forman parte de la aplicación (como

por ejemplo, la base de datos). Obviamente, se aplican diferentes técnicas de

prueba a cada tipo de producto software.

En este primer capítulo se enmarca el proceso de pruebas dentro del ciclo de

vida software, se describe brevemente una serie de buenas prácticas para el proceso

de pruebas, y se presentan algunos retos en cuanto a la automatización del

proceso.

1. El proceso de pruebas en el ciclo de vida

El estándar ISO/IEC 12207 [1] identifica tres grupos de procesos en el ciclo

de vida software:

- Procesos principales, grupo en el que incluye los procesos de Adquisición,

Suministro, Desarrollo, Operación y Mantenimiento.

- Procesos de la organización, en donde se encuentran los procesos de

Gestión, Mejora, Infraestructura y Formación.

- Procesos de soporte o auxiliares, en donde están los procesos de Documentación,

Gestión de la Configuración, Auditoría, Resolución de

Problemas, Revisión Conjunta, Aseguramiento de la Calidad, Verificación,

Validación,

No define, como vemos, un proceso de Pruebas como tal, sino que aconseja,

durante la ejecución de los procesos principales o de la organización, utilizar los

procesos de soporte. Entre éstos se encuentran los procesos de Validación y de

Verificación:

- El proceso de Validación tiene como objetivo determinar si los requisitos

y el sistema final cumplen los objetivos para los que se construyó el

producto, respondiendo así a la pregunta ¿el producto es correcto?

- El proceso de Verificación intenta determinar si los productos software

de una actividad se ajustan a los requisitos o a las condiciones impuestas

en actividades anteriores. De este modo, la pregunta a la que responde

este proceso es ¿se está construyendo el producto correctamente?

Del proceso de Verificación se observa la importancia de verificar cada uno

de los productos que se van construyendo, pues se asume que si lo que se va

construyendo es todo ello correcto, también lo será el producto final. Igualmente,

se observa que el proceso de Validación resalta la importancia de comprobar

el cumplimiento de los objetivos de los requisitos y del sistema final, de suerte

que podría construirse un Plan de pruebas de aceptación desde el momento

mismo de tener los requisitos, que sería comprobado al finalizar el proyecto. Si

tras la fase de requisitos viniese una segunda de diseño a alto nivel del sistema,

también podría prepararse un Plan de pruebas de integración, que sería comprobado

tras tener (o según se van teniendo) codificados los diferentes módulos

del sistema. Esta correspondencia entre fases del desarrollo y niveles de prueba

produce el llamado “modelo en V”, del que se muestra un ejemplo en la Figura 1.

En la figura se muestra cómo, efectivamente, mientras que en el desarrollo se va

de lo más general a lo más particular, en las pruebas se va de lo más particular a

lo más general: si lo primero que se hace es recolectar los requisitos con el usuario,

las últimas pruebas que se hacen son las de aceptación, con el mismo usuario;

si lo último que se construye es el código, lo primero que se hace son las

pruebas unitarias dedicho código.

2.-El plan de pruebas

El plan de pruebas es un documento que se utiliza para indicar los recursos,

los elementos que se van a probar, las actividades, el personal y los riesgos asociados.

El estándar IEEE 829 es el estándar para documentación de las pruebas,

e indica la siguiente estructura para el plan de pruebas:

1) Identificador del documento.

2) Introducción, resumen de los elementos y las características que se van a

probar.

3) Elementos que se van a probar (programas, módulos…)

4) Características que se van a probar.

5) Características que no se van a probar.

6) Enfoque general de la prueba.

7) Criterios de paso o fallo.

8) Criterios de suspensión y de reanudación.

9) Documentación asociada.

10)Actividades de preparación y ejecución de pruebas.

11) Entorno necesario.

12) Responsables.

Pruebas de sistemas de información

13

13) Necesidades de personal y de formación.

14) Esquema de tiempos.

15) Riesgos asumidos y planes de contingencia.

16) Aprobaciones, con las firmas de los responsables.

3.- Automatización de las pruebas

Diversos estudios recientes han destacado la falta de automatización de las

tareas relacionadas con las pruebas de software en la mayoría de las compañías

[3, 4]. De acuerdo con Meudec [5], hay tres líneas de automatización en este

contexto:

1) Tareas administrativas, como el registro de especificaciones o la

generación de informes.

2) Tareas mecánicas, como la ejecución y la monitorización, o las posibilidades

de captura y reejecución de casos.

3) Tareas de generación de casos de prueba. Respecto estas tareas,

[6] indican tres enfoques:

a. Generar casos de prueba a partir de código fuente para alcanzar

un nivel determinado de cobertura.

b. Dado el conocimiento del ingeniero de pruebas sobre el programa

y sobre su comportamiento esperado, generar automáticamente

entradas y comprobar las salidas.

c. Dada una especificación formal, generar automáticamente casos

de prueba para una implementación de esa especificación.

En los últimos años se han desarrollado una serie de herramientas ligadas al

Test DrivenDevelopment(Desarrollo Dirigido por las Pruebas) que han tenido

un éxito importante en el desarrollo de software. Estas herramientas, que se

agrupan habitualmente bajo la denominación X-Unit, automatizan parcialmente

las pruebas unitarias de código orientado a objetos, en los que habitualmente

se considera que la unidad de pruebas es la clase. En X-Unit, siendo K la clase

que se va a probar (abreviadamente CUT, de las siglas ClassUnder Test), se

construye una clase TestKque contiene métodos (que realmente constituyen

Pruebas de sistemas de información

14

casos de prueba) que ejercitan las diversas funcionalidades ofrecidas por K. Así,

cada caso de prueba suele consistir en la construcción de una instancia de la

CUT, en la ejecución de una serie de servicios sobre ésta y en la comprobación

del resultado (a lo que se le llama oráculo). La Tabla 2 muestra la clase Java TestAccount,

que prueba la clase de dominio Account(que representa una cuenta

bancaria) mediante tres casos de prueba, correspondientes los tres métodos

test1, test2 y test3.

• test1 construye una instancia de la CUT, ingresa 1000 euros en ella y,

...