Plan de Pruebas Propósito
El propósito de este documento de Plan de Pruebas para el Desarrollo de un sistema informático para gestión de la información del bufete jurídico de la universidad centroamericana, es definir el alcance, enfoque, recursos requeridos, responsables del proceso de pruebas y la descripción de las pruebas a realizarse. Contexto
El proyecto consiste en el desarrollo de un software para la gestión de la información del bufete jurídico, el software permite el manejo de consultas, seguimiento de proyectos, citas, mediaciones realizadas, bitácoras de los casos, búsquedas, casos, responsables de casos, actividades que se realizan en las distintas áreas del bufete (área civil o área Penitenciaria y Penal), además de dar la posibilidad de realizar informes de forma mensual, trimestral y anual, todo esto con el objetivo de agilizar el manejo de los datos en el bufete.
En este documento se contemplan las distintas pruebas a realizar al software ya sea de integridad, unitarias, desempeño, etc.
Alcance
El presente documento abarca la descripción de las pruebas a realizarse y los elementos utilizados en la misma.
Para este proyecto se realizaran las siguientes pruebas:
Pruebas Unitarias: es una forma de probar el correcto funcionamiento de un módulo de código. Esto sirve para asegurar que cada uno de los módulos funcione correctamente por separado.
Integridad: Permite verificar el correcto ensamblaje entre los distintos módulos que componen el sistema desarrollado.
Pruebas del Sistema: Estas pruebas buscan diferencias entre la solución desarrollada y los requerimientos, con el fin de identificar errores que se puedan generar entre la especificación funcional y el diseño del sistema. A continuación se detallan las pruebas del sistema.
Prueba de la seguridad:Verifica el cumplimiento de las políticas de seguridad acordadas para el sistema.
Pruebas Funcionales: La prueba funcional es un proceso para procurar encontrar discrepancias entre el programa y la especificación funcional.
Prueba de Instalación: Se enfoca en evaluar que el elemento a probar se instala como se indica, en diferentes configuraciones de hardware y software.
Pruebas de Aceptación: Pruebas realizadas por los usuarios, para verificar que el sistema se ajusta a sus requerimientos
Estrategia de Pruebas
Como estrategia del proceso del plan de pruebas se utilizara el Ciclo de plan de pruebas, este contempla seis actividades básicas que pueden observarse en el siguiente gráfico:
Figura 33. Proceso del plan de pruebas
Planificación
Para el desarrollo Sistema para la gestión de la información del bufete Jurídico, se considera de gran importancia la ejecución del plan de pruebas, haciéndose necesario la planificación de las mismas, lo que en consecuencia hace necesario tener claro los siguientes planteamientos:
Se planifican pruebas específicamente para el proyecto. Se definen niveles de pruebas a aplicar.
Se especifican las técnicas a utilizar.
Se establece el tiempo para la ejecución de cada una de las pruebas. Uso de herramientas.
Criterios de aceptación. Recursos involucrados.
Planificación Diseño Configuración Ejecución Cierre
Plan de Pruebas
Especificación Casos de Prueba
Además se determinara: El alcance de la aplicación, la complejidad de sus procesos, plataforma/s en las que se debe probar, conocimientos y formación de quienes ejecutarán las pruebas y normativas legales aplicables.
Como resultado de la planificación de las pruebas se obtendrá, Cronograma detallado de la ejecución de las pruebas; donde se especifica qué prueba se realiza, cuánto tiempo se estima para su ejecución, recursos a utilizar (humanos y tecnológicos), formatos a utilizar para el diseño de las pruebas, Formatos a utilizar para el registro y análisis de los resultados de las pruebas, Herramientas a utilizar para la gestión de incidencias, Procedimientos para el control de cambios, herramientas a utilizar para la ejecución de las pruebas.
Diseño
Para el diseño de las pruebas, se tendrán en cuenta aspectos que permitirán encontrar defectos en el periodo de desarrollo del software, la realización de pruebas propias de verificación y validación de datos a como se observa en el siguiente gráfico:
Figura 34. Ciclo de vida del plan de pruebas
Resultado de la ejecución de las Pruebas: En este punto se resaltan las entradas fundamentales que son la partida para la ejecución del plan de pruebas. Ciclo de la Prueba: Las actividades de la prueba se realizarán para una determinada versión del producto, sobre la cual se ejecutan las pruebas y se reportan los incidentes encontrados.
Para cada versión del producto se realizan alguna o todas las tareas asociadas a las pruebas.
En el diseño de la prueba se prepara el análisis de la carga de trabajo, se identifica y describen los casos de la prueba, se identifican y estructuran los métodos de prueba y finalmente se determina la cobertura de las pruebas.
Configuración
En esta actividad se establece el mantenimiento e integridad del software a través del ciclo de vida del proyecto y se proveen contextos de trabajo estables para los posibles cambios antes de ser entregado formalmente en producción.
Administración de Configuraciones: Es el proceso de identificar y definir los elementos o ítems de configuración del sistema, controlando la entrega y el cambio de estos elementos a través del ciclo de vida del sistema, almacenando el estado de los mismos y de las solicitudes de cambio, y verificando la completitud con respecto a los requisitos especificados.
Configuración: Conjunto completo (respecto de la Arquitectura del Sistema, es decir que cada componente está representado) y coherente (respecto de que defina una versión estable del sistema, es decir que las versiones de cada componente se correspondan) de Ítems de Configuración que constituyen un producto de software.
Comité de control de cambios: Grupo con la autoridad para evaluar, aprobar y/o rechazar la implementación de un cambio. El establecimiento de un Comité de control de cambios tiene como objetivo proveer un mecanismo para asegurar que toda solicitud de cambio es direccionada adecuadamente.
Ítem de Configuración: Componente de Software y/o producto de software destinado para ser puesto bajo Administración de Configuraciones.
Solicitud de Cambio: Documento a través del cual el equipo técnico autorizado solicita al Grupo de Desarrollo realizar la corrección de un defecto en el sistema del bufete jurídico o de una mejora sobre la solución antes de su lanzamiento. Ejecución
En cuanto a la ejecución de las pruebas, estas se extienden a lo largo del ciclo de vida de desarrollo del software, es decir que durante las fases derequerimientos, análisis, diseño e implementación se van diseñando las pruebas y al llegar a la etapa de pruebas se inicia la ejecución de lo diseñado anteriormente.
Además se tendrá en cuenta las siguientes especificaciones:
Elementos del sistema, es decir; los módulos y características de la solución que se van a probar.
Se listarán las especificaciones de cada entrada requerida para ejecutar el caso; incluyendo la sincronizaciones entre cada una de estas.
Especificaciones de todas las salidas y las características requeridas como el tiempo y la respuesta para los elementos que se van a probar.
Necesidades del entorno del proceso de ejecución del hardware, software y recurso humano.
Requisitos especiales de procedimiento o restricciones especiales en los procedimientos para ejecutar este caso.
Cierre
En el cierre de las pruebas se presentará un informe de pruebas donde se documentará el resultado de cada una de las pruebas ejecutadas.
Pruebas Unitarias
Las pruebas unitarias tienen como objetivo verificar la funcionalidad y estructura de cada componente individualmente del sistema una vez que ha sido codificado.
Verificar que los módulos del sistema estén libres de errores.
Que todos los caminos lógicos principales deben ejecutarse correctamente en cada módulo de la aplicación.
Todos los tipos de registro de entrada válidos deben ser procesados
Todos los tipos de registro de entrada inválidos deben ser procesados correctamente.
Códigos de vuelta no nulos.
Todas las salidas válidas son procesadas
Objetivo de Prueba:
Comprobar que cada función o pedazo de código funcione correctamente, es decir que lea y guarde los datos correctos.
Técnica: Utilizar técnica de caja blanca ejecutando pedazos de código y
comprobando el correcto funcionamiento de este.
Crear caso de prueba donde se evalúen los datos de entrada que permite el software y que pueden provocar errores en el mismo.
Herramientas requeridas
Nunit, Visual Estudio 2010
Criterios de Terminación:
Todos los métodos y procesos de acceso de base de datos funcionan según lo diseñado y sin ninguna corrupción de los datos.
Prueba de Funcionalidad
La prueba de funcionalidad se verifica la aceptación de datos apropiada, proceso, y recuperación, e implementación apropiada de las reglas de negocio. Este tipo de prueba se basa sobre técnicas de la caja negra; eso está verificando la aplicación y sus procesos internos interactuando con la aplicación vía la Interfaz Gráfica del Usuario (GUI) y analizando la salida o los resultados.
Objetivo de
Prueba:
Verificar la funcionalidad apropiada del sistema, navegación, entrada de datos y recuperación.
Técnica: Ejecutar un caso de prueba, usando datos válidos e inválidos,
para comprobar lo siguiente:
Los resultados previstos ocurren cuando se utilizan los datos válidos.
Se exhibe el error apropiado o los mensajes de alerta cuando se utilizan los datos inválidos.
Cada regla de negocio se aplica correctamente. Herramientas
Requeridas:
Gestor Base de Datos SQL Server Microsoft Visual Studio 2010
Criterios de
Terminación:
Se han ejecutado todas las pruebas previstas.
Se han identificado errores en el funcionamiento del sistema Tabla 9. Prueba de funcionalidad generalidades
Prueba de la seguridad
La prueba de seguridad se enfoca el acceso a los datos o a las funcionalidades del negocio. La prueba de seguridad comprueba que los mecanismos de protección integrados en el sistema realmente lo protejan de irrupciones no apropiadas.
Esta prueba asegura de que, basada en la seguridad deseada, restringe a los actores de las funciones específicas o casos de uso, o los limita en los datos que están disponibles para ellos.
Objetivo de Prueba: Verificar que un actor pueda tener acceso
solamente a esas funciones o datos para los cuales su tipo del usuario tenga permisos proporcionados.
Técnica: Identificar y enumerar cada tipo de usuario y las
funciones o los datos para los que tiene permiso. Crear las pruebas para cada tipo del usuario y verificar cada permiso creando las transacciones específicas a cada tipo del usuario.
Herramienta Nessus
Criterios de
Terminación:
Para cada tipo de usuario conocido la función o los datos apropiados están disponibles, y todas las transacciones funcionan según lo esperado y funcionan en pruebas de función anteriores del uso.
Tabla 10. Prueba de seguridad generalidades
Herramientas
Las herramientas siguientes serán empleadas para este proyecto: NUNIT
Características Prueba
Es un framework libre en Java, para realizar pruebas de carga o estrés utilizando una consola gráfica.
Esta versión hace uso del lenguaje script phyton, lo que permite a cualquier código Java ser encapsulado como una prueba.
Esta herramienta permite utilizar un ambiente de red para realizar las pruebas de carga de forma totalmente distribuida.
Esta herramienta será utilizada para la
ejecución de:
1. Pruebas de Sistema
Recursos del Plan de Pruebas Recurso Humano
El recurso humano que debe estar disponible para la ejecución de las pruebas varía de acuerdo al tipo de prueba. En el siguiente cuadro se especifica el tipo de perfil necesario por tipo de prueba.
Trabajador Responsabilidades específicas o Comentarios
Manejador de Prueba, Manejador del Proyecto de Prueba
Proporciona cuidado de la gerencia. Responsabilidades:
Proporciona la dirección técnica Adquiere recursos apropiados
Proporcione la divulgación de la gerencia Diseñador de
Prueba
Identifica, da la prioridad, y pone a casos de la prueba en ejecución.
Responsabilidades:
Genere el plan de prueba Genere el modelo de la prueba
Evalúe la eficacia del esfuerzo de la prueba
Probador
Ejecuta las pruebas. Responsabilidades:
Ejecute las pruebas Resultados del registro Recupérese de errores
Peticiones del cambio del documento
Manejador del Sistema de Prueba
Asegura el ambiente de la prueba y se manejan y se mantienen los activos.
Responsabilidades:
Administre el sistema de gerencia de la prueba
Instale y maneje el acceso a los sistemas de la prueba Administrador de la
Base de Datos, Manejador de la
base de Datos
Asegura el ambiente de los datos de prueba (base de datos) y se manejan y se mantienen los activos.
Responsabilidades:
Administre los datos de prueba (base de datos)
Diseñador
Identifica y define las operaciones, las cualidades, y las asociaciones de las clases de la prueba.
Responsabilidades:
Identifica y define las clases de la prueba Identifica y define los paquetes de la prueba
Implementador
Instrumentos y pruebas de unidad que la prueba clasifica y los paquetes de la prueba.
Responsabilidades:
crea las clases y los paquetes de la prueba puestos en ejecución en el modelo de la prueba
Tabla 12. Recurso Humano
En este apartado se detallan los criterios de evaluación de las pruebas estos, los cuales estarán dados de forma independiente para cada tipo de pruebas; a continuación se muestra los criterios de evaluación generales de las pruebas ejecutadas
Pruebas Unitarias: Las pruebas unitarias se evalúan por medio de la siguiente tabla.
Elemento a Revisar SI NO No Aplica Observaciones
¿Se realizaron las Pruebas Unitarias con alguna herramienta especializada?
¿Con las pruebas realizadas, cuál fue el porcentaje de cobertura del sistema?
¿El funcionamiento de la prueba unitaria respeta el diseño
establecido?
¿Existe un manejo de errores adecuado?
¿Se cumplió con la estrategia de ejecución de la prueba?
Tabla 13. Prueba unitaria, formato
Pruebas del Sistema: El resultado de estas pruebas será detallado a través del siguiente cuadro:
Caso de Uso <Identificador del
Caso de uso> Descripción del escenario <Número total de casos de prueba ejecutados de acuerdo al escenario> Número de pruebas exitosas <Del total de pruebas ejecutadas, cuantas pruebas fueron exitosas> Número de pruebas Fallidas
<Del total de pruebas ejecutadas, cuantas
pruebas fueron fallidas>
Número de peticiones exitosas <Número de peticiones> Número de Peticiones Fallidas <Número de peticiones >
Número de Errores <Número de errores
ocurridos durante las pruebas>
Tipo de errores
<Descripción del tipo de errores presentados> Tabla 14. Prueba del sistema, formato
Pruebas Funcionales: El resultado de las pruebas funcionales se verá reflejado de acuerdo al siguiente formato.
Información Global del Caso de Prueba CASO DE PRUEBA
No.
<Número del caso de prueba constituido por SP-[número del caso de uso]-[Numero del caso de prueba]>
CASO DE USO: <Identificación del caso de
uso objeto de la prueba>
MODULO DEL SISTEMA <Nombre del módulo al que corresponde el caso de uso objeto de la prueba> Descripción del caso de prueba:
<Descripción de lo que se pretende probar en el caso de prueba> CASO DE PRUEBA
Precondiciones
<Lista de precondiciones que deben cumplirse para realizar la prueba> Pasos de la prueba
<Pasos secuenciales que deben ser ejecutados por el analista de pruebas o usuario, ante el sistema para ejecutar la prueba>
DATOS DE ENTRADA RESPUESTA
ESPERADA DE LA APLICACIÓN
COINCIDE RESPUESTA DEL
SISTEMA
CAMPO VALOR TIPO
ESCEN ARIO SI NO <Descripción del dato de entrada> <Valor que debe ser suminist rado en la prueba para el dato de entrada > <Tipo de escenari o que pretend e probars e: Correcto /Incorrec to> <Respuesta que se espera de la aplicación> <Respuesta que se obtuvo de la aplicación en el momento de la ejecución de la prueba> Post condiciones
Tabla 15. Prueba funcional, formato
Pruebas de Seguridad: El resultado de las pruebas de seguridad se verá reflejado en el siguiente informe o lista de chequeo:
Elemento a Revisar SI NO No
Aplica
Observaciones ¿Se realizaron las pruebas de seguridad con
alguna herramienta especializada?
¿Cuál fue el porcentaje de cobertura de la prueba con relación al sistema total?
¿Qué capas o componentes de la arquitectura se cubrió con la ejecución de las pruebas?
¿Se estableció un criterio para la ejecución de las pruebas? ¿Cuál?
¿Se cumplió la estrategia de ejecución de la prueba?
Tabla 16. Prueba de seguridad, formato
<Lista de pos condiciones que deben cumplirse después de realizar la prueba> RESULTADOS DE LA PRUEBA
Defectos y desviaciones
<Lista de defectos o desviaciones encontrados por el analista o usuario al ejecutar la prueba>
Observaciones Probador
<Observaciones generales del analista o usuario sobre la ejecución de la prueba>
Firma: Nombre: Fecha: