Anexo 13 Modelo Plan de Prueba

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:
02 Diciembre 2.008
Sumario:
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:
DOC
Dependencia:
Ministerio de comunicaciones: programa Agenda de Conectividad
Proyecto Sistema de Notificaciones y Comunicaciones

Electrnicas
Cdigo:
Lenguaje:
Versin:
2.0
Espaol
Estado:
Categora:
Autor (es):
Revis:
Aprob:
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
Informacin
Adicional:
Ubicacin:
Pgina 2 de
59
Firmas:
APROBADO

CONTROL DE CAMBIOS
VERSI
N
1.0
FECHA
31/07/2008
No.
SOLICITUD
RESPONSABLE
Equipo U.T. eNotificaciones
DESCRIPCIN
Creacin de documento
Inclusin de las siguientes modificaciones segn
observaciones del Programa Agenda de Conectividad e
Interventora.
1.1
1.2
29/10/2008
06/11/2008
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 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.3
19/11/2008
1.4
01/12/2008
2.0
02/12/2008
Pgina 3 de
Fueron incluidas las caractersticas del ambiente de

pruebas en el punto 3.2.1.
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.
Programa Agenda de Conectividad y la Interventora en
reunin del 28/11/2008.
Programa Agenda de Conectividad y la Interventora en
reunin del 02/12/2008.
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. RECURSO HUMANO....................................................................................................................................................... 38
3.2. RECURSO DEL SISTEMA............................................................................................................................................. 38
3.2.1. CONFIGURACION DEL AMBIENTE DE PRUEBAS...................................................................................39
3.3. HERRAMIENTAS DE REPORTES Y CONTROL DE INCIDENCIAS......................................................40
3.4. ADMINISTRACIN DE VERSIONES...................................................................................................................... 40
3.4.1. HERRAMIENTAS........................................................................................................................................................... 41
Pgina 4 de
59

4.
EVALUACIN DE PRUEBAS EJECUTADAS...................................................................................................................... 43

4.1.
4.2.
4.3.
4.4.
5.
CRITERIOS
CRITERIOS
CRITERIOS
CRITERIOS
DE
DE
DE
DE
INICIO DE EJECUCIN............................................................................................................... 43
EVALUACION.................................................................................................................................... 43
TERMINACIN................................................................................................................................. 47
SUSPENSIN................................................................................................................................... 48
ANEXOS................................................................................................................................................................................................. 49
5.1. RELEASE NOTES............................................................................................................................................................... 49
5.2. CASOS DE PRUEBAS..................................................................................................................................................... 50
5.2.1. FORMATO CASOS DE PRUEBA FUNCIONALES......................................................................................50
5.2.2. LISTA DE CHEQUEO CASOS DE PRUEBAS FUNCIONALES............................................................51
5.2.3. ENCUESTA PARA PRUEBAS DE USABILIDAD..........................................................................................52
5.2.4. FORMATO CASOS DE PRUEBA TECNICOS................................................................................................56
5.2.5. MATRIZ CASOS DE USO VS CASOS DE PRUEBA FUNCIONALES..............................................57
5.2.6. MATRIZ REQUERIMIENTOS NO FUNCIONALES VS CASOS DE PRUEBA TCNICOS....58
5.3. LISTA DE CHEQUEO....................................................................................................................................................... 58
5.4. INFORME DE PRUEBAS............................................................................................................................................... 59
5.5. PROCEDIMIENTO PARA INCIDENCIAS.............................................................................................................. 59
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 ENOTIFICACIONES 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
DEFINICIONES
FASE DE RUP
ELABORACIN
UNITARIAS
INTEGRACIN
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 mximos
especificados en los requerimientos no Funcionales
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.
Pgina 8 de
59
CONSTRUCCI
N

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

Pgina 9 de
59

de factores humanos, o usabilidad.
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.
Pgina 10 de
59

1.5.
Documento de Especificacin de Requerimientos.

