Download Plan de Pruebas de Software

Plan de Pruebas de
Software
STP
01/12/2012
Herramienta para el seguimiento de las pruebas de software realizadas para el
sistema DiaFoot.
CAMILA ANDREA ROJAS PINEDA
HISTORIAL DE CAMBIOS
FECHA
VERSIÓN
DESCRIPCIÓN
RESPONSABLE
13-11-12
1.0
Organización
documento.
14-11-12
1.1.
Sección 1
Camila Andrea Rojas Pineda
15-11-12
1.2
Secciones 1 y 2
Camila Andrea Rojas Pineda
16-11-12
1.3
Secciones 3 y 4
Camila Andrea Rojas Pineda
17-11-12
1.4
Secciones restantes Camila Andrea Rojas Pineda
y Pruebas y Registro
18-11-12
1.5
Sección 6, Pruebas y Camila Andrea Rojas Pineda
Registro
19-11-12
1.6
Pruebas y Registro
del Camila Andrea Rojas Pineda
Camila Andrea Rojas Pineda
Tabla 1: Historial de cambios
TABLA DE CONTENIDO
HISTORIAL DE CAMBIOS .....................................................................................................................1
TABLA DE CONTENIDO .......................................................................................................................3
ÍNDICE DE TABLAS ..............................................................................................................................5
1
2
INTRODUCCIÓN ..........................................................................................................................6
1.1.
Objetivos ............................................................................................................................6
1.2.
Estrategia de Pruebas ...........................................................Error! Bookmark not defined.
1.3.
Alcance ...............................................................................................................................6
1.4.
Referencias .........................................................................................................................7
1.5.
Definiciones, abreviaciones y acrónimos ............................................................................7
ARTEFACTOS DE PRUEBA ...........................................................................................................9
2.1
Módulos del Programa .......................................................................................................9
2.2
Procedimientos de Usuario ..............................................................................................10
3
CARACTERISTICAS A SER PROBADAS ........................................................................................11
4
CARACTERÍSTICAS QUE NO SERAN PROBADAS.........................................................................12
5
APROXIMACION .......................................................................................................................13
6
5.1
Pruebas Unitarias .............................................................................................................13
5.2
Pruebas de Frontera .........................................................................................................13
5.3
Pruebas de Integración .....................................................................................................14
5.4
Pruebas de Sistema ..........................................................................................................14
PROCESO DE PRUEBAS .............................................................................................................15
7
ANEXO ......................................................................................................................................20
7.1
Anexo 1: Reportes de Pruebas .........................................................................................20
ÍNDICE DE TABLAS
TABLA 1: HISTORIAL DE CAMBIOS ................................................................................ 2
TABLA 2: DEFINICIONES, ACRÓNIMOS Y ABREVIACIONES ..................................................... 7
TABLA 3: MÓDULOS A PROBAR EN EL SISTEMA ............................................................... 10
TABLA 4. CARACTERÍSTICAS A SER PROBADAS ............................................................... 11
TABLA 5. CARACTERÍSTICAS QUE NO SERÁN PROBADAS. .................................................... 12
TABLA 6. PRUEBAS UNITARIAS. ................................................................................ 13
TABLA 7. PRUEBAS DE FRONTERA .............................................................................. 13
TABLA 8. ENTREGABLE DE LA PRUEBA. ......................................................................... 13
TABLA 9. PRUEBA DE INTEGRACIÓN. ........................................................................... 14
TABLA 10. RESULTADOS PRUEBA INTEGRACIÓN .............................................................. 14
TABLA 11. PRUEBAS DE SISTEMA .............................................................................. 14
TABLA 12. RESULTADOS PRUEBAS DE SISTEMA. ............................................................. 14
TABLA 13: CASO DE PRUEBA 1 ................................................................................. 15
TABLA 14: CASO DE PRUEBA 2 ................................................................................. 16
TABLA 15: CASO DE PRUEBA 3 ................................................................................ 16
TABLA 16: CASO DE PRUEBA 4 ................................................................................. 16
TABLA 17: CASO DE PRUEBA 5 ................................................................................ 17
TABLA 18: CASO DE PRUEBA 6 ................................................................................ 17
TABLA 19: CASO DE PRUEBA 7 ................................................................................. 18
TABLA 20: CASO DE PRUEBA 8 ................................................................................ 19
TABLA 21: CASO DE PRUEBA 9 ................................................................................. 19
TABLA 22: CASO DE PRUEBA 10 .............................................................................. 19
1
INTRODUCCIÓN
1.1.
Objetivo
El presente plan de pruebas fue utilizado para comprobar las funcionalidades del sistema DiaFoot
según los requerimientos, apoyando el proceso de trazabilidad y calculando el porcentaje de
avance en la implementación de los mismos.
1.2.
Alcance
Las pruebas realizadas se dividen en tres grupos:
Pruebas de
Sistema
Pruebas de
Integracion
Pruebas unitarias
(Pruebas Frontera)
Ilustración 1: Alcance del plan de pruebas
1.3.
Referencias
[1]. IEEE Computer Society, IEEE Standard For Software Test Documentation, Disponible en:
http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=573169, [Última consulta: 9 de
enero de 2010].
[2]. Sommerville I, INGENIERÍA DE SOFTWARE. Séptima Edición. Madrid. España: Pearson
Educación; 2005.
[3]. Grupo de Construcción de Software Universidad de los Andes, Planes de Prueba,
Disponible
en:
http://chie.uniandes.edu.co/~gsd/index.php?option=com_content&task=category&sectio
nid=8&id=101&Itemid=183, [Última consulta: 10 de enero de 2010]
[4]. Bruegge B, Dutoit AH, INGENIERÍA DE SOFTWARE ORIENTADO A OBJETOS. Primera
Edición. Naucalpan. México: Pearson Educación; 2002.
[5]. Buitrago, V. Cáceres, D. Loaiza, C. Medina, O. Muñoz, R. Tenjo, J. Plan de Pruebas de
Software (STP). PIRATE RISK. 2009.
1.4.
Definiciones, abreviaciones y acrónimos
CONCEPTO
DESCRIPCIÓN
AS
Arquitectura de Software
ANS
Asignación Numerica Simple (Método de Priorización)
ERMT
Hace referencia a las iniciales del Nombre designado para la
herramienta, el cual es: Easy Requirement Management Tool.
IS
Ingeniería de Software
STP
Software Tester Plan
Método Wiegers
Método de Priorización de Wiegers
Tabla 2: Definiciones, acrónimos y abreviaciones
2
ARTEFACTOS DE PRUEBA
2.1 Módulos del Programa
A continuación se especificará los módulos junto con sus respectivas pruebas. Cada uno de los
módulos son los especificados en el Diagrama de Arquitectura de DiaFoot.
Modulo
Presentación
Pruebas
Descripción
Facilidad de uso
El usuario puede navegar fácilmente a través de
la aplicación y sea DiaFoot quien lo guie durante
su sesión.
Look & feel
Apariencia del sistema que le permite al usuario
tener una interacción agradable con DiaFoot.
Lógica de Negocio Funcionalidad
(Logic)
El sistema debe poder realizar los
requerimientos establecidos con el cliente que
tuvieron mayor priorizad en la etapa de
priorización.
Acceso a Archivos
El sistema debe tener acceso a los datos de los
reportes en archivos de tipo PDF.
Persistencia
Conexión a base de Acceso y modificación
datos
El acceso a la información de los usuarios de
DiaFoot y la modificación de los datos según las
acciones de los mismos se debe se deben ver
reflejados en la Base de datos del sistema sin
que se presenten problemas de consistencia e
integridad.
NO funcionales
El sistema debe cumplir con los requerimientos
no funcionales con mayor prioridad según el
No funcionales
documento SRS de este proyecto.
Tabla 3: Módulos a probar en el sistema
2.2 Procedimientos de Usuario
Con el fin de hacer uso adecuado de la herramienta DiaFoot el usuario necesita documentación
acerca de su instalación y uso. Para lograr este cometido, se crearon guías de usuario y manuales
que aclaran el funcionamiento del sistema y describen a groso modo las funcionalidades
disponibles. Estos documentos se elaboraron teniendo en cuenta atributos de calidad que apoyan
el entendimiento de los mismos. [1] Los atributos que se tuvieron en cuenta para promover la
calidad de los documentos son:




