Plan de Pruebas V 2

PLAN DE PRUEBAS DETALLADO SISTEMA DE NOTIFICACIN EN LNEA
PLATAFORMA DE INTEROPERABILIDAD, PDI INTRANET GUBERNAMENTAL Repblica de Colombia - Derechos Reservados
Bogot, D.C., Diciembre de 2008
FORMATO PRELIMINAR AL DOCUMENTO Ttulo: Fecha elaboracin aaaa-mm-dd: Sumario: PLAN DE PRUEBAS DETALLADO SISTEMA DE NOTIFICACIN EN LNEA 02 Diciembre 2.008 Este documento tiene por objeto establecer el contenido y criterios de aceptacin para el entregable PLAN DE PRUEBAS DETALLADO para el proyecto SISTEMA DE NOTIFICACIONES Y COMUNICACIONES ELECTRNICAS.
Palabras Claves: Formato: Dependencia: Cdigo: Categora: Autor (es): Revis: Equipo U.T e-Notificaciones Gerente de Proyecto U.T. eNotificaciones lvaro Rueda Zapata Gerente de Proyecto Programa Agenda de Conectividad Johanna Pimiento Quintero Gerente de Interventora Manuel Gomez Restrepo Gerente de Proyecto U.T. eNotificaciones lvaro Rueda Zapata DOC Lenguaje: Espaol
Ministerio de comunicaciones: programa Agenda de Conectividad Proyecto Sistema de Notificaciones y Comunicaciones Electrnicas Versin: 2.0 Estado: APROBADO
Firmas:
Aprob:
Informacin Adicional: Ubicacin:
Pgina 2 de 59
CONTROL DE CAMBIOS
VERSIN 1.0 FECHA 31/07/2008 No. SOLICITUD RESPONSABLE Equipo U.T. eNotificaciones Creacin de documento Inclusin de las siguientes modificaciones segn observaciones del Programa Agenda de Conectividad e Interventora. DESCRIPCIN

1.2 06/11/2008 Equipo U.T. eNotificaciones
Inclusin de resultados de la etapa de planificacin en el numeral 2.1.1.1. Fueron incluidas las pruebas de seguridad en el punto 2.3.8. Fueron incluidas la lista de Dummies a desarrollar para las pruebas de interoperabilidad en el punto 2.3.4. Fue incluida la tipificacin de pruebas en el punto 2.5 Fueron incluidas las caractersticas del ambiente de pruebas en el punto 3.2.1. Fueron incluidas las tcnicas de ejecucin de pruebas en el punto 2.6. Fue incluida la lista de chequeo para pruebas funcionales en el punto 5.2.1. Fueron descritas las pruebas y las herramientas a utilizar en los puntos 2.5, 2.6, 3.1, 3.2.1. Para cada herramienta de pruebas de identifico en qu tipo de pruebas ser utilizada en el punto 2.3. Inclusin del formato para el diseo de las pruebas tcnicas en el punto 5.2.3 Inclusin de matriz de trazabilidad de pruebas tcnicas versus requerimientos no funcionales en el punto 5.2.4.
1.1
29/10/2008
Equipo U.T. eNotificaciones
1.3 1.4
19/11/2008 01/12/2008
Equipo U.T. eNotificaciones Equipo U.T. eNotificaciones Equipo U.T. eNotificaciones
2.0
02/12/2008
Fueron eliminadas las pruebas del plan piloto por no ser parte de los trminos de referencia. Ajustes al documento de acuerdo a observaciones del Programa Agenda de Conectividad y la Interventora. Ajustes al documento de acuerdo a observaciones del Programa Agenda de Conectividad y la Interventora en reunin del 28/11/2008. Ajustes al documento de acuerdo a observaciones del Programa Agenda de Conectividad y la Interventora en reunin del 02/12/2008.
Pgina 3 de 59
TABLA DE CONTENIDO
DERECHOS DE AUTOR .................................................................................................................................................................................. 6 1. INTRODUCCIN..................................................................................................................................................................................... 7
1.1. 1.2. 1.3. 1.4. 1.5.

2.
PROPSITO ............................................................................................................................................................................... 7 ALCANCE ...................................................................................................................................................................................... 7 DEFINICIONES, ACRNIMOS Y ABREVIATURAS ................................................................................................ 10 REFERENCIAS ......................................................................................................................................................................... 10 VISTA GENERAL ..................................................................................................................................................................... 11
ESTRATEGIA DE PRUEBAS ............................................................................................................................................................. 13
2.1. TCNICAS DE ESPECIFICACIN DE LAS PRUEBAS ............................................................................................ 13 2.1.1. CICLO DE PRUEBAS ........................................................................................................................................................ 13 2.1.1.1. PLANIFICACIN .......................................................................................................................................................... 13 2.1.1.2. DISEO DE LAS PRUEBAS ...................................................................................................................................... 15 2.1.1.3. CONFIGURACIN ........................................................................................................................................................ 16 2.1.1.4. EJECUCIN ..................................................................................................................................................................... 17 2.1.1.5. EVALUACIN Y CIERRE ........................................................................................................................................... 19 2.1.1.6. SEGUIMIENTO Y CONTROL ................................................................................................................................... 19 2.2. HERRAMIENTAS PARA PRUEBAS ................................................................................................................................. 19 2.2.1. JUNIT ...................................................................................................................................................................................... 20 2.2.2. HTTPUNIT ............................................................................................................................................................................ 20 2.2.3. JMETER .................................................................................................................................................................................. 21 2.2.4. GRINDER .............................................................................................................................................................................. 21 2.2.5. NESSUS .................................................................................................................................................................................. 22 2.2.6. XMLBuddy ............................................................................................................................................................................ 22 2.3. TIPOS DE PRUEBAS ............................................................................................................................................................. 23 2.3.1. PRUEBAS UNITARIAS .................................................................................................................................................... 23 2.3.2. PRUEBAS DEL SISTEMA ............................................................................................................................................... 24 2.3.3. PRUEBAS DE INTEGRACIN ...................................................................................................................................... 25 2.3.4. PRUEBAS DE INTEROPERABILIDAD ..................................................................................................................... 25 2.3.5. PRUEBAS DE REGRESIN ........................................................................................................................................... 26 2.3.6. PRUEBAS FUNCIONALES ............................................................................................................................................. 27 2.3.7. PRUEBAS DE USABILIDAD.......................................................................................................................................... 28 2.3.8. PRUEBAS DE SEGURIDAD ........................................................................................................................................... 29 2.3.9. PRUEBAS DE CONFIGURACIN ............................................................................................................................... 29 2.3.10. PRUEBAS DE RECUPERACIN A FALLAS........................................................................................................ 30 2.3.11. PRUEBAS DE ACEPTACIN .................................................................................................................................... 31 2.4. ENTREGABLES DE PRUEBAS ........................................................................................................................................... 31 2.5. MATRIZ DE TIPIFICACIN DE PRUEBAS ................................................................................................................ 32 2.6. TECNICAS DE EJECUCIN DE PRUEBAS .................................................................................................................. 32
3. RECURSOS DEL PLAN DE PRUEBAS .......................................................................................................................................... 38
3.1. 3.2. 3.2.1. 3.3. 3.4. 3.4.1.
RECURSO HUMANO ............................................................................................................................................................. 38 RECURSO DEL SISTEMA .................................................................................................................................................... 38 CONFIGURACION DEL AMBIENTE DE PRUEBAS ............................................................................................ 39 HERRAMIENTAS DE REPORTES Y CONTROL DE INCIDENCIAS .................................................................. 40 ADMINISTRACIN DE VERSIONES ............................................................................................................................ 40 HERRAMIENTAS ............................................................................................................................................................... 41
Pgina 4 de 59

4. EVALUACIN DE PRUEBAS EJECUTADAS .............................................................................................................................. 43
4.1. 4.2. 4.3. 4.4.

5.
CRITERIOS DE INICIO DE EJECUCIN .................................................................................................................... 43 CRITERIOS DE EVALUACION ......................................................................................................................................... 43 CRITERIOS DE TERMINACIN ...................................................................................................................................... 47 CRITERIOS DE SUSPENSIN ......................................................................................................................................... 48 RELEASE NOTES .................................................................................................................................................................... 49 CASOS DE PRUEBAS ............................................................................................................................................................ 50 FORMATO CASOS DE PRUEBA FUNCIONALES ................................................................................................. 50 LISTA DE CHEQUEO CASOS DE PRUEBAS FUNCIONALES ......................................................................... 51 ENCUESTA PARA PRUEBAS DE USABILIDAD ................................................................................................... 52 FORMATO CASOS DE PRUEBA TECNICOS .......................................................................................................... 56 MATRIZ CASOS DE USO VS CASOS DE PRUEBA FUNCIONALES ............................................................. 57 MATRIZ REQUERIMIENTOS NO FUNCIONALES VS CASOS DE PRUEBA TCNICOS .................... 58 LISTA DE CHEQUEO ............................................................................................................................................................. 58 INFORME DE PRUEBAS...................................................................................................................................................... 59 PROCEDIMIENTO PARA INCIDENCIAS .................................................................................................................... 59
ANEXOS .................................................................................................................................................................................................... 49
5.1. 5.2. 5.2.1. 5.2.2. 5.2.3. 5.2.4. 5.2.5. 5.2.6. 5.3. 5.4. 5.5.
Pgina 5 de 59
DERECHOS DE AUTOR
A menos que se indique de forma contraria, el copyright del texto incluido en este documento es del gobierno de la Repblica de Colombia. Se puede reproducir gratuitamente en cualquier formato o medio sin requerir un permiso expreso para ello, bajo las siguientes condiciones: 1. El texto particular no se ha indicado como excluido y por lo tanto no puede ser copiado o distribuido. 2. La copia no se hace con el fin de distribuirla comercialmente. 3. Los materiales se deben reproducir exactamente y no se deben utilizar en un contexto engaoso. 4. Las copias sern acompaadas por las palabras "copiado/distribuido con permiso de la Repblica de Colombia. Todos los derechos reservados." 5. El ttulo del documento debe ser incluido al ser reproducido como parte de otra publicacin o servicio. Si se desea copiar o distribuir el documento con otros propsitos, debe solicitar el permiso entrando en contacto con el programa Agenda de Conectividad del Ministerio de Comunicaciones de la Repblica de Colombia.
Pgina 6 de 59
1. INTRODUCCIN
El contenido de este documento de plan de pruebas hace parte integral de la metodologia de pruebas que se encuentra en el capitulo 8 del documento general denominado Plan de Proyecto; el contenido de estos dos (2) documentos se encuentran fundamentados en estndares de calidad que no solo permiten el seguimiento y correcciones a tiempo del software sino que adems se encuentra definido por etapas, facilitando el seguimiento y control de los procesos del proyecto en desarrollo y proporcionando a la UNION TEMPORAL E-NOTIFICACIONES garantizar la operatividad y funcionalidad de la solucin desarrollada.
Acorde con el enfoque del desarrollo de la solucin, el plan de pruebas est basado en la metodologa de Rational Unified Process (RUP), lo que hace que este plan de pruebas tenga como propsito establecer las tcnicas, herramientas y actividades relacionadas con la ejecucin y validacin de cada una de las prueas, incluyendo responsabilidades de cada una de las actividades, los recursos y los prerequisitos que deben ser considerados en el esfuerzo de cada una de las pruebas; lo anterior permite garantizar el cumplimiento de los requerimientos planteados en el marco del desarrollo del proyecto denominado SISTEMA DE NOTIFICACIONES Y COMUNICACIONES ELECTRNICAS.
1.1.
PROPSITO
Este documento tiene como propsito establecer las tcnicas, herramientas y actividades relacionadas con la ejecucin y validacin del plan de pruebas; incluye responsabilidades de cada una de las tareas, los recursos y los prerequisitos que deben ser considerados en el esfuerzo de cada una de las pruebas, permitiendo garantizar el cumplimiento de los requerimientos planteados en el marco del desarrollo del proyecto denominado SISTEMA DE NOTIFICACIONES Y COMUNICACIONES ELECTRNICAS.
1.2.
ALCANCE
Este documento de PLAN DE PRUEBAS DETALLADO, se convierte en una gua para desarrollar de una forma organizada las diferentes actividades que se realizarn en el proceso del plan de pruebas en el desarrollo del proyecto denominado SISTEMA DE NOTIFICACIONES Y COMUNICACIONES ELECTRNICAS.
Pgina 7 de 59

