INSTITUTO TECNOLGICO DE CULIACN

INGENIERA EN SISTEMAS COMPUTACIONALES

EVALUACIN # 3
PROYECTO PARA PRUEBAS DE SOFTWARE
APLICACIN AL SOFTWARE
[Link]

ASIGNATURA:
Pruebas De Software

PROFESORA:
Norma Rebeca Godoy Castro

AULA:
EC04

HORA:
8:00 a.m. 9:00 a.m.

ALUMNA:
Laura Vianeth Parra Parra

29/ Mayo/2015

APLICACIN AL SOFTWARE
[Link]

ESTNDAR IEEE 829

Plan De Pruebas Del Software

1. Identificador nico del documento (para la gestin de configuracin).
Proyecto_Final_PRUSOFT

2. Introduccin y resumen de elementos y caractersticas a probar.

La documentacin pertinente que mostraremos esta basada en el proyecto de
software en torno a la pagina web [Link], su uso principal es la de
funcionar como un intermediario entre compradores y vendedores de la regin de
la ciudad de Culiacn, Sin., haciendo mencin al lugar ubicado en esta ciudad
donde se realiza esta misma funcin de forma fsica. En dicho software se muestra
un entorno fcil de usar para los usuario dando lugar a un panorama inicial con la
bienvenida al mismo donde se visualizan tambin campos de categorizacin de
productos, informacin acerca del servicio, rea de login para vendedores y
compradores as como opciones de contacto y administrar.
El presente plan de pruebas contiene la descripcin de los casos de prueba
definidos con el fin de validar y verificar que el desarrollo cumple con los requisitos
funcionales.
Las pruebas se harn en las siguientes categoras:
Fluidez de datos
Soporte del software
Interfaz de usuario
Unitarias
Funcionalidad
Rendimiento
Integracin
Requisitos

3. Elementos software que se van a probar (por ejemplo programas o mdulos)

MODULO ENTRADA

Seleccin de campo:
Se elige el campo de la pgina con el cual trabajar.
Definicin de parmetros:
Define los parmetros a introducir en cada campo.
Introduce la informacin requerida:
Se introducen los datos para acceder a la actividad.
MODULO PROCESO

Se inicializa en la pantalla la interaccin con el usuario.

Se actualiza la pantalla despus de acceder a la actividad y aparecen
opciones a elegir segn la actividad:
Explora el rea para proseguir con la funcionalidad de la actividad:
Se registra la actividad (compra/venta) segn sea el usuario.
MODULO SALIDA

Visualizacin por completo de la actividad en ejecucin.

Sistema de gestin de base de datos

Tipo de software muy especfico, dedicado a servir de interfaz entre la base
de datos, el usuario y las aplicaciones que la utilizan.
Base de datos
Conjunto de datos que pertenecen al mismo contexto almacenados
sistemticamente para su posterior uso.

4. Caractersticas que se van a probar.

FUNCIONALIDAD

DESCRIPCIN

Entrar

Si se obtuvo una cuenta, ingresarla ya

sea para comprar o para vender.

Crear una cuenta

Si no se tiene una cuenta, registrarse

para obtener permisos y as poder
comprar o vender.

Buscar lo que necesitas (barra)

Si eres comprador, escribir lo que

deseas comprar para ver si se
encuentra disponible.

Categoras

Se utiliza como opcin para comprar ya

que se muestran productos existentes.

Bienvenido (despus de entrar)

Muestra diferentes opciones segn sea

el caso (comprador/vendedor).
Comprador
Perfil
Mis compras
Carrito
Vendedor
Perfil
Nuevo producto
Mis productos

5. Caractersticas que no se prueban.

Errores relacionados con el tiempo.
Pruebas fsicas o de elementos hardware.
Problemas en caso de desastres.
Condiciones de error no detectadas.
Condiciones especiales de los datos.
Invalidez de la informacin mostrada por pantalla.
Incapacidad de soportar el volumen de carga.

6. Enfoque general de la prueba (actividades, tcnicas, herramientas, etc.).

UNITARIAS

Pretenden probar que los fragmentos individuales (unitarias) que forman el

sistema cumplen las especificaciones y tienen el comportamiento esperado.
INTERFAZ

Esto se refiere a probarla facilidad con lo cual los usuarios de una

aplicacin la pueden operar. Se busca lograr proporcionar a nuestros
usuarios una interfaz grfica bien organizada, similar a la de otras
aplicaciones, con campos fciles de entender y sobre todo manejables.
PRUEBAS FUNCIONALES

Tienen por objetivo probar que el sistema implementado cumpla con la

funciones. Bsicamente el enfoque de este tipo de prueba se basa en el
anlisis de los datos de entrada y en los de salida (datos que ingresa el
usuario para las compras, datos que ingresa el usuario para las ventas) y
as verificar los datos de salida.
RENDIMIENTO

A veces es importante el tiempo de respuesta, u otros parmetros de

rendimiento. Cuando el sistema debe procesar tantos datos, o cunta
memoria consume, o cunto espacio en disco utiliza, o cuntos datos
transfiere por un canal de comunicaciones. Para todos estos parmetros es
importante conocer cmo evolucionan al variar la dimensin del problema.
INTEGRACIN

Las pruebas de integracin se refieren a la prueba o pruebas de todos los

elementos unitarios, que comprueban la compatibilidad y funcionalidad de
las interfaces entre las distintas partes que componen un sistema, estas
partes pueden ser, aplicaciones individuales, aplicaciones cliente/servidor,
aplicaciones web, etc. Se realizan en el mbito una vez que se han
aprobado las pruebas unitarias.
REQUISITOS

Diferentes tcnicas de captura y anlisis de requisitos (prototipos, casos de

uso, etc.). El resultado es una descripcin de las funciones del sistema

7. Criterios de paso/fallo para cada elemento.

