3.7 Pruebas de volumen

Dat@Solutions
SGAC
Plan de pruebas
Versión 1.0
SGAC
Versión:
1.0
Fecha: 02/062012
Plan de pruebas
419514942.DOC
Historial de revisiones
Fecha
02/06/2012
Versión
1.0
Descripción
Creación del documento
Ccurier, 2015
Autor
Novoa Tafur Einstein
Manuel
Página 2
SGAC
Versión:
1.0
Fecha: 02/062012
Plan de pruebas
419514942.DOC
Tabla de contenido
1.
Propósito
4
2.
Alcances
4
3.
Requerimientos de pruebas
4
3.1
3.2
3.3
3.4
3.5
3.6
3.7
4
4
4
4
4
5
5
4.
5.
6.
Pruebas de integridad de datos y BD
Pruebas del sistema
Pruebas de la interfaz de usuario
Pruebas de desempeño
Pruebas de carga
Pruebas de stress
Pruebas de volumen
Estrategia de pruebas
5
4.1
5
5
5
6
6
6
7
7
Tipos de pruebas
4.1.1 Pruebas de integridad de datos y BD
4.1.2 Pruebas del sistema
4.1.3 Pruebas de la interfaz de usuario (IU)
4.1.4 Pruebas de desempeño
4.1.5 Pruebas de carga
4.1.6 Pruebas de stress
4.1.7 Pruebas de volumen
Recursos
8
5.1
8
Trabajadores
Entregables
9
Ccurier, 2015
Página 3
SGAC
Versión:
1.0
Fecha: 02/062012
Plan de pruebas
419514942.DOC
Plan de pruebas maestro
1. Propósito
Este documento describe el plan para probar las funcionalidades y características del sistema SGAC. Este
documento está basado sobre los siguientes objetivos:

Identificar que la información existente del proyecto y los componentes de software sean probados.

Listar los requerimientos recomendados de prueba (de alto nivel).

Recomendar y describir las estrategias a ser empleadas.

Identificar los recursos requeridos y estimar los esfuerzos de las pruebas.

Listar los elementos a entregar de las actividades de pruebas.
2. Alcances
Este plan de pruebas aplica para la integración y las pruebas de sistema que serán conducidos en el lanzamiento de
la versión 1.0 del sistema SGAC.
Se asume que pruebas unitarias previas han debido proveer de pruebas de caja negra totales a través de una
extensiva cobertura del código fuente y pruebas de todas las interfaces de los módulos.
Este plan de pruebas aplica para todos los requerimientos definidos en el documento de Visión, ECUS .
3. Requerimientos de pruebas
La lista que prosigue este párrafo identifica aquellos elementos (requerimientos funcionales, no funcionales) que
han sido identificados como objetivos de las pruebas. Esta lista representa el qué será probado. Los detalles de cada
prueba serán determinados posteriormente mientras los casos de prueba sean identificados y los scripts sean
desarrollados.
3.1 Pruebas de integridad de datos y BD




Verificar el acceso a la BD de SGAC.
Verificar el acceso simultáneo en la lectura de registro de las distintas tablas.
Verificar el bloqueo realizado durante actualizaciones de registros de las tablas transaccionales
Verificar la correcta obtención de data actualizada.
3.2 Pruebas del sistema
 Verificar el CU Login/Logout
 Verificar el CU Registrar cliente
 Verificar el CU Registrar Solicitud Servicio
 Verificar el CU Consulta Solicitud Servicio
 Verificar el CU Generar Factura




Verificar el CU Generar Orden Servicio
Verificar el CU Generar Manifiesto
Verificar el CU Generar Guía Remisión
Verificar el CU Buscar Cliente
3.3 Pruebas de la interfaz de usuario
 Verificar la facilidad de navegación mediante un ejemplo de pantallazos de las funcionalidades.
 Verificar que los pantallazos de ejemplo cumplan estándares de GUI.
