plan de pruebas

Desarrollo de una Aplicacion Web para la Gestion de los Procesos del Departamento de Captación y Selección de Personal en la

División del Cuerpo de Seguridad y Orden Público del Estado Aragua.Plan de Pruebas

Versión <1.0>

Prof. Edgard Vidal

Desarrollo de una Aplicación Web que permita agilizar y optimizar la gestión de los procesos

del Departamento de Captación y Selección de Personal en la División del Cuerpo de Seguridad

y Orden Público del Estado Aragua.

Versión: <1.0>

Plan de Pruebas Fecha: <16/01/2008>Documento de Plan de Pruebas

Historia de RevisionesFecha Versión Descripción Autor

Confidencial Fabrica de Hielo Gotardo C.A 2023 Página 2 de 26




Versión: <1.0>


Tabla de Contenidos

1. Introducción 5

1.1 Propósito 51.2 Alcance 51.3 Audiencia a la que se orienta 51.4 Terminología del Documento y Acrónimos 61.5 Referencias 61.6 Estructura del Documento

2. Propósito de la evaluación y motivación de las pruebas 6

2.1 Antecedentes 62.2 Propósito de la Evaluación 62.3 Motivadores de la prueba 7

3. Aspectos a los que se enfoca la prueba 7

4. Delimitación de las pruebas previstas 8

4.1 Pruebas a incluir 84.2 Pruebas potenciales a ser incluídas 84.3 Pruebas a Excluir 8

5. Enfoque de las Pruebas 8

5.1 Ideas Iniciales y otras Fuentes de referencia 85.2 Técnicas y tipos de prueba 8

5.2.1 Pruebas de datos e integridad de Base de Datos 85.2.2 Pruebas de Función 95.2.3 Pruebas del ciclo del negocio 105.2.4 Pruebas de Interfaces de usuario 115.2.5 Pruebas de Desempeño 115.2.6 Pruebas de Carga 125.2.7 Pruebas de Volúmen 135.2.8 Pruebas de Seguridad y Control de Acceso 145.2.9 Pruebas de Fallas y Recuperación 155.2.10 Pruebas de Configuración 165.2.11 Pruebas de Instalación 16

6. Criterios de Entrada y Salida 17

6.1 Plan de Pruebas 176.1.1 Criterios de Entrada 176.1.2 Criterios de Salida 176.1.3 Criterios de Suspensión y Retomar actividad 17

6.2 Ciclos de Prueba 176.2.1 Criterios de Entrada 176.2.2 Criterios de salida 176.2.3 Finalización anormal 17





Versión: <1.0>


7. Entregables 17

7.1 Resúmen de pruebas de evaluación 177.2 Reportes de Pruebas de cobertura 187.3 Reportes de calidad percibida 187.4 Seguimiento de registros de cambios sugeridos 187.5 Pruebas de Regresión y soporte de los Scripts de Prueba 187.6 Productos de trabajo adicionales 18

7.6.1 Resultados de pruebas detalladas 187.6.2 Scripts de pruebas adicionales 187.6.3 Guías de Pruebas 187.6.4 Matrices de trazabilidad 18

8. Flujos de Trabajo de Pruebas 19

9. Necesidades de ambiente 19

9.1 Hardware 199.2 Software 199.3 Herramientas de Productividad y Soporte 199.4 Configuraciones de Pruebas de ambiente 20

10. Responsabilidades, Personal y necesidades de entrenamiento 20

10.1 Personal y Roles 2010.2 Personal y Necesidades de entrenamiento 23

11. Puntos de control en la iteración 23

12. Riesgos, Dependencias, Suposiciones y Restricciones 24

13. Procedimientos y Gerencia de Procesos 25

13.1 Midiendo y determinando el grado de la prueba 2513.2 Determinación de los entregables de éste plan de pruebas 2513.3 Reportes del problema, escalada y resolución 2513.4 Gerenciar Ciclos de Prueba 2513.5 Estrategias de trazabilidad 2513.6 Aprobación y Finalización 25





Versión: <1.0>


Plan de Pruebas

1. Introducción

El siguiente Plan de Pruebas (PP) proporciona una descripción del documento entero. Incluye el propósito, el alcance, las definiciones, las siglas, las abreviaturas, las referencias y la descripción de este Plan de Pruebas

1.1 Propósito

El propósito del plan de prueba es recopilar toda la información necesaria para planear y para controlar el esfuerzo de la prueba para una iteración dada. Describe el enfoque para probar el software y es el plan a nivel superior generado y usado por los encargados para dirigir el esfuerzo de la prueba.

Este plan de prueba para el Desarrollao de una Aplicación Web que permita agilizar y optimizar la gestión de los procesos del Departamento de Captación y Selección de Personal en la División del Cuerpo de Seguridad y Orden Público del Estado Aragua.

Apoya los siguientes objetivos:

• Las pruebas van orientadas y dirigidas específicamente a los distintos modulos del sistema.

• En cuanto a la motivación es la de mayor seguridad generando confianza entre las personas que van a utilizar el sistema y las ideas que se implementan es evaluar cada uno de los modulos para verificar y estar seguros de que no existan errores.

• El enfoque a proyectar en este documento es revisar cada programa para cerciorarse de los posibles errores para darles solicucion y asi poder ofrecer un sistema en las mejores condiciones posibles.

• Los recursos requeridos para llevar a cabo el plan de pruebas son un computador con los requerimientos minimos de hardware y software para la ejecución del sistema.

• Las lista de los entregables de las pruebas del proyecto son básicamente evaluar los distintos modulos del sistema

1.2 Alcance

Los niveles de clase de prueba previstos radican en el momento en que se generan los resultados dando seguridad de que los datos introducidos se muestran como salida final y como se lleva a cabo cada flujo de los mismos asi como si cumplen con el control de los modulos y de los datos.

