Grupo10 TF PruebasSoftware

ESCUELA PROFESIONAL DE INGENIERÍA DE COMPUTACIÓN Y
SISTEMAS
11ELABORAR UN PLAN DE PRUEBAS PARA MEJORAR LA CALIDAD

DEL SOFTWARE EN LA VENTA Y CONTROL DEL RESTAURANTE
CONGA, LIMA
Pruebas de Software
Presentado por:
Gabino Huaringa, Juan Antonio
Saldaña Huamán, Fernando Daniel
Docente: Mg. Valenzuela Tasayco, Yamela Amparo
LIMA – PERÚ
2018
ÍNDICE
Página
RESUMEN.........................................................................................................................iii
ABSTRACT.......................................................................................................................iv
INTRODUCCIÓN...............................................................................................................v
CAPÍTULO I: DESCRIPCIÓN GENERAL.........................................................................1
1.1. Formulación del problema......................................................................................1
1.2. Objetivos.................................................................................................................1
1.2.1. Objetivo General..............................................................................................1
1.2.2. Objetivos específicos.......................................................................................1
1.3. Justificación.............................................................................................................2
1.4. Viabilidad.................................................................................................................2
CAPÍTULO II: MARCO TEÓRICO.....................................................................................4
2.1. Antecedentes..........................................................................................................4
2.2. Bases teóricas.........................................................................................................5
2.2.1. Pruebas de software........................................................................................5
2.2.2. Tipos de pruebas..............................................................................................6
2.2.3. Calidad de software..........................................................................................9
2.3. Definición de términos básicos.............................................................................10
CAPÍTULO III: METODOLOGÍA......................................................................................12
3.1. Diseño metodológico............................................................................................12
3.2. Cronograma..........................................................................................................12
CAPÍTULO IV: DESARROLLO........................................................................................14
4.1. Requerimientos para las pruebas.........................................................................14
4.2. Casos de pruebas.................................................................................................15
CAPÍTULO V: RESULTADOS.........................................................................................19
5.1. Resultado de las pruebas.....................................................................................19
CONCLUSIONES............................................................................................................30
RECOMENDACIONES....................................................................................................31
FUENTES DE INFORMACIÓN.......................................................................................32
ii
RESUMEN
El presente trabajo de investigación tiene como objetivo dar a conocer las diferentes
metodologías, pruebas de software y la aplicación de las mismas sobre un sistema. Se
desarrolló el modelo de pruebas de software, una vez que se terminó se pasó a realizar
un plan de pruebas que permitió conocer el panorama en el cual se ejecutaron las
pruebas de software. Para finalizar se analizaron todas y cada una de las pruebas de
software separadas por tipo para medir el estado de calidad en el que se encontró el
sistema. Las pruebas indicaron que aunque un 50% en promedio de ellas tienen
errores, no son de gravedad o pudieran comprometer la información del caso de
estudio. Dichos errores se pueden solucionar en un tiempo relativamente corto sin
afectar a los usuarios o al sistema mismo.
Las pruebas son el único instrumento que permite conocer el estado de calidad en el
que se encuentra un software, por lo cual son un factor importante para determinar si
se cumplen o no los requisitos funcionales del sistema. Es por eso que a través del
ciclo de vida del software y de las metodologías existentes siempre deben
contemplarse durante las diferentes fases que componen el desarrollo del software.
Las pruebas de software serán realizadas con mayor eficiencia, lo cual traerá múltiples
beneficios para la empresa, de esta forma, presentar un producto de calidad.
La investigación permite concluir con la identificación de las etapas de procesos de

pruebas y los documentos adecuados como entregables. Además de una selección de
herramientas que nos permite tener un reporte y control de observaciones encontradas.
Palabras claves: Calidad, modelo de prueba, herramientas de prueba, niveles de

pruebas, software, testing
iii
ABSTRACT
The objective of this research work is to make known the different methodologies,
software tests and the application of them on a system. The software testing model was
made, once it was done it was passed and a test plan was made so that the scenario in
which the software tests were executed was known. So that each and every one of the
software tests can be analyzed to know how to measure the quality status in which the
system is located. The tests indicate that in 50% of them on average have errors, there
is no serious problem or commitment in the information of the case study. These errors
can be solved at the same time.
The tests are the only instrument that allows to know the status of the quality in which a
software is found, so they are an important factor in determining if the functional
requirements of the system are met or not. Thus, throughout the life cycle of the
software and the methodologies that should always be considered during the different
phases that make up the software development.
The software tests will be carried out with greater efficiency, which will bring multiple
benefits for the company, this way, to present a quality product.
The investigation allows to conclude with the identification of the stages of the testing
processes and the appropriate documents as deliverables. In addition to a selection of
tools that allows us to have a report and control observations.
Keywords: Quality, test model, test tools, levels of tests, software, testing
iv
INTRODUCCIÓN
Un problema muy común en el desarrollo de software y que también se presenta