Documento de Arquitectura General Detallada
Trminos de referencia del proceso de licitacin de la plataforma de interoperabilidad.
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.
Pgina 11 de
59

Anexos:
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

macro-actividades 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.
Pgina 14 de
59

Herramientas a utilizar para la ejecucin de las pruebas.
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:
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.
Pgina 15 de
59

Inventario de pruebas priorizado.

Estimacin de esfuerzo de cada funcionalidad.
Plan de desarrollo del producto.
Plazos previstos para el proyecto.
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:
Atrasos de desarrollo
Modificaciones en los requerimientos inciales
Cambios en el alcance del producto
Calidad del producto
Pgina 16 de
59

2.1.1.3. 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 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.
2.1.1.5. EVALUACIN Y CIERRE

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 ejecucin de clases Java de manera controlada,
para poder evaluar si 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 evala el valor de retorno
esperado; si la clase cumple con la especificacin, entonces
JUnit devolver que el mtodo de la clase pas 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
Esta
herramienta
ser
utilizada para la ejecucin
de:
Pruebas unitarias.
Pruebas de sistema
Pruebas de Integracin.
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 JUnit, pero donde los mdulos a probar son pginas web
(servlets, 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 cdigo Java Script, etc.
Esta
herramienta
ser
de:
Pruebas Funcionales.
Pruebas de Sistema
Pruebas
de
Pgina 20 de
59

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 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
2.2.3.
JMETER
Caractersticas
Tipo de prueba
JMeter es una herramienta de carga para llevar acabo

simulaciones sobre cualquier recurso de Software.
Esta
herramienta
ser
de:
Pruebas de Sistema
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.
2.2.4.
GRINDER
Caractersticas
Tipo de prueba
Es un framework libre en Java, para realizar pruebas de carga

o estrs utilizando una consola grfica.
Esta
herramienta
ser
de:
Pgina 21 de
59

Esta versin hace uso del lenguaje script jhyton, lo que

permite a cualquier cdigo Java ser encapsulado como una
prueba.
Pruebas de Sistema
Esta herramienta permite utilizar un ambiente de red para

realizar las 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
diversos sistemas
operativos.
Consiste
en nessusd, utilizada para la ejecucin
el daemon Nessus, que realiza el escaneo en el sistema de:
objetivo, y nessus, el cliente (basado en consola o grfico) que Pruebas de Seguridad
muestra el avance y reporte de los 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.
Pgina 22 de
59

2.2.6.
XMLBuddy
Caractersticas
Tipo de prueba
Este es un PlugIn para Eclipse (IDE que ser utilizado para el

desarrollo). Esta herramienta, entre otras funcionalidades,
permite que el desarrollador valide los archivos XML contra el
archivo de esquemas XSD correspondiente.
Esta
herramienta
ser
de:
Pruebas
de
Interoperabilidad para los
archivos XML que 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:
2.3.1.
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.
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.
Pgina 23 de
59

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.
Objetivo de la Prueba:
Estrategia:
Herramienta requeridas:
Observaciones
2.3.2.
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.
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.
Estrategia:
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
Pgina 24 de
59

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
Observaciones:
2.3.3.
La eleccin de la herramienta de prueba ser a discrecin del

grupo de 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.
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
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
Pgina 25 de
59

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.
JUNIT
Observaciones:
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 digitales, servicios publicados en el tramitador
transaccional, servicios de envo de SMS, servicios de envo de correo electrnico.
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,
Pgina 26 de
59

se probaran
incompleto).
tres
escenarios:
(Correcto,
Incorrecto
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.
Estrategia:
Observaciones
2.3.6.
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.
Los responsables de las Pruebas de Regresin se establecen
dependiendo del momento en el que se realicen las
modificaciones.
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
Pgina 27 de
59

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.
Estrategia :
Herramientas Requeridas:
Observaciones:
2.3.7.
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

Para el reporte de incidencias se utilizar una herramienta para
el registro y seguimiento.
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
Facilidad de aprendizaje: facilidad con la que nuevos

usuarios desarrollan una interaccin efectiva con el sistema
Pgina 28 de
59

o
Estrategia :
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.
o Tiempo requerido para concluir la actividad.
o Recuerdo: Qu tanto recuerda el usuario despus de
un periodo sin usar la aplicacin.
o Respuesta emocional: Cmo se siente el usuario al
terminar la tarea (bajo tensin, satisfecho, molesto,
etctera).
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 de la capa de presentacin.
Encuesta
Prototipos del sistema.
Observaciones:
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.
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.
Pgina 29 de
59

Estrategia :
Observaciones:
2.3.9.
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.

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.
Estrategia :
Observaciones:
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

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.
Pgina 30 de
59

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 :
Observaciones:
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
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

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
Pgina 31 de
59

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
ENTREGABLES
Pruebas Unitarias
Pruebas de Sistema
Pruebas de Integracin
Pruebas de Interoperabilidad
Pruebas de Regresin
Pruebas Funcionales
Pruebas de Usabilidad
Pruebas de Seguridad
Pruebas de Recuperacin a Fallas
Pruebas de Aceptacin
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
incluye
resultados
de
la
comunicacin con los servicios y DUMMIES previstos.
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.
Pgina 32 de
59

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 Regresin
TIPO DE PRUEBA
Automticas
Automticas
Automticas
Automticas
Automticas
y
Manuales
Manuales
Manuales
Automticas
y
Manuales
Automticas
y
Manuales
Automticas
y
Manuales
Manuales
Pruebas Funcionales
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 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
Pgina 33 de
59
HERRAMIENTAS A
UTILIZAR
JUNIT

TIPO DE
PRUEBAS
Pruebas
Sistema
TECNICA DE EJECUCIN
de
test. Dichos mtodos son reconocidos por su

asignatura, la cual debe tener la forma public
void test<Descripcion>(), adems pueden lanzar
cualquier exception.
Las pruebas del sistema tal como estn concebidas
para el proyecto de notificaciones electrnicas involucra
los siguientes pasos:
HERRAMIENTAS A
UTILIZAR
JMETER
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.
Pruebas
Integracin
de
g. Repeticin de la prueba.
Las pruebas del integracin tal como estn concebidas
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
total
de
componentes y/o servicios y su eleccin contar
con la aprobacin del Programa Agenda de
Conectividad e Interventora.
b. Ejecucin de las pruebas de integracin
mediante la herramienta seleccionada.
de incidencias)
herramienta de gestin de incidencias).
Pgina 34 de
59
GRINDER