Por otra parte tambien es necesario señalar la interfaz es dec ir como interactua el usuario con el sistema.

Señalando la funcionalidad del sistema se puede decir que es alli donde se estudiara si los modulos cumplen o no con cada accion ejecutada, ahora bien la usabilidad radica en verificar si el usuario maneja adecuadamente el sistema, si tiene los conocimientos o no para hacerlo de alli se podriamos estar proponiendo una charla de inducción a los usuarios del mismo.

La confiabilidad del sistema esta en ver si los niveles de seguridad funcionan de manera adecuada si el usurio coincide con la contraseña y si le da acceso a los modulos correspondientes, si respalda y resgurda de manera correcta la información del sistema entre otras, por ultimo en este plan de pruebas se tratara el tema de desempeño y soporte el cual redica en verificar si el sistema funcionacorrectamente en el hardware y en el software en el cual se instaló.

1.3 Audiencia a la que se orienta

Las audiencias para las cuales se esta desarrollando este plan de pruebas son para los modulos del sistema; esto ayudara a que el usuario pueda identificarse con los modulos y asi poder ver mas fácilmente los errores que se presenten.





Versión: <1.0>


Tambien se evaluara la seguridad y respaldo de información del sistema con lo se podra asegurar con mayor confianza la recuperacion de la misma en caso de que ocurran pérdidas.

Por ultimo se estara evaluando el comportamiento y seguridad que nos brinda el computador en el cual se esta trabajando el sistema, es necesario evaluar cuales son sus fortalezas y sus debilidades.

1.4 Terminología del Documento y Acrónimos

Almacenamiento: nombre generico bajo el cual se incluyen todos los dispositivos de hardwre y software.

Archivo: datos almacenados bajo un nombre que puedan ser recuperados fácilmente y usarse cuando se desee.

Base de datos: Conjunto de datos relaciondos entre si, almacenados de forma accesible para poder relacionarlos, ordenarlos y mostrarlos.

Clave de acceso: Es una combinación de letras numeros y signos que deben teclearse para obtener acceso a un sistema o a partes de el.

Codigo: se refiere a las instrucciones contenidas en un programa y entendibles por el ordenador.

Comando: Orden dada al ordenador para que realice una accion determinada.

1.5 Referencias

Si aplica ya que el metodo usado para evaluar las pruebas es el de conversión en paralelo. La cual se usa para al mismo tiempo el sistema antiguo y el sistema actual teniendo en cuenta si los resultado arrojados son exactamente iguales y de esta forma asegurse de desechar el sistema antiguo.

2. Propósito de la evaluación y motivación de las pruebas

Asegurarse de que los modulos y componentes del computador sean confiables y optimos para lainstalacion segura del sistema.

2.1 Antecedentes

Este documento de plan de pruebas esta destinado para asegurarse de que los modulos del computador y otros puedan tener errores de tal manera que puedan ser evaluados, desde el principio los problemas que se presentaban en laempresa fueron el manejo inadecuado de la información y el traspapeleo de los documentos y redundancia de registros. La solucion que se ofrece con el sistema es la de realizar un aplicación web que le permita a a empresa generar todos esos procesos y reportes de manera rapida y sencilla.

La División del Cuerpo de Seguridad y Orden Público del Estado Aragua.es una institucion del estado, es un ente policial que se encarga de controlar las labores policiales dentro del estado Aragua. Y uno de sus matores retos es realizar la selección de todos aquellos aspirantes a agebte policial que deseen ingresar a la institucion.

2.2 Propósito de la Evaluación

Tanto el programador como el diseñador deben tener en cuenta que la mision más importante del plan de pruebas es asegurarse que el sistema funcione correctamente que noproduja errores ni ahora ni en el futuro. Se pueden encontrar distintas clases de errores como por ejemplo almomento de introducir los datos que estos nocorrespondan con las pantallas de salida.

Que hallan errores internos en la programación de los modulos específicamente de los procesos.Se pueden decir que losproblemas más importantes a los cuales se le pueden pervenir los riesgosson:





Versión: <1.0>


Que los modulos a los que tiene acceso el usuario no correspondan con los los niveles, esto hay que vericarlo muy bien en la programación. Otro podria ser la perdida de informacion esto es el resgurdo y respaldo se debe respaldandar la información en un dispositivo seguro.

Se debe tener un estandar en el diseño de las pantallas.

La calidad del sistema puede ser muy alta pero pueden exister mejores propuestas.

La prueba utilizada en este sistema es importante y fiable para el usuario porque omite posibles errores.

Si satisface las necesisdadesdel proyecto ya que es la base por la cual se elabora el sistema.

2.3 Motivadores de la prueba

Los elementos claves en los que se motivara el esfuerzo de las pruebas de esta interaccion son los modulos ya que a partir de estos sera la evaluacion del sistema. Probar que los escenarios y partes de la plicacion cumplen con los requerimientos exigidos por el usuario.

Los riesgos de calidad pueden ser la mejora o la falta de los elementos del sistema. Los posibles riesgos estan basados en el analisis incorrecto de cada uno delos casos.

En cuanto a los casos de uso estos especifican paso a paso el flujo de los procesos del sistema. Los requerimientos funcionales estan basados en el sistema por medio de sus procesos y los requerimientos no funcionales son los que el sistema no toma en cuenta almomento de hacer alguna evaluacion.

Las sospechas de falta se pueden ver después de que el sistema se pone a prueba por un tiempo por lo cuales importante incluirlo en el plan de pruebas, se pueden dar posibles mejoras a losa requerimentos para la elaboración del sistema.

3. Aspectos a los que se enfoca la prueba

