Access Pruebas Al Sistema
Enviado por Leovg • 31 de Mayo de 2013 • 2.082 Palabras (9 Páginas) • 447 Visitas
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
...