TIPO DE
PRUEBAS
f.
Pruebas
de
Interoperabilidad
Correccin de la incidencia.
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
de incidencias)
g. Asignacin de la incidencia. (A travs de la
herramienta de gestin de incidencias)
h. Correccin de la incidencia.
Pruebas
Regresin
Pruebas
Funcionales
HERRAMIENTAS A
UTILIZAR
TECNICA DE EJECUCIN
de
i. Repeticin de la prueba.
Las pruebas de regresin tal como estn concebidas
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
de incidencias)
d. Asignacin de la incidencia. (A travs de la
e. Correccin de la incidencia.
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.
de incidencias)
Pgina 35 de
59
Servicios
Enrutador
transaccional
DUMMIES
del
XMLBuddy
Casos de Prueba
Grinder
Casos de Prueba

TIPO DE
PRUEBAS
HERRAMIENTAS A
UTILIZAR
TECNICA DE EJECUCIN
Pruebas
Usabilidad
de
Las pruebas de usabilidad tal como estn concebidas
para el proyecto de notificaciones electrnicas (uso de
prototipado) involucra los siguientes pasos:
Prototipos
Encuesta
usabilidad
NESSUS
Casos de prueba
funcionales
de
seguridad.
Listas de chequeo
para instalacin.
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.
Pruebas
Seguridad
de
e. Compilacin y anlisis de resultados de

