Plan de Pruebas

Instituto Profesional Santo Tomás.Escuela de Informática.

Gestor de HorarioAnalisis/Implementacion Plan de Pruebas

Versión 1.0

Gestor de Horario. Version: 1.0<Iteration/ Master> Test Plan Fecha: 31/05/2011

PLAPRU_GESHOR

Historial de Revisiones

Fecha Versión Descripción Autor

31/05/2011 1.0 Creación de documento Plan de Pruebas Gestor de Horario.

Jocelyn Verdugo.

Confidential <Company Name>, 2023


PLAPRU_GESHOR

Índice

1. Introducción 5

1.1 Propósito 51.2 Alcances 51.3 Destinatarios 51.4 Documento de Terminología y Acrónimos 61.5 Referencias 61.6 Estructura del Documento 6

2. Pruebas de Evaluación y Motivación 6

2.1 Antecedentes 72.2 Evaluación de la Misión 72.3 Pruebas Motivadoras 7

3. Metas de las Pruebas 7

4. Esquema de Planificación de las Pruebas 8

4.1 Ensayo de lo que incluyen las Pruebas 84.2 Esbozo de Otros Candidatos para su posible inclusión 84.3 Esquemas de Pruebas de Exclusiones 8

5. Pruebas de Enfoque 8

5.1 Ideas de Pruebas Iniciales de Catálogos y Otras Fuentes de Referencia 105.2 Tipos de Pruebas Técnicas 10

5.2.1 Pruebas de Datos e Integridad de Base de Datos 105.2.2 Pruebas de Función 115.2.3 Pruebas del ciclo del Negocio 115.2.4 Pruebas de Interfaz de Usuarios 125.2.5 Rendimientos de los Perfiles 125.2.6 Pruebas de Carga 135.2.7 Pruebas de Stress 135.2.8 Pruebas de Volúmen 145.2.9 Seguridad y Pruebas de Control de Acceso 145.2.10 Pruebas de Reconexión y Recuperación 165.2.11 Configuración de las Pruebas 165.2.12 Pruebas de Instalación 18

6. Criterios de Entrada y Salida 19

6.1 Plan de Pruebas 196.1.1 Test Plan de entrada Criterios 196.1.2 Criterios de salida plan de pruebas 196.1.3 Suspensión y reanudación de criterios 20

6.2 Ciclos de Prueba 206.2.1 Criterios para las Entradas de Ciclo de Pruebas 206.2.2 Criterios para la Finalización de Ciclo de Pruebas 206.2.3 Ciclo de término anormal 20



PLAPRU_GESHOR

7. Entregables 20

7.1 Resumen de las pruebas de evaluación 207.2 Presentación de los Informes sobre la cobertura de las Pruebas 207.3 Calidad Percibida de los Reportes 207.4 Registro de Incidentes y de Cambios Requeridos 217.5 Trabajo Adicional a los Productos 21

7.5.1 Resultado Detallado de las Pruebas 217.5.2 Agregar Scripts Automáticos a las Pruebas Funcionales 21Se deberán agregar los scripts de las funciones que se agregaran al sistema para mejorarlo, los que se usaron en cada prueba y una descripción de que es lo que hace o que es lo que corrige dentro del sistema. Ademas el código fuente deberá llevar líneas de texto en las que se especifique cada acciones y en caso de variables a que corresponden. 217.5.3 Directrices para las Pruebas 21

8 Pruebas del Flujo de Trabajo 21

9 Necesidades de Ambiente 22

9.1 Hardware Básico para el Sistema 229.2 Pruebas Básicas de los Elementos del Software 229.3 Herramientas de Producción y de Soporte 22

10 Responsabilidades, Dotación de Personal y Necesidades de Entrenamiento 23

10.1 Personas y Roles 2310.2 Dotación de personal y Necesidades de Capacitación 25Se mostraran pantallas de como deben de realizarse las operaciones dentro del sistema, detalladas paso a paso según el perfil del usuario. 25

11. Iteraciones e Hitos 25

12. Riesgos, Dependencias, Dependencies, Supuestos y Limitaciones 26



PLAPRU_GESHOR

<Iteration/ Master> Test Plan1. Introducción

1.1 Propósito

Este Plan de Pruebas para el sistema Gestor de Horario tiene como propósito los siguientes objetivos:

- Identificar la información existente de las especialidades, profesores y asignaturas que deben ser otorgadosal Horario Semestral.

- Listar los principales requisitos a probar para la elaboración del proyecto.- Definir las estrategias de prueba que deben emplearse.- Identificar los recursos necesarios que pueden requerirse.- Implementar la construcción del proyecto para cualquier escuela perteneciente a la corporación Santo

Tomás.- Solucionar la problemática actual de creación horaria, ya que que debe realizarse de forma manual por los

jefes de carrera de las distintas escuelas de la corporación.

1.2 Alcances

El alcance será explicado punto a punto, mencionando los que delimitan este para evitar malas interpretaciones o dejar vacíos que puedan prestarse para malos entendidos para las partes involucradas.

El prototipo grafico es presentado de manera que se desplegará el sistema una vez implementado, el cliente es quien determina las características de esta, entregando las políticas necesarias para cumplir este proceso por ello se realizarán los siguientes tipos de pruebas Técnicas:

Pruebas de Datos e Integridad de Base de Datos.Pruebas de Función.Pruebas del ciclo del Negocio.Pruebas de Interfaz de Usuarios.Rendimientos de los Perfiles.Pruebas de Carga.Pruebas de Stress.Pruebas de Volúmen.Seguridad y Pruebas de Control de Acceso.Pruebas de Reconexión y Recuperación.Configuración de las Pruebas.Pruebas de Instalación.

1.3 Destinatarios

Este Documento va dirigido a las personas que desempeñan los roles jefes de carrera pertenecientes a las distintas escuelas de corporación santotomas.



PLAPRU_GESHOR

1.4 Documento de Terminología y Acrónimos

A continuación se describen los términos y acrónimos utilizados en el proyecto Gestor de Horario, con el objeto de aclarar y quitar ambigüedades que pueden generar ciertos términos.

Aquí (definición de palabras que no entienda el usuario).

