• Author / Uploaded
• Julio Gastelum

Citation preview

INSTITUTO TECNOLÓGICO DE CULIACÁN

INGENIERÍA EN SISTEMAS COMPUTACIONALES EVALUACIÓN # 3 PROYECTO PARA PRUEBAS DE SOFTWARE APLICACIÓN AL SOFTWARE Huizaches.com

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

APLICACIÓN AL SOFTWARE Huizaches.com

ESTÁNDAR IEEE 829

Plan De Pruebas Del Software 1. Identificador único del documento (para la gestión de configuración). Proyecto_Final_PRUSOFT

2. Introducción y resumen de elementos y características a probar. La documentación pertinente que mostraremos esta basada en el proyecto de software en torno a la pagina web Huizaches.com, su uso principal es la de funcionar como un intermediario entre compradores y vendedores de la región de la ciudad de Culiacán, Sin., haciendo mención al lugar ubicado en esta ciudad donde se realiza esta misma función de forma física. En dicho software se muestra un entorno fácil de usar para los usuario dando lugar a un panorama inicial con la bienvenida al mismo donde se visualizan también campos de categorización de productos, información acerca del servicio, área de login para vendedores y compradores así como opciones de contacto y administrar. El presente plan de pruebas contiene la descripción de los casos de prueba definidos con el fin de validar y verificar que el desarrollo cumple con los requisitos funcionales. Las pruebas se harán en las siguientes categorías: Fluidez de datos Soporte del software Interfaz de usuario Unitarias Funcionalidad Rendimiento Integración Requisitos

3. Elementos software que se van a probar (por ejemplo programas o módulos) MODULO ENTRADA

Selección de campo: Se elige el campo de la página con el cual trabajar. Definición de parámetros: Define los parámetros a introducir en cada campo. Introduce la información requerida: Se introducen los datos para acceder a la actividad. MODULO PROCESO

Se inicializa en la pantalla la interacción con el usuario. Se actualiza la pantalla después de acceder a la actividad y aparecen opciones a elegir según la actividad: Explora el área para proseguir con la funcionalidad de la actividad: Se registra la actividad (compra/venta) según sea el usuario. MODULO SALIDA

Visualización por completo de la actividad en ejecución.

Sistema de gestión de base de datos Tipo de software muy específico, 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 sistemáticamente para su posterior uso.

4. Características que se van a probar. FUNCIONALIDAD

DESCRIPCIÓN

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.

Categorías

Se utiliza como opción para comprar ya que se muestran productos existentes.

Bienvenido (después de entrar)

Muestra diferentes opciones según sea el caso (comprador/vendedor). Comprador Perfil Mis compras Carrito Vendedor Perfil Nuevo producto Mis productos

5. Características que no se prueban. Errores relacionados con el tiempo. Pruebas físicas o de elementos hardware. Problemas en caso de desastres. Condiciones de error no detectadas. Condiciones especiales de los datos. Invalidez de la información mostrada por pantalla. Incapacidad de soportar el volumen de carga.