el restaurante Conga, es asegurar la calidad del servicio, esto se debe a que no hay
una apropiada metodología de pruebas para la validación de la aplicación web en el
área de calidad. En algunos casos comprobar que el producto final cumpla con los
requisitos del usuario no es suficiente, es por ello que se debe definir un proceso de
pruebas estandarizadas que indique cuales serían las mejores prácticas para el
planeamiento, diseño y ejecución de pruebas, además de identificar las mejores
herramientas y técnicas para las pruebas funcionales y no funcionales a realizar según
el proyecto.
Por lo anterior toda la empresa o profesional que se encuentra en el área del

desarrollo de software debe establecer una estrategia adecuada para probar sus
servicios o productos. Dichos productos deben pasar por diferentes tipos de pruebas
durante todo el ciclo de vida del software. Es importante tratar de encontrar el mayor
número de errores antes de que el producto sea implementado.
El sistema de ventas y control fue desarrollado por un grupo de alumnos de la

universidad San Martín, y cuenta con dos perfiles: Usuario y Administrador. Además
cuenta con 3 módulos: Registrar pedidos, donde solo los clientes registrados podrán
acceder a este módulo para poder pedir su orden online, módulo de Iniciar Sesión, el
cual permitirá hacer un registro de usuarios, solo los usuarios registrados podrán tener
acceso a la opción de pedir su orden a través del sistema web. Y el módulo de
mantenimiento: en este módulo solo tiene acceso el administrador, que se encargara
del mantenimiento de proveedores del restaurante así como el mantenimiento de
productos para tener un inventario de productos.
v
CAPÍTULO I:
DESCRIPCIÓN GENERAL
1.1. Formulación del problema
Baja calidad del sistema en la atención de ventas y control en el restaurante

Conga.
1.2. Objetivos
1.2.1. Objetivo General
Elaborar un plan de pruebas para mejorar la calidad del software en la

venta y control del restaurante Conga.
1.2.2. Objetivos específicos
Para facilitar el cumplimiento de nuestro objetivo central y solucionar el

problema central tenemos los siguientes objetivos específicos.
 Analizar los diferentes estándares, reglas, prácticas y normativas de

calidad internacional de pruebas de software; para entender los
conceptos básicos de calidad.
 Elaborar plan de pruebas para el software del restaurante Conga en el

módulo venta y control.
 Identificar y documentar los elementos que se deben cumplir en el

proceso de planeación y ejecución de pruebas.
 Diseñar y aplicar las pruebas de software en el módulo venta y control.
 Elaborar un reporte de la calidad del producto de software.

1.3. Justificación
El restaurante Conga juega un papel importante, al conectar a diferentes

personas relacionadas con el rubro de los inmuebles. Aunque para que esta conexión
entre las personas sea exitosa, es necesario garantizar la calidad del producto de
software, el cual debe ser evaluado por medio de diferentes pruebas y con ayuda de
una metodología. Estas herramientas permitirán encontrar los errores que pasaron
desapercibidos durante el desarrollo software y que pudieran comprometer la integridad
de la información del sistema.
El impacto tecnológico será positivo beneficiando al restaurante en la

satisfacción del usuario y proporcionando beneficios económicos a dicho restaurante.
1.4. Viabilidad
Para la viabilidad técnica se analiza y evalúa los recursos como información,

herramientas, tecnologías y el equipo de trabajo necesario con conocimientos y
habilidades para la realización del proyecto.
ROL RESPONSABLE DESCRIPCIÓN

Gestor de - Gabino Huaringa, Encargado de liderar al equipo
Proyecto Juan Antonio responsable.
- Gabino Huaringa,
Encargado de analizar las
Juan Antonio
Analista funcional funcionalidades del aplicativo, para el
- Saldaña Huamán,
control y supervisión del desarrollo.
Fernando Daniel
- Saldaña Huamán, Se encarga de probar el software para
Tester
Fernando Daniel detectar las fallas y errores.
SOFTWARE LICENCIA DESCRIPCIÓN

Herramienta para el administrador de base de datos en
Open
MySQL la gestión de base de datos aplicada en la fase de diseño
source
y desarrollo, ejecución.
2
EQUIPO CANTIDAD DESCRIPCIÓN
Indispensable para los programadores en el
desarrollo de los módulos.
Se utilizarán laptops con los siguientes requisitos
Laptop 1 mínimos:
- Procesador Intel Core I5
- Memoria RAM de 4GB
- Disco Duro de 1 TB
App service para crear aplicaciones en la nube para
la web y móvil. Especificaciones:
Servidor Web 1 - Windows
- 1.75 GB de RAM, 1 núcleo
- 10 GB de almacenamiento
Servicio de base de datos MySQL para los
desarrolladores. Especificaciones:
Servidor de Base
- 2 vCore
1
de Datos - 5 GB de almacenamiento
- 100 GB de almacenamiento de copia de
seguridad
3
CAPÍTULO II:
MARCO TEÓRICO
2.1. Antecedentes
Según Cardona (2009) menciona en su investigación que las pruebas son un