Claro: Las instrucciones brindadas en los documentos deben ser explícitas y gráficas para
ayudar al usuario a la navegación de las funcionalidades que ofrece la herramienta.
Correcto: No existen errores de idioma referentes a la semántica, sintáctica, ortografía en
el documento.
Completo: Toda la información que se desee incluir con respecto a la herramienta debe
estar consignada dentro del documento en vez de hacer enlaces a documentos anexos.
Coherente: No existen incoherencias, ambigüedades, ni incongruencias dentro del
documento que conduzcan al usuario a cometer errores.
Los documentos a entregar con la herramienta son:
Manual de usuario
•Documento que contiene las instrucciones de
manejo de la herramienta.
Manual de Instalación
•Documento que contiene instrucciones y
especificaciones del sistema donde se instala la
herramienta
Ilustración 2: Documentos y responsables.
3
CARACTERISTICAS A SER PROBADAS
En esta sección se encuentran las características de la herramienta a ser probadas con un caso de
estudio específico.
Característica
Descripción
Módulo
Requerimientos Funcionales
Se debe tener en cuenta el criterio de
aceptación y dependencias, para
realizar pruebas en los módulos.
Además se debe utilizar el documento
de casos de uso para tener claro los
casos de éxito y fallo, y si la
herramienta cumple con ellos.
Lógica de Negocio
Se
tienen
en
cuenta
las
especificaciones
de
aceptación
planteadas en el documento SRS.
Requerimientos
Funcionales
Requerimientos
Funcionales
No
Tabla 4. Características a ser Probadas
Acceso a Archivos
Conexión a base de
datos
No
4
CARACTERÍSTICAS QUE NO SERAN PROBADAS
En esta sección se encuentran las características de la herramienta a ser probadas con un caso de
estudio específico.
Característica
Requerimientos con
Prioridad 3 y 2
Descripción
Debido a que DiaFoot es un prototipo, se
realizó la implementación de los
requerimientos que obtuvieron prioridad
1. Por esta razón, los requerimientos con
prioridad 3 y algunos de prioridad 2 no
fueron implementados y por lo tanto no
serán probados.
Módulo
Lógica de Negocio
Acceso a Archivos
Conexión a base de datos
Tabla 5. Características que no serán probadas.
5
APROXIMACION
A continuación se describen los tipos de pruebas que se realizaron a DiaFoot.
5.1 Pruebas Unitarias
Se realizó pruebas de cada requerimiento según la especificación del mismo en el documento SRS.
NOMBRE
Pruebas
ACTIVIDADES
TIEMPO ESTIMADO
MÉTODOS
O
HERRAMIENTAS
ENTREGABLES
Unitarias
IDENTIFICADOR
Chequeo de requerimientos del sistema
30 minutos por unidad
Netbeans
U01
Lista de chequeo sobre el cumplimiento del requerimiento, ¿realiza lo
que el requerimiento describe?
Tabla 6. Pruebas Unitarias.
5.2 Pruebas de Frontera
Se probó DiaFoot con valores límite y así observar su comportamiento en cada caso.
NOMBRE
Pruebas de Frontera
IDENTIFICADOR F01
ACTIVIDADES
Se realizarán pruebas con los valores límites y mínimos que debe recibir
el programa.
TIEMPO ESTIMADO
15 minutos por prueba
MÉTODOS
O Netbeans
HERRAMIENTAS
Tabla 7. Pruebas de Frontera
En cuanto a los entregables de esta prueba se llenara la siguiente tabla:
Nombre
Valor máximo
Resultado esperado
Resultados obtenidos
Estado
Comentarios
Identificador
Valor mínimo
Funciona:
Tabla 8. Entregable de la prueba.
T01
No funciona:
5.3 Pruebas de Integración
Las pruebas de integración, como su nombre lo indica, son pruebas hechas a un conjunto de
requerimientos, en este caso se distribuyen en los tipos de requerimientos que se definieron en el
documento SRS.
NOMBRE
Pruebas de Integración
IDENTIFICADOR
ACTIVIDADES
Validación de requerimientos
IT01
TIEMPO ESTIMADO
15 minutos por pruebas
MÉTODOS
O Netbeans
HERRAMIENTAS
Texto donde se indica si se tiene un correcto funcionamiento o no.
ENTREGABLES
Tabla 9. Prueba de Integración.
ID
GRUPO DE REQUERIMIENTOS
Grupo de requerimientos que
están relacionados dentro del
grafo de dependencias
RESULTADOS DE LA PRUEBA
Resultado de la prueba.
Tabla 10. Resultados Prueba Integración
5.4 Pruebas de Sistema
Las pruebas de sistema son pruebas realizadas a la herramienta como un conjunto, que casos de
uso cumple a cabalidad, con rutas de éxito y fallo, que han sido definidas en el documento de
Casos de Uso.
NOMBRE
Pruebas
ACTIVIDADES
TIEMPO ESTIMADO
MÉTODOS
O
HERRAMIENTAS
ENTREGABLES
sistemas
IDENTIFICADOR ST01
Se realizarán pruebas generales de funcionamiento del sistema
15 minutos
Netbeans
Informe generado por el responsable de esta prueba el cual informara si se
tiene un correcto funcionamiento o no.
Tabla 11. Pruebas de Sistema
ID
CASO DE USO
RESULTADOS DE LA PRUEBA
Grupo de requerimientos que Resultado de la prueba.
están relacionados dentro del
grafo de dependencias
Tabla 12. Resultados Pruebas de Sistema.
6
PROCESO DE PRUEBAS
En esta sección se presentan los casos de pruebas generales para usarlos con la herramienta
ERMT. Cada cuadro está asociado a un caso de Uso, desde ahí se desglosa en los diferentes
módulos involucrados para el funcionamiento y se evalúa el resultado obtenido. En las siguientes
tablas, se muestran los casos de pruebas a realizar:
NOMBRE
PROPÓSITO
PRERREQUISITOS
UBICACIÓN
ENTRADA
ESTADO FINAL
PASOS
Módulos Asociados
Actualizar registros de glucosa en PRUEBAS
P1
base de datos
Verificar que en el momento de hacer un ingreso de datos en el sistema se
vean reflejados en la base de datos como registros nuevos.
 Tener un perfil de usuario creado en el sistema o hacer la solicitud
