¡Descarga Pruebas de Calidad de Software: Un Análisis de las Diferentes Fases y Herramientas y más Esquemas y mapas conceptuales en PDF de Gestión de Proyectos solo en Docsity!
“AÑO DEL BICENTENARIO DEL PERÚ: 200 AÑOS DE INDEPENDENCIA”
PRUEBAS DE CALIDAD DE SOFTWARE
PRODUCTO ACADÉMICO Nº 0 3
Ejecución de casos de Pruebas
PROYECTO INFORME - CASO DESPEGAR.COM
Docente : SANDRA ANALIA WONG DURAND
Integrantes:
• JOSE ANTONIO TELLO JIMENEZ COD:
• RICARDO DEMETRIO GALLEGOS GARCIA COD:
• RONNY JHANCARLO GAGO PIZARRO COD:
• ARNOLD MAX ROJAS VASQUEZ COD:
• DEYVI ALFREDO SONCCO QUISPE COD:
PERÚ
INDICE
- 10 CASOS DE PRUEBAS FUNCIONALES
- 1.1 Pruebas Unitarias.
- 1.2 Prueba de componentes.
- 1.3 Prueba de humo.
- 1.4 Pruebas de integración.
- 1.4.1 Prueba de interfaz.
- 1.5 Pruebas de regresión.
- 1.6 Prueba de cordura.
- 1.7 Pruebas de aceptación de usuario.
- 1.8 Prueba de Test Case.
- 1.9 Pruebas Alpha.
- 1.10 Pruebas Beta.
- 2 05 CASOS DE PRUEBAS NO FUNCIONALES
- 2.1 Pruebas de carga.
- 2.2 Pruebas de usabilidad
- 2.3 Pruebas de seguridad
- 2.4 Pruebas de recuperación y Tolerancia a Fallas
- 2.5 Pruebas de mantenibilidad
- 3 DETERMINACIÓN DEL FLUJO DE PRUEBAS DE REGRESIÓN
- 3.1 REGRESIÓN DE COMPRA DE PASAJES DE VUELO
- 4 05 HERRAMIENTAS DE EJECUCIÓN DE PRUEBAS DE AUTOMATIZACIÓN
- 4.1 02 de pruebas Funcionales
- 4.2 02 de pruebas No Funcionales
- 4.3 01 de pruebas Unitarias
- 4.4 Nombre de la herramienta
- 4.4.1 Herramienta
- 4.4.2 Herramienta
- 4.4.3 Herramienta
- 4.4.4 Herramienta
- 4.4.5 Herramienta
1.2 Prueba de componentes. Se ejecutan de forma independiente para comprobar que el resultado sea el requerido su objetivo es verificar las funcionalidades y usabilidades de los componentes, aunque no se limite solo a eso. Un ejemplo de esta prueba puede ser cualquier elemento que tenga entrada y deba generar alguna salida puede ser el módulo del código, página web, pantallas e incluso un sistema dentro de otro sistema más grande en un componente aquí algunos usos de los componentes que se pueden probar.
- Pruebas de login con credenciales validas e invalidas
- Inyección de SQL a través de componentes de UI para asegurar la seguridad
- Prueba de carga para asegurar el rendimiento
- Prueba de UI para usabilidad y accesibilidad 1.3 Prueba de humo. Se realizan para verificar si las funcionalidades más significativas de la aplicación funcionan o no de forma que lo más básico del software se ejecute de forma correcta con pruebas sencillas y rápidas. Es una de las pruebas más importantes y debería de ser la primera que se realice en una nueva compilación, la prueba de humo es común y aunque a veces no se tiene claro su concepto no se trata de realizar pruebas exhaustivas sino de verificar que la funcionalidad crítica del sistema realmente funciona bien. Si la prueba es exitosa será entonces una compilación estable el equipo QA realizara pruebas funcionales para las características o funcionalidades recién agregadas posteriormente o pruebas de regresión según la situación por otro lado si esta no es estable y falla la compilación
lo común es que se devuelva al equipo de desarrollo para solucionar los problemas de compilación y crear una nueva. 1.4 Pruebas de integración. Se realiza de forma automatizada para probar componentes individuales con el objetivo de verificar los módulos que trabajan de forma individual funcionan cuando estén integrados. El objetivo de realizar pruebas es porque comúnmente los desarrolladores se enfocan en construir diferentes módulos del sistema simultáneamente y no se centran en otros las pruebas de integración permiten que los datos y comandos operativos fluyan entre módulos hacer que todo actúe como partes de un solo sistema en lugar de aplicativos aislados usualmente nos ayuda a identificar problemas en las operaciones de la interfaz de usuario, formatos de datos, invocar API, acceso a base de datos entre otras. Algunas de las verificaciones que se realizan en las pruebas de integración son: 1.4.1 Prueba de interfaz. En la comprobación de las transferencias de datos entre componentes prueba de interfaces como servicios web, API, entre otros se realiza para verificar que los componentes estén sincronizados entre sí ayudan a determinar que diferentes funciones como la transferencia de datos entre los diferentes elementos del sistema se realizan de acuerdo con la forma en que fueron diseñadas. 1.5 Pruebas de regresión. Es normal que los desarrolladores modifiquen y mejoren las funcionalidades de su desarrollo por esto existe una gran posibilidad de que puedan causar efectos inesperados en su comportamiento estas pruebas de regresión se realizan para asegurar que los cambios o adiciones no hayan alterado ni eliminado las funcionalidades existentes.
evitar reprocesos y garantizar las funcionalidades de la aplicación tanto para el usuario final como para el cliente. 1.8 Prueba de Test Case. Son las condiciones o variables bajo las cuales el analista determinará si el requisito de una aplicación es parcial o completamente satisfactorio lo que caracteriza un escrito formal de caso de prueba es que hay una entrada conocida y una salida esperada los cuales son formulados antes de que se ejecute la prueba la entrada conocida debe probar una precondición y la salida esperada debe probar una postcondición. 1.9 Pruebas Alpha. Se realiza cuando el software está en desarrollo y cuyo objetivo es asegurar que lo que estamos desarrollando es probablemente correcto y útil para el cliente. Son normalmente realizadas contra un prototipo desarrollado rápidamente y con poco coste realizado para poder experimentar con el de esta forma si las pruebas alfa fallan no hemos desperdiciado mucho tiempo ni dinero una vez que las pruebas ALPHA se completen el prototipo debería ser descartado y aprovechar todo lo que se ha aprendido sobre el problema para el desarrollo de la versión final. 1.10 Pruebas Beta. Se realizan cuando el sistema esta teóricamente correcto y pasa a ejecutarse en un entorno real. Es la fase que le sigue a las pruebas Alpha no importan cuan bueno que sea nuestro proceso de desarrollo siempre habrá fallos que no han sido descubiertos por los desarrolladores ni por el equipo de pruebas las pruebas beta son pruebas para localizar esos problemas que no han sido detectados y poder corregirlos antes de liberar una versión la prueba debería ser realizada por usuarios finales
de este modo dependiendo de la naturaleza del software. A los que realizan este tipo de pruebas beta se les llama beta tester debido a que realizan este tipo de pruebas y comunicar los errores pueden ser muy tedioso y frustrante normalmente se brinda alguna clase de incentivo. 2 05 CASOS DE PRUEBAS NO FUNCIONALES Las pruebas No Funcionales considerados para el presente proyecto Caso Despegar, se ha visto por conveniente realizar las siguientes pruebas por ser una empresa dedicada a la venta de servicios de viaje con sus diversas modalidades que brinda (Alojamientos, Vuelos, Paquetes, Escapadas, Actividades turísticas, Renta de autos, Disney, Seguros de viajes, Cruceros, Traslados), que por medio de una plataforma virtual (Web). 2.1 Pruebas de carga. Las pruebas de carga se utilizaron para la simulación de demanda como si de manera simultánea existiese miles de usuarios haciendo uso de la herramienta esto con el objetivo de identificar la máxima capacidad operativa de la aplicación (Página Web), así como también poder identificar los cuellos de botella y las causas de posibles degradaciones del desempeño. Para poder ejecutar este tipo de prueba se requiere el uso de herramientas testing que nos ayuden a simular la carga en esta ocasión se utilizó el software SoapUI ( Herramienta, desarrollada en java, para la realización de pruebas a aplicaciones con arquitectura orientada a servicio y transferencia de estado representacional. Soporta múltiples protocolos como SOAP, REST, HTTP, JMS, AMF y JDBC. )
los clientes (tester) que coadyuvaron a presentar una aplicación muy fácil. Las características evaluadas incluyen: Facilidad de aprendizaje: Qué tan fácil es para los usuarios realizar funciones básicas la primera vez que utilizan la aplicación. Eficiencia: Que tan rápido los usuarios pueden realizar sus tareas. Memorización: Que tan fácil de memorizar es el uso de la aplicación, esto es, cuando un usuario pasa mucho tiempo sin usar la aplicación, puede recordar lo suficiente para usarla con efectividad la próxima vez, o tiene que empezar a aprender de nuevo. Errores: Cuántos errores atribuibles al diseño o comete el usuario, que tan severos son y qué tan fácil es recuperarse de los mismos. Satisfacción: Que tanto le gusta o no al usuario utilizar el sistema.
2.3 Pruebas de seguridad Dado que la aplicación maneja información personal, confidencial e información de tarjetas de crédito o débito de cada usuario registrado que haya realizado uso de nuestro servicio. Es muy necesario probar los atributos o características de seguridad del sistema, que tan seguro ha sido desarrollado, si puede ser vulnerado o si existe un control de acceso por medio de las cuentas de usuarios. Con estas pruebas de seguridad podemos garantizar la confidencialidad, integridad, autenticación, autorización y la disponibilidad, para que el cliente pueda estar tranquilo con el servicio brindado de Despegar.com. Para estas pruebas se recomienda el uso del software OWASP (Desarrolladores de Software, Tester de Software, Especialistas de Seguridad). “La seguridad de un sistema informático es inversamente proporcional a la estupidez del administrador”. owasp.org.
2.5 Pruebas de mantenibilidad Según las políticas de empresa Despegar.com, efectúa como tarea Básicamente consiste en evaluar qué tan fácil es realizar el mantenimiento de un sistema o aplicación. Esto significa que tan fácil es analizar, cambiar y probar estos cambios. Para realizar esta prueba deben evaluarse la forma en que está implementada la aplicación, siguiendo buenas prácticas de ingeniería de software. Es decir, que se estén siguiendo los patrones recomendados de ingeniería de software y que no se estén introduciendo inadvertidamente anti-patrones, esto es, que no se estén cometiendo errores comunes de programación. 3 DETERMINACIÓN DEL FLUJO DE PRUEBAS DE REGRESIÓN 3.1 REGRESIÓN DE COMPRA DE PASAJES DE VUELO Nombre CP 01. Registro de usuario Precondición No aplica. Pasos de ejecución (secuencias)
- Escribir en el browser la siguiente url: https://www.despegar.com.pe/.
- Ingresar a Iniciar Sesión y hacer clic en “Regístrate”.
- Seleccionar la opción de registrarse con Facebook, Google o con otro email. 4.Ingresar los datos respectivos de la cuenta seleccionada (Facebook, Google, email)
- Hacer click en botón aceptar. Alternativas No aplica.
Errores
- El sistema indica el mensaje “cuenta ya existente”.
- El sistema indica el mensaje “contraseña poco segura”.
- El sistema no logra registrar la cuenta. Postcondición
- El sistema debe mostrar la confirmación de la cuenta.
- En el caso de que el correo o la cuenta ya existe, debe aparecer el mensaje “Cuenta ya existente”.
- En el caso que exista problemas de conexión interna del sistema para registrar la cuenta, debe enviarse el mensaje “comuníquese con mesa de ayuda, en caso de tener problemas de conexión”. Nombre CP 02. Ingresar usuario Precondición CP 01. Registro de usuario Pasos de ejecución (secuencias) 1.Luego de haberse registrado
- Ingresar a Iniciar Sesión.
- Seleccionar la cuenta que ya registramos.
- Hacer click en botón aceptar. Alternativas No aplica. Errores 1. El sistema indica el mensaje “usuario incorrecto”.
- El sistema indica el mensaje “contraseña incorrecta”.
- El sistema proporciona acceso a perfil erróneo de usuario ingresado
Postcondición
- El sistema debe mostrar los vuelos disponibles según los parámetros dados.
- En el caso de mal ingreso de origen o destino, debe aparecer el mensaje “No hay vuelos disponibles para esta búsqueda”.
- En el caso de ingresar una fecha y no haber vuelos ese día, debe aparecer el mensaje “No hay vuelos disponibles en estas fechas”. Nombre CP 04. Comprar de vuelo Precondición CP 03. Buscar vuelo Pasos de ejecución (secuencias)
- En la pestaña de los vuelos ya buscados seleccionar la aerolínea según el precio y horario que más se acomode a las necesidades del usuario.
- Seleccionar “tarifa Basic”, “tarifa Light”, “tarifa Plus” si se le sumará más equipaje.
- Luego de seleccionar la tarifa de equipaje hacer click en continuar.
- Se da click en “seleccionar” de acuerdo con el vuelo escogido.
- Se selecciona el método de pago.
- Se ingresa los datos de la tarjeta.
- Se ingresan los datos de las personas a viajar.
- Hacer click en botón comprar. Alternativas No aplica. Errores
- El sistema indica el mensaje “Debe seleccionar una tarifa de equipaje”.
- El sistema indica el mensaje “Datos de tarjeta inválidos”.
- El sistema indica el mensaje “Faltan ingresar datos”. Postcondición
- El sistema debe mostrar el menú de compra de vuelo.
- En el caso de no ingresar la tarifa de equipaje, debe aparecer el mensaje “Debe seleccionar una tarifa de equipaje”.
- En el caso de no ingresar los datos correctos de la tarjeta, debe aparecer el mensaje “Datos de tarjeta inválidos”.
- En el caso de no ingresar todos los datos de los pasajes, debe aparecer el mensaje “Faltan ingresar datos”.
Errores
- El sistema indica el mensaje “Debe seleccionar una tarifa de equipaje”.
- El sistema indica el mensaje “Datos de tarjeta inválidos”.
- El sistema indica el mensaje “Faltan ingresar datos”. Postcondición
- El sistema debe mostrar el menú de compra de vuelo.
- En el caso de no ingresar la tarifa de equipaje, debe aparecer el mensaje “Debe seleccionar una tarifa de equipaje”.
- En el caso de no ingresar los datos correctos de la tarjeta, debe aparecer el mensaje “Datos de tarjeta inválidos”.
- En el caso de no ingresar todos los datos de los pasajes, debe aparecer el mensaje “Faltan ingresar datos”. 0 5 HERRAMIENTAS DE EJECUCIÓN DE PRUEBAS DE AUTOMATIZACIÓN 3.2 0 2 de pruebas Funcionales Épica Definir parámetros del servicio de venta de recuerdos ID-HU 003 Owner: Ronny Gago Título HU Escoger recuerdo de viaje Puntos de estimación Sprint 1
Descripción HU: Como usuario, quiero escoger un recuerdo de viaje durante el vuelo para poder comprarlo. Criterios de Aceptación: Escenario: Se obtiene el comprobante de compra Dado que el usuario quiere escoger un recuerdo de viaje Cuando el usuario selecciona el recuerdo y selecciona realizar compra Entonces el sistema muestra formulario de tipo de pago de forma automática. Épica Definir parámetros del servicio de niñeras ID-HU 005 Owner: ronny gago Título HU Escoger día y horarios del servicio Puntos de estimación Sprint 1 Descripción HU: Como usuario, quiero escoger los días y horarios en los cuales requiere contar con el servicio para poder saber el pago exacto que debo realizar. Criterios de Aceptación: Escenario: Se obtiene el monto total del servicio Dado que el usuario quiere escoger los días y el horario en los cuales quiere contar con el servicio de niñera Cuando el usuario selecciona el horario en el cual desea el servicio Entonces el sistema muestra el monto total por el servicio de niñeras de forma automática.