medio para asegurar la calidad del producto ya que nos permite identificar los defectos.
Es por ello que las pruebas se toman en cuenta en todas las etapas de desarrollo del
software. El CICLO-P es un método que usa una gran variedad de pruebas que
permiten cubrir gran parte del software y pueden tener un impacto pequeño en el
desarrollo. Con este método se logra integrar las pruebas con la etapa de desarrollo, lo
que conllevaría a mejorar los tiempos de pruebas y costos asociados.
Se puede notar que en la actualidad el proceso de desarrollo de software se ha

convertido en una actividad muy importante para toda empresa, y que con el apoyo de
las pruebas y los estándares de calidad se ha logrado conseguir que el producto
cumpla de manera más eficiente los requerimientos del cliente. Valdivia y Valdivia
(2005) mencionan en su investigación que el desarrollo de software se ha convertido en
una actividad programada, planificada y con un ciclo de vida definido que le otorga un
carácter formal. Además hace referencia que para la IEEE 1074 el ciclo de vida de
software es como una aproximación lógica a la adquisición, el suministro, el desarrollo,
la explotación y el mantenimiento del software. Mientras que para la ISO 12207-1 el
ciclo de vida es un marco de referencia que contiene los procesos, las actividades y las
tareas involucradas en el desarrollo, la explotación y el mantenimiento de un producto
de software, abarcando la vida del sistema desde la definición de requisitos hasta la
finalización de su uso.
Baldeón (2015) tuvo como objetivo el proponer un método basado en el estándar

ISO/IEC 25000-2005 para poder evaluar la calidad de los entregables de un proyecto.
Este método proporciona los lineamientos necesarios para contribuir al incremento de
la calidad del producto final y asegurar el cumplimiento de los requisitos del usuario. La
muestra para aplicar al análisis cuantitativo han sido 28 proyectos financieros, y el
instrumento usado para obtener la información son los reportes de error y bitácora de
4
pases a producción. Y se obtuvo como conclusión que la aplicación del método de
evaluación de calidad de software basado en ISO/IEC 25000 logró mejorar la calidad
del producto software, esto se vio reflejado en una menor cantidad de re-trabajo para
que el usuario de la conformidad del software y éste presente una menor cantidad de
errores luego del pase a producción del software. Asimismo, respecto a la mejora en la
calidad del software, se halló un 95% de confianza en que el método para evaluación
de calidad basado en ISO/IEC 25000 puede mejorar la calidad del software
2.2. Bases teóricas
2.2.1. Pruebas de software
Pruebas de software o Software testing son un conjunto de actividades,

tareas, técnicas y herramientas que buscan asegurar que la aplicación o
software funcione de manera apropiada, con el fin de encontrar todos los errores
o fallos que al final serán corregidos. Es decir es el proceso de ejecutar una serie
de pasos con la intención de encontrar fallos. 17 El proceso de pruebas se
centra en los procesos lógicos internos del software, asegurando que todas las
sentencias se han comprobado, y en los procesos externos funcionales, es decir,
la realización de las prueba para la detección de errores (Pressman, 2005). El
proceso de pruebas no va orientado a demostrar la falta de fallos en el software,
sino lo contrario, encontrar cuantos fallos existan, realizando todos los
escenarios posibles. Según CemKaner del Centro de Ensayo de Software
(Travieso, 2014) define las “pruebas” como una investigación técnica de un
producto bajo prueba con el fin de brindar información relativa a la calidad del
software, a los diferentes actores involucrados en un proyecto. Las pruebas de
software es una actividad en la cual un sistema o uno de sus componentes se
ejecutan en dos o más circunstancias previamente especificadas, los resultados
se observan y registran y se realiza una evaluación de algún aspecto (IEE Std
610.12, 1990). Lo que se busca con la realización de las pruebas es descubrir
todos los errores posibles y que se haga con un gasto mínimo de tiempo y
5
esfuerzo, a continuación en la Figura 1 se presenta un conjunto de principios
para las pruebas prueba.
2.2.2. Tipos de pruebas
Pruebas de unidad. Se centran en la verificación de la menor unidad o

módulo del software diseñado, con el propósito de descubrir errores dentro de
los límites del módulo. Por lo general las pruebas que se realizan son de interfaz
para verificar que la información fluye correctamente (Pressman, 2005). Para
llevar a cabo este tipo de pruebas se elaboran casos de prueba que recorran
todos los caminos posibles. Una vez que todos los módulos hayan sido probados
y los errores encontrados corregidos, se podrá pasar a la siguiente prueba que
es la integración.
Pruebas de integración. Según Pressman (2005) señala que constituye la

siguiente etapa de las pruebas de unidad, ya que en las pruebas unitarias se
verifica el comportamiento de los módulos o unidades y en las pruebas de
integración se verifica el comportamiento del conjunto de estas. Su objetivo es
construir una estructura del programa a partir de los módulos ya evaluados en
las pruebas unitarias. Un módulo podría presentar algún efecto inadvertido sobre
otro, es por ello que las pruebas de integración combinan distintos módulos con
la finalidad de verificar que se cumplan con las especificaciones.
Pruebas de sistema. Valdivia (2005) señala que tienen como finalidad