encuestas de usabilidad.
Las pruebas de seguridad tal como estn concebidas
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
de incidencias)
h. Asignacin de la incidencia. (A travs de la
i. Correccin de la incidencia.
Pruebas
Configuracin
de
j. 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
Pgina 36 de
59
de

TIPO DE
PRUEBAS
HERRAMIENTAS A
UTILIZAR
TECNICA DE EJECUCIN
Pruebas
Recuperacin
Fallas
de
a
Pruebas
Aceptacin
de
sistema.
b. Ejecucin de la instalacin segn la lista de
chequeo.
de incidencias)
f. Correccin de la incidencia.
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.
de incidencias)
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
de incidencias)
c. Asignacin de la incidencia. (A travs de la
d. Correccin de la incidencia.
e. Repeticin de la prueba.
Pgina 37 de
59
Grinder.
Casos de prueba
Funcionales.
Listas
de
Chequeo.

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 Regresin
Pruebas Funcionales
3.2.
PERFIL DEL RECURSO HUMANO

Ingeniero Desarrollador.
Analista de Pruebas.
Analista de Pruebas
Analista de Pruebas
Analista de Pruebas
Analista de Pruebas
Analista de Pruebas
Usuario Funcional.
Analista de Pruebas
Arquitecto de Desarrollo.
Arquitecto de Desarrollo.
Analista de Pruebas
Usuario Funcional.
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
Herramientas
de
pruebas de sistemas
Share Point
3.2.1.
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
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
Servidor 2
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
Serial-Attach 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
Ready
Disco Duro: 2 dd c/u 300GB, 10K RPM
Serial-Attach SCSI 3Gbps 3,5 in HotPlug
HardDrive
Regulador de disco duro: PREC6i SAS
RAID Controller, 2x4 Connectors, Int,
PCIe, 246MB cache, x6 Bkpl
Pgina 39 de
59
SOFTWARE
INSTALADO Y
CONFIGURADO
Red Hat Enterprise
Linux 4,5ES1 64
Jboss.
Suse 6 de 64
Oracle 10DB
CANTIDAD

Servidor 3
Servidor 4
Estaciones de Trabajo
FireWall
3.3.

Procesador:
Quad
Core
Xeon
E53102x4MB Cache, 1,0GHz, 1066MHz
FSB,
Ready
Disco Duro: 146GB, 10K RPM SerialAttach SCSI 3Gbps 3,5 in HotPlug
HardDrive
Procesador:
Quad
Core
Xeon
E53102x4MB Cache, 1,0GHz, 1066MHz
FSB,
Ready
Disco Duro: 146GB, 10K RPM SerialAttach SCSI 3Gbps 3,5 in HotPlug
HardDrive
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
Red Hat Enterprise

Linux 4,5ES1 64
Alero
Apache
Red Hat Enterprise Linux

4,5ES1 64
bugzilla,
Sistema
Operativo:
Windows XP
Internet Explorer 6.0,
Mozilla 2.0, Office 2003.
Microsoft Windows 2003

spk 2
Microsoft
ISA
Server
2004 Spk2
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.
Pgina 40 de
59

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.
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.
Pgina 41 de
59

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.
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:
4.2.
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.
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.
La totalidad de los puntos de control probadas debe ser
mayor al 75% del total de los componentes que integran
la solucin.
El 90% de las pruebas realizadas deben ser exitosas
contra los servicios del tramitador.
Pgina 43 de
59

Pruebas de Regresin
Pruebas Funcionales
El 90% de las pruebas realizadas deben ser exitosas

contra los servicios DUMMIES.
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
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.
mnimos para el funcionamiento.
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.
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
SI
NO
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?
Pgina 44 de
59
No
Aplica
Observaciones

Existe un manejo de errores adecuado?
Se cumpli con la estrategia de ejecucin de la
prueba?
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>
Descripcin
del escenario
<Nmero total de casos

de prueba ejecutados de
acuerdo al escenario>
Nmero de pruebas
exitosas
<Del total de pruebas

ejecutadas, cuantas
pruebas fueron exitosas>
<Tiempo mximo que dur
en ejecucin una Prueba>
Nmero de
pruebas
Fallidas
Tiempo
Promedio de
ejecucin de
las pruebas
Nmero de
Peticiones
Fallidas
Tipo de errores
<Del total de pruebas

ejecutadas, cuantas pruebas
fueron fallidas>
<Tiempo promedio de
ejecucin de las pruebas>
Cantidad de
Memoria
utilizada
<Cantidad de MB de
memoria utilizada en la
prueba>
Promedio de
bytes recibidos
<Promedio de bytes
recibidos>
Tiempo mximo de
ejecucin de una
prueba
Nmero de peticiones
exitosas
<Nmero de peticiones
http exitosas>
Nmero de Errores
<Numero de errores
ocurridos durante las
pruebas>
<Porcentaje de consumo
de utilizacin de CPU
durante la ejecucin de la
prueba>
<Promedio de bytes
enviados>
% de Utilizacin del
Procesador
Promedio de bytes
enviados
<Nmero de peticiones http

fallidas>
<Descripcin del tipo de
errores presentados>
Pruebas de Integracin: El resultado de las pruebas de integracin se ver reflejado

en el siguiente informe o lista de chequeo:
Elemento a Revisar
SI
NO
No
Aplica
Observaciones
Se realizaron las pruebas de Integracin con alguna

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 Interoperabilidad: El resultado de las pruebas de interoperabilidad se

ver reflejado en el siguiente informe o lista de chequeo:
Pgina 45 de
59

Elemento a Revisar
SI
NO
No
Aplica
Observaciones
Se realizaron las pruebas de Interoperabilidad con alguna

Cul?
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
Elemento a Revisar
SI
NO
No
Aplica
Observaciones
Se realizaron las pruebas de interfaz de usuario con

alguna herramienta especializada?
Qu pginas se cubri con la prueba?
Cul?
Pruebas de Seguridad: El resultado de las pruebas de seguridad se ver reflejado en

el siguiente informe o lista de chequeo:
Elemento a Revisar
SI
Se realizaron las pruebas de seguridad con alguna

Pgina 46 de
59
NO
No
Aplica
Observaciones

Cul?
Pruebas de Configuracin: El resultado de las pruebas de configuracin se ver

reflejado en el siguiente informe o lista de chequeo
Elemento a Revisar
SI
NO
No
Aplica
Observaciones
Se realizaron las pruebas de Configuracin con alguna

Cul?
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
Elemento a Revisar
SI
NO
No
Aplica
Observaciones
Se realizaron las pruebas de recuperacin a fallas con

alguna herramienta especializada?
Se estableci un criterio para la ejecucin de las
pruebas? Cul?
4.3.
Pruebas de Aceptacin: El resultado de las pruebas de aceptacin se ver reflejado

de acuerdo a los tipos de pruebas seleccionados.
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.
Pgina 47 de
59

4.4.
Los incidentes encontrados en las pruebas fueron corregidos y probados.
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
REQUERIMIENTO
HARDWARE
SISTEMA OPERATIVO
SOFTWARE BASE
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.
CASOS DE PRUEBAS
5.2.1.
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]>
CASO DE PRUEBA No.
VERSIN DE EJECUCIN
FECHA EJECUCIN
<Identificacin del caso de uso objeto de la prueba>
CASO DE USO:
MODULO DEL SISTEMA
Descripcin del caso de prueba:

1.
CASO DE PRUEBA
a.
Precondiciones
<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>
<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>
c.
RESPUESTA ESPERADA DE LA
APLICACIN
TIPO
ESCENARIO
<Tipo
de <Respuesta que se espera de la
escenario que
aplicacin>
pretende
probarse:
Correcto/Incorre
cto>
COINCIDE
SI
NO
RESPUESTA DEL SISTEMA
<Respuesta que se obtuvo de la aplicacin

en el momento de la ejecucin de la prueba>
Post condiciones
<Lista de poscondiciones que deben cumplirse despus de realizar la prueba>
2.
RESULTADOS DE LA PRUEBA
Defectos y desviaciones
Veredicto
Paso
<Lista de defectos o desviaciones encontrados por el analista o usuario al ejecutar la prueba>
Pgina 50 de
Fall
59

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
Reglas de Negocio
Flujos Alternos
Flujos de Excepcin
Flujo Bsico
Generalidades:
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 ejecutar la
Pgina 51 de
59

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
diferentes
CRITERIOS DE
EVALUACIN
1 = Se encuentran en
todo el sistema
2 = Se
algunas
sistema.
encuentra en
partes
del
3 = No se encuentran en
ninguna
parte
del
sistema.
1 = El vocabulario es
demasiado tcnico.
2. Es simple el vocabulario utilizado?
2
=
El
vocabulario
presenta
algunas
dificultades
de
comprensin.
3. Se proporciona tiempo suficiente para