Los requerimientos que deben tomar en cuenta para poder realizar la instalacion del sistema son los de hardware y software para que asi elsistema tenga un funcionamientooptimo a continuación se especificaran cada uno de ellos: No necesariamente se necesita un computador dealta tecnologia ya que el sistema funciona en cualquier computador ya sea de poco o de muchos GHZ.

En cuanto al harware:

Procesador Pentium IV,

Velocidad de 2.5 GHZ a 2.8 GHZ,

Memoria Ram 512

D.D de 40 GB a 80 GB

En cuanto al software:

Sistema operativo Linux Rapidez

Rapidez

Confiabilidad

Niveles de seguridad

Consistencia de datos





Versión: <1.0>


Amigabilidad

Estandarizacion

4. Delimitación de las pruebas previstas

Las pruebas que se tienen previstas para este sistema son:

Verificar que el hardware en el cual se instalara el sistema sea el mas indicado

Evaluar al software para comprobar que cumple con los estándares de seguridad, confiabilidad, amigabilidad, rapidez, estandarización.

4.1 Pruebas a incluir

Las pruebas previstas a realizar para los elementos anteriormente descritos son evaluar el hardware y el sistema que cumpla con los requerimientos necesarios en cuanto a los elementos tecnicos verificando que no tengan ninguna falla, y el software o los programas del sistema operativo por lo cual trabajara el sistema sean compatiblescon el software de instalacion del sistema.

4.2 Pruebas potenciales a ser incluídas

La vision principal de esta prueba es la de verificar el equipo tecnico y prevenir el no funcionamiento de sistema. Es decir la evaluación intensa a los diferentes modulos o partes que componen la aplicación web que se desarrolla.

4.3 Pruebas a Excluir

No se excluirá ningún tipo de pruebas ya que todo intento de evaluar y conseguir fallas será favorable para gantizar la calidad del producto.

5. Enfoque de las Pruebas

Las pruebas de delimitacion seran especificadas desde el punto de vista específico con personas capacitadas el funcionamiento del hardware y el software. Los tipos de pruebas que se utilizaran para el correcto funcionamiento del sistema y de otros dispositivos perefericos desde una perpectiva manual automatizada son la evaluacion operaciona ldel computador y del sistema. El impacto que acarrea para la misma y el desempeño, para cada una de estas tecnicas es necesario proporcionar en primera instancia el analisis de los dispositivos o perifericos a evaluar, en segunda instancia como trabaja el sistema y el computador ambos enlazados y por ultimo eldesempeño del producto a utilizar por parte del usuario.

5.1 Ideas Iniciales y otras Fuentes de referencia

Los diferentes modelos de fallas aplicables al sistema y al hardware son las fallas tecnicas al momento de ejecutar elsistema o fallas del software en las que el sistema operativono conozca elarchivo ejecutable para trabajar con elsistema.

5.2 Técnicas y tipos de prueba

5.2.1 Pruebas de datos e integridad de Base de Datos





Versión: <1.0>


Objetivo de la Técnica: Asegurar los datos que estan en la base de datos, y que todas las tablas esten bien relaciondas para asi evitar redundancia a la hora de trabajar con eella

Técnica: Ejecutar cada método y proceso de acceso de base de datos, validando o no los datos

Examinar que la base de datos cumple con las acciones correspondientes al sistema y verificar que las tablas corresponden con las utilizadas cada uno de los formularios del sistema.

Oráculos: Verificar que los campos de los distintos modulos del sistema correspondan con los especificados en la base de datos para determinar si corresponden o no y satisfacer las acciones las esperadas por el usuario

Herramientas Requeridas:

La técnica requiere de las herramientas siguientes:

Evaluar las pruebas automaticas de la base de datos.

Actualizar las base de datos

Respaldar y resguardar la información de la base de datos

Monitoreo – Instalación ( registro, disco duro CPU, memoria, base de datos acces)

Criterios de Exito: El éxito dependera de la aprobación del los modulos de y procesos claves acceso a la base de datos

Consideraciones Especiales:

La prueba requiere de un ambiente de desarrollo en My SQL para incorporar o modificar los datos en la base de datos.

5.2.2 Pruebas de Función

Objetivo de la Técnica: La funcionalidad del sistema dependera en general de la validación de accesos al sistema a traves del gestor de entrada y que el acceso a los modulos sea de acuerdo a su nivel de alli comienza navegación de las pantallas ejecutando una serie de acciones conducidas por el usuario.

Técnica: Las características de los flujos de los casos de uso parten de la manera en que se ejecutan cada una de ellas de forma individual

Cuando un usuario ingresa datos incorrectos el sistema lo captura, si es correcto el sistema valida datos y muestra los resultados esperados.

Por otro lado si el usuario introduce datos incorrectos entonces el sistema le mostrara un mensaje de error y le permitira una segunda y tercera oportunidad para corregir los datos.

Verificar que los procesos realicen su función tal como lo indica el caso de uso, además que los datos en los procesos ingresados sean validados y que las respuestas sean las esperdas.





Versión: <1.0>


Oráculos: El sistema valida los datos introducidos por el usuario y los evalua para verificar si son los correctos., al mismo tiempo enlaza esos datos con la base de datos y muestra resultados.

Herramientas requeridas:

La tecnica requiere de las siguientes herramientas:

Evaluacion de cada uno de los campos del sistema.

Respaldo, recuperacion de datos

Monitoreo.

Criterios de Exito: Técnicas de soporte de pruebas de:

El sistema debe manejar los datos de cada uno de los flujos de los Casos de Uso claves dándole aceptación validando datos.

Que el sistema pueda darle al usuario la respuesta de acuerdo a los datos introducidos por el que los mismos concuerden con la base de datos.


El impacto que tomo el sistema puesto en marcha es favorable ya que al momento de evaluar y analizar todos los del sistema y del computador estos funcionan correctamente.