ejercitar el sistema basado en computadoras; para ello se llevan a cabo pruebas
de recuperación (cuando se fuerza un fallo y se verifica que la recuperación sea
correcta), seguridad (verifica la protección del sistema de accesos impropios),
resistencia (enfrentar situaciones anormales) y rendimiento (verificar el tiempo
de ejecución).
Pruebas de validación. Pressman (2005) las pruebas de validación se

llevan a cabo después de realizar las validaciones de integración, ya que en ese
momento la aplicación se encuentra completamente ensamblado con todos sus
6
módulos. Además este tipo se llevan a cabo mediante una serie de análisis de
caja negra que permiten demostrar que la aplicación cumple con los
requerimientos establecidos en el documento de análisis. Un elemento
importante para las validaciones es la revisión de la configuración, ya que con
esta se asegura que la aplicación se ha desarrollado correctamente y está apta
para soportar mantenimiento.
Pruebas de regresión. Según Valdivia (2005) sostiene que las pruebas de

regresión permiten asegurar que los cambios ocasionados por algún error
detectado anteriormente no introduzcan un comportamiento no deseado o
nuevos errores (bugs). Este tipo de pruebas pueden ser desarrolladas
manualmente 24 (reproducir de nuevo todos los casos de prueba) o utilizando
alguna herramienta automática que capture los casos de prueba y los resultados
para la siguiente reproducción y comparación
Pruebas funcionales o de caja negra. El nombre de pruebas funcionales

se debe a que al tester solo le interesa probar la funcionalidad del sistema y no
su desarrollo. Para llevar a cabo este tipo de pruebas se elaboran casos de
prueba, basados en el documento funcional o historias de usuario; que tengan
una gran posibilidad de revelar defectos en la aplicación. El analista de calidad
suministra datos de entrada y evalúa los datos de salida, sin preocuparse por el
procesamiento interno. Mayormente la estrategia para elaborar los casos de
prueba es probar primero el ingreso de información real y luego información
aislada, (Pressman, 2005).
Pruebas de desempeño. Para Pressman (2005) consiste en realizar

pruebas que demanden recursos en gran cantidad y nos permitan probar la
aplicación en tiempo de ejecución. Este se lleva a cabo durante todo el proceso
de pruebas, incluso a nivel de módulos individuales. Las pruebas de desempeño
para una aplicación web afectan principalmente a la configuración del servidor
(fallas no planificadas de componentes del sistema y mantenimiento),
configuración del cliente, la red y la frecuencia de peticiones. Es por ello que
estos análisis deben ser diseñadas con diferentes configuraciones; es decir
7
diferentes browsers, métodos de acceso a internet, velocidad de conexión y
velocidades de las maquinas.
Pruebas de usabilidad. Según Pérez (2006) explica que las pruebas de

usabilidad permiten obtener información acerca del diseño de la aplicación, de la
funcionalidad mínima requerida, de las limitaciones (ancho de banda, tipo de
navegador, interfaces, entre otros), de las preferencias del usuario (gráficos,
textos), de hábitos del usuario e incluso información específica del tipo de
usuario. Consiste en identificar y entender todas las respuestas y problemas que
el 25 usuario pueda tener cuando esté usando la aplicación. Este tipo de
pruebas se lleva a cabo durante todo el proceso de desarrollo del producto; en
un inicio evalúa la versión previa, en la etapa media se valida el diseño e informa
las mejoras; y en la etapa final las pruebas aseguran que el producto cumpla con
los objetivos del diseño.
Pruebas de compatibilidad. Según Pérez (2006) sostiene que este tipo de

pruebas nos permite asegurar que una aplicación web funciona adecuadamente
para todo tipo de clientes, ofrezca el mismo grado de funcionalidad en todos los
buscadores del mercado y se comporten de igual manera en las diferentes
plataformas y versiones, como Windows, Linux entre otros.
Pruebas de seguridad. Para el autor Pressman (2005) es uno de los tipos

de pruebas más importantes, debido a la gran cantidad de transacciones que se
realizan en internet. Es por ello que las pruebas deben cubrir un conjunto mínimo
de condiciones que incluyan la autenticación (validar usuarios), integridad
(información correcta), privacidad (permisos de usuarios), disponibilidad (que el
servicio siempre se encuentre en línea aun en presencia de fallas).
Pruebas de escabilidad. Según Bidart & Mujiaca (2002) señala que las
pruebas de escalabilidad nos permiten cuando y como se degrada el acceso
web en función del número de accesos. Consiste en crear escenarios reales con
ayuda de herramientas que simulen el número de transacciones simultáneas,
que nos permitan medir el volumen de datos y el tiempo total de transacciones
para obtener una imagen real de la experiencia del usuario. Para este tipo de
8
pruebas se llevan a cabo las pruebas de estrés, en la cual se prueba los límites
del sistema para determinar su nivel de tolerancia.
Pruebas de aceptación. Según Bidart & Mujiaca (2002) sostiene que las
pruebas de aceptación son llevadas a cabo por el usuario final antes que la
aplicación sea instalada en un 26 ambiente de producción. Su duración y
rigurosidad varía de acuerdo a los requerimientos establecidos en un inicio, es
decir, verifica si el producto está listo para ser implantado en un ambiente
operativo.
Pruebas de disponibilidad de servicio. Consiste en simular un periodo