de creación de uno.
 Tener una sesión iniciada
 Llenar los campos del sistema.
Base de datos MySQL y ventana DiaFoot
 Datos solicitados por DiaFoot
o Datos Glucosa
o Encuesta síntomas
o Ventana Actividad física
La base de datos tiene nuevos registros
1. Visitar la ventana “Datos Glucosa”.
2. Escoger la comida del día.
3. Escoger la hora de la comida elegida.
4. Ingresar el valor de glucosa para la comida y hora elegidas.
5. Clic en “ingresar”.
6. Ingresar datos solicitados del historial (Responsable y
Justificación).
 Conexión
 Acceso a datos
Tabla 13: Caso de Prueba 1
NOMBRE
PROPÓSITO
PRERREQUISITOS
UBICACIÓN
ENTRADA
ESTADO FINAL
PASOS
Generar reporte diario de usuario PRUEBAS
P2
Verificar la creación de reportes diarios de paciente cada vez que se
solicite.
 Existen registros en la base de datos asociados a un paciente.
Base de datos MySQL, ventana de Análisis en DiaFoot
 Selección dl día.
Creación de un documento en formato PDF almacenado en la carpeta de
instalación de DiaFoot. Este documento contiene los datos referentes al
reporte del paciente.
 Navegar en la pestaña “Análisis”
 Selección de la acción que desea hacer