5.2.3 Pruebas del ciclo del negocio

Objetivo de la Técnica: El objectivo principal es determinar el Comportamiento del sistema en un periodo determinado.

Técnica: La prueba simulará varios ciclos de negocio realizando lo siguiente:

Almacenar el número de veces que cada función se ejecuta para simular los diferentes usuarios en un período especificado.

Serán ejecutadas todas las funciones sencibles usando fechas o períodos válidos e inválidos.

En la prueba se incluirán datos válidos e inválidos para verificar lo siguiente:

Se mostrara un resultado favorable cuando se ingresen datos correctos o no.

Si los datos son incorrectos se mostrara un mensaje de error adecuado.

Oráculos: Realizar copia impresa de los registros de la base de datos para corroborar que los resultados arrojados se corresponden con los existentes.





Versión: <1.0>


Herramientas requeridas:

La técnica requiere las siguientes herramientas:

Evaluar las pruebas automaticas en cuanto a la Fecha de ejecución

Un resguardo y respaldo todo lo guardado para la fecha de la accion.

Monitoreo – Instalacion (registro, disco duro, memoria) generador de datos. (impresora)

Criterios de Exito: Corregir los errores que el sistema reconozca y la base de datos


Las fechas y los acontecimientos del sistema pueden requerir actividades especiales de la ayuda.

Se requiere un modelo del negocio para identificar requerimientos y procedimientos favorables para el negocio.

5.2.4 Pruebas de Interfaces de usuario

Objetivo de la Técnica: El objetivo principal para la interfaz de usuarioes identificar la forma mas clara y sencilla de manejar los modulois, permitiendo al usuario acceder a de las opciones elegidas mediante un enlace que lo conecte a la pantalla seleccionada

Técnica: Navegar por los dstintos escenarios y ejecutar cada uno de los controles para verificar su correcto funcionamiento.

Oráculos: Delimitar las pantallas por medio de la navegación de una pantalla a otra.

Conseguir errores de navegabilidad debido a errores de programación y poder repararlos a tiempo.


Criterios de Exito: La técnica apoya la prueba de cada pantalla o ventana principal que pueden ser usadas extensivamente por el usuario.


No todas las personas podran tener el privilegio de accerder al sistema solo aquellos que tengan su clave personal

5.2.5 Pruebas de Desempeño

Objetivo de la Técnica: Ejercitar las transacciones o las funciones del sistema de manera tal que muetre los resultados en el menor tiempo posible. Asi como imprima reportes o genere consultas.





Versión: <1.0>


Técnica: Modificar los archivos de datos para aumentar el número de transacciones o de los scripts para aumentar el número de las iteraciones que ocurren en cada transacción.

Someter el sistema a pruebas rigurosas de manejode archivos para poder medir el tiempo que ocurre entre cada interaccion

Oráculos: Delimitar las pantallas por medio de la navegación de una pantalla a otra.

Conseguir errores de navegabilidad debido a errores de programación y poder repararlos a tiempo.


Herramientas de automatización de datos.

Especificar la aplicación con la que se va a cuantificar el perfil de desempeño