Script: Archivo de órdenes o archivo de procesamiento por lotes es un programa usualmente simple.Algoritmo: Conjunto pre-escrito de instrucciones o reglas bien definidas, ordenadas y finitas que permite realizar una actividad mediante pasos sucesivos que no generen dudas a quien deba realizar dicha actividad.Proceso de Negocio: Tareas relacionadas lógicamente llevadas a cabo para lograr un resultado de negocio definido.

1.5 Referencias

Los siguientes son documentos en los que se apoya este plan de pruebas:

Informe general Gestor de Horario (casos de usos). Documento Rup tspln

1.6 Estructura del Documento

Documentos N°. Versión DisponibilidadRevisado/Aprobado

Observaciones

Plan de Pruebas 1.0 SI



PLAPRU_GESHOR

2. Pruebas de Evaluación y Motivación

2.1 Antecedentes

Como resultado de la planificación y análisis desarrollado para la problemática actual de la creación horaria, se obtuvo una arquitectura de solución para el sistema de horario y un plan de tareas a desarrollar para solucionar la problemática planteada. Por ello se efectuo la planificación de pruebas con el fin de validar que la solución y sus funcionalidades son consistentes y acordes a las expectativas de la institución.

2.2 Evaluación de la Misión

Las pruebas tienen como finalidad verificar que la solución planteada satisface los requerimientos encontrados en nuestro Sistema. Estas pruebas también tienen como finalidad verificar la calidad de la solución en su primera versión.

Encontrar la mayor cantidad de errores posibles.

Encontrar problemas importantes, evaluar la calidad de los riesgos.

Evaluar sobre la percepción de los riesgos del Proyecto.

Certificar el estándar.

Verificación de la especificación (requisitos, diseño o reclamos).

Asesorar las Pruebas.

Proceso de Cumplir con las normas.

2.3 Pruebas Motivadoras

- Obtener un grado de calidad en los entregables del proyecto.- Validar el cumplimiento de los requerimientos funcionales y no funcionales.- Asegurar la aplicación de estándares.

3. Metas de las PruebasLa siguiente lista identifica aquellos elementos (casos de uso, requisitos funcionales y no funcionales) que han sido identificados como objetivos de las pruebas y que serán sometidos a prueba:

Administrar proyecto. Identificar requerimientos de las pruebas. Generar informe de consultas sobre disponibilidad de profesores, asignaturas, jornadas, secciones, días y

salas de la especialidad para el Horario. Generar informe de asignación de profesores, asignaturas, jornadas, secciones, días y salas de la

especialidad para el Horario. Verificar conflicto de Horario. Revisar informe de modificaciones que se realizarón en el horario. Programar Horario. Consultar proyecto terminado.



PLAPRU_GESHOR

Definir proyecto. Validación de Proyecto Consultar horario. Generar Reportes de horario.

4. Esquema de Planificación de las PruebasLa planeación efectiva del proyecto depende de la planeación detallada de su avance, anticipado problemas que puedan surgir y preparando con anticipación soluciones a ellos. El administrador del proyecto es responsable de la planeación desde la definición de requisitos hasta la entrega del sistema terminado.

4.1 Ensayo de lo que incluyen las Pruebas

Los tipos de pruebas que son necesarios para las diferentes etapas de la implementación de la solución y, específicamente, las responsabilidades del grupo de trabajo de pruebas en cada tipo de prueba.

La estrategia usada para la prueba en cada tipo de prueba.

Las distintas funciones de equipo para los miembros del grupo de trabajo de pruebas.

Las actividades de requisitos necesarias para cada miembro del equipo.

4.2 Esbozo de Otros Candidatos para su posible inclusión

Otras pruebas que podrían ser incluidas son:

- Pruebas de manejo de requerimientos que tendrían como objetivo validar el cumplimiento de los requerimientos planteados en el proyecto.

- Pruebas de manejo de errores, que tendrían el objetivo de validar la forma en cómo se están controlando las excepciones arrojadas por los algoritmos del sistema.

4.3 Esquemas de Pruebas de Exclusiones

Como no se tiene conocimiento del sistema que soportan los institutos en la actualidad ni se conoce el entorno en el que se encuentra funcionando, no se harán los siguientes tipos de pruebas:

Pruebas en paralelo, que tendrían como objetivo comparar el comportamiento y funcionalidad de otros proyectos similares.Estas pruebas no ayudan a lograr la meta de l proyecto de evaluación.

No hay suficientes recursos como para llevar a cabo estas pruebas.

5. Pruebas de Enfoque Las pruebas se harán en las siguientes categorías:

a) Usabilidadb) Unitariasc) Funcionalidad, de acuerdo a los procesos de negocios vigentesd) Prueba de demanda “on line” (por ejemplo inscripción de asignaturas(especialidad)e) Rendimiento.f) Integración, con los sistemas en produccióng) Carga masiva de datos (ficha prospectos)



PLAPRU_GESHOR

h) Recuperación frente a una caídai) Seguridadj) Robutezk) Aceptación

a) Pruebas de usabilidadEstas pruebas están orientadas a probar la usabilidad del sistema. Esto se refiere a probar la facilidad con lo cual los usuarios de una aplicación la pueden operar. En nuestro caso, los objetivos principales serán:Determinar si los usuarios pueden utilizar las distintas funcionalidadesdel sistema sin mayores complicaciones, es decir, ubicar rápidamente lafunción que desean ejecutar.Determinar si la interfaz es lo suficientemente intuitiva tanto para usuarios que tienen experiencia como para aquellos que no la tienen.Determinar si la aplicación requiere modificaciones para que cumpla con los objetivos anteriores.

b) Pruebas unitariasPretenden probar que las funciones (unitarias) dentro del sistema cumplan las especificaciones y tienen el comportamiento esperado.

c) Pruebas funcionalesSe denominan pruebas funcionales a las pruebas de software que tienen por objetivo probar que el sistema implementado cumpla con lafunciones.Básicamente el enfoque de este tipo de prueba se basa en el análisis de los datos de entrada y en los de salida (datos que ingresa el usuario para el horario; como ingresar profesores con sus respectivas asignaturas, sección, sala, dia y jornada para la especialidad) y asi mostrar las asignaciones de estas como reporte del horario).

