Documento de pruebas by Sistema Automatizado L.B. Rafael Rangel

DOCUMENTO DE PRUEBAS SISTEMA AUTOMATIZADO PARA EL CONTROL ACADÉMICO DEL LICEO BOLIVARIANO “RAFAEL RANGEL”

Integrantes: Acevedo, Mayerling C.I.: V-18.350.361 González, Janeth C.I.: V- 9.793.640 Monreal, Leonard C.I.: V-15.583.657 Provenzali, Frany C.I.: V-17.266.193 Riera, Marbelis C.I.: V-18.376.257 Profesora: Ing. Briceño Doris

Valera, Junio de 2013

DOCUMENTO DE PRUEBAS SALBRR `

INDICE GENERAL Índice General…………………………………………………………………..……….2 1. Introducción…………………………………………………………………..……….3 a. Propósito…………………………………………………………..…………..4 b. Alcance……………………………………………………………………..….4 c. Definiciones, acrónimos y abreviaturas…………………………….……...5 d. Referencias…………………………………………………………….……..5 2. Definición del proceso de prueba…………………………………………….…….5 a. Elementos del software a probar………………………………………..….6 b. Características a probar del software………………………………….…..6 c. Características del software que no se probarán………………………...7 d. Niveles y tipos de pruebas a realizar………………………………….…..7 e. Estrategias y técnicas de pruebas a aplicar……………………………..11 f. Cronograma de actividades de pruebas………………………………….16 g. Responsabilidades de los miembros del grupo de pruebas………..…17 h. Recursos necesarios para aplicar las pruebas……………………..…..17 3. Diseño de Pruebas…………………………………………………………………19 a. Identificación………………………………………………………………..19 b. Objetivo……………………………………………………………………..19 c. Criterios inicio, evaluación y finalización…………………………………20 d. Suite de Prueba…………………………………………………………….20 e. Método y técnica……………………………………………………………21 f. Procedimiento y responsables…………………………………………….23 g. Documentación……………………………………………………………..23

DOCUMENTO DE PRUEBAS SALBRR

1. INTRODUCCIÓN

El contenido de este documento de plan de pruebas se encuentran fundamentados en estándares de calidad que no solo permiten el seguimiento y correcciones a tiempo del software sino que además se encuentra definido por etapas, facilitando el seguimiento y control de los procesos del proyecto en desarrollo con el propósito de garantizar la operatividad y funcionalidad del sistema desarrollado.

Acorde con el enfoque del desarrollo del sistema, el plan de pruebas está basado en el Estándar ANSI/IEEE 829 el cual proporciona una base modelo para la documentación del proceso de pruebas, permitiendo plasmar todos los aspectos clave de las pruebas. El propósito de las mismas en los sistemas es ayudar a la organización de desarrollo, de la calidad de construcción en el software y el sistema durante los procesos de ciclo de vida y para validar que la calidad se logró. Estos procesos de prueba determinan si el producto de desarrollado se ajusta a los requisitos de los procesos y si el software satisface su uso previsto y las necesidades del usuario.

Por tal sentido, lo que hace que este plan de pruebas tenga como propósito establecer las técnicas, herramientas y actividades relacionadas con la ejecución y validación de cada una de las pruebas, incluyendo responsabilidades de cada una de las actividades, los recursos y los prerequisitos que deben ser considerados en el esfuerzo de cada una de las pruebas;

para corroborar y

garantizar el cumplimiento de los requerimientos planteados en el marco del desarrollo del proyecto denominado “Sistema Automatizado para el Control Académico del Liceo Bolivariano Rafael Rangel”. 3

DOCUMENTO DE PRUEBAS SALBRR

a. PROPÓSITO

Este documento tiene como propósito establecer las técnicas, herramientas y actividades relacionadas con la ejecución y validación del plan de pruebas; incluye responsabilidades de cada una de las tareas, los recursos y los prerequisitos que deben ser considerados en el esfuerzo de cada una de las pruebas, permitiendo garantizar el cumplimiento de los requerimientos planteados en el marco del desarrollo del proyecto denominado “Sistema Automatizado para el Control Académico del Liceo Bolivariano Rafael Rangel”.

b. ALCANCE Este “Documento de Pruebas”, se convierte en una guía para desarrollar de una forma organizada las diferentes actividades que se realizarán en el proceso del plan de pruebas en el desarrollo del proyecto denominado “Sistema Automatizado para el Control Académico del Liceo Bolivariano Rafael Rangel”.

La metodologia de pruebas y este documento de plan de pruebas permitirán al equipo de trabajo que participan en el frente de pruebas del proyecto denominado “Sistema Automatizado para el Control Académico del Liceo Bolivariano Rafael Rangel”, evaluar aspectos como: la lógica estructural, la seguridad, la interconexión, el soporte conceptual, las herramientas de apoyo y sobretodo la independencia de aspectos técnicos del desarrollo de la solución tecnológica contratada, tales como: la plataforma tecnológica o la arquitectura de la solución a probar.

DOCUMENTO DE PRUEBAS SALBRR

c. DEFINICIONES, ACRÓNIMOS Y ABREVIATURAS 

El plan de prueba: describe todos los métodos que se utilizarán para verificar que el software satisface la especificación del producto y las necesidades del cliente. Incluye los objetivos de calidad, necesidades de recursos, cronograma, asignaciones, métodos, entre otros.



Casos de prueba: lista los ítems específicos que serán probados y describe los pasos detallados que serán seguidos para verificar el software.



Reporte de pruebas: describen los problemas encontrados al ejecutar los casos de prueba.



Herramientas de pruebas y automatización: documentación de las herramientas empleadas en el proceso de pruebas.



Métricas, estadísticas y resúmenes: indican como ha sido el progreso del proceso de prueba.

d. REFERENCIAS

Para elaborar este documento se siguieron los lineamientos basados en el Estándar ANI/IEEE829, los cuales están establecidos en las especificaciones del Documento del Software de la cátedra Ing. De Software III que está definida en el programa y reglamento del Proyecto Nacional de Formación para Ingeniería en Informática. 2. DEFINICION DEL PROCESO DE PRUEBA

El proceso de pruebas comienza con la generación de un plan de pruebas con base en la documentación del proyecto y la documentación del software a probar. A partir de dicho plan, se entra en detalle diseñando pruebas específicas basándose en la documentación del software a probar. Una vez detalladas las 5

DOCUMENTO DE PRUEBAS SALBRR pruebas se toma la configuración del software que se va a probar para ejecutar sobre ella los casos. A partir de los resultados de salida, se pasa a su evaluación mediante comparación con la salida esperada. A partir de ésta, se pueden realizar dos actividades: 

La depuración (localización y corrección de defectos).



El análisis de la estadística de errores.

a. ELEMENTOS DEL SOFTWARE A PROBAR MODULO ENTRADA Sub. Modulo -Definición de Variables: Define las variables: Datos del estudiante, datos del representante, unidad curricular, año escolar, periodo escolar. MODULO PROCESO Sub. Modulo – Registro de los datos del alumno, representante, periodo escolar, año escolar, unidad curricular, constancia, docente. Sub. Modulo – Consulta de los datos registrados. Sub. Modulo - Modificar datos almacenados. Sub. Modulo – Eliminar datos ya registrados MODULO SALIDA Sub. Modulo -Visualización e impresión de Fichas de Inscripción, constancias.

b. CARACTERISTICAS A PROBAR DL SOTWARE 1. Fluidez de datos 2. Independencia de módulos 3. Soporte del software 4. Interfaz de usuario 6

DOCUMENTO DE PRUEBAS SALBRR

c. CRARACTERISTICAS DEL SOFTWARE QUE NO SE PROBARAN 1. Errores relacionados con el tiempo. 2. Condiciones de error no detectadas. 3. Condiciones especiales de los datos. 4. Invalidez de la información mostrada por pantalla. 5. Interacción con tareas en background. 6. Fallos de configuración/compatibilidad con software 7. Incapacidad de soportar el volumen de carga o fallos hard.

d. NIVELES Y TIPOS DE PRUEBAS

La metodologia de pruebas y este documento de plan de pruebas permitirán al equipo profesionales

expertos que participan en el frente de pruebas del

proyecto denominado “Sistema Automatizado para el Control Académico del Liceo Bolivariano Rafael Rangel”, evaluar aspectos como: la lógica estructural, la seguridad, la interconexión, el soporte conceptual, las herramientas de apoyo y sobretodo la independencia de aspectos técnicos del desarrollo de la solución tecnológica contratada, tales como: la plataforma tecnológica o la arquitectura de la solución

a probar, sin embargo a continuación se describen las diferentes

pruebas a ser aplicadas:

DOCUMENTO DE PRUEBAS SALBRR TIPO DE PRUEBA

UNITARIAS

INTEGRACIÓN

OBJETIVO

Unitarias:

PARTICIPANTES

AMBIENTE

MÉTODO

Programadores

Desarrollo

Caja Blanca

Programadores

Desarrollo

Caja Blanca

Probadores

Desarrollo

Funcional

Permite

verificar

funcionalidad

estructura

cada

individualmente

del

componente

sistema una vez que ha sido codificado.

Integración:

Permite

verificar

correcto

ensamblaje entre los distintos módulos que componen el sistema desarrollado.

SISTEMA:

Sistema:



Carga

pruebas



Volumen

diferencias



Estress

solución



Robustez

y los



Concurrencia,

con el fin de identificar



Interfaz Usuario

Estas (Tester) buscan entre

desarrollada

requerimientos,

de errores que se puedan generar entre la

Recuperación a especificación funcional y el diseño Fallas

DOCUMENTO DE PRUEBAS SALBRR 

Rendimiento



Seguridad



Integridad de las Carga: BD



del sistema.

Valida

aquellos

volúmenes



Interoperabilidad de datos máximos especificados en los Desempeño



Configuración

requerimientos

Funcionales

Volumen:

Esta

prueba

somete

software

grandes

cantidades de datos para determinar si se alcanzan límites que causen

falla

del

software

Estrés:

Valida

aquellos

volúmenes

de datos máximos que resiste antes

sistema

comenzar

con errores.

Robustez: el

Valida si

sistema

mantiene consistente

estable

se y

después

DOCUMENTO DE PRUEBAS SALBRR de

circunstancias

adversas

Concurrencia: Valida la

capacidad

sistema

del

atender

múltiples

solicitudes

departe

los

usuarios que acceden a un mismo recurso.

Interfaz de usuario: Ppermite verificar que la navegación a través de los elementos que se

están

probando,

reflejen las funciones del

negocio

los

requerimientos funcionales.

Rendimiento: Permite validar si la aplicación cumple los criterios de tiempos de respuesta establecidos.

Seguridad: Verifica el cumplimiento de las

DOCUMENTO DE PRUEBAS SALBRR políticas de seguridad acordadas

para

sistema.

Integridad bases

las

datos:

Consiste en asegurar que los métodos y procesos de acceso a la

base

datos

funcionan correctamente

sin

corromper datos.

e.- ESTRATEGIA DE PRUEBAS

TÉCNICAS DE ESPECIFICACIÓN DE LAS PRUEBAS

La estrategia del proceso del plan de pruebas se implementará de acuerdo con lo siguiente:

El ciclo de pruebas comprende seis actividades las cuales deberán ser desarrolladas de la siguiente manera:

PLANIFICACIÓN Para el desarrollo del “Sistema Automatizado para el Control Académico del Liceo Bolivariano Rafael Rangel”, se considera de gran importancia la

DOCUMENTO DE PRUEBAS SALBRR 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: 

planifican

pruebas

personalizando

los

estándares

específicamente para el proyecto de notificaciones. 

Se definen niveles de pruebas a aplicar.



Se especifican las técnicas a utilizar.



Se establece el tiempo para la ejecución de cada una de las pruebas.



Uso de herramientas.



Criterios de aceptación.



Recursos involucrados.

En la definición del plan de pruebas, se valorará: 

El alcance de la aplicación.



La complejidad de sus procesos.



Plataforma/s en las que se debe probar.



Conocimientos y formación de quienes ejecutarán las pruebas.



Normativas legales aplicables.



Otros recursos involucrados.

Se tendrá en cuenta que: 

Las pruebas estarán presentes a lo largo de todo el ciclo de vida del desarrollo, de la solución.



Siempre hay errores.



Probar exhaustivamente el software es imposible. 12

DOCUMENTO DE PRUEBAS SALBRR 

No es recomendable que el programador pruebe sus propios programas.



Se puede disponer de herramientas.



Se debe considerar la importancia de actualización del plan de pruebas con el fin de reflejar los cambios que se produzcan en los requisitos y/o proceso de desarrollo del producto.

Resultado de la planificación: 

Cronograma detallado de la ejecución de las pruebas; donde se especifica qué prueba se realiza, cuánto tiempo se estima para su ejecución, recursos a utilizar (humanos y tecnológicos); este cronograma se encuentra dentro del cronograma general del proyecto y específicamente en la fase desarrollo (ver plan de construcción)



Formatos a utilizar para el diseño de las pruebas.



Formatos a utilizar para el registro y análisis de los resultados de las pruebas.



Herramientas a utilizar para la gestión de incidencias.



Procedimientos para el control de cambios.



Herramientas a utilizar para la ejecución de las pruebas.

DISEÑO DE LAS PRUEBAS

Para el diseño de las pruebas, se tendrán en cuenta aspectos que permitirán encontrar defectos en el periodo de desarrollo del software, la realización de pruebas propias de verificación y validación de datos, según se aclara en los siguientes ítems:

DOCUMENTO DE PRUEBAS SALBRR

Alcance: El alcance de las pruebas estará dado por el marco del “Sistema Automatizado para el Control Académico del Liceo Bolivariano Rafael Rangel”, que se encuentra en desarrollo. 

Modelo Conceptual.



Procesos.



Descripción de Procesos.



Vista de Casos de Uso.



Vista Lógica.



Diseño de las clases y su organización en paquetes y subsistemas.



Vista de Datos.



Vista de Implementación.



Vista de Despliegue.



Vista de Integración con Sistemas Externos.



Vista de Parametrización del Sistema.



Requerimientos no Funcionales.



Prototipos del sistema

C El proceso de planificación se ajusta al comenzar cada ciclo debido a posibles: 

Atrasos de desarrollo



Modificaciones en los requerimientos iníciales



Cambios en el alcance del producto



Calidad del producto

DOCUMENTO DE PRUEBAS SALBRR

EJECUCIร N En el siguiente grรกfico se muestra el modelo estรกndar de ejecuciรณn de pruebas:

Para cada una de las pruebas se realizarรก el siguiente procedimiento:

DOCUMENTO DE PRUEBAS SALBRR

Aquí se tendrán en cuenta las siguientes especificaciones: 

Elementos del sistema, es decir; los módulos y características de la solución que se van a probar.



Se listarán las especificaciones de cada entrada requerida para ejecutar el caso; incluyendo la sincronizaciones entre cada una de estas.



Especificaciones de todas las salidas y las características requeridas como el tiempo y la respuesta para los elementos que se van a probar. Estas especificaciones se harán utilizando los formatos establecidos en el numeral ¡Error! No se encuentra el origen de la referencia. de este plan de pruebas.



Necesidades del entorno del proceso de ejecución del hardware, software y recurso humano.



Requisitos especiales de procedimiento o restricciones especiales en los procedimientos para ejecutar este caso.

f.- CRONOGRAMA DE ACTIVIDADES

El siguiente cuadro muestra el cronograma de actividades para la realización del plan de pruebas:

ACTIVIDAD

TIEMPO

PLANIFICACIÓN 1

Definir estándares

Definir niveles de pruebas a aplicar

Especificar Técnicas a utilizar

Establecer tiempo para la ejecución de cada una de las pruebas

3 Semanas

DISEÑO

DOCUMENTO DE PRUEBAS SALBRR 5

Definir y asignar prioridades

Establecer un orden de Trabajo

Estimar el tiempo de cada funcionalidad

Evaluar los aspectos técnicos

3 Semanas

EJECUCIÓN 9

Pruebas de Caja Blanca

Pruebas de Caja Negra

Pruebas de Interfaz

Pruebas de Integración

3 Semanas

g. RESPONSABILIDADES DE LOS MIEMBROS DEL GRUPO DE PRUEBAS

ACTORES

GRUPO DE PRUEBAS

RESPONSABILIDAD

T.S.U Leonard Monreal

Programador 1

Pruebas de Caja blanca

T.S.U Janeth Gonzales

Programador 2

Pruebas de Caja negra

T.S.U Mayerling Acevedo

Analistas del sistema

Pruebas de Integración

Diseñador

Pruebas de Interfaz

T.S.U Frany Provenzali T.S.U Marbelis Riera

h.- RECURSOS NECESARIOS PARA APLICAR LAS PRUEBAS

Este capítulo identifica los recursos humanos y no humanos (hardware, software, herramientas de soporte, configuración de entorno de pruebas, entre otros), necesarios para desarrollar el proceso del plan de pruebas del “Sistema Automatizado para el Control Académico del Liceo Bolivariano Rafael Rangel”.

DOCUMENTO DE PRUEBAS SALBRR

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. Los perfiles mencionados no necesariamente corresponden a los enunciados en la metodología de pruebas, ya que allí se mencionan perfiles de apoyo al proceso de pruebas y aquí solo se mencionarán los perfiles que van a ejecutar las pruebas o que intervienen directamente en la prueba.

RECURSO DEL SISTEMA Las pruebas se realizaran en un ambiente controlado; a continuación se describen las características de la infraestructura del ambiente de pruebas.

DESCRIPCION Servidor

FUNCIONALIDAD

Montar ambiente de Pruebas con la solución en proceso de desarrollo Software: Instalado Windows 7, Dream Weaver, y configurado AppServer, MySql Hardware Procesador: Intel o compatible: Sistema Pentium IV o superior, memoria RAM: 1Gb, Monitor: 17”LCD, Disco Duro: S CII SATA 80GB, Unidad de DVD ROM: tarjeta de Red, Trajeta de Video, Teclado, Mouse, Unidad de Protección UPS.

CANTIDA D 1

1 1

DOCUMENTO DE PRUEBAS SALBRR

HERRAMIENTAS DE REPORTES Y CONTROL DE INCIDENCIAS La herramienta que se utilizará para la realización del reporte Adobe Acrobat. Adobe Acrobat es una familia de programas informáticos desarrollados por Adobe Systems diseñados para visualizar, crear y modificar archivos con el formato Portable Document Format, más conocido como PDF.

3. DISEÑO DE PRUEBAS

En este punto se diseñan las pruebas que tengan la mayor probabilidad de encontrar el mayor número de errores con la mínima cantidad de esfuerzo y de tiempo.

a. IDENTIFICACIÓN Las pruebas que se realizaran sobre el sistema “Sistema Automatizado para el Control Académico del Liceo Bolivariano Rafael Rangel”, tiene como objetivo comprobar los requisitos iníciales así mismo como los requerimientos funcionales y no funcionales descritos en el documento anterior.

b. OBJETIVOS  Determinar si los requisitos planteados al comienzo del proyecto se están cumpliendo correctamente.  Comprobar que todos los módulos que conforman el sistema estén integrados y funcionen correctamente. 19

DOCUMENTO DE PRUEBAS SALBRR

 Identificar todos los defectos y errores que presente el sistema para proceder a corregirlos.

c. CRITERIO DE INICIO El documento de pruebas del “Sistema Automatizado para el Control Académico del Liceo Bolivariano Rafael Rangel”, tiene como finalidad la entrega de un producto de buena calidad, para tal motivo se identificaran los posibles efectos del sistema y se determinara si es utilizable en un ámbito real.

Evaluación: Todo software debe ser sometido a pruebas antes de su publicación o liberación. En esta documento se le aplicaran pruebas al software, las cuales permitirán mejorar la calidad del software, ya que con la corrección de los errores presentados se garantiza la futura estabilidad operativa del mismo.

Finalización: La ejecución de los procesos de implementación y pruebas van a dar como resultado un producto estable y maduro como para ser entregado a sus usuarios para ser probado.

d. SUITE DE PRUEBA Conjunto de casos de pruebas que serán aplicados al “Sistema Automatizado para el Control Académico del Liceo Bolivariano Rafael Rangel”.

-Pruebas de caja blanca: Toman en consideración la estructura interna (código fuente) del componente ignoran las entradas y salidas del componente, por lo que constituyen pruebas complementarias de caja negra, Son denominadas, también, pruebas de caja de cristal o pruebas estructurales, La prueba de caja 20

DOCUMENTO DE PRUEBAS SALBRR

blanca ideal es aquella que recorre cada uno de los posibles caminos lógicos en un programa, Un camino lógico es una ruta del flujo de control de un programa.

-Pruebas de caja negra: Ignoran la estructura interna del componente o unidad de prueba, Se centran en los requisitos funcionales y Evalúa que tan bien el componente satisface sus requisitos funcionales.

-Pruebas de Integración: Identificar errores introducidos por la combinación de programas probados unitariamente. Determina cómo la base de datos de prueba será cargada. Verificar que las interfaces entre las entidades externas (usuarios) y las aplicaciones funcionan correctamente. Verificar que las especificaciones de diseño sean alcanzadas. Determina el enfoque para avanzar desde un nivel de integración de las componentes al siguiente. -Pruebas de Interfaz: El diseño de interfaz provoca un diálogo hombremáquina que permite un intercambio rápido de información entre los ordenadores y sus usuarios humanos, mientras que la interfaz no interactiva utiliza un soporte de papel para contener la información en el que las entradas normalmente se realizan en formularios especialmente diseñados y las salidas se producen en un listado impreso. Será necesario definir los formatos individuales de las pantallas utilizadas. En el caso de utilizar un paquete estándar, habrá que evaluar la posibilidad de adoptar el tipo de formato del producto.

e. METODOS Y TECNICAS

En este caso se aplicaran los métodos de pruebas de caja blanca, caja negra, pruebas de integración y de interfaz.

DOCUMENTO DE PRUEBAS SALBRR

En la prueba de caja blanca se utilizara la técnica de:

Prueba del camino básico: es una técnica propuesta inicialmente por Tom McCabe la cual le permite al diseñador de casos de prueba obtener una medida de la complejidad lógica de un diseño procedimental y usar esa medida como guía para la definición de un conjunto básico de caminos de ejecución. Los casos de prueba obtenidos del conjunto básico garantizarán que durante la prueba se ejecuta por lo menos una vez cada sentencia del programa. En la prueba de caja negra se utilizara la técnica de: Partición equivalente: Pressman presenta la partición equivalente como un método de prueba de caja negra que divide el campo de entrada de un programa en clases de datos de los que se pueden derivar casos de prueba. Un caso de prueba ideal descubre de forma inmediata una clase de errores que, de otro modo, requerirían la ejecución de muchos casos antes de detectar el error genérico. La partición equivalente se dirige a la definición de casos de prueba que descubran clases de errores, reduciendo así el número total de casos de prueba que hay que desarrollar.

En la prueba de integración se utilizara la técnica de: Utilizar la tecnica top-down la cual se empieza con los módulos del nivel superior y se verifica que los módulos de nivel superior llaman a los de nivel inferior de manera correcta, con los parámetros correctos. En la prueba de interfaz se utilizara la técnica de: Entre los aspectos a considerar en los formatos de pantalla se destacan: encabezamiento, cuerpo principal, pie, teclas de función, teclas de ayuda y líneas de visualización de los mensajes de ayuda.

DOCUMENTO DE PRUEBAS SALBRR

También hay que describir, de forma detallada, los diálogos entre pantallas y su encadenamiento. Para ello, es útil representarlas jerárquicamente, de forma que en los niveles superiores se representen los menús, y en los niveles inferiores las pantallas de diálogos, representativas de funciones o procesos concretos del sistema. En esta representación jerárquica nos interesa identificar los menús o diálogos concretos en función de los grupos de usuarios que los utilicen.

f. PROCEDIMIENTO Y RESPONSABLES

ACTORES

GRUPO DE PRUEBAS

RESPONSABILIDAD

T.S.U Leonard Monreal

Programador 1

Pruebas de Caja blanca

T.S.U Janeth Gonzales

Programador 2

Pruebas de Caja negra

T.S.U Mayerling Acevedo

Analistas del sistema

Pruebas de Integración

Diseñador

Pruebas de Interfaz

T.S.U Frany Provenzali T.S.U Marbelis Riera

g. DOCUMENTACION

PRUEBA DE INTERFAZ

Caso de Prueba #: 1

Lista de Chequeo

Nombre de la Aplicación: Sistema Automatizado Para el Control Académico del Liceo Bolivariano “Rafael Rangel” de Valera Estado Trujillo. 23

DOCUMENTO DE PRUEBAS SALBRR

Módulo/Pantalla/Proceso: Inscripción

Diseñado/ejecutado por: Riera, Marbelis, Acevedo, Mayerling.

Instrucciones: Marque las casillas correspondientes a SI, NO o No APLICA para cada ítem. Si considera que un aspecto se cumple sólo parcialmente, puede indicarlo en la casilla INFORMACIÓN ADICIONAL.

Especificación del diseño de pruebas.

Aspectos a probar

La presente especificación de diseño de pruebas está orientada a probar de manera gráfica el módulo “Inscripción”, perteneciente al Sistema Automatizado Para el Control Académico del Liceo Bolivariano “Rafael Rangel” de Valera Estado Trujillo.

Técnicas de pruebas que se utilizan

La técnica utilizada en el proceso de pruebas es de interfaz. La cual busca chequear

características

como

compresibilidad,

facilidad

aprendizaje,

operabilidad, grado de atracción, accesibilidad y que cumpla con lo solicitado inicialmente.

Entorno de la Prueba: Windows XP, Windows 7, Ubuntu, Mozilla Firefox o Google Chrome, Servidor web APPServer.

DOCUMENTO DE PRUEBAS SALBRR

Identificaci贸n de la prueba

DOCUMENTO DE PRUEBAS SALBRR

Se distribuye la información según estereotipos La información relacionada está agrupada

ADICIONAL

INFORMACION

Organización y distribución

ELEMENTO A REVISAR

NO APLICA

Cuadro N° 1. Cuadro de Chequeo.

X X FORMA

¿Tiene la página la descripción y su título de acuerdo con los estándares? ¿Tiene la página la dimensión correcta?

X COLOR

Es usado funcionalmente (resaltar, agrupar, informar) Su función es reforzada por otros recursos comunicativos Se utiliza de acuerdo a connotaciones culturales y estereotipos El contraste figura –fondo permite legibilidad y evita cansancio visual

X X

X TEXTO

Se utiliza la fuente Verdana ó arial. Su tamaño mínimo es legible en las condiciones habituales de uso. ¿El color del texto es apropiado y contrasta con el fondo?

X X

DOCUMENTO DE PRUEBAS SALBRR

ICONOS La metáfora elegida se asocia al mensaje Los recursos gráficos elegidos logran transmitir el mensaje Los íconos están formalmente coordinados

X X X PREVENCION

Se requiere confirmación del usuario antes de una acción destructiva Hay mecanismos de validación de las entradas Se advierte a los usuarios de las posibles consecuencias de una acción destructiva

X X

ACTIVIDAD ¿Tiene los encabezados de título y nombre de aplicación correctos? ¿Las etiquetas de los campos son claras y representativas? ¿Los campos de despliegue están completamente inhabilitados y del color respectivo? ¿El formulario tiene la dimensión correcta?

X GENERAL

El sistema incorpora X documentación de ayuda La ayuda se invoca según X estándares Fuente: Grupo de Desarrolladores (2013)

DOCUMENTO DE PRUEBAS SALBRR

PRUEBA DE CAJA NEGRA Caso de Prueba #: 2

Particiones Equivalentes Nombre de la Aplicación: Sistema Automatizado Para el Control Académico del Liceo Bolivariano “Rafael Rangel” de Valera Estado Trujillo.

Módulo/Pantalla/Proceso: Registro de Estudiantes

Diseñado/ejecutado por: González, Janeth, Monreal, Leonard.

Especificación del diseño de pruebas.

Aspectos a probar

La presente especificación de diseño de pruebas está orientada a probar de manera funcional el módulo “Registro de Estudiantes”, perteneciente a la Aplicación Sistema Automatizado Para el Control Académico del Liceo Bolivariano “Rafael Rangel” de Valera Estado Trujillo.

Técnicas de pruebas que se utilizan

La técnica utilizada en el proceso de pruebas es de caja negra, específicamente, particiones equivalentes. La cual divide el campo de entrada de un programa en clases de datos de los que se pueden derivar casos de prueba. Un caso de prueba ideal descubre de forma inmediata una clase de errores que, 28

DOCUMENTO DE PRUEBAS SALBRR de otro modo, requerirían la ejecución de muchos casos antes de detectar el error genérico. La partición equivalente se dirige a la definición de casos de prueba que descubran clases de errores, reduciendo así el número total de casos de prueba que hay que desarrollar.

Identificación de la prueba

DOCUMENTO DE PRUEBAS SALBRR

Identificador único para cada campo del módulo Cedula Nombre Apellido Fecha de Nacimiento Sexo Dirección Teléfono Cédula del Estudiante

A B C D E F G H

En la tabla anterior se le asignó un identificador único a cada atributo del módulo registro de estudiante, los cuales serán utilizados para referirse a ellos en la especificación de los casos de prueba. Especificación de Casos de Pruebas

A continuación se describen las Clases de Equivalencia identificadas para el módulo “Registro de Estudiante”

Campo Cedula (A)

Nombre (B) Apellido (C) Fecha de Nacimiento (D) Sexo (E) Dirección (F)

Módulo Registro de Estudiante Clases de Equivalencia Clases Válidas Clases no válidas (2) Vacio (3) < 100000 (1) [100000-99999999] (4) > 99999999 (5) No es número (2) Vacio (6) [A..Z , a..z] (7) [0..9] (2) Vacio (6) [A..Z , a..z] (7) [0..9] (2) Vacio (8) (F.A.-F.N) >=18 and (9) {(F.A.-F.N) < 18 ó (F.A.-F.N) <=80 (F.A.-F.N) >80} Vacio (2) (10) {M,F} (11) ∉ {M,F} (2) Vacio (12) <= 50 Caracteres >=1 (13) >50 caracteres <1 30

DOCUMENTO DE PRUEBAS SALBRR Teléfono (G)

(14)

<= 11 Caracteres

Cédula Representante (H)

(1) [10000099999999]

(15) (2) (3) (4) (5) (14)

>11 caracteres Vacio < 100000 > 99999999 No es número No existe

Identificación de los Casos de Prueba Caso de Clase de Descripción Prueba Campo Equivalencia usada 1 A 1,2,3,4,5 2 B 6,2,7 Se utilizaran todas las clases 3 C 6,2,7 válidas y no válidas. 4 D 2,8,9 Los campos que no se están 5 E 2,10,11 evaluando se les colocarán una 6 F 2,12,13 clase válida. 7 G 14,15 8 H 1,2,3,4,5,14 Casos de Prueba

En cada caso de prueba se utilizarán valores validos y no validos para la columna “campo”, para efectos del caso se prueba se asume que el resto de los valores para los demás campos son válidos. Caso de Prueba 1 Campo

Equival.

Valor

Resultado Esperado

(A)

(1)

10333241

Que registre el Estudiante

(A)

(2)

(A)

(3)

90000

(A)

(4)

10000000 0

Resultado obtenido Estudiante registrado satisfactoriamente

DOCUMENTO DE PRUEBAS SALBRR

(A)

(5)

Emita mensaje indicando que sólo debe escribir números.

AEDEDD

Caso de Prueba 2 Campo

Equival .

Valor

Resultado Esperado

(B)

(6)

Pepe

Que registre el Estudiante

(B)

(2)

(B)

(7)

Resultado obtenido Estudiante registrado satisfactoriamente

Emita mensaje de error indicando que el nombre es obligatorio Emita mensaje de error Emita mensaje indicando que no admite números.

84548

Caso de Prueba 3 Campo

Equival .

Valor

Resultado Esperado

(C)

(6)

Trueno

Que registre el Estudiante

(C)

(2)

(C)

(7)

Resultado obtenido Estudiante registrado satisfactoriamente

Emita mensaje de error indicando que el nombre es obligatorio Emita mensaje de error Emita mensaje indicando que no admite números.

84548

Caso de Prueba 4 Campo

Equival.

Valor

Resultado Esperado

(D)

(8)

22/07/1981

Que registre el Estudiante

(D)

(2)

Resultado obtenido Estudiante registrado satisfactoriamente

Emita mensaje de error indicando que la fecha de nacimiento es obligatorio

DOCUMENTO DE PRUEBAS SALBRR

(D)

(9)

22/07/2005

Emita mensaje de error indicando que debe ser mayor de edad

Caso de Prueba 5 Campo

Equival.

Valor

Resultado Esperado

(E)

(10)

Que registre el Estudiante

(E)

(2)

(E)

(9)

Resultado obtenido Estudiante registrado satisfactoriamente

Emita mensaje de error indicando que el checkbox de sexo obligatorio Emita mensaje de error indicando que los valores permitidos son M 贸 F

Caso de Prueba 6 Campo

Equival.

Valor

Resultado Esperado

(F)

(12)

Calle 10, Valera

Que registre el Estudiante

(F)

(2)

(F)

(13)

Resultado obtenido Estudiante registrado satisfactoriamente

Emita mensaje de error indicando que la direcci贸n no puede estar vac铆a. Emita mensaje de (texto mayor error indicando que a 50 no puede exceder los caracteres) 50 caracteres Caso de Prueba 7

Campo

(G)

Equival.

(14)

Valor

02712222222

Resultado Esperado Que registre el Estudiante

Resultado obtenido Estudiante registrado satisfactoriamente

DOCUMENTO DE PRUEBAS SALBRR

(G)

(15)

(texto mayor a 12 caracteres)

Emita mensaje de error indicando que no debe exceder los 12 caracteres

Caso de Prueba 8 Campo

Equival.

Valor

Resultado Esperado

(A)

(1)

10333241

Que registre el Estudiante

(A)

(2)

(A)

(3)

90000

(A)

(4)

100000000

(A)

(5)

AEDEDD

(A)

(14)

23254

Resultado obtenido Estudiante registrado satisfactoriamente

Emita mensaje indicando que el nro. de la cédula es obligatorio Emita mensaje indicando que el número de cédula es un número inválido. Emita mensaje indicando que el número de cédula es un nro. invalido. Emita mensaje indicando que sólo debe escribir números. Emita mensaje indicando que el representante no existe

PRUEBA DE CAJA BLANCA Caso de Prueba #: 3

Camino Básico Nombre de la Aplicación: Sistema Automatizado Para el Control Académico del Liceo Bolivariano “Rafael Rangel” de Valera Estado Trujillo.

Módulo/Pantalla/Proceso: Registro de Ano Escolar

DOCUMENTO DE PRUEBAS SALBRR Diseñado/ejecutado por: Monreal, Leonard, González, Janeth. Especificación del diseño de pruebas.

Aspectos a probar

La presente especificación de diseño de pruebas está orientada a probar de manera funcional el módulo “Registro de Ano Escolar”, perteneciente a la Aplicación Sistema Automatizado Para el Control Académico del Liceo Bolivariano “Rafael Rangel” de Valera Estado Trujillo.

Técnicas de pruebas que se utilizan

La técnica utilizada en el proceso de pruebas es de caja blanca, específicamente, caminos básicos. La cual permite corroborar si se ejecutan todos los caminos, alternativas (true, false), loops, entre otros.

Identificación de la prueba

DOCUMENTO DE PRUEBAS SALBRR

C贸digo interno del formulario Ano Escolar (Modelo) <?php $inicializar=true; if (isset($_POST['btnAccion'])){ include ("../funciones/conexion.php"); $anocodigova =htmlspecialchars(mysql_real_escape_string($_POST['txtcodigo'])); $anonombreva =htmlspecialchars(mysql_real_escape_string($_POST['txtnombre'])); $anoestatusen =htmlspecialchars(mysql_real_escape_string($_POST['rdestatus'])); $accion = htmlspecialchars(mysql_real_escape_string($_POST['btnAccion'])); switch ($accion){ case "Salir": session_destroy(); echo "<script languaje='javascript'>alert('Sesi贸n Cerrada')</script>"; $url="../controladores/index.php"; echo "<SCRIPT>window.location='$url';</SCRIPT>"; break; case "Guardar": $comandoSQL ="SELECT * FROM anoescolar WHERE anocodigova = '$anocodigova' LIMIT 1"; $resultado=mysql_query($comandoSQL) or die(mysql_error()); if (mysql_num_rows($resultado)>0){ $comandoSQL ="UPDATE anoescolar SET anonombreva = '$anonombreva', anoestatusen ='$anoestatusen' WHERE anocodigova = '$anocodigova'"; mysql_query($comandoSQL) or die(mysql_error()); echo "<script languaje='javascript'>alert('Informaci贸n Modificada')</script>"; $inicializar=true; break; } else{ $comandoSQL ="INSERT INTO anoescolar VALUES ('$anocodigova', '$anonombreva', '$anoestatusen')"; mysql_query($comandoSQL) or die(mysql_error()); echo "<script languaje='javascript'>alert('Informaci贸n Almacenada')</script>"; } $inicializar=true; break; case "Eliminar":

4 5

7 8

9 10 11

14 15

16 17

18 19 20

if ($_SESSION['usuarioNivel']=="A"){ $comandoSQL ="SELECT * FROM anoescolar WHERE anocodigova = '$anocodigova' LIMIT 1"; $resultado=mysql_query($comandoSQL) or die(mysql_error()); if (mysql_num_rows($resultado)>0){ $comandoSQL ="SELECT * FROM cabecerainscripcion WHERE txtcodigoae = '$anocodigova' LIMIT 1"; $resultado=mysql_query($comandoSQL) or die(mysql_error()); if (mysql_num_rows($resultado)>0){

DOCUMENTO DE PRUEBAS SALBRR echo 21

"<script

languaje='javascript'>alert('No

puede

Eliminar, ya lo inscribi贸 en este A帽o')</script>"; } else{ $comandoSQL

="DELETE

FROM

anoescolar

WHERE

anocodigova = '$anocodigova'"; mysql_query($comandoSQL) or die(mysql_error()); echo "<script languaje='javascript'>alert('Informaci贸n

Eliminada')</script>"; } } else{ echo "<script languaje='javascript'>alert('No Existe')</script>"; } $inicializar=true; break;

} else{ 25

echo "<script languaje='javascript'>alert('No puedes Elimimnar')</script>";

} case "Buscar": $comandoSQL ="SELECT * FROM anoescolar WHERE anocodigova 27 '$anocodigova' LIMIT 1"; $resultado=mysql_query($comandoSQL) or die(mysql_error()); if (mysql_num_rows($resultado)>0){ 28 $registro=mysql_fetch_array($resultado,MYSQL_ASSOC); $anonombreva = $registro['anonombreva']; $anoestatusen=$registro['anoestatusen']; 29 $inicializar=false; break; } else{ echo "<script languaje='javascript'>alert('No Existe')</script>"; 30 $inicializar=true; } break; 31 case "Consultar": $comandoSQL ="SELECT * FROM anoescolar"; 31 $resultado=mysql_query($comandoSQL) or die(mysql_error()); if (mysql_num_rows($resultado)>0){ 32 26

echo "<table border='1'> <tr> <th>Codigo</th> <th>Nombre</th> <th>Estatus</th> </tr>"; while ($registro=mysql_fetch_array($resultado,MYSQL_ASSOC)){ echo "<tr>"; echo "<td>",$registro['anocodigova'], "</td>"; echo "<td>",$registro['anonombreva'], "</td>"; echo "<td>",$registro['anoestatusen'], "</td>"; echo "<tr>"; } echo "</table><br>";

} break; 36

DOCUMENTO DE PRUEBAS SALBRR default: $inicializar=true; mysql_close($enlaceConec);

} } if($inicializar==true){ $anocodigova=''; $anonombreva = ''; $anoestatusen='A'; }

Grafo de Flujo del C贸digo interno del formulario Ano Escolar (Modelo)

DOCUMENTO DE PRUEBAS SALBRR

Complejidad Ciclomática del Grafo CC(G) = e – n + 2, donde e representa el número de aristas y n el número de nodos.

e=42

n=37 CC(G)=42 – 37 + 2

CC(G)= 12

Caminos Básicos para Realizar las Pruebas (12)

C1: 1,2,38 C2: 1,3,4,37,38 C3: 1,3,4,31,,38 C4: 1,3,4,26,27,28,29 C5: 1,3,4,26,27,28,30 C6: 1,3,4,15,16,17,18,19,20,21 C7: 1,3,4,15,16,17,18,19,20,22 C8: 1,3,4,15,16,17,18,23 C9: 1,3,4,7,8,9,10,11,12,14 C10: 1,3,4,7,8,9,10,13,14 C11: 1,3,4,5,6 C12: 1,3,4,5,38