Esta seccin determina cuales son los criterios que se encargan de aprobar la
calidad de un producto, as tambin se establece cual es el criterio de fallo que se
encargar de hundir la aplicacin. En cuanto a los criterios de xito cada una de
las funciones deber de pasar las pruebas que se les fueron asignadas para poner
a prueba el objetivo por el cual fueron hechas.
La primera unidad de xito es completada si la aplicacin logra iniciar un usuario
previamente en la base de datos, en caso de poder hacer un inicio de sesin
correcto para cada uno de los usuarios se considera que la prueba ya ha sido
completada.
La segunda parte es muy similar a la anterior con la diferencia de que esta se
encarga de registrar primero al usuario para que tenga una cuenta con la cual
poder dar login despus.
Esta otra parte se relaciona con las dos anteriores, se encarga de revisar que el
sistema pueda cerrar la sesin de usuario, en caso de lograr la prueba
correctamente se da por concluida esta fase.
En la siguiente prueba corresponde probar las funciones de buscar lo que
necesitas (barra) en la base de datos, para esta prueba se cuenta con una serie
de casos que tratan de todos los puntos dbiles a la hora de acceder a la base de
datos, aqu tambin entra la prueba de categoras que funciona de la misma
manera a diferencia que se muestran todos los productos en vez de solo el
especificado, en caso de completar todos los casos correctamente se considera la
aceptacin de esta prueba.
La ltima prueba tiene que ver con Bienvenido (despus de entrar), para esta
ocasin tambin vamos a utilizar una serie de casos que describen el probable
flujo de acciones de una persona para actuar como comprador o como vendedor
de un producto. En caso de que se completen los casos determina la prueba como
un xito.
Como es de esperarse el criterio que evala si una prueba fue un fracaso se
obtiene a partir de las pruebas anteriores, en esta caso si la aplicacin no logra
terminar las pruebas mencionadas anteriormente entonces se considera que se
cumpli un criterio de fallo

8. Criterios de suspensin y requisitos de reanudacin.

Durante la ejecucin de las pruebas pueden aparecer problemas en los que este
proceso se vera suspendido. Tambin existen casos en los que despus de un
resultado se debe reanudar el proceso de pruebas para el sistema.
Suspensin:
- Que alguna prueba no resulte de la forma esperada:
En este caso no es necesario seguir haciendo pruebas, ya que se
debe corregir el defecto detectado antes de poder continuar.
- Que todas las pruebas de las funciones principales no presenten errores:
En este caso no es necesario continuar ya que si las funciones
principales funcionan, quiere decir que tambin lo hacen las otras
funciones.
Reanudacin:
- Despus de haber arreglado algn defecto de la pgina:
En este caso se procede a continuar aplicando las pruebas faltantes,
as como la prueba que produjo el fallo.

9. Documentos a entregar (como mnimo, los descritos en el estndar).

Entre los documentos que se entregaran para el proceso de pruebas se
encuentran los siguientes:
- Documento del plan de pruebas.
- Especificacin de diseo de pruebas
- Especificacin de casos de pruebas
- Especificacin de procedimientos de pruebas
- Histrico de Pruebas (Test Log).
- Informe Resumen De Pruebas (Test Summary Report).
- Los resultados esperados

10. Actividades de preparacin y ejecucin de pruebas.

Para realizar la preparacin de dichas pruebas necesitamos el cdigo fuente del
programa as como una idea clara de lo que se va a realizar.
Preparacin de casos de pruebas
Ejecucin de pruebas
Datos de la prueba
Preparar informe

11. Necesidades de entorno.

Entorno HTML
Entorno Java
Sistema operativo indistinto
Diseo de la BD

12. Responsabilidades de la organizacin y realizacin de las pruebas.

Responsabilidades

Plan de pruebas
Especificacin de
diseo de pruebas
Especificacin de
casos de pruebas
Especificacin de
procedimientos de
pruebas
Histrico de pruebas
Informe Resumen De
Pruebas
Los resultados
esperados

Vianeth Parra

Vianeth Parra

Vianeth Parra

13. Necesidades de personal y de formacin.

Que se tenga conocimientos de lenguaje HTML
Conocimientos de Lenguaje de Programacin JAVA
Experiencia en Base de Datos

14. Esquema de tiempos (con tiempos estimados, etc.).

15. Riesgos asumidos por el plan y planes de contingencia para cada riesgo.
Copias de seguridad
Frecuencia
Periodicidad
Plan de contingencias
Prever fallos crticos
Procedimientos alternativos
Tratamiento de errores
Posibilidad de error recuperacin
Planificacin contenido mensajes de error

16. Aprobaciones y firmas con nombre y puesto desempeado.

Los encargados de aprobar las distintas pruebas han sido mencionados a lo largo
del documento, y es por eso que no se detallan en este punto quienes son dichos
personas solo se mencionaran:
Laura Vianeth Parra Parra

Especificacin de diseo de pruebas

1. Caractersticas a probar de los elementos software (y combinaciones de
caractersticas).
Fluidez de datos
Soporte del software
Interfaz de usuario
Unitarias
Funcionalidad
Rendimiento
Integracin
Requisitos

2. Detalles sobre el plan de pruebas del que surge este diseo, incluyendo las
tcnicas de prueba especfica y los mtodos de anlisis de resultados.
Desarrollo de una solucin o diseo que permita satisfacer los requisitos del
cliente (no slo en trminos de calidad, sino tambin en trminos de coste y plazo)
de manera que todas y cada una de las caractersticas de diseo sean trazables a
los requisitos de cliente y viceversa.
En el caso de existir diversas alternativas de diseo, el director de proyecto deber
analizar las mismas de acuerdo a los objetivos de proyecto, eligiendo aquella que
maximice la probabilidad de xito del proyecto. Si alguna alternativa mereciera
consideracin, pero precisara de una modificacin de objetivos, deber consultar
al sponsor o patrocinador del proyecto.
Elaboracin de una filosofa o estrategia de pruebas que permita detectar en una
fase posterior incumplimientos de los requisitos por parte de la solucin adoptada
para as proceder a su correccin.
sta consistir bsicamente en determinar entre otros:
1.- Como se demostrar cada uno de los requisitos de cliente
2.- Nmero de prototipos, etc.
Gestionar la fase de acuerdo al plan de proyecto dentro del coste y plazo
asignado.
Los entregables de la fase de diseo son, adems de la solucin o diseo y la
estrategia de pruebas arriba mencionadas, la actualizacin del plan de proyecto a
partir de la informacin disponible al acabar la fase.

3. Identificacin de cada prueba:

El objetivo fundamental de esta fase es demostrar que el producto cumple con los
requisitos de cliente para as alcanzar los objetivos del proyecto. Para ello ser
necesario:
Fabricar, construir, o integrar el producto de acuerdo al diseo de la fase anterior y
de manera que ste no pierda sus caractersticas debido a una fabricacin
defectuosa.
Elaborar el plan de pruebas de acuerdo a la estrategia definida en la fase anterior.
Para ello se proceder a:
1.- Revisar la estrategia de acuerdo al diseo realizado definiendo los diferentes
niveles de prueba (componente, mdulo, sistema).
2.- Elaborar procedimientos de prueba para los diferentes niveles.
Validar y depurar el diseo modificando el mismo si fuera necesario a la vista de
los resultados de las pruebas. Se distingue entre:
1.- pruebas de diseo cuyo objeto es validar el enfoque de diseo realizado
utilizando prototipos o modelos de ingeniera
2.- pruebas de calificacin cuyo objetivo es demostrar que el producto cumple con
los requisitos de cliente plasmados en una especificacin.
Gestionar la fase de acuerdo al plan de proyecto dentro del coste y plazo
asignado.