d) Prueba de demanda “on line” (por ejemplo inscripción de asignaturas semestral de la especialidad e inscripción del profesor con su respectiva asignatura.

e) Rendimiento A veces es importante el tiempo de respuesta, u otros parámetros de r e n d i m i e n t o . C u a n d o e l s i s t e m a d e b e procesar tantos datos, o cuánta memoria consume, o cuánto espacio en disco utiliza, o cuántos datos transfiere por un canal de comunicaciones. Para todos estos parámetros es importante conocer cómo evolucionan alvariar la dimensión del problema (por ejemplo, al duplicarse el volumen dedatos de entrada).

f) Prueba de integración Las pruebas de integración se refieren a la prueba o pruebas de todos los elementos unitarios, que comprueban la compatibilidad y funcionalidad de las interfaces entre las distintas ‘partes’ que componen un sistema, estas ‘partes’pueden ser, aplicaciones individuales, aplicaciones cliente/servidor,aplicaciones web, etc. Se realizan en el ámbito una vez que se han aprobadolas pruebas unitarias.

g) Carga masiva de datos (por ejemplo anuncios)

h) Recuperación frente a caídas

i) SeguridadSe valida la funcionalidad del sistema para proveer una estructura de permisos y acceso según sea el perfil del usuario.



PLAPRU_GESHOR

j) Prueba de robustezDeterminan la capacidad del sistema para no soportar entradas incorrectas.Se prueba la capacidad del sistema para salir de situaciones problematicas provocadas por errores en el suministro de datos.

k) Pruebas de AceptaciónSon las que harán de acuerdo a los criterios de aceptación, determinar que el sistema cumpla con lo deseado para obtener la conformidad del cliente. Estas pruebas las realiza el cliente. Son básicamente pruebas funcionales, sobre el sistema completo.

5.1 Ideas de Pruebas Iniciales de Catálogos y Otras Fuentes de Referencia

Como principal objetivo se usan técnicas para apagar el impacto de los defectos del software en la operación de la organización.En el sector conflicto de horario esta la clase de errores o impactos que son aún más críticos que se encuentra en el sistema, como referencia se va a usar el manejo de información utilizando las pruebas técnicas, como ejemplo prueba de carga para ver si es factible la disponibilidad de asignaturas y profesores para la especialidad, además utilizar la prueba de stress para ver si el sistema responde adecuadamente con la carga de horario esperada.

5.2 Tipos de Pruebas Técnicas

5.2.1 Pruebas de Datos e Integridad de Base de DatosSe realizara una Investigación adicional en el sistema de gestión de bases de datos (DBMS), debe

ser realizado para identificar las herramientas y técnicas que puedan existir para apoyar las pruebas señaladas en el siguiente cuadro.

Objetivo de la Técnica: Ejercicios de acceso por ejemplo: La consulta de horario, esta base de datos se podrá acceder y observar el funcionamiento incorrecto del comportamiento objetivo o corrupción de los datos consultados.

Técnica: Inspeccionar los datos consultados o ingresados en la base de datos para asegurar que se encuentren en perfecto funcionamiento a la hora de ser procesados.

Resultados Esperados: Observación y características específicas de los resultados, lo cual indican el éxito o el fracaso de la consulta realizada.

Herramientas Requeridas Pruebas de Herramientas de Comandos automáticos

Configurador y restaurador de imágenes Base

Herramientas de Respaldo y Recuperación

Instalación de herramientas de seguimiento (registro, disco duro, CPU, memoria, etc.)

Utilitarios y Herramientas de Base de Datos y SQL

Criterios de Éxito: Resultado esperado del usuario en la consulta o gestión realizada.



PLAPRU_GESHOR

Consideraciones Especiales: Los Administradores del sistema podrán ingresar o modificar los datos directamente en las bases de datos.

Los procesos podrán ser invocados manualmente.

5.2.2 Pruebas de FunciónEl objetivo de estas pruebas es para comprobar la correcta aceptación procesamiento y

recuperación de los datos. Este tipo de pruebas se basa en técnicas donde verifica la interacción de la interfaz gráfica de usuario (GUI) y el análisis de las salidas.

Objetivos de las Técnicas Navegación, entrada de datos y consultas.

Técnicas: Realizar cada procedimiento, para verificar su correcto funcionamiento, y expectativas del usuario.

Resultados Esperados: Observar con precisión los procesos de prueba, siendo los resultados esperados se auto-verifiquen, permitiendo hacer una evaluación inicial de pruebas o el fracaso de las gestiones realizadas.

Herramientas Requeridas: Configurador y restaurador de imagines base

Herramientas de respaldo y recuperación

Herramientas de Monitoreo e Instalación (registro, Disco Duro, CPU, memoria, y así sucesivamente)

Criterios de Éxito: Todos los escenarios y claves características para los casos de uso

Consideraciones Especiales: Temas que tienen un impacto en la implementación y ejecución de las pruebas de función.

5.2.3 Pruebas del ciclo del NegocioLas pruebas del ciclo de negocio afectan directamente a la capa de negocio del proyector Gestor de horario

las cuales están encargadas de verificar el comportamiento con el tiempo de dicha capa.

Objetivo de las Técnicas: En esta prueba tenemos como objetivo probar el funcionamiento del ciclo de negocio en un tiempo definido.



PLAPRU_GESHOR

Técnicas: La prueba simula ciclos de negocio, en los que haremos;

Pruebas que simulen ciclos de negocios simultáneamente para ver la capacidad de de usuarios que interactual con el en un periodo de tiempo

En estas pruebas se ocuparan datos validos e invalidos para ver como reaccionar los ciclos al momento de ingresar datos invalidos y verificar que las reglas de negocio actúen satisfactoriamente.

Resultados Esperados: Los resultados esperados pueden ser de estado exitoso o fallido los resultados fallidos se rescataran para poder llegar a una solución y que no ocurra nuevamente.

Herramientas Requeridas: Las pruebas necesitan las siguientes herramientas:

Herramientas que autogeneren datos.

Herramienta de respaldo.

Criterio de Éxito: Estas técnicas las soportan todos los ciclos de la capa de negocio

Consideraciones Especiales: Al momento que autogeneren datos será necesaria una herramienta de respaldo por alguna eventualidad.