largo de tráfico regular, sin sobrecarga. Este tipo de pruebas nos permiten
verificar cuanto tiempo el sistema trabajara con un rendimiento óptimo o si el
servicio sufre algún problema durante su tiempo de operatividad (Bidart &
Mujiaca, 2002).
Pruebas de idioma. Bidart & Mujiaca (2002) es una prueba a la cual

muchas veces no se le da importancia, pero debe ser tomada en cuenta ya que
también se prueban las funcionalidades del sitio en condiciones reales y con los
buscadores del idioma seleccionado, es por ello que no debe ser considerada
solo como una prueba superficial.
Pruebas de accesibilidad. Bidart & Mujiaca (2002) Consiste en analizar los

problemas que las personas con discapacidades puedan tener para acceder a
las páginas del sitio web, por lo que se intenta simular el modo en que ellos van
a acceder. Las pruebas de accesibilidad también nos permitirán mejorar el
acceso a la web y su navegación.
2.2.3. Calidad de software
La meta principal de todo el ciclo de vida del software es cumplir con los
requerimientos y producir software de calidad, pero esto va depender en su
totalidad de la coherencia entre los requisitos planteados y los obtenidos. Ambos
conceptos resaltan la necesidad de que un software de calidad debe satisfacer
9
los requisitos dados por el usuario. La obtención de un software con calidad
implica también la utilización de metodologías o procedimientos estándares para
el análisis, diseño, programación y prueba del software que permitan uniformar
el trabajo, con el fin de obtener una mayor confiabilidad, mantenibilidad y
facilidad de prueba, a la vez que eleven la productividad, tanto para el desarrollo
como para el control de la calidad del software.
Se entiende por calidad del software, el grado en el que producto

incorpora un conjunto de características, definidas por el equipo del proyecto, de
tal manera que se garantiza su eficiencia de uso respecto a los a requerimientos
del cliente, así la calidad también puede afectar la relación entre el usuario y la
organización que proporciona el software durante su iteración.
2.3. Definición de términos básicos
 Falla. Es cuando un sistema o alguno de sus componentes obtienen un

resultado incorrecto. Es la manifestación de un defecto y se puede producir
en cualquier etapa. Es observada por los usuarios.
 Error. Es una equivocación realizada por una persona que al llevar a cabo
alguna actividad de desarrollo de software produce o genera un resultado
incorrecto.
 Bug. Se refiere a cualquier cosa que puede estar mal en el software. Cuando
se reporta un bug este puede referirse a un defecto o una falla. Distintos bugs
pueden mostrarse de la misma forma pero pueden tener distintas causas.
 Caso de prueba. Es un conjunto de valores de entrada, condiciones de

ejecución y resultados esperados, para evaluar un determinado flujo de
acuerdo a los requerimientos solicitados.
 Verificación. Se refiere a la evaluación, revisión, inspección y controles del

producto intermedio para determinar si cumple las condiciones establecidas
en el inicio de la fase.
10
 Validación. Se refiere a la evaluación del sistema para determinar si se
cumplen o no con los requerimientos establecidos. Para llevar a cabo la
validación es necesario ejecutar el código.
 Incidencia. Cualquier suceso o circunstancia que ocurre en el desarrollo de

un producto y que puede afectar el resultado final.
 Métrica. Escala de medida y el método utilizado para la medición.
11
CAPÍTULO III:
METODOLOGÍA
3.1. Diseño metodológico
La metodología del proyecto determinada asegura la producción de los

entregables en cada paquete de trabajo definido en las fases mediante una estructura
de descomposición del trabajo.
3.2. Cronograma
Se presenta el cronograma, según el diseño metodológico descrito, con las

actividades, la secuencia de actividades y estimación de duración de las actividades.
12
13
CAPÍTULO IV:
DESARROLLO
4.1. Requerimientos para las pruebas
La siguiente lista identifica aquellos elementos (casos de uso, requisitos

funcionales y no funcionales) que han sido identificados como objetivos de las pruebas
y que serán sometidos a prueba:
 Iniciar sesión.
 Cerrar sesión.
 Administrar usuarios.
 Administrar proyectos.
 Generar informes.
 Consultar tareas de proyectos finalizados.
 Consultar plan de trabajo.
 Generar informe de actividades.
 Cambiar de proyecto.
 Consultar proyectos terminados.
 Rellenar calendario vacacional.
 Definir proyecto.
 Asignar personal a tareas 
 Finalizar un período.
 Consultar proyecto.
 Revisar informe de actividades.