4. Criterios de paso/fallo de la prueba (criterios para determinar si una

caracterstica o combinacin de caractersticas ha pasado con xito. la prueba
o no)
Esta fase es ms importante de lo que a primera vista pueda parecer y de hecho
muchos proyectos fallan en esta fase, cuando ya se ha invertido una gran parte
del presupuesto del proyecto. Entre las causas ms frecuentes de fallo se
encuentran:
1.- El producto no satisface las necesidades del usuario o cliente al no haber
tenido en cuenta sus necesidades
2.- Errores en la estrategia de implantacin
3.- Falta de formacin y de apoyo durante la fase inicial de operacin
4.- Errores en la estrategia de comunicacin
5.- Resistencia al cambio de los usuarios no adecuadamente gestionada por el
director de proyecto.

Especificacin de caso de prueba

A continuacin se pasara a describir los casos de pruebas junto con sus
especificaciones, caractersticas, e informacin relacionada con la misma.
El entorno del cual partiremos para realizar la prueba ser el formulario de
entrada de la aplicacin, es decir de la pagina inicial los campos que se deben
llenar para poder utilizar la aplicacin misma.
Objetivos a nivel de usuario:
Actor
Administrador del sistema

Cliente
Vendedor

Objetivo
Administrar usuarios
Mantener base de datos
Mantener la seguridad del
sistema
Conocer diferentes artculos
Comprar productos
Promover sus productos
Comercializar artculos
Vender

El sistema estar implantado en una pgina web a travs de internet, sirviendo a

diferentes usuarios (Compradores, Vendedores) e invocando servicios de otros
sistemas como autorizacin de pagos, contabilidad, soporte tcnico, etc.

MODELO DE CASOS DE USO

Lista actor-semntica
Actor
Vendedor
Administrador del sistema
Cliente

Semntica
Usuario principal del sistema, registra los artculos,
vende y cobra la venta.
Mantiene y soporta el sistema, procesa usuarios, y
vigila la seguridad del sistema.
Compra artculos, efecta pagos y promociones y
realiza devoluciones.

Lista actor-objetivo
Actor
Vendedor
Administrador del sistema

Cliente
Lista de casos de uso
Vendedor:
CU1: Registrar artculos
CU2: Procesar venta
CU3: Realizar devoluciones
CU4: Efectuar promociones
CU5: Modificar precios
Administrador:
CU6: Registrar usuarios
CU7: Procesar garantas
CU8: Registrar cliente
Comprador:
CU9: Consultar inventario
CU10: Realizar pedido a vendedor
CU11: Realizar pago

Objetivo
Procesar venta
Gestionar devoluciones.
Administrar usuarios
Mantener base de datos
Mantener la seguridad
sistema
Adquirir artculos

del

Descripcin breve de casos de uso

CU1: Registrar artculos
Un vendedor con un artculo nuevo registra la cantidad de artculos con los que
cuenta, el precio, caractersticas y una descripcin breve de este en el sistema.
CU2: Procesar venta
El cliente encuentra artculos y lo pide al vendedor en el sistema, el sistema
muestra un subtotal con el detalle de cada producto, el cliente elegir la forma de
pago, el sistema lo validara, se registrara la venta y los artculos en inventario, el
vendedor proporciona las facilidades de pago y el cliente obtiene sus artculos.
CU3: Realizar devoluciones
El cliente se queja del producto a devolver, el vendedor examina el producto y al
cliente se le devolver su dinero o un artculo similar.
CU4: Efectuar promociones
El cliente desea comprar artculos en promocin, el vendedor debe de especificar
la promocin en el sistema y efectuarla. Los movimientos se registraran junto con
las ventas.
CU5: Modificar precios
El vendedor del sistema en coordinacin con el administrador modificaran precios
y promociones de artculos, los cambios son efectuados en el sistema por el
administrador en base a lo acordado.
CU6: Registrar usuarios
Un nuevo usuario quiere utilizar los servicios de la pagina, el administrador se
encargara de dar de alta sus datos en el sistema adems de asignarle un usuario
y contrasea para el acceso del mismo siendo este un vendedor.
CU7: Procesar garantas
Un cliente compra un artculo y desea hacer efectiva su garanta pues este fall, el
administrador le solicita su comprobante de compra al cliente, el artculo se enva
a reparacin y registra en el sistema el uso de la garanta.

CU8: Registrar cliente

Un cliente solicita afiliarse a la pagina para servicios tales como envi a domicilio,
promociones o facturacin puede ser registrado en el sistema por el administrador
con la posibilidad de ser un cliente leal y se le es asignado id de usuario as como
contrasea para poder acceder a la pagina.
CU9: Consultar inventario
Si un comprador desea conocer la existencia de un artculo en el inventario de esa
base de datos de la pgina ser posible realizando una consulta a este y conocer
precios, modelo y otros detalles de inters.
CU10: Realizar pedido a vendedor
Se registran los artculos prospectos a pedido y se enva al centro de distribucin.
Los artculos solicitados son enviados al almacn de la sucursal y son registradas
en el inventario tanto del almacn como del centro de distribucin.
CU11: Realizar pagos
Cuando el cliente ha seleccionado su articulo y quiere hacerse de el, se contacta
con el vendedor con quien establecer el modo de pago, algunas opciones ya
vienen dada en el sistemas.

Casos de uso completos:

Caso de Uso UC2: Procesar venta
Actor principal: vendedor
Personal involucrado e intereses:
vendedor: Quiere registrar fcil, rpido y de manera concisa, para evitar
prdidas.
Servicio de autorizacin de pagos: Quiere atender peticiones de pago con
los datos correctos para registrar el cobro.
Pagina [Link]: Quiere llevar un registro conciso de las ventas y
satisfacer las necesidades de los compradores y que a pesar de fallos en
el sistema las ventas pueda ser completadas. Tambin quiere una
administracin rpida y actualizada del inventario.
Comprador: Quiere adquirir artculos rpidamente con la forma de pago
que el desee usar.
Precondiciones: El vendedor ingresa al sistema con su nombre de usuario y
contrasea correspondiente.
Garantas de xito (Postcondiciones): Se registra la venta. El inventario es
actualizado. Se expide el cobro. El comprador adquiere satisfactoriamente sus
artculos. Se registra el tipo de pago y su autorizacin.
Escenario principal de xito (o flujo bsico):
1. El cliente selecciona los artculos que desea comprar.
2. El vendedor inicia un nuevo registro de venta.
3. El vendedor registra el artculo.
4. El artculo es registrado en el sistema y se presentan los datos del artculo
y se muestra un subtotal.
El vendedor repite los pasos 3 y 4 hasta que ya no haya artculos.
5. El sistema muestra el monto total a pagar.
6. El vendedor solicita el pago del monto total al comprador.
7. El comprador realiza el pago y el sistema lo registra.
8. El sistema procesa, registra la venta y actualiza el sistema de inventario.
9. El vendedor le enva o entrega el artculo al cliente segn el caso de pago.
Extensiones o flujos alternativos:
*a. En cualquier momento el sistema falla.
1. El administrador reinicia el sistema, inicia la sesin y solicita
recuperacin al estado anterior.
2. El sistema reconstruye el estado anterior.
2a. El sistema detecta anomalas intentando la recuperacin:
1. El sistema informa de error al administrador, registra el
error y pasa a un estado limpio.

1. El articulo que el comprador elige no esta disponible.

1. El comprador busca otro artculo.
Se repite el paso 1 hasta encontrar otro articulo.
3. Registro de artculo invalido.
1. El sistema seala el error y rechaza la entrada
3-6a. El comprador pide al vendedor eliminar un artculo de la venta.
1. El vendedor selecciona la venta y el artculo a eliminar.
2. El sistema muestra la suma parcial actualizada.
3-6b. El comprador pide al vendedor cancelar la venta.
1. El vendedor cancela la venta en el sistema.
3-6c. El vendedor detiene la venta.
1. La venta queda registrada en el sistema para su posterior recuperacin.
5a. El comprador solicita un descuento por ser cliente leal.
1. El comprador proporciona su cdigo de cliente al vendedor.
2. El sistema valida el cdigo del comprador.
3. El sistema realiza el descuento y lo muestra.
6a. El comprador no cuenta con una forma de pago.
1. El vendedor cancela la venta.
6b. Pago en efectivo.
1. El comprador entrega el dinero al vendedor.
1a. El comprador no cuenta con efectivo suficiente.
1a. El comprador decide realizar un pago del monto restante con otra
forma de pago.
1b. El comprador decide cancelar la compra.
1b. El vendedor cancela la venta en el sistema.
2. El sistema registra el pago.
6c. Pago con tarjeta.
1. El comprador proporciona su nmero de cuenta al vendedor.
2. El sistema valida el nmero y la cuenta del comprador.
3. El sistema hace el cargo a la cuenta del comprador.
4. La tarjeta es rechazada.
El vendedor le informa al comprador y le solicita otra forma de pago.
Requisitos especiales:
Monitor de pantalla amplia.
Tolerante a fallos externos.
Frecuencia: Continua

Caso de Uso UC3: Realizar pedido a vendedor

Actor principal: comprador
Personal involucrado e intereses:
Comprador: Quiere realizar pedidos de productos al vendedor
correspondiente.
Pagina [Link]: Quiere llevar un registro conciso de los pedidos y
satisfacer las necesidades de los compradores con suficiente surtido de
productos, pero solo el necesario. Tambin quiere una administracin
rpida y actualizada del inventario.
Vendedor: Quiere conocer las necesidades de cada comprador para
proveer sus pedidos.
Precondiciones: El comprador ingresa al sistema con su nombre de usuario y
contrasea correspondiente.
Garantas de xito (Postcondiciones): Se registra el pedido. Se expide la orden
de pedido.
Escenario principal de xito (o flujo bsico):
10. El comprador selecciona el vendedor correspondiente.
11. El comprador ingresa el artculo y cantidad.
12. El artculo es registrado en el sistema y muestra sus datos.
13. El sistema muestra el total de artculos y cantidad.
14. El sistema solicita la confirmacin del pedido.
15. El comprador confirma el pedido.
16. El sistema procesa y registra el pedido.
17. El sistema expide la orden de pedido.
Extensiones o flujos alternativos:
*a. En cualquier momento el sistema falla.
1. El administrador reinicia el sistema, inicia la sesin y solicita
recuperacin al estado anterior.
2. El sistema reconstruye el estado anterior.
2a. El sistema detecta anomalas intentando la recuperacin:
1. El sistema informa de error al administrador, registra el
error y pasa a un estado limpio.
2. El vendedor no es el correspondiente.
1. El sistema muestra un mensaje de error.
1a. El comprador selecciona nuevamente el vendedor.
2. El comprador cancela el pedido.
Requisitos especiales:
Monitor de pantalla amplia.
Tolerante a fallos externos.
Frecuencia: Continua

Especificacin de procedimiento de prueba

1. Identificador nico de la especificacin y referencia a la correspondiente
especificacin de diseo de prueba.
En esta seccin se definirn los tipos de pruebas que se le aplicarn al software,
explicando bien sus objetivos y metas. En la interaccin del proceso de pruebas
de sistema se realicen este grupo de pruebas: Funcionalidad, Seguridad,
Disponibilidad y Red, Rendimiento o Carga, Compatibilidad, Resistencia o Stress,
Usabilidad y Fiabilidad.
1. Prueba de Funcionalidad
Objetivo
Verificar la funcin del sistema al fijar la tensin en la validacin de las funciones,
mtodos, servicios y casos de usos.
Metas
Validar que la aplicacin:
Cumpla con los requisitos funcionales especificados en el diseo de la
solucin.
Cumpla con los requisitos No funcionales especificados en el diseo de la
solucin.
Cumpla con las restricciones de entrada y salida de la informacin
especificada en el diccionario de Datos, de cada caso de uso.
Cumpla ntegramente con la estructura referencial especificada en el Mapa
de Navegacin.
2. Prueba de Seguridad
Objetivo
Verificar que los mecanismos de proteccin incorporados en el sistema realmente
lo protegern de accesos impropios.
Metas
Validar que en la aplicacin:
Los datos y funciones del sistema solo pueden ser accesibles por los
autores debidamente autorizados.
Las funciones que atenten contra la integridad de los datos de negocios
sean debidamente impedidas.
3. Prueba de Disponibilidad y Red
Objetivo
Verificar el comportamiento de la aplicacin cambiando la infraestructura de red al
aplicar diferentes configuraciones, o retardos.
Metas
Validar que en la aplicacin:
No se reduzca la disponibilidad de los sistemas, debido a la actividad de
alguna persona o sistema, ya sea, accidental o malintencionado.

4. Prueba de Rendimiento o Carga