6. Enfoque general de la prueba (actividades, técnicas, 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 aplicación la pueden operar. Se busca lograr proporcionar a nuestros usuarios una interfaz gráfica bien organizada, similar a la de otras aplicaciones, con campos fáciles de entender y sobre todo manejables. PRUEBAS FUNCIONALES

Tienen por objetivo probar que el sistema implementado cumpla con la funciones. Básicamente el enfoque de este tipo de prueba se basa en el análisis 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 parámetros de rendimiento. Cuando el sistema debe procesar tantos datos, o cuánta memoria consume, o cuánto espacio en disco utiliza, o cuántos datos transfiere por un canal de comunicaciones. Para todos estos parámetros es importante conocer cómo evolucionan al variar la dimensión del problema. INTEGRACIÓN

Las pruebas de integración 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 técnicas de captura y análisis de requisitos (prototipos, casos de uso, etc.). El resultado es una descripción de las funciones del sistema

7. Criterios de paso/fallo para cada elemento. Esta sección determina cuales son los criterios que se encargan de aprobar la calidad de un producto, así también se establece cual es el criterio de fallo que se encargará de hundir la aplicación. 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 aplicación logra iniciar un usuario previamente en la base de datos, en caso de poder hacer un inicio de sesión 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 después. Esta otra parte se relaciona con las dos anteriores, se encarga de revisar que el sistema pueda cerrar la sesión 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 débiles a la hora de acceder a la base de datos, aquí también entra la prueba de categorías 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 aceptación de esta prueba. La última prueba tiene que ver con Bienvenido (después de entrar), para esta ocasión también 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 evalúa si una prueba fue un fracaso se obtiene a partir de las pruebas anteriores, en esta caso si la aplicación no logra terminar las pruebas mencionadas anteriormente entonces se considera que se cumplió un criterio de fallo

8. Criterios de suspensión y requisitos de reanudación. Durante la ejecución de las pruebas pueden aparecer problemas en los que este proceso se vería suspendido. También existen casos en los que después de un resultado se debe reanudar el proceso de pruebas para el sistema. Suspensión: - 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 también lo hacen las otras funciones. Reanudación: - Después de haber arreglado algún defecto de la página: En este caso se procede a continuar aplicando las pruebas faltantes, así como la prueba que produjo el fallo.

9. Documentos a entregar (como mínimo, los descritos en el estándar). Entre los documentos que se entregaran para el proceso de pruebas se encuentran los siguientes: - Documento del plan de pruebas. - Especificación de diseño de pruebas - Especificación de casos de pruebas - Especificación de procedimientos de pruebas - Histórico de Pruebas (Test Log). - Informe Resumen De Pruebas (Test Summary Report). - Los resultados esperados

10. Actividades de preparación y ejecución de pruebas. Para realizar la preparación de dichas pruebas necesitamos el código fuente del programa así como una idea clara de lo que se va a realizar. Preparación de casos de pruebas Ejecución de pruebas Datos de la prueba Preparar informe

11. Necesidades de entorno. Entorno HTML Entorno Java Sistema operativo indistinto Diseño de la BD

12. Responsabilidades de la organización y realización de las pruebas. Responsabilidades

Plan de pruebas Especificación de diseño de pruebas Especificación de casos de pruebas Especificación de procedimientos de pruebas Histórico de pruebas Informe Resumen De Pruebas Los resultados esperados

Vianeth Parra

Vianeth Parra

Vianeth Parra

   

13. Necesidades de personal y de formación. Que se tenga conocimientos de lenguaje HTML Conocimientos de Lenguaje de Programación 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 críticos Procedimientos alternativos Tratamiento de errores Posibilidad de error recuperación Planificación contenido mensajes de error

16. Aprobaciones y firmas con nombre y puesto desempeñado. 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

Especificación de diseño de pruebas 1. Características a probar de los elementos software (y combinaciones de características). Fluidez de datos Soporte del software Interfaz de usuario Unitarias Funcionalidad Rendimiento Integración Requisitos

2. Detalles sobre el plan de pruebas del que surge este diseño, incluyendo las técnicas de prueba específica y los métodos de análisis de resultados. Desarrollo de una solución o diseño que permita satisfacer los requisitos del cliente (no sólo en términos de calidad, sino también en términos de coste y plazo) de manera que todas y cada una de las características de diseño sean trazables a los requisitos de cliente y viceversa. En el caso de existir diversas alternativas de diseño, 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 consideración, pero precisara de una modificación de objetivos, deberá consultar al sponsor o patrocinador del proyecto. Elaboración de una filosofía o estrategia de pruebas que permita detectar en una fase posterior incumplimientos de los requisitos por parte de la solución adoptada para así proceder a su corrección. Ésta consistirá básicamente en determinar entre otros: 1.- Como se demostrará cada uno de los requisitos de cliente 2.- Número de prototipos, etc. Gestionar la fase de acuerdo al plan de proyecto dentro del coste y plazo asignado. Los entregables de la fase de diseño son, además de la solución o diseño y la estrategia de pruebas arriba mencionadas, la actualización del plan de proyecto a partir de la información disponible al acabar la fase.

3. Identificación 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 diseño de la fase anterior y de manera que éste no pierda sus características debido a una fabricación 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 diseño realizado definiendo los diferentes niveles de prueba (componente, módulo, sistema). 2.- Elaborar procedimientos de prueba para los diferentes niveles. Validar y depurar el diseño modificando el mismo si fuera necesario a la vista de los resultados de las pruebas. Se distingue entre: 1.- pruebas de diseño cuyo objeto es validar el enfoque de diseño realizado utilizando prototipos o modelos de ingeniería 2.- pruebas de calificación cuyo objetivo es demostrar que el producto cumple con los requisitos de cliente plasmados en una especificación. 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 característica o combinación de características ha pasado con éxito. la prueba o no) Esta fase es más 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 más 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 implantación 3.- Falta de formación y de apoyo durante la fase inicial de operación 4.- Errores en la estrategia de comunicación 5.- Resistencia al cambio de los usuarios no adecuadamente gestionada por el director de proyecto.