realizar las entradas por teclado?
3 = El vocabulario es
completamente
comprensible.
1 = El tiempo es muy
limitado.
2 = El tiempo es limitado
para
algunas
funcionalidades.
4. Hay algn tipo de asistencia para los

usuarios que hacen uso del sistema por
primera vez?
Pgina 52 de
59
3
=
El
tiempo
es
completamente
suficiente.
1 = No existe ninguna
ayuda.

2 = Se encuentra ayuda
en algunas partes.
3. El sistema es fcil de operar para alguien

que no recibi capacitacin en su operacin?
3 = Existen ayudas en
todo el sistema.
1 = El sistema es de
difcil comprensin.
2 = El sistema es fcil de
operar en algunas de sus
funcionalidades.
6. Se entienden la interfaz y su contenido?
3 = El sistema es
completamente fcil de
operar.
1 = No se entiende su
interfaz.
2 = La interfaz se
entiende
en
algunas
partes.
7. Resulta fcil identificar un objeto o una

accin?
3 = La interfaz es
completamente
entendible.
1 = Es difcil identificar
los objetos o acciones.
2 = Se pueden identificar
los objetos y acciones en
algunas
partes
del
sistema.
8. Resulta fcil entender el resultado de

una accin?
3 = Todos los objetos y

acciones son fcilmente
identificables.
1 = Los resultados de las
acciones
no
son
entendibles.
2 = Los resultados de las
acciones son entendibles
en algunas partes o la
mayor parte del sistema.
Pgina 53 de
59

9. Est diseada la interfaz para facilitar la

realizacin eficiente de las tareas de la
mejor forma posible?
3 = Todos los resultados

de las acciones son
entendibles.
1 = La interfaz es difcil
de usar.
2 = La interfaz es difcil
de usar en algunas partes
del sistema.
10.
Son
apropiados
presentado por el sistema?
los
mensajes
3 = La interfaz es
completamente
sencilla
de usar.
1 = Los mensajes non son
apropiados.
2 = Los mensajes son
apropiados en algunas
partes del sistema.
11. Acta el sistema en la prevencin de

errores?
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.
12. El sistema informa claramente sobre los

errores presentados?
3 = El sistema previene
cualquier error que pueda
cometer el usuario.
1 = El sistema no informa
de
manera
adecuada
sobre
los
errores
cometidos.
2 = El sistema informa de
manera
adecuada
algunos o la mayora de
los errores cometidos por
el usuario.
Pgina 54 de
59