La metodologia de pruebas y este documento de plan de pruebas permitirn al equipo profesionales expertos que participan en el frente de pruebas del proyecto denominado SISTEMA DE NOTIFICACIONES Y COMUNICACIONES ELECTRNICAS, evaluar aspectos como: la lgica estructural, la seguridad, la interconexin, el soporte conceptual, las herramientas de apoyo y sobretodo la independencia de aspectos tcnicos del desarrollo de la solucin tecnolgica contratada, tales como: la plataforma tecnolgica o la arquitectura de la solucin a probar, sin embargo a continuacin se describen las diferentes pruebas a ser aplicadas:
TIPO DE PRUEBA UNITARIAS INTEGRACIN
DEFINICIONES
FASE DE RUP ELABORACIN
Unitarias: Permite verificar la funcionalidad y estructura de cada componente individualmente del sistema una vez que ha sido codificado. Integracin: Permite verificar el correcto ensamblaje entre los distintos mdulos que componen el sistema desarrollado.
SISTEMA: Carga Volumen Estress Robustez Concurrencia, Interfaz de Usuario Recuperacin a Fallas Rendimiento Seguridad Integridad de las BD Interoperabilidad Desempeo Configuracin
Sistema: Estas pruebas buscan diferencias entre la solucin desarrollada y los requerimientos, con el fin de identificar errores que se puedan generar entre la especificacin funcional y el diseo del sistema. Carga: Valida aquellos volmenes de datos especificados en los requerimientos no Funcionales mximos
Volumen: Esta prueba somete el software a grandes cantidades de datos para determinar si se alcanzan lmites que causen la falla del software Estrs: Valida aquellos volmenes de datos mximos que resiste el sistema antes de comenzar con errores. Robustez: Valida si el sistema se mantiene estable y consistente despus de circunstancias adversas Concurrencia: Valida la capacidad del sistema de atender mltiples solicitudes departe de los usuarios que acceden a un mismo recurso. Interfaz de usuario: Ppermite verificar que la navegacin a travs de los elementos que se estn probando, reflejen las funciones del negocio y los requerimientos funcionales.
CONSTRUCCIN
Pgina 8 de 59

Recuperacin a fallas: Estas pruebas aseguran que el que el software pueda recuperarse a fallas de hardware, software o mal funcionamiento de la red sin prdida de datos o de integridad de los datos. Rendimiento: Permite validar si la aplicacin cumple los criterios de tiempos de respuesta establecidos. Seguridad: Verifica el cumplimiento de las polticas de seguridad acordadas para el sistema. Integridad de las bases de datos: Consiste en asegurar que los mtodos y procesos de acceso a la base de datos funcionan correctamente y sin corromper datos. Interoperabilidad: Esta prueba permite verificar todos los artefactos de la solucin desarrollada, su arquitectura base, los protocolos de la solucin, las interfaces y los mdulos del sistema, funcionando en forma conjunta. Desempeo: Este tipo de prueba es un aspecto fundamental en una aplicacin, ya que si sta no responde en el debido tiempo, se pueden perder clientes, o daar la imagen ante los usuarios.
Configuracin: Establece y mantiene la integridad de los productos de software a travs del ciclo de vida del proceso del mismo.
FUNCIONALES
Funcional: La prueba funcional es un proceso para procurar encontrar discrepancias entre el programa y la especificacin funcional.
Caja Negra: Estas pruebas permiten obtener conjuntos de condiciones de entrada que ejecutan todos los requisitos funcionales de un programa.
Ciclo de Negocio: Esta prueba tiene por objeto garantizar que el proceso de negocio esta adecuadamente soportado por el software desarrollado y que ste dispone de la funcionalidad adecuada para ejecutar todas las tareas incorporadas en el proceso de negocio. Usabilidad: Esta prueba permite encontrar problemas de factores humanos, o usabilidad.
Pgina 9 de 59
Instalacin: Esta prueba permite verificar la instalacin y desinstalacin de la aplicacin en diferentes entornos de hardware y software
TRANSICIN ACEPTACIN
Es la prueba final basada en las especificaciones del usuario o basada en el uso del programa por el usuario final luego de un periodo de tiempo
REGRESIN
En esta prueba se valida que el sistema mantenga su correcta funcionalidad debido a la incorporacin de un ajuste, correccin o nuevo requerimiento. Es una prueba funcional y tcnica que valida que el sistema siga funcionando perfectamente despus de que las correcciones sean aplicadas.
1.3.
DEFINICIONES, ACRNIMOS Y ABREVIATURAS
El plan de prueba: describe todos los mtodos que se utilizarn para verificar que el software satisface la especificacin del producto y las necesidades del cliente. Incluye los objetivos de calidad, necesidades de recursos, cronograma, asignaciones, mtodos, etc. Casos de prueba: lista los tems especficos que sern probados y describe los pasos detallados que sern seguidos para verificar el software. Reporte de pruebas: describen los problemas encontrados al ejecutar los casos de prueba. Herramientas de pruebas y automatizacin: documentacin de las herramientas empleadas en el proceso de pruebas. Mtricas, estadsticas y resmenes: indican como ha sido el progreso del proceso de prueba.
1.4.
REFERENCIAS
Algunos documentos del proyecto SISTEMA DE NOTIFICACIONES Y COMUNICACIONES, son base fundamental de este documento inicial de plan de pruebas, que a continuacin se relacionan Metodologa de Pruebas Punto 8 pagina 67 del Plan de Proyecto. Documento de Especificacin de Requerimientos. Documento de Arquitectura General Detallada Trminos de referencia del proceso de licitacin de la plataforma de interoperabilidad.
Pgina 10 de 59
1.5.
VISTA GENERAL
Descripcin resumida de contenido de cada una de las secciones que siguen, y explicacin de la forma en que est organizado el presente documento.
Estrategia de Pruebas: En este captulo se presenta una perspectiva general de la estrategia que se va a seguir para analizar, disear, implementar y ejecutar las pruebas del proyecto SISTEMA DE NOTIFICACIONES Y COMUNICACIONES ELECTRNICAS. As mismo se definir qu tipos de pruebas se van a realizar y cmo se ejecutarn. Recursos del Plan de Pruebas: Este captulo identifica los recursos humanos y no humanos (hardware, software, herramientas de soporte, configuracin de entorno de pruebas, entre otros), necesarios para desarrollar el proceso del plan de pruebas de la solucin del Sistema de Notificacin en Lnea. Evaluacin de Pruebas Ejecutadas: En este captulo se describe de los mtodos de evaluacin de las pruebas ejecutadas, de tal forma que permitir evaluar los grados de aceptacin de las pruebas.
Anexos:
Pgina 11 de 59
En este captulo se describen los documentos anexos que se utilizarn para la especificacin y la documentacin de la ejecucin de las pruebas.
Pgina 12 de 59
2. ESTRATEGIA DE PRUEBAS
2.1.
TCNICAS DE ESPECIFICACIN DE LAS PRUEBAS
La estrategia del proceso del plan de pruebas se implementar de acuerdo al esquema de macroactividades que se presenta en la siguiente grfica:
2.1.1.
CICLO DE PRUEBAS
El ciclo de pruebas comprende seis actividades las cuales debern ser desarrolladas de la siguiente manera: 2.1.1.1. PLANIFICACIN
Para el desarrollo de la solucin del Sistema de Notificacin en Lnea, se considera de gran importancia la ejecucin del plan de pruebas, hacindose necesario la planificacin de las mismas, lo que en consecuencia hace necesario tener claro los siguientes planteamientos:
Pgina 13 de 59

Se planifican pruebas personalizando los estndares especficamente para el proyecto de notificaciones. Se definen niveles de pruebas a aplicar. Se especifican las tcnicas a utilizar. Se establece el tiempo para la ejecucin de cada una de las pruebas. Uso de herramientas. Criterios de aceptacin. Recursos involucrados.
En la definicin del plan de pruebas, se valorar: El alcance de la aplicacin. La complejidad de sus procesos. Plataforma/s en las que se debe probar. Conocimientos y formacin de quienes ejecutarn las pruebas. Normativas legales aplicables. Otros recursos involucrados.
Se tendr en cuenta que: Las pruebas estarn presentes a lo largo de todo el ciclo de vida del desarrollo, de la solucin. Siempre hay errores. Probar exhaustivamente el software es imposible. No es recomendable que el programador pruebe sus propios programas. Se puede disponer de herramientas. Se debe considerar la importancia de actualizacin del plan de pruebas con el fin de reflejar los cambios que se produzcan en los requisitos y/o proceso de desarrollo del producto.
Resultado de la planificacin: Cronograma detallado de la ejecucin de las pruebas; donde se especifica qu prueba se realiza, cunto tiempo se estima para su ejecucin, recursos a utilizar (humanos y tecnolgicos); este cronograma se encuentra dentro del cronograma general del proyecto y especficamente en la fase desarrollo (ver plan de construccin) Formatos a utilizar para el diseo de las pruebas. Formatos a utilizar para el registro y anlisis de los resultados de las pruebas. Herramientas a utilizar para la gestin de incidencias. Procedimientos para el control de cambios. Herramientas a utilizar para la ejecucin de las pruebas.
Pgina 14 de 59

2.1.1.2. DISEO DE LAS PRUEBAS
Para el diseo de las pruebas, se tendrn en cuenta aspectos que permitirn encontrar defectos en el periodo de desarrollo del software, la realizacin de pruebas propias de verificacin y validacin de datos, segn se aclara en los siguientes tems: A. Alcance: El alcance de las pruebas estar dado por el marco del Sistema de Notificacin en Lnea, que se encuentra en desarrollo, sta compuesta (Informacin tomada de los trminos de referencia y del documento de Arquitectura General Detallada) por: Modelo Conceptual. Procesos. Descripcin de Procesos. Vista de Casos de Uso. Vista Lgica. Diseo de las clases y su organizacin en paquetes y subsistemas. Vista de Datos. Vista de Implementacin. Vista de Despliegue. Vista de Integracin con Sistemas Externos. Vista de Parametrizacin del Sistema. Requerimientos no Funcionales. Prototipos del sistema
B. Inventario de las Pruebas: En esta seccin se especifica el inventario de las pruebas, el cual permitir:
C
Definir y asignar prioridades como; alta, media o baja. Establecer un orden de trabajo. Decidir qu casos entraran en una regresin y cules no con mayor facilidad. Recortar alcance en forma rpida y ordenada. Se estima el tiempo en probar cada funcionalidad. Evaluar aspectos tcnicos del sistema.
C. Resultado de la ejecucin de las Pruebas: En este punto se resaltan las entradas fundamentales que son la partida para la ejecucin del plan de pruebas. Inventario de pruebas priorizado. Estimacin de esfuerzo de cada funcionalidad. Plan de desarrollo del producto. Plazos previstos para el proyecto.
Pgina 15 de 59
D. Ciclo de la Prueba: Las actividades de la prueba se realizarn para una determinada versin del producto, sobre la cual se ejecutan las pruebas y se reportan los incidentes encontrados. Para cada versin del producto se realizan alguna o todas las tareas asociadas a las pruebas.
El proceso de planificacin se ajusta al comenzar cada ciclo debido a posibles: 2.1.1.3. Atrasos de desarrollo Modificaciones en los requerimientos inciales Cambios en el alcance del producto Calidad del producto
CONFIGURACIN
Este captulo se enfoca a la definicin del proceso de administracin de la configuracin del proyecto SISTEMA DE NOTIFICACIONES Y COMUNICACIONES ELECTRNICAS, en el cual se establece el
Pgina 16 de 59

mantenimiento e integridad del software a travs del ciclo de vida del proyecto y se proveen contextos de trabajo estables para los posibles cambios antes de ser entregado formalmente en produccin. A continuacin se presenta una definicin de los conceptos bsicos de la disciplina de administracin de configuraciones, una descripcin de las actividades principales y una propuesta de formatos para facilitar la captura de la informacin necesaria en las distintas actividades. Administracin de Configuraciones: Es el proceso de identificar y definir los elementos o tems de configuracin del sistema, controlando la entrega y el cambio de estos elementos a travs del ciclo de vida del sistema, almacenando el estado de los mismos y de las solicitudes de cambio, y verificando la completitud con respecto a los requisitos especificados. Configuracin: Conjunto completo (respecto de la Arquitectura del Sistema, es decir que cada componente est representado) y coherente (respecto de que defina una versin estable del sistema, es decir que las versiones de cada componente se correspondan) de tems de Configuracin que constituyen un producto de software. Comit de control de cambios: Grupo con la autoridad para evaluar, aprobar y/o rechazar la implementacin de un cambio. El establecimiento de un Comit de control de cambios tiene como objetivo proveer un mecanismo para asegurar que toda solicitud de cambio es direccionada adecuadamente. tem de Configuracin: Componente de Software y/o producto de software destinado para ser puesto bajo Administracin de Configuraciones. Solicitud de Cambio: Documento a travs del cual el equipo tcnico autorizado solicita al Grupo de Desarrollo realizar la correccin de un defecto del Sistema de Notificacin en Lnea o de una mejora sobre la solucin antes de salir a produccin. Versin: Resultado de la evolucin que ha sufrido un Componente de Software en el tiempo. 2.1.1.4. EJECUCIN
En el siguiente grfico se muestra el modelo estndar de ejecucin de pruebas:
Pgina 17 de 59
Como se observa, representa un modelo de pruebas en V, a diferencia de los modelos clsicos, extiende las pruebas a lo largo de todo el ciclo de vida del software. Mientras se realizan las fases de requerimientos, anlisis, diseo e implementacin se van diseando las pruebas del mismo nivel. Al llegar a la etapa de pruebas se inicia la ejecucin de lo diseado desde las pruebas unitarias hasta las pruebas funcionales. Para cada una de las pruebas se realizar el siguiente procedimiento:
Pgina 18 de 59