Módulos Asociados
o Crear reporte diario
 Selección del día o rango de fechas.
Clic en “Generar Reporte Diario”.
 Acceso a archivos, conexión.
Tabla 14: Caso de Prueba 2
NOMBRE
PROPÓSITO
PRERREQUISITOS
UBICACIÓN
ENTRADA
ESTADO FINAL
PASOS
Módulos Asociados
Generar reporte mensual de PRUEBAS
P3
usuario
Verificar la creación de reportes diarios de paciente cada vez que se
solicite.
 Existen registros de varios días en la base de datos asociados a un
paciente.
Base de datos MySQL, ventana de Análisis en DiaFoot
 Selección de fecha .
Creación de un documento en formato PDF almacenado en la carpeta de
instalación de DiaFoot. Este documento contiene los datos referentes al
reporte del paciente.
 Navegar en la pestaña “Análisis”
 Selección de la acción que desea hacer
o Crear reporte mensual
 Selección mes.
Clic en “Generar Reporte Mensual”.
 Acceso a archivos, conexión.
Tabla 15: Caso de Prueba 3
NOMBRE
PROPÓSITO
PRERREQUISITOS
UBICACIÓN
ENTRADA
ESTADO FINAL
PASOS
Módulos Asociados
Generar Consejo
PRUEBAS
P4
Verificar que el sistema genera consejos a los pacientes según los datos de
síntomas ingresados.
 Debe haber síntomas ingresados, ó
 Debe haber datos de “Actividad Física” ingresados