13.
Se
utiliza
descriptivos?
mensajes
textos
3 = El sistema informa de
forma adecuada todos los
errores cometidos por el
usuario.
1 = Los mensajes de
texto no son descriptivos.
2 = La mayora de los
textos son descriptivos o
fciles de interpretar
14. Permite una cmoda navegacin dentro

del producto y una fcil salida de ste?
3 = Todos los textos son

descriptivos o fciles de
interpretar.
1 = La navegacin no es
sencilla.
2
=
La
presenta
dificultades.
13. Se permite al usuario personalizar la

interfaz?
navegacin
algunas
3 = La navegacin es
sencilla,
requiere
de
pocos
vnculos
para
accedes
a
las
funcionalidades
del
sistema.
1 = La interfaz no es
personalizable.
2 = La interfaz es
personalizable
con
algunas restricciones.
16. Se proporciona informacin visual de

dnde est el usuario, qu est haciendo y
qu puede hacer a continuacin?
3 = La interfaz es
completamente
personalizable.
1 = No se presenta
ninguna
informacin
visual ni otro tipo de
ayuda.
2 = Presenta ayudas en
algunas
partes
del
sistema.
Pgina 55 de
59

17. Existe atajos del teclado bien hechos?
3 = Las ayudas son

apropiadas
y
estn
distribuidas a los largo del
sistema.
1 = No existen atajos por
teclado.
2 = Existen algunos
atajos por teclado.
18. Se presenta al usuario la informacin

que slo necesita?
3 = Todas las opciones

presentan
atajos
por
teclado.
1
=
La
informacin
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 del tipo de prueba:

Carga, Volumen, Estrs, ETC>
Descripcin de la
prueba:
<Descripcin del objetivo de la prueba>
Versin de Ejecucin
<Versin o iteracin de ejecucin de la

prueba>
1. Prerrequisitos de la prueba
Pgina 56 de
59
Cdigo
de la
prueba
<Codificacin de la prueba>
Fecha
de
Ejecuci
n
<Fecha
de
ejecucin
en
formato
AAAA/MM/DD diligenciado por el analista
de pruebas al momento de su ejecucin>

<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

Prueba
satisfactori
a
SI
NO
Pasos a Seguir
Observaciones
<Pasos numerados en orden lgico para la ejecucin de la

prueba>
4. Resultados de la prueba
Defectos y desviaciones
Veredicto
<Lista de defectos o desviaciones encontrados por el analista o usuario al ejecutar la prueba>
Paso
Fall
Observaciones
Probador
<Observaciones generales del analista o usuario sobre la ejecucin de la prueba>
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
<Identificacin del caso de
uso>
Aspecto a Evaluar
1. Datos Entrada
Obligatoriedad
Longitud
Tipo de Dato
Caso de Prueba
prueba
que
evala
Obligatoriedad>
prueba que evala Longitud>
prueba que evala Tipo de
dato>
2. Reglas de Negocios
Relacionadas con datos
de entrada
<Lista de casos de prueba>
Pgina 57 de
59

prueba que evala la regla de
negocio>
3. Reglas de Negocios
<Lista de casos de prueba>
4. Flujos de Excepcin
<Lista
de
flujos
excepcin>
de <Identificacin del caso de

prueba que evala los flujos
de excepcin
5. Flujos Alternos
<Lista de casos de flujos
alternos>
6. Flujo Bsico
5.2.6.
MATRIZ REQUERIMIENTOS
TCNICOS
NO

prueba que evala la regla de
negocio>
<Identificacin del
prueba que evala
alternos.>
<Identificacin del
prueba que evala
bsico.
FUNCIONALES
VS
CASOS
DE
caso de
los flujos
caso de
el flujos
PRUEBA
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
5.3.
REQUERIMIENTO NO
FUNCIONAL VERIFICADO
OBSERVACIONES
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
Ejecuci
n
Fecha
de
Ejecuci
n
EJECUTAD
A
Pgina 58 de
59
CUMPL
E
NO
CUMPLE
Observaciones

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