5.2.4 Pruebas de Interfaz de Usuarios La Interface de Usuarios (IU) verifica la interacción de los usuarios con el sistema, su perfecto

funcionamiento a través de la web, donde las consultas y administración del sistema se lleven a cabo con éxito.

El IU asegura que dentro de las funciones cumpla con los objetivos como se esperaba y se ajusten a las normas de la Institución.

Técnicas de los Objetivos: La Navegación a través del objetivo de la prueba, se reflejan las necesidades y las funciones del gestor de horario, incluyendo las teclas de tabulación, los movimientos del ratón, teclas de acelerador.

Técnicas: Crear o modificar las pruebas por cada opción que toma el usuario, para verificar la apropiada navegación en las consultas y gestiones que realiza.

Resultados Esperados: Los resultados esperados serán Auto-Verificados, permitiendo hacer una evaluación de las pruebas realizadas.

Herramientas Requeridas: Interacción Usuario-Sistema

Criterios para el Éxito.: Conformidad del usuario, de acuerdo a su gestión o consulta.

5.2.5 Rendimientos de los PerfilesEstas pruebas están orientadas a medir la velocidad de las respuestas y las transacciones que se efectúan

hacia el gestor de horario.



PLAPRU_GESHOR

Objetivos de las Técnicas: Probar el rendimiento de velocidad de respuesta y transacción de los distintos perfiles.

Técnica: Hacer varias transacciones para medir velocidad de respuesta de los disintos perfiles del sistema.

Resultado Esperado: Los resultados posibles en esta prueba pueden ser de éxito o fracaso viendo el tiempo de respuesta si es bueno sera de éxito pero si es muy lento sera de fracaso y debera haber alguna modificación en las iteraciones o en el ancho de banda.

Herramientas Requeridas: Las herramientas para esta prueba serán:

Herramientas de comandos automaticos.

Herramientas para medir rendimiento de perfiles.

Criterios para el Éxito: Las técnicas soportadas para las pruebas:

Transacciones de un solo usuario para asi tener transacciones sin fallas.

Consideraciones Especiales: Crear un usuario virtual para poder efectuar el simulador y hacer las transacciones.

5.2.6 Pruebas de CargaEsta prueba se encarga de cargar al máximo la transacción y medir la respuesta del sistema a dicha transacción.

Objetivo de la Técnica: Medir el rendimiento de las transacciones lógicas del negocio.

Técnica: En esta prueba haremos:

Que las transacciones utilizen la carga máxima para asi ver como reacciona el sistema.

Las cargas se realizar en un estimado de tiempo continuo y estas siempre serán cargas máximas.

Resultado Esperado: Los resultados pueden ser de carácter exitoso o fallido al momento de ser exitoso o fallido se guardaran automáticamente con un capturador de sucesos y asi poder tener un registro de estos para hacer los cambios correspondientes

Herramientas requeridas: Las herramientas utilizadas serán:

Herramientas de automatización de procesos.

Herramientas de autogeneración de datos.

Herramienta para cargar transacciones.

Criterios de Éxito: La prueba puede ser exitosa si trabajamos con las transacciones adecuadamente y asi no tener ninguna posible falla.

Consideraciones especiales: Para poder llevar a cabo esta prueba se necesita tener un usuario que pueda dedicarse a hacer estas transacciones.

5.2.7 Pruebas de StressEl Test de rendimiento implementado y ejecutado para cuando el sistema falla en condiciones de bajos



PLAPRU_GESHOR

recursos, en estas condiciones revela como caen las metas de las pruebas que no están aparentemente bajo condiciones normales.

Objetivo de la Técnica: Verificar las condiciones bajo las cuales el sistema falla para continuar con los siguientes procedimientos.

Poca memoria disponible o no en el servidor.

Técnica: Múltiples usuarios realizando la misma transacción contra la misma información o cantidad.

Resultado Esperado: El resultado esperado serán pruebas de evaluación en procesos que tienen éxito o fracaso.

Herramientas Requeridas:

Automatización de procesos.

Herramientas de Instalación-Monitoreo (registros, disco duro, CPU, memoria, etc.)

Criterio de Éxito: En las aplicaciones realizadas, que el resultado sea exitoso de acuerdo a las pruebas realizadas.

Consideraciones Especiales:

Aumento de la disponibilidad de espacio para las bases de datos.

Sincronizar el acceso de usuarios a los mismos registros.

5.2.8 Pruebas de VolúmenEsta prueba esta encargada de medir el máximo numero de usuarios que puedan hacer transaciones a la vez

y que estas sean soportadas por el sistema.

Objetivo de la Técnica : Esta prueba se encarga de medir el rendimiento del sistema de acuerdo a la cantidad de usuarios que están simultáneamente en el sistema y asi poder dar un aproximado de los usuarios máximos para un buen rendimiento del sistema.

Técnica: Conectar una gran cantidad de usuarios al sistema y hacer varias transacciones para ver como se comporta este.

Resultados Esperados: Los resultados pueden ser exitosos o fallidos estos serultados serán capturados para asi poder tener un registro de estos y ver las fallas para poder remediarlas.

Herramientas Requiridas: Se utilizaran las siguientes herramientas:

Herramientas de automatización de procesos.

Herramientas de autogeneración de datos.

Herramientas para cargar transacciones.

Criterios de Éxito: Para un éxito en la prueba es necesario tener una gran cantidad de usuarios virtuales para poder generar transacciones al sistema y ver como responde este.



PLAPRU_GESHOR


Crear una gran cantidad de usuarios para poder medir el rendimientos y cargar las transacciones con datos reales para no tener problemas con dichas transacciones.

5.2.9 Seguridad y Pruebas de Control de Acceso Dentro de cualquier tipo de sistema debe existir por lo menos el mínimo de seguridad para depositar la confiabilidad a un sistema informático. Dentro de este sistema que es el gestor de horarios existirá el tipo de seguridad pertinente. Dentro del gestor podremos acceder por medio de cuentas de usuario, en donde existirán por lo menos dos tipos, los cuales para acceder a cualquier información deberán estar previamente autenticados.

Seguridad y Pruebas de Control de Acceso, enfocado en dos áreas claves de seguridad:

Nivel de seguridad de la aplicación, incluyendo acceso a los datos o a las funciones del negocio.

