El documento describe el diseño de un caso de pruebas para un sistema. Explica los pasos involucrados como definir los requerimientos funcionales y no funcionales, seleccionar los módulos a probar, documentar las funciones de cada módulo, registrar los resultados de las pruebas y documentar la prueba completa.
1. DISEÑO DE CASO DE PRUEBAS
1. REQUERIMIENTOS DEL SISTEMA
Para la realización de las pruebas de nuestro sistema, realizamos una lista con los
requerimientos funcionales y no funcionales solicitados para el correcto desarrollo de nuestro
proyecto.
1.1. Requerimientos Funcionales
Un requerimiento funcional define una función del sistema de software o sus
componentes. Una función es descrita como un conjunto de entradas, comportamientos y
salidas. Los requerimientos funcionales pueden ser:
CÁLCULOS,
DETALLES TÉCNICOS,
MANIPULACIÓN DE DATOS Y
OTRAS FUNCIONALIDADES ESPECÍFICAS QUE SE SUPONE, UN SISTEMA DEBE
CUMPLIR (REGISTRAR, MODIFICAR, ELIMINAR, GENERAR REPORTES, ENTRE
OTRAS).
Como se define en la ingeniería de requerimientos, los requerimientos funcionales
establecen los comportamientos del sistema.
1.2. Requerimientos No funcionales
Un requerimiento no funcional o atributo de calidad es, en la ingeniería de sistemas y
la ingeniería de software, un requerimiento que especifica criterios que pueden usarse para
juzgar la operación de un sistema en lugar de sus comportamientos específicos, ya que éstos
corresponden a los requerimientos funcionales. Por tanto, se refieren a todos los
requerimientos que ni describen información a guardar, ni funciones a realizar.
2. Algunos ejemplos de requisitos no funcionales típicos son los siguientes:
Rendimiento
Disponibilidad
Seguridad
Accesibilidad
Usabilidad
Estabilidad
Portabilidad
Costo
Operatividad
Interoperabilidad
Escalabilidad
Concurrencia
Mantenibilidad
Interfaz
2. SELECCIÓN DE MÓDULOS A PROBAR
Una vez teniendo en cuenta el listado de los requerimientos procedemos a especificar
cuales módulos vamos a evaluar lo hacemos de acuerdo a los requerimientos solicitados y le
agregamos un identificador a cada unidad a probar. Por ejemplo, basándonos en los
requerimientos:
3. Unidad de Prueba Identificador
Acceso MOD1
Contenido MOD2
Interfaz
Navegación
Seguridad
Validación
Base de Datos
Configuración
Comportamiento General
NOTA: El ID puede ser cualquier termino que se decida para designar a la unidad a probar.
3. PRUEBA DE LAS FUNCIONES POR MÓDULOS
Una vez identificados las unidades o módulos del sistema a probar hacemos una tabla
en la que colocamos el identificador del módulo con las funciones que debería cumplir el
sistema. Este es un ejemplo
Modulo Registrar Eliminar Modificar Calcular Reportes Funcion6
Mod1 SI NA NA NA NA NA
Mod2 SI SI SI SI SI SI
Mod3 SI NO SI NA NA SI
Mod4 SI SI SI NA NA SI
Mod5 NA NA NO NO NA SI
Mod6 NA NA NA NA NA SI
PARA AFIRMACIÓN DE LA FUNCIÓN SE COLOCA (SI), (NO) O (N/A)= NO
4. APLICA
O EN SU DEFECTO UNA X O UN VIÑETE DE AFIRMACIÓN
Recuerden que las funciones pueden ser Cálculos, detalles técnicos y funciones
básicas que debe cumplir el sistema, como de la misma manera se pueden estar evaluando
los requemamientos no funciones como: interfaz, acceso, seguridad, usabilidad, entre otras.
4. VEREDICTO DE LAS PRUEBAS
Una vez realizada la prueba se hace la descripción para el veredicto y/o resultado
generado por la prueba.
ID Módulo Probado Resultado
obtenido
Veredicto observaciones
Mod1 Acceso a la interfaz principal Esperado Funcional
Mod2 Validación de formularios Esperado Funcional
Mod3 Registro de los usuarios Esperado Funcional
Mod4 Seguridad de acceso Esperado Funcional
Mod5 Conexión con la base de
datos
Esperado Funcional
Mod6 Genera el reporte solicitado Esperado Funcional
- El resultado puede ser Esperado o sin resultado (el modulo esta en construcción), o fallido.
- Veredicto puede ser Funcional o No Funcional.
- Observaciones se coloca cualquier eventualidad presentada durante la prueba.
5. DOCUMENTACIÓN DE LA PRUEBA
Por último se realiza una ficha la cual contendrá ciertos datos indispensables de la
realización de prueba la cual es la que el PROBADOR certificara y hará constar de la
ejecución de la misma.
5. Documentación de la Prueba
INSTITUCIÓN RESPONSABLE FECHA
NOMBRE DE LA INSTITUCIÓN
TITULO DEL PST II
DOCUMENTOS DE REFERENCIA
Identificador Título
Mod1 Acceso a la interfaz principal
Fecha de realización:
22-06-2013
Duración de la prueba: 1 hora
Requerimientos
de la prueba
LAPTOP, PENDRIVE...
Objetivo Encontrar el mayor numero de errores posibles, para la mejora
del sistema.
Resultado Esperado
Resultado Obtenido Prueba Exitosa SI(X ) NO( )
Estado del Caso de No iniciado En curso Terminado
6. prueba X
Personal Requerido Cargo Nombre Firma
Profesor/Ingeniero FULANITO
Comentarios En este modulo, se encontró una falla de seguridad, no esta
cifrada la contraseña.
Realizado por: Firma Fecha
NOMBRE TUTOR
TECNICO
00/00/201X
Aprobado por: Firma Fecha
TUTOR(A) ACADEMIC@ 00/00/201X