Base de datos de MySQL, Pestaña Datos Glucosa, Pestaña Actividad Física
 Datos glucosa del paciente
 Datos actividad física del paciente
Ventana emergente con un consejo.
PARA GENERAR CONSEJO CON SÍNTOMAS
1. Visitar la pestaña “Síntomas”
2. Realizar la encuesta.
PARA GENERAR CONSEJO CON ACTIVIDAD FÍSICA
1. Visitar la pestaña “Actividad Física”.
2. Llenar los datos de actividad física realizada en el día
3. Aparece un consejo.
PARA GENERAR CONSEJO CON DATOS GLUCOSA
1. Visitar la pestaña “Datos Glucosa”.
2. Llenar los datos de actividad física realizada en el día
 Conexión, Lógica del negocio
Tabla 16: Caso de Prueba 4
NOMBRE
PROPÓSITO
PRERREQUISITOS
UBICACIÓN
ENTRADA
ESTADO FINAL
PASOS
Módulos Asociados
Generar alerta
PRUEBAS
P5
Verificar que el sistema genera alertas a partir de los datos ingresados en
la pestaña “Clasificación Topográfica”
1. Debe haber completado la encuesta de la pestaña “Síntomas”,
2. Debe haber diligenciado los campos de la pestaña “Clasificación
Topográfica”
Base de datos de MySQL, Pestaña “Clasificación Topográfica”
 Datos glucosa del paciente
 Datos actividad física del paciente
 Datos de clasificación topográfica del paciente
Ventana emergente con un alerta.
1. Visitar la pestaña “Clasificación Topográfica”.
2. Llenar los campos vacíos según corresponda.
3. Hacer clic en el botón Ingresar.
4. Aparece ventana emergente con alerta.
 Conexión, Lógica del negocio
Tabla 17: Caso de Prueba 5
NOMBRE
PROPÓSITO
PRERREQUISITOS
UBICACIÓN
ENTRADA
ESTADO FINAL
PASOS
Módulos Asociados
Generar reporte al médico
PRUEBAS
P6
Verificar que los reportes dirigidos al médico son generados
correctamente.
 El reporte generado debe hacerse sobre un paciente asociado al
médico que hace la solicitud del reporte.
Base de datos MySQL, Pestaña “Consultar paciente”
 Identificación del paciente.
 Fecha para la generación del reporte (día o mes).
Se genera un archivo en formato PDF que contiene los datos personales,
síntomas, actividad física y datos de glucosa del paciente.
1. Iniciar sesión como médico
2. Clic en la pestaña “Consultar paciente”
3. Clic para escoger el paciente del que desea generar el reporte
Para reporte diario:
1. Escoger el día del cual quiere recuperar el reporte.
2. Clic en “Reporte Diario”
Para reporte mensual:
1. Escoger el mes del cual quiere recuperar el reporte.
2. Clic en “Reporte mensual”
 Conexión, Lógica del negocio, Acceso a Archivos