Especificación de caso de prueba A continuación se pasara a describir los casos de pruebas junto con sus especificaciones, características, e información relacionada con la misma. El entorno del cual partiremos para realizar la prueba será el formulario de entrada de la aplicación, es decir de la pagina inicial los campos que se deben llenar para poder utilizar la aplicación 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 artículos Comprar productos Promover sus productos Comercializar artículos Vender

El sistema estará implantado en una página web a través de internet, sirviendo a diferentes usuarios (Compradores, Vendedores) e invocando servicios de otros sistemas como autorización de pagos, contabilidad, soporte técnico, etc.

MODELO DE CASOS DE USO Lista actor-semántica Actor Vendedor Administrador del sistema Cliente

Semántica Usuario principal del sistema, registra los artículos, vende y cobra la venta. Mantiene y soporta el sistema, procesa usuarios, y vigila la seguridad del sistema. Compra artículos, efectúa pagos y promociones y realiza devoluciones.

Lista actor-objetivo Actor Vendedor Administrador del sistema

Cliente Lista de casos de uso Vendedor: CU1: Registrar artículos CU2: Procesar venta CU3: Realizar devoluciones CU4: Efectuar promociones CU5: Modificar precios Administrador: CU6: Registrar usuarios CU7: Procesar garantías 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 artículos

del

Descripción breve de casos de uso CU1: Registrar artículos Un vendedor con un artículo nuevo registra la cantidad de artículos con los que cuenta, el precio, características y una descripción breve de este en el sistema. CU2: Procesar venta El cliente encuentra artículos 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 artículos en inventario, el vendedor proporciona las facilidades de pago y el cliente obtiene sus artículos. 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 artículo similar. CU4: Efectuar promociones El cliente desea comprar artículos en promoción, el vendedor debe de especificar la promoción en el sistema y efectuarla. Los movimientos se registraran junto con las ventas. CU5: Modificar precios El vendedor del sistema en coordinación con el administrador modificaran precios y promociones de artículos, 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 además de asignarle un usuario y contraseña para el acceso del mismo siendo este un vendedor. CU7: Procesar garantías Un cliente compra un artículo y desea hacer efectiva su garantía pues este falló, el administrador le solicita su comprobante de compra al cliente, el artículo se envía a reparación y registra en el sistema el uso de la garantía.

CU8: Registrar cliente Un cliente solicita afiliarse a la pagina para servicios tales como envió a domicilio, promociones o facturación 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 contraseña para poder acceder a la pagina. CU9: Consultar inventario Si un comprador desea conocer la existencia de un artículo en el inventario de esa base de datos de la página será posible realizando una consulta a este y conocer precios, modelo y otros detalles de interés. CU10: Realizar pedido a vendedor Se registran los artículos prospectos a pedido y se envía al centro de distribución. Los artículos solicitados son enviados al almacén de la sucursal y son registradas en el inventario tanto del almacén como del centro de distribución. 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 fácil, rápido y de manera concisa, para evitar pérdidas. Servicio de autorización de pagos: Quiere atender peticiones de pago con los datos correctos para registrar el cobro. Pagina “huizaches.com”: 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. También quiere una administración rápida y actualizada del inventario. Comprador: Quiere adquirir artículos rápidamente con la forma de pago que el desee usar. Precondiciones: El vendedor ingresa al sistema con su nombre de usuario y contraseña correspondiente. Garantías de éxito (Postcondiciones): Se registra la venta. El inventario es actualizado. Se expide el cobro. El comprador adquiere satisfactoriamente sus artículos. Se registra el tipo de pago y su autorización. Escenario principal de éxito (o flujo básico): 1. El cliente selecciona los artículos que desea comprar. 2. El vendedor inicia un nuevo registro de venta. 3. El vendedor registra el artículo. 4. El artículo es registrado en el sistema y se presentan los datos del artículo y se muestra un subtotal. El vendedor repite los pasos 3 y 4 hasta que ya no haya artículos. 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 envía o entrega el artículo al cliente según el caso de pago. Extensiones o flujos alternativos: *a. En cualquier momento el sistema falla. 1. El administrador reinicia el sistema, inicia la sesión y solicita recuperación al estado anterior. 2. El sistema reconstruye el estado anterior. 2a. El sistema detecta anomalías intentando la recuperación: 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 artículo. Se repite el paso 1 hasta encontrar otro articulo. 3. Registro de artículo invalido. 1. El sistema señala el error y rechaza la entrada 3-6a. El comprador pide al vendedor eliminar un artículo de la venta. 1. El vendedor selecciona la venta y el artículo 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 recuperación. 5a. El comprador solicita un descuento por ser cliente leal. 1. El comprador proporciona su código de cliente al vendedor. 2. El sistema valida el código 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 número de cuenta al vendedor. 2. El sistema valida el número 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 “huizaches.com”: Quiere llevar un registro conciso de los pedidos y satisfacer las necesidades de los compradores con suficiente surtido de productos, pero solo el necesario. También quiere una administración rápida 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 contraseña correspondiente. Garantías de éxito (Postcondiciones): Se registra el pedido. Se expide la orden de pedido. Escenario principal de éxito (o flujo básico): 10. El comprador selecciona el vendedor correspondiente. 11. El comprador ingresa el artículo y cantidad. 12. El artículo es registrado en el sistema y muestra sus datos. 13. El sistema muestra el total de artículos y cantidad. 14. El sistema solicita la confirmación 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 sesión y solicita recuperación al estado anterior. 2. El sistema reconstruye el estado anterior. 2a. El sistema detecta anomalías intentando la recuperación: 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

Especificación de procedimiento de prueba 1. Identificador único de la especificación y referencia a la correspondiente especificación de diseño de prueba. En esta sección se definirán los tipos de pruebas que se le aplicarán al software, explicando bien sus objetivos y metas. En la interacción 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 función del sistema al fijar la tensión en la validación de las funciones, métodos, servicios y casos de usos. Metas Validar que la aplicación:  Cumpla con los requisitos funcionales especificados en el diseño de la solución.  Cumpla con los requisitos No funcionales especificados en el diseño de la solución.  Cumpla con las restricciones de entrada y salida de la información especificada en el diccionario de Datos, de cada caso de uso.  Cumpla íntegramente con la estructura referencial especificada en el Mapa de Navegación. 2. Prueba de Seguridad Objetivo Verificar que los mecanismos de protección incorporados en el sistema realmente lo protegerán de accesos impropios. Metas Validar que en la aplicación:  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 aplicación cambiando la infraestructura de red al aplicar diferentes configuraciones, o retardos. Metas Validar que en la aplicación:  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 ejecución dentro del contexto de un sistema integrado y así como la verificación de la capacidad del sistema para manejar volúmenes de datos extremos de acuerdo a la velocidad que se especifique para el sistema. Metas Validar en la aplicación:  Comprobar los tiempos de respuesta del sistema en una cantidad limitada de escenarios de trabajo (a nivel de número de usuarios y número de transacciones), bajo una configuración de hardware y software constante.  Comprobar el tiempo de respuesta al realizar una función.  Comprobar el tiempo de respuesta al realizar accesos concurrentes a una determinada información.  Atender múltiples 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 aplicación:  Sistemas Operativos.  Navegadores. 6. Prueba de Resistencia o Stress Objetivo Verificar cómo se comporta el sistema bajo condiciones anormales: Metas Validar en la aplicación:  Carencia de sistemas externos con los que interactúa el sistema.  Aplicar carga excesiva de trabajo al sistema (extremas sobrecarga).  Recursos compartidos no disponibles.  Además verifica qué hace el sistema cuando el usuario no hace lo que supuestamente debe hacer. 7. Prueba de Usabilidad Objetivo Determinar si la organización 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 aplicación:  Para poder ver las páginas adecuadamente necesita utilizar un navegador compatible con estándares Web.  Proporcionar al usuario información relacionada con el estado actual del sistema.