Herramientas de instalación y monitoreo (registros, disco duro, CPU, memoria, etc.

Criterios de Exito: La técnica soporta las pruebas:

Una sola transacción o un solo usuario: Emulación acertada de los scripts de la transacción sin alguna falla, debido a los problemas de implementación de la prueba.

Transacciones múltiples o usuarios múltiples: Emulación acertada de la carga de trabajo sin cualquier falla, debido a los problemas de la implementación de la prueba.


La prueba de funcionamiento comprensiva incluye tener una carga de trabajo en el servidor. Hay varios métodos que se pueden utilizar para realizar esto, incluyendo:

“Conduzca las transacciones "directamente al servidor, generalmente en la forma de lenguajes de búsquedas estructurados (SQL).

Cree la carga "virtual" del usuario para simular a muchos clientes, generalmente varios cientos. Las herramientas alejadas de la emulación terminal se utilizan para lograr esta carga. Esta técnica se puede también utilizar para cargar la red con "tráfico".

Utilice a clientes físicos múltiples, escrituras de cada prueba del funcionamiento, para poner una carga en el sistema.

La prueba de desempeño se debe realizar en una máquina "dedicada" o en un momento " dedicado”. Esto permite control completo y la medida exacta.

Las bases de datos usadas para la prueba de funcionamiento deben ser de cualquier tamaño real o escalado igualmente.

5.2.6 Pruebas de Carga

La prueba de la carga es una prueba del funcionamiento que sujeta el Objetivo de las pruebas de las cargas de trabajo que varían en la medida y evalúa los comportamientos para medir y evaluar el desempeño. La meta de las pruebas es determinar y asegurarse de que el sistema funciona correctamente más allá de la carga de trabajo máxima prevista. Además, la prueba de la carga evalúa las características de funcionamiento, tales





Versión: <1.0>


como tiempos de reacción, costos de la transacción y otras ediciones sensibles al tiempo.

Objetivo de la Técnica: Ejercite las transacciones señaladas para los Casos de Uso bajo condiciones de la carga de trabajo que varían para observar y registrar el comportamiento de los objetivos de las pruebas y datos.

Técnica: Usar Scripts de prueba de transacción desarrollados para la prueba de la función o de ciclo de negocio como base, pero recordar quitar interacciones y retrasos innecesarios.

Modifique los archivos de datos para aumentar el número de transacciones o las pruebas para aumentar el número de veces que cada transacción ocurre.

Las cargas de trabajo deben incluir (por ejemplo, diario, semanal, mensualmente y así sucesivamente) cargas máximas.

Las cargas de trabajo deben representar tanto promedios como cargas máximas.

Las cargas de trabajo deben representar picos instantáneos y sostenidos.

Las cargas de trabajo se deben ejecutar bajo diversas configuraciones del ambiente de la prueba.

Oráculos: Verificar que los cargos de datos son hechos sin ninguna falla y puestos correctamente en el proceso ejecutado.

Herramientas Requeridas

La técnica requiere de las siguientes herramientas:

Automatización de scripts de pruebas.

Instalacion y monitoreo

Criterios de Exito: La tecnica apoya la prueba de carga de datos al sistema, sin que halla ninguna falla que aumente su tiempo de respuesta.


La prueba de la carga se debe realizar en una máquina dedicada o en un rato dedicado. Esto permite control completo y la medida exacta.

Las bases de datos usadas para la prueba de la carga deben ser cualquier tamaño real o escalado igualmente.

5.2.7 Pruebas de Volúmen

Objetivo de la Técnica: Mostrar en un tiempo de ejecución todos los reportes pero de manera correcta, señalando en ella que el sistema respondio como se esperaba.

Técnica: Utilice las pruebas desarrolladas para el Perfil de Desempeño o Pruebas de Carga.

El volumen de los datos debe ser amplio para verificar que el sistema cuenta con un potencial excelente para ejecutar archivos





Versión: <1.0>


Oráculos: Especificar que el sistema puede trabajar con mucho volumen de información sin presentar ningun tipo de problemas.



Automatización de los de pruebas.

Herramientas de instalacion y monitoreo.

Banco de datos, para poder hacer las pruebas.

Criterios de Exito: Los cambios de estdo del sistema son aprobados por las técnicas de prueba de volumen certificando su correcto funcionamiento


5.2.8 Pruebas de Seguridad y Control de Acceso

Los niveles de seguridad del sistema aseguran de que solamente a esos usuarios se les conceda el acceso al sistema y solamente a través de las entradas apropiadas.

Objetivo de la Técnica: Nivel de seguridad de la aplicación: un actor puede acceder solo aquellas funciones o datos para los cuales su tipo del usuario tenga permiso.

Nivel de seguridad al sistema: la entrada al mismo se tomara de acuerdo a su tipo de nivel bien sea, administrador, gerente o usuaio

Técnica: Nivel administrador: tiene acceso a todo el sistema.

Nivel gerencial: solo podra hacer consultas e imprimir reportes.

Nivel usuario: solo podra cargar datos.

Oráculos: Permitir la seguridad a los usuarios por medio de los diferentes accesos de acuerdo a su clave, su nivel y contraseña

Herramientas Requeridas


Una herramienta de protección contra “Hacker”

Administración de seguridad OS

Criterios de Exito: La técnica apoya las pruebas para que cada actor conozca las funciones apropiadas o los datos afectados por seguridad.


El acceso del sistema debe ser discutido o revisado con el administrador adecuado





Versión: <1.0>


5.2.9 Pruebas de Fallas y Recuperación

Objetivo de la Técnica: Estudiar la recuperacion de información si ocurre alguno de estos eventos

Interrupción de electricidad

Apuntadores y claves de Bases de datos inválidos

Elementos en la base de datos inválidos o datos corruptos ]

Técnica: Interrupcion de energia al cliente: apagar la PC.

Iinterrupcion de energia al servidor: simule o inicie los procedimientos de la energia para el servidor

Una vez que se alcanzan las condiciones anteriores, otras transacciones adicionales deben ser ejecutadas y al alcanzar este segundo estado, los procedimientos de recuperacion deben ser invocados.

La prueba para los ciclos incompletos utiliza la misma tecnica que ya fue descrita excepto que los procesos de la base de datos en si mismos deberian ser abortados o prematuramente finalizados.

La prueba para las condiciones siguientes requiere que un estado conocido de la base de datos sea alcanzado.

Varios campos de la base de datos, apuntadores y claves se podrian corromper manualmente y directamenete de la base de datos (via las herramientas de la base de datos). Las transacciones adicionales se deben ejecutar usando las pruebas desde las pruebas de ciclo de funcion y del subsistema y los ciclos completos seran ejecutados.

Oráculos: Verificar que la falta de energia no afecte en algun momento al sistema o algunos de los componentes que integran el computador



UPS

Configurador base y restaurador

Monitoreo de instalación

Criterios de Exito: Lograr que en el momento de una falla electrica los datos con los cuales se estaban trabajando no se pierdan si no que se almacene en la base de datos, para luego buscarlos y este aparezca en la ultima accion que realizo el usuario.


Los procedimientos para desconectar el cableado en caso de que haya habido pérdida de luz o comunicación pueden no ser deseables o factibles. Los metodos alternativos, tales como herramientas del software de diagnostico pueden ser requeriddos.





Versión: <1.0>


5.2.10 Pruebas de Configuración

Objetivo de la Técnica:

Ejercitar las pruebas para las configuraciones requeridas del hardware del software para observar y registrar el desempeño bajo diversas configuraciones e identificar cambios en el estado de la configuración.

Técnica: Abra y cierre el software relacionado, tal como usos de herramientas automatizadas (Excel y Word), como parte de la prueba o antes del comienzo de la prueba.

Ejecute las transacciones seleccionadas para simular a actores que interactuan con los objetivos y los no objetivos de las pruebas.

Repita el proceso anterior, reduciendo al mínimo la memoria convencional disponible en el sitio de trabajo del cliente.

Oráculos: Verificar que la configuración del sistema es la más apropiada y la más compatible con el computador.





Criterios de Exito: La técnica soporta las pruebas de una o más combinaciones las cuales se ejecutan en ambientes esperados y soportados por la implantación.


5.2.11 Pruebas de Instalación

Objetivo de la Técnica: Asegurarse de que el software que va a ser aplicado pueda ser instaldo bajo diversas condiciones.

Verificar que el software funcione correctamente luego de ser instalado correctamente.