Aqu se tendrn en cuenta las siguientes especificaciones: Elementos del sistema, es decir; los mdulos y caractersticas de la solucin que se van a probar. Se listarn las especificaciones de cada entrada requerida para ejecutar el caso; incluyendo la sincronizaciones entre cada una de estas. Especificaciones de todas las salidas y las caractersticas requeridas como el tiempo y la respuesta para los elementos que se van a probar. Estas especificaciones se harn utilizando los formatos establecidos en el numeral 5 de este plan de pruebas. Necesidades del entorno del proceso de ejecucin del hardware, software y recurso humano. Requisitos especiales de procedimiento o restricciones especiales en los procedimientos para ejecutar este caso. EVALUACIN Y CIERRE
2.1.1.5.
Para la evaluacin y cierre de las pruebas se presentar el informe de pruebas donde se documentar el resultado de cada una de las diferentes pruebas ejecutadas. El contenido de este informe estar compuesto de la manera descrita en la Propuesta de esquema y contenido del Inform de pruebas; esto ya que el informe de pruebas es un entregable independiente. 2.1.1.6. SEGUIMIENTO Y CONTROL
Para el seguimiento y control de las pruebas se llevarn a cabo comits tcnicos de seguimiento peridico semanal donde se evalen los siguientes temas.
Avance de las pruebas segn cronograma Estado o resultado de las pruebas ejecutadas Seguimiento a las incidencias reportadas segn la ejecucin de pruebas. Se presentar plan de contingencia para aquellas incidencias de mayor impacto que sean de riesgo para el proyecto.
2.2.
HERRAMIENTAS PARA PRUEBAS
En este captulo se sealaran las diferentes herramientas de software que se utilizarn para la ejecucin de las pruebas. Las herramientas que se utilizarn, dependern del tipo de prueba que se realizar, es decir que por cada tipo de prueba es posible que se utilice una herramienta diferente.
Pgina 19 de 59