3.4 Pruebas de desempeño
 Verificar el tiempo de respuesta para acceder remotamente a la aplicación
 Verificar el tiempo de respuesta para registrar un cliente
 Verificar el tiempo de respuesta para consultar solicitud de servicio
 Verificar el tiempo de respuesta para generar orden de servicio
3.5 Pruebas de carga
 Verificar la respuesta del sistema cuando tiene 50 usuarios accediendo a la tabla de producto.
Ccurier, 2015
Página 4
SGAC
Versión:
1.0
Fecha: 02/062012
Plan de pruebas
419514942.DOC
3.6 Pruebas de stress
 Verificar la respuesta del sistema cuando tiene 200 sesiones de usuario activas.
3.7 Pruebas de volumen
 Verificar el tiempo de respuesta cuando la tabla servicio está en el 90% de su capacidad.
4. Estrategia de pruebas
La estrategia de pruebas presenta el alcance recomendado para la prueba de aplicaciones de software. La sección
previa a los requerimientos de pruebas describen qué será probado; ésta describirá cómo será probado.
4.1 Tipos de pruebas
Las consideraciones principales para la estrategia de pruebas son las técnicas a usarse y los criterios para determinar
si la prueba fue completada.
Además de las consideraciones provistas para cada prueba mencionada, las pruebas deberían ser únicamente
ejecutadas usando bases de datos conocidas y controladas en entornos seguros.
La siguiente estrategia de pruebas es genérica en su naturaleza y está dirigida a aplicarse sobre los requerimientos
listados en la sección 3 de este documento.
4.1.1 Pruebas de integridad de datos y BD
La base de datos y los procesos de bases de datos deberían ser probadas en sistemas separados. Estos sistemas
deberían ser probados sin la aplicación SGAC . Revisión exhaustiva sobre el gestor de base de datos a usarse
necesita ser realizada para identificar las herramientas y técnicas que puedan existir para soportar las pruebas a
realizarse.
4.1.1.1 Objetivo
Asegurar que los métodos de acceso y los procesos funcionen apropiadamente y sin corrupción de datos
4.1.1.2 Técnicas
Invocar cada método de acceso a la BD, intentando con datos válidos e inválidos.
Inspeccionar la base de datos para asegurar que la data ha sido poblada como se esperaba, que todos los eventos
ocurran apropiadamente, o revisar la data retornada para asegurar que la data correcta fue obtenida (por las razones
correctas).
4.1.1.3 Criterio de cumplimiento
Todos los métodos de acceso a la base de datos y procesos funcionan como fueron diseñados y sin corrupción de
datos.
4.1.2 Pruebas del sistema
Las pruebas sobre la aplicación deberían enfocarse en requerimientos que puedan ser asociados directamente a casos
de uso (o funciones de negocio), y reglas del negocio. Las metas de estas pruebas son verificar la aceptación, el
procesamiento y obtención de data apropiada, así como la apropiada implementación de reglas del negocio. Este tipo
de pruebas está basado en las técnicas de caja negra, utilizando para ello la GUI y analizando los resultados.
4.1.2.1 Objetivo
Asegurar la navegación apropiada en la aplicación; el correcto ingreso de datos, procesamiento y obtención.
4.1.2.2 Técnicas
Ejecutar cada CU, cada flujo de CU o función, usando data válida e inválida, para verificar: a) que los resultados
ocurran cuando la data sea válida.; b) que se muestren apropiados mensajes de error o alerta cuando data inválida
sea empleada.
Cada regla de negocio es apropiadamente aplicada.
Ccurier, 2015
Página 5
SGAC
Versión:
1.0
Fecha: 02/062012
Plan de pruebas
419514942.DOC
4.1.2.3 Criterio de cumplimiento
Todas las pruebas planificadas fueron ejecutadas
Todos los defectos de pruebas han sido manejados.
4.1.3 Pruebas de la interfaz de usuario (IU)
Verifica la interacción del usuario con el software. La meta de las pruebas de IU es asegurar que la interfaz de
usuario provea al usuario el acceso apropiado para acceder y navegar por las funciones de la aplicación. Además, las
pruebas IU asegura que los objetivos dentro de la IU funcionen como se esperaba y conforme a los estándares de la
compañía.
4.1.3.1 Objetivo
Verificar: a) la navegación por la aplicación refleje propiamente las funciones y requerimientos de negocio; b) los
objetos de ventanas y sus características, como menús medidas posición, estado y foco sea conforme a los
estándares.
4.1.3.2 Técnicas
Crear modificar las pruebas para cada ventana para verificar apropiadamente la navegación y los estados de los
objetos para cada ventana y objeto de la aplicación.
4.1.3.3 Criterio de cumplimiento
Cada ventana fue verificada exitosamente para comparar si se sigue el estándar o no.
4.1.4 Pruebas de desempeño
Realizar las pruebas que miden los tiempos de respuesta, las tasas de transacción y otros requerimientos sensibles al
tiempo. La meta de las pruebas de desempeño es verificar y validar que los requerimientos de desempeño han sido
alcanzados. Este tipo de pruebas es ejecutado muchas veces, y cada ejecución emplea una carga subrepticia
(background load) en el sistema.
4.1.4.1 Objetivo
Validar el tiempo de respuesta para transacciones diseñadas o funciones de negocio bajo las siguientes condiciones:
a) volumen normal anticipado, b) volumen de caso mal anticipado.
4.1.4.2 Técnicas
Usar scripts de prueba desarrollados por pruebas de modelo de negocio (pruebas de sistema).
Modificar archivos de datos (para incrementar el número de transacciones) o modificar los scripts para incrementar
el número de iteraciones en que cada transacción ocurre.
Lo scripts deben correr en una sola máquina (en el mejor de los casos simular un usuario único, una única
transacción) y ser repetido en múltiples clientes (virtuales o actuales).
4.1.4.3 Criterio de cumplimiento
Una transacción / un único usuario. El cumplimiento exitoso de estas pruebas, es cuando no se encuentran fallas en
los tiempos esperados o requerido (en cada transacción).
Múltiples transacciones / múltiples usuarios. El cumplimiento exitoso de estas pruebas, es cuando no se encuentran
fallas en los tiempos aceptables.
4.1.5 Pruebas de carga
Las pruebas de carga miden las situaciones en las que el sistema se somete a variaciones en su carga de trabajo para
evaluar la habilidad del sistema para continuar funcionando adecuadamente, más allá de la carga de trabajo
esperada. Adicionalmente, las pruebas evalúan las características de desempeño (tiempos de respuestas, tasas de
transacción y otros problemas sensibles a tiempos).
4.1.5.1 Objetivo
Verificar el tiempo de respuesta del sistema para transacciones diseñada o casos de negocio bajo condiciones de
carga de trabajo variada.
Ccurier, 2015
Página 6
SGAC
Versión:
1.0
Fecha: 02/062012
Plan de pruebas
419514942.DOC
4.1.5.2 Técnicas
Pruebas de uso desarrolladas para ciclos de prueba de negocio.
Modificar archivos de datos (incrementando el número de transacciones) o las pruebas para incrementar el número
de veces en que una transacción ocurre.
4.1.5.3 Criterio de cumplimiento
Múltiples transacciones / múltiples usuarios. El cumplimiento exitoso de estas pruebas, es cuando no se encuentran
fallas en los tiempos aceptables.
4.1.6 Pruebas de stress
Las pruebas de stress intentan encontrar errores debido a bajos recursos o competencia por recursos. La baja
memoria o espacio del disco pueden revelar defectos en el software que no aparecen bajo condiciones normales.
4.1.6.1 Objetivo
Verificar que el sistema y el software funciona apropiadamente y sin errores bajo las siguientes condiciones de
stress:
Poca o sin memoria disponible en el servidor.
Máximo (actual o físicamente capaz) número de clientes conectados o simulados.
Múltiples usuarios realizando las mismas transacciones contra los mismos datos o cuentas.
4.1.6.2 Técnicas
Pruebas de uso desarrolladas para las pruebas de desempeño.
4.1.6.3 Criterio de cumplimiento
Probar recursos limitados, las pruebas deberían correr sobre una sola maquina, y la memoria RAM en el servidor
debería ser la mínima (o limitada).
El espacio en el disco duro usado por el sistema debería ser temporalmente reducido para restringir el espacio
disponible para que la base d datos crezca.
4.1.7 Pruebas de volumen
Determina si el sistema puede trabajar con grandes cantidades de datos, indicando cuando los límites son alcanzados
lo que causaría que el software falle.las pruebas de volumen además identifican las cargas continuas de carga o el
volumen que el sistema puede manejar por un tiempo dado.
4.1.7.1 Objetivo
Verificar que la aplicación funcione exitosamente bajo los siguientes escenarios de gran volumen:
Máximo número de clientes conectados, todos realizando la misma funcionalidad de negocio con el peor caso (de
desempeño) por un periodo largo de tiempo.
Tamaño máximo de la BD ha sido alcanzado y múltiples transacciones de consultas y reportes son ejecutados
simultáneamente.
4.1.7.2 Técnicas
Las pruebas de uso desarrolladas para las pruebas de desempeño.
Múltiples clientes deberían ser usados, bien corriendo las mismas pruebas o pruebas complementarias para producir
la transacción del peor caso de volumen por un periodo extendido.
Máximo tamaño de la base de datos es creado y múltiples clientes lo usan para ejecutar consultas y reportes
simultáneamente por un periodo extendido.
4.1.7.3 Criterio de cumplimiento
Todas las pruebas han sido ejecutadas y los limites del sistema son alcanzados/excedidos sin que el software falle.
Ccurier, 2015
Página 7
SGAC
Versión:
1.0
Fecha: 02/062012
Plan de pruebas
419514942.DOC
5. Recursos
5.1 Trabajadores
La siguiente tabla muestra las personas asignadas para el equipo de pruebas:

Analista





Diseñador web
Base de Datos
Programador
Pruebas
Gestión
Ccurier, 2015
Página 8
SGAC
Versión:
1.0
Fecha: 02/062012
Plan de pruebas
419514942.DOC
Entregables
1 .Registrar Cliente
Ccurier, 2015
Página 9
SGAC
Versión:
1.0
Fecha: 02/062012
Plan de pruebas
419514942.DOC
CASOS DE PRUEBA
C.C. COURIER
Caso de Uso
Caso de Prueba
Actor
CU_01 Registrar cliente
CP_01 Registrar cliente
Pre Condiciones:
El RV debe estar logueado en el Sistema.
Propósito:
Registrar cliente
Escenario
CP_01_E01: Comprobar el correcto Registro del cliente
Sec.
Actividad
1
El RV ingresa los datos:
Cliente: Juan Perez
Tipo de pago: Visa
Fecha de Vencimineto: 27/07/12
Codigo de Verificación: 12345
Nro cuotas: 1
Dirección,: Los portales 255-San Isidro
e-mail : [email protected]
RV
2
Solicita " Registrar cliente"
Clase de equivalencia Resultado Esperado
Válida
Visualiza los datos
ingresados en los
respectivos campos
deacuerdo al set de
datos.
Válida
Muestra MSG: "Registro
satisfactorio”.
Escenario
CP_01_E02: Comprobar que el sistema genere el mensaje de error al registrar un error al ejeccutar la trasacción
Sec.
Actividad
Clase de equivalencia Resultado Esperado
1
Solicita: "Registrar cliente"
Válida
Muestra MSG:
"“DNI/RUC incorrecto”."
Escenario:
CP_01_E03: Comprobar que el sistema genere el mensaje si desea cancelar el registro
Sec.
Actividad
Clase de equivalencia Resultado Esperado
1
Solicita "Registrar cliente"
Válida
Muestra Msg: "Seguro
Ccurier, 2015
Página 10
desea cancelar el
registro".
SGAC
Versión:
1.0
Fecha: 02/062012
Plan de pruebas
419514942.DOC
2. Registrar Solicitud Servicio
Ccurier, 2015
Página 11
SGAC
Versión:
1.0
Fecha: 02/062012
Plan de pruebas
419514942.DOC
CASOS DE PRUEBA
C.C. COURIER
Caso de Uso
Caso de Prueba
Actor
CU_02 Registrar Solicitud de Servicio
CP_02 Registrar Solicitud de Servicio
Pre Condiciones:
El RV debe estar logueado en el Sistema.
Propósito:
Registrar Solicitud de Servicio
Escenario
CP_02_E01: Comprobar el correcto Registrar Solicitud de Servicio
Sec.
Actividad
Clase de equivalencia
1
El cliente ingresa los datos:
Válida
Datos del destinatario:
Datos de mercadería:
Datos del producto:
Cliente
2
Solicita " Registrar Solicitud de Servicio"
Válida
Resultado Esperado
Visualiza los datos
ingresados en los
respectivos campos
deacuerdo al set de
datos.
Muestra MSG: "Registro
satisfactorio”.
Escenario
CP_02_E02: Comprobar que el sistema genere el mensaje de error al registrar un error al ejeccutar la trasacción
Sec.
Actividad
Clase de equivalencia Resultado Esperado
1
Solicita: "Registrar Solicitud de Servicio"
Válida
Muestra MSG: "“Tipo de
identidad incorrecto”."
Escenario:
CP_05_E03: Comprobar que el sistema genere el mensaje si desea cancelar solucitud
Sec.
Actividad
Clase de equivalencia Resultado Esperado
1
Solicita "Registrar Solicitud de Servicio"
Válida
Muestra Msg: "Seguro
desea cancelar el
registro de la solucitud".
Ccurier, 2015
Página 12
SGAC
Versión:
1.0
Fecha: 02/062012
Plan de pruebas
419514942.DOC
3. Consultar Solicitud Servicio
Ccurier, 2015
Página 13
SGAC
Versión:
1.0
Fecha: 02/062012
Plan de pruebas
419514942.DOC
CASOS DE PRUEBA
C.C. COURIER
Caso de Uso
Caso de Prueba
Actor
CU_03 Consultar Solicitud de Servicio
CP_03 Consultar Solicitud de Servicio
Pre Condiciones:
Representante de Ventas (RV)
Transportista (T)
El (RV o T) debe estar logueado en el Sistema
La Lista de solicitud de servicio debe estar disponible
El sistema debe notificar al RV en la interfaz del menú principal.
Propósito:
Consultar Solicitud de Servicio
Escenario
CP_03_E01: Comprobar la correcto Generación de Orden de Servicio
Sec.
Actividad
Clase de equivalencia
1
Datos de la solicitud de servicio:
Válida
Datos del cliente:
Datos del destinatario:
Datos de mercadería:
Detalle de la mercadería:
2
Escenario
Solicita " Consultar Solicitud de Servicio"
Válida
Resultado Esperado
Visualiza los datos
seleccionados en los
respectivos campos
deacuerdo al set de
datos.
Muestra MSG: "Datos del
orden de servicio a
generar”.
CP_03_E02: Comprobar que el sistema muestre estados pendientes
Sec.
Actividad
Clase de equivalencia Resultado Esperado
1
Solicita: "Consultar Solicitud de Servicio"
Válida
Muestra MSG: "No existe
solicitudes pendientes."
Ccurier, 2015
Página 14
SGAC
Versión:
1.0
Fecha: 02/062012
Plan de pruebas
419514942.DOC
4. Generar Factura
Ccurier, 2015
Página 15
SGAC
Versión:
1.0
Fecha: 02/062012
Plan de pruebas
419514942.DOC
CASOS DE PRUEBA
C.C. COURIER
Caso de Uso:
Caso de Prueba:
Actor:
CP_04 Generar Factura
CP_04 Generar Factura
Pre Condiciones:
El Representante de Ventas logueado en el sistema.
Lista de órdenes de servicio disponible.
Lista de clientes disponible.
Representante de Ventas
Propósito:
Escenario:
Escenario:
Escenario:
CP_04_E01: Comprobar la correcta generacion de factura
Sec.
Actividad
1
El RV selecciona Generar Factura
2
Ingresa datos
3
2
3
Ingresa monto
Solicita "Generar Factura"
Solicita"Imprimir"
CP_04_E02: Consultar órdenes de servicio en la tabla
Sec.
Actividad
1
Selecciona consultar
Clase de equivalencia Resultado Esperado
Válida
Muestra datos del
servicios, datos del
cliente.
Válida
OK
Válida
Válida
Válida
Calcula el subtotal
OK
OK
Clase de equivalencia Resultado Esperado
Muestra los datos de la
Válida
orden de servicio
seleccionada
CP_04_E03: Comprobar errores en la generacion del registro de la factura
Sec.
Actividad
Clase de equivalencia Resultado Esperado
1
Selecciona Generacion de Factura
Válida
muestra el MSG:
“Factura no registrada”
Ccurier, 2015
Página 16
SGAC
Versión:
1.0
Fecha: 02/062012
Plan de pruebas
419514942.DOC
5. Generar Orden Servicio
CASOS DE PRUEBA
C.C. COURIER
Caso de Uso:
Caso de Prueba:
Actor:
CU_05 Generar Orden de Servicio
CP_05 Generar Orden de Servicio
Pre Condiciones:
El RV debe estar logueado en el Sistema
Propósito:
Generar Orden de Servicio
Escenario:
CP_05_E01: Comprobar la correcta generación de Orden de Servicio de un cliente
Sec.
Actividad
Clase de equivalencia Resultado Esperado
1
EL RV selecciona “Buscar Cliente”
Válida
OK
Representante de Ventas (RV)
Transportista (T)
2
El RV solicita Cotizar Servicio.
Válida
3
El RV solicita "Grabar Orden."
Válida
Muestra el detalle de
orden de servicio y los
datos de la mercadería.
OK
4
Solicita"Imprimir"
Válida
OK
Escenario:
CP_05_E02: Comprobar que el sistema genere el mensaje de error Orden de servicio no registrada.
Sec.
Actividad
Clase de equivalencia Resultado Esperado
1
Selecciona grabar servicio
Válida
Muestra Msg: “Orden de
servicio no registrada”
Escenario:
CP_05_E03: Comprobar que el sistema valide los datos incompletos
Sec.
Actividad
Clase de equivalencia
1
Solicita "Buscar cliente"
Ccurier, 2015
Válida
Resultado Esperado
Muestra Msg: "Por favor,
ingrese datos del cliente
a buscar"
Página 17
SGAC
Versión:
1.0
Fecha: 02/062012
Plan de pruebas
419514942.DOC
6. Generar Manifiesto
Ccurier, 2015
Página 18
SGAC
Versión:
1.0
Fecha: 02/062012
Plan de pruebas
419514942.DOC
CASOS DE PRUEBA
C.C. COURIER
Caso de Uso:
Caso de Prueba:
Actor:
CU_06 Generar Manifiesto
CP_06 Generar Manifiesto
Pre Condiciones:
El Almacenero debe estar logueado en el Sistema
Propósito:
Generar Manifiesto
Escenario:
CP_06_E01: Comprobar la correcta generación del Manifiesto
Sec.
Actividad
1
El Almacenero selecciona la Provincia ,Ciudad de Destino y tipo.
Almacenero
Clase de equivalencia Resultado Esperado
Válida
OK
2
El Almacenero selecciona Buscar "Orden de Servicio".y "proveedor"
Válida
3
El almacenero selecciona "Generar Manifiesto"
Válida
Muestra los datos de la
orden de servicio y
proveedor.
OK
4
Solicita"Imprimir"
Válida
OK
Escenario:
CP_06_E02: Comprobar que el sistema genere el mensaje de error Manifiesto no registrado.
Sec.
Actividad
Clase de equivalencia Resultado Esperado
1
Selecciona grabar manifiesto
Válida
Muestra Msg:“Manifiesto
no registrado”
Escenario:
CP_06_E03: Comprobar que el sistema valide los datos incompletos
Sec.
Actividad
1
Escenario:
Ingresar datos del chofer y placa
CP_06_E04: Comprobar Peso total de manifiesto es mayor a una tonelada
Sec.
Actividad
1
Si se aprueba "Evaluar Despacho "
Ccurier, 2015
Clase de equivalencia Resultado Esperado
Válida
Muestra Msg: "ingrese
datos del chofer y placa"
Clase de equivalencia Resultado Esperado
Válida
Se selecciona "Servicio
Carguero"
Página 19
SGAC
Versión:
1.0
Fecha: 02/062012
Plan de pruebas
419514942.DOC
7. Generar Guía Remisión
CASOS DE PRUEBA
C.C. COURIER
Caso de Uso:
Caso de Prueba:
Actor:
CU_07 Generar Guía de Remisión
CP_07 Generar Guía de Remisión
Pre Condiciones:
El Gerente de Operaciones logueado en el sistema.
Ordenes de servicio disponible
Lista de proveedor de transporte disponible
Propósito:
Generar Guía de Remisión
Escenario:
CP_07_E01: Comprobar la correcta generación de Guía de Remisión
Sec.
Actividad
Escenario:
Gerente de Operaciones
Clase de equivalencia
1
El Gerente solicita “Buscar Orden de Servicio”.
Válida
2
3
El gerente selecciona "Generar Guía de Remisión."
Solicita"Imprimir"
Válida
Válida
Resultado Esperado
Muestra los datos de la
orden de servicio con su
detalle.
OK
OK
CP_07_E02: Comprobar que el sistema genere el mensaje de error Guía de remisión no registrada.
Sec.
Actividad
Clase de equivalencia
Resultado Esperado
1
Selecciona grabar guía de remisión
Válida
Muestra el MSG: “Guía
de Remisión no
registrada”
CP_07_E03: Comprobar que el sistema valide los datos incompletos
Escenario:
Sec.
1
Actividad
Solicita "Buscar orden de servicio"
Ccurier, 2015
Clase de equivalencia
Válida
Resultado Esperado
Muestra Msg: "Por favor,
ingrese datos del orden
de servicio"
Página 20
SGAC
Versión:
1.0
Fecha: 02/062012
Plan de pruebas
419514942.DOC
8 . Buscar Cliente
Ccurier, 2015
Página 21
SGAC
Versión:
1.0
Fecha: 02/062012
Plan de pruebas
419514942.DOC
CASOS DE PRUEBA
C.C. COURIER
Caso de Uso:
Caso de Prueba:
Actor:
CU_09 Buscar Cliente
CP_09 Buscar Cliente
Pre Condiciones:
El RV debe estar logueado en el Sistema.
Lista de Clientes disponible.
Propósito:
Probar la busqueda del cliente que se realiza para poder cargar los datos en un CU base.
Escenario
CP_09_01 Realizar una busqueda de un cliente
Sec.
Actividad
1
Selecciona criterio de busqueda
Representante de Ventas (RV)
Clase de equivalencia
Válida
2
Ingresa nombre o codigo del cliente
Válida
2
Selecciona Buscar
Válida
3
Presiona Aceptar
Resultado Esperado
Resultado Obtenido
Carga los datos del cliente al
CU base donde fue invocado
Escenario
CP_09_02 Cliente no encontrado
Sec.
Actividad
1
Selecciona criterio de busqueda
2
3
Ingresa nombre o codigo del cliente
Selecciona Buscar
Ccurier, 2015
Clase de equivalencia
Válida
Resultado Esperado
Resultado Obtenido
Válida
Muestra el mensaje sobre que
el cliente solicitado no fue
encontrado.
Página 22
SGAC
Versión:
1.0
Fecha: 02/062012
Plan de pruebas
419514942.DOC
Ccurier, 2015
Página 23