Técnica: Verificar que el sistema funcione correctamente luego de sus instalaciones observando las diferencias que aporte cuando se prueben en una maquina nueva con todas sus instalaciones y en otra ya usada con las actualizaciones.

Oráculos: Asegurarse que el sistema se ha instalado correctamente en el computadory ademas verificar que exista espacio suficiente en el disco duro para ejecutar los datos.


La técnica requiere de las siguientes herramientas:







Versión: <1.0>


Criterios de Exito: La técnica soporta las pruebas de la instalación del producto desarrollado en unas o más configuraciones de la instalación.


6. Criterios de Entrada y Salida

6.1 Plan de Pruebas

6.1.1 Criterios de Entrada

Verfificar que exista el archivo en el la panatalla inicicial del computador para que el usuario pueda iniciar el arranque del sistema y permitir su entrada. Y a su vez sera llevado a cabo una vez que se haya desarrollado la interfaz grafica asi como la base de datos con sus diferentes componentes

6.1.2 Criterios de Salida

Asuegurarse de que el sistema cumpla con el completo funcionamiento de todos los modulos y no solo una parte de ellos. Y de igual formase evaluara de acuerdo a las etapas del sistema.

6.1.3 Criterios de Suspensión y Retomar actividad

Serciorarce de que el sistema no se suspenda por algun motivo que presente el computador y pueda continuar la actividad que en ese momento se este efectuando. Para este criterio se utilizaran las pruebas de carga y las pruebas de instalacion.

6.2 Ciclos de Prueba

6.2.1 Criterios de Entrada

Colocar el sistema a prueba y estar en constante evaluación poara evaluarlo continuamente y por ende poner el sistema nuvamente a prueba una vezque el programamador certifique la finalizacion del sistema mediante la programación.

6.2.2 Criterios de salida

Los criterios de prueba en esta seccion deben ser de completa perfeccion para garantizar el buen funcionamiento del sistema.

6.2.3 Finalización anormal

Revisar vada uno de los criterios puestos a prueba para prevenir la suspensión del sistema por fallas erróneas en cualquiera de sus caracteristicas.

7. Entregables

Todos los beneficios que fueron obtenidos del sistema luego de las pruebas que se le ha aplicado como:La Documentacion de cad una de las pruebas

7.1 Resúmen de pruebas de evaluación

Todos los criterios fueron evaluados de acuerdo a las reacciones del sistema con el computador generando resulatdos que sirven de ayuda para el usuario puesto que aumentara la confianza y la seguridad de la posee





Versión: <1.0>


dicho sistema.

7.2 Reportes de Pruebas de cobertura

Mediante la cobertura del sistema con la imeracion del computador se puede determinar que existe una excelente cobertura de información por parte del sistema.]

7.3 Reportes de calidad percibida

Los informes seran realizados a medida que se evalua el sistema, para a su vez reparar las fallas presentadas. Para asi brindarle la confianza al usuario al momento de usar el sistema..

7.4 Seguimiento de registros de cambios sugeridos

Se puede decir que la manera del como se debe manejar la informacion sera después de haber llenado los campos de los modulos y guardarlo en la basae de datos del sistema verificando en ella misma si los datos que se ingresaron quedaron registrados. De igual forma deido a las herramientas que se udsan se les da seguridad a los usuarios que los datos que ingresen o modifiquen seran guardados evitando perdidas de estos.

7.5 Pruebas de Regresión y soporte de los Scripts de Prueba

La forma de manejar los registros, se hara después de haber sido llevado a la base de datos confirmando que los datos fueron guardados. Sin embargo una de las herramientas a utilizar sera la evaluacion contanste para asi certificar al usuario que los datos no se perderan

7.6 Productos de trabajo adicionales

Los productos que son entregables son el sistema ejecutable y la manera en que trabajara el sistema poniendo primero a evaluación y a criterio del programador para que a la hora de la entrega no tenga ninguna falla.

7.6.1 Resultados de pruebas detalladas

Revision del hardware del computador

Verificación del software del sistema

Análisis de la instalación del sistema con el computador

Verificación del sistema acoplado al computador

Certificar validaciones

Mantener un control de errores que seran corregidos y prevenidos a tiempo..]

7.6.2 Scripts de pruebas adicionales

Evaluación del codigo fuente para verificar si existen errores, y se evaluara paso a paso cada modulo junto a sus códigos.

7.6.3 Guías de Pruebas

Las pautas es la evaluacion de los errores por individual en el sistema y asi proporcinar una guia al programador de todas las fallas presentadas para indagar mas a fondo su contenido y poder solucionar a tiempo algun a falla que en un momento dado se pueda presentar, en cuanto a los diseños de cada pantalla tendra que ver con la estandarizacion con la que se ha trabajado.

7.6.4 Matrices de trazabilidad

Son las herramientas con la cual se verifica y se asegura de que exista concordancia de los procesos con





Versión: <1.0>


cada uno de los requerimientos del diseño del sistema .

8. Flujos de Trabajo de Pruebas

Detalles más específicos de las tareas de prueba individuales se definen de diversas maneras, dependiendo de la cultura del proyecto; por ejemplo:

Evaluaxion de la carga de trabajo

Evaluacion del código fuente

Documentacion de errores en papel para que sen solucionados a tiempo

9. Necesidades de ambiente

Etste requiere de un tipo de ambientes donde se encuentra el computador con un sistema ya utilizado pero con sus actualizaciones y otro donde no se halla usado el sistema.

9.1 Hardware

La tabla siguiente dispuso los recursos de sistema para el esfuerzo de la prueba presentado en este plan de prueba.

Recursos del Sistema

Recurso Cantidad Nombre y Tipo

Equipos disponibles para la instalacion

2 Computador pentiun IV

Monitor 2 Cualquiera