2.2.1. JUNIT
Caractersticas
Tipo de prueba
JUnit es un conjunto de clases (framework) que permite realizar la Esta herramienta ser utilizada ejecucin de clases Java de manera controlada, para poder evaluar si para la ejecucin de: el funcionamiento de cada uno de los mtodos de la clase se comporta como se espera. Es decir, en funcin de algn valor de entrada se Pruebas unitarias. evala el valor de retorno esperado; si la clase cumple con la Pruebas de sistema especificacin, entonces JUnit devolver que el mtodo de la clase pas Pruebas de Integracin. exitosamente la prueba; en caso de que el valor esperado sea diferente al que regres el mtodo durante la ejecucin, JUnit devolver un fallo en el mtodo correspondiente JUnit es tambin un medio de controlar las pruebas de regresin, necesarias cuando una parte del cdigo ha sido modificado y se desea ver que el nuevo cdigo cumple con los requerimientos anteriores y que no se ha alterado su funcionalidad despus de la nueva modificacin. En la actualidad las herramientas de desarrollo como NetBeans y Eclipse cuentan con plug-ins que permiten que la generacin de las plantillas necesarias para la creacin de las pruebas de una clase Java se realice de manera automtica, facilitando al programador enfocarse en la prueba y el resultado esperado, y dejando a la herramienta la creacin de las clases que permiten coordinar las pruebas. La versin de la herramienta que se utilizar ser: release 4.5
2.2.2.
HTTPUNIT
Caractersticas
Tipo de prueba
Esta herramienta nos permite implementar unidades de test al estilo Esta herramienta ser utilizada JUnit, pero donde los mdulos a probar son pginas web (servlets, para la ejecucin de: pginas jsp, php, cgi's, etc.). HttpUnit nos permite simular el acceso a un portal web, hacer "click" en los links, consultar las cookies, ejecutar Pruebas Funcionales. Pruebas de Sistema cdigo Java Script, etc. Pruebas de Configuracin HttpUnit permite escribir test que simulen a un usuario accediendo a una aplicacin basada en Web mediante un navegador. Tiene muchas de las funciones de un navegador: control de cookies por sesiones, anlisis de contenido HTML, envo de formularios mediante los mtodos
Pgina 20 de 59

GET y POST, autentificacin, y otras caractersticas. Se puede chequear si hay cierto contenido en la pgina, enlace por enlace y formulario por formulario, lo que permite verificar que la aplicacin devuelve los resultados apropiados La versin de la herramienta que se utilizar ser: release 1.7
2.2.3.
JMETER
Caractersticas
Tipo de prueba
JMeter es una herramienta de carga para llevar acabo simulaciones Esta herramienta ser utilizada sobre cualquier recurso de Software. para la ejecucin de: Inicialmente diseada para pruebas de estrs en aplicaciones web, hoy en da, su arquitectura ha evolucionado no slo para llevar a cabo pruebas en componentes habilitados en Internet (HTTP), sino adems en Bases de Datos, programas en Perl, requisiciones FTP y prcticamente cualquier otro medio. Posee la capacidad de realizar desde una solicitud sencilla hasta secuencias de requisiciones que permiten diagnosticar el comportamiento de una aplicacin en condiciones de produccin. En este sentido, simula todas las funcionalidades de un Navegador ("Browser"), o de cualquier otro cliente, siendo capaz de manipular resultados en determinada requisicin y reutilizarlos para ser empleados en una nueva secuencia. La versin de la herramienta que se utilizar ser: release 1.9 2.2.4. GRINDER Pruebas de Sistema
Caractersticas
Tipo de prueba
Es un framework libre en Java, para realizar pruebas de carga o estrs Esta herramienta ser utilizada utilizando una consola grfica. para la ejecucin de: Esta versin hace uso del lenguaje script jhyton, lo que permite a cualquier cdigo Java ser encapsulado como una prueba. Esta herramienta permite utilizar un ambiente de red para realizar las Pruebas de Sistema
Pgina 21 de 59

pruebas de carga de forma totalmente distribuida. La versin de la herramienta que se utilizar ser: The Grinder 3 2.2.5. NESSUS
Caractersticas
Tipo de prueba
Nessus es un programa de escaneo de vulnerabilidades en Esta herramienta ser utilizada diversos sistemas operativos. Consiste en nessusd, el daemon Nessus, para la ejecucin de: que realiza el escaneo en el sistema objetivo, y nessus, el cliente (basado en consola o grfico) que muestra el avance y reporte de los Pruebas de Seguridad escaneos. Desde consola nessus puede ser programado para hacer escaneos programados con cron. En operacin normal, nessus comienza escaneando los puertos con nmap o con su propio escaneador de puertos para buscar puertos abiertos y despus intentar varios para atacarlo exploits. Las pruebas de vulnerabilidad, disponibles como una larga lista de plugins, son escritos en NASL (Nessus Attack Scripting Language, Lenguaje de Scripting de Ataque Nessus por sus siglas en ingls), un lenguaje scripting optimizado para interacciones personalizadas en redes. Opcionalmente, los resultados del escaneo pueden ser exportados en reportes en varios formatos, como texto plano, XML, HTML, y LaTeX. Los resultados tambin pueden ser guardados en una base de conocimiento para referencia en futuros escaneos de vulnerabilidades. Algunas de las pruebas de vulnerabilidades de Nessus pueden causar que los servicios o sistemas operativos se corrompan y caigan. El usuario puede evitar esto desactivando "unsafe test" (pruebas no seguras) antes de escanear.
2.2.6.
XMLBuddy
Caractersticas
Tipo de prueba
Este es un PlugIn para Eclipse (IDE que ser utilizado para el Esta herramienta ser utilizada desarrollo). Esta herramienta, entre otras funcionalidades, permite que para la ejecucin de: el desarrollador valide los archivos XML contra el archivo de esquemas Pruebas de Interoperabilidad XSD correspondiente. para los archivos XML que
Pgina 22 de 59

genere la aplicacin.
2.3.
TIPOS DE PRUEBAS
Las pruebas que se realizarn sern aquellas que fueron sealadas como tipos de pruebas en el numeral 8.3 de la metodologa de pruebas; en este captulo solo sern mencionados a manera general los tipos de pruebas.
El objetivo principal de la ejecucin de las pruebas esta dado a: Descubrir tantos errores como sea posible. Notificar acerca de los riesgos percibidos del proyecto Identificar falencias funcionales de la aplicacin, enmarcadas en grados de usabilidad ya definidos. Evaluar la calidad del producto y sealar un indicador de aceptacin del mismo. Evaluar la calidad tcnica del producto y resolver las falencias identificadas en las pruebas de tipo tcnico. Cumplir con los requerimientos especficos del cliente, en cuanto a la ejecucin de las pruebas.
2.3.1.
PRUEBAS UNITARIAS
Las pruebas unitarias tienen como objetivo verificar la funcionalidad y estructura de cada componente individualmente del sistema una vez que ha sido codificado. Es una Prueba tcnica que permitir: Verificar que los mdulos del sistema estn libres de errores. Que todos los caminos lgicos principales deben ejecutarse correctamente en cada mdulo de la aplicacin. Todas las transacciones deben ser probados. Todos los tipos de registro de entrada vlidos deben ser procesados Todos los tipos de registro de entrada invlidos deben ser procesados correctamente Cdigos de vuelta no nulos. Excepciones a tratamiento normal. Todas las salidas vlidas son procesadas. Rasgos de Control son probados y documentados.
Pgina 23 de 59

Objetivo de la Prueba: Estrategia: Validar las piezas individuales del software como una unidad independiente. Se efectan para los servicios del negocio y para la lgica de beans en capa Web que tengan complejidad alta. Generar casos de pruebas necesarios que permitan identificar: o Que al menos cada sentencia o instruccin del programa se ejecute al menos una vez correctamente. o Que cada condicin tenga por lo menos una vez un resultado positivo y/o negativo. o Que cada bucle del sistema se pueda probar considerando: ignorar el bucle, pasar una vez, pasar n veces. JUNIT La prueba se realizar por Mdulo entendindose por tal: Bloque bsico de programa Implementa funcin independiente y simple Puede probarse por separado.
Herramienta requeridas: Observaciones
2.3.2.
PRUEBAS DEL SISTEMA
Las pruebas de sistema buscan diferencias entre la solucin desarrollada y los requerimientos, enfocndose en la identificacin de los errores que se puedan generar entre la especificacin funcional y el diseo del sistema, as como, el negocio objeto de la aplicacin.
Objetivo de la Prueba:
Estrategia:
Herramienta requeridas: Observaciones:
Validar aquellos volmenes de datos mximos (por lo general las transacciones o informes) que pueden ser completados dentro de un perodo especfico en el tiempo, y con un nivel de concurrencia dado (carga, concurrencia y desempeo). Validar los requerimientos no funcionales de cada proyecto. Realizar Set de Pruebas a partir de los Requerimientos no funcionales. Realizar pruebas de rendimiento bsico. Consiste en probar la aplicacin simulando la carga esperada en el entorno de produccin. Realizar las pruebas de concurrencia: verificar el comportamiento de la aplicacin en condiciones de sobrecarga de usuarios, que supone permitir identificar potenciales problemas de rendimiento o cuellos de botella, antes de su pase a produccin. Realizar pruebas de requerimientos no funcionales: Consiste en probar la aplicacin con cada uno de los requerimientos no funcionales establecidos en el proyecto. Identificar posibles cuellos de botella o problemas de rendimiento. Realizar pruebas de carga: Altos volmenes de informacin. JUNIT HTTPUNIT JMETER o THE GRINDER 3
La eleccin de la herramienta de prueba ser a discrecin del grupo de
Pgina 24 de 59

pruebas y su eleccin depender de la prueba que se va a realizar, es decir puede que para pruebas de carga y altos volmenes se utilice THE GRINDER 3 pero para validacin de funcionalidad se utilice HTTPUNIT.
2.3.3.
PRUEBAS DE INTEGRACIN
El objetivo de las pruebas de integracin es verificar el correcto ensamblaje entre los distintos mdulos que componen la solucin una vez que han sido probados unitariamente con el fin de comprobar que interactan correctamente a travs de sus interfaces internas y externas, que cubren la funcionalidad establecida y se ajustan a los requisitos no funcionales especificados en las verificaciones correspondientes. En esta prueba se comprueba la compatibilidad y funcionalidad de los interfaces entre las distintas partes que componen el desarrollo de la solucin. Estas partes pueden ser mdulos, aplicaciones individuales, es decir esta prueba vlida la integracin entre los diferentes mdulos que componen la solucin con el fin de garantizar que su operacin integrada es correcta, teniendo en cuenta los siguientes temas tcnicos: El funcionamiento integrado de mdulos interdependientes debe estar libre de errores Probar todas las dependencias entre mdulos Probar el flujo de control y el flujo de datos a travs de todas las capas
Objetivo de la Prueba: Estrategia:
Validar la integracin entre los diferentes mdulos que componen la solucin con el fin de garantizar que su operacin integrada es correcta Pruebas de Integracin Incremental Ascendente Combinacin de mdulos de bajo nivel en grupos que realicen una misma funcin o subfuncin especifica, con el fin de reducir el nmero de pasos de integracin. Se escribe para cada mdulo un mdulo impulsor o conductor, con el fin de simular la llamada a los mdulos, introducir datos de pruebas y recoger resultados. Se prueba cada mdulo mediante su impulsor. Se eliminan los mdulos impulsores y se sustituyen por los mdulos de nivel superior en la jerarqua.
Herramienta requeridas: Observaciones:
JUNIT
2.3.4.
PRUEBAS DE INTEROPERABILIDAD
En esta prueba se valida que el sistema se comunique de manera exitosa con los sistemas externos con que se requiera, de acuerdo a los requerimientos no funcionales. Estos sistemas pueden ser sistemas propios de cada entidad, servicios de estampado de tiempo, servicios para la validacin de certificados
Pgina 25 de 59

digitales, servicios publicados en el tramitador transaccional, servicios de envo de SMS, servicios de envo de correo electrnico.
Objetivo de la Prueba: Estrategia: Validar la interoperabilidad de la solucin con sistemas externos. Prueba directa con los servicios que se encuentren disponibles en un ambiente de pruebas controlado suministrado por Agenda de conectividad. Para los servicios que no estn disponibles para prueba se desarrollarn sistemas DUMMIE que garanticen que la integracin funcionar. Para los archivos XML generados por la aplicacin se verificar que sean vlidos segn la definicin de los esquemas xsd definidos para cada uno. La verificacin de los archivos GEL- XML la realizar cada desarrollador, aprovechando las caractersticas de la herramienta utilizada para estas pruebas. La autenticacin de los sistemas externos se probar mediante un DUMMIE; el cual llevar el usuario y contrasea de autenticacin frente al sistema de notificaciones. Se probarn 3 escenarios uno con el usuario incorrecto, otro con la clave incorrecta y finalmente un escenario con el usuario y clave correctos. Las pruebas de conexin con el tramitador de gobierno en lnea se verificar mediante una prueba tcnica utilizando y siguiendo los pasos del Wizard de conexin java con el tramitador de gobierno en lnea; de esta prueba se espera que la conexin quede establecida. Se expondr un servidor de sFTP externo, con el cual se realizarn transferencias masivas de documentos histricos, se probaran tres escenarios: (Correcto, Incorrecto e incompleto).
Herramienta requeridas:
DUMMIES de los servicios que no estn construidos o no estn disponibles:
Autenticacin Firma Digital Estampado de Tiempo Sistema Emisor
XSD de cada archivo XML generado. XMLBuddy Observaciones:
2.3.5.
PRUEBAS DE REGRESIN
En esta prueba se valida que el sistema mantenga su correcta funcionalidad despus de la incorporacin de un ajuste, correccin o nuevo requerimiento. Es una prueba funcional y tcnica que valida que el sistema siga funcionando perfectamente despus de que las correcciones sean aplicadas.
Pgina 26 de 59
Objetivo de la Prueba: Estrategia:
Validar que el sistema siga funcionando perfectamente despus de que las acciones correctivas sean aplicadas. Repetir las pruebas (unitarias, de integracin, funcionales y de carga) que se hicieron antes de corregir defectos o de aadir nuevas funcionalidades, para comprobar que las modificaciones no provocan errores donde antes no los haba. Utilizar las mismas herramientas usadas para las pruebas segn sea el caso.
Herramienta requeridas:
Observaciones
Los responsables de las Pruebas de Regresin se establecen dependiendo del momento en el que se realicen las modificaciones.
2.3.6.
PRUEBAS FUNCIONALES
La prueba funcional es un proceso para procurar encontrar discrepancias entre el software desarrollado y la especificacin funcional. La prueba funcional normalmente es una actividad de caja negra. Esta prueba permite validar: Los procesos y reglas de negocio establecidas, Que se cumplan los requerimientos funcionales establecidos
En esta prueba se validan los Casos de Uso que fueron aprobados por el cliente, y a partir de ellos se disean y ejecutan los set de pruebas correspondientes. Se deben elaborar los casos de pruebas necesarios que permitan asegurar el funcionamiento de todos los flujos normales y alternos de dichos casos de uso.
Se asegura el trabajo apropiado de los requisitos funcionales, Incluyendo la navegacin, entrada de datos, procesamiento y obtencin de resultados. Validacin y ejecucin de Set de Pruebas y escenarios definidos, teniendo en cuenta flujo normal y flujos alternativos, usando datos validos e invlidos para verificar lo siguiente: o Los resultados esperados ocurren cuando se usan datos validos. o Se despliegan mensajes de error cuando se usan datos invlidos. o Cada regla de negocio es propiamente aplicada. o Realizar set de pruebas de los requerimientos mnimos para el adecuado funcionamiento de la aplicacin HTTPUNIT cuando aplique Formato de casos de prueba funcionales
Estrategia :
Herramientas Requeridas: Observaciones:
Para el reporte de incidencias se utilizar una herramienta para el registro
Pgina 27 de 59

y seguimiento.
2.3.7.
PRUEBAS DE USABILIDAD
Las pruebas de usabilidad son una forma de medir que tan bien puede una persona usar un objeto hecho por el hombre, como puede ser una pgina web, una interfaz de usuario, un documento o un dispositivo. Las pruebas de usabilidad consisten en seleccionar a un grupo de usuarios de una aplicacin y solicitarles que lleven a cabo las tareas para las cuales fue diseada, en tanto el equipo de diseo, desarrollo y otros involucrados toman nota de la interaccin, particularmente de los errores y dificultades con las que se encuentren los usuarios. No es necesario que se trate de una aplicacin completamente terminada, pudiendo tratarse de un prototipo
Validar el grado de usabilidad emprico del sistema. El grado de usabilidad se medir en tres aspectos clave:
o
o Estrategia :
Facilidad de aprendizaje: facilidad con la que nuevos usuarios desarrollan una interaccin efectiva con el sistema o producto. Flexibilidad: relativa a la variedad de posibilidades con las que el usuario y el sistema pueden intercambiar informacin. Robustez: es el nivel de apoyo al usuario que facilita el cumplimiento de sus objetivos.
Se usarn cuatro mtricas principales para medir la usabilidad del sistema o Exactitud: Nmero de errores cometidos por los sujetos de prueba y si estos fueron recuperables o no al usar los datos o procedimientos adecuados. Tiempo requerido para concluir la actividad. Recuerdo: Qu tanto recuerda el usuario despus de un periodo sin usar la aplicacin. Respuesta emocional: Cmo se siente el usuario al terminar la tarea (bajo tensin, satisfecho, molesto, etctera).
o o o
Estas mtricas ser implementadas para cada uno de los aspectos clave sealados en el objetivo de la prueba. La forma de evaluacin ser mediante el uso de encuestas; donde cada pregunta evaluar un aspecto clave de usabilidad y aportar valor a una o varias mtricas dentro del aspecto clave evaluado. Las encuestas se realizarn a los usuarios utilizando los prototipos del sistema; para as poder realizar cambios de forma temprana al diseo
Pgina 28 de 59

de la capa de presentacin. Herramientas Requeridas: Observaciones:
Encuesta Prototipos del sistema.
2.3.8.
PRUEBAS DE SEGURIDAD
Estas pruebas tienen dos enfoques: Pruebas de seguridad de la aplicacin; donde se verifica que un actor solo pueda acceder a las funciones y datos que su usuario tiene permitido. Pruebas de seguridad del sistema; donde se verificar que solo los actores con acceso al sistema y a la aplicacin estn habilitados para accederla.
Objetivo de la Prueba: Que los usuarios estn restringidos a funciones especficas o su acceso est limitado nicamente a los datos que est autorizado a acceder. Que solo aquellos usuarios autorizados a acceder al sistema son capaces de ejecutar las funciones del sistema. Que el cortafuego oculte apropiadamente la aplicacin. Que los puertos clave solo puedan ser accedidos de la forma establecida para su acceso. Que los puertos restringidos efectivamente no se encuentren accesibles. Identificar cada tipo de usuario y las funciones y datos a los que se debe autorizar. Crear pruebas para cada tipo de usuario y verificar cada permiso, creando transacciones especficas para cada tipo de usuario. Modificar tipos de usuarios y volver a ejecutar las pruebas. Nessus Pruebas funcionales de seguridad.
Estrategia : Herramientas Requeridas: Observaciones:
Para el reporte de incidencias se utilizar una herramienta para el registro y seguimiento.
2.3.9.
PRUEBAS DE CONFIGURACIN
El propsito de esta prueba es establecer y mantener la integridad de los productos de software a travs del ciclo de vida del proceso del mismo. Esta prueba implica la identificacin de la Configuracin del software en puntos dados en el tiempo, el control sistemtico de los cambios en la Configuracin y el mantenimiento de la integridad y trazabilidad de la Configuracin a travs del ciclo de vida del software.
Pgina 29 de 59
Objetivo de la Prueba: Estrategia :
Validar la integridad de los productos de software. Validacin y ejecucin de Set de Pruebas que representen un ciclo del proceso de negocio principal de principio a fin. Validacin de la integridad de la configuracin de todos los sistemas involucrados en puntos datos en el tiempo. Realizar trazabilidad de los cambios de configuracin realizados para puesta a punto. HTTPUNIT
Herramientas Requeridas:
Observaciones:
2.3.10.
PRUEBAS DE RECUPERACIN A FALLAS
Estas pruebas aseguran que el software pueda recuperarse a fallas de hardware, software o mal funcionamiento de la red sin prdida de datos o de integridad de los datos. El objetivo de esta prueba es verificar que los procesos de recuperacin (manual o automticos) se realice apropiadamente: las base de datos, las aplicaciones y el sistema a un estado conocido y deseado. En la prueba se incluyen los siguientes tipos de condiciones: Interrupcin de energa al cliente Interrupcin de energa al servidor Interrupcin de comunicaciones mediante los servidores de la red Interrupcin de comunicacin o prdida de energa de los discos del servidor o con los controladores Ciclos incompletos (procesos de filtro de datos interrumpidos, procesos de sincronizacin de datos interrumpidos)
Estrategia :
Validar la capacidad de recuperacin a fallas de: o Hardware o Software o Mal funcionamiento de Red. Interrumpir la energa del cliente: apagar el PC. Interrumpir la energa del servidor: simular o iniciar el proceso de apagado del servidor. Interrupcin por medio de los servidores de red: simular o iniciar la prdida de comunicacin con la red (desconectar fsicamente la comunicacin o apagar el servidor de red o router Interrumpir la comunicacin o quitar la energa de los discos del servidor o sus controladores: simular o
Pgina 30 de 59

eliminar fsicamente la comunicacin con uno o ms controladores de disco o los discos.] Una vez que se lograron o simularon estas condiciones, se deben invocar los procedimientos de recuperacin. Ninguna
Herramientas Requeridas:
Observaciones:
2.3.11.
PRUEBAS DE ACEPTACIN
El objetivo de las pruebas de aceptacin es validar que la solucin desarrollada cumpla con el funcionamiento esperado y permitir al usuario de dicho sistema determine su aceptacin, desde el punto de vista de su funcionalidad y de su rendimiento. Estas pruebas son realizadas por el cliente, donde comprueba que el sistema cumple con lo definido y se obtiene la conformidad del cliente. Esta prueba se realiza mediante el proceso de validacin de caja negra.
Estas pruebas corresponden a la ejecucin de las siguientes pruebas por parte de los usuarios funcionales o cliente: Pruebas Funcionales. Pruebas de Usabilidad. Pruebas de Configuracin
2.4.
ENTREGABLES DE PRUEBAS
De acuerdo al tipo de pruebas ejecutadas puede que el entregable del mismo sea diferente, en el siguiente cuadro se sealan los diferentes entregables por tipo de prueba. TIPO DE PRUEBAS
Pruebas Unitarias Pruebas de Sistema
ENTREGABLES
Resumen de validacin de la prueba. Se entregar un documento de resultados de las pruebas realizadas, que incluya resultados de la ejecucin de los scripts de pruebas y anlisis de los errores o defectos encontrados durante el proceso de realizacin de las pruebas. Se entregar un documento de pruebas de integracin que incluye resultados de la ejecucin de los scripts de pruebas y anlisis de los defectos encontrados durante el proceso de pruebas Se entregar un documento de pruebas de interoperabilidad que
Pgina 31 de 59
Pruebas de Integracin
Pruebas de Interoperabilidad

incluye resultados de la comunicacin con los servicios y DUMMIES previstos. Pruebas de Regresin Se entregar un documento de pruebas de regresin, que incluye resultados de la ejecucin de los scripts de pruebas, anlisis de los defectos encontrados durante el proceso de pruebas y solicitud de las correcciones recibidas. Se entregar un documento de pruebas de regresin, que incluye resultados de la ejecucin de los scripts de pruebas y anlisis de los defectos encontrados durante el proceso de pruebas y solicitud de las correcciones recibidas. Indicadores de Usabilidad Informe de vulnerabilidades Resultado de pruebas funcionales de seguridad. Resumen de validacin de la prueba. Resumen de validacin de la prueba. Resumen de validacin de la prueba.
Pruebas Funcionales
Pruebas de Usabilidad Pruebas de Seguridad Pruebas de Configuracin Pruebas de Recuperacin a Fallas Pruebas de Aceptacin
Los entregables de las pruebas sern elaborados de acuerdo a la estructura del entregable Informe de Pruebas solicitados en los trminos de referencia para la fase de desarrollo y pruebas. 2.5. MATRIZ DE TIPIFICACIN DE PRUEBAS
TIPO DE PRUEBAS Pruebas Unitarias Pruebas de Sistema Pruebas de Integracin Pruebas de Interoperabilidad Pruebas de Regresin Pruebas Funcionales Pruebas de Usabilidad Pruebas de Seguridad Pruebas de Configuracin Pruebas de Recuperacin a Fallas Pruebas de Aceptacin
TIPO DE PRUEBA Automticas Automticas Automticas Automticas Automticas y Manuales Manuales Manuales Automticas y Manuales Automticas y Manuales Automticas y Manuales Manuales
2.6.
TECNICAS DE EJECUCIN DE PRUEBAS
TIPO DE PRUEBAS Pruebas Unitarias
TECNICA DE EJECUCIN El uso de JUnit normalmente involucra los siguientes pasos: a. Crear una subclase de junit.framework.TestCase. b. Opcionalmente sobrescribir el mtodo setUp() que ser invocado en la inicializacin de objetos y variables
HERRAMIENTAS A UTILIZAR JUNIT
Pgina 32 de 59

HERRAMIENTAS A UTILIZAR
TIPO DE PRUEBAS
TECNICA DE EJECUCIN usados por todos los casos de prueba. No todos los casos de uso necesitan esto. Note que setUp() es invocado antes de cada caso particular. c. Opcionalmente sobrescribir el mtodo tearDown(). Mtodo que ser invocado al final de cada caso de prueba y que nos sirve para liberar recursos usados en la prueba o incluso para volver atrs lo probado, por ejemplo cuando el caso de prueba involucre la actualizacin de datos en una base de datos relacional. d. Adicionar mtodos de prueba a la clase. Note que no necesitamos implementar ninguna interface, pues JUnit usa el paquete reflection del java para detectar automticamente mtodos test. Dichos mtodos son reconocidos por su asignatura, la cual debe tener la forma public void test<Descripcion>(), adems pueden lanzar cualquier exception.
Pruebas de Sistema
Las pruebas del sistema tal como estn concebidas para el proyecto de notificaciones electrnicas involucra los siguientes pasos: a. Seleccin de los casos de uso para los que se probar Carga, volumen, estrs, concurrencia. Estos casos de uso correspondern al 10% del total de casos de uso y su eleccin contar con la aprobacin del Programa Agenda de Conectividad e Interventora. b. Ejecucin de las pruebas de Carga, volumen, estrs, concurrencia mediante la herramienta seleccionada. c. Recopilacin de resultados. d. Reporte de los defectos encontrados segn las pruebas. (A travs de la herramienta de gestin de incidencias) e. Asignacin de la incidencia. (A travs de la herramienta de gestin de incidencias). f. Correccin de la incidencia. g. Repeticin de la prueba.
JMETER
Pruebas Integracin
de
Las pruebas del integracin tal como estn concebidas para el proyecto de notificaciones electrnicas involucra los siguientes pasos: a. Seleccin de los componentes y/o servicios para los que se probar integracin con los componentes y/o servicios que tienen relacin directa. Estos componentes y/o servicios correspondern al 10% del
GRINDER
Pgina 33 de 59

TIPO DE PRUEBAS
TECNICA DE EJECUCIN total de componentes y/o servicios y su eleccin contar con la aprobacin del Programa Agenda de Conectividad e Interventora. Ejecucin de las pruebas de integracin mediante la herramienta seleccionada. Recopilacin de resultados. Reporte de los defectos encontrados segn las pruebas. (A travs de la herramienta de gestin de incidencias) Asignacin de la incidencia. (A travs de la herramienta de gestin de incidencias). Correccin de la incidencia. Repeticin de la prueba.
b. c. d. e. f. g. Pruebas Interoperabilidad de
Las pruebas de interoperabilidad tal como estn concebidas para el proyecto de notificaciones electrnicas involucra los siguientes pasos: a. b. c. d. Definicin de la lista de servicios a probar. Definicin de DUMMIES a construir. Construccin de DUMMIES. Ejecucin de la prueba de interoperabilidad contra los servicios y DUMMIES definidos. e. Recopilacin de resultados. f. Reporte de los defectos encontrados segn las pruebas. (A travs de la herramienta de gestin de incidencias) g. Asignacin de la incidencia. (A travs de la herramienta de gestin de incidencias) h. Correccin de la incidencia. i. Repeticin de la prueba.
Servicios Enrutador transaccional DUMMIES XMLBuddy
del
Pruebas de Regresin
Las pruebas de regresin tal como estn concebidas para el proyecto de notificaciones electrnicas involucra los siguientes pasos: a. Repeticin de las pruebas funcionales y de sistema que estn involucradas en los cambios realizados al sistema. b. Recopilacin de resultados. c. Reporte de los defectos encontrados segn las pruebas. (A travs de la herramienta de gestin de incidencias) d. Asignacin de la incidencia. (A travs de la herramienta de gestin de incidencias) e. Correccin de la incidencia.
Casos de Prueba Grinder
Pgina 34 de 59

HERRAMIENTAS A UTILIZAR Casos de Prueba
TIPO DE PRUEBAS Pruebas Funcionales
TECNICA DE EJECUCIN f. Repeticin de la prueba. Las pruebas funcionales normalmente involucra los siguientes pasos: a. Crear los casos de prueba mediante el formato establecido para ellos. b. Ejecucin de los casos de prueba con forme las funcionalidades van siendo liberadas para pruebas. c. Reporte de los defectos encontrados segn las pruebas. (A travs de la herramienta de gestin de incidencias) d. Asignacin de la incidencia. (A travs de la herramienta de gestin de incidencias) e. Correccin de la incidencia. f. Repeticin de la prueba.
Pruebas de Usabilidad
Las pruebas de usabilidad tal como estn concebidas para el proyecto de notificaciones electrnicas (uso de prototipado) involucra los siguientes pasos: a. Elaboracin de prototipos. b. Elaboracin de encuestas de usabilidad. c. Evaluacin de prototipos mediante la aplicacin de encuestas de usabilidad a usuarios comunes. d. Recopilacin de datos de la encuesta. e. Compilacin y anlisis de resultados de encuestas de usabilidad.
Prototipos Encuesta usabilidad
de
Pruebas de Seguridad
Las pruebas de seguridad tal como estn concebidas para el proyecto de notificaciones electrnicas involucra los siguientes pasos: a. Elaboracin de casos de prueba funcionales de seguridad. b. Elaboracin de casos de prueba automticos de seguridad. c. Configuracin de ambiente de pruebas. d. Ejecucin de pruebas funcionales de seguridad. e. Ejecucin de casos automticos de pruebas de seguridad con el uso de las herramientas de evaluacin y ataque. f. Recopilacin de resultados. g. Reporte de los defectos encontrados segn las pruebas. (A travs de la herramienta de gestin de incidencias) h. Asignacin de la incidencia. (A travs de la herramienta
NESSUS Casos de prueba funcionales de seguridad.
Pgina 35 de 59

TIPO DE PRUEBAS i. j. Pruebas Configuracin de
TECNICA DE EJECUCIN de gestin de incidencias) Correccin de la incidencia. Repeticin de la prueba.
Dada la metodologa RUP, al ser un desarrollo iterativo e incremental se efectuaran pruebas de instalacin a medida que sean liberadas las diferentes versiones del aplicativo. Las pruebas incluiran: a. Elaboracin de listas de chequeo de instalacin de sistema operativo, base de datos, servidor de aplicaciones y cualquier otro componente del sistema. b. Ejecucin de la instalacin segn la lista de chequeo. c. Recopilacin de resultados. d. Reporte de los defectos encontrados segn las pruebas. (A travs de la herramienta de gestin de incidencias) e. Asignacin de la incidencia. (A travs de la herramienta de gestin de incidencias) f. Correccin de la incidencia. g. Repeticin de la prueba.
Listas de chequeo para instalacin.
Pruebas de Recuperacin a Fallas
Las pruebas de recuperacin a fallas normalmente involucra los siguientes pasos: a. Crear los casos de prueba de recuperacin. b. Ejecucin de los casos de prueba. c. Reporte de los defectos encontrados segn las pruebas. (A travs de la herramienta de gestin de incidencias) d. Asignacin de la incidencia. (A travs de la herramienta de gestin de incidencias) e. Correccin de la incidencia. f. Repeticin de la prueba.
Pruebas Aceptacin
de
Las pruebas de recuperacin a fallas normalmente involucra los siguientes pasos: a. Ejecucin de una muestra de las pruebas funcionales, de carga, de configuracin por parte del Programa Agenda de Conectividad e Interventora. b. Reporte de los defectos encontrados segn las pruebas. (A travs de la herramienta de gestin de incidencias) c. Asignacin de la incidencia. (A travs de la herramienta de gestin de incidencias)
Grinder. Casos de prueba Funcionales. Listas de Chequeo.
Pgina 36 de 59

TIPO DE PRUEBAS
TECNICA DE EJECUCIN d. Correccin de la incidencia. e. Repeticin de la prueba.
Pgina 37 de 59
3. RECURSOS DEL PLAN DE PRUEBAS
3.1.
RECURSO HUMANO
El recurso humano que debe estar disponible para la ejecucin de las pruebas vara de acuerdo al tipo de prueba. En el siguiente cuadro se especifica el tipo de perfil necesario por tipo de prueba. Los perfiles mencionados no necesariamente corresponden a los enunciados en la metodologa de pruebas, ya que all se mencionan perfiles de apoyo al proceso de pruebas y aqu solo se mencionarn los perfiles que van a ejecutar las pruebas o que intervienen directamente en la prueba.
TIPO DE PRUEBAS Pruebas Unitarias Pruebas de Sistema Pruebas de Integracin Pruebas de Interoperabilidad Pruebas de Regresin Pruebas Funcionales Pruebas de Usabilidad Pruebas de Seguridad
PERFIL DEL RECURSO HUMANO Ingeniero Desarrollador. Analista de Pruebas. Ingeniero Desarrollador. Analista de Pruebas. Ingeniero Desarrollador. Analista de Pruebas Ingeniero Desarrollador. Analista de Pruebas Ingeniero Desarrollador. Analista de Pruebas Analista de Pruebas Analista de Pruebas Usuario Funcional. Ingeniero Desarrollador. Analista de Pruebas Arquitecto de Desarrollo. Arquitecto de Desarrollo. Ingeniero Desarrollador. Analista de Pruebas Analista de Pruebas. Usuario Funcional.
Pruebas de Configuracin Pruebas de Recuperacin a Fallas Pruebas de Aceptacin
3.2.
RECURSO DEL SISTEMA
Las pruebas se realizaran en un ambiente controlado y administrado por la UT; a continuacin se describen las caractersticas de la infraestructura del ambiente de pruebas.
Pgina 38 de 59
DESCRIPCION Servidor Estaciones de Trabajo Software: Instalado configurado y
FUNCIONALIDAD Montar ambiente de Pruebas con la solucin en proceso de desarrollo Con acceso al Servidor de Pruebas a travs de la red LAN de la UT. Herramientas Bugzilla, con acceso al equipo tcnico del proyecto y del frente de pruebas JUNIT, HTTPUNIT, JMETER o THE GRINDER 3. Repositorio central: Acceso a todo el equipo tcnico y frente de pruebas.
CANTIDAD 4 4 1 1 1
Herramientas de pruebas de sistemas Share Point
3.2.1.
CONFIGURACION DEL AMBIENTE DE PRUEBAS
El ambiente de pruebas estar implementado en las instalaciones de la UT y su configuracin deber ser la siguiente.
COMPONENTE Servidor 1 CONFIGURACIN Procesador: Quad Core Xeon E5405 Porcessor2x6MB Cache, 2,0GHz, 1333MHz FSB, PE2950 Memoria: 4GB 667MHz (4x1GB) Daul Ranked Fully Buffered DIMMs Tarjeta de Video: LOM NICs are TOE Ready Disco Duro: 2 dd c/u 300GB, 10K RPM SerialAttach SCSI 3Gbps 3,5 in HotPlug HardDrive Regulador de disco duro: PREC6i SAS RAID Controller, 2x4 Connectors, Int, PCIe, 246MB cache, x6 Bkpl Red: 2 Integradas NetXtreme II 5708 Gigabit NICs TOE Capable Procesador: Quad Core Xeon E5405 Porcessor2x6MB Cache, 2,0GHz, 1333MHz FSB, PE2950 Memoria: 4GB 667MHz (4x1GB) Daul Ranked Fully Buffered DIMMs Tarjeta de Video: LOM NICs are TOE Ready Disco Duro: 2 dd c/u 300GB, 10K RPM SerialAttach SCSI 3Gbps 3,5 in HotPlug HardDrive Regulador de disco duro: PREC6i SAS RAID Controller, 2x4 Connectors, Int, PCIe, 246MB cache, x6 Bkpl Red: 2 Integradas NetXtreme II 5708 Gigabit NICs TOE Capable Procesador: Quad Core Xeon E53102x4MB Cache, 1,0GHz, 1066MHz FSB, SOFTWARE INSTALADO Y CONFIGURADO CANTIDAD 1
Red Hat Enterprise Linux 4,5ES1 64 Jboss.
Servidor 2
Suse 6 de 64 Oracle 10DB
Servidor 3
Red Hat Enterprise Linux 4,5ES1 64
Pgina 39 de 59

Memoria: 2GB 667MHz (2x1GB) Daul Ranked Fully Buffered DIMMs Tarjeta de Video: LOM NICs are TOE Ready Disco Duro: 146GB, 10K RPM Serial-Attach SCSI 3Gbps 3,5 in HotPlug HardDrive Red: 2 Integradas NetXtreme II 5708 Gigabit NICs TOE Capable Procesador: Quad Core Xeon E53102x4MB Cache, 1,0GHz, 1066MHz FSB, Memoria: 2GB 667MHz (2x1GB) Daul Ranked Fully Buffered DIMMs Tarjeta de Video: LOM NICs are TOE Ready Disco Duro: 146GB, 10K RPM Serial-Attach SCSI 3Gbps 3,5 in HotPlug HardDrive Red: 2 Integradas NetXtreme II 5708 Gigabit NICs TOE Capable Equipos con mnimo: Procesador Intel Pentium V Memoria RAM: 512 MB RED: Acceso a la red local (Para los equipos dentro del rea de trabajo de la UT), Acceso a Internet (Para los equipos fuera del rea de trabajo de la UT). Publicacin de los servidores de pruebas a travs de una IP fija. Pentium IV 3,5GH, 3 GB de RAM, 80GB DD, DVD RW, Fuente redundante
Alero Apache
Servidor 4
Red Hat Enterprise Linux 4,5ES1 64 bugzilla,
Estaciones de Trabajo
Sistema Operativo: Windows XP Internet Explorer 6.0, Mozilla 2.0, Office 2003.
FireWall
Microsoft Windows 2003 spk 2 Microsoft ISA Server 2004 Spk2
3.3.
HERRAMIENTAS DE REPORTES Y CONTROL DE INCIDENCIAS
La herramienta que se utilizar para la realizacin del reporte, seguimiento y control de errores o Bug (Bug Tracking System) es BUGZILLA. Bugzilla permite organizar en mltiples formas los defectos de software, permitiendo el seguimiento de mltiples productos con diferentes versiones, a su vez compuestos de mltiples componentes. Permite adems categorizar los defectos de software de acuerdo a su prioridad y severidad, as como asignarles versiones para su solucin. Esta herramienta ser el apoyo para la metodologa de seguimiento y control de incidencias, acordada en el punto 9 del plan de proyecto.
3.4.
ADMINISTRACIN DE VERSIONES
La administracin de versiones que se probarn ser el mecanismo ideal, para controlar los release de pruebas y los cambios que estos sufrirn en la etapa de correccin de incidencias reportadas.
Pgina 40 de 59
De acuerdo a lo anterior la administracin de versiones contempla las siguientes etapas: 1. Entrega de la Versin para Pruebas (Release) o La versin debe venir con el Release Note. o Lista de Chequeo (si aplica) 2. Creacin de Incidencias en la herramienta. o Se debe especificar a que Release pertenecen las incidencias. 3. Anlisis y Desarrollo de Incidencias. o Se realiza la clasificacin de las incidencias. o Se empieza el desarrollo de las correcciones. o Se integran los desarrollos en el release correspondiente 4. Pruebas de Correcciones de Incidencias segn el release. 5. Aprobacin del Release.
Cabe anotar que los puntos 2,3 y 4 hacen parte de nuestra METODOLOGA DE SEGUIMIENTO Y CONTROL DE INCIDENCIAS, para mayor referencia, consultar el documento Plan de Proyecto Numeral 9.
3.4.1.
HERRAMIENTAS
SUBVERSION SUBVERSION es un software de sistema de control de versiones, Una caracterstica importante de Subversion es que, a diferencia de CVS, los archivos versionados no tienen cada uno un nmero de revisin independiente. En cambio, todo el repositorio tiene un nico nmero de versin que identifica un estado comn de todos los archivos del repositorio en cierto punto del tiempo Ventajas Se sigue la historia de los archivos y directorios a travs de copias y renombrados. Las modificaciones (incluyendo cambios a varios archivos) son atmicas. La creacin de ramas y etiquetas es una operacin ms eficiente. Se envan slo las diferencias en ambas direcciones Puede ser publicado mediante Apache, sobre WebDAV/DeltaV. Esto permite que clientes WebDAV utilicen Subversion en forma transparente. Maneja eficientemente archivos binarios. Permite selectivamente el bloqueo de archivos. Se usa en archivos binarios que, al no poder fusionarse fcilmente, conviene que no sean editados por ms de una persona a la vez.
Pgina 41 de 59

Cuando se usa integrado a Apache permite utilizar todas las opciones que este servidor provee a la hora de autentificar archivos (SQL, LDAP, PAM, etc.).
MAVEN MAVEN una herramienta software para la gestin de proyectos Java, La versin 2 usa un fichero de configuracin en XML llamado pom.xml. Su funcionalidad es parecida a Apache Ant de manera que permite compilar, ejecutar test o realizar distribuciones pero con la diferencia que trata de forma automtica las dependencias del proyecto. Una de las ms importantes caractersticas es su actualizacin en lnea mediante servidores repositorios. Maven es capaz de descargar nuevas actualizaciones de las bibliotecas de las que depende el proyecto y de igual manera subir una nueva distribucin a un repositorio de versiones, dejndola al acceso de todos los usuarios.
Pgina 42 de 59
4. EVALUACIN DE PRUEBAS EJECUTADAS

Este captulo mostrar los criterios de ejecucin, evaluacin, terminacin y suspensin de las pruebas.
4.1.
CRITERIOS DE INICIO DE EJECUCIN
A continuacin se sealan las condiciones mnimas que se deben presentar para iniciar la ejecucin de las pruebas: Se poseen los set de pruebas aprobados con escenarios claros. El entorno de pruebas es el adecuado para el tipo de pruebas a iniciar. Todos los artefactos requeridos se encuentran disponibles. Se recibi la Versin del Software para pruebas con su correspondiente Release Note y Lista de Chequeo cuando esta aplique. Todos los recursos humanos y tcnicos necesarios se encuentran disponibles.
4.2.
CRITERIOS DE EVALUACION
Los criterios de evaluacin estarn dados de forma independiente para cada tipo de pruebas; el siguiente cuadro muestra los criterios de evaluacin generales de las pruebas ejecutadas.
TIPO DE PRUEBAS
Pruebas Unitarias Pruebas de Sistema
CRITERIOS DE EVALUACION
Detectar errores en la ejecucin de las pruebas. El 90% de las pruebas realizadas deben ser exitosas. Detectar errores en la ejecucin de las pruebas Que los reportes generados por las herramientas de automatizacin de las pruebas contengan las mnimas variables que permitan un anlisis acertado de cada una de las pruebas realizadas. Tener en cuenta todos los escenarios posibles. El 90% de las pruebas realizadas deben ser exitosas. La totalidad de los puntos de control probadas debe ser mayor al 75% del total de los componentes que integran la solucin. Detectar errores en la ejecucin de las pruebas El 90% de las pruebas realizadas deben ser exitosas. Detectar errores en la ejecucin de las pruebas El 90% de las pruebas realizadas deben ser exitosas contra los servicios del tramitador. El 90% de las pruebas realizadas deben ser exitosas contra los
Pruebas de Integracin Pruebas de Interoperabilidad
Pgina 43 de 59

servicios DUMMIES. Pruebas de Regresin Pruebas Funcionales Pruebas de Usabilidad Para realizar esta prueba se debe tomar como base los criterios de aceptacin de las pruebas que se volvern a realizar. El resultado de cada caso de prueba debe ser igual al resultado de salida esperado. Encontrar fallas al ejecutar los diferentes casos de pruebas. La aplicacin cumple con los requerimientos funcionales especificados en la fase de anlisis La aplicacin cumple con los requerimientos mnimos para el funcionamiento El resultado de cada caso de prueba debe ser igual al resultado de salida esperado. Se deben incluir los datos de entrada vlidos y esperados como no validos e inesperados Encontrar los errores al ejecutar los diferentes casos de pruebas. La aplicacin debe cumplir con los requerimientos funcionales especificados en la fase de anlisis. La aplicacin debe cumplir con los requerimientos mnimos para el funcionamiento. El resultado de cada caso de prueba debe ser igual al resultado de salida esperado. La aplicacin debe cumplir con los requerimientos mnimos de seguridad. Considerar todos los escenarios posibles. Qu el sistema funcione bien en el ambiente de pruebas. Considerar todos los escenarios posibles Qu el sistema funcione de acuerdo a lo esperado despus de las pruebas. Para realizar esta prueba se debe tomar como base los criterios de aceptacin de las pruebas que se volvern a realizar.
Pruebas de Seguridad Pruebas de Configuracin Pruebas de Recuperacin a Fallas
Pruebas de Aceptacin
Para cada una de las pruebas se tendr en cuenta: Pruebas Unitarias: Las pruebas unitarias se evalan por medio de la siguiente tabla o lista de chequeo.
Elemento a Revisar
Se realizaron las Pruebas Unitarias con alguna herramienta especializada? Con las pruebas realizadas, cul fue el porcentaje de cobertura del sistema? Existe constancia de la realizacin de las pruebas mencionadas? El funcionamiento de la prueba unitaria respeta el diseo establecido? Existe un manejo de errores adecuado? Se cumpli con la estrategia de ejecucin de la prueba?
Pgina 44 de 59
SI
NO
No Aplica
Observaciones
Pruebas del Sistema: El resultado de las pruebas del sistema se ver reflejado en el siguiente informe:
Caso de Uso <Identificador del Caso de uso>
<Del total de pruebas ejecutadas, cuantas pruebas fueron exitosas> <Tiempo mximo que dur en ejecucin una Prueba> <Nmero de peticiones http exitosas> <Numero de errores ocurridos durante las pruebas> <Porcentaje de consumo de utilizacin de CPU durante la ejecucin de la prueba> <Promedio de bytes enviados>
Descripcin del escenario

Nmero de pruebas Fallidas Tiempo Promedio de ejecucin de las pruebas Nmero de Peticiones Fallidas Tipo de errores Cantidad de Memoria utilizada Promedio de bytes recibidos
<Nmero total de casos de prueba ejecutados de acuerdo al escenario>

<Del total de pruebas ejecutadas, cuantas pruebas fueron fallidas> <Tiempo promedio de ejecucin de las pruebas> <Nmero de peticiones http fallidas> <Descripcin del tipo de errores presentados> <Cantidad de MB de memoria utilizada en la prueba> <Promedio de bytes recibidos>
Nmero de pruebas exitosas Tiempo mximo de ejecucin de una prueba Nmero de peticiones exitosas Nmero de Errores % de Utilizacin del Procesador Promedio de bytes enviados
Pruebas de Integracin: El resultado de las pruebas de integracin se ver reflejado en el siguiente informe o lista de chequeo:
Elemento a Revisar
Se realizaron las pruebas de Integracin con alguna herramienta especializada? Cul fue el porcentaje de cobertura de la prueba con relacin al sistema total? Existe constancia de la ejecucin de las pruebas? Qu capas o componentes de la arquitectura se cubri con la ejecucin de las pruebas? Se estableci un criterio para la ejecucin de las pruebas? Cul? Se cumpli la estrategia de ejecucin de la prueba?
SI
NO
No Aplica
Observaciones
Pruebas de Interoperabilidad: El resultado de las pruebas de interoperabilidad se ver reflejado en el siguiente informe o lista de chequeo:
Elemento a Revisar SI NO No Aplica Observaciones
Se realizaron las pruebas de Interoperabilidad con alguna herramienta especializada?

Pgina 45 de 59

Cul fue el porcentaje de cobertura de la prueba con relacin al sistema total? Existe constancia de la ejecucin de las pruebas? Qu capas o componentes de la arquitectura se cubri con la ejecucin de las pruebas? Se estableci un criterio para la ejecucin de las pruebas? Cul? Se cumpli la estrategia de ejecucin de la prueba?
Pruebas de Regresin: El resultado de las pruebas de regresin se ver reflejado de acuerdo a los tipos de pruebas seleccionados. Pruebas Funcionales: El resultado de las pruebas funcionales se ver reflejado de acuerdo al formato de set de pruebas, ver anexos. Pruebas de interfaz de Usuario: El resultado de las pruebas de interfaz de usuario se ver reflejado en el siguiente informe o lista de chequeo
Se realizaron las pruebas de interfaz de usuario con alguna herramienta especializada? Cul fue el porcentaje de cobertura de la prueba con relacin al sistema total? Existe constancia de la ejecucin de las pruebas? Qu pginas se cubri con la prueba? Se estableci un criterio para la ejecucin de las pruebas? Cul? Se cumpli la estrategia de ejecucin de la prueba?
Pruebas de Seguridad: El resultado de las pruebas de seguridad se ver reflejado en el siguiente informe o lista de chequeo:
Elemento a Revisar
Se realizaron las pruebas de seguridad con alguna herramienta especializada? Cul fue el porcentaje de cobertura de la prueba con relacin al sistema total? Existe constancia de la ejecucin de las pruebas? Qu capas o componentes de la arquitectura se cubri con la ejecucin de las pruebas? Se estableci un criterio para la ejecucin de las pruebas? Cul? Se cumpli la estrategia de ejecucin de la prueba?
SI
NO
No Aplica
Observaciones
Pruebas de Configuracin: El resultado de las pruebas de configuracin se ver reflejado en el siguiente informe o lista de chequeo
Pgina 46 de 59

Elemento a Revisar
Se realizaron las pruebas de Configuracin con alguna herramienta especializada? Cul fue el porcentaje de cobertura de la prueba con relacin al sistema total? Existe constancia de la ejecucin de las pruebas? Qu pginas se cubri con la prueba? Se estableci un criterio para la ejecucin de las pruebas? Cul? Se cumpli la estrategia de ejecucin de la prueba?
SI
NO
No Aplica
Observaciones
Pruebas de Recuperacin a Fallas: El resultado de las pruebas de Recuperacin a Fallas se ver reflejado en el siguiente informe o lista de chequeo
Se realizaron las pruebas de recuperacin a fallas con alguna herramienta especializada? Cul fue el porcentaje de cobertura de la prueba con relacin al sistema total? Existe constancia de la ejecucin de las pruebas? Qu pginas se cubri con la prueba? Se estableci un criterio para la ejecucin de las pruebas? Cul? Se cumpli la estrategia de ejecucin de la prueba?
Pruebas de Aceptacin: El resultado de las pruebas de aceptacin se ver reflejado de acuerdo a los tipos de pruebas seleccionados.
4.3.
CRITERIOS DE TERMINACIN
A continuacin se sealan los criterios de terminacin de las pruebas a ejecutar. Se ejecutaron todas las pruebas del sistema. Todas las pruebas se ejecutaron de acuerdo a los criterios de evaluacin. Las pruebas de carga demuestran que se posee un grado satisfactorio de capacidad operativa y funcional. Los incidentes encontrados en las pruebas fueron corregidos y probados.
Pgina 47 de 59
4.4.
CRITERIOS DE SUSPENSIN
Los criterios de suspensin impiden la iniciacin y/o continuacin de las pruebas ante cualquier situacin de improvisto que hace que la ejecucin de las pruebas no logre grados satisfactorios de probabilidad de xito. Despus de la instalacin y configuracin del sistema, se evidencia problemas o situaciones anormales en cualquiera de sus componentes. Despus de la instalacin y configuracin del sistema, se evidencia que el ambiente de pruebas no es lo suficientemente estable para la ejecucin de las pruebas. Discrepancia entre la documentacin (Set de Pruebas, Casos de Uso) y el sistema.
Pgina 48 de 59
5. ANEXOS
A continuacin se listarn los anexos al plan de pruebas, que bsicamente corresponden a todos los documentos, formatos o plantillas que se utilizarn en la especificacin, ejecucin y documentacin de resultados de las pruebas. 5.1. RELEASE NOTES
A continuacin se presenta el formato que se utilizar como release notes, el cual deber acompaar cada una de las versiones entregadas para pruebas.
1. Presentacin a. Identificador del Release: <Numero de Release> b. Descripcin del producto: 2. Requerimientos de Hardware, Sistema Operativo y Software Base. Se deben especificar los requerimientos de Hardware, Sistema Operativo y Software Base que el ambiente de pruebas debe tener instalado y configurado antes de iniciar el proceso de instalacin del sistema.
COMPONENTE
HARDWARE SISTEMA OPERATIVO SOFTWARE BASE
REQUERIMIENTO
3. Requerimientos del Sistema. Aqu se incluyen los requerimientos de instalacin y configuracin del sistema. 4. Caractersticas Nuevas (opcional). Se describen las caractersticas nuevas que tiene el release entregado 5. Caractersticas Obsoletas (opcional). Se describen las caractersticas obsoletas con relacin a una versin anterior del release. 6. Caractersticas Eliminadas (opcional). Se describen las caractersticas eliminadas con relacin a una versin anterior del release.
Pgina 49 de 59
5.2. 5.2.1.
CASOS DE PRUEBAS FORMATO CASOS DE PRUEBA FUNCIONALES
A continuacin se presenta el formato que se utilizar como Set de Pruebas funcionales.

INFORMACIN GLOBAL DEL CASO DE PRUEBA <Numero del caso de prueba constituido por SP[numero del caso de uso]-[Numero del caso de prueba]> VERSIN DE EJECUCIN <Versin diligenciado por el analista de pruebas en el momento de ejecutarla. Este nmero se incrementa de 1 en 1> <Fecha de ejecucin diligenciado por el analista de pruebas> <Nombre del modulo al que corresponde el caso de uso objeto de la prueba>
CASO DE PRUEBA No.
FECHA EJECUCIN CASO DE USO: Descripcin del caso de prueba: 1. a. CASO DE PRUEBA Precondiciones <Identificacin del caso de uso objeto de la prueba> MODULO DEL SISTEMA
<Descripcin de lo que se pretende probar en el caso de prueba>
<Lista de precondiciones que deben cumplirse para realizar la prueba> b. Pasos de la prueba
<Pasos secuenciales que deben ser ejecutados por el analista de pruebas o usuario, ante el sistema para ejecutar la prueba>
DATOS DE ENTRADA CAMPO VALOR
<Descripcin del dato de <Valor que debe entrada> ser suministrado en la prueba para el dato de entrada>
RESPUESTA ESPERADA DE LA APLICACIN TIPO ESCENARIO <Tipo de <Respuesta que se espera de la escenario que aplicacin> pretende probarse: Correcto/Incorre cto>
COINCIDE RESPUESTA DEL SISTEMA SI NO
<Respuesta que se obtuvo de la aplicacin en el momento de la ejecucin de la prueba>
c.
Post condiciones
<Lista de poscondiciones que deben cumplirse despus de realizar la prueba>
2.
RESULTADOS DE LA PRUEBA Veredicto
Defectos y desviaciones
<Lista de defectos o desviaciones encontrados por el analista o usuario al ejecutar la prueba>

Pgina 50 de 59
Paso

Fall
Observaciones
Probador
<Observaciones generales del analista o usuario sobre la ejecucin de la prueba> Firma: Nombre: Fecha:
5.2.2.
LISTA DE CHEQUEO CASOS DE PRUEBAS FUNCIONALES
Con el fin de garantizar que los casos de prueba contemplen el 100% de los escenarios a probar para cada caso de uso; en su construccin deber tenerse en cuenta la siguiente lista de chequeo. Cada conjunto de casos de prueba para cada caso de uso deber contemplar: ELEMENTO DEL CASO DE USO Datos de entrada CASO DE PRUEBA Verificar que los datos de entrada cumplan con: Obligatoriedad Tipo de datos Longitud Estructura Validar reglas de negocio que afecten los datos de entrada (Dependencia de datos). Validar reglas de negocio que afecten los flujos. Verificar la ejecucin de todos los flujos alternos. Verificar la ejecucin de todos los flujos de Excepcin. Verificar la ejecucin del flujo bsico. Los casos de prueba deben especificar exactamente rutas, nombres de archivos, valores para los datos de entrada. Para asegurar que las rutas y nombres de archivos se cumplan; deber instalarse una rbol de carpetas predefinido en la estacin donde se
Reglas de Negocio
Flujos Alternos Flujos de Excepcin Flujo Bsico Generalidades:
Pgina 51 de 59

ejecutar la prueba. 5.2.3. ENCUESTA PARA PRUEBAS DE USABILIDAD
Las pruebas de usabilidad se guiaran por la siguiente estructura de encuesta:
PREGUNTA 1. Hay trminos mezclados? en idiomas
CRITERIOS DE EVALUACIN diferentes 1 = Se encuentran en todo el sistema 2 = Se encuentra en algunas partes del sistema. 3 = No se encuentran en ninguna parte del sistema. 1 = El vocabulario es demasiado tcnico. 2 = El vocabulario presenta algunas dificultades de comprensin.
2. Es simple el vocabulario utilizado?
3 = El vocabulario es completamente comprensible. 3. Se proporciona tiempo suficiente para realizar 1 = El tiempo es muy las entradas por teclado? limitado. 2 = El tiempo es limitado para algunas funcionalidades. 3 = El tiempo es completamente suficiente. 4. Hay algn tipo de asistencia para los usuarios 1 = No existe ninguna ayuda. que hacen uso del sistema por primera vez? 2 = Se encuentra ayuda en algunas partes. 3 = Existen ayudas en todo
Pgina 52 de 59

el sistema. 3. El sistema es fcil de operar para alguien que 1 = El sistema es de difcil no recibi capacitacin en su operacin? comprensin. 2 = El sistema es fcil de operar en algunas de sus funcionalidades. 3 = El sistema es completamente fcil de operar. 1 = No se entiende su interfaz. 2 = La interfaz se entiende en algunas partes. 3 = La interfaz es completamente entendible. 7. Resulta fcil identificar un objeto o una 1 = Es difcil identificar los accin? objetos o acciones. 2 = Se pueden identificar los objetos y acciones en algunas partes del sistema. 3 = Todos los objetos y acciones son fcilmente identificables. 8. Resulta fcil entender el resultado de una 1 = Los resultados de las accin? acciones no son entendibles. 2 = Los resultados de las acciones son entendibles en algunas partes o la mayor parte del sistema. 3 = Todos los resultados de las acciones son entendibles. 9. Est diseada la interfaz para facilitar la 1 = La interfaz es difcil de realizacin eficiente de las tareas de la mejor usar. forma posible?
6. Se entienden la interfaz y su contenido?
Pgina 53 de 59

2 = La interfaz es difcil de usar en algunas partes del sistema. 3 = La interfaz es completamente sencilla de usar. 10. Son apropiados los mensajes presentado por 1 = Los mensajes non son el sistema? apropiados. 2 = Los mensajes son apropiados en algunas partes del sistema. 3 = Todos los mensajes son apropiados y fciles de comprender. 1 = El sistema no previene errores del usuario. 2 = El sistema previene algunos o la mayora de los errores del usuario. 3 = El sistema previene cualquier error que pueda cometer el usuario. 12. El sistema informa claramente sobre los 1 = El sistema no informa de errores presentados? manera adecuada sobre los errores cometidos. 2 = El sistema informa de manera adecuada algunos o la mayora de los errores cometidos por el usuario. 3 = El sistema informa de forma adecuada todos los errores cometidos por el usuario. 1 = Los mensajes de texto no son descriptivos.
11. Acta el sistema en la prevencin de errores?
13. Se utiliza mensajes y textos descriptivos?
Pgina 54 de 59
2 = La mayora de los textos son descriptivos o fciles de interpretar 3 = Todos los textos son descriptivos o fciles de interpretar. 14. Permite una cmoda navegacin dentro del 1 = La navegacin no es producto y una fcil salida de ste? sencilla. 2 = La navegacin presenta algunas dificultades. 3 = La navegacin es sencilla, requiere de pocos vnculos para accedes a las funcionalidades del sistema. la 1 = La interfaz no es personalizable. 2 = La interfaz es personalizable con algunas restricciones. 3 = La interfaz es completamente personalizable. 16. Se proporciona informacin visual de dnde 1 = No se presenta ninguna est el usuario, qu est haciendo y qu puede informacin visual ni otro tipo hacer a continuacin? de ayuda. 2 = Presenta ayudas en algunas partes del sistema. 3 = Las ayudas son apropiadas y estn distribuidas a los largo del sistema. 1 = No existen atajos por teclado.
13. Se interfaz?
permite
al
usuario
personalizar
17. Existe atajos del teclado bien hechos?
Pgina 55 de 59

2 = Existen algunos atajos por teclado. 3 = Todas las opciones presentan atajos por teclado. 18. Se presenta al usuario la informacin que 1 = La informacin slo necesita? presentadas es ms de la que necesita y tiende a ser confusa. 2 = En algunas partes se presenta mayor informacin a la necesaria. 3 = La informacin es estrictamente la necesaria segn el perfil. 5.2.4. FORMATO CASOS DE PRUEBA TECNICOS
A continuacin se presenta el formato que se utilizar para documentar las pruebas tcnicas; estas pruebas sern documentadas conforme avance el desarrollo de la solucin y se tengan versiones liberadas sobre las que se aplicarn estas pruebas.
INFORMACIN GLOBAL DEL CASO DE PRUEBA Tipo de Prueba: Descripcin de la prueba:
<Descripcin del tipo de prueba: Carga, Volumen, Estrs, ETC>
Cdigo de la prueba
<Codificacin de la prueba>
<Descripcin del objetivo de la prueba>
Versin de Ejecucin 1.
<Versin o iteracin de ejecucin de la prueba>
Fecha de Ejecucin
<Fecha de ejecucin en formato AAAA/MM/DD diligenciado por el analista de pruebas al momento de su ejecucin>
Prerrequisitos de la prueba
<Lista de los prerrequisitos a tener en cuenta antes de ejecutar la prueba>
2.
Insumos de la prueba
<Lista de Insumos necesarios para ejecutar la prueba>
3.
Lista de chequeo de la prueba Pasos a Seguir Prueba satisfactoria

Pgina 56 de 59
Observaciones

SI
<Pasos numerados en orden lgico para la ejecucin de la prueba>
NO
4. Resultados de la prueba Defectos y desviaciones

<Lista de defectos o desviaciones encontrados por el analista o usuario al ejecutar la prueba>
Veredicto
Paso
Fall
Observaciones
<Observaciones generales del analista o usuario sobre la ejecucin de la prueba>
Probador
Firma: Nombre: Fecha:
5.2.5.
MATRIZ CASOS DE USO VS CASOS DE PRUEBA FUNCIONALES
A continuacin se presenta el formato de matriz de trazabilidad que se llevara para asegurar que sean probados todos los aspectos definidos dentro de los casos de uso.
Caso de Uso
Aspecto a Evaluar 1. Datos Entrada Obligatoriedad
Caso de Prueba <Identificacin del caso de prueba que evala Obligatoriedad> <Identificacin del caso de prueba que evala Longitud> <Identificacin del caso de prueba que evala Tipo de dato>
Longitud Tipo de Dato <Identificacin del caso de uso>
2. Reglas de Negocios Relacionadas con datos de entrada <Lista de casos de prueba> <Identificacin del caso prueba que evala la regla negocio> 3. Reglas de Negocios <Lista de casos de prueba> <Identificacin del caso prueba que evala la regla negocio>
Pgina 57 de 59
de de
de de

4. Flujos de Excepcin <Lista de flujos de excepcin>
<Identificacin del caso de prueba que evala los flujos de excepcin
5. Flujos Alternos <Lista de casos alternos> 6. Flujo Bsico
de
flujos <Identificacin del caso de prueba que evala los flujos alternos.> <Identificacin del caso de prueba que evala el flujos bsico.
5.2.6.
MATRIZ REQUERIMIENTOS NO FUNCIONALES VS CASOS DE PRUEBA TCNICOS
A continuacin se presenta el formato de matriz de trazabilidad que se llevara para asegurar que sean probados todos los aspectos tcnicos de la solucin; en esta matriz se registrar cada caso de prueba tcnico y requerimiento no funcional que ser verificado. Esta matriz ser diligenciada en la medida que las pruebas tcnicas sean diseadas.
CDIGO DE LA PRUEBA TCNICA REQUERIMIENTO NO FUNCIONAL VERIFICADO OBSERVACIONES
5.3.
LISTA DE CHEQUEO
A continuacin se presenta el formato que se utilizar para lista de chequeo de las pruebas ejecutadas
TIPO DE PRUEBA Versin de Ejecucin Fecha de Ejecucin EJECUTADA CUMPLE NO CUMPLE Observaciones
Pgina 58 de 59
5.4.
INFORME DE PRUEBAS
Ver el Esquema y Contenido del entregable informe de pruebas de la fase 4. 5.5. PROCEDIMIENTO PARA INCIDENCIAS
El procedimiento para el manejo de incidencias esta descrito en el plan de proyecto en el captulo 9. METODOLOGA DE SEGUIMIENTO Y CONTROL DE INCIDENCIAS.
Pgina 59 de 59

Plan de Pruebas V 2

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Plan de Pruebas V 2

Hochgeladen von

Copyright:

Verfügbare Formate

PLAN DE PRUEBAS DETALLADO SISTEMA DE NOTIFICACIN EN LNEA

PLATAFORMA DE INTEROPERABILIDAD, PDI INTRANET GUBERNAMENTAL Repblica de Colombia - Derechos Reservados

Bogot, D.C., Diciembre de 2008

PLAN DE PRUEBAS DETALLADO SISTEMA DE NOTIFICACIN EN LNEA

Informacin Adicional: Ubicacin:

PLAN DE PRUEBAS DETALLADO SISTEMA DE NOTIFICACIN EN LNEA

Equipo U.T. eNotificaciones

Equipo U.T. eNotificaciones Equipo U.T. eNotificaciones Equipo U.T. eNotificaciones

PLAN DE PRUEBAS DETALLADO SISTEMA DE NOTIFICACIN EN LNEA

1.1. 1.2. 1.3. 1.4. 1.5.

ESTRATEGIA DE PRUEBAS ............................................................................................................................................................. 13

3.1. 3.2. 3.2.1. 3.3. 3.4. 3.4.1.

PLAN DE PRUEBAS DETALLADO SISTEMA DE NOTIFICACIN EN LNEA

4.1. 4.2. 4.3. 4.4.

PLAN DE PRUEBAS DETALLADO SISTEMA DE NOTIFICACIN EN LNEA

PLAN DE PRUEBAS DETALLADO SISTEMA DE NOTIFICACIN EN LNEA

PLAN DE PRUEBAS DETALLADO SISTEMA DE NOTIFICACIN EN LNEA

TIPO DE PRUEBA UNITARIAS INTEGRACIN

FASE DE RUP ELABORACIN

PLAN DE PRUEBAS DETALLADO SISTEMA DE NOTIFICACIN EN LNEA

PLAN DE PRUEBAS DETALLADO SISTEMA DE NOTIFICACIN EN LNEA

DEFINICIONES, ACRNIMOS Y ABREVIATURAS

PLAN DE PRUEBAS DETALLADO SISTEMA DE NOTIFICACIN EN LNEA

PLAN DE PRUEBAS DETALLADO SISTEMA DE NOTIFICACIN EN LNEA

PLAN DE PRUEBAS DETALLADO SISTEMA DE NOTIFICACIN EN LNEA

TCNICAS DE ESPECIFICACIN DE LAS PRUEBAS

PLAN DE PRUEBAS DETALLADO SISTEMA DE NOTIFICACIN EN LNEA

PLAN DE PRUEBAS DETALLADO SISTEMA DE NOTIFICACIN EN LNEA

PLAN DE PRUEBAS DETALLADO SISTEMA DE NOTIFICACIN EN LNEA

PLAN DE PRUEBAS DETALLADO SISTEMA DE NOTIFICACIN EN LNEA

En el siguiente grfico se muestra el modelo estndar de ejecucin de pruebas:

PLAN DE PRUEBAS DETALLADO SISTEMA DE NOTIFICACIN EN LNEA

PLAN DE PRUEBAS DETALLADO SISTEMA DE NOTIFICACIN EN LNEA

HERRAMIENTAS PARA PRUEBAS

PLAN DE PRUEBAS DETALLADO SISTEMA DE NOTIFICACIN EN LNEA

PLAN DE PRUEBAS DETALLADO SISTEMA DE NOTIFICACIN EN LNEA

PLAN DE PRUEBAS DETALLADO SISTEMA DE NOTIFICACIN EN LNEA

PLAN DE PRUEBAS DETALLADO SISTEMA DE NOTIFICACIN EN LNEA

PLAN DE PRUEBAS DETALLADO SISTEMA DE NOTIFICACIN EN LNEA

Herramienta requeridas: Observaciones

PRUEBAS DEL SISTEMA

Herramienta requeridas: Observaciones:

La eleccin de la herramienta de prueba ser a discrecin del grupo de

PLAN DE PRUEBAS DETALLADO SISTEMA DE NOTIFICACIN EN LNEA

Objetivo de la Prueba: Estrategia:

Herramienta requeridas: Observaciones:

PLAN DE PRUEBAS DETALLADO SISTEMA DE NOTIFICACIN EN LNEA

DUMMIES de los servicios que no estn construidos o no estn disponibles:

Autenticacin Firma Digital Estampado de Tiempo Sistema Emisor

XSD de cada archivo XML generado. XMLBuddy Observaciones:

PLAN DE PRUEBAS DETALLADO SISTEMA DE NOTIFICACIN EN LNEA

Objetivo de la Prueba: Estrategia:

Herramientas Requeridas: Observaciones:

Para el reporte de incidencias se utilizar una herramienta para el registro

PLAN DE PRUEBAS DETALLADO SISTEMA DE NOTIFICACIN EN LNEA

PLAN DE PRUEBAS DETALLADO SISTEMA DE NOTIFICACIN EN LNEA

Encuesta Prototipos del sistema.

Estrategia : Herramientas Requeridas: Observaciones:

Para el reporte de incidencias se utilizar una herramienta para el registro y seguimiento.

PLAN DE PRUEBAS DETALLADO SISTEMA DE NOTIFICACIN EN LNEA

Objetivo de la Prueba: Estrategia :

Para el reporte de incidencias se utilizar una herramienta para el registro y seguimiento.

PRUEBAS DE RECUPERACIN A FALLAS