Tabla 18: Caso de Prueba 6
NOMBRE
PROPÓSITO
PRERREQUISITOS
UBICACIÓN
ENTRADA
ESTADO FINAL
PASOS
Módulos Asociados
Registrar usuario
PRUEBAS
P7
Verificar que los usuarios que los usuarios que llenan el formato de
registro sean registrados correctamente en el sistema (guardado de
información en la base de datos.
 El usuario no debe estar registrado previamente.
Base de datos MySQL, Ventana de registro
Datos personales del usuario diligenciados en el formulario de registro.
Registro satisfactorio del usuario en la BD del sistema.
1. En la ventana de inicio de sesión hacer clic en el botón
“registrarse”.
2. Hacer clic en el botón que corresponda al rol que tiene en DiaFoot
3. Llenar los campos requeridos del formato de registro.
4. Clic en el botón “Registrar”.
5. Iniciar sesión con los datos del registro
6. Usuario: número de identificación ingresado en el formulario.
7. Contraseña: clave ingresada en el formulario
8. Clic en “Ingresar”.
 Conexión, Lógica del negocio
Tabla 19: Caso de Prueba 7
NOMBRE
PROPÓSITO
PRERREQUISITOS
UBICACIÓN
ENTRADA
ESTADO FINAL
PASOS
Asociar paciente con médico
PRUEBAS
P8
Comprobar que la asociación entre pacientes y médicos se hace efectiva
en la base de datos.
 Los usuarios que van a vincularse o asociarse deben están
registrados en DiaFoot.
 Los usuarios a asociar no deben tener el mismo rol.
Ventana Administración – Pestaña “Asignar Pacientes”, Base de datos
MySQL
 Número de identificación del doctor.
 Número de identificación del paciente a asociar.
 Asociación exitosa entre usuarios.
 El paciente asociado aparece en la lista de pacientes que tiene un
médico a cargo en su perfil.
1. Iniciar sesión con perfil de administrador.
2. Clic en la pestaña “Asignar Pacientes”.
3. Escoger de la lista de médicos a quien se desea signar un
paciente.
4. Clic en la lista de pacientes registrados que no tienen médico
asociado.
5. Clic en “Asignar Paciente”
Comprobación:
1. Iniciar sesión como médico.
2. Consultar la lista de pacientes asociados.
3. Verificar que el paciente que asocio el administrador si se
encuentra dentro de esta lista.
Módulos Asociados

Conexión, Lógica del negocio
Tabla 20: Caso de Prueba 8
NOMBRE
PROPÓSITO
PRERREQUISITOS
UBICACIÓN
ENTRADA
ESTADO FINAL
PASOS
Módulos Asociados
Liberar paciente
PRUEBAS
P9
Comprobar que la asociación entre pacientes y médicos se hace efectiva
en la base de datos.
 Los usuarios que van a vincularse o asociarse deben están
registrados en DiaFoot.
 Los usuarios a asociar no deben tener el mismo rol.
Ventana Administración – Pestaña “Asignar Pacientes”, Base de datos
MySQL
 Número de identificación del doctor.
 Número de identificación del paciente a asociar.
 Asociación exitosa entre usuarios.
 El paciente asociado aparece en la lista de pacientes que tiene un
médico a cargo en su perfil.
6. Iniciar sesión con perfil de administrador.
7. Clic en la pestaña “Asignar Pacientes”.
8. Escoger el médico del cual se desea liberar el paciente.
9. Escoger el paciente a liberar en la lista de pacientes asignados
al médico escogido en el paso 3.
10. Clic en “Liberar Paciente”
Comprobación:
4. Iniciar sesión como médico.
5. Consultar la lista de pacientes asociados.
6. Verificar que el paciente que des asocio el administrador NO se
encuentra dentro de esta lista.
 Conexión, Lógica del negocio
Tabla 21: Caso de Prueba 9
NOMBRE
PROPÓSITO
PRERREQUISITOS
UBICACIÓN
ENTRADA
ESTADO FINAL
PASOS
Módulos Asociados
Generar gráfico
PRUEBAS
P10
Verificar la creación de los gráficos de glucosa de los pacientes.
 Deben haber datos de nivel de glucosa ingresados por el paciente.
Ventana Paciente – Pestaña “Datos glucosa”, Base de datos MySQL
Datos de nivel de glucosa en los diferentes momentos del día (pestaña
“Datos Glucosa”)
Ventana emergente con el gráfico de nivel de glucosa del día.
1. Iniciar sesión con rol de paciente.
2. Clic en la pestaña “Datos Glucosa”.
3. Ingresar todos los datos del día.
4. Clic en botón “generar gráfico”
 Conexión, Lógica del negocio
Tabla 22: Caso de Prueba 10
7
ANEXO
7.1 Anexo 1: Reportes de Pruebas
VER DOCUMENTO DE EXCEL “Reporte de Pruebas.xlsx”