14
4.2. Casos de pruebas
Nombre del Sistema: Sistema de Ventas Conga Nivel de Pruebas: 1

Tipos de Pruebas: Prueba de
funcionalidad, pruebas de
Caso de Uso: Iniciar Sesión
desempeño, pruebas de interfaz de
usuario
Autor del Caso de Prueba:
Requerimiento: Usuario Registrado
Fernando Saldaña Huaman
Probador: Fernando Saldaña
Nombre del caso de prueba: Iniciar Sesión Conga
Huaman
Fecha
Fecha Creación:
Versión del Caso de Prueba: 1.0 Ejecución:
02/11/18
03/11/18
Condición(es) para que se ejecute el Caso de Prueba: Se deben cumplir con los recursos
necesarios en cuanto a software y hardware necesarios para que se pueda ejecutar este
caso de prueba
Se deben cumplir con los recursos necesarios en cuanto a software y hardware necesarios
para que se pueda ejecutar este caso de prueba
Software de Auditorias antes
Procesador AMD A8 mencionado
Memoria RAM 1 GB medir el rendimiento de la aplicación
Para la ejecución del Caso de pruebas: Contar con todas las herramientas citadas anteriormente
Esperado
Elementos a probar Condición Valor(es) s Obtenido
Deben mandar la información a la
TextBox 100% 100% 95%
BD
Deben concordar de acuerdo al
Labels 100% 95% 100%
cuadro de texto
Deben cumplir con la función:
Botones 100% 95% 100%
Insertar, grabar, modificar, etc.
Criterios de Aprobación del caso de prueba: Debe cumplir con los resultados esperados al
menos en 95%
Decisión de aprobación del caso de pruebas: Aprobó: X Fallo: _____
Fecha de aprobación del caso de pruebas: 03/11/18

Caso de Uso: Mantener Proveedor Tipos de Pruebas: Prueba de
15
Requerimiento: Proveedor Registrado
Nombre del caso de prueba: Mantener proveedor
Huaman
Fecha
Fecha Creación:
03/11/18
04/11/18
caso de prueba
Esperado
TextBox 100% 100% 95%
BD
Labels 100% 95% 100%
cuadro de texto
La cuadrilla debe tener los datos
DataGriew 100% 95% 100%
de la BD.
Botones 100% 95% 100%
menos en 95%

Caso de Uso: Mantener Producto
usuario
Requerimiento: Producto Registrado
Nombre del caso de prueba: Mantener producto
Huaman
Versión del Caso de Prueba: 1.0 Fecha Creación: Fecha
03/11/18 Ejecución:
16
04/11/18
caso de prueba
Esperado
TextBox 100% 100% 95%
BD
Labels 100% 95% 100%
cuadro de texto
DataGriew 100% 95% 100%
de la BD.
Botones 100% 95% 100%
menos en 95%

Caso de Uso: Realizar Pedido
usuario
Requerimiento: Registrado Usuario
Nombre del caso de prueba: Realizar pedido
Huaman
Fecha
Fecha Creación:
03/11/18
04/11/18
caso de prueba
17
Esperado
TextBox 100% 100% 95%
BD
Labels 100% 95% 90%
cuadro de texto
DataGriew 100% 90% 90%
de la BD.
Botones 100% 90% 90%
menos en 95%
Decisión de aprobación del caso de pruebas: Aprobó: ____ Fallo: X
18
CAPÍTULO V:
RESULTADOS
5.1. Resultado de las pruebas
Prueba Login de usuario Modulo: Login

prerrequisito El usuario aun ha realizado Login
s Existe un usuario de admintrador y user
Ubicación http://localhost:8080/Restaurante1/login1.jsp
Pasos 1. Ingresar al sistema web del restaurante
2. Ingresar a la opción Iniciar Sesión
3. Ingresar el usuario y password
Hacer clic en Iniciar Sesión
19
Observaciones:
 Si se deja en blanco los datos, el sistema permita entrar como usuario

logeado.
 No hay mensaje de alerta en caso de contraseña mal ingresada.
 No hay mensaje de alerta en caso de usuario mal ingresado.
 No hay mensaje de advertencia al oprimir el boton “Iniciar Sesión” y tener los
campos en blanco.
Prueba Registro de Proveedores Modulo: Mantener

Proveedor
prerrequisito El administrador estará logeado
s
Ubicación http://localhost:8080/Restaurante1/administrador.jsp
2. Ingresar a la opción “Lista de Proveedores”
3. Ingresar en el icono “Registrar Proveedor”
4. Ingresar campos del Proveedor
Hacer clic en Registrar
20
Observaciones:
 Permite ingresar valores alfabéticos en el campo Teléfono, no está validado

 El campo Correo Electrónico no está validado ya que permite ingresar cualquier
dato, no está validado.
 No hay mensaje de alerta en caso se seleccione “Registrar Proveedor” con

campos vacíos.
 Los campos Provincia y País, tampoco están validados.