Anexo 13 Modelo Plan de Prueba

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Anexo 13 Modelo Plan de Prueba

Cargado por

Copyright:

Formatos disponibles

PLAN DE PRUEBAS DETALLADO

SISTEMA DE NOTIFICACIN EN LNEA

Bogot, D.C., Diciembre de 2008

PLAN DE PRUEBAS DETALLADO

FORMATO PRELIMINAR AL DOCUMENTO

PLAN DE PRUEBAS DETALLADO

Este documento tiene por objeto establecer el contenido y criterios

Ministerio de comunicaciones: programa Agenda de Conectividad

Proyecto Sistema de Notificaciones y Comunicaciones

Equipo U.T e-Notificaciones

PLAN DE PRUEBAS DETALLADO

Equipo U.T. eNotificaciones

Equipo U.T. eNotificaciones

Inclusin de resultados de la etapa de planificacin

Fueron incluidas las pruebas de seguridad en el

Fueron incluidas la lista de Dummies a desarrollar

Fue incluida la tipificacin de pruebas en el punto 2.5

Fueron incluidas las tcnicas de ejecucin de pruebas

Fue incluida la lista de chequeo para pruebas

Fueron descritas las pruebas y las herramientas a

Para cada herramienta de pruebas de identifico en

Inclusin del formato para el diseo de las pruebas

Inclusin de matriz de trazabilidad de pruebas

Equipo U.T. eNotificaciones

Equipo U.T. eNotificaciones

Equipo U.T. eNotificaciones

Fueron incluidas las caractersticas del ambiente de

Fueron eliminadas las pruebas del plan piloto por no

PLAN DE PRUEBAS DETALLADO

RECURSOS DEL PLAN DE PRUEBAS................................................................................................................................. 38

PLAN DE PRUEBAS DETALLADO

EVALUACIN DE PRUEBAS EJECUTADAS...................................................................................................................... 43

PLAN DE PRUEBAS DETALLADO

PLAN DE PRUEBAS DETALLADO

El contenido de este documento de plan de pruebas hace parte integral de la metodologia de

Este documento de PLAN DE PRUEBAS DETALLADO, se convierte en una gua para

PLAN DE PRUEBAS DETALLADO

Unitarias: Permite verificar la funcionalidad y estructura

Sistema: Estas pruebas buscan diferencias entre la

PLAN DE PRUEBAS DETALLADO

Configuracin: Establece y mantiene la integridad de

Funcional: La prueba funcional es un proceso para

Caja Negra: Estas pruebas permiten obtener conjuntos

Ciclo de Negocio: Esta prueba tiene por objeto

Esta prueba permite encontrar problemas

PLAN DE PRUEBAS DETALLADO

Es la prueba final basada en las especificaciones del

En esta prueba se valida que el sistema mantenga su

DEFINICIONES, ACRNIMOS Y ABREVIATURAS

Algunos documentos del proyecto SISTEMA DE NOTIFICACIONES Y COMUNICACIONES, son

Metodologa de Pruebas Punto 8 pagina 67 del Plan de Proyecto.

PLAN DE PRUEBAS DETALLADO

Documento de Especificacin de Requerimientos.

PLAN DE PRUEBAS DETALLADO

PLAN DE PRUEBAS DETALLADO

TCNICAS DE ESPECIFICACIN DE LAS PRUEBAS

La estrategia del proceso del plan de pruebas se implementar de acuerdo al esquema de

PLAN DE PRUEBAS DETALLADO

Se planifican pruebas personalizando los estndares especficamente para el

En la definicin del plan de pruebas, se valorar:

Se tendr en cuenta que:

Las pruebas estarn presentes a lo largo de todo el ciclo de vida del

Cronograma detallado de la ejecucin de las pruebas; donde se especifica

PLAN DE PRUEBAS DETALLADO