Nivel de seguridad, incluyendo registrando dentro de acceso remoto al sistema.

Basado en la seguridad que tu quieres, el nivel de seguridad de la aplicación, asegura que los actors están restringidos para especificar las funciones o los casos de uso, o ellos están limitados en la informaci´ñon que está disponible para ellos. Por ejemplo, para cualquiera puede estar permitido ingresar datos y crear nuevas cuentas, pero solo los adminsitradores pueden borrarla. Si esto es seguridad al nivel de los datos, asegurándose que “usuario tipo uno” puese ver a toda la información de los clientes, incluyendo información financiera, sim embargo “el usurio tipo dos” solo verá la información demografica del mismo cliente.

A nivel de sistema de seguridad garantiza que sólo los usuarios acceso al sistema es capaz de acceder a las aplicaciones y sólo a través de las correspondientes puertas de acceso (gateway).

Objetivos de la Técnica: Dependiendo del comportamiento y las características de los usuarios que utilizaran este sistema se han dividido en dos tipos: usuario general y administrador.

Nivel de seguridad de las aplicaciones: dentro de este tipo de escenario podrá interactuar el usuario general, el cual tendrá acceso a la información que otorgara el sistema, pero no a modificarla.

El nivel de Seguridad: dentro de este nivel solo podrá interactuar el administrador, ya que este tiene acceso a inserta, modifica y eliminar cualquier información.

Técnica: Los usuarios que pueden interactuar con el sistema son dos, estos tienen distintos tipos de permisos sobre el sistema.

Usuario general: este usuario podrá interactuar con el sistema a nivel solo de consulta, es decir, este tendrá acceso a la información que entregará el sistema, pero no podrá hacer ninguna modificación de ella.

Administrador: este usuario también podrá interactuar con el sistema (consulta), pero además podrá modificar, ingresar y eliminar la información que estime conveniente.

Nivel de Seguridad de las Aplicaciones: dentro de este nivel tendrá acceso el usuario general (solo podrá consultar), además tendrá acceso el administrador al cual se le otorgaran permisos de administración.Acceso al nivel de Seguridad:a este nivel solo tendrá acceso el administrador.



PLAPRU_GESHOR

Resultado Esperados: Con el sistema de gestor de horarios se espera alcanzar un alto nivel de seguridad con los datos que se puedan utilizar. Además de proporcionar la mayor confiabilidad en el acceso de los usuarios, tanto con los que tendrán solo la posibilidad de consultar tanto como los que podrán ralizar algún tipo de cambio.

Herramientas Requeridas: Dentro de las herramientas que se utilizaran tendremos:

"Hacker" de seguridad y herramientas de sondeo.

Herramienta administradora para la Seguridad de los Sistemas Operativos.

Criterio del Éxito: Dentro de las posibilidades de seguridad para ser aplicadas en el caso del acceso de cualquier tipo de actores son variadas. En este caso utilizaremos alguna que nos permita seguridad al logearse.

Consideraciones Especiales: En el caso del tipo de red que utilizaremos puede que no dependa del sistema en sí, esto tendrá que ver con el tipo de administración de red. En tal caso mejor dirigirse a soporte técnico.

5.2.10 Pruebas de Reconexión y RecuperaciónLas conexiones, o más bien el tipo de red no están ligadas directamente con el sistemas, pero es muy

necesario tomar en cuenta el mejor servicio de red par obtener resultados satisfactorios.

Objetivo de la Técnica: En el caso de pérdida de conexión por cualquier motivo bebe existir algún tiempo para poder resguardar la información, con esto se garantizara el buen funcionamiento del sistema.

Técnica: Dentro del sistema se pueden utilizar variadas herramientas como base para la creación de una serie de operaciones para apoyar la recuperación de pruebas y fallos, principalmente para definir que las pruebas de ejecución de la recuperación ha sido exitosa.

Interrumpir la energía eléctrica al cliente: Desconectar el PC, y Interrupción del la energía eléctrica del servidor: Simular o iniciar los procedimientos con la energía eléctrica abajo para el servidor ( debe ser proporcionado algún tipo de baterías o generador que brinden energía para evitar la pérdida de información)

Igualmete debe existir la conexión de red que aporte seguridad en el caso de que se Interrumpir vía red el servidor: Simular o inicializar la comunicación pérdida con la red

Resultados Esperados: Los resultados esperados para un optimo funcionamiento del sistema es poder resguardar la información al momento de cualquier pérdida de conexión.

Herramientas Requeridas :

Las herramientas requeridas son:

Herramientas de monitoreo además de algún otro tipo que ayude a resguardar los datos en caso de pérdida de conexión



PLAPRU_GESHOR

Criterio de Éxito: Se deben tener en cuenta muchos puntos para el buen funcionamiento de este sistema, por lo que se requiere el tipo de conexión de red más segura que pueda conseguir, además de la alimentación eléctrica segura que impida cualquier pérdida de energia, con esto se garantiza el buen funcionamiento del sistema.


Baterías y/o generadores que proporciones larga duración de la energía a los servidores.

Buena conexión de red.

5.2.11 Configuración de las PruebasDentro de las posibilidades que existen al poner en marcha un nuevo sistema ya sea de cualquier

característica, podemos encontrarnos con los riesgos de no compatibilidad con los equipos, es por esto que es de mucha importancia dar a conocer las condiciones en donde se deben ejecutar este sistema de gestor de horarios. En este tipo de condicione se debe explicar la capacidad de los equipos, como también el tipo de conexión de red, además d los servidores de base de datos.

Objetivo de las Técnica: Como se menciono anteriormente, para lograr una satisfactoria ejecución del programa se debe cumplir con las condiciones requeridas previamente a la instalación.

Por ejemplo: el equipo debe tener por lo menos 2 gb de ram para aportar un correcto funcionamiento de los procesos. Ademas se debe contar con cualquier Explorer, siempre y cuando este no sea de google.

Técnica: Al ser ejecutado el sistema, este no debe aportar ningún tipo de problemas a abrir y cerrar distintos tipos de aplicaciones que no estén relacionados con el gestor de horario, ya se a abris, cerra, minimizar o restaurar el Word, Excel, etc.