Objetivo
Verificar el rendimiento del software en tiempo de ejecucin dentro del contexto de
un sistema integrado y as como la verificacin de la capacidad del sistema para
manejar volmenes de datos extremos de acuerdo a la velocidad que se
especifique para el sistema.
Metas
Validar en la aplicacin:
Comprobar los tiempos de respuesta del sistema en una cantidad limitada
de escenarios de trabajo (a nivel de nmero de usuarios y nmero de
transacciones), bajo una configuracin de hardware y software constante.
Comprobar el tiempo de respuesta al realizar una funcin.
Comprobar el tiempo de respuesta al realizar accesos concurrentes a una
determinada informacin.
Atender mltiples solicitudes de parte de los actores que acceden a un
mismo recurso.
5. Prueba de Compatibilidad
Objetivo
Verificar el funcionamiento del sistema sobre diferentes componentes de software.
Metas
Validar en la aplicacin:
Sistemas Operativos.
Navegadores.
6. Prueba de Resistencia o Stress
Objetivo
Verificar cmo se comporta el sistema bajo condiciones anormales:
Metas
Validar en la aplicacin:
Carencia de sistemas externos con los que interacta el sistema.
Aplicar carga excesiva de trabajo al sistema (extremas sobrecarga).
Recursos compartidos no disponibles.
Adems verifica qu hace el sistema cuando el usuario no hace lo que
supuestamente debe hacer.
7. Prueba de Usabilidad
Objetivo
Determinar si la organizacin de los contenidos y las funcionalidades que se
ofrecen desde el Sitio Web son entendidas y utilizadas por los usuarios de manera
simple y directa.
Metas
Validar en la aplicacin:
Para poder ver las pginas adecuadamente necesita utilizar un navegador
compatible con estndares Web.
Proporcionar al usuario informacin relacionada con el estado actual del
sistema.

8. Prueba de Fiabilidad
Objetivo
Verificar la probabilidad de que ese sistema funcione o desarrolle una cierta
funcin, bajo condiciones fijadas y durante un perodo de tiempo determinado.
Meta
Validar en la aplicacin:
El sistema deber estar disponible todo el tiempo.
El tiempo permitido para que el sistema pueda estar fuera de operacin
despus de un fallo no debe exceder 2 das.
Esta seccin determina cuales son los criterios que se encargan de aprobar la
calidad de un producto, as tambin se establece cual es el criterio de fallo que se
encargar de hundir la aplicacin. En cuanto a los criterios de xito cada una de
las funciones deber de pasar las pruebas que se les fueron asignadas para poner
a prueba el objetivo por el cual fueron hechas.
Las pruebas de sistema se dividen en dos tipos: las pruebas funcionales y las
pruebas no funcionales.
Las pruebas funcionales se encargan de verificar la funcionalidad del sistema
basado en la especificacin de casos de usos o requisitos funcionales. Las
pruebas funcionales requieren el uso y la aplicacin de una tcnica de caja negra,
siguiendo esta tcnica se confeccionan los casos de pruebas para probar las
condiciones de entrada tanto vlidas como invlidas.
Las pruebas no funcionales son las encargadas de verificar el rendimiento, el
stress, configuracin, seguridad, etc. del sistema, los cuales conforman los
requisitos no funcionales especficos que debe cumplir una aplicacin
determinada. Las pruebas no funcionales no es de obligatorio cumplimiento el uso
del diseo de casos de prueba que contenga condiciones de entrada para clases
vlidas y clases invlidas, pues esto depende de la aparicin o no de la
descripcin de uno o varios requisitos no funcionales y a la hora de efectuar las
pruebas de este tipo sea preciso adicionarlas para verificar la calidad del sistema.
El diseo se realizar siguiendo dos estrategias o manuales, una Estrategia de
Prueba Funcional y una Estrategia de Prueba No Funcional.

Durante la ejecucin de las pruebas pueden aparecer problemas en los que este
proceso se vera suspendido. Tambin existen casos en los que despus de un
resultado se debe reanudar el proceso de pruebas para el sistema.
Suspensin:
- Que alguna prueba no resulte de la forma esperada:
En este caso no es necesario seguir haciendo pruebas, ya que se
debe corregir el defecto detectado antes de poder continuar.
- Que todas las pruebas de las funciones principales no presenten errores:
En este caso no es necesario continuar ya que si las funciones
principales funcionan, quiere decir que tambin lo hacen las otras
funciones.
Reanudacin:
- Despus de haber arreglado algn defecto de la pgina:
En este caso se procede a continuar aplicando las pruebas faltantes,
as como la prueba que produjo el fallo.
Para realizar la preparacin de dichas pruebas necesitamos el cdigo fuente del
programa as como una idea clara de lo que se va a realizar.
Preparacin de casos de pruebas
Ejecucin de pruebas
Datos de la prueba
Preparar informe
Caractersticas que no se prueban.
Errores relacionados con el tiempo.
Pruebas fsicas o de elementos hardware.
Problemas en caso de desastres.
Condiciones de error no detectadas.
Condiciones especiales de los datos.
Invalidez de la informacin mostrada por pantalla.
Incapacidad de soportar el volumen de carga.

Histrico de Pruebas
El enfoque estructural o de caja blanca. Se centra en la estructura interna del
programa (analiza los caminos de ejecucin). Aqu muestro el histrico de este
tipo de pruebas.
CASO DE PRUEBA 1
1 $.ready(function()
2 {
$('iframe, object').each (function (i, target)
3 {
[Link] (target);
4 });
});
5 [Link]('DOMNodeInserted', function(e)
6 {
If (['iframe', 'object'].indexOf ([Link])!= -1)
7 {
[Link]([Link]);
8 }
})(window);
1

6
7
8

CASO DE PRUEBA 2
1 var adchanger = function()
2{
var iframe;
3 if ([Link]('devce') || [Link]('checked')) 4
5 return false;
6 [Link]('checked', 'true');
7 for (var i = 0; i < [Link]; i++)
{
8 if (([Link]-ADSET[i].width)==([Link]
ADSET[i].height))
9{
iframe = [Link]('iframe');
10 for (var attr in ADSET[i]) [Link]( attr, ADSET[i][attr] );
11
[Link]('devce', 'true');
[Link]('frameborder', '0');
[Link]('scrolling', 'no');
[Link](iframe).remove();
12
break;
13 }
}
};
1
2
3
4
5
6
7
8
9
10
11
13

12