8. Prueba de Fiabilidad Objetivo Verificar la probabilidad de que ese sistema funcione o desarrolle una cierta función, bajo condiciones fijadas y durante un período de tiempo determinado. Meta Validar en la aplicación:  El sistema deberá estar disponible todo el tiempo.  El tiempo permitido para que el sistema pueda estar fuera de operación después de un fallo no debe exceder 2 días. Esta sección determina cuales son los criterios que se encargan de aprobar la calidad de un producto, así también se establece cual es el criterio de fallo que se encargará de hundir la aplicación. 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 especificación de casos de usos o requisitos funcionales. Las pruebas funcionales requieren el uso y la aplicación de una técnica de caja negra, siguiendo esta técnica se confeccionan los casos de pruebas para probar las condiciones de entrada tanto válidas como inválidas. Las pruebas no funcionales son las encargadas de verificar el rendimiento, el stress, configuración, seguridad, etc. del sistema, los cuales conforman los requisitos no funcionales específicos que debe cumplir una aplicación determinada. Las pruebas no funcionales no es de obligatorio cumplimiento el uso del diseño de casos de prueba que contenga condiciones de entrada para clases válidas y clases inválidas, pues esto depende de la aparición o no de la descripción 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 diseño se realizará siguiendo dos estrategias o manuales, una Estrategia de Prueba Funcional y una Estrategia de Prueba No Funcional.

Durante la ejecución de las pruebas pueden aparecer problemas en los que este proceso se vería suspendido. También existen casos en los que después de un resultado se debe reanudar el proceso de pruebas para el sistema. Suspensión: - 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 también lo hacen las otras funciones. Reanudación: - Después de haber arreglado algún defecto de la página: En este caso se procede a continuar aplicando las pruebas faltantes, así como la prueba que produjo el fallo. Para realizar la preparación de dichas pruebas necesitamos el código fuente del programa así como una idea clara de lo que se va a realizar. Preparación de casos de pruebas Ejecución de pruebas Datos de la prueba Preparar informe Características que no se prueban. Errores relacionados con el tiempo. Pruebas físicas o de elementos hardware. Problemas en caso de desastres. Condiciones de error no detectadas. Condiciones especiales de los datos. Invalidez de la información mostrada por pantalla. Incapacidad de soportar el volumen de carga.

Histórico de Pruebas El enfoque estructural o de caja blanca. Se centra en la estructura interna del programa (analiza los caminos de ejecución). Aquí muestro el histórico de este tipo de pruebas. CASO DE PRUEBA 1 1 $.ready(function() 2 { $('iframe, object').each (function (i, target) 3 { adchanger.call (target); 4 }); }); 5 document.on('DOMNodeInserted', function(e) 6 { If (['iframe', 'object'].indexOf (e.target.localName)!= -1) 7 { adchanger.call(e.target); 8 } })(window); 1

2

3

4

5

6 7 8