Durante las pruebas que se realicen no debería existir ningún tipo de inconveniente con las aplicaciones que no pertenezcan al sistema.

Ademas deberia funcionar, si se lega a minimizar la memoria disponible del cliente.

Resultado Esperado: Durante la realización de las pruebas el sistema se encontrara con distintos tipos de complicaciones, lo cual se quiere minimizar al máximo. Al cabo de este procedimiento no debería existir algún obstáculo para lograr ejecutar aplicaciones que no tenga que ver con el sistema que se desea emplear.


Para realizar este tipo de pruebas necesitaremos interactuar con aplicaciones que no tengan que ver con el sistema, estas pueden ser: Word, Excel, etc.

Durante la ejecución de algunas de estas aplicaciones y el gestor de horarios, no debería existir algún inconveniente al minimizar, restaurar, cerrar o abrir estas aplicaciones.



PLAPRU_GESHOR

Criterios de Éxito: Debe ponerse en marcha el sistema ejecutando a la misma vez otras aplicaciones para poder tener noción de las posibles complicación es que pueda generar este tipo de proceso, y así poder descartar cualquier tipo error.


Los objetivos que no están disponibles para las pruebas que necesita el software son poder ejecutar otra aplicación junto con el sistema, esto se refiere a que no existe la prueba concreta de que otra aplicación funcionara correctamente al ser ejecutado el gestor de horarios.

Las aplicaciones que se utilizan conmunmente son: Word Excel, power point. Pdf, etc.

[¿Que objetivos no están disponibles par alas pruebas que necesita el software y que están disponibles en el escritorio?

¿Que aplicaciones son comunmente usadas?

¿Que aplicaciones de datos están corriendo; por ejemplo, una gran hoja de cálculo abierta en Excel o unas 100 páginas de un documento Word?

¿La entrada al sistema netware, servidores de red, based d datos, etc, también necesitan ser documentadas como parte de las pruebas?.]

5.2.12 Pruebas de InstalaciónEl nuevo sistema de gestor de horarios debe ser capaz de poder ser instalado en diversos entornos, con esto

se quiere decir, que este debe ser capas de montarse en cualquier tipo de equipo que el cliente requiera además, de poder adaptarse a la personalización que el usuario solicite. En palabras más simples, el sistema debe poder ser instalado bajo diferentes condiciones como poder: instalar nuevamente, actualizar, instalación completa y personalizada del software.

Objetivo de la Técnica:

Como se menciono anteriormente el sistema debe adaptarse según las circunstancias que se puedan requerir. Entre estas podemos mencionar:

Nueva instalación: el sistema gestor de horarios debe poder ser instalado en una maquina que no haya contado con el software anteriormente, es decir, una instalación por primera vez.

Actualización: el sistema gestor de horarios debe poder refrescarse a alguna nueva versión en una maquina con el software previamente instalado, así como también pueda soportar versiones antiguas.

Instalación Personalizada: el sistema gestor de horarios debe permitir la interacción con el cliente, es decir, el cliente podrá instalar el software con las propiedades o características que estime convenientes.



PLAPRU_GESHOR

Técnica:Para poder facilitar una instalación óptima, se debe conceder los manuales necesarios para conseguir el correcto funcionamiento del sistema. Dentro de las posibilidades de instalación podemos encontrar variadas situaciones como:

Nuevo: al ser la primera vez que se instala un software con estas características, se debe proporcionar un manual en donde se explique detalladamente la manera de cómo ejecutar el programa, dando a conocer los distintos entornos en donde puede ser situado.

Actualización: en este caso se debe proporcionar al cliente un manual donde se proporcione información de cómo renovar el software, es decir, este manual será para casos en donde es sistema ya ha sido previamente instalado.

El sistema debe otorgar las características del medio e donde debe realizarse la instalación.

Resultados Esperados: El sistema en si, debe cumplir con los requerimientos del cliente y las capacidades hardware que se estimen convenientes para un conveniente y oportuno funcionamiento del sistema gestor de horarios.

