4.6.
Plan de implementación (Diagrama de Gantt).
4.7.
Colocación de canaletas, cableado y
gabinetes.
De
acuerdo a la metodología analizada y una vez estudiado el terreno, podemos
concluir que las canaletas los colocaremos a un metro por el estado del
terreno.
Para
los servidores hemos acondicionado un cuarto el cual tendrá los switch y el
router en un ambiente más adecuado para el mejor rendimiento del área de
trabajo.
4.8.
Configuración del direccionamiento de red
(IP).
Configuración
de equipos para el switch 1
Configuración
de equipos para el switch 2
4.9.
Configuración del Servidor y/o Configuración
del Cliente
4.10. Configuración de los
Servicios
4.11. Plan de pruebas
y correcciones.
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 estándares de calidad que no
solo permiten el seguimiento y correcciones a tiempo del software sino que además se encuentra definido por
etapas, facilitando el seguimiento y control de los procesos del proyecto en
desarrollo y proporcionando a la UNION
TEMPORAL E-NOTIFICACIONES garantizar la operatividad y funcionalidad de la
solución desarrollada.
Acorde
con el enfoque del desarrollo de la solución, el plan de pruebas está basado en
la metodología de Rational Unified
Process (RUP), lo que hace que este plan de pruebas tenga como propósito
establecer las técnicas, herramientas y
actividades relacionadas con la ejecución y validación 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 ELECTRÓNICAS”.
Este documento tiene como propósito establecer las técnicas,
herramientas y actividades relacionadas con la ejecución y validación 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 ELECTRÓNICAS”.
Este
documento de PLAN DE PRUEBAS DETALLADO,
se convierte en una guía para
desarrollar de una forma organizada las diferentes actividades que se
realizarán en el proceso del plan de pruebas
en el desarrollo del proyecto
denominado “SISTEMA DE NOTIFICACIONES Y
COMUNICACIONES ELECTRÓNICAS”.
La metodologia de pruebas y este documento de plan de pruebas
permitirán al equipo profesionales
expertos que participan en el frente de pruebas del proyecto denominado
“SISTEMA DE NOTIFICACIONES Y COMUNICACIONES ELECTRÓNICAS”, evaluar
aspectos como: la lógica estructural, la seguridad, la interconexión, el
soporte conceptual, las herramientas de
apoyo y sobretodo la independencia de aspectos técnicos del desarrollo de la
solución tecnológica contratada, tales
como: la plataforma tecnológica o la arquitectura de la solución a probar, sin embargo a continuación se
describen las diferentes pruebas a ser aplicadas:
|
TIPO DE PRUEBA
|
DEFINICIONES
|
FASE DE RUP
|
|
UNITARIAS
INTEGRACIÓN
|
Unitarias: Permite verificar la funcionalidad y
estructura de cada componente individualmente del sistema una vez que ha sido
codificado.
Integración: Permite
verificar el correcto ensamblaje entre los distintos módulos que
componen el sistema desarrollado.
|
ELABORACIÓN
|
|
SISTEMA:
·
Carga
·
Volumen
·
Estress
·
Robustez
·
Concurrencia,
·
Interfaz de Usuario Recuperación a Fallas
·
Rendimiento
·
Seguridad
·
Integridad de las BD
·
Interoperabilidad
·
Desempeño
·
Configuración
|
Sistema: Estas pruebas buscan diferencias entre la
solución desarrollada y los
requerimientos, con el fin de identificar errores que se puedan generar entre la
especificación funcional y el diseño del sistema.
Carga: Valida aquellos volúmenes de datos máximos
especificados en los requerimientos no Funcionales
Volumen: Esta prueba somete el software a grandes
cantidades de datos para determinar si se alcanzan límites que causen la
falla del software
Estrés: Valida aquellos volúmenes de datos máximos
que resiste el sistema antes de comenzar con errores.
Robustez:
Valida si el sistema se mantiene estable y consistente después de
circunstancias adversas
Concurrencia: Valida la capacidad del sistema de atender
múltiples solicitudes departe de los usuarios que acceden a un mismo recurso.
Interfaz de usuario: Ppermite verificar que la navegación a través
de los elementos que se están probando, reflejen las funciones del negocio y
los requerimientos funcionales.
Recuperación a fallas: Estas pruebas aseguran que el que el software pueda recuperarse a fallas de
hardware, software o mal funcionamiento de la red sin pérdida de datos o de
integridad de los datos.
Rendimiento: Permite validar si la aplicación cumple los
criterios de tiempos de respuesta establecidos.
Seguridad: Verifica el cumplimiento de las políticas
de seguridad acordadas para el sistema.
Integridad de las bases de datos: Consiste en asegurar que los métodos 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 solución desarrollada, su arquitectura base, los protocolos
de la solución, las interfaces y los
módulos del sistema, funcionando en forma conjunta.
Desempeño: Este tipo de prueba es un aspecto
fundamental en una aplicación, ya que si ésta no responde en el debido
tiempo, se pueden perder clientes, o dañar la imagen ante los usuarios.
Configuración: Establece y mantiene la
integridad de los productos de software a través del ciclo de vida del
proceso del mismo.
|
CONSTRUCCIÓN
|
|
FUNCIONALES
|
Funcional:
La prueba funcional es
un proceso para procurar encontrar discrepancias entre el programa y la
especificación funcional.
Caja
Negra: Estas
pruebas permiten obtener conjuntos de condiciones de entrada que ejecutan
todos los requisitos funcionales de un
programa.
Ciclo de Negocio:
Esta prueba tiene por objeto garantizar que el proceso de negocio esta
adecuadamente soportado por el software desarrollado y que éste dispone de la
funcionalidad adecuada para ejecutar todas las tareas incorporadas en el
proceso de negocio.
Usabilidad: Esta
prueba permite encontrar problemas de factores humanos, o usabilidad.
Instalación: Esta prueba permite
verificar la instalación y desinstalación de la aplicación en diferentes
entornos de hardware y software
|
|
|
ACEPTACIÓN
|
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
|
TRANSICIÓN
|
|
REGRESIÓN
|
En esta prueba se
valida que el sistema mantenga su correcta funcionalidad debido a la
incorporación de un ajuste, corrección o nuevo requerimiento. Es una prueba
funcional y técnica que valida que el sistema siga funcionando perfectamente
después de que las correcciones sean
aplicadas.
|
·
El plan de prueba:
describe todos los métodos que se utilizarán para verificar que el software
satisface la especificación del producto y las necesidades del cliente. Incluye
los objetivos de calidad, necesidades de recursos, cronograma, asignaciones,
métodos, etc.
·
Casos de prueba:
lista los ítems específicos que serán probados y describe los pasos detallados
que serán seguidos para verificar el software.
·
Reporte de pruebas: describen
los problemas encontrados al ejecutar los casos de prueba.
·
Herramientas de pruebas y
automatización: documentación de las herramientas
empleadas en el proceso de pruebas.
·
Métricas, estadísticas y
resúmenes: indican cómo ha sido el progreso del proceso
de prueba.
Algunos documentos
del proyecto SISTEMA DE NOTIFICACIONES Y COMUNICACIONES, son base fundamental
de este documento inicial de plan de pruebas, que a continuación se relacionan
- Metodología
de Pruebas – Punto 8 página 67 del Plan de Proyecto.
- Documento
de Especificación de Requerimientos.
- Documento
de Arquitectura General Detallada
- Términos de referencia del proceso de licitación de la plataforma de interoperabilidad.
Descripción resumida
de contenido de cada una de las secciones que siguen, y explicación de la forma
en que está organizado el presente documento.
Estrategia de Pruebas:
En este capítulo se presenta una
perspectiva general de la estrategia que se va a seguir para analizar, diseñar,
implementar y ejecutar las pruebas del proyecto “SISTEMA DE NOTIFICACIONES Y COMUNICACIONES ELECTRÓNICAS”. Así mismo
se definirá qué tipos de pruebas se van a realizar y cómo se ejecutarán.
Recursos del Plan de Pruebas:
Este capítulo identifica los recursos humanos y no
humanos (hardware, software, herramientas de soporte, configuración de entorno de pruebas, entre
otros), necesarios para desarrollar el proceso del plan de pruebas de la
solución del Sistema de Notificación en Línea.
Evaluación de Pruebas Ejecutadas:
En este capítulo se describe de los métodos de
evaluación de las pruebas ejecutadas, de tal forma que permitirá evaluar los
grados de aceptación de las pruebas.
Anexos:
En este capítulo se describen los documentos anexos
que se utilizarán para la especificación y la documentación de la ejecución 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 gráfica:
El ciclo de pruebas
comprende seis actividades las cuales deberán ser desarrolladas de la siguiente
manera:
Para el desarrollo de
la solución del Sistema de Notificación en Línea, se considera de gran importancia la ejecución del plan de
pruebas, haciéndose necesario la planificación de las mismas, lo que en
consecuencia hace necesario tener claro los siguientes planteamientos:
·
Se planifican pruebas
personalizando los estándares específicamente para el proyecto de
notificaciones.
·
Se definen niveles de
pruebas a aplicar.
·
Se especifican las técnicas
a utilizar.
·
Se establece el tiempo para
la ejecución de cada una de las pruebas.
·
Uso de herramientas.
·
Criterios de aceptación.
·
Recursos involucrados.
En la
definición del plan de pruebas, se
valorará:
·
El alcance de la aplicación.
·
La complejidad de sus
procesos.
·
Plataforma/s en las que se
debe probar.
·
Conocimientos y formación de
quienes ejecutarán las pruebas.
·
Normativas legales
aplicables.
·
Otros recursos involucrados.
Se tendrá en cuenta que:
·
Las pruebas estarán
presentes a lo largo de todo el ciclo de vida del desarrollo, de la solución.
·
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 actualización 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
planificación:
·
Cronograma detallado de la
ejecución de las pruebas; donde se especifica qué prueba se realiza, cuánto
tiempo se estima para su ejecución, recursos a utilizar (humanos y
tecnológicos); este cronograma se encuentra dentro del cronograma general del
proyecto y específicamente en la fase desarrollo (ver plan de construcción)
·
Formatos a utilizar para el
diseño de las pruebas.
·
Formatos a utilizar para el
registro y análisis de los resultados de las pruebas.
·
Herramientas a utilizar para
la gestión de incidencias.
·
Procedimientos para el
control de cambios.
·
Herramientas a utilizar para
la ejecución de las pruebas.
Para el diseño de las
pruebas, se tendrán en cuenta aspectos que permitirán encontrar defectos en el
periodo de desarrollo del software, la realización de pruebas propias de
verificación y validación de datos, según se aclara en los siguientes ítems:
A. Alcance: El alcance de las
pruebas estará dado por el marco del Sistema de Notificación en Línea, que se encuentra en desarrollo, ésta compuesta (Información
tomada de los términos de referencia y del documento de Arquitectura General
Detallada) por:
·
Vista
de Casos de Uso.
·
Diseño
de las clases y su organización en paquetes y subsistemas.
·
Prototipos
del sistema
B. Inventario
de las Pruebas: En esta sección 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 entrarían en una regresión y cuáles no con mayor facilidad.
- Recortar
alcance en forma rápida y ordenada.
- Se
estima el tiempo en probar cada funcionalidad.
- Evaluar
aspectos técnicos del sistema.
C
C. Resultado
de la ejecución de las Pruebas: En este punto se resaltan
las entradas fundamentales que son la partida para la ejecución del plan de
pruebas.
·
Inventario de pruebas
priorizado.
·
Estimación de esfuerzo de
cada funcionalidad.
·
Plan de desarrollo del producto.
·
Plazos previstos para el
proyecto.
A. Ciclo
de la Prueba: Las actividades de la prueba se
realizarán para una determinada versión del producto, sobre la cual se ejecutan
las pruebas y se reportan los incidentes encontrados. Para cada versión del
producto se realizan alguna o todas las tareas asociadas a las pruebas.
El proceso de planificación se ajusta al
comenzar cada ciclo debido a posibles:
·
Atrasos de desarrollo
·
Modificaciones en los
requerimientos iníciales
·
Cambios en el alcance del
producto
·
Calidad del producto
Este
capítulo se enfoca a la definición del proceso de administración de la
configuración del proyecto “SISTEMA DE
NOTIFICACIONES Y COMUNICACIONES ELECTRÓNICAS”, en el cual se establece
el mantenimiento e integridad del software a través del ciclo de vida del
proyecto y se proveen contextos de trabajo estables para los posibles cambios
antes de ser entregado formalmente en producción.
A
continuación se presenta una definición de los conceptos básicos de la
disciplina de administración de configuraciones, una descripción de las
actividades principales y una propuesta de formatos para facilitar la captura
de la información necesaria en las distintas actividades.
Administración de Configuraciones: Es el proceso de identificar y definir los elementos o ítems
de configuración del sistema, controlando la entrega y el cambio de estos
elementos a través 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.
Configuración: Conjunto completo (respecto de la Arquitectura del
Sistema, es decir que cada componente está representado) y coherente (respecto
de que defina una versión estable del sistema, es decir que las versiones de
cada componente se correspondan) de Ítems de Configuración que constituyen un
producto de software.
Comité de control de cambios: Grupo con la autoridad para evaluar, aprobar y/o rechazar la
implementación 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 Configuración: Componente de Software y/o producto de software destinado para
ser puesto bajo Administración de Configuraciones.
Solicitud de Cambio: Documento a través del cual el equipo técnico autorizado
solicita al Grupo de Desarrollo realizar la corrección de un defecto del Sistema
de Notificación en Línea o de una mejora sobre la
solución antes de salir a producción.
Versión: Resultado de la evolución que ha sufrido un Componente de
Software en el tiempo.
En el siguiente gráfico se
muestra el modelo estándar de ejecución de pruebas
:
Como se
observa, representa un modelo de pruebas en V, a diferencia de los modelos
clásicos, extiende las pruebas a lo largo de todo el ciclo de vida del
software.
Mientras se
realizan las fases de requerimientos, análisis, diseño e implementación se van
diseñando las pruebas del mismo nivel. Al llegar a la etapa de pruebas se
inicia la ejecución de lo diseñado desde las pruebas unitarias hasta las
pruebas funcionales.
Para cada
una de las pruebas se realizará el siguiente procedimiento:
Aquí se tendrán en cuenta las
siguientes especificaciones:
- Elementos
del sistema, es decir; los módulos y características de la solución que se
van a probar.
- Se
listarán 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 características requeridas como el tiempo y la respuesta para los elementos que se van
a probar. Estas especificaciones se harán utilizando los formatos
establecidos en el numeral 5
de este plan de pruebas.
- Necesidades
del entorno del proceso de ejecución del hardware, software y recurso
humano.
- Requisitos
especiales de procedimiento o restricciones especiales en los
procedimientos para ejecutar este caso.
1.1.1.1.
EVALUACIÓN Y CIERRE
Para la evaluación 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.
Para el seguimiento y control de las
pruebas se llevarán a cabo comités técnicos de seguimiento periódico semanal
donde se evalúen los siguientes temas.
En este
capítulo se señalaran las diferentes herramientas de software que se utilizarán
para la ejecución de las pruebas.
Las
herramientas que se utilizarán, dependerán del tipo de prueba que se realizará,
es decir que por cada tipo de prueba es posible que se utilice una herramienta
diferente.
|
Características
|
Tipo de prueba
|
|
JUnit es un
conjunto de clases (framework) que permite realizar la ejecución de clases
Java de manera controlada, para poder evaluar si el funcionamiento de cada
uno de los métodos de la clase se comporta como se espera. Es decir, en
función de algún valor de entrada se evalúa el valor de retorno esperado; si
la clase cumple con la especificación, entonces JUnit devolverá que el método
de la clase pasó exitosamente la prueba; en caso de que el valor esperado sea
diferente al que regresó el método durante la ejecución, JUnit devolverá un
fallo en el método correspondiente
JUnit es
también un medio de controlar las pruebas de regresión, necesarias cuando una
parte del código ha sido modificado y se desea ver que el nuevo código cumple
con los requerimientos anteriores y que no se ha alterado su funcionalidad
después de la nueva modificación.
En la
actualidad las herramientas de desarrollo como NetBeans y Eclipse cuentan con
plug-ins que permiten que la generación de las plantillas necesarias para la
creación de las pruebas de una clase Java se realice de manera automática,
facilitando al programador enfocarse en la prueba y el resultado esperado, y
dejando a la herramienta la creación de las clases que permiten coordinar las
pruebas.
La versión
de la herramienta que se utilizará será: release 4.5
|
Esta herramienta será
utilizada para la ejecución de:
·
Pruebas
unitarias.
·
Pruebas de
sistema
·
Pruebas de
Integración.
|
|
Características
|
Tipo de prueba
|
|
Esta
herramienta nos permite implementar unidades de test al estilo JUnit, pero
donde los módulos a probar son páginas web (servlets, páginas jsp, php,
cgi's, etc.). HttpUnit nos permite simular el acceso a un portal web, hacer
"click" en los links, consultar las cookies, ejecutar código Java
Script, etc.
HttpUnit
permite escribir test que simulen a un usuario accediendo a una aplicación
basada en Web mediante un navegador. Tiene muchas de las funciones de un
navegador: control de cookies por sesiones, análisis de contenido HTML, envío
de formularios mediante los métodos GET y POST, autentificación, y otras
características. Se puede chequear si hay cierto contenido en la página,
enlace por enlace y formulario por formulario, lo que permite verificar que
la aplicación devuelve los resultados apropiados
La versión
de la herramienta que se utilizará será: release 1.7
|
Esta herramienta será
utilizada para la ejecución de:
·
Pruebas
Funcionales.
·
Pruebas de
Sistema
·
Pruebas de
Configuración
|
|
Características
|
Tipo de prueba
|
|
JMeter es
una herramienta de carga para llevar acabo simulaciones sobre cualquier
recurso de Software.
Inicialmente
diseñada para pruebas de estrés en aplicaciones web, hoy en día, su
arquitectura ha evolucionado no sólo para llevar a cabo pruebas en
componentes habilitados en Internet (HTTP), sino además en Bases de Datos,
programas en Perl, requisiciones FTP y prácticamente cualquier otro medio.
Posee la
capacidad de realizar desde una solicitud sencilla hasta secuencias de
requisiciones que permiten diagnosticar el comportamiento de una aplicación
en condiciones de producción.
En este
sentido, simula todas las funcionalidades de un Navegador
("Browser"), o de cualquier otro cliente, siendo capaz de manipular
resultados en determinada requisición y reutilizarlos para ser empleados en
una nueva secuencia.
La versión
de la herramienta que se utilizará será: release 1.9
|
Esta herramienta será
utilizada para la ejecución de:
·
Pruebas de
Sistema
|
|
Características
|
Tipo de prueba
|
|
Es un
framework libre en Java, para realizar pruebas de carga o estrés utilizando
una consola gráfica.
Esta versión
hace uso del lenguaje script jhyton, lo que permite a cualquier código Java
ser encapsulado como una prueba.
Esta
herramienta permite utilizar un ambiente de red para realizar las pruebas de
carga de forma totalmente distribuida.
La versión
de la herramienta que se utilizará será: The Grinder 3
|
Esta herramienta será
utilizada para la ejecución de:
·
Pruebas de
Sistema
|
|
Características
|
Tipo de prueba
|
|
Nessus es
un programa de escaneo de vulnerabilidades en diversos sistemas operativos. Consiste en nessusd, el daemon Nessus,
que realiza el escaneo en el sistema objetivo, y nessus, el cliente
(basado en consola o gráfico) que muestra el avance y reporte de los
escaneos. Desde consola nessus puede ser programado para hacer
escaneos programados con cron.
En operación
normal, nessus comienza escaneando los puertos con nmap o con su propio
escaneador de puertos para buscar puertos abiertos y después 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 inglés), 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 también
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.
|
Esta herramienta será
utilizada para la ejecución de:
· Pruebas de Seguridad
|
|
Características
|
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á
utilizada para la ejecución de:
·
Pruebas de
Interoperabilidad para los archivos XML que genere la aplicación.
|
Las
pruebas que se realizarán serán aquellas que fueron señaladas como tipos de
pruebas en el numeral 8.3 de la metodología de pruebas; en este capítulo solo
serán mencionados a manera general los tipos de pruebas.
El
objetivo principal de la ejecución de las pruebas esta dado a:
·
Descubrir tantos errores
como sea posible.
·
Notificar acerca de los
riesgos percibidos del proyecto
·
Identificar falencias
funcionales de la aplicación, enmarcadas en grados de usabilidad ya definidos.
·
Evaluar la calidad del
producto y señalar un indicador de aceptación del mismo.
·
Evaluar la calidad técnica
del producto y resolver las falencias identificadas en las pruebas de tipo
técnico.
·
Cumplir con los
requerimientos específicos del cliente, en cuanto a la ejecución de las
pruebas.
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 técnica que permitirá:
- Verificar
que los módulos del sistema estén libres de errores.
- Que
todos los caminos lógicos principales deben ejecutarse correctamente en
cada módulo de la aplicación.
- Todas
las transacciones deben ser probados.
- Todos
los tipos de registro de entrada válidos deben ser procesados
- Todos
los tipos de registro de entrada inválidos deben ser procesados
correctamente
- Códigos
de vuelta no nulos.
- Excepciones
a tratamiento normal.
- Todas
las salidas válidas son procesadas.
- Rasgos
de Control son probados y documentados.
|
Objetivo de la Prueba:
|
·
Validar las piezas
individuales del software como una unidad independiente.
|
|
Estrategia:
|
·
Se efectúan para los servicios del negocio y para la
lógica de beans en capa Web que tengan complejidad alta.
·
Generar casos de pruebas
necesarios que permitan identificar:
o Que
al menos cada sentencia o instrucción del programa se ejecute al menos una
vez correctamente.
o Que
cada condición 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.
|
|
Herramienta requeridas:
|
JUNIT
|
|
Observaciones
|
La prueba se realizará por
Módulo entendiéndose por tal:
·
Bloque básico
de programa
·
Implementa
función independiente y simple
·
Puede probarse
por separado.
|
Las
pruebas de sistema buscan diferencias entre la solución desarrollada y los
requerimientos, enfocándose en la identificación de los errores que se puedan
generar entre la especificación funcional y el diseño del sistema, así como, el
negocio objeto de la aplicación.
El
objetivo de las pruebas de integración es verificar el correcto ensamblaje
entre los distintos módulos que componen la solución una vez que han sido
probados unitariamente con el fin de comprobar que interactúan correctamente a
través 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 solución. Estas
partes pueden ser módulos, aplicaciones individuales, es decir esta prueba
válida la integración entre los diferentes módulos que componen la solución con
el fin de garantizar que su operación integrada es correcta, teniendo en cuenta
los siguientes temas técnicos:
- El
funcionamiento integrado de módulos interdependientes debe estar libre de
errores
- Probar
todas las dependencias entre módulos
- Probar
el flujo de control y el flujo de datos a través de todas las capas
|
Objetivo de la Prueba:
|
Validar la integración entre los
diferentes módulos que componen la solución con el fin de garantizar que su
operación integrada es correcta
|
|
Estrategia:
|
Pruebas de Integración Incremental
Ascendente
·
Combinación de módulos de
bajo nivel en grupos que realicen una misma función o subfunción especifica,
con el fin de reducir el número de pasos de integración.
·
Se escribe para cada
módulo un módulo impulsor o conductor, con el fin de simular la llamada a los módulos, introducir datos
de pruebas y recoger resultados.
·
Se prueba cada módulo
mediante su impulsor.
·
Se eliminan los módulos
impulsores y se sustituyen por los módulos de nivel superior en la jerarquía.
|
|
Herramienta requeridas:
|
JUNIT
|
|
Observaciones:
|
|
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 validación de certificados
digitales, servicios publicados en el tramitador transaccional, servicios de
envío de SMS, servicios de envío de correo electrónico.
|
Objetivo de la Prueba:
|
·
Validar la
interoperabilidad de la solución con sistemas externos.
|
|
Estrategia:
|
·
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
estén disponibles para prueba se desarrollarán sistemas DUMMIE que garanticen
que la integración funcionará.
·
Para los archivos XML
generados por la aplicación se verificará que sean válidos según la
definición de los esquemas xsd definidos para cada uno.
La
verificación de los archivos GEL- XML
la realizará cada desarrollador, aprovechando las características de
la herramienta utilizada para estas pruebas.
·
La autenticación de los
sistemas externos se probará mediante un DUMMIE; el cual llevará el usuario y
contraseña de autenticación frente al sistema de notificaciones. Se probarán
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 conexión
con el tramitador de gobierno en línea se verificará mediante una prueba
técnica utilizando y siguiendo los pasos del Wizard de conexión java con el
tramitador de gobierno en línea; de esta prueba se espera que la conexión
quede establecida.
·
Se expondrá un servidor de
sFTP externo, con el cual se realizarán transferencias masivas de documentos
históricos, se probaran tres escenarios: (Correcto, Incorrecto e incompleto).
|
|
Herramienta requeridas:
|
DUMMIES de los servicios que no están construidos o no
están disponibles:
·
Autenticación
·
Firma Digital
·
Estampado de Tiempo
·
Sistema Emisor
XSD de cada archivo XML generado. XMLBuddy
|
|
Observaciones:
|
|
En
esta prueba se valida que el sistema mantenga su correcta funcionalidad después
de la incorporación de un ajuste, corrección o nuevo requerimiento. Es una
prueba funcional y técnica que valida que el sistema siga funcionando
perfectamente después de que las correcciones sean aplicadas.
La
prueba funcional es un proceso para procurar encontrar discrepancias entre el
software desarrollado y la especificación funcional. La prueba funcional
normalmente es una actividad de caja negra. Esta prueba permite validar:
·
Los procesos y reglas de
negocio establecidas,
·
Que se cumplan los
requerimientos funcionales establecidos
En
esta prueba se validan los Casos de Uso que fueron aprobados por el cliente, y
a partir de ellos se diseñan 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.
|
Objetivo de la Prueba:
|
Se asegura el trabajo apropiado de los
requisitos funcionales, Incluyendo la navegación, entrada de datos,
procesamiento y obtención de resultados.
|
|
Estrategia :
|
·
Validación y ejecución de
Set de Pruebas y escenarios definidos, teniendo en cuenta flujo normal y flujos
alternativos, usando datos validos e inválidos para verificar lo siguiente:
o Los
resultados esperados ocurren cuando se usan datos validos.
o Se
despliegan mensajes de error cuando se usan datos inválidos.
o Cada
regla de negocio es propiamente aplicada.
o Realizar
set de pruebas de los requerimientos mínimos para el adecuado funcionamiento
de la aplicación
|
|
Herramientas Requeridas:
|
·
HTTPUNIT cuando aplique
·
Formato de casos de prueba
funcionales
|
|
Observaciones:
|
Para el reporte de incidencias se
utilizará una herramienta para el
registro y seguimiento.
|
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 página
web, una interfaz de usuario,
un documento o un dispositivo.
Las
pruebas de usabilidad consisten
en seleccionar a un grupo de usuarios de
una aplicación y
solicitarles que lleven a cabo las tareas para las cuales fue diseñada, en
tanto el equipo de diseño, desarrollo y otros involucrados toman nota de la
interacción, particularmente de los errores y dificultades con las que se
encuentren los usuarios.
No
es necesario que se trate de una aplicación completamente terminada, pudiendo
tratarse de un prototipo
|
Objetivo de la Prueba:
|
·
Validar el grado de
usabilidad empírico del sistema.
·
El grado de usabilidad se
medirá en tres aspectos clave:
o Facilidad
de aprendizaje: facilidad con la que nuevos usuarios desarrollan una
interacción efectiva con el sistema o producto.
o Flexibilidad:
relativa a la variedad de posibilidades con las que el usuario y el sistema
pueden intercambiar información.
o
Robustez: es el nivel de
apoyo al usuario que facilita el cumplimiento de sus objetivos.
|
|
Estrategia :
|
·
Se usarán cuatro métricas
principales para medir la usabilidad del sistema
o Exactitud:
Número de errores cometidos por los sujetos de prueba y si estos fueron
recuperables o no al usar los datos o procedimientos adecuados.
o Respuesta emocional:
Cómo se siente el usuario al terminar la tarea (bajo tensión, satisfecho,
molesto, etcétera).
·
Estas métricas será
implementadas para cada uno de los aspectos clave señalados en el objetivo de
la prueba.
·
La forma de evaluación
será mediante el uso de encuestas; donde cada pregunta evaluará un aspecto
clave de usabilidad y aportará valor a una o varias métricas dentro del
aspecto clave evaluado.
·
Las encuestas se
realizarán a los usuarios utilizando los prototipos del sistema; para así
poder realizar cambios de forma temprana al diseño de la capa de
presentación.
|
|
Herramientas Requeridas:
|
·
Encuesta
·
Prototipos del sistema.
|
|
Observaciones:
|
|
Estas pruebas tienen dos enfoques:
·
Pruebas de seguridad de la
aplicación; 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
aplicación están habilitados para accederla.
|
Objetivo de la Prueba:
|
·
Que los usuarios están
restringidos a funciones específicas o su acceso está limitado únicamente a
los datos que está autorizado a acceder.
·
Que solo aquellos usuarios
autorizados a acceder al sistema son capaces de ejecutar las funciones del
sistema.
·
Que el cortafuego oculte
apropiadamente la aplicación.
·
Que los puertos clave solo
puedan ser accedidos de la forma establecida para su acceso.
·
Que los puertos
restringidos efectivamente no se encuentren accesibles.
|
|
Estrategia :
|
·
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 específicas
para cada tipo de usuario.
·
Modificar tipos de usuarios
y volver a ejecutar las pruebas.
|
|
Herramientas Requeridas:
|
·
Nessus
·
Pruebas funcionales de
seguridad.
|
|
Observaciones:
|
Para el reporte de incidencias se
utilizará una herramienta para el
registro y seguimiento.
|
El
propósito de esta prueba es establecer y mantener la integridad de los
productos de software a través del ciclo de vida del proceso del mismo. Esta
prueba implica la identificación de la Configuración del software en puntos
dados en el tiempo, el control sistemático de los cambios en la Configuración y
el mantenimiento de la integridad y trazabilidad de la Configuración a través
del ciclo de vida del software.
|
Objetivo de la Prueba:
|
Validar la integridad de los productos
de software.
|
|
Estrategia :
|
·
Validación y ejecución de
Set de Pruebas que representen un ciclo del proceso de negocio principal de
principio a fin.
·
Validación de la
integridad de la configuración de todos los sistemas involucrados en puntos
datos en el tiempo.
·
Realizar trazabilidad de
los cambios de configuración realizados para puesta a punto.
|
|
Herramientas Requeridas:
|
·
HTTPUNIT
|
|
Observaciones:
|
Para el reporte de incidencias se
utilizará una herramienta para el
registro y seguimiento.
|
Estas
pruebas aseguran que el software pueda recuperarse a fallas de hardware,
software o mal funcionamiento de la red sin pérdida de datos o de integridad de
los datos.
El
objetivo de esta prueba es verificar que los procesos de recuperación (manual o
automáticos) 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:
·
Interrupción de energía al
cliente
·
Interrupción de energía al
servidor
·
Interrupción de
comunicaciones mediante los servidores de la red
·
Interrupción de comunicación
o pérdida de energía de los discos del servidor o con los controladores
·
Ciclos incompletos (procesos
de filtro de datos interrumpidos, procesos de sincronización de datos interrumpidos)
|
Objetivo de la Prueba:
|
·
Validar la capacidad de
recuperación a fallas de:
o Hardware
o Software
o Mal
funcionamiento de Red.
|
|
Estrategia :
|
·
Interrumpir la energía del
cliente: apagar el PC.
·
Interrumpir la energía del
servidor: simular o iniciar el proceso de apagado del servidor.
·
Interrupción por medio de
los servidores de red: simular o iniciar la pérdida de comunicación con la
red
·
(desconectar físicamente
la comunicación o apagar el servidor de red o router
·
Interrumpir la
comunicación o quitar la energía de los discos del servidor o sus
controladores: simular o
·
eliminar físicamente la
comunicación con uno o más controladores de disco o los discos.]
·
Una vez que se lograron o
simularon estas condiciones, se deben invocar los procedimientos de
·
recuperación.
|
|
Herramientas Requeridas:
|
·
Ninguna
|
|
Observaciones:
|
Para el reporte de incidencias se
utilizará una herramienta para el
registro y seguimiento.
|
El
objetivo de las pruebas de aceptación es validar que la solución desarrollada
cumpla con el funcionamiento esperado y permitir al usuario de dicho sistema
determine su aceptación, desde el punto de vista de su funcionalidad y de su
rendimiento. Estas pruebas son realizadas por el cliente, donde comprueba que
el sistema cumple con lo definido y se obtiene la conformidad del cliente. Esta
prueba se realiza mediante el proceso de validación de caja negra.
Estas
pruebas corresponden a la ejecución de las siguientes pruebas por parte de los
usuarios funcionales o cliente:
·
Pruebas Funcionales.
·
Pruebas de Usabilidad.
·
Pruebas de Configuración
De acuerdo al
tipo de pruebas ejecutadas puede que el entregable del mismo sea diferente, en
el siguiente cuadro se señalan los diferentes entregables por tipo de prueba.
|
TIPO DE PRUEBAS
|
ENTREGABLES
|
|
Pruebas Unitarias
|
|
|
Pruebas de Sistema
|
|
|
Pruebas de Integración
|
|
|
Pruebas de Interoperabilidad
|
|
|
Pruebas de Regresión
|
|
|
Pruebas Funcionales
|
|
|
Pruebas de Usabilidad
|
|
|
Pruebas de Seguridad
|
|
|
Pruebas de Configuración
|
|
|
Pruebas de Recuperación a Fallas
|
|
|
Pruebas de Aceptación
|
|
Los
entregables de las pruebas serán elaborados de acuerdo a la estructura del
entregable “Informe de Pruebas” solicitados en los términos de referencia para
la fase de desarrollo y pruebas.
|
TIPO DE
PRUEBAS
|
TIPO DE PRUEBA
|
|
Pruebas Unitarias
|
Automáticas
|
|
Pruebas de Sistema
|
Automáticas
|
|
Pruebas de Integración
|
Automáticas
|
|
Pruebas de Interoperabilidad
|
Automáticas
|
|
Pruebas de Regresión
|
Automáticas
y Manuales
|
|
Pruebas Funcionales
|
Manuales
|
|
Pruebas de Usabilidad
|
Manuales
|
|
Pruebas de Seguridad
|
Automáticas
y Manuales
|
|
Pruebas de Configuración
|
Automáticas
y Manuales
|
|
Pruebas de Recuperación a Fallas
|
Automáticas
y Manuales
|
|
Pruebas de Aceptación
|
Manuales
|
|
TIPO DE PRUEBAS
|
TECNICA DE EJECUCIÓN
|
HERRAMIENTAS A UTILIZAR
|
|
Pruebas Unitarias
|
El uso de
JUnit normalmente involucra los siguientes pasos:
a. Crear una subclase de junit.framework.TestCase.
b. Opcionalmente sobrescribir el método setUp() que será invocado
en la inicialización 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 método tearDown(). Método 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 atrás lo probado, por
ejemplo cuando el caso de prueba involucre la actualización de datos en una
base de datos relacional.
d. Adicionar métodos de prueba a la clase. Note que no
necesitamos implementar ninguna interface, pues JUnit usa el paquete
reflection del java para detectar automáticamente métodos test. Dichos
métodos son reconocidos por su asignatura, la cual debe tener la forma public
void test<Descripcion>(), además pueden lanzar cualquier exception.
|
JUNIT
|
|
Pruebas de Sistema
|
Las pruebas
del sistema tal como están concebidas para el proyecto de notificaciones
electrónicas involucra los siguientes pasos:
a. Selección de los casos de uso para los que se probará Carga,
volumen, estrés, concurrencia. Estos casos de uso corresponderán al 10% del
total de casos de uso y su elección contará con la aprobación del Programa
Agenda de Conectividad e Interventoría.
b. Ejecución de las pruebas de Carga, volumen, estrés,
concurrencia mediante la herramienta seleccionada.
c. Recopilación de resultados.
d. Reporte de los defectos encontrados según las pruebas. (A
través de la herramienta de gestión de incidencias)
e. Asignación de la incidencia. (A través de la herramienta de
gestión de incidencias).
f. Corrección de la incidencia.
g. Repetición de la prueba.
|
JMETER
|
|
Pruebas de Integración
|
Las pruebas
del integración tal como están concebidas para el proyecto de notificaciones
electrónicas involucra los siguientes pasos:
a. Selección de los componentes y/o servicios para los que se
probará integración con los componentes y/o servicios que tienen relación
directa. Estos componentes y/o servicios corresponderán al 10% del total de
componentes y/o servicios y su elección contará con la aprobación del
Programa Agenda de Conectividad e Interventoría.
b. Ejecución de las pruebas de integración mediante la
herramienta seleccionada.
c. Recopilación de resultados.
d. Reporte de los defectos encontrados según las pruebas. (A
través de la herramienta de gestión de incidencias)
e. Asignación de la incidencia. (A través de la herramienta de
gestión de incidencias).
f. Corrección de la incidencia.
g. Repetición de la prueba.
|
GRINDER
|
|
Pruebas de Interoperabilidad
|
Las pruebas
de interoperabilidad tal como están concebidas para el proyecto de notificaciones
electrónicas involucra los siguientes pasos:
a. Definición de la lista de servicios a probar.
b. Definición de DUMMIES a construir.
c. Construcción de DUMMIES.
d. Ejecución de la prueba de interoperabilidad contra los
servicios y DUMMIES definidos.
e. Recopilación de resultados.
f. Reporte de los defectos encontrados según las pruebas. (A
través de la herramienta de gestión de incidencias)
g. Asignación de la incidencia. (A través de la herramienta de
gestión de incidencias)
h. Corrección de la incidencia.
i. Repetición de la prueba.
|
·
Servicios
del Enrutador transaccional
·
DUMMIES
·
XMLBuddy
|
|
Pruebas de Regresión
|
Las pruebas
de regresión tal como están concebidas para el proyecto de notificaciones
electrónicas involucra los siguientes pasos:
a. Repetición
de las pruebas funcionales y de sistema que estén involucradas en los cambios
realizados al sistema.
b. Recopilación de resultados.
c. Reporte de los defectos encontrados según las pruebas. (A
través de la herramienta de gestión de incidencias)
d. Asignación de la incidencia. (A través de la herramienta de
gestión de incidencias)
e. Corrección de la incidencia.
f. Repetición de la prueba.
|
·
Casos de Prueba
·
Grinder
|
|
Pruebas
Funcionales
|
Las pruebas funcionales normalmente involucra los siguientes
pasos:
a.
Crear los casos de prueba mediante el formato establecido para
ellos.
b.
Ejecución de los casos de prueba con forme las funcionalidades
van siendo liberadas para pruebas.
c.
Reporte de los defectos encontrados según las pruebas. (A
través de la herramienta de gestión de incidencias)
d.
Asignación de la incidencia. (A través de la herramienta de
gestión de incidencias)
e.
Corrección de la incidencia.
f.
Repetición de la prueba.
|
·
Casos
de Prueba
|
|
Pruebas
de Usabilidad
|
Las pruebas de usabilidad tal como están concebidas para el
proyecto de notificaciones electrónicas (uso de prototipado) involucra los
siguientes pasos:
a.
Elaboración de prototipos.
b.
Elaboración de encuestas de usabilidad.
c.
Evaluación de prototipos mediante la aplicación de encuestas
de usabilidad a usuarios comunes.
d.
Recopilación de datos de la encuesta.
e.
Compilación y análisis de resultados de encuestas de
usabilidad.
|
·
Prototipos
·
Encuesta
de usabilidad
|
|
Pruebas
de Seguridad
|
Las pruebas de seguridad tal como están concebidas para el
proyecto de notificaciones electrónicas involucra los siguientes pasos:
a.
Elaboración de casos de prueba funcionales de seguridad.
b.
Elaboración de casos de prueba automáticos de seguridad.
c.
Configuración de ambiente de pruebas.
d.
Ejecución de pruebas funcionales de seguridad.
e.
Ejecución de casos automáticos de pruebas de seguridad con el
uso de las herramientas de evaluación y ataque.
f.
Recopilación de resultados.
g.
Reporte de los defectos encontrados según las pruebas. (A
través de la herramienta de gestión de incidencias)
h.
Asignación de la incidencia. (A través de la herramienta de
gestión de incidencias)
i.
Corrección de la incidencia.
j.
Repetición de la prueba.
|
·
NESSUS
·
Casos de prueba funcionales de seguridad.
|
|
Pruebas de Configuración
|
Dada la metodología RUP, al ser un
desarrollo iterativo e incremental se efectuaran pruebas de instalación a
medida que sean liberadas las diferentes versiones del aplicativo.
Las pruebas incluirían:
a. Elaboración de listas de chequeo de instalación de sistema
operativo, base de datos, servidor de aplicaciones y cualquier otro
componente del sistema.
b. Ejecución de la instalación según la lista de chequeo.
c. Recopilación de resultados.
d. Reporte de los defectos encontrados según las pruebas. (A
través de la herramienta de gestión de incidencias)
e. Asignación de la incidencia. (A través de la herramienta de
gestión de incidencias)
f. Corrección de la incidencia.
g. Repetición de la prueba.
|
·
Listas de chequeo para
instalación.
|
|
Pruebas de Recuperación a Fallas
|
Las pruebas
de recuperación a fallas normalmente involucra los siguientes pasos:
a. Crear los casos de prueba de recuperación.
b. Ejecución de los casos de prueba.
c. Reporte de los defectos encontrados según las pruebas. (A
través de la herramienta de gestión de incidencias)
d. Asignación de la incidencia. (A través de la herramienta de
gestión de incidencias)
e. Corrección de la incidencia.
f. Repetición de la prueba.
|
|
|
Pruebas de Aceptación
|
Las pruebas
de recuperación a fallas normalmente involucra los siguientes pasos:
a. Ejecución de una muestra de las pruebas funcionales, de carga,
de configuración por parte del Programa Agenda de Conectividad e Interventoría.
b. Reporte de los defectos encontrados según las pruebas. (A
través de la herramienta de gestión de incidencias)
c. Asignación de la incidencia. (A través de la herramienta de
gestión de incidencias)
d. Corrección de la incidencia.
e. Repetición de la prueba.
|
·
Grinder.
·
Casos de prueba
Funcionales.
·
Listas de Chequeo.
|
No hay comentarios.:
Publicar un comentario