21
 El registro de proveedores no cuentan con un RUC de la empresa.
 No hay mensaje de alerta en caso de ingresar mal los campos.
 Al retroceder la página, se vuelven a llenar los datos del último registro, no
cuenta con un botón de regresar a la lista de proveedores
Prueba Modificar Proveedores Modulo: Mantener

Proveedor
s El administrador Seleccionara lista de proveedores
Pasos 1. Seleccionar el proveedor a editar datos.
2. Seleccionar el icono “Editar Proveedor”
3. Ingresar los campos a modificar.
Hacer clic en Editar Proveedor
Observaciones:
22
 El campo Teléfono no está validado, permite ingresar campo alfabético.
 El campo correo Electrónico no está validado, permite ingresar cualquier
nombre sin el formato”@........”
 Los campos Provincia y País no están validados.
 El sistema no muestra mensaje de alerta en caso faltar rellenar campos.
 El sistema no muestra alerta si se “Edita Proveedor” con los campos
vacíos.
Prueba Eliminar Proveedores Modulo: Mantener

Proveedor
s El administrador Seleccionara lista de proveedores
Pasos 1. Seleccionar el proveedor a eliminar datos.
2. Seleccionar el icono “Eliminar Proveedor”
Hacer clic en Eliminar Proveedor
23
Observaciones:
 No hay mensaje de alerta en caso, haya error de eliminación, y el

usuario se quiera rectificar.
Mantener Producto
24
Prueba Registro de Productos Modulo: Mantener
Producto
s
Ubicación http://localhost:8080/Restaurante1/agregarProductos.jsp
25
2. Ingresar a la opción “Lista de Productos”
3. Ingresar en el icono “Registrar Producto”
4. Ingresar campos del Producto
Hacer clic en Registrar Producto
Observaciones:
 El campo precio no está validado, se puede ingresar campos alfabéticos.

 No hay mensaje de alerta, al momento de repetir el código de producto
ya registrado.
 Si seleccionamos el botón “Registrar Pedido”, puede registrar campos
vacíos que son obligatorios.
26
 No hay mensaje de alerta, al registrar campos vacíos obligatorios.
 El campo categoría no está validado.
Prueba Modificar Productos Modulo: Mantener

Productos
s El administrador Seleccionara lista de productos
Ubicación http://localhost:8080/Restaurante1/editarProducto.jsp
Pasos 1. Seleccionar el proveedor a editar datos.
2. Seleccionar el icono “Editar Proveedor”
3. Ingresar los campos a modificar.
Hacer clic en Editar Proveedor
27
Observaciones:
 El cambo nombre no está validado, acepta campos numéricos.

 El campo precio no está validado, acepta campos alfabéticos
 Si seleccionamos el botón “Editar Producto” edita campos vacíos
obligatorios.
 No hay mensaje de alerta, en caso se graba campos obligatorios
vacíos.
Prueba Eliminar Productos Modulo: Mantener

Proveedor
s El administrador Seleccionara lista de productos
Ubicación http://localhost:8080/Restaurante1/eliminarProducto.jsp
Pasos 1. Seleccionar el producto a eliminar datos.
2. Seleccionar el icono “Eliminar Producto”
Hacer clic en Eliminar Producto
Observaciones:
 No hay mensaje de confirmación al eliminar producto, en caso haya un

error del usuario y poder evitar eliminar un producto.
28
29
CONCLUSIONES
Se observa que el proceso de pruebas impacta en los riesgos del producto

software; por ende, para las empresas de software es vital formular y adecuar un buen
proceso de pruebas de calidad de software.
Al implementar un proceso de pruebas de calidad de software se genera un

control y seguimiento a los defectos o faltas y a los fallos, de manera que las
soluciones que se generen tengan un mayor nivel de calidad.
El tiempo que se le debe dedicar a las pruebas es preponderante en el éxito de

la realización de las mismas, se resalta el tiempo que debe estimarse sea el necesario
y suficiente para garantizar la funcionalidad en los parámetros establecidos por el
gestor de proyectos.
30
RECOMENDACIONES
Es importante que los diferentes roles en una empresa de desarrollo software o

en un equipo de trabajo tengan un conocimiento básico sobre el proceso de pruebas de
calidad. Esto permite que en cada etapa del ciclo del proyecto se manejen mejores
estándares de producción y por ende de calidad.
Tener en cuenta que se debe contar con una estrategia de mejora continua en
base a la información que se obtiene del aplicativo informático, de esta forma tener una
retroalimentación constante para cada proceso a realizar y evitar repetición de errores,
de esta forma mejorar la eficiencia de las actividades realizadas.
Es importante contar con un plan de capacitación para los todos los miembros
de equipo de cada área para que se familiaricen con el aplicativo, y poder solventar las
dudas que se generen en el camino, de esta forma poder iniciar la implementación con
un grupo piloto.
31
FUENTES DE INFORMACIÓN
Baldeón Villanes, E. J. (2015). Método para la evaluación de calidad de software