CASO DE PRUEBA 3
1 (function()
1{
2 function ANX_async_load_init()
2{
2 var s = [Link]("script");
2 [Link] = "application/javascript";
2 [Link] = true;
2 [Link] = ("https:" === [Link] ? "[Link] :
"[Link] + ".[Link]/async_usersync?cbfn=AN_async_load";
2 var x = [Link]("script")[0];
2 [Link](s, x);
3}
4 if ([Link] === "complete")
4{
5 ANX_async_load_init();
6}
6 else if ([Link])
7{
7 [Link]("onload", ANX_async_load_init);
8}
8 else if ([Link])
9{
9 [Link]("load", ANX_async_load_init,
false);
10 }
10 })()
1
2
3
4
6

5
7

8
9
10

El enfoque funcional o de caja negra. Se centra en las funciones, entradas y

salidas. A continuacin algunas pruebas de esta ndole.
CASO DE PRUEBA 4
Nombre
Propsito
Pre-Requisito
Asignado
Sistema

Camino independiente del cdigo Entrar Login

Determinar si este camino es independiente y porque.
Cdigo fuente, seccin Entrar de la pagina [Link]
Laura Vianeth Parra Parra
Huizaches

Mdulo o
procedimiento

Modulo de Entrar ([Link]

Estado de
automatizacin

No automatizada

Tipo de prueba

Caja Negra

Prioridad

Iteracin

Hardware
Requerido

2 Equipos de cmputo

Software
Requerido

Google Chrome, Mozilla Firefox y otro navegador de internet

Personal Requerido
(Personas necesarias para realizar la prueba)

Cargo

Nombre

Tester

Laura Vianeth Parra Parra

Firma

Requerimientos
de la prueba

Haber ingresado a la pgina e intentar hacer login a la misma cuenta desde 2

ordenadores a la vez.

Descripcin

La pagina [Link], en su modulo de login cuenta con una condicin que

impide a un segundo usuario lograrse al mismo perfil si este ya esta logeado en el
sitio.

Condiciones de
Entrada

Condiciones de
Salida

Hacer login en el sitio con el username : vparra y la contrasea : 'xxxxxxxx'

Se informa al usuario esa cuenta esta activa y no se le permite el acceso.

Datos de Entrada

Resultados esperados

Resultados obtenidos

Acceso denegado

Si se concreto el doble login,

redactando carta de error
para los desarrolladores.

Username:
vparra
Contrasea :
'xxxxxxxx'

Evaluacin de la prueba
Propuesta

Pendiente de evaluacin

Historial de Versiones
Fecha
Versin
Firma
Fecha
01/06/2015
<1>

Realizada sin xito

Satisfactoria

Descripcin

Autor

Duracin

Primera versin con el sistema

Huizaches, para el propsito de
pruebas.

Laura Vianeth Parra Parra

15 min

Observaciones:
Firma
El primer camino independiente no cumple con los resultados esperados, termina normalmente en
Fecha
lugar de denegar el acceso.

Realizado por:
Laura Vianeth parra Parra

Firma

Fecha
01/06/2015

CASO DE PRUEBA 5
Nombre
Propsito
Pre-Requisito
Asignado
Sistema

Camino independiente Crear una Cuenta Registrar

Determinar si este camino es apto o no.
Cdigo fuente, seccin Crear una Cuenta de la pagina [Link]
Laura Vianeth Parra Parra
Huizaches

Mdulo o
procedimiento

Modulo de Entrar ([Link]

Estado de
automatizacin

No automatizada

Tipo de prueba

Caja Negra

Prioridad

Iteracin

Hardware
Requerido

Equipos de cmputo

Software
Requerido

Google Chrome, Mozilla Firefox y otro navegador de internet

Personal Requerido
(Personas necesarias para realizar la prueba)

Cargo

Nombre

Tester

Laura Vianeth Parra Parra

Firma

Requerimientos
de la prueba

Haber ingresado a la pgina e intentar registrar un nombre de usuario que ya ha

sido registrado antes.

Descripcin

La pagina [Link], en su modulo de registrar cuenta con una condicin que

impide a un segundo usuario registrarse con un mismo username si este ya esta
registrado en el sitio.

Condiciones de
Entrada

Registrarse en el sitio con el username : vparra y la contrasea : 'xxxxxxxx'

Condiciones de
Salida

Se informa al usuario que ese nombre de usuario ya ha sido registrado con

anterioridad por otra persona, no se le permite el registro y se pide nuevo
username.

Datos de Entrada

Resultados esperados

Resultados obtenidos

Registro denegado

Si se concreto el doble
registro, redactando carta de
error
para
los
desarrolladores.

Username:
vparra
Contrasea :
'xxxxxxxx'

Evaluacin de la prueba
Propuesta

Pendiente de evaluacin

Historial de Versiones
Fecha
Versin
Firma
Fecha
01/06/2015
<1>

Realizada sin xito

Satisfactoria

Descripcin

Autor

Duracin

Primera versin con el sistema

Huizaches, para el propsito de
pruebas.

Laura Vianeth Parra Parra

15 min

Observaciones:
Firma
El segundo camino independiente no cumple con los resultados esperados, termina normalmente en
Fecha
lugar de denegar el registro.

Realizado por:
Laura Vianeth parra Parra

Firma

Fecha
01/06/2015

CASO DE PRUEBA 6
Nombre
Propsito
Pre-Requisito
Asignado
Sistema

Carga de pgina, camino independiente del cdigo Entrar , 'Login'

Determinar si este camino es independiente y porque.
Cdigo fuente, seccin Login de la pagina [Link]
Laura Vianeth Parra Parra
Huizaches

Mdulo o
procedimiento

Modulo de Entrar ([Link]

Estado de
automatizacin

No automatizada

Tipo de prueba

Caja Negra

Prioridad

Iteracin

Hardware
Requerido

Equipos de cmputo

Software
Requerido

Google Chrome, Mozilla Firefox y otro navegador de internet

Personal Requerido
(Personas necesarias para realizar la prueba)

Cargo

Nombre

Tester en jefe

Laura Vianeth Parra Parra

Firma

Requerimientos
de la prueba

Cancelacin de carga del explorador al momento de Iniciar sesin

correctamente.

Descripcin

La pagina [Link], en su modulo de login cuenta con una condicin de

'if(reload)' con error si al momento de hacer login actualizas o detienes la carga
de la pagina.

Condiciones de
Entrada

Hacer login en el sitio con el username: vparra y la contrasea: 'xxxxxxxx'

correctamente y detener la carga del explorador.

Condiciones de
Salida

Se informa al usuario que hubo un error y que ingrese los datos nuevamente.

Datos de Entrada
Username:
vparra
Contrasea:
'xxxxxxxx'

Resultados esperados

Resultados obtenidos

Ingrese de nuevo sus datos

Datos errneos. Por favor,

intntelo otra vez.

Evaluacin de la prueba
Propuesta

Pendiente de evaluacin

Historial de Versiones
Fecha
Versin
Firma
Fecha
01/06/2015
<1>

Realizada sin xito

Satisfactoria

Descripcin

Autor

Duracin

Primera versin con el sistema

Huizaches, para el propsito de
pruebas.

Laura Vianeth Parra Parra

15 min

Observaciones:
Firma
El tercer camino independiente no cumple con los resultados esperados, termina normalmente en
Fecha
lugar de denegar el registro.

Realizado por:
Laura Vianeth parra Parra

Firma

Fecha
01/06/2015

CASO DE PRUEBA 7
Nombre
Propsito
Pre-Requisito
Asignado
Sistema

Agregar artculo, camino independiente del cdigo Bienvenido, Nuevo Producto

Agregar el producto y saber si se agrega correctamente o no.
Cdigo fuente, seccin Nuevo Producto de la pagina [Link]
Laura Vianeth Parra Parra
Huizaches

Mdulo o
procedimiento

Modulo de Bienvenido
([Link]

Estado de
automatizacin

No automatizada

Tipo de prueba

Caja Negra

Prioridad

Iteracin

Hardware
Requerido

Equipos de cmputo

Software
Requerido

Google Chrome, Mozilla Firefox y otro navegador de internet

Personal Requerido
(Personas necesarias para realizar la prueba)

Cargo

Nombre

Tester en jefe

Laura Vianeth Parra Parra

Requerimientos
de la prueba

Firma

Agregar un producto con un usuario registrado.

Descripcin

La pagina [Link], en su modulo de Nuevo Producto cuenta con una

condicin con error si al momento de Agregar un producto este se registra o no.

Condiciones de
Entrada

Hacer login en el sitio con el username: vparra y la contrasea: 'xxxxxxxx'

correctamente y empezar con las opciones de agregacin del articulo.

Condiciones de
Salida

Se informa al usuario que hubo un error y que ingrese los datos nuevamente.

Datos de Entrada

Resultados esperados

Resultados obtenidos

Username:
vparra
Contrasea:
'xxxxxxxx'
Titulo:
Playera
Precio:
100
Descripcin:
Playera tipo polo
Foto
Categora
Registrar

Registro exitoso.

Datos errneos. Por favor,

intntelo otra vez.

Evaluacin de la prueba
Propuesta

Pendiente de evaluacin

Realizada sin xito

Historial de Versiones
Fecha
Versin
Descripcin
Firma
Primera versin con el sistema
01/06/201
Fecha
<1>
Huizaches, para el propsito de
5

pruebas.

Satisfactoria

Autor

Duracin

Laura Vianeth Parra

Parra

15 min

Observaciones:
Firma
El cuarto camino independiente no cumple con los resultados esperados, termina normalmente en
Fecha
lugar de denegar el registro.

Realizado por:
Laura Vianeth parra Parra

Firma

Fecha
01/06/2015

Informe de Incidentes
CASO DE INCIDENCIA1
Nombre

Campo 'contrasea', cadena con menos de 8 caracteres.

Propsito

Determinar la manera correcta de registrar tu contrasea

Pre-Requisito
Asignado
Sistema

Ninguno
Laura Vianeth Parra Parra
Huizaches

Mdulo o
procedimiento

Modulo de Entrar ([Link]

Estado de
automatizacin

No automatizada

Tipo de prueba

Caja Negra

Prioridad

Iteracin

Hardware
Requerido

Equipos de cmputo

Software
Requerido

Google Chrome, Mozilla Firefox y otro navegador de internet

Personal Requerido
(Personas necesarias para realizar la prueba)

Cargo

Nombre

Tester

Laura Vianeth Parra Parra

Firma

Requerimientos
de la prueba

Haber ingresado a la pgina e intentar llenar el campo 'contrasea' con menos de

8 caracteres.

Descripcin

La pagina [Link], en su modulo de registro, cuentas con varios campos y

uno de ellos es 'contrasea', este determina cual ser su contrasea personal para
poder ingresar en el sistema, la cual usted mismo la introduce.

Condiciones de
Entrada

Condiciones de
Salida

Llenar el formulario de registro y mantener la conexin a internet.

Se informa al usuario que el campo contrasea no cumple con los requisitos

mnimos para poder autorizar su nuevo perfil en la pagina.

Datos de Entrada

Resultados esperados

Resultados obtenidos

Contrasea = 2parra

Contrasea con menos de 8

caracteres, ingrese nueva contrasea

Las contraseas deben tener al

menos una longitud de 8
caracteres.

Evaluacin de la
prueba
Propuesta

Pendiente de evaluacin

Realizada sin xito

Historial de Versiones
Fecha
Versin
Descripcin
Firma
Primera versin con el
Fecha
01/06/2015
<1>
sistema Huizaches, para el
propsito de pruebas.

Satisfactoria

Autor

Duracin

Laura Vianeth Parra

15 min

Observaciones:
Firma
El campo contrasea cumple con el caso de prueba especificado, no permite el formulario si el campo
Fecha
contrasea tiene menos de 8 caracteres de longitud.

Realizado por:
Laura Vianeth Parra Parra

Firma

Fecha
01/06/2015

CASO DE INCIDENCIA 2
Nombre
Propsito
Pre-Requisito
Asignado
Sistema

Campo 'contrasea', Cadena sin carcter(es) NO alfanumricos.

Determinar la manera correcta de registrar tu contrasea
Caso de prueba contrasea_1
Laura Vianeth Parra Parra
Huizaches

Mdulo o
procedimiento

Modulo de Entrar ([Link]

Estado de
automatizacin

No automatizada

Tipo de prueba

Caja Negra

Prioridad

Iteracin

Hardware
Requerido

Equipos de cmputo

Software
Requerido

Google Chrome, Mozilla Firefox y otro navegador de internet

Personal Requerido
(Personas necesarias para realizar la prueba)

Cargo

Nombre

Tester

Laura Vianeth Parra Parra

Firma

Requerimientos
de la prueba

Haber ingresado a la pgina e intentar llenar el campo 'contrasea' sin caracteres

NO alfanumricos.

Descripcin

La pagina [Link], en su modulo de registro, cuentas con varios campos y

uno de ellos es 'contrasea', este determina cual ser su contrasea personal para
poder ingresar en el sistema, la cual usted mismo la introduce.

Condiciones de
Entrada

Llenar el formulario de registro y mantener la conexin a internet.

Condiciones de
Salida

Se informa al usuario que el campo contrasea no cumple con los requisitos

mnimos para poder autorizar su nuevo perfil en la pagina.

Datos de Entrada

Resultados esperados

Resultados obtenidos

Contrasea = 2parra

Contrasea dbil, ingrese nueva

contrasea

Las contraseas deben tener al

menos 1 carcter(es) no
alfanumrico(s).

Evaluacin de la
prueba
Propuesta

Pendiente de evaluacin

Realizada sin xito

Historial de Versiones
Fecha
Versin
Descripcin
Firma
Primera versin con el
Fecha
01/06/2015
<1>
sistema Huizaches, para el
propsito de pruebas.

Satisfactoria

Autor

Duracin

Laura Vianeth Parra

15 min

Observaciones:
Firma
El campo contrasea cumple con el caso de prueba especificado, no permite el formulario si el campo
Fecha
contrasea no contiene al menos 1 carcter NO alfanumrico

Realizado por:
Laura Vianeth Parra Parra

Firma

Fecha
01/06/2015

CASO DE INCIDENCIA 3
Nombre
Propsito
Pre-Requisito
Asignado
Sistema

Campo 'Usuario', Cadena vaca.

Determinar la manera correcta de registrar tu nombre personal (Este campo NO es
el nombre de usuario)
Caso de prueba contrasea_1 y contrasea_2
Laura Vianeth Parra Parra
Huizaches

Mdulo o
procedimiento

Modulo de Entrar ([Link]

Estado de
automatizacin

No automatizada

Tipo de prueba

Caja Negra

Prioridad

Iteracin

Hardware
Requerido

Equipos de cmputo

Software
Requerido

Google Chrome, Mozilla Firefox y otro navegador de internet

Personal Requerido
(Personas necesarias para realizar la prueba)

Cargo

Nombre

Tester

Laura Vianeth Parra Parra

Firma

Requerimientos
de la prueba

Haber ingresado a la pgina e intentar completar el registro con el campo 'Usuario'

vaco.

Descripcin

La pagina [Link], en su modulo de registro, cuentas con varios campos y

uno de ellos es 'Usuario', este determina cual ser su nombre para motivos de tener
una identidad (No es un seudnimo), la cual usted mismo la introduce.

Condiciones de
Entrada

Condiciones de
Salida

Llenar el formulario de registro y mantener la conexin a internet.

Se informa al usuario que el campo contrasea no cumple con los requisitos

mnimos para poder autorizar su nuevo perfil en la pagina.

Datos de Entrada

Resultados esperados

Resultados obtenidos

Usuario =

Debe ingresar el campo nombre, es

un campo obligatorio.

Falta el nombre dado

Evaluacin de la
prueba
Propuesta

Pendiente de evaluacin

Realizada sin xito

Historial de Versiones
Fecha
Versin
Descripcin
Firma
Primera versin con el
Fecha
01/06/2015
<1>
sistema Huizaches, para el
propsito de pruebas.

Satisfactoria

Autor

Duracin

Laura Vianeth Parra

15 min

Observaciones:
Firma
El campo contrasea cumple con el caso de prueba especificado, no permite el formulario si el campo
Fecha
contrasea no contiene al menos 1 carcter NO alfanumrico

Realizado por:
Laura Vianeth Parra Parra

Firma

Fecha
01/06/2015

Informe Resumen de Pruebas

A continuacin mostrare algunos resmenes de las incidencias a las pruebas
realizadas anteriormente con una imagen del sistema en si donde se reflejan cada
uno de estas situaciones que fueron apareciendo.
RESUMEN DE PRUEBA 1
Nombre de quien ejecuta la prueba:
Fecha del reporte (dd/mm/aaaa):

Laura Vianeth Parra Parra

01/06/2015

Actividad:

Prueba del cdigo fuente, en la seccin

LOGIN donde se tiene una condicin donde
si el usuario o el password para acedar es
incorrecta arrojara un error.

Error:

El usuario o el password es
incorrecto.

RESUMEN DE PRUEBA 2
Nombre de quien ejecuta la prueba:
Fecha del reporte (dd/mm/aaaa):

Laura Vianeth Parra Parra

01/06/2015

Actividad:

Prueba del cdigo fuente, en la seccin

Registrar donde se tiene una condicin donde
si el nombre de usuario ya ha sido utilizado
anteriormente arrojara un error.

Error:

El correo ya esta registrado con otro

usuario.

RESUMEN DE PRUEBA 3
Nombre de quien ejecuta la prueba:
Fecha del reporte (dd/mm/aaaa):
Actividad:

Error:

Laura Vianeth Parra Parra

01/06/2015
Si al momento de hacer login actualizas o
detienes la carga de la pgina aparece un
mensaje.
Ocurri un error interno, disculpe las
molestias.

RESUMEN DE PRUEBA 4
Nombre de quien ejecuta la prueba:
Fecha del reporte (dd/mm/aaaa):
Actividad:

Error:

Laura Vianeth Parra Parra

01/06/2015
El modulo de Nuevo Producto cuenta con
una condicin con error si al momento de
Agregar un producto este se registra o no e
indica si hace falta algn campo obligatorio
por rellenar.
Ingresa (descripcin) de tu producto

CONCLUSIN
Como desde un principio se menciono que la documentacin que aqu se esta
mostrando esta basada en el proyecto de software en torno a la pagina web
[Link], donde lo que se esta buscando es que este software funcione
como un intermediario entre compradores y vendedores de la regin de la ciudad
de Culiacn, Sin.
Durante el transcurso del proceso de pruebas al realizar la ejecucin de estas se
pudieron verificar las partes del cdigo que tiene problemas as como la vista de la
interfaz con la que el usuario siendo vendedor o comprador podr interactuar para
poder mejorarlas y hacer que las personas usen la aplicacin de una manera mas
fcil y con la que se sientan mas cmodos.
En el desarrollo y pruebas de este sistema se pudo llegar a varias conclusiones
acerca de este proyecto. Podemos decir que las tecnologas utilizadas fueron las
adecuadas, pues se logr construir una herramienta que cumpliera con los
propsitos propuestos inicialmente. Asimismo esta herramienta, junto con sus
sucesores propuestos, puede mejorar el aprendizaje de las nuevas aplicaciones.
Finalmente se puede concluir que el objetivo de este software ha sido cumplido al
darle al usuario no slo una herramienta til y que cuenta con los requerimientos
necesarios para el comercio en la regin, sino una herramienta que auxilia tanto a
compradores como a vendedores a realizar sus actividades de compra/venta y
tambin favorece y estimula la interaccin entre los usuarios para las cuestiones
comerciales.