Teclado 2 Compatible con el pc

Mouse 2 Compatible con el pc

Procesador 2 2.8 Mhz o uno menor

Memoria 2 256MB

Disco duro 2 80G

9.2 Software

Los siguientes elementos de software serán requeridos en las pruebas de ambiente para el Plan de Pruebas

Nombre del Software Versión Tipo y otras notas

Apliacion Web para la gestion de la procesos del deparatmento de Captacion y Selección de

Personal en (C.S.O.P.E.A)

1.0 Ejecutable

Linux (No definida aún) Sistema Operativo

9.3 Herramientas de Productividad y Soporte

Las siguientes herramientas serán empleadas para soportar el proceso de pruebas del Plan de Pruebas .





Versión: <1.0>


Categoría de la Herramienta o Tipo

Nombre de la marca Herramienta

Vendedor o In-house Versión

PHP Lenguaje de programación

5.0

9.4 Configuraciones de Pruebas de ambiente

Las Configuraciones del ambiente de Prueba deben ser provistas y soportadas por este proyecto.

Nombre de Configuración Descripción Implementación de la Configuración Física

Cpu

Memoria

Unidad central de procesamiento o sobre que plataforma se instalara el sistema

Capacidad de almacenamiento de información y modo de ejecución de la misma es decir, sobre que velocidad trabajara el sistema de información.

En la empresa … sobre distintos computadores

10. Responsabilidades, Personal y necesidades de entrenamiento

El personal de la empresa esta capacitado para manejar el sistema de información y las responsablidades que abarca en cada uno de ellos. De igual forma se necesita darle a estos una determinada serie de instrucciones de entrenamiento que les facilite el conocimiento del sistema de cómo se trabaja utilizando diferentes recursos para lograrlo .

10.1 Personal y Roles

Esta tabla muestra supuestos que proveen de personal para el esfuerzo de la prueba.





Versión: <1.0>


Recursos Humanos

Roles Recursos Mínimos Recomendados

(número de roles a tiempo completo asignados)

Responsabilidades Específicas o Comentarios

Gerentes de Prueba Los analistas seran capaces de gerenciar las pruebas a la hora de que estas se realicen en dicha empresa.

Soportar a la gerencia.

Responsabilidades que abarca:

Planificación y logística

Identifique motivadores

Adquiera los recursos apropiados

Divulgación de la gerencia actual

Abogue los intereses de la prueba

Evalúe la efectividad del esfuerzo de la prueba.

Analistas de Pruebas Los analistas del sistema deberean estudiar y analizar las diferentes pruebas que seran aplicadas al sistema.

Identificar y definir las pruebas específicas que se conducirán.


Identificar pruebas

Definir detalles de la prueba

Determinar resultados de la prueba

Requerimientos de cambio de documento

Evaluar la calidad del producto

DiSeñadores de Pruebas Son los que se encargan de verificar que tan Buena puede ser la prueba.

Definir la especificación técnica para implementar del esfuerzo de la prueba.

Responsibilities que incluye:

Defina la especificación de la prueba

Defina la arquitectura de la automatización de la prueba

Verifique las técnicas de prueba

Defina los elementos de prueba

Implementación de la prueba de la estructura





Versión: <1.0>


Recursos Humanos




Probadores Mediante este se prueba el funcionamiento del sistema en la empresa, después de haber realizado las pruebas pertinentes.

Implementar y ejecutar las pruebas.


Implementar pruebas y ejecutar suites de pruebas

Ejecutar las suites de prueba

Resultados del registro

Analizar y recuperar las fallas de la prueba

Incidentes del documento

Administradores de las Pruebas del Sistema

Los creadores del sistema deben estar al tanto de cómo se manejan las pruebas y de que forma para evitar errores en la misma

Asegurar el ambiente de la prueba y se manejan y se mantienen los activos. Responsibilidades que abarca:

Administrar el sistema de gerencia de la prueba

Instalar y apoyar el acceso y a la recuperación, de las configuraciones del ambiente de la prueba y a los laboratorios de la prueba

Administrador de Base de Datos, Gerente de Base de Datos

Los administradores estan al tanto de todos los datos que estan manejados y son responsables de los mismos.

Asegurar que en el ambiente de los datos de prueba (base de datos), sean manejados y se mantengan activos.

Las responsabilidades incluyen:

Apoyar la administración de los datos de prueba y de prueba (base de datos)

Diseñador El diseñador esta al tanto de las pruebas de evaluacion del sistemas el cual debe definir el estandar y el limite de los datos que se usaran para evitar tanta carga de información

Identificar y definir las operaciones, las cualidades y las asociaciones de las clases de la prueba.

Las responsabilidades incluyen:

Definir las clases de la prueba requeridas para apoyar requerimientos las pruebas según lo definido por el equipo de la prueba





Versión: <1.0>


Recursos Humanos




Implementador Los instrumento utilizados para esta prueba se basa en la responsabilidad que tenga el implementador de crear diferentes requerimientos que permitan asegurar los planes de puebas por parte del diseñador.

Instrumentos y pruebas de unidad, para los que la prueba clasifica y los paquetes de la prueba. Las responsabilidades incluyen:

Crear los componentes de la prueba requeridos para apoyar requerimientos de las pruebas, según lo definido por el diseñador

10.2 Personal y Necesidades de entrenamiento

En esta parte del plan de prueba es necesario hacer cosntar de los diseñadores, programadores, desrrolladores estan en la capacidad de dictar cursos de conocimiento y adiestramiento del sistema primero al administrador para que este oriente a una serie de charla que seran planteadas a los usuarios que usaran el sistema.

De igual forma se utilizara una guia especial que sera de mejor ayuda y mayor entendimiento para los usuarios puesto que en ellas estaran escrito cada uso de los objetos que contienen cada una de las pantallas, el cual lleva por nombre manual de usuarios.