basado en ISO/IEC 25000 . (Tesis de maestría), Universidad San Martín de
Porres, Lima.
Bidart, C., & Mujica, J. (2002). Web Testing 'Aspectos teóricos y prácticos'. Universidad
Técnica Federico Santa María.
Cardona Velásquez, C. (2009). Propuesta metodológica para la realización de pruebas

de software en un ambiente productivo. (Tesis de pregrado), Universidad
Nacional de Colombia, Colombia.
Pérez Lamancha, B. (2006). Proceso de testing funcional independiente. (Tesis de

maestría), Universidad de la República, Montevideo, Uruguay.
Pressman, R. (2005). Ingeniería del software. The McGraw-Hill.
Travieso, M. (2014). Blog de CES. Obtenido de http://blog.ces.com.uy/?cat=12
Valdivia Espinoza, D. R., & Valdivia Espinoza, E. G. (2005). Estándares de calidad para
pruebas de software. (Tesis de pregrado), Universidad Nacional Mayor de San
Marcos, Lima.
32

Grupo10 TF PruebasSoftware

Cargado por

Copyright:

Formatos disponibles

Grupo10 TF PruebasSoftware

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Grupo10 TF PruebasSoftware

Cargado por

Copyright:

Formatos disponibles

ESCUELA PROFESIONAL DE INGENIERÍA DE COMPUTACIÓN Y

11ELABORAR UN PLAN DE PRUEBAS PARA MEJORAR LA CALIDAD

Docente: Mg. Valenzuela Tasayco, Yamela Amparo

La investigación permite concluir con la identificación de las etapas de procesos de

Palabras claves: Calidad, modelo de prueba, herramientas de prueba, niveles de

Un problema muy común en el desarrollo de software y que también se presenta

Por lo anterior toda la empresa o profesional que se encuentra en el área del

El sistema de ventas y control fue desarrollado por un grupo de alumnos de la

1.1. Formulación del problema

Baja calidad del sistema en la atención de ventas y control en el restaurante

1.2.1. Objetivo General

Elaborar un plan de pruebas para mejorar la calidad del software en la

1.2.2. Objetivos específicos

Para facilitar el cumplimiento de nuestro objetivo central y solucionar el

 Analizar los diferentes estándares, reglas, prácticas y normativas de

 Elaborar plan de pruebas para el software del restaurante Conga en el

 Identificar y documentar los elementos que se deben cumplir en el

 Diseñar y aplicar las pruebas de software en el módulo venta y control.

 Elaborar un reporte de la calidad del producto de software.

El restaurante Conga juega un papel importante, al conectar a diferentes

El impacto tecnológico será positivo beneficiando al restaurante en la

Para la viabilidad técnica se analiza y evalúa los recursos como información,

ROL RESPONSABLE DESCRIPCIÓN

SOFTWARE LICENCIA DESCRIPCIÓN

Según Cardona (2009) menciona en su investigación que las pruebas son un

Se puede notar que en la actualidad el proceso de desarrollo de software se ha

Baldeón (2015) tuvo como objetivo el proponer un método basado en el estándar

2.2. Bases teóricas

2.2.1. Pruebas de software

Pruebas de software o Software testing son un conjunto de actividades,

2.2.2. Tipos de pruebas

Pruebas de unidad. Se centran en la verificación de la menor unidad o

Pruebas de integración. Según Pressman (2005) señala que constituye la

Pruebas de sistema. Valdivia (2005) señala que tienen como finalidad

Pruebas de validación. Pressman (2005) las pruebas de validación se

Pruebas de regresión. Según Valdivia (2005) sostiene que las pruebas de

Pruebas funcionales o de caja negra. El nombre de pruebas funcionales

Pruebas de desempeño. Para Pressman (2005) consiste en realizar

Pruebas de usabilidad. Según Pérez (2006) explica que las pruebas de

Pruebas de compatibilidad. Según Pérez (2006) sostiene que este tipo de

Pruebas de seguridad. Para el autor Pressman (2005) es uno de los tipos

Pruebas de disponibilidad de servicio. Consiste en simular un periodo

Pruebas de idioma. Bidart & Mujiaca (2002) es una prueba a la cual

Pruebas de accesibilidad. Bidart & Mujiaca (2002) Consiste en analizar los

2.2.3. Calidad de software

Se entiende por calidad del software, el grado en el que producto

2.3. Definición de términos básicos

 Falla. Es cuando un sistema o alguno de sus componentes obtienen un

 Caso de prueba. Es un conjunto de valores de entrada, condiciones de

 Verificación. Se refiere a la evaluación, revisión, inspección y controles del

 Incidencia. Cualquier suceso o circunstancia que ocurre en el desarrollo de

 Métrica. Escala de medida y el método utilizado para la medición.

3.1. Diseño metodológico

La metodología del proyecto determinada asegura la producción de los

Se presenta el cronograma, según el diseño metodológico descrito, con las

4.1. Requerimientos para las pruebas

La siguiente lista identifica aquellos elementos (casos de uso, requisitos

 Consultar tareas de proyectos finalizados.

 Consultar plan de trabajo.

 Generar informe de actividades.