Se espera poder cumplir con todo lo establecido previamente, además de poder adaptar el software según las circunstancias permitidas ( ya sea una nueva instalación, actualización e instalación personalizada


El sistema requiere algunas herramientas para poder ser instalado:

Se debe aportar algún medio de recuperación de datos en caso de algún error.

El sistema deberá ser instalado según las condiciones que se requieran ( en tal caso el sistema otorgara las características del medio en donde debe ser montado el programa).

Criterios de Exito: El sistema entregara un medio de contacto, ya sea un correo electrónico algún teléfono e el caso de que sea necesario ayuda y soporte técnico.


El sistema gestor de horario requiere estrictamente la lectura del manual de instalación o en caso contrario contactar con algun especialista.

6. Criterios de Entrada y Salida

6.1 Plan de Pruebas

6.1.1 Criterios de entrada Plan de pruebas

Para comenzar con el plan de pruebase deben: Contar con los equipos necesarios para poder llevar a cabo el plan de pruebas Contar con el software para realizar las pruebas Contar con el personal capacitado para realizar la prueba

6.1.2.1 Criterios de salida Plan de pruebas

Los criterios de salida que debemos probar en este plan son los siguientes: Los Usuarios logran acceder al sistema a travez de un login, el cual solicita un username y una

password



PLAPRU_GESHOR

Los usuarios_profesores, deberán ver en su sesión datos como: Nombre, Asignatura y Nota de Evaluacion correspondiente

Los usuarios_jefecarrera deberán ver en su sesión datos como: Nombre, Carrera a la cual esta asociada y datos de los demás profesores y las asignaturas.

Los usuarios_administrativos deberán ver en su sesión datos como: Nombre, Sede en la cual se encuentran e Informacion estadística.

El sistema deberá generar un informe con las asignaturas que no están programadas y además de las asignaturas programadas con su respectiva carrera y profesor asignado.

El sistema debe generar un informe exportable a Excel o a Pdf para las asignaturas no programadas.

6.1.3 Suspensión y reanudación de criterios

El plan de pruebas podrá ser suspendido solo si se agregaran nuevos requerimientos por parte del usuario-final. O en caso de falla en los servidores del Instituto Profesional Santo Tomas.O se presenten problemas de salud por parte de las personas encargadas de las pruebas.

6.2 Ciclos de Prueba

6.2.1 Criterios para las Entradas de Ciclo de Pruebas

Revisión y aceptación del documento que contiene los casos de pruebas para la certificación del proyecto.

6.2.2 Criterios para la Finalización de Ciclo de Pruebas

El ciclo de prueba se finalizara una vez que se hayan corregidos los problemas que se hayan encontrado, además las correciones que se hayan hecho al sistema deberán ser registradas y documentadas en el plan de pruebas de cada ciclo.

6.2.3 Ciclo de término anormal

El ciclo deberá ser documentado y en caso de encontrar errores estos se pasaran al equipo de desarrollo y estos deberán corregir el problema, para ellos deberá detallarse bien el problema que se encontró en el ciclo de prueba y además las correcciones que se requieren.

7. Entregables

7.1 Resumen de las pruebas de evaluación

Las pruebas al sistema se realizaran una vez terminado el sistema, y se crearan informes en un tiempo determinado para corregir los errores que se podrián encontrar, ademas con las pruebas de evaluación se podrá mejorar el sistema y hacerlo mas robusto en caso de errores.

7.2 Presentación de los Informes sobre la cobertura de las Pruebas

Los informes que se generaran en las pruebas deberán comenzar con el caso de uso al cual se esta realizando el plan de pruebas, deberán contener un autor y los registros que se encontran al realizar la prueba. Estos deberán tener una hora en la que se realizo, una fecha y ademas observaciones del autor, en el que proporciona información de posibles hechos del error, ademas de posibles soluciones todo esto con el método que se utilizo y las herramientas que se ocuparon para dicha prueba.

7.3 Calidad Percibida de los Reportes

Para cada prueba deberá mostrarse si el caso de uso logro o no lo que tenia que hacer, para medir si logra o no lo que se pide lo haremos a travez de métricas las cuales deberán ser: ¿se logra hacer lo que se pide?, ¿se podría mejorar?, ¿se logra con eficiencia lo que se pide?. Todo esto deberá ser documentado y registrado para una vez terminado el plan de prueba.



PLAPRU_GESHOR

7.4 Registro de Incidentes y de Cambios Requeridos

Todo incidente o cambio requerido deberá ser documentado en el plan de prueba, este deberá ser analizado y solucionado por parte del equipo de desarrollo, los incidentes o cambios requeridos deberán ser en un documento con fecha, hora, nombre del caso de uso y el autor. Se deberán especificar los cambios y el porque deberían hacerse.

7.5 Trabajo Adicional a los Productos

7.5.1 Resultado Detallado de las Pruebas

Los resultados de las pruebas deberán ser detallados en una planilla Excel, con el nombre del caso de uso, los errores encontrados y las soluciones que sedeberan agregar y las que se solucionaron, todo esto bajo un autor, fecha, y hora.

7.5.2 Agregar Scripts Automáticos a las Pruebas Funcionales

Se deberán agregar los scripts de las funciones que se agregaran al sistema para mejorarlo, los que se usaron en cada prueba y una descripción de que es lo que hace o que es lo que corrige dentro del sistema. Ademas el código fuente deberá llevar líneas de texto en las que se especifique cada acciones y en caso de variables a que corresponden.

7.5.3 Directrices para las Pruebas

Cada prueba debera realizarse partiendo por ejecutar la acción que se solicita, una vez se vera la capacidad de reacción del sistema, luego se verán los resultados arrojados por el sistema, todo esot debera ser documentado

8 Pruebas del Flujo de TrabajoFlujo de trabajo que debera seguir el plan de pruebas en el desarrollo y ejecución del plan.

1.- El usuario par a ingresar al sistema debera autentificarse, atravez de un username y unas password.

2.- El sistema debera verificar al usuario, en caso de que el login sea correcto debera iniciar sesión de usuario, de lo contrario mostrara un mensaje de error.

3.- El sistema mostrara al usuario una interfaz de inicio que tendrá el nombre del usuario y cargo que desempeña en el IP.

4.- En el caso de los profesores la interfaz debera mostrar una pantalla con la opción de ingresar la especialidad del profesor y disponibilidad horaria.

5- En el caso de los jefe de carrera, el sistema debera mostrar una opción de generar reporte de horario. En el cual se deberán mostrar los profesores que han ingresado su disponibilidad y ademas su especialidad correspondiente.

6.- En el caso del usuario administrador se podrán ver los informes, ademas de los profesores y los jefes de carrera que tengan acceso al sistema.

7.- El sistema debera generar reportes para ser exportables en Excel o en PDF.



PLAPRU_GESHOR

9 Necesidades de AmbienteSe detallaran las necesidades para el desarrollo de las pruebas, estas necesidades abarcan las herramientas que utilizaremos y que es necesario tener para un buen plan de pruebas.

9.1 Hardware Básico para el Sistema

System Resources

Resource Quantity Name and Type

Servidor de Base de Datos

Servidor CST TBD

Base de Datos CST TBD

Pruebas del PC del Cliente

Internet Explorer 9

Ancho Banda 4mbps

TBD

Desarrollo de las pruebas para PC TBD

9.2 Pruebas Básicas de los Elementos del Software

Nombre Software Versión Tipos y Otras Notas

Windows Server 2003 Sistema Operativo de Red

Windows 7 Home Sistema Operativo

Internet Explorer 9 Internet Browser

9.3 Herramientas de Producción y de Soporte

Categoría o Tipo de la Herramienta

Tool Brand Name Vendor or In-house Version

Pruebas de Gestión

Pistas Defectuosas

Herramientes de DBMS

Microsoft Project

Microsoft Excel

Gestión del Proyecto



PLAPRU_GESHOR

10 Responsabilidades, Dotación de Personal y Necesidades de Entrenamiento

10.1 Personas y Roles

Esta tabla muestra la dotación de personal sumidas para esta prueba de esfuerzo

Recursos Humanos

Roles Recursos mínimos recomendados

Especificar las Responsabilidades o comentarios

Gestor de Pruebas Proporciona la supervision de la Gestión.

Resposabilidades incluídas:

Planificación y Logística

Misión de los acuerdosa

Identificación de las Motivaciones

Adquirir los recursos adecuados

Reportes de gestión Actulaes

Defender los interes de las pruebas

Evaluar efectivamente las pruebas de esfuerzo

Analista de Pruebas Identificar y definir las pruebas especificas a conducir.

Las responsabilidades Incluyen:

Identificar la idea de las Pruebas

Definir el detalle de las Pruebas

Determinar el resultado de las pruebas

Documentar los cambios requeridos

Evaluar la calidad del producto

Diseñador de las Pruebas Define el enfoque técnico para la aplicación de las pruebas de esfuerzo

Responsabilidades incluídas:

Definir el enfoque de las pruebas

Definir la arquitectura de las pruebas automáticas

Verificar las Pruebas técnicas

Definir los elementos de pruebas

Implementación de la estructura de las pruebas



PLAPRU_GESHOR

Recursos Humanos

Roles Recursos mínimos recomendados

Especificar las Responsabilidades o comentarios

Revisor Implementa y ejecuta las pruebas.


Implementar las pruebas y la suite de las pruebas

Ejecutar los suites de pruebas

Registrar los resultados

Analizar y recuperación de pruebas fallidas

Documentar los incidentes

Administrador de Sistemas de las Pruebas

Asegurar el ambiente de las pruebas y mantener y administrar los activos


Administrar la gestion de las pruebas de sistema

instalar y apoyar el acceso y la recuperación de configuraciones de entorno de prueba y laboratorios de prueba

Administrador de Base de Datos, Gestor de Base de Datos

Asegurar el ambiente de las pruebas de Datos (base de datos) y los valores son adminiustrados y mantenidos.


Soporte de la Adminitración de las pruebas de datos y los bancos de pruebas (base de datos).

Diseñador Identifica y define las operaciones, atributos y asociaciones de las pruebas de clases.

Responsibilities include:

define las clases de prueba necesarios para apoyar los requisitos de prueba, tal como se define por el equipo de prueba

Implementador Implemetar y probar las clases de pruebas y las pruebas de los paquetes.

Responsibilities include:

crear los components de pruebas requeridos para apoyar los requyierimientos de pruebas com son definidos por el diseñador



PLAPRU_GESHOR

10.2 Dotación de personal y Necesidades de Capacitación

Se mostraran pantallas de como deben de realizarse las operaciones dentro del sistema, detalladas paso a paso según el perfil del usuario.

11. Iteraciones e Hitos

Hitos Fecha de Inicio

Planificado

Fecha de Inicio Actual

Fecha de Termino Planeada

Fecha de Termino Actual

Acuerdos del Plan de Iteración 18-03-2011 23-03-2011 30-06-2011 04-07-2011

Comienzo de la Iteración 28-03-2011 28-03-2011 01-04-2011 04-04-2011

Línea de Base de los Requerimientos

05-04-2011 06-04-2011 11-04-2011 13-04-2011

Línea de Base de la Architectura 14-04-2011 14-04-2011 21-04-2011 23-04-2011

Linea de Base de la Interfaz de los usuarios

14-04-2011 14-04-2011 20-04-2011 21-04-2011

Primera entrega para pruebas 24-04-2011 24-04-2011 27-04-2011 27-04-2011

Primera entrega acepatada dentro de las pruebas

28-04-2011 28-04-2011 29-04-2011 29-04-2011

Primer cilco de pruebas finalizado

02-05-2011 02-05-2011 06-05-2011 06-05-2011

[Segunda construcción no sera revisada]

07-05-2011 07-05-2011 12-05-2011 13-05-2011

Tercera construcción entregada para pruebas

13-05-2011 14-05-2011 17-05-2011 18-05-2011

Tercera entrega acepatada dentro de las pruebas

18-05-2011 19-05-2011 21-05-2011 23-05-2011

Tercer cilco de pruebas finalizado

24-05-2011 24-05-2011 28-05-2011 29-05-2011

Cuarta construcción entregada para pruebas

29-05-2011 30-05-2011 08-05-2011 10-05-2011

Cuarta contrucción aceptada dentro de las pruebas

11-05-2011 13-05-2011 19-05-2011 21-05-2011

Revisión de la evaluación de la Iteración revisada

22-05-2011 23-05-2011 29-04-2011 02-04-2011

Termino de la Iteración 30-06-2011 04-07-2011



PLAPRU_GESHOR

12. Riesgos, Dependencias, Dependencies, Supuestos y Limitaciones

Riesgo Estrategia de Migración

Contingencia

(El riesgo es realizado)

Pre-requisito de los criterios de entrada no son cumplidas.

Declarará las definiciones de los pre-requisitos que deben cumplirse antes que la Carga de las Pruebas pueda comenzar.

Cumplir los requisitos pendientes

Considerar las pruebas de falla de Carga

Los datos de las pruebas resultan ser insuficientes

Realizar nuevas pruebas y generar nuevos documentos, las pruebas anteriores también deben ser documentadas.

13.Management Process and Procedures

13.1 Medir y Evaluar el alcance de las pruebas

Las prueba serán medidas a trave de métricas las cuales van desde el cumplimiento de los requerimientos especifico de cada caso de uso. Y estas deberán ser documentadas para evaluaciones para cada plan de prueba.

13.2 Informes de Problemas, la escalada, y la resolución de problemas

Los documentos con los problemas que se presenten serán entregados al equipo de desarrollo. Los informes deberán detallar los problemas encontrados y además pobles soluciones como observaciones por parte del autor del informe.

13.3 Gestión de los Ciclos de Prueba

Se comenzara con la ejecución del proceso.



PLAPRU_GESHOR

Se vera la reacción del proceso a travez de consultas e interacion con el usuario.Se buscaran posibles errores a travez de datos mal ingresados.Se documentara cada problema encontradoSe dara una posible solución al problema.Se entrege el documento, bajo un autor, fecha, hora y nombre del proceso.

13.4 Aprobación y Cierre

El Plan de Pruebas deberá ser entregado al equipo de desarrollo, una vez terminado el ciclo de pruebas y ya con los procesos verificados y listos, estos deberán ser entregados a la Corporacion Santo Tomas.La Corporacion Santo Tomas deberá firmar una acuerdo en el que certifique que las pruebas que se realizaron están cumplidas y que el sistema funciona según la documentación que se establecio.


Plan de Pruebas

Documents

Transcript of Plan de Pruebas