11. Puntos de control en la iteración

Identifique los puntos de control claves del cronograma que fijan el contexto para el esfuerzo de prueba. Evite repetir demasiado detalle que se documente en otra parte donde los planes tratan el proyecto completo.

Puntos de Control Fecha de Inicio Planificada

Fecha de Inicio actual

Fecha de Final Planificada

Fecha de Final

actual

Acuerdos de Plan de Iteración 20/03/2008 20/03/2008 20/03/2008 20/03/2008

Inicio de la Iteración 01/042008 01/042008 01/042008 01/042008

Primera construcción a ser entregada para pruebas

01/04/2008 01/04/2008 15/04/2008 15/04/2008

Primera construcción a ser aceptada por pruebas

16/04/2008 16/04/2008 16/04/2008 16/04/2008

Primera construcción que finaliza ciclo de pruebas

17/04/2008 17/04/2008 17/04/2008 17/04/2008





Versión: <1.0>


Puntos de Control Fecha de Inicio Planificada

Fecha de Inicio actual

Fecha de Final Planificada

Fecha de Final

actual

Dos informes de pruebas (No serán revisadas)

19/04/2008 19/04/2008 19/04/2008 19/04/2008

Tercera construcción entregada a pruebas

21/05/2008 21/05/2008 01/06/2008 01/06/2008

Tercera construcción aceptada por pruebas

08/06/2008 08/06/2008 08/06/2008 08/06/2008

Tercera construcción que finaliza ciclo de pruebas

10/06/2008 10/06/2008 10/06/2008 10/06/2008

Cuarta construcción entregada a pruebas

11/06/2008 11/06/2008 18/06/2008 18/06/2008

Cuarta construcción aceptada por pruebas

25/06/2008 25/06/2008 25/06/2008 25/06/2008

Revisión de la Iteración 29/06/2008 29/06/2008 29/06/2008 29/06/2008

Fin de la Iteración 30/06/2008 30/06/2008 30/06/2008 30/06/2008

12. Riesgos, Dependencias, Suposiciones y Restricciones

En la siguiente tabla se muestra algunos riesgo, estrategias de migración y contingencias que se pueden presentar con respecto al sistema cuando se ejecute el plan de pruebas.

Riesgos Estrategias de MitigaciónContingencias (Riesgo

es realizado)

Prerequerimientos no logrados.

Los creadores del sistema deben definir los prerequerimientos que deben ser logrados antes de que las pruebas de carga puedan comenzar.

El usuario se esforzará para resolver los requerimientos previos indicados por los creadores del sistema.

Lograr prerequerimientos sobresalientes

Fallas en Pruebas de Carga

Los datos de prueba demuestran ser inadecuados.

El usuario asegurará un sistema completo de conveniente y los datos de pruebaprotegidos están disponibles.

Los Creadores indicarán qué se requiere y verificará la conveniencia de los datosde prueba.

Redefinir pruebas de datos Revisar Plan de Pruebas y

modificar componentes (scripts)

Fallas en Pruebas de Carga

La base de datos requiere restaurarse

El administrador del sistema se esforzará para asegurar la base de datos se restaura regularmentesegún los requerimientos exigidos.

Recuperación de datos Bases de Datos Limpias





Versión: <1.0>


Esta tabla muestra algunas de las dependencias que podrian afectar la ejecución del plan de prueba.

Dependencia entre Impacto Potencial o Dependencia DueñosSuministro de electricidad al ambiente donde se presentara el sistema para ser probado. (Si cortan la electricidad).

Evita lña presentación por falta de algun dispositivo a menos de que se cuenta con un equipo portátil.

Portadores de la electricidad

Esta tabla muestra los suspuesto que pueden afectar la ejecución del sistema.

Supuestos a ser probadosImpacto de los supuestos

incorrectos DueñosAlgun virus en la maquina donde se esta trabajando

Puede infundir de manera negativa en el sistema. Podria estrar afectando su buen funcionamiento.

Esta tabla muestra las limitaciones que pueden intervenir en la ejecución del sistema.

LimitacionesImpacto que tienen las limitaciones y

el esfuerzo de las Pruebas DueñosInstalacion del sistema en un equipo de optimas condiciones

Es imposible presentar un sistema en un equipo que no cuenta con los requerimientos especificos.

13. Procedimientos y Gerencia de Procesos

13.1 Midiendo y determinando el grado de la prueba

Ya instalado el sistema en el ambiente donde lo necesitamos se proseguira a seguir el oren de las pruebas

13.2 Determinación de los entregables de éste plan de pruebas

Una vez instalado el sistema este sera revisado sugun la navegabilidad y mediante sus diversos componenetes

13.3 Reportes del problema, escalada y resolución

Los resultados de la evaluación seran presentandos al correspondiente creador del sistema y de esta forma ellos se encargaran de modificar el sistema.

13.4 Estrategias de trazabilidad

Se debe considerar las estrategias apropiadas de trazabilidad para:

Cobertura de la prueba contra especificaciones -- permite la medida el grado de la prueba

Las motivaciones para probar -- permite resaltar la importancia de pruebas para ayudar a determinar si mantenienen o se retiraran las pruebasLos elementos del diseño del software -- activan el seguimiento de los cambios subsecuentes del diseño que harían necesario la reejecución de pruebas o retirarlas

Requerimientos resultantes de los Cambios - activa las pruebas que descubrieron la necesidad para el cambio a ser identificado y reejecuta para verificarque la petición del cambio se ha terminado con éxito.





Versión: <1.0>


13.5 Aprobación y Finalización

El proyecto sera evaluado en un laboratorio de informatica por el profesor Edgar Vidal y la profesora Mayba Uzcateguiz.


plan de pruebas

Documents