CASO DE PRUEBA 2 1 var adchanger = function() 2{ var iframe; 3 if (this.data('devce') || this.data('checked')) 4 5 return false; 6 this.data('checked', 'true'); 7 for (var i = 0; i < ADSET.length; i++) { 8 if ((this.offsetWidth-ADSET[i].width)==(this.offsetHeight ADSET[i].height)) 9{ iframe = document.createElement('iframe'); 10 for (var attr in ADSET[i]) iframe.attr( attr, ADSET[i][attr] ); 11 iframe.data('devce', 'true'); iframe.attr('frameborder', '0'); iframe.attr('scrolling', 'no'); this.before(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 = document.createElement("script"); 2 s.type = "application/javascript"; 2 s.async = true; 2 s.src = ("https:" === document.location.protocol ? "https://secure" : "http://ib") + ".adnxs.com/async_usersync?cbfn=AN_async_load"; 2 var x = document.getElementsByTagName("script")[0]; 2 x.parentNode.insertBefore(s, x); 3} 4 if (document.readyState === "complete") 4{ 5 ANX_async_load_init(); 6} 6 else if (window.attachEvent) 7{ 7 window.attachEvent("onload", ANX_async_load_init); 8} 8 else if (window.addEventListener) 9{ 9 window.addEventListener("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 continuación algunas pruebas de esta índole. CASO DE PRUEBA 4 Nombre Propósito Pre-Requisito Asignado Sistema

Camino independiente del código Entrar “Login” Determinar si este camino es independiente y porque. Código fuente, sección Entrar de la pagina Huizaches.com Laura Vianeth Parra Parra Huizaches

Módulo o procedimiento

Modulo de Entrar (http://alexservice.cloudapp.net/login.xhtml)

Estado de automatización

“No automatizada”

Tipo de prueba

Caja Negra

Prioridad

3

Iteración

1

Hardware Requerido

2 Equipos de cómputo

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 página e intentar hacer login a la misma cuenta desde 2 ordenadores a la vez.

Descripción

La pagina Huizaches.com, en su modulo de login cuenta con una condición 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 contraseña : '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 Contraseña : 'xxxxxxxx'

Evaluación de la prueba Propuesta

Pendiente de evaluación

Historial de Versiones Fecha Versión Firma Fecha 01/06/2015

Realizada sin éxito

Satisfactoria

Descripción

Autor

Duración

Primera versión con el sistema Huizaches, para el propósito 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 Propósito Pre-Requisito Asignado Sistema

Camino independiente Crear una Cuenta “Registrar” Determinar si este camino es apto o no. Código fuente, sección Crear una Cuenta de la pagina Huizaches.com Laura Vianeth Parra Parra Huizaches

Módulo o procedimiento

Modulo de Entrar (http://alexservice.cloudapp.net/registrar.xhtml)

Estado de automatización

“No automatizada”

Tipo de prueba

Caja Negra

Prioridad

3

Iteración

2

Hardware Requerido

Equipos de cómputo

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 página e intentar registrar un nombre de usuario que ya ha sido registrado antes.

Descripción

La pagina Huizaches.com, en su modulo de registrar cuenta con una condición 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 contraseña : '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 Contraseña : 'xxxxxxxx'

Evaluación de la prueba Propuesta

Pendiente de evaluación

Historial de Versiones Fecha Versión Firma Fecha 01/06/2015

Realizada sin éxito

Satisfactoria

Descripción

Autor

Duración

Primera versión con el sistema Huizaches, para el propósito 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 Propósito Pre-Requisito Asignado Sistema

Carga de página, camino independiente del código Entrar , 'Login' Determinar si este camino es independiente y porque. Código fuente, sección Login de la pagina Huizaches.com Laura Vianeth Parra Parra Huizaches

Módulo o procedimiento

Modulo de Entrar (http://alexservice.cloudapp.net/login.xhtml)

Estado de automatización

“No automatizada”

Tipo de prueba

Caja Negra

Prioridad

2

Iteración

3

Hardware Requerido

Equipos de cómputo

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

Cancelación de carga del explorador al momento de Iniciar sesión correctamente.

Descripción

La pagina Huizaches.com, en su modulo de login cuenta con una condición 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 contraseña: '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 Contraseña: 'xxxxxxxx'

Resultados esperados

Resultados obtenidos

Ingrese de nuevo sus datos

Datos erróneos. Por favor, inténtelo otra vez.

Evaluación de la prueba Propuesta

Pendiente de evaluación

Historial de Versiones Fecha Versión Firma Fecha 01/06/2015

Realizada sin éxito

Satisfactoria

Descripción

Autor

Duración

Primera versión con el sistema Huizaches, para el propósito 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 Propósito Pre-Requisito Asignado Sistema

Agregar artículo, camino independiente del código Bienvenido, “Nuevo Producto” Agregar el producto y saber si se agrega correctamente o no. Código fuente, sección Nuevo Producto de la pagina Huizaches.com Laura Vianeth Parra Parra Huizaches

Módulo o procedimiento

Modulo de Bienvenido (http://alexservice.cloudapp.net/seller/productos/agregar.xhtml)

Estado de automatización

“No automatizada”

Tipo de prueba

Caja Negra

Prioridad

2

Iteración

4

Hardware Requerido

Equipos de cómputo

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.

Descripción

La pagina Huizaches.com, en su modulo de Nuevo Producto cuenta con una condición 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 contraseña: 'xxxxxxxx' correctamente y empezar con las opciones de agregación 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 Contraseña: 'xxxxxxxx' Titulo: Playera Precio: 100 Descripción: Playera tipo polo Foto Categoría Registrar

Registro exitoso.

Datos erróneos. Por favor, inténtelo otra vez.

Evaluación de la prueba Propuesta

Pendiente de evaluación

Realizada sin éxito

Historial de Versiones Fecha Versión Descripción Firma Primera versión con el sistema 01/06/201 Fecha

Huizaches, para el propósito de 5

pruebas.

Satisfactoria

Autor

Duración

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 'contraseña', cadena con menos de 8 caracteres.

Propósito

Determinar la manera correcta de registrar tu contraseña

Pre-Requisito Asignado Sistema

Ninguno Laura Vianeth Parra Parra Huizaches

Módulo o procedimiento

Modulo de Entrar (http://alexservice.cloudapp.net/registrar.xhtml)

Estado de automatización

“No automatizada”

Tipo de prueba

Caja Negra

Prioridad

3

Iteración

1

Hardware Requerido

Equipos de cómputo

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 página e intentar llenar el campo 'contraseña' con menos de 8 caracteres.

Descripción

La pagina Hizaches.com, en su modulo de registro, cuentas con varios campos y uno de ellos es 'contraseña', este determina cual será su contraseña 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 conexión a internet.

Se informa al usuario que el campo contraseña no cumple con los requisitos mínimos para poder autorizar su nuevo perfil en la pagina.

Datos de Entrada

Resultados esperados

Resultados obtenidos

Contraseña = “2parra”

Contraseña con menos de 8 caracteres, ingrese nueva contraseña

Las contraseñas deben tener al menos una longitud de 8 caracteres.

Evaluación de la prueba Propuesta

Pendiente de evaluación

Realizada sin éxito

Historial de Versiones Fecha Versión Descripción Firma Primera versión con el Fecha 01/06/2015

sistema Huizaches, para el propósito de pruebas.

Satisfactoria

Autor

Duración

Laura Vianeth Parra

15 min

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

Realizado por: Laura Vianeth Parra Parra

Firma

Fecha 01/06/2015

CASO DE INCIDENCIA 2 Nombre Propósito Pre-Requisito Asignado Sistema

Campo 'contraseña', Cadena sin carácter(es) NO alfanuméricos. Determinar la manera correcta de registrar tu contraseña Caso de prueba contraseña_1 Laura Vianeth Parra Parra Huizaches

Módulo o procedimiento

Modulo de Entrar (http://alexservice.cloudapp.net/registrar.xhtml)

Estado de automatización

“No automatizada”

Tipo de prueba

Caja Negra

Prioridad

2

Iteración

2

Hardware Requerido

Equipos de cómputo

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 página e intentar llenar el campo 'contraseña' sin caracteres NO alfanuméricos.

Descripción

La pagina Hizaches.com, en su modulo de registro, cuentas con varios campos y uno de ellos es 'contraseña', este determina cual será su contraseña personal para poder ingresar en el sistema, la cual usted mismo la introduce.

Condiciones de Entrada

Llenar el formulario de registro y mantener la conexión a internet.

Condiciones de Salida

Se informa al usuario que el campo contraseña no cumple con los requisitos mínimos para poder autorizar su nuevo perfil en la pagina.

Datos de Entrada

Resultados esperados

Resultados obtenidos

Contraseña = “2parra”

Contraseña débil, ingrese nueva contraseña

Las contraseñas deben tener al menos 1 carácter(es) no alfanumérico(s).

Evaluación de la prueba Propuesta

Pendiente de evaluación

Realizada sin éxito

Historial de Versiones Fecha Versión Descripción Firma Primera versión con el Fecha 01/06/2015

sistema Huizaches, para el propósito de pruebas.

Satisfactoria

Autor

Duración

Laura Vianeth Parra

15 min

Observaciones: Firma El campo contraseña cumple con el caso de prueba especificado, no permite el formulario si el campo Fecha contraseña no contiene al menos 1 carácter NO alfanumérico

Realizado por: Laura Vianeth Parra Parra

Firma

Fecha 01/06/2015

CASO DE INCIDENCIA 3 Nombre Propósito Pre-Requisito Asignado Sistema

Campo 'Usuario', Cadena vacía. Determinar la manera correcta de registrar tu nombre personal (Este campo NO es el nombre de usuario) Caso de prueba contraseña_1 y contraseña_2 Laura Vianeth Parra Parra Huizaches

Módulo o procedimiento

Modulo de Entrar (http://alexservice.cloudapp.net/registrar.xhtml)

Estado de automatización

“No automatizada”

Tipo de prueba

Caja Negra

Prioridad

2

Iteración

3

Hardware Requerido

Equipos de cómputo

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 página e intentar completar el registro con el campo 'Usuario' vacío.

Descripción

La pagina Huizaches.com, 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 seudónimo), la cual usted mismo la introduce.

Condiciones de Entrada

Condiciones de Salida

Llenar el formulario de registro y mantener la conexión a internet.

Se informa al usuario que el campo contraseña no cumple con los requisitos mínimos 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

Evaluación de la prueba Propuesta

Pendiente de evaluación

Realizada sin éxito

Historial de Versiones Fecha Versión Descripción Firma Primera versión con el Fecha 01/06/2015

sistema Huizaches, para el propósito de pruebas.

Satisfactoria

Autor

Duración

Laura Vianeth Parra

15 min

Observaciones: Firma El campo contraseña cumple con el caso de prueba especificado, no permite el formulario si el campo Fecha contraseña no contiene al menos 1 carácter NO alfanumérico

Realizado por: Laura Vianeth Parra Parra

Firma

Fecha 01/06/2015

Informe Resumen de Pruebas A continuación mostrare algunos resúmenes 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 código fuente, en la sección LOGIN donde se tiene una condición 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 código fuente, en la sección Registrar donde se tiene una condición 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 página 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 condición con error si al momento de Agregar un producto este se registra o no e indica si hace falta algún campo obligatorio por rellenar. Ingresa (descripción) de tu producto

CONCLUSIÓN Como desde un principio se menciono que la documentación que aquí se esta mostrando esta basada en el proyecto de software en torno a la pagina web Huizaches.com, donde lo que se esta buscando es que este software funcione como un intermediario entre compradores y vendedores de la región de la ciudad de Culiacán, Sin. Durante el transcurso del proceso de pruebas al realizar la ejecución de estas se pudieron verificar las partes del código 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 aplicación de una manera mas fácil y con la que se sientan mas cómodos. En el desarrollo y pruebas de este sistema se pudo llegar a varias conclusiones acerca de este proyecto. Podemos decir que las tecnologías utilizadas fueron las adecuadas, pues se logró construir una herramienta que cumpliera con los propósitos 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 sólo una herramienta útil y que cuenta con los requerimientos necesarios para el comercio en la región, sino una herramienta que auxilia tanto a compradores como a vendedores a realizar sus actividades de compra/venta y también favorece y estimula la interacción entre los usuarios